Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxY8N-000873-9a for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:00:23 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.180 as permitted sender) client-ip=209.85.220.180; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f180.google.com; Received: from mail-qk0-f180.google.com ([209.85.220.180]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxY8M-0001HN-3i for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:00:23 +0000 Received: by qkhg32 with SMTP id g32so2347517qkh.0 for ; Wed, 27 May 2015 03:00:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.132.17 with SMTP id 17mr21530271qhe.36.1432720816708; Wed, 27 May 2015 03:00:16 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 27 May 2015 03:00:16 -0700 (PDT) In-Reply-To: References: <20150527074713.GB22286@savin.petertodd.org> Date: Wed, 27 May 2015 11:00:16 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Development Content-Type: multipart/alternative; boundary=001a11c07c7257a29305170d4fd1 X-Spam-Score: 3.3 (+++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1YxY8M-0001HN-3i Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 10:00:23 -0000 --001a11c07c7257a29305170d4fd1 Content-Type: text/plain; charset=UTF-8 This could cause legacy transactions to become unspendable. A new transaction version number should be used to indicate the change of the field from sequence number to relative lock time. Legacy transactions should not have the rule applied to them. On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell wrote: > On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > > Equally this proposal is no more "consensus enforcement" than simply > > increasing the fee (and possibly decreasing the absolute nLockTime) for > > You've misunderstood it, I think-- Functionally nlocktime but relative > to each txin's height. > > But the construction gives the sequence numbers a rational meaning, > they count down the earliest position a transaction can be included. > (e.g. the highest possible sequence number can be included any time > the inputs are included) the next lower sequence number can only be > included one block later than the input its assigned to is included, > the next lower one block beyond that. All consensus enforced. A > miner could opt to not include the higher sequence number (which is > the only one of the set which it _can_ include) it the hopes of > collecting more fees later on the next block, similar to how someone > could ignore an eligible locked transaction in the hopes that a future > double spend will be more profitable (and that it'll enjoy that > profit) but in both cases it must take nothing at all this block, and > risk being cut off by someone else (and, of course, nothing requires > users use sequence numbers only one apart...). > > It makes sequence numbers work exactly like you'd expect-- within the > bounds of whats possible in a decentralized system. At the same time, > all it is ... is relative nlocktime. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c07c7257a29305170d4fd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This could cause legacy transactions to become u= nspendable.


A new transaction version number should be use= d to indicate the change of the field from sequence number to relative lock= time.

Legacy transactions should not have the rule applied to= them.

O= n Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <gmaxwell@gmail.com&g= t; wrote:
On Wed,= May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> Equally this proposal is no more "consensus enforcement" tha= n simply
> increasing the fee (and possibly decreasing the absolute nLockTime) fo= r

You've misunderstood it, I think-- Functionally nlocktime but re= lative
to each txin's height.

But the construction gives the sequence numbers a rational meaning,
they count down the earliest position a transaction can be included.
(e.g. the highest possible sequence number can be included any time
the inputs are included) the next lower sequence number can only be
included one block later than the input its assigned to is included,
the next lower one block beyond that. All consensus enforced.=C2=A0 =C2=A0A=
miner could opt to not include the higher sequence number (which is
the only one of the set which it _can_ include) it the hopes of
collecting more fees later on the next block, similar to how someone
could ignore an eligible locked transaction in the hopes that a future
double spend will be more profitable (and that it'll enjoy that
profit) but in both cases it must take nothing at all this block, and
risk being cut off by someone else (and, of course, nothing requires
users use sequence numbers only one apart...).

It makes sequence numbers work exactly like you'd expect-- within the bounds of whats possible in a decentralized system.=C2=A0 At the same time,=
all it is ... is relative nlocktime.

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c07c7257a29305170d4fd1--