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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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