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

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

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

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

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

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

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

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

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

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

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

2015-08-26 Thread Rusty Russell via bitcoin-dev
Btc Drak via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org writes: This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained

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

2015-08-25 Thread Btc Drak via bitcoin-dev
This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained control over txins which neuters the usefulness considerably. Also using

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

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

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

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

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

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

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

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

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

2015-08-23 Thread Gregory Maxwell via bitcoin-dev
On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html I can't follow this

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

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

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

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

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

2015-08-23 Thread Jorge Timón via bitcoin-dev
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional

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

2015-08-19 Thread Jorge Timón via bitcoin-dev
On Wed, Aug 19, 2015 at 11:27 PM, Joseph Poon joseph@lightning.network wrote: On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote: If anyone feels strongly about this, please speak up. On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n

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

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

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

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

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

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

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

2015-08-14 Thread Matt Corallo via bitcoin-dev
On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote: On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I haven't tested the details of this, but is there another bit available

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

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

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

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