📅 Original date posted:2015-08-23
📝 Original message:Sorry this was meant for the list:
There are only 32 bits in the version field. If you're going to spend a bit
for perpetuity to indicate whether or not a feature is active, you'd better
have a good reason to make that feature optional.
I haven't seen a compelling use case for having BIP 68 be optional in that
way. As you note, BIP 68 semantics is already optional by toggling the most
significant bit, and that doesn't permanently burn a version bit.
On Aug 23, 2015 7:41 PM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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, higher resolution numbers for a
>> sharechain commitement.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> I think this comment is more related to BIP68 instead of OP_CSV? Without
> further complicating the BIP68, I believe the best way to leave room for
> improvement is to spend a bit in tx nVersion to indicate the activation of
> BIP68. I have raised this issue before with
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
> However, it seems Mark isn't in favor of my proposal
>
> The idea is not to permanently change the meaning of nSequence. Actually,
> BIP68 is "only enforced if the most significant bit of the sequence number
> field is set." So BIP68 is optional, anyway. All I suggest is to move the
> flag from nSequence to nVersion. However, this will leave much bigger room
> for using nSequence for other purpose in the future.
>
> AFAIK, nSequence is the only user definable and signed element in TxIn.
> There could be more interesting use of this field and we should not change
> its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes,
> it could be used to indicate the value of the input to fix this problem:
> https://bitcointalk.org/index.php?topic=181734.0 )
>
> _______________________________________________
> 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/20150823/7192627d/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:46:53
in reply to nevent1q…fqda
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:46:53Event JSON
{
"id": "e4672b66175533a06f0046b47280375b305b34ce2b4d54e5827a958375a20367",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152813,
"kind": 1,
"tags": [
[
"e",
"6086ec24c7436956a4324b488abdb6aa06edbf1e682d11a0a5b70b6f8e62e6f3",
"",
"root"
],
[
"e",
"28ff79e456f917abbef1241be6ea3e3bf3e913a4542542646fcb10f7feaba984",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2015-08-23\n📝 Original message:Sorry this was meant for the list:\n\nThere are only 32 bits in the version field. If you're going to spend a bit\nfor perpetuity to indicate whether or not a feature is active, you'd better\nhave a good reason to make that feature optional.\n\nI haven't seen a compelling use case for having BIP 68 be optional in that\nway. As you note, BIP 68 semantics is already optional by toggling the most\nsignificant bit, and that doesn't permanently burn a version bit.\nOn Aug 23, 2015 7:41 PM, \"jl2012 via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:\n\u003e\n\u003e\n\u003e\u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e\u003e discussion has any thought been given to represent one block with more\n\u003e\u003e than one increment? This would leave additional space for future\n\u003e\u003e signaling, or allow, for example, higher resolution numbers for a\n\u003e\u003e sharechain commitement.\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 I think this comment is more related to BIP68 instead of OP_CSV? Without\n\u003e further complicating the BIP68, I believe the best way to leave room for\n\u003e improvement is to spend a bit in tx nVersion to indicate the activation of\n\u003e BIP68. I have raised this issue before with\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html\n\u003e However, it seems Mark isn't in favor of my proposal\n\u003e\n\u003e The idea is not to permanently change the meaning of nSequence. Actually,\n\u003e BIP68 is \"only enforced if the most significant bit of the sequence number\n\u003e field is set.\" So BIP68 is optional, anyway. All I suggest is to move the\n\u003e flag from nSequence to nVersion. However, this will leave much bigger room\n\u003e for using nSequence for other purpose in the future.\n\u003e\n\u003e AFAIK, nSequence is the only user definable and signed element in TxIn.\n\u003e There could be more interesting use of this field and we should not change\n\u003e its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes,\n\u003e it could be used to indicate the value of the input to fix this problem:\n\u003e https://bitcointalk.org/index.php?topic=181734.0 )\n\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/20150823/7192627d/attachment.html\u003e",
"sig": "6c4917f156c6e3e23b1e887c2d6b9cb6ef095f45e2754f83c49b2da9bf97491c9bba9b737b842a77994063b185f57fc96b5fc99f5b65a6f3ca9db9a86954bef7"
}