path: root/0f/c0c05d6e2778fd78e1ae38b4c200ae127a6501

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 <adam@cypherspace.org>) id 1Yzlyd-0000k9-Dz
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 13:11:31 +0000
X-ACL-Warn: 
Received: from mout.perfora.net ([74.208.4.196])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Yzlyb-00082E-Pv
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 13:11:31 +0000
Received: from mail-qg0-f47.google.com ([209.85.192.47]) by mrelay.perfora.net
	(mreueus001) with ESMTPSA (Nemesis) id 0MWRTQ-1YcAGf3lBi-00Xazz for
	<bitcoin-development@lists.sourceforge.net>;
	Tue, 02 Jun 2015 15:11:24 +0200
Received: by qgf2 with SMTP id 2so58405273qgf.3
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 02 Jun 2015 06:11:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.238.8 with SMTP id j8mr29922398qhc.78.1433250683307;
	Tue, 02 Jun 2015 06:11:23 -0700 (PDT)
Received: by 10.96.112.164 with HTTP; Tue, 2 Jun 2015 06:11:23 -0700 (PDT)
In-Reply-To: <E67A3D18-EFB0-4156-98B7-082793D2D871@gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
	<CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
	<CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com>
	<E67A3D18-EFB0-4156-98B7-082793D2D871@gmail.com>
Date: Tue, 2 Jun 2015 14:11:23 +0100
Message-ID: <CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Stephen <stephencalebmorse@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:BEpBHuL2YRWJCUN8RWBZB7pE6/UY8QDxz6VKJ47EFubGbOnCtXl
	CdS/Ll6+fPYwJ4aNj5V8YvJ9b1BW2OHimhZWWzMoGfURmO28KD4GCc3EhjdOc3EHU3dsoAc
	Lnvq/AeCn/5OsZ8UCtypVYyfB25z1/hjP6zTubinW5bICReOOS6N+XH7N4sKvDc/enUgEbO
	iFpqajxJC3WoLVZA3HwzA==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [74.208.4.196 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
X-Headers-End: 1Yzlyb-00082E-Pv
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced
 transaction replacement signalled via sequence numbers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 13:11:31 -0000

That would also introduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time.  That is
not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.

(Not a huge flexibility loss as you can implement "not after" by
making it the previous holders responsibility to spend a "not before"
back to themselves.)

Adam

On 2 June 2015 at 13:52, Stephen <stephencalebmorse@gmail.com> wrote:
> Do you think it would be useful to have an inverted version of both CSV and
> CLTV? To verify if an output is spent before a specific time. CLTV and CSV
> could be implemented by taking two stack arguments, an integer for the
> comparison and TRUE/FALSE.
>
> Now that I think about this more, the problem is that, for example, just
> having a lock time of less than some value doesn't actually mean it has to
> be spent before that script value, so this might not work. Likely any
> implementations of such a feature would have to provide the script execution
> environment with access to information that it doesn't have now, which is
> what we are trying to avoid.
>
> Best,
> Stephen
>
>
>
> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org> wrote:
>
> You are correct! I am maintaining a 'checksequenceverify' branch in my git
> repository as well, an OP_RCLTV using sequence numbers:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
> Most of the interesting use cases for relative lock-time require an RCLTV
> opcode. What is interesting about this architecture is that it possible to
> cleanly separate the relative lock-time (sequence numbers) from the RCLTV
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
> CLTV, the CSV opcode only checks transaction data and requires no contextual
> knowledge about block headers, a weakness of the other RCLTV proposals that
> violate the clean separation between libscript and libconsensus. In a
> similar way, this BIP proposal only touches the transaction validation logic
> without any impact to script.
>
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
> opcode and its enabling applications. But, well, one thing at a time.
>
> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse@gmail.com>
> wrote:
>>
>> Hi Mark,
>>
>> Overall, I like this idea in every way except for one: unless I am missing
>> something, we may still need an OP_RCLTV even with this being implemented.
>>
>> In use cases such as micropayment channels where the funds are locked up
>> by multiple parties, the enforcement of the relative locktime can be done by
>> the first-signing party. So, while your solution would probably work in
>> cases like this, where multiple signing parties are involved, there may be
>> other, seen or unforeseen, use cases that require putting the relative
>> locktime right into the spending contract (the scriptPubKey itself). When
>> there is only one signer, there's nothing that enforces using an nSequence
>> and nVersion=2 that would prevent spending the output until a certain time.
>>
>> I hope this is received as constructive criticism, I do think this is an
>> innovative idea. In my view, though, it seems to be less fully-featured than
>> just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously
>> that it saves transaction space by repurposing unused space, and would
>> likely work for most cases where an OP_RCLTV would be needed.
>>
>> Best,
>> Stephen
>>
>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark@friedenbach.org>
>> wrote:
>>>
>>> I have written a reference implementation and BIP draft for a soft-fork
>>> change to the consensus-enforced behaviour of sequence numbers for the
>>> purpose of supporting transaction replacement via per-input relative
>>> lock-times. This proposal was previously discussed on the mailing list in
>>> the following thread:
>>>
>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>>
>>> In short summary, this proposal seeks to enable safe transaction
>>> replacement by re-purposing the nSequence field of a transaction input to be
>>> a consensus-enforced relative lock-time.
>>>
>>> The advantages of this approach is that it makes use of the full range of
>>> the 32-bit sequence number which until now has rarely been used for anything
>>> other than a boolean control over absolute nLockTime, and it does so in a
>>> way that is semantically compatible with the originally envisioned use of
>>> sequence numbers for fast mempool transaction replacement.
>>>
>>> The disadvantages are that external constraints often prevent the full
>>> range of sequence numbers from being used when interpreted as a relative
>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>>> use in other contexts. The latter point has been partially addressed by
>>> having the relative lock-time semantics be enforced only if the
>>> most-significant bit of nSequence is set. This preserves 31 bits for
>>> alternative use when relative lock-times are not required.
>>>
>>> The BIP draft can be found at the following gist:
>>>
>>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>>
>>> The reference implementation is available at the following git
>>> repository:
>>>
>>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>>
>>> I request that the BIP editor please assign a BIP number for this work.
>>>
>>> Sincerely,
>>> Mark Friedenbach
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>