Published on: 2013-11-04T11:59:25+00:00
In a discussion about Bitcoin transaction replacement, Adam Back suggests that keeping everything the same except for the amount going to one address would simplify and strengthen transactions. However, he acknowledges that this method may compromise privacy. He also points out that change addresses do not provide much privacy based on network analysis. Back believes that more robust solutions are needed to address privacy concerns, in addition to revising fees.It is worth noting that transaction replacement has uses beyond modifying fees. However, changing the value of a designated change address after the fact could potentially enable a zeroconf attack, making it incompatible with current zero-conf-using implementations. Despite this, the code for implementing replacement is already simple and does not require further simplification. It is important to mention that transaction relaying rules are not part of consensus.In an email exchange between Bitcoin developers, Adam Back suggests that keeping everything the same except for one address receiving a different amount might enhance security. While this approach may compromise privacy, Back argues that it is worth considering to simplify and facilitate transaction validation. In response, Peter Todd suggests that instead of focusing on revising fees or undermining the 0-conf feature, more robust privacy fixes should be independently developed. Todd also proposes that replace-for-fee could prepare infrastructure for future replace-by-fee usage while avoiding debates around zero-conf transactions. The conversation also touches on the imperfect nature of estimates and the importance of backups.In another email exchange from 2013, John Dillon and Peter Todd discuss the limitations of Bitcoin estimates and the significance of backups. Todd presents his work on replace-for-fee, which allows for infrastructure preparation for potential replace-by-fee usage without getting involved in the politics surrounding zero-conf transactions. The rules for replacement are straightforward: each output in the old transaction must have a corresponding output in the new transaction with the same scriptPubKey and equal or greater value, and all old transaction outputs must be unspent. However, Todd highlights a flaw in Bitcoin wallet code where a transaction with double-spent inputs permanently blocks those inputs from being spent. Although this occurrence is rare, any CoinJoin implementation violates that assumption and could cause issues. Todd suggests that wallets should recognize when a transaction's inputs no longer exist and mark remaining inputs as unspent.
Updated on: 2023-08-01T06:23:37.836408+00:00