[Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
On Mon, Oct 28, 2013 at 07:17:50AM +, John Dillon wrote: This discussion seems to be a lot of hot air over a simple observation that estimates are imperfect and always will be. I do not understand you vehement opposition the notion that a backup is a good thing except in the context that replacement to change fees is halfway to profit-seeking replacement by fee. Peter Todd: You did a fair bit of leg work for replace-by-fee. Seems to me that replace-for-fee will help prep infrastructure to eventual replace-by-fee usage, while avoiding some of the politics around zero-conf transactions. Here's the easy part done: https://github.com/petertodd/bitcoin/tree/replace-for-fee The rules are pretty simple: a replacement can only happen if every output in the old transaction has a corresponding output in the new with the same scriptPubKey, and of equal or greater value. All old tx outputs must also be unspent. For implementation reasons, the order of the outputs must also be the same, and the code will never replace two transactions with one. If someone wanted to mine with the above code, I'd say go right ahead. (modulo general testing concerns) Client-side though it shows a flaw with the Bitcoin wallet code that I should have realized months ago: essentially a transaction in your wallet with double-spent inputs forever blocks those inputs from being spent. This doesn't happen too often because you're wallet will currently never create double-spends, and will never respend unconfirmed coins from someone else, but any CoinJoin implementation violates that assumption and an attacker could easily cause a lot of havok. I'll have to think about the issue further, but essentially the wallet needs to recognize when a transaction's inputs no longer exist, and mark the remaining inputs as unspent. Actually deleting those transactions from your wallet is secondary to that more important concern. -- 'peter'[:-1]@petertodd.org 2fdfe6bbcffea72c934475cd4fcfe78d8d06910016d707c9b4a9e827 signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
Might leak less wiggle room and be simpler/more robut to validate that *everything* has to be the same except for the amount going to one (presumed change) address. A privacy leak I know, but dont do that - ie send enough change the first time. And network analysis has shown change addresses arent adding hardly any privacy. We need more robust privacy fixes independently. I do not support damaging the 0-conf feature, so I think this later approach is a better track for revising fees. Adam On Mon, Nov 04, 2013 at 05:52:43AM -0500, Peter Todd wrote: On Mon, Oct 28, 2013 at 07:17:50AM +, John Dillon wrote: This discussion seems to be a lot of hot air over a simple observation that estimates are imperfect and always will be. I do not understand you vehement opposition the notion that a backup is a good thing except in the context that replacement to change fees is halfway to profit-seeking replacement by fee. Peter Todd: You did a fair bit of leg work for replace-by-fee. Seems to me that replace-for-fee will help prep infrastructure to eventual replace-by-fee usage, while avoiding some of the politics around zero-conf transactions. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
On Mon, Nov 04, 2013 at 12:10:38PM +0100, Adam Back wrote: Might leak less wiggle room and be simpler/more robut to validate that *everything* has to be the same except for the amount going to one (presumed change) address. A privacy leak I know, but dont do that - ie send enough change the first time. And network analysis has shown change addresses arent adding hardly any privacy. We need more robust privacy fixes independently. I do not support damaging the 0-conf feature, so I think this later approach is a better track for revising fees. There's been a number of uses found for tx-replacement beyond simply modifying fees. In additition, allowing for the value of a specificly designated change address to be changed after the fact is not compatible with current zero-conf-using implementations; they don't know to treat a txout as special so allowing its value to be reduced would allow for a zeroconf attack. Anyway, if you look at the code that actually implements the replacement, it's extremely simple already. I see no reason to make it less general; transaction relaying rules are not part of consensus. -- 'peter'[:-1]@petertodd.org 000a6dd96c551eca7299463e4e523462798a006535f412b519c7 signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
