[Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Rusty Russell
rusty at rustcorp.com.au
Tue Jun 16 08:06:38 UTC 2015
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.
More information about the bitcoin-dev
mailing list