* [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
@ 2015-10-03 14:30 Peter Todd
2015-10-03 18:49 ` jl2012
` (5 more replies)
0 siblings, 6 replies; 21+ messages in thread
From: Peter Todd @ 2015-10-03 14:30 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
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
00000000000000000ea95b4a24d0a510d4b5a98186f904dc16da07c41189d8b8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd @ 2015-10-03 18:49 ` jl2012 2015-10-04 8:35 ` Anthony Towns ` (4 subsequent siblings) 5 siblings, 0 replies; 21+ messages in thread From: jl2012 @ 2015-10-03 18:49 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd 2015-10-03 18:49 ` jl2012 @ 2015-10-04 8:35 ` Anthony Towns 2015-10-04 12:04 ` s7r 2015-10-06 0:28 ` Btc Drak ` (3 subsequent siblings) 5 siblings, 1 reply; 21+ messages in thread From: Anthony Towns @ 2015-10-04 8:35 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev 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 "<n> 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 "<n> 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 <n> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-04 8:35 ` Anthony Towns @ 2015-10-04 12:04 ` s7r 2015-10-05 22:03 ` Alex Morcos 0 siblings, 1 reply; 21+ messages in thread From: s7r @ 2015-10-04 12:04 UTC (permalink / raw) To: Anthony Towns, Peter Todd; +Cc: bitcoin-dev -----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 "<n> 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 "<n> > 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 <n> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9 mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk= =U0N6 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-04 12:04 ` s7r @ 2015-10-05 22:03 ` Alex Morcos 2015-10-06 0:19 ` Mark Friedenbach 0 siblings, 1 reply; 21+ messages in thread From: Alex Morcos @ 2015-10-05 22:03 UTC (permalink / raw) To: s7r; +Cc: Bitcoin Dev, Anthony Towns [-- Attachment #1: Type: text/plain, Size: 7772 bytes --] 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 "<n> 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 "<n> > > 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 <n> 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9 > mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k > dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb > j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD > /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th > RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk= > =U0N6 > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9458 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-05 22:03 ` Alex Morcos @ 2015-10-06 0:19 ` Mark Friedenbach 2015-10-06 11:09 ` Peter Todd 0 siblings, 1 reply; 21+ messages in thread From: Mark Friedenbach @ 2015-10-06 0:19 UTC (permalink / raw) To: Alex Morcos; +Cc: Bitcoin Dev, Anthony Towns [-- Attachment #1: Type: text/plain, Size: 8563 bytes --] 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 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 "<n> 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 "<n> >> > 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 <n> 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 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9 >> mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k >> dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb >> j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD >> /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th >> RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk= >> =U0N6 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 > > [-- Attachment #2: Type: text/html, Size: 10569 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-06 0:19 ` Mark Friedenbach @ 2015-10-06 11:09 ` Peter Todd 0 siblings, 0 replies; 21+ messages in thread From: Peter Todd @ 2015-10-06 11:09 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev, Anthony Towns [-- Attachment #1: Type: text/plain, Size: 752 bytes --] 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 000000000000000010734953ce486a820b6f7907e879b1b6e30fccf603098bef [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd 2015-10-03 18:49 ` jl2012 2015-10-04 8:35 ` Anthony Towns @ 2015-10-06 0:28 ` Btc Drak 2015-10-06 1:58 ` Rusty Russell ` (2 subsequent siblings) 5 siblings, 0 replies; 21+ messages in thread From: Btc Drak @ 2015-10-06 0:28 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 490 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 645 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd ` (2 preceding siblings ...) 2015-10-06 0:28 ` Btc Drak @ 2015-10-06 1:58 ` Rusty Russell 2015-10-08 17:41 ` Peter Todd 2015-10-06 20:00 ` Joseph Poon 2015-10-08 17:43 ` Peter Todd 5 siblings, 1 reply; 21+ messages in thread From: Rusty Russell @ 2015-10-06 1:58 UTC (permalink / raw) To: Peter Todd, bitcoin-dev Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-06 1:58 ` Rusty Russell @ 2015-10-08 17:41 ` Peter Todd 2015-10-09 1:38 ` Rusty Russell 0 siblings, 1 reply; 21+ messages in thread From: Peter Todd @ 2015-10-08 17:41 UTC (permalink / raw) To: Rusty Russell; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1213 bytes --] On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > 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 00000000000000000de60f807a5fd32057510e7715038ecbc888052861b6a5c1 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-08 17:41 ` Peter Todd @ 2015-10-09 1:38 ` Rusty Russell 2015-10-15 13:47 ` Alex Morcos 0 siblings, 1 reply; 21+ messages in thread From: Rusty Russell @ 2015-10-09 1:38 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev Peter Todd <pete@petertodd•org> writes: > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> >> 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-09 1:38 ` Rusty Russell @ 2015-10-15 13:47 ` Alex Morcos 2015-10-15 16:27 ` Btc Drak 0 siblings, 1 reply; 21+ messages in thread From: Alex Morcos @ 2015-10-15 13:47 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2411 bytes --] 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 <pete@petertodd•org> writes: > > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > >> 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 > [-- Attachment #2: Type: text/html, Size: 3483 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 13:47 ` Alex Morcos @ 2015-10-15 16:27 ` Btc Drak 2015-10-15 16:37 ` Adam Back 2015-10-15 23:18 ` Rusty Russell 0 siblings, 2 replies; 21+ messages in thread From: Btc Drak @ 2015-10-15 16:27 UTC (permalink / raw) To: Alex Morcos; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4297 bytes --] 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 = 0x0000ffff; /* 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 <pete@petertodd•org> writes: >> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> >> >> 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 > > [-- Attachment #2: Type: text/html, Size: 6213 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 16:27 ` Btc Drak @ 2015-10-15 16:37 ` Adam Back 2015-10-15 16:41 ` Alex Morcos 2015-10-15 18:31 ` Mark Friedenbach 2015-10-15 23:18 ` Rusty Russell 1 sibling, 2 replies; 21+ messages in thread From: Adam Back @ 2015-10-15 16:37 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev 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 <bitcoin-dev@lists•linuxfoundation.org> 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 = 0x0000ffff; > > /* 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 <pete@petertodd•org> writes: >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> >>> >> 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 > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 16:37 ` Adam Back @ 2015-10-15 16:41 ` Alex Morcos 2015-10-15 18:31 ` Mark Friedenbach 1 sibling, 0 replies; 21+ messages in thread From: Alex Morcos @ 2015-10-15 16:41 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5549 bytes --] 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 <adam@cypherspace•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 > <bitcoin-dev@lists•linuxfoundation.org> 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 = 0x0000ffff; > > > > /* 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 <pete@petertodd•org> writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > >>> >> 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 > > > [-- Attachment #2: Type: text/html, Size: 8149 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 16:37 ` Adam Back 2015-10-15 16:41 ` Alex Morcos @ 2015-10-15 18:31 ` Mark Friedenbach 1 sibling, 0 replies; 21+ messages in thread From: Mark Friedenbach @ 2015-10-15 18:31 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7394 bytes --] 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 > <bitcoin-dev@lists•linuxfoundation.org> 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 = 0x0000ffff; > > > > /* 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 <pete@petertodd•org> writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> > >>> >> 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 list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 10205 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 16:27 ` Btc Drak 2015-10-15 16:37 ` Adam Back @ 2015-10-15 23:18 ` Rusty Russell 2015-10-16 1:26 ` Rusty Russell 1 sibling, 1 reply; 21+ messages in thread From: Rusty Russell @ 2015-10-15 23:18 UTC (permalink / raw) To: Btc Drak, Alex Morcos; +Cc: Bitcoin Dev Btc Drak <btcdrak@gmail•com> 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-15 23:18 ` Rusty Russell @ 2015-10-16 1:26 ` Rusty Russell 2015-10-19 10:43 ` Jorge Timón 0 siblings, 1 reply; 21+ messages in thread From: Rusty Russell @ 2015-10-16 1:26 UTC (permalink / raw) To: Btc Drak, Alex Morcos; +Cc: Bitcoin Dev Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-16 1:26 ` Rusty Russell @ 2015-10-19 10:43 ` Jorge Timón 0 siblings, 0 replies; 21+ messages in thread From: Jorge Timón @ 2015-10-19 10:43 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Dev On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd ` (3 preceding siblings ...) 2015-10-06 1:58 ` Rusty Russell @ 2015-10-06 20:00 ` Joseph Poon 2015-10-08 17:43 ` Peter Todd 5 siblings, 0 replies; 21+ messages in thread From: Joseph Poon @ 2015-10-06 20:00 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev 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: e7b394187fd96bd77a1c49f7c9b7a9b2@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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd ` (4 preceding siblings ...) 2015-10-06 20:00 ` Joseph Poon @ 2015-10-08 17:43 ` Peter Todd 5 siblings, 0 replies; 21+ messages in thread From: Peter Todd @ 2015-10-08 17:43 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 659 bytes --] On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, <snip> 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 00000000000000000de60f807a5fd32057510e7715038ecbc888052861b6a5c1 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-10-19 10:43 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd 2015-10-03 18:49 ` jl2012 2015-10-04 8:35 ` Anthony Towns 2015-10-04 12:04 ` s7r 2015-10-05 22:03 ` Alex Morcos 2015-10-06 0:19 ` Mark Friedenbach 2015-10-06 11:09 ` Peter Todd 2015-10-06 0:28 ` Btc Drak 2015-10-06 1:58 ` Rusty Russell 2015-10-08 17:41 ` Peter Todd 2015-10-09 1:38 ` Rusty Russell 2015-10-15 13:47 ` Alex Morcos 2015-10-15 16:27 ` Btc Drak 2015-10-15 16:37 ` Adam Back 2015-10-15 16:41 ` Alex Morcos 2015-10-15 18:31 ` Mark Friedenbach 2015-10-15 23:18 ` Rusty Russell 2015-10-16 1:26 ` Rusty Russell 2015-10-19 10:43 ` Jorge Timón 2015-10-06 20:00 ` Joseph Poon 2015-10-08 17:43 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox