<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Note how transaction malleability can quickly sabotage naive notions of this idea.<br></blockquote><div><br></div><div>Bitcoin-United relies on a notion of transaction equivalence that doesn&#39;t involve the transaction hash at all, so it should be immune to malleability issues and compatible with segwit. </div><div><br></div><div>From the post, two transactions are equal if they &quot;consume the same inputs and result in the same outputs, not counting the miner fee. Simple pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward. Multikey transactions are evaluated for equivalency by their inputs and outputs, so it is allowable for a 2-out-of-3 payment to be signed by one set of two keys on Dum and another set of two keys on Dee, as long as the transaction consumes the same coins and produces the same outputs. Not that we&#39;ll ever encounter such a case, but making this point helps pedagogically with getting across the notion of transaction equivalence. What counts are the consumed inputs and the destination and amounts of the outputs.&quot;</div><div><br></div><div>But you&#39;re right, if a naive implementation were to just use the transaction hash, the result would be a mess.</div><div><br></div><div>- egs</div><div><br></div><div><br></div></div></div></div>