On 5/26/2015 12:10 PM, Gregory Maxwell wrote: > On Tue, May 26, 2015 at 5:54 PM, Tom Harding <t...@thinlink.com> wrote: >> It's not difficult to >> imagine real-world consequences to not having contributed to the >> transaction. > I'm having a hard time. Can you help me understand a specific case > where this makes a difference. >
The bitcoin transaction is part of a real-world "deal" with unknown connections to the other parts. New inputs combined with new or increased outputs can be thought of as a second deal sharing the same envelope. That's not the case if paying parties are kicked out of the deal, and possibly don't learn about it right away. A subset of parties to an Armory simulfunding transaction (an actual multi-input use case) could replace one signer's input after they broadcast it. Whether that's a problem depends on real-world connections. Maybe the receiver cares where he is paid from or is basing a subsequent decision on it. Maybe a new output is being added, whose presence makes the transaction less likely to be confirmed quickly, with that speed affecting the business. With Kalle's Proof of Payment proposed standard, one payer in a two-input transaction could decide to boot the other, and claim the concert tickets all for himself. The fact that he pays is not the only consideration in the real world -- what if these are the last 2 tickets? Mempool policy shouldn't help one payer make a unilateral decision to become the sole party to a deal after various parties have seen it broadcast. > The inherent malleability of signatures makes it unreliable to depend > on the signature content of a transaction until its good and buried, > regardless. I'd argue that changing how an input is signed doesn't change the deal. For example if a different 2 of 3 multisig participants sign, those 3 people gave up that level of control when they created the multisig. Replacement is new - we have a choice what kind of warnings we need to give to signers of multi-input transactions. IMHO we should avoid needing a stronger warning than is already needed for 0-conf. ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
