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

Jorge Timón jtimon at jtimon.cc
Sun Jun 21 07:27:33 UTC 2015


---------- Forwarded message ----------
From: "Jorge Timón" <jtimon at 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 at rustcorp.com.au>
Cc:

On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Jorge Timón <jtimon at jtimon.cc> writes:
>> On Jun 15, 2015 11:43 PM, "Rusty Russell" <rusty at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/d20ce7e1/attachment.html>


More information about the bitcoin-dev mailing list