Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
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)? 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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06 Abstract This BIP provides a canonical ordering of inputs and outputs when creating transactions. Motivation Most bitcoin wallet implementations randomize the outputs of transactions they create to avoid trivial linkage analysis (especially change outputs), however implementations have made mistakes in this area in the past. Using a canonical ordering has the same effect, but is simpler, more obvious if incorrect, and can eventually be enforced by IsStandard() and even a soft-fork to enforce it. Specification Inputs should be ordered like so: index (lower value first) txid (little endian order, lower byte first) Outputs should be ordered like so: amount (lower value first) script (starting from first byte, lower byte first, shorter wins) Rationale Any single wallet is already free to implement this, but if other wallets do not it would reduce privacy by making those transactions stand out. Thus a BIP is appropriate, especially if this were to become an IsStandard() rule once widely adopted. Because integers are fast to compare, they're sorted first, before the lexographical ordering. The other input fields do not influence the sort order, as any valid transactions cannot have two inputs with the same index and txid. Reference Implementation https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering Sorry I wasn't a part of the IRC conversation where this was first discussed, though I'm very happy to see a concrete implementation along with the proposal. I'm not a great fan of this proposal for two reasons: The first is that the strict ordering requirements is incompatible with future soft-forks that may expose additional ordering constraints. Today we have _SINGLE, which as noted this interacts with poorly, but there have been other constraints proposed that this would also interact with poorly. The second is that even absent consensus rules there may be invisible constraints in systems-- e.g. hardware wallets that sign top down, or future transaction covenants that have constraints about ordering, or proof systems that use (yuck) midstate compression for efficiency. Right now, with random ordering these applications are fairly indistinguishable from other random uses (since their imposed order could come about by chance) but if everyone else was ordered, even if wasn't enforced.. these would be highly distinguishable. Which would be unfortunate. Worse, if most transactions are ordered the few that aren't could be mishandled (which is, I assume, part of why you propose requiring the ordering-- but I think the soft fork constraints there hurt it more). [Sorry for the delay in stating my views here; I wanted to talk them over with a few other people to see if I was just being stupid and misunderstanding the proposal] I think perhaps the motivations here are understated. We have not seen any massive deployments of accidentally broken ordering that I'm aware of-- and an implementation that got this wrong in a harmful way would likely make far more fatal mistakes (e.g. non random private keys). As an alternative to this proposal the ordering can be privately derandomized in the same way DSA is, to avoid the need for an actual number source. If getting the randomness right were really the only motivation, I'd suggest we propose a simple derandomized randomization algorithm--- e.g. take the order from (H(input ids||client secret)). I think there is actually an unstated motivation also driving this (and the other) proposal related to collaborative transaction systems like coinjoins or micropayment channels; where multiple clients need to agree on the same ordering. Is this the case? If so we should probably talk through some of the requirements there and see if there isn't a better way to address it. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe danny.tho...@gmail.com wrote: Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is significant. Is it your opinion that its fine if the result is that it makes the usage trivially distinguishable e.g. where it might be subjected to higher tx fees, or might break some software which incorrectly expects all transactions to be ordered since most are? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote: FWIW, The Open Assets colored coin protocol (CoinPrism) places special significance on the zeroth input and the position of the OP_RETURN colored coin marker output to distinguish colored coin issuance outputs from transfer outputs. Reordering the inputs or the outputs breaks the colored coin representation. Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is significant. Timestamping is another case where order matters: if you put the digest in the last vout you can use SHA256 midstate's to reduce the size of the timestamp proof. Anyway, there's no reason to rush re: changes to IsStandard() -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Mark Friedenbach m...@friedenbach.org writes: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... Ah, I forgot about that particular wart. Yech. Implies that you can order inputs or outputs, not both. Something like outputs must be in order, inputs which do not CHECK(MULTI)SIG_(VERIFY) a SIGHASH_SINGLE sig must be in order with respect to each other. But that's much less trivial since it implies script evaluation. In other news, I noticed Kristov Atlas's concurrent proposal just after I posted this (via reddit). He used far more words, but didn't note this issue either AFAICT. Thanks! Rusty. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Certainly, but I would drop discussion of IsStandard or consensus rules. On Jun 6, 2015 1:24 AM, Wladimir J. van der Laan laa...@gmail.com wrote: On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... On Jun 5, 2015 9:43 PM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06 Abstract This BIP provides a canonical ordering of inputs and outputs when creating transactions. Motivation Most bitcoin wallet implementations randomize the outputs of transactions they create to avoid trivial linkage analysis (especially change outputs), however implementations have made mistakes in this area in the past. Using a canonical ordering has the same effect, but is simpler, more obvious if incorrect, and can eventually be enforced by IsStandard() and even a soft-fork to enforce it. Specification Inputs should be ordered like so: index (lower value first) txid (little endian order, lower byte first) Outputs should be ordered like so: amount (lower value first) script (starting from first byte, lower byte first, shorter wins) Rationale Any single wallet is already free to implement this, but if other wallets do not it would reduce privacy by making those transactions stand out. Thus a BIP is appropriate, especially if this were to become an IsStandard() rule once widely adopted. Because integers are fast to compare, they're sorted first, before the lexographical ordering. The other input fields do not influence the sort order, as any valid transactions cannot have two inputs with the same index and txid. Reference Implementation https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
