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

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

---------- Forwarded message ----------
From: "Jorge Timón" <jtimon@jtimon.cc>
Date: Jun 17, 2015 6:59 PM
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output
ordering in transactions
To: "Rusty Russell" <rusty@rustcorp.com.au>
Cc:

On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <rusty@rustcorp.com.au>
wrote:
> Jorge Timón <jtimon@jtimon.cc> writes:
>> On Jun 15, 2015 11:43 PM, "Rusty Russell" <rusty@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.

[-- Attachment #2: Type: text/html, Size: 2002 bytes --]