---------- Forwarded message ---------- From: "Jorge Timón" <jti...@jtimon.cc> Date: Jun 17, 2015 6:59 PM Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions To: "Rusty Russell" <ru...@rustcorp.com.au> Cc:
On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Jorge Timón <jti...@jtimon.cc> writes: >> On Jun 15, 2015 11:43 PM, "Rusty Russell" <ru...@rustcorp.com.au> wrote: >> >>> Though Peter Todd's more general best-effort language might make more >>> sense. It's not like you can hide an OP_RETURN transaction to make it >>> look like something else, so that transaction not going to be >>> distinguished by non-canonical ordering. >> >> What about commitments that don't use op_return (ie pay2contract >> commitments)? > > I have no idea what they are? :) Here's a short explanation and the code: https://github.com/Blockstream/contracthashtool Here's a longer explanation with a concrete use case (the contract is the invoice): https://www.youtube.com/watch?v=qwyALGlG33Q > Yes, my plan B would be an informational bip with simple code, > suggesting a way to permute a transaction based on some secret. No > point everyone reinventing the wheel, badly. Great. Well, then all I'm saying is that I like this as plan A.
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
