Jorge Timón writes:
> On Jun 15, 2015 11:43 PM, "Rusty Russell" 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
>> distingui
On Jun 15, 2015 11:43 PM, "Rusty Russell" 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 orderi
Mark Friedenbach writes:
> There's another important use case which you mentioned Greg, that also
> requires special exemption: compact commitments via mid-state compression.
>
> The use case is an OP_RETURN output sorted last, whose last N bytes are a
> commitment of some kind. A proof of the com
On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell wrote:
> 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 th
There's another important use case which you mentioned Greg, that also
requires special exemption: compact commitments via mid-state compression.
The use case is an OP_RETURN output sorted last, whose last N bytes are a
commitment of some kind. A proof of the commitment can then use mid state
comp
On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell wrote:
> The softfork argument I find the most compelling, though it's tempting
> to argue that every ordering use (including SIGHASH_SINGLE) is likely
> a mistake.
Oh.
Hm.
It is the case that the generalized sighash flag design I was thinking
abou
Gregory Maxwell writes:
> 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 the
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe 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
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell
> Discussions-To: "Bitcoin Dev"
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs wh
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 outpu
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 repre
Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan" 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 amo
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 us
Mark Friedenbach 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
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" wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell
> Discussion
Title: Canonical Input and Output Ordering
Author: Rusty Russell
Discussions-To: "Bitcoin Dev"
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 implementatio
16 matches
Mail list logo
