š
Original date posted:2015-10-15
š Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/11660e06/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10zā¦3xfzw
2023-06-07 19:42:29
in reply to nevent1qā¦w9qt
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwPublished at
2023-06-07 19:42:29Event JSON
{
"id": "9af282da27de38df49349c325c6e72a2b599c2d0aa50d3224400a891695bc8ac",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686159749,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"05a0ed8541b75d35d20ee28642eda51001d77b61b34841bc2b157502051eae70",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2015-10-15\nš Original message:Mark,\n\nYou seemed interested in changing BIP 68 to use 16 bits for sequence number\nin both the block and time versions, making time based sequence numbers\nhave a resolution of 512 seconds.\n\nI'm in favor of this approach because it leaves aside 14 bits for further\nsoft forks within the semantics of BIP 68.\n\nIt would be nice to know if you're planning this change, and perhaps people\ncan hold off on review until things are finalized.\n\nI'd cast my \"vote\" against BIP 68 without this change, but am also open to\nbeing convinced otherwise.\n\nWhat are other peoples opinions on this?\n\nOn Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Peter Todd \u003cpete at petertodd.org\u003e writes:\n\u003e \u003e On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:\n\u003e \u003e\u003e Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e \u003e\u003e writes:\n\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 implement this feature via nSequence.\n\u003e \u003e\u003e\n\u003e \u003e\u003e It could be implemented in other ways, but nSequence is the neatest and\n\u003e \u003e\u003e most straightforward I've seen.\n\u003e \u003e\u003e\n\u003e \u003e\u003e - I'm not aware of any other (even vague) proposal for its use?\n\u003e Enlighten?\n\u003e \u003e\n\u003e \u003e There's three that immediately come to mind:\n\u003e \u003e\n\u003e \u003e Gregory Maxwell has proposed it as a way of discouraging miners from\n\u003e \u003e reorging chains, by including some of the low-order bits of a previous\n\u003e \u003e block header in nSequence.\n\u003e \u003e\n\u003e \u003e A few people have proposed implementing proof-of-stake blocksize voting\n\u003e \u003e with nSequence.\n\u003e\n\u003e Excellent, thanks! It's good to have such ideas as a compass. PoS\n\u003e voting seems like it won't be a problem in 5 bits.\n\u003e\n\u003e The \"prevbits\" idea would want more bits; naively 64 would be good, but\n\u003e I think there are some tricks we can use to make 32 work OK. We would\n\u003e have to then split between nLocktime (if available) and multiple\n\u003e nSequence fields, and it would weaken it for some txs.\n\u003e\n\u003e There is one easy solution: change the BIP wording from:\n\u003e\n\u003e -For transactions with an nVersion of 2 or greater,\n\u003e +For transactions with an nVersion of 2,\n\u003e\n\u003e And on every tx bump, we decide whether to keep this scheme (mempool\n\u003e would enforce it always).\n\u003e\n\u003e Cheers,\n\u003e Rusty.\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/11660e06/attachment.html\u003e",
"sig": "77d0f1bcd38d539539d56c8ac6427131a654089e2a588fe00752ab346d996296fdd61611ffa114e229662cef23f5a2345668bfe8ba9d84fb511fc270cd5d535c"
}