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 +0000, 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=65839951&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
