Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev wrote: > ... Gavin just told me about setmocktime. That's fast service! Once more functions (specially consensus-critical functions) take nTime explicitly as parameter instead of relying on the library-unfriendly GetAdjustedTime(), then SetMockTime() will be less necessary for testing. For example, see https://github.com/jtimon/bitcoin/commit/88a35548518a27c7d24efe064e1bf4e5b3029578#diff-524ba4b43aa70d393ef51ab42a6d25f2L52 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Rusty Russell via bitcoin-dev writes: >>From a practical perspective: yuck. There's currently no way to play > with bitcoind's perception of time, so that's a very long sleep to > blackbox test (which is what my lightning test script does). > > So consider this YA feature request :) ... Gavin just told me about setmocktime. That's fast service! Thanks, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Btc Drak writes: > Alex, > > I am sorry for not communicating more clearly. Mark and I discussed your > concerns from the last meeting and he made the change. The BIP text still > needs to be updated, but the discussed change was added to the PR, albeit > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK > and SEQUENCE_LOCKTIME_GRANULARITY in the PR > https://github.com/bitcoin/bitcoin/pull/6312. I like it from a technical perspective. >From a practical perspective: yuck. There's currently no way to play with bitcoind's perception of time, so that's a very long sleep to blackbox test (which is what my lightning test script does). So consider this YA feature request :) Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Adam, there is really no justification I can see to lower the interblock interval on the Bitcoin blockchain, primarily due to the effects of network latency. Lowering the interblock interval and raising the block size are not equal alternatives - you can always get more throughput in bitcoin by raising the block size than by lowering the interblock time. And that's without considering the effect shorter intervals would have on e.g. SPV client bandwidth or sidechain connectivity proofs. So I find it very unlikely that such granularity would ever be needed on the Bitcoin block chain, although if were to happen then extra bits from nSequence could be used in a soft-fork compatible way. However it is true that various sidechains such as Liquid will have a much shorter interblock interval than 10min, as well as customer demand for protocols with shorter timeouts. It would be nice if such systems did not HAVE to resort to complex bit shifting to support more precision, and if protocols written for bitcoin could be reused on such systems with minimal or no modification. To that end, it might be preferable to move the flag bit indicating use of seconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22 to provide higher granularity in a sidechain environment. This keeps the size of a stack push to 3 bytes while also keeping sufficient room for high-order bits of relative lock-time in a sidechain that supports shorter block intervals. Another alternative is to put the units flag in the least significant bit, which has the advantage of allowing both units of lock-time to make use of 1-2 byte pushes, but the disadvantage of making lock times of 64..127 2-bytes instead of 1-byte. Thoughts? On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Does that pre-judge that block interval would never change from > 10mins? Eg say with IBLT or fountain codes etc and security arguments > for the current limitations of them are found, such that orphan rates > can remain low in a decentralised way with 1min blocks, then the > locktime granularity would be coarse relative to the block interval > (with 512s locktime granularity. > > Adam > > On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev > wrote: > > Alex, > > > > I am sorry for not communicating more clearly. Mark and I discussed your > > concerns from the last meeting and he made the change. The BIP text still > > needs to be updated, but the discussed change was added to the PR, albeit > > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits > with > > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and > > SEQUENCE_LOCKTIME_GRANULARITY in the PR > > https://github.com/bitcoin/bitcoin/pull/6312. > > > > /* If CTxIn::nSequence encodes a relative lock-time, this mask is > > * applied to extract that lock-time from the sequence field. */ > > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x; > > > > /* In order to use the same number of bits to encode roughly the > > * same wall-clock duration, and because blocks are naturally > > * limited to occur every 600s on average, the minimum granularity > > * for time-based relative lock-time is fixed at 512 seconds. > > * Converting from CTxIn::nSequence to seconds is performed by > > * multiplying by 512 = 2^9, or equivalently shifting up by > > * 9 bits. */ > > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; > > > > I am also much happier with this last tightening up of the specification > > because it removes ambiguity. 512s granularity makes sense within the > > context of the 10 minute block target. > > > > Thank you for spending so much time carefully considering this BIP and > > reference implementation and please let me know if there there are any > > remaining nits so we can get those addressed. > > > > > > > > > > > > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev > > wrote: > >> > >> Mark, > >> > >> You seemed interested in changing BIP 68 to use 16 bits for sequence > >> number in both the block and time versions, making time based sequence > >> numbers have a resolution of 512 seconds. > >> > >> I'm in favor of this approach because it leaves aside 14 bits for > further > >> soft forks within the semantics of BIP 68. > >> > >> It would be nice to know if you're planning this change, and perhaps > >> people can hold off on review until things are finalized. > >> > >> I'd cast my "vote" against BIP 68 without this change, but am also open > to > >> being convinced otherwise. > >> > >> What are other peoples opinions on this? > >> > >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev > >> wrote: > >>> > >>> Peter Todd writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev > >>> >> writes: > >>> >> > However I don't think we've done a good job showing why we need to >
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Adam, The remaining 14 bits can be used to soft fork in finer granularity in the future. Alex On Thu, Oct 15, 2015 at 12:37 PM, Adam Back wrote: > Does that pre-judge that block interval would never change from > 10mins? Eg say with IBLT or fountain codes etc and security arguments > for the current limitations of them are found, such that orphan rates > can remain low in a decentralised way with 1min blocks, then the > locktime granularity would be coarse relative to the block interval > (with 512s locktime granularity. > > Adam > > On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev > wrote: > > Alex, > > > > I am sorry for not communicating more clearly. Mark and I discussed your > > concerns from the last meeting and he made the change. The BIP text still > > needs to be updated, but the discussed change was added to the PR, albeit > > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits > with > > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and > > SEQUENCE_LOCKTIME_GRANULARITY in the PR > > https://github.com/bitcoin/bitcoin/pull/6312. > > > > /* If CTxIn::nSequence encodes a relative lock-time, this mask is > > * applied to extract that lock-time from the sequence field. */ > > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x; > > > > /* In order to use the same number of bits to encode roughly the > > * same wall-clock duration, and because blocks are naturally > > * limited to occur every 600s on average, the minimum granularity > > * for time-based relative lock-time is fixed at 512 seconds. > > * Converting from CTxIn::nSequence to seconds is performed by > > * multiplying by 512 = 2^9, or equivalently shifting up by > > * 9 bits. */ > > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; > > > > I am also much happier with this last tightening up of the specification > > because it removes ambiguity. 512s granularity makes sense within the > > context of the 10 minute block target. > > > > Thank you for spending so much time carefully considering this BIP and > > reference implementation and please let me know if there there are any > > remaining nits so we can get those addressed. > > > > > > > > > > > > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev > > wrote: > >> > >> Mark, > >> > >> You seemed interested in changing BIP 68 to use 16 bits for sequence > >> number in both the block and time versions, making time based sequence > >> numbers have a resolution of 512 seconds. > >> > >> I'm in favor of this approach because it leaves aside 14 bits for > further > >> soft forks within the semantics of BIP 68. > >> > >> It would be nice to know if you're planning this change, and perhaps > >> people can hold off on review until things are finalized. > >> > >> I'd cast my "vote" against BIP 68 without this change, but am also open > to > >> being convinced otherwise. > >> > >> What are other peoples opinions on this? > >> > >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev > >> wrote: > >>> > >>> Peter Todd writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev > >>> >> writes: > >>> >> > However I don't think we've done a good job showing why we need to > >>> >> > implement this feature via nSequence. > >>> >> > >>> >> It could be implemented in other ways, but nSequence is the neatest > >>> >> and > >>> >> most straightforward I've seen. > >>> >> > >>> >> - I'm not aware of any other (even vague) proposal for its use? > >>> >> Enlighten? > >>> > > >>> > There's three that immediately come to mind: > >>> > > >>> > Gregory Maxwell has proposed it as a way of discouraging miners from > >>> > reorging chains, by including some of the low-order bits of a > previous > >>> > block header in nSequence. > >>> > > >>> > A few people have proposed implementing proof-of-stake blocksize > voting > >>> > with nSequence. > >>> > >>> Excellent, thanks! It's good to have such ideas as a compass. PoS > >>> voting seems like it won't be a problem in 5 bits. > >>> > >>> The "prevbits" idea would want more bits; naively 64 would be good, but > >>> I think there are some tricks we can use to make 32 work OK. We would > >>> have to then split between nLocktime (if available) and multiple > >>> nSequence fields, and it would weaken it for some txs. > >>> > >>> There is one easy solution: change the BIP wording from: > >>> > >>> -For transactions with an nVersion of 2 or greater, > >>> +For transactions with an nVersion of 2, > >>> > >>> And on every tx bump, we decide whether to keep this scheme (mempool > >>> would enforce it always). > >>> > >>> Cheers, > >>> Rusty. > >>> ___ > >>> bitcoin-dev mailing list > >>> bitcoin-dev@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > >> > >> > >> __
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Does that pre-judge that block interval would never change from 10mins? Eg say with IBLT or fountain codes etc and security arguments for the current limitations of them are found, such that orphan rates can remain low in a decentralised way with 1min blocks, then the locktime granularity would be coarse relative to the block interval (with 512s locktime granularity. Adam On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev wrote: > Alex, > > I am sorry for not communicating more clearly. Mark and I discussed your > concerns from the last meeting and he made the change. The BIP text still > needs to be updated, but the discussed change was added to the PR, albeit > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and > SEQUENCE_LOCKTIME_GRANULARITY in the PR > https://github.com/bitcoin/bitcoin/pull/6312. > > /* If CTxIn::nSequence encodes a relative lock-time, this mask is > * applied to extract that lock-time from the sequence field. */ > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x; > > /* In order to use the same number of bits to encode roughly the > * same wall-clock duration, and because blocks are naturally > * limited to occur every 600s on average, the minimum granularity > * for time-based relative lock-time is fixed at 512 seconds. > * Converting from CTxIn::nSequence to seconds is performed by > * multiplying by 512 = 2^9, or equivalently shifting up by > * 9 bits. */ > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; > > I am also much happier with this last tightening up of the specification > because it removes ambiguity. 512s granularity makes sense within the > context of the 10 minute block target. > > Thank you for spending so much time carefully considering this BIP and > reference implementation and please let me know if there there are any > remaining nits so we can get those addressed. > > > > > > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev > wrote: >> >> Mark, >> >> You seemed interested in changing BIP 68 to use 16 bits for sequence >> number in both the block and time versions, making time based sequence >> numbers have a resolution of 512 seconds. >> >> I'm in favor of this approach because it leaves aside 14 bits for further >> soft forks within the semantics of BIP 68. >> >> It would be nice to know if you're planning this change, and perhaps >> people can hold off on review until things are finalized. >> >> I'd cast my "vote" against BIP 68 without this change, but am also open to >> being convinced otherwise. >> >> What are other peoples opinions on this? >> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev >> wrote: >>> >>> Peter Todd writes: >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >>> >> Peter Todd via bitcoin-dev >>> >> writes: >>> >> > However I don't think we've done a good job showing why we need to >>> >> > implement this feature via nSequence. >>> >> >>> >> It could be implemented in other ways, but nSequence is the neatest >>> >> and >>> >> most straightforward I've seen. >>> >> >>> >> - I'm not aware of any other (even vague) proposal for its use? >>> >> Enlighten? >>> > >>> > There's three that immediately come to mind: >>> > >>> > Gregory Maxwell has proposed it as a way of discouraging miners from >>> > reorging chains, by including some of the low-order bits of a previous >>> > block header in nSequence. >>> > >>> > A few people have proposed implementing proof-of-stake blocksize voting >>> > with nSequence. >>> >>> Excellent, thanks! It's good to have such ideas as a compass. PoS >>> voting seems like it won't be a problem in 5 bits. >>> >>> The "prevbits" idea would want more bits; naively 64 would be good, but >>> I think there are some tricks we can use to make 32 work OK. We would >>> have to then split between nLocktime (if available) and multiple >>> nSequence fields, and it would weaken it for some txs. >>> >>> There is one easy solution: change the BIP wording from: >>> >>> -For transactions with an nVersion of 2 or greater, >>> +For transactions with an nVersion of 2, >>> >>> And on every tx bump, we decide whether to keep this scheme (mempool >>> would enforce it always). >>> >>> Cheers, >>> Rusty. >>> ___ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Alex, I am sorry for not communicating more clearly. Mark and I discussed your concerns from the last meeting and he made the change. The BIP text still needs to be updated, but the discussed change was added to the PR, albeit squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and SEQUENCE_LOCKTIME_GRANULARITY in the PR https://github.com/bitcoin/bitcoin/pull/6312. /* If CTxIn::nSequence encodes a relative lock-time, this mask is * applied to extract that lock-time from the sequence field. */ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x; /* In order to use the same number of bits to encode roughly the * same wall-clock duration, and because blocks are naturally * limited to occur every 600s on average, the minimum granularity * for time-based relative lock-time is fixed at 512 seconds. * Converting from CTxIn::nSequence to seconds is performed by * multiplying by 512 = 2^9, or equivalently shifting up by * 9 bits. */ static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; I am also much happier with this last tightening up of the specification because it removes ambiguity. 512s granularity makes sense within the context of the 10 minute block target. Thank you for spending so much time carefully considering this BIP and reference implementation and please let me know if there there are any remaining nits so we can get those addressed. On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Mark, > > You seemed interested in changing BIP 68 to use 16 bits for sequence > number in both the block and time versions, making time based sequence > numbers have a resolution of 512 seconds. > > I'm in favor of this approach because it leaves aside 14 bits for further > soft forks within the semantics of BIP 68. > > It would be nice to know if you're planning this change, and perhaps > people can hold off on review until things are finalized. > > I'd cast my "vote" against BIP 68 without this change, but am also open to > being convinced otherwise. > > What are other peoples opinions on this? > > On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Peter Todd writes: >> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >> >> Peter Todd via bitcoin-dev >> >> writes: >> >> > However I don't think we've done a good job showing why we need to >> >> > implement this feature via nSequence. >> >> >> >> It could be implemented in other ways, but nSequence is the neatest and >> >> most straightforward I've seen. >> >> >> >> - I'm not aware of any other (even vague) proposal for its use? >> Enlighten? >> > >> > There's three that immediately come to mind: >> > >> > Gregory Maxwell has proposed it as a way of discouraging miners from >> > reorging chains, by including some of the low-order bits of a previous >> > block header in nSequence. >> > >> > A few people have proposed implementing proof-of-stake blocksize voting >> > with nSequence. >> >> Excellent, thanks! It's good to have such ideas as a compass. PoS >> voting seems like it won't be a problem in 5 bits. >> >> The "prevbits" idea would want more bits; naively 64 would be good, but >> I think there are some tricks we can use to make 32 work OK. We would >> have to then split between nLocktime (if available) and multiple >> nSequence fields, and it would weaken it for some txs. >> >> There is one easy solution: change the BIP wording from: >> >> -For transactions with an nVersion of 2 or greater, >> +For transactions with an nVersion of 2, >> >> And on every tx bump, we decide whether to keep this scheme (mempool >> would enforce it always). >> >> Cheers, >> Rusty. >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Mark, You seemed interested in changing BIP 68 to use 16 bits for sequence number in both the block and time versions, making time based sequence numbers have a resolution of 512 seconds. I'm in favor of this approach because it leaves aside 14 bits for further soft forks within the semantics of BIP 68. It would be nice to know if you're planning this change, and perhaps people can hold off on review until things are finalized. I'd cast my "vote" against BIP 68 without this change, but am also open to being convinced otherwise. What are other peoples opinions on this? On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Peter Todd writes: > > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >> Peter Todd via bitcoin-dev > >> writes: > >> > However I don't think we've done a good job showing why we need to > >> > implement this feature via nSequence. > >> > >> It could be implemented in other ways, but nSequence is the neatest and > >> most straightforward I've seen. > >> > >> - I'm not aware of any other (even vague) proposal for its use? > Enlighten? > > > > There's three that immediately come to mind: > > > > Gregory Maxwell has proposed it as a way of discouraging miners from > > reorging chains, by including some of the low-order bits of a previous > > block header in nSequence. > > > > A few people have proposed implementing proof-of-stake blocksize voting > > with nSequence. > > Excellent, thanks! It's good to have such ideas as a compass. PoS > voting seems like it won't be a problem in 5 bits. > > The "prevbits" idea would want more bits; naively 64 would be good, but > I think there are some tricks we can use to make 32 work OK. We would > have to then split between nLocktime (if available) and multiple > nSequence fields, and it would weaken it for some txs. > > There is one easy solution: change the BIP wording from: > > -For transactions with an nVersion of 2 or greater, > +For transactions with an nVersion of 2, > > And on every tx bump, we decide whether to keep this scheme (mempool > would enforce it always). > > Cheers, > Rusty. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Peter Todd writes: > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >> Peter Todd via bitcoin-dev >> writes: >> > However I don't think we've done a good job showing why we need to >> > implement this feature via nSequence. >> >> It could be implemented in other ways, but nSequence is the neatest and >> most straightforward I've seen. >> >> - I'm not aware of any other (even vague) proposal for its use? Enlighten? > > There's three that immediately come to mind: > > Gregory Maxwell has proposed it as a way of discouraging miners from > reorging chains, by including some of the low-order bits of a previous > block header in nSequence. > > A few people have proposed implementing proof-of-stake blocksize voting > with nSequence. Excellent, thanks! It's good to have such ideas as a compass. PoS voting seems like it won't be a problem in 5 bits. The "prevbits" idea would want more bits; naively 64 would be good, but I think there are some tricks we can use to make 32 work OK. We would have to then split between nLocktime (if available) and multiple nSequence fields, and it would weaken it for some txs. There is one easy solution: change the BIP wording from: -For transactions with an nVersion of 2 or greater, +For transactions with an nVersion of 2, And on every tx bump, we decide whether to keep this scheme (mempool would enforce it always). Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > Peter Todd via bitcoin-dev > writes: > > However I don't think we've done a good job showing why we need to > > implement this feature via nSequence. > > It could be implemented in other ways, but nSequence is the neatest and > most straightforward I've seen. > > - I'm not aware of any other (even vague) proposal for its use? Enlighten? There's three that immediately come to mind: Gregory Maxwell has proposed it as a way of discouraging miners from reorging chains, by including some of the low-order bits of a previous block header in nSequence. A few people have proposed implementing proof-of-stake blocksize voting with nSequence. > - BIP68 reserves much of it for future use already. Well, a few low-order bits, if you want to use RCLTV functionality; pure RCLTV would save a lot more bits. > If we apply infinite caution we could never use nSequence, as there > might be a better use tommorrow. Indeed! But lets make sure we have a good argument in the BIP. -- 'peter'[:-1]@petertodd.org 0de60f807a5fd32057510e7715038ecbc888052861b6a5c1 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, Another issue that came to mind re: CSV review is that there isn't actually any one pull-req with all the code changes together, making it hard to be sure what the final effect will be once all three BIPs are merged. While evaluating stuff separately is often good, I think this is a case where the overall design needs to be evaluated as a single unit to fully understand the behavior. -- 'peter'[:-1]@petertodd.org 0de60f807a5fd32057510e7715038ecbc888052861b6a5c1 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Hi Peter, On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > So we need to make the case for two main things: > > 1) We have applications that need a relative (instead of absolute CLTV) Lightning network needs RCLTV for bidireciontal payment channels without an explicit expiration date. Without a relative locktime, there is an economic tradeoff between longer channel expiry dates due to lower fees, and the time-value delay for non-cooperation. Due to this tradeoff, there is a risk that people may create channels with entities which they believe will be around in the future and act in a particular way. In other words, it is possible that people will attach reputation as part of their decision-making for channel creation. > 2) Additionally to RCLTV, we need to implement this via nSequence > > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. BIP68 describes the new nSequence > semantics, and gives the rational for them as being a > "Consensus-enforced tx replacement" mechanism, with a bidirectional > payment channel as an example of this in action. However, the > bidirectional payment channel concept itself can be easily implemented > with CLTV alone. There is a small drawback in that the initial > transaction could be delayed, reducing the overall time the channel > exists, but the protocol already assumes that transactions can be > reliably confirmed within a day - significantly less than the proposed > 30 days duration of the channel. That example alone I don't think > justifies a fairly complex soft-fork that limits future upgrades; we > need more justification. The examples (including for Lightning Network) in BIP 112 provides a rationale for using a relative locktime which cannot be achieved using CLTV/hard-nLocktime alone. Without BIP 112, I agree the example in BIP 68 can also be done with nLocktime, but I think they sort of go together? However, there are some advantages to using some kind of relative locktime field such as nSequence over purely a script opcode. This is especially useful if one presumes some kind of long-term malleability fix which does not include directly signing the TXID of the parent transaction. It allows one to update dependent spending transactions after-the-fact; after transactions are signed. If there are unbroadcasted 2-of-2 multisig output transactions, where Tx1 is confirmed on-chain and off-chain Tx2 spends from Tx1, they can elect to spend Tx3a from the output of Tx2. Tx3a can have an nSequence value which requires a minimum of 100 block confirmations of Tx2 to elapse before Tx3a can be broadcast. As neither Tx2 or Tx3a have yet broadcast, they can elect to double-spend Tx2 with a new transaction with a lower nSequence value, e.g. Tx3b. This is important, as Tx2 will *always* be spendable so creating new revocation rules is useful for Tx2. I think Mark had once described the general idea is to have a similar separation of the opcode and the actual validation of block height in the codebase as nLockTime/OP_CLTV, as having pure validation in the script which may make things a bit ugly. > So, what else can the community come up with? nSequence itself exists > because of a failed feature that turned out to not work as intended; > it'd be a shame to make that kind of mistake again, so let's get our > semantics and use-cases in the BIPs and documented before we deploy. I agree. There may be some impact for future changes in Bitcoin, wrt BIP 68. For BIP 112, I think the impact could be minimal, but there may be future interpretations of nSequence. In particular, in the long term there may be some kind of need for some kind of "timestop" bit (to define whether to count relative blockheight or timestopped blockheight), which already consumes unreserved space. To account for more than one upgrade, the next future upgrade after BIP 68 may be implemented by taking the unused most significant bit in nSequence as defined in BIP 68 in combination with using up a version field bit. jl1202 had previously suggested doing this for BIP 68 itself: e7b394187fd96bd77a1c49f7c9b7a...@xbt.hk http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011358.html As-is, the only actual tradeoff made by BIP 68 is reducing range by half. I think BIP 68 works as-is or with burning an nVersion bit today, as it should allow for future (necessary) upgrades. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
On Mon, Oct 05, 2015 at 05:19:06PM -0700, Mark Friedenbach via bitcoin-dev wrote: > Alex, decreasing granularity is a soft-fork, increasing is a hard-fork. > Therefore I've kept the highest possible precision (1 second, 1 block) with > the expectation that at some point in the future if we need more low-order > bits we can soft-fork them to other purposes, we can decrease granularity > at that time. You should write that up in the BIP, along with a description of how exactly that would go; I suspect the most obvious way of dong that upgrade - just increase precision for everyone - would break compatbility too much to be practical. -- 'peter'[:-1]@petertodd.org 10734953ce486a820b6f7907e879b1b6e30fccf603098bef signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Peter Todd via bitcoin-dev writes: > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. It could be implemented in other ways, but nSequence is the neatest and most straightforward I've seen. - I'm not aware of any other (even vague) proposal for its use? Enlighten? - BIP68 reserves much of it for future use already. If we apply infinite caution we could never use nSequence, as there might be a better use tommorrow. Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Regarding the keeping nSequence for future expansion I believe this has been covered in the specification section of BIP68[1]: For transaction version >= 2, if the MSB of nSequence is unset, the field is interpreted as relative locktime, otherwise no special consensus meaning is attached (and thus free for repurposing in the future). Effectively if the MSB is set, the remaining 31 bits (out of 32) are free. Also please note the BIP112 text has been updated with several more usecases. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Alex, decreasing granularity is a soft-fork, increasing is a hard-fork. Therefore I've kept the highest possible precision (1 second, 1 block) with the expectation that at some point in the future if we need more low-order bits we can soft-fork them to other purposes, we can decrease granularity at that time. On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Peter, > > Your concern about whether this is the best way to use the nSequence > field; would that be addressed by providing more high order bits to signal > different uses of the field? At a certain point we're really not limiting > the future at all and there is something to be said for not letting the > perfect be the enemy of the good. I think it would be nice to make forward > progress on BIPS 68,112, and 113 and move towards getting them finalized > and implemented. (Although I do suspect they aren't quite ready to go out > with CLTV) > > What is the reasoning for having single second resolution on the time > based sequence number locks? Might it not make some sense to reduce that > resolution and leave more low order bits as well? > > Alex > > On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Hi aj, >> >> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote: >> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via >> > bitcoin-dev wrote: >> >> So we need to make the case for two main things: 1) We have >> >> applications that need a relative (instead of absolute CLTV) 2) >> >> Additionally to RCLTV, we need to implement this via nSequence >> > >> >> However I don't think we've done a good job showing why we need >> >> to implement this feature via nSequence. BIP68 describes the new >> >> nSequence semantics, and gives the rational for them as being a >> >> "Consensus-enforced tx replacement" mechanism, with a >> >> bidirectional payment channel as an example of this in action. >> >> However, the bidirectional payment channel concept itself can be >> >> easily implemented with CLTV alone. >> > >> > Do you mean "with RCLTV alone" here? >> > >> > RCLTV/OP_CSV is used in lightning commitment transactions to >> > enforce a delay between publishing the commitment transaction, and >> > spending the output -- that delay is needed so that the >> > counterparty has time to prove the commitment was revoked and claim >> > the outputs as a penalty. >> > >> >> I partially understand - can you please provide a simple Alice and Bob >> example here with the exact scenario? Thanks. Why is there a need to >> 'delay between publishing the commitment transaction and spending the >> output'? If the absolute CLTV script reached its maturity it means >> something went wrong (e.g. counterparty cheated or got hit by a bus) >> so what is with the delay time needed for proving that the commitment >> was revoked? I assume an absolute CLTV script reaching its maturity >> (nLockTime) is the proof itself that the commitment was revoked - but >> maybe I'm missing something obvious, sorry if this is the case. >> >> > Using absolute CLTV instead would mean that once the effective >> > delay a commitment transaction has decreases over time -- initially >> > it will be longer than desirable, causing unwanted delays in >> > claiming funds when no cheating is going on; but over time it will >> > become too short, which means there is not enough time to prove >> > cheating (and the channel has to be closed prematurely). You can >> > trade those things off and pick something that works, but it's >> > always going to be bad. >> > >> I agree, I see the logic here. Absolute CLTV is not necessary inferior >> to RCLTV - there are use cases and use cases. For example, you can >> avoid unnecessary waiting until the nLockTime expires if you use >> absolute CLTV in combination with P2SH (2/2). Again, it always depends >> on the use case - it might be a good solution, it might not be such a >> good solution, but even absolute CLTV alone clearly fixes a lot of >> things and takes smart contracts to the next level. >> >> >> There is a small drawback in that the initial transaction could >> >> be delayed, reducing the overall time the channel exists, but the >> >> protocol already assumes that transactions can be reliably >> >> confirmed within a day - significantly less than the proposed 30 >> >> days duration of the channel. >> > >> > Compared to using a CLTV with 30 days duration, With RCLTV a >> > channel could be available for years (ie 20x longer), but in the >> > case of problems funds could be reclaimed within hours or days (ie >> > 30x faster). >> > >> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it >> would be neat to have both, but if I can only have (for the time >> being) absolute CLTV so be it - it's still a lot better. >> >> > But that's all about RCLTV vs CLTV, not about RC
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Peter, Your concern about whether this is the best way to use the nSequence field; would that be addressed by providing more high order bits to signal different uses of the field? At a certain point we're really not limiting the future at all and there is something to be said for not letting the perfect be the enemy of the good. I think it would be nice to make forward progress on BIPS 68,112, and 113 and move towards getting them finalized and implemented. (Although I do suspect they aren't quite ready to go out with CLTV) What is the reasoning for having single second resolution on the time based sequence number locks? Might it not make some sense to reduce that resolution and leave more low order bits as well? Alex On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi aj, > > On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote: > > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via > > bitcoin-dev wrote: > >> So we need to make the case for two main things: 1) We have > >> applications that need a relative (instead of absolute CLTV) 2) > >> Additionally to RCLTV, we need to implement this via nSequence > > > >> However I don't think we've done a good job showing why we need > >> to implement this feature via nSequence. BIP68 describes the new > >> nSequence semantics, and gives the rational for them as being a > >> "Consensus-enforced tx replacement" mechanism, with a > >> bidirectional payment channel as an example of this in action. > >> However, the bidirectional payment channel concept itself can be > >> easily implemented with CLTV alone. > > > > Do you mean "with RCLTV alone" here? > > > > RCLTV/OP_CSV is used in lightning commitment transactions to > > enforce a delay between publishing the commitment transaction, and > > spending the output -- that delay is needed so that the > > counterparty has time to prove the commitment was revoked and claim > > the outputs as a penalty. > > > > I partially understand - can you please provide a simple Alice and Bob > example here with the exact scenario? Thanks. Why is there a need to > 'delay between publishing the commitment transaction and spending the > output'? If the absolute CLTV script reached its maturity it means > something went wrong (e.g. counterparty cheated or got hit by a bus) > so what is with the delay time needed for proving that the commitment > was revoked? I assume an absolute CLTV script reaching its maturity > (nLockTime) is the proof itself that the commitment was revoked - but > maybe I'm missing something obvious, sorry if this is the case. > > > Using absolute CLTV instead would mean that once the effective > > delay a commitment transaction has decreases over time -- initially > > it will be longer than desirable, causing unwanted delays in > > claiming funds when no cheating is going on; but over time it will > > become too short, which means there is not enough time to prove > > cheating (and the channel has to be closed prematurely). You can > > trade those things off and pick something that works, but it's > > always going to be bad. > > > I agree, I see the logic here. Absolute CLTV is not necessary inferior > to RCLTV - there are use cases and use cases. For example, you can > avoid unnecessary waiting until the nLockTime expires if you use > absolute CLTV in combination with P2SH (2/2). Again, it always depends > on the use case - it might be a good solution, it might not be such a > good solution, but even absolute CLTV alone clearly fixes a lot of > things and takes smart contracts to the next level. > > >> There is a small drawback in that the initial transaction could > >> be delayed, reducing the overall time the channel exists, but the > >> protocol already assumes that transactions can be reliably > >> confirmed within a day - significantly less than the proposed 30 > >> days duration of the channel. > > > > Compared to using a CLTV with 30 days duration, With RCLTV a > > channel could be available for years (ie 20x longer), but in the > > case of problems funds could be reclaimed within hours or days (ie > > 30x faster). > > > Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it > would be neat to have both, but if I can only have (for the time > being) absolute CLTV so be it - it's still a lot better. > > > But that's all about RCLTV vs CLTV, not about RCLTV vs > > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily > > BIP 68 (nSequence relative locktime), if they could be > > disentangled. > > > > You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY" that > > ignores nSequence, and directly compares the height of the current > > block versus the input tx's block (or the diff of their > > timestamps?) though, I think? > > > > I think the disadvantage is that (a) you have to look into the > > input transaction's block height when processing the script;
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi aj, On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote: > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via > bitcoin-dev wrote: >> So we need to make the case for two main things: 1) We have >> applications that need a relative (instead of absolute CLTV) 2) >> Additionally to RCLTV, we need to implement this via nSequence > >> However I don't think we've done a good job showing why we need >> to implement this feature via nSequence. BIP68 describes the new >> nSequence semantics, and gives the rational for them as being a >> "Consensus-enforced tx replacement" mechanism, with a >> bidirectional payment channel as an example of this in action. >> However, the bidirectional payment channel concept itself can be >> easily implemented with CLTV alone. > > Do you mean "with RCLTV alone" here? > > RCLTV/OP_CSV is used in lightning commitment transactions to > enforce a delay between publishing the commitment transaction, and > spending the output -- that delay is needed so that the > counterparty has time to prove the commitment was revoked and claim > the outputs as a penalty. > I partially understand - can you please provide a simple Alice and Bob example here with the exact scenario? Thanks. Why is there a need to 'delay between publishing the commitment transaction and spending the output'? If the absolute CLTV script reached its maturity it means something went wrong (e.g. counterparty cheated or got hit by a bus) so what is with the delay time needed for proving that the commitment was revoked? I assume an absolute CLTV script reaching its maturity (nLockTime) is the proof itself that the commitment was revoked - but maybe I'm missing something obvious, sorry if this is the case. > Using absolute CLTV instead would mean that once the effective > delay a commitment transaction has decreases over time -- initially > it will be longer than desirable, causing unwanted delays in > claiming funds when no cheating is going on; but over time it will > become too short, which means there is not enough time to prove > cheating (and the channel has to be closed prematurely). You can > trade those things off and pick something that works, but it's > always going to be bad. > I agree, I see the logic here. Absolute CLTV is not necessary inferior to RCLTV - there are use cases and use cases. For example, you can avoid unnecessary waiting until the nLockTime expires if you use absolute CLTV in combination with P2SH (2/2). Again, it always depends on the use case - it might be a good solution, it might not be such a good solution, but even absolute CLTV alone clearly fixes a lot of things and takes smart contracts to the next level. >> There is a small drawback in that the initial transaction could >> be delayed, reducing the overall time the channel exists, but the >> protocol already assumes that transactions can be reliably >> confirmed within a day - significantly less than the proposed 30 >> days duration of the channel. > > Compared to using a CLTV with 30 days duration, With RCLTV a > channel could be available for years (ie 20x longer), but in the > case of problems funds could be reclaimed within hours or days (ie > 30x faster). > Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it would be neat to have both, but if I can only have (for the time being) absolute CLTV so be it - it's still a lot better. > But that's all about RCLTV vs CLTV, not about RCLTV vs > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily > BIP 68 (nSequence relative locktime), if they could be > disentangled. > > You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY" that > ignores nSequence, and directly compares the height of the current > block versus the input tx's block (or the diff of their > timestamps?) though, I think? > > I think the disadvantage is that (a) you have to look into the > input transaction's block height when processing the script; and > (b) you don't have an easy lookup to check whether the transaction > can be included in the next block. > > You could maybe avoid (b) by using locktime though. Have " > OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions > locktime against the input's block height or time; if the locktime > is 0 or too low, the transaction is invalid. (So if nLockTime is in > blockheight, you can only spend inputs with blockheight based > OP_CRLTV tests; and if it's in blocktime, you can only spend inputs > with blocktime based OP_CRLTV. "n" does need to encode whether it's > time/block height though). > > That way, when you see a txn: > > - run the script. if you see RCLTV, then + if the tx's locktime > isn't set, it's invalid; drop it + if the input txn is unconfirmed, > it's invalid; try again later + workout "locktime - n" if that's >= > the input tx's block height/time, it's good; keep it in mempool, > forward it, etc > > - if you're mining, include the tx when l
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > So we need to make the case for two main things: > 1) We have applications that need a relative (instead of absolute CLTV) > 2) Additionally to RCLTV, we need to implement this via nSequence > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. BIP68 describes the new nSequence > semantics, and gives the rational for them as being a > "Consensus-enforced tx replacement" mechanism, with a bidirectional > payment channel as an example of this in action. However, the > bidirectional payment channel concept itself can be easily implemented > with CLTV alone. Do you mean "with RCLTV alone" here? RCLTV/OP_CSV is used in lightning commitment transactions to enforce a delay between publishing the commitment transaction, and spending the output -- that delay is needed so that the counterparty has time to prove the commitment was revoked and claim the outputs as a penalty. Using absolute CLTV instead would mean that once the effective delay a commitment transaction has decreases over time -- initially it will be longer than desirable, causing unwanted delays in claiming funds when no cheating is going on; but over time it will become too short, which means there is not enough time to prove cheating (and the channel has to be closed prematurely). You can trade those things off and pick something that works, but it's always going to be bad. > There is a small drawback in that the initial > transaction could be delayed, reducing the overall time the channel > exists, but the protocol already assumes that transactions can be > reliably confirmed within a day - significantly less than the proposed > 30 days duration of the channel. Compared to using a CLTV with 30 days duration, With RCLTV a channel could be available for years (ie 20x longer), but in the case of problems funds could be reclaimed within hours or days (ie 30x faster). But that's all about RCLTV vs CLTV, not about RCLTV vs nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily BIP 68 (nSequence relative locktime), if they could be disentangled. You could do all that with " OP_CHECK_HEIGHT_DELTA_VERIFY" that ignores nSequence, and directly compares the height of the current block versus the input tx's block (or the diff of their timestamps?) though, I think? I think the disadvantage is that (a) you have to look into the input transaction's block height when processing the script; and (b) you don't have an easy lookup to check whether the transaction can be included in the next block. You could maybe avoid (b) by using locktime though. Have " OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions locktime against the input's block height or time; if the locktime is 0 or too low, the transaction is invalid. (So if nLockTime is in blockheight, you can only spend inputs with blockheight based OP_CRLTV tests; and if it's in blocktime, you can only spend inputs with blocktime based OP_CRLTV. "n" does need to encode whether it's time/block height though). That way, when you see a txn: - run the script. if you see RCLTV, then + if the tx's locktime isn't set, it's invalid; drop it + if the input txn is unconfirmed, it's invalid; try again later + workout "locktime - n" if that's >= the input tx's block height/time, it's good; keep it in mempool, forward it, etc - if you're mining, include the tx when locktime hits, just like you would any other valid tx with a locktime I think the use cases for BIP68 (nSequence) are of the form: 1) published input; here's a signed tx that spends it to you, usable after a delay. might as well just use absolute locktime here, though. 2) here's an unpublished input, you can build your own transaction to spend it, just not immediately after it's published. BIP112 is required, and OP_RCLTV as defined above works fine, just include it in the published input's script. 3) here's an unpublished input, and a signed transaction spending it, that you can use to spend it after a delay. BIP68 is enough; but OP_RCLTV in the second transaction works here. however without normalised tx ids, the input could be malleated before publication, so maybe this use case isn't actually important anyway. So I think OP_CRLTV alone works fine for them too... (Does that make sense, or am I missing something obvious?) Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
BIP68 allows per-input locktime, though I don't know how this could be useful. BIP68 and BIP112 are mostly ready. If we try to reimplement relative-locktime without using nSequence, we may need to wait for another year for deployment. A compromise is to make BIP68 optional, indicated by a bit in tx nVersion, as I suggested earlier (1). This will allow deploying relative-locktime without further delay while not permanently limiting future upgrades. (1) http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html Peter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到: BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY. However, CSV does define behavior for the previously undefined nSequence field, which is the only "free-form" field we currently have in the transaction serialization format that can be used for future upgrades - we should justify this new behavior carefully as it limits our options in the future. Adding new fields to the serialization format is very difficult, due to the very broad system-wide impact of the hard-fork required to do so. So we need to make the case for two main things: 1) We have applications that need a relative (instead of absolute CLTV) 2) Additionally to RCLTV, we need to implement this via nSequence To show we need RCLTV BIP112 provides the example "Escrow with Timeout", which is a need that was brought up by GreenAddress, among others; I don't think we have an issue there, though getting more examples would be a good thing. (the CLTV BIP describes seven use cases, and one additional future use-case) However I don't think we've done a good job showing why we need to implement this feature via nSequence. BIP68 describes the new nSequence semantics, and gives the rational for them as being a "Consensus-enforced tx replacement" mechanism, with a bidirectional payment channel as an example of this in action. However, the bidirectional payment channel concept itself can be easily implemented with CLTV alone. There is a small drawback in that the initial transaction could be delayed, reducing the overall time the channel exists, but the protocol already assumes that transactions can be reliably confirmed within a day - significantly less than the proposed 30 days duration of the channel. That example alone I don't think justifies a fairly complex soft-fork that limits future upgrades; we need more justification. So, what else can the community come up with? nSequence itself exists because of a failed feature that turned out to not work as intended; it'd be a shame to make that kind of mistake again, so let's get our semantics and use-cases in the BIPs and documented before we deploy. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY. However, CSV does define behavior for the previously undefined nSequence field, which is the only "free-form" field we currently have in the transaction serialization format that can be used for future upgrades - we should justify this new behavior carefully as it limits our options in the future. Adding new fields to the serialization format is very difficult, due to the very broad system-wide impact of the hard-fork required to do so. So we need to make the case for two main things: 1) We have applications that need a relative (instead of absolute CLTV) 2) Additionally to RCLTV, we need to implement this via nSequence To show we need RCLTV BIP112 provides the example "Escrow with Timeout", which is a need that was brought up by GreenAddress, among others; I don't think we have an issue there, though getting more examples would be a good thing. (the CLTV BIP describes seven use cases, and one additional future use-case) However I don't think we've done a good job showing why we need to implement this feature via nSequence. BIP68 describes the new nSequence semantics, and gives the rational for them as being a "Consensus-enforced tx replacement" mechanism, with a bidirectional payment channel as an example of this in action. However, the bidirectional payment channel concept itself can be easily implemented with CLTV alone. There is a small drawback in that the initial transaction could be delayed, reducing the overall time the channel exists, but the protocol already assumes that transactions can be reliably confirmed within a day - significantly less than the proposed 30 days duration of the channel. That example alone I don't think justifies a fairly complex soft-fork that limits future upgrades; we need more justification. So, what else can the community come up with? nSequence itself exists because of a failed feature that turned out to not work as intended; it'd be a shame to make that kind of mistake again, so let's get our semantics and use-cases in the BIPs and documented before we deploy. -- 'peter'[:-1]@petertodd.org 0ea95b4a24d0a510d4b5a98186f904dc16da07c41189d8b8 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev