---------- 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>

On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <ru...@rustcorp.com.au>
> 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:


Here's a longer explanation with a concrete use case (the contract is
the invoice):


> 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

Reply via email to