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

2015-06-16 Thread Jorge Timón
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

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

2015-06-14 Thread Gregory Maxwell
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

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

2015-06-14 Thread Gregory Maxwell
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

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

2015-06-08 Thread Peter Todd
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.

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

2015-06-06 Thread Rusty Russell
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

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

2015-06-06 Thread Wladimir J. van der Laan
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

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

2015-06-06 Thread Mark Friedenbach
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

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

2015-06-05 Thread Mark Friedenbach
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

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

2015-06-05 Thread Rusty Russell
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