📅 Original date posted:2015-08-23
📝 Original message: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 )
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:35:00
in reply to nevent1q…nvjg
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:35:00Event JSON
{
"id": "bf751b82ec5fb3373a1c3a62a6d9e69e261161b17103bbb8b4341388c6a4a051",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159300,
"kind": 1,
"tags": [
[
"e",
"41b744fb00dece0ad755afb2bd169d7e5d2189a91240037a08b3b215596a998e",
"",
"root"
],
[
"e",
"42f9c383aefd05d0bd0ccec8bb0f969a2162150c45fc427872bd9fb309b7f95c",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-08-23\n📝 Original message:Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:\n\n\u003e \n\u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e discussion has any thought been given to represent one block with more\n\u003e than one increment? This would leave additional space for future\n\u003e signaling, or allow, for example, higher resolution numbers for a\n\u003e sharechain commitement.\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\nI think this comment is more related to BIP68 instead of OP_CSV? Without \nfurther complicating the BIP68, I believe the best way to leave room for \nimprovement is to spend a bit in tx nVersion to indicate the activation \nof BIP68. I have raised this issue before with \nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html \nHowever, it seems Mark isn't in favor of my proposal\n\nThe idea is not to permanently change the meaning of nSequence. \nActually, BIP68 is \"only enforced if the most significant bit of the \nsequence number field is set.\" So BIP68 is optional, anyway. All I \nsuggest is to move the flag from nSequence to nVersion. However, this \nwill leave much bigger room for using nSequence for other purpose in the \nfuture.\n\nAFAIK, nSequence is the only user definable and signed element in TxIn. \nThere could be more interesting use of this field and we should not \nchange its meaning permanently. (e.g. if nSequence had 8 bytes instead \nof 4 bytes, it could be used to indicate the value of the input to fix \nthis problem: https://bitcointalk.org/index.php?topic=181734.0 )",
"sig": "6202c57cd483a6b98a97cf6a69ae8bd888a98530ea4acbe070809f78b0a0962493109ac605193b0b5613c2ea787c7c13d162b144deb72eb05f55af429a5dbb6b"
}