Subject: [Bitcoin-development] Fwd: Re: [RFC] Canonical input and output ordering in transactions

From: Jorge Timón <[email-masked]>
Date: Sun, 21 Jun 2015 09:27:33 +0200

---------- Forwarded message ----------
From: "Jorge Timón" <[email-masked]>
Date: Jun 17, 2015 6:59 PM
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output
ordering in transactions
To: "Rusty Russell" <[email-masked]>
Cc:

On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <[email-masked]>
wrote:
> Jorge Timón <[email-masked]> writes:
>> On Jun 15, 2015 11:43 PM, "Rusty Russell" <[email-masked]> 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.