Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxWYH-00083g-OA for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 08:19:01 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.177 as permitted sender) client-ip=209.85.213.177; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f177.google.com; Received: from mail-ig0-f177.google.com ([209.85.213.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxWYD-0002oK-Lg for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 08:19:01 +0000 Received: by igbpi8 with SMTP id pi8so78674304igb.1 for ; Wed, 27 May 2015 01:18:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.76.195 with SMTP id zf3mr1915507icb.62.1432714732431; Wed, 27 May 2015 01:18:52 -0700 (PDT) Received: by 10.107.147.213 with HTTP; Wed, 27 May 2015 01:18:52 -0700 (PDT) In-Reply-To: <20150527074713.GB22286@savin.petertodd.org> References: <20150527074713.GB22286@savin.petertodd.org> Date: Wed, 27 May 2015 08:18:52 +0000 Message-ID: From: Gregory Maxwell To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 X-Headers-End: 1YxWYD-0002oK-Lg Cc: Bitcoin Development 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 08:19:01 -0000 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.