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