Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Mark Friedenbach via bitcoin-dev writes: > Eric, that would be, I think, my sequencenumbers2 branch in which nSequence > is an explicit relative lock-time field (unless the most significant bit is > set). That has absolutely clear semantics. You should comment on #6312 > where this is being discus

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

How many years of relative lock time do we need? It really depends why we need a relative lock time in the first place, what what does it offer in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the confirmation taking too long, CLTV may expire before the tx is confirmed. For use

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Eric, that would be, I think, my sequencenumbers2 branch in which nSequence is an explicit relative lock-time field (unless the most significant bit is set). That has absolutely clear semantics. You should comment on #6312 where this is being discussed. On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombro

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I'd rather replace the whole nSequence thing with an explicit relative locktime with clear semantics...but I'm not going to fight this one too much. On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev wrote: >Where do we stand now on which sequencenumbers variation to use? We >really

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Where do we stand now on which sequencenumbers variation to use? We really should make a decision now. On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So I've created 2 new repositories with changed rules regarding > sequencenum

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

jl2...@xbt.hk writes: > Rusty Russell 於 2015-08-26 23:08 寫到: >> - We should immediately deploy an IsStandard() rule which insists that >> nSequence is 0x or 0, so nobody screws themselves when we >> soft fork and they had random junk in there. > > This is not needed because BIP68 is not

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

So I've created 2 new repositories with changed rules regarding sequencenumbers: https://github.com/maaku/bitcoin/tree/sequencenumbers2 This repository inverts (un-inverts?) the sequence number. nSequence=1 means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1 second relative l

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Rusty Russell 於 2015-08-26 23:08 寫到: - We should immediately deploy an IsStandard() rule which insists that nSequence is 0x or 0, so nobody screws themselves when we soft fork and they had random junk in there. This is not needed because BIP68 is not active for version 1 tx. No exi

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Thu, Aug 27, 2015 at 12:38:42PM +0930, Rusty Russell via bitcoin-dev wrote: > So I'd like an IsStandard() rule to say it nLockTime be 0 if an > nSequence != 0x. Would that screw anyone currently? That sentence doesn't quite parse ("say it nLockTime"), so please forgive me if I'm misunde

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Btc Drak via bitcoin-dev writes: > This BIP has been assigned BIP112 by the BIP repository maintainer. I > have updated the pull request accordingly. > > Regarding the suggestion to cannibalise version, by your own > disadvantage list, we would lose fine grained control over txins which > neuters

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Assuming a maximum of 1-year relative lock-times. But what is an > appropriate maximum to choose? The use cases I have considered have only > had lock times on the order of a few da

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

To follow up on this, let's say that you want to be able to have up to 1 year relative lock-times. This choice is somewhat arbitrary and what I would like some input on, but I'll come back to this point. * 1 bit is necessary to enable/disable relative lock-time. * 1 bit is necessary to indicate

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained control over txins which neuters the usefulness considerably. Also using versi

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Your proposal also permanently burns a sequence bit. It depends on how we value a nSequence bit and a nVersion bit. I think there is a trade-off here: 1. nSequence is signed by each TxIn individually, while all TxIns must share the same nVersion 2. If nVersion is used to indicate the meaning

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Sorry this was meant for the list: There are only 32 bits in the version field. If you're going to spend a bit for perpetuity to indicate whether or not a feature is active, you'd better have a good reason to make that feature optional. I haven't seen a compelling use case for having BIP 68 be op

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, high

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

A power of 2 would be far more efficient here. The key question is how long of a relative block time do you need? Figure out what the maximum should be ( I don't know what that would be, any ideas?) and then see how many bits you have left over. On Aug 23, 2015 7:23 PM, "Jorge Timón" < bitcoin-dev@

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev wrote: > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the > discussion has any thought been given to represent one block with more > than one increment? This would leave additional space for future > signaling, or al

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev wrote: > ack no inversion. This can actually allow more direct preservation of > existing semantics. > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html I can't follow this logic. Can you help? The existin

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote: > I am indifferent on this issue (the bit inversion), but so far on

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Wed, Aug 19, 2015 at 02:27:10PM -0700, Joseph Poon via bitcoin-dev wrote: > On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev > wrote: > > If anyone feels strongly about this, please speak up. > > > > On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n < > > bitcoin-dev@list

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Wed, Aug 19, 2015 at 11:27 PM, Joseph Poon wrote: > On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev > wrote: >> If anyone feels strongly about this, please speak up. >> >> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n < >> bitcoin-dev@lists.linuxfoundation.org> wrote

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote: > If anyone feels strongly about this, please speak up. > > On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > I repeated my nit on https://github.com/bitcoin/bips

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I am indifferent on this issue (the bit inversion), but so far only Jorge has spoken up. I opted for this detail during implementation in order to preserve existing semantics, even if those semantics are not commonly used. This was the conservative choice, driven in part because I didn't want the p

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I repeated my nit on https://github.com/bitcoin/bips/pull/179 On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev wrote: > Please note there is now a PR for this BIP[1] and also a pull request for > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. > > [1] https://github.com/bitcoin/bips/

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Please note there is now a PR for this BIP[1] and also a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. [1] https://github.com/bitcoin/bips/pull/179 [2] https://github.com/bitcoin/bitcoin/pull/6564 ___ bitcoin-dev mailing list bitcoi

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I extremely dislike the inversion to preserve the "previous nSequence semantics". The "previous nSequence semantics" were consensus-unenforceable but we can cover the same use cases (or the realistic ones at least) with nMaturity. Let's face it and move on without technical debt we don't need and m

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

With the assumed malleability-fix CHECKSIG2 version of lightning, watching for and responding to bad behavior is fully outsourceable. You can synchronize channel state (signed refund transactions) with a third party that watches for replay of old transactions on the mainnet, and starts the refund p

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote: > On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev > > wrote: > > I haven't tested the details of this, but is there another bit available > for use in the future for the

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't tested the details of this, but is there another bit available > for use in the future for the relative blockheight? > > I strongly believe that Lightning needs mitigations for

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Very cool! This will certainly help make Lightning Network testable on the main-chain and permit channels to remain open indefinitely. I'm looking forward to it. On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote: > // Note that unlike CHECKLOCKTIMEVERIFY we do not ne

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Thu, Aug 13, 2015 at 6:12 PM, Mark Friedenbach wrote: > As per the rules of BIP 1, I hereby request that the BIP editor please > assign an official number to this work. The idea has been discussed before > on the bitcoin-dev mailing list: > > http://lists.linuxfoundation.org/pipermail/bitcoin-d

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

As per the rules of BIP 1, I hereby request that the BIP editor please assign an official number to this work. The idea has been discussed before on the bitcoin-dev mailing list: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html And a reference implementation is availab

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak)

On August 13, 2015 7:34:03 PM GMT+03:00, Nicolas Dorier via bitcoin-dev wrote: >Would be wonderful to have this pushed together with CLTV and BIP68. >If BIP68 get pushed in the next fork, this CSV is a no brainer. > >Was there a competing RCLTV implementation somewhere that did not >depend on >

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak)

Would be wonderful to have this pushed together with CLTV and BIP68. If BIP68 get pushed in the next fork, this CSV is a no brainer. Was there a competing RCLTV implementation somewhere that did not depend on BIP68 for information ? I don't manage to find it. __

[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I have written the following draft BIP for a new opcode CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of relative-locktime to Bitcoin's scripting language. https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki BIP: XX Title: CHECKSEQUENCEVERIFY A