Published on: 2022-05-02T15:59:49+00:00
In a recent email conversation on the bitcoin-dev mailing list, Jeremy Rubin discusses the correct timestamping service model that should be followed by OpenTimestamps (OTS). He suggests that if OTS does not conform to their proposed model, it may be considered unreliable. The author also questions whether there is any formal proof of what guarantees OTS provides against which threat model and suggests that a formal model of OTS would be necessary.In response, Peter Todd argues that linearization for timestamping service doesn't prevent any attack and questions Rubin's understanding of cryptography. The conversation between Rubin and Todd also touches on various topics related to OTS and its implementation. Rubin expresses confusion about how OTS can support RBF for updating to larger commitments and still be correct without having an epoch-based re-committing scheme. He suggests that OTS may not be formally correct and has some holes in what is committed to or relies on clients re-requesting proofs if they fail to be committed.Rubin recommends creating an actual spec for OTS for more meaningful discussions. Rubin and Todd also discuss the concept of "pinning attacks" in relation to blockchain transactions. Rubin argues that pinned transactions prevent progress, while Todd asserts that using such terminology is misleading in the blockchain environment. They also debate the definition of progress and the need for clarity in technical discussions.The conversation further explores topics such as fee accounts, CPFP in offchain transactions, and the design of OTS. There are discussions on the explicit tagging of fee accounts, the use of CPFP in complicated offchain transactions, and the lack of output chain in OTS. The importance of having a proper specification for protocols like OTS is highlighted, along with the need for clarity in technical discussions to avoid confusion among readers.Overall, the email thread covers a range of topics related to blockchain schemes, timestamping services, fee accounts, and the design of OTS. The authors engage in a thoughtful discussion, sharing their perspectives and raising important questions about the reliability and correctness of these systems.A recent email exchange between Bitcoin developers Jeremy Rubin and Peter Todd discussed a new type of attack on Bitcoin transactions known as "pinning". The term "pinning" refers to sequences of transactions that hinder progress in terms of computation. Rubin suggested calling this new attack "necromancing", which involves bringing back old versions of a transaction that would otherwise be irrational. However, Todd pointed out that this name is not accurate for all use cases.They specifically discussed the use case of OpenTimestamps calendars, which use RBF to update timestamp transactions with a new merkle tip hash once per block. In high fee situations, older versions of the same transaction getting mined wastes money and delays settlement. The conversation also touched on the potential for third-party attackers to mess up OTS calendars by delaying the mining of timestamp transactions. Todd clarified that a third party can only accelerate the mining of timestamp transactions, not delay them. He also mentioned that there are already services that allow similar attacks using out-of-band transaction fees, but they are either scams or very expensive.Another topic discussed in the email exchange was the improvement of Bitcoin's fee paying system. Rubin proposed establishing an account system as an extension block to simplify fee bumping and support long-lived smart contracts. However, Todd raised concerns about the introduction of transaction pinning attacks by allowing arbitrary fees to be attached to any transaction without permission. He suggested that transactions should designate a pubkey allowed to add further transaction fees if required, which Bitcoin already has in the form of Replace-by-Fee and Child Pays for Parent.The conversation expanded further to include other proposals related to cleaning up the fee paying semantics in Bitcoin. One proposal involved the use of sponsor transactions or fee accounts to separate the pays-for from the participates-in concerns, making it easier to compute effective feerates for transactions. Another proposal introduced an account system as an extension block, allowing for the storage of deposits in a separate UTXO database. These fee accounts could sign transactions with fee amounts and TXIDs or withdraw amounts, fees, and addresses.Overall, the email exchange discussed various aspects of pinning attacks, fee paying semantics, and potential improvements to the Bitcoin protocol. The developers explored different ideas and considerations related to these topics, highlighting the need for secure and efficient transaction processing in the Bitcoin system.In the context provided, there is a discussion about a design for descendant transactions that could be implemented without a fork. The proposed design involves creating a federated network that incentivizes miners through bribes, possibly even after a block has been formed. The idea behind this design is to ensure that descendant transactions are carried out in a specific way. By implementing a federated network, various parties can collaborate and enforce the desired transaction structure. This approach eliminates the need for a fork, which can be a complex and disruptive process.One interesting aspect of this design is the use of bribes to incentivize miners.
Updated on: 2023-08-01T00:00:16.775247+00:00