š
Original date posted:2015-10-15
š Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete at petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/d0e24a27/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-07 17:42:30
in reply to nevent1qā¦0wpd
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 17:42:30Event JSON
{
"id": "054d9e17fe07e3bf14bd626ee74f787491cd290427d0d574c6194ad3591fab6c",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686159750,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"db630c5f305a8b0d3c93dddadf61ae8637af9787e70b6caf7a794e2e2bbdf802",
"",
"reply"
],
[
"p",
"78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c"
]
],
"content": "š
Original date posted:2015-10-15\nš Original message:Adam, there is really no justification I can see to lower the interblock\ninterval on the Bitcoin blockchain, primarily due to the effects of network\nlatency. Lowering the interblock interval and raising the block size are\nnot equal alternatives - you can always get more throughput in bitcoin by\nraising the block size than by lowering the interblock time. And that's\nwithout considering the effect shorter intervals would have on e.g. SPV\nclient bandwidth or sidechain connectivity proofs. So I find it very\nunlikely that such granularity would ever be needed on the Bitcoin block\nchain, although if were to happen then extra bits from nSequence could be\nused in a soft-fork compatible way.\n\nHowever it is true that various sidechains such as Liquid will have a much\nshorter interblock interval than 10min, as well as customer demand for\nprotocols with shorter timeouts. It would be nice if such systems did not\nHAVE to resort to complex bit shifting to support more precision, and if\nprotocols written for bitcoin could be reused on such systems with minimal\nor no modification.\n\nTo that end, it might be preferable to move the flag bit indicating use of\nseconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22\nto provide higher granularity in a sidechain environment. This keeps the\nsize of a stack push to 3 bytes while also keeping sufficient room for\nhigh-order bits of relative lock-time in a sidechain that supports shorter\nblock intervals.\n\nAnother alternative is to put the units flag in the least significant bit,\nwhich has the advantage of allowing both units of lock-time to make use of\n1-2 byte pushes, but the disadvantage of making lock times of 64..127\n2-bytes instead of 1-byte.\n\nThoughts?\n\nOn Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Does that pre-judge that block interval would never change from\n\u003e 10mins? Eg say with IBLT or fountain codes etc and security arguments\n\u003e for the current limitations of them are found, such that orphan rates\n\u003e can remain low in a decentralised way with 1min blocks, then the\n\u003e locktime granularity would be coarse relative to the block interval\n\u003e (with 512s locktime granularity.\n\u003e\n\u003e Adam\n\u003e\n\u003e On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Alex,\n\u003e \u003e\n\u003e \u003e I am sorry for not communicating more clearly. Mark and I discussed your\n\u003e \u003e concerns from the last meeting and he made the change. The BIP text still\n\u003e \u003e needs to be updated, but the discussed change was added to the PR, albeit\n\u003e \u003e squashed making it more non-obvious. BIP68 now explicitly uses 16 bits\n\u003e with\n\u003e \u003e a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and\n\u003e \u003e SEQUENCE_LOCKTIME_GRANULARITY in the PR\n\u003e \u003e https://github.com/bitcoin/bitcoin/pull/6312.\n\u003e \u003e\n\u003e \u003e /* If CTxIn::nSequence encodes a relative lock-time, this mask is\n\u003e \u003e * applied to extract that lock-time from the sequence field. */\n\u003e \u003e static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;\n\u003e \u003e\n\u003e \u003e /* In order to use the same number of bits to encode roughly the\n\u003e \u003e * same wall-clock duration, and because blocks are naturally\n\u003e \u003e * limited to occur every 600s on average, the minimum granularity\n\u003e \u003e * for time-based relative lock-time is fixed at 512 seconds.\n\u003e \u003e * Converting from CTxIn::nSequence to seconds is performed by\n\u003e \u003e * multiplying by 512 = 2^9, or equivalently shifting up by\n\u003e \u003e * 9 bits. */\n\u003e \u003e static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;\n\u003e \u003e\n\u003e \u003e I am also much happier with this last tightening up of the specification\n\u003e \u003e because it removes ambiguity. 512s granularity makes sense within the\n\u003e \u003e context of the 10 minute block target.\n\u003e \u003e\n\u003e \u003e Thank you for spending so much time carefully considering this BIP and\n\u003e \u003e reference implementation and please let me know if there there are any\n\u003e \u003e remaining nits so we can get those addressed.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Mark,\n\u003e \u003e\u003e\n\u003e \u003e\u003e You seemed interested in changing BIP 68 to use 16 bits for sequence\n\u003e \u003e\u003e number in both the block and time versions, making time based sequence\n\u003e \u003e\u003e numbers have a resolution of 512 seconds.\n\u003e \u003e\u003e\n\u003e \u003e\u003e I'm in favor of this approach because it leaves aside 14 bits for\n\u003e further\n\u003e \u003e\u003e soft forks within the semantics of BIP 68.\n\u003e \u003e\u003e\n\u003e \u003e\u003e It would be nice to know if you're planning this change, and perhaps\n\u003e \u003e\u003e people can hold off on review until things are finalized.\n\u003e \u003e\u003e\n\u003e \u003e\u003e I'd cast my \"vote\" against BIP 68 without this change, but am also open\n\u003e to\n\u003e \u003e\u003e being convinced otherwise.\n\u003e \u003e\u003e\n\u003e \u003e\u003e What are other peoples opinions on this?\n\u003e \u003e\u003e\n\u003e \u003e\u003e On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev\n\u003e \u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Peter Todd \u003cpete at petertodd.org\u003e writes:\n\u003e \u003e\u003e\u003e \u003e On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:\n\u003e \u003e\u003e\u003e \u003e\u003e Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e \u003e\u003e\u003e \u003e\u003e writes:\n\u003e \u003e\u003e\u003e \u003e\u003e \u003e However I don't think we've done a good job showing why we need to\n\u003e \u003e\u003e\u003e \u003e\u003e \u003e implement this feature via nSequence.\n\u003e \u003e\u003e\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e \u003e\u003e It could be implemented in other ways, but nSequence is the neatest\n\u003e \u003e\u003e\u003e \u003e\u003e and\n\u003e \u003e\u003e\u003e \u003e\u003e most straightforward I've seen.\n\u003e \u003e\u003e\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e \u003e\u003e - I'm not aware of any other (even vague) proposal for its use?\n\u003e \u003e\u003e\u003e \u003e\u003e Enlighten?\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e There's three that immediately come to mind:\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e Gregory Maxwell has proposed it as a way of discouraging miners from\n\u003e \u003e\u003e\u003e \u003e reorging chains, by including some of the low-order bits of a\n\u003e previous\n\u003e \u003e\u003e\u003e \u003e block header in nSequence.\n\u003e \u003e\u003e\u003e \u003e\n\u003e \u003e\u003e\u003e \u003e A few people have proposed implementing proof-of-stake blocksize\n\u003e voting\n\u003e \u003e\u003e\u003e \u003e with nSequence.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Excellent, thanks! It's good to have such ideas as a compass. PoS\n\u003e \u003e\u003e\u003e voting seems like it won't be a problem in 5 bits.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e The \"prevbits\" idea would want more bits; naively 64 would be good, but\n\u003e \u003e\u003e\u003e I think there are some tricks we can use to make 32 work OK. We would\n\u003e \u003e\u003e\u003e have to then split between nLocktime (if available) and multiple\n\u003e \u003e\u003e\u003e nSequence fields, and it would weaken it for some txs.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e There is one easy solution: change the BIP wording from:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e -For transactions with an nVersion of 2 or greater,\n\u003e \u003e\u003e\u003e +For transactions with an nVersion of 2,\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e And on every tx bump, we decide whether to keep this scheme (mempool\n\u003e \u003e\u003e\u003e would enforce it always).\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Cheers,\n\u003e \u003e\u003e\u003e Rusty.\n\u003e \u003e\u003e\u003e _______________________________________________\n\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/d0e24a27/attachment.html\u003e",
"sig": "8bdadc3aee0e8549ae2d5404a0991d1f0fe1f50cf2fefe820dc9ee296cce104fb5f7838d18108a02b4a98ff655db29600c396237d49526bea7510c018a584d14"
}