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

[Rusty Russell]

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? :)

> In any case, if the motivation is ordering in multi-party transactions
> there should be ways to do it without any consequences for other
> transaction types' privacy. For example you could have a deterministic
> method that depends on a random seed all parties in the transaction
> previously share. That way the ordering is deterministic for all parties
> involved in the transaction (which can use whatever channel they're using
> to send the parts to also send this random seed) while at the same time the
> order looks random (or at least not cannonical in a recognisable way) to
> everyone else.

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.

Cheers,
Rusty.