📅 Original date posted:2015-08-08
📝 Original message:I think I have explained my motivation but let me try to make it
clearer.
For example, BIP62 says "scriptPubKey evaluation will be required to
result in a single non-zero value". If we had BIP62 before BIP16, P2SH
could not be done in the current form because BIP16 leaves more than one
element on the stake for non-upgrading nodes. BIP17 also violates BIP62.
BIP68 is "only enforced if the most significant bit of the sequence
number field is set.", so it is optional, anyway. All I do is to move
the flag from sequence number to version number.
The blocksize debate shows how a permanent softfork may cause trouble
later. We need to be very careful when doing further softforks, making
sure we will have enough flexibility for further development.
Mark Friedenbach 於 2015-08-08 14:56 寫到:
> It is not a bug that you are unable to selectively choose these
> features with higher version numbers. The version selection is in
> there at all because there is a possibility that there exists already
> signed transactions which would violate these new rules. We wouldn't
> want these transactions to become unspendable. However moving forward
> there is no reason to selectively pick and choose which of these new
> consensus rules you want to apply your transaction.
> On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> BIP68 rules and some of the BIP62 rules are applied only if the tx
>> version is >=2 and >=3 respectively. Therefore, it is not possible
>> to create a tx which follows BIP62 but not BIP68. If we introduce v4
>> tx later, BIP62 and BIP68 will all become mandatory.
>>
>> Some rules, e.g. "scriptPubKey evaluation will be required to
>> result in a single non-zero value" in BIP62, will cause trouble when
>> we try to introduce a new script system with softfork.
>>
>> I suggest to divide the tx version field into 2 parts: the higher 4
>> bits and lower 28 bits.
>>
>> BIP62 is active for a tx if its highest bits are 0000, and the
>> second lowest bit is 1.
>>
>> BIP68 is active for a tx if its highest bits are 0000, and the
>> third lowest bit is 1.
>>
>> So it will be easier for us to re-purpose the nSequence, or to take
>> advantage of malleability in the future. If this is adopted, the
>> nSequence high bit requirement in BIP68 becomes unnecessary as we
>> could easily switch it off.
>>
>> The low bits will allow 28 independent BIPs and should be ample for
>> many years. When they are exhausted, we can switch the high bits to
>> a different number (1-15) and redefine the meaning of low bits. By
>> that time, some of the 28 BIPs might have become obsoleted or could
>> be merged.
>>
>> (I'm not sure if there are other draft BIPs with similar
>> interpretation of tx version but the comments above should also
>> apply to them)
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 15:46:26
in reply to nevent1q…7tt8
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 15:46:26Event JSON
{
"id": "60e43b6c3ac895cdc8b69ce79f7e77dec2ade7da2c2d0ba1f222042fc0f9a455",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686152786,
"kind": 1,
"tags": [
[
"e",
"f06a7cd2747e31340564f810d490900f46bd451a618cf571ed926724a303532c",
"",
"root"
],
[
"e",
"ea2dce0907b2266e0d7072cc6d6d59d35cbcf6eeaf78210832fc6d5d4099326e",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-08-08\n📝 Original message:I think I have explained my motivation but let me try to make it \nclearer.\n\nFor example, BIP62 says \"scriptPubKey evaluation will be required to \nresult in a single non-zero value\". If we had BIP62 before BIP16, P2SH \ncould not be done in the current form because BIP16 leaves more than one \nelement on the stake for non-upgrading nodes. BIP17 also violates BIP62.\n\nBIP68 is \"only enforced if the most significant bit of the sequence \nnumber field is set.\", so it is optional, anyway. All I do is to move \nthe flag from sequence number to version number.\n\nThe blocksize debate shows how a permanent softfork may cause trouble \nlater. We need to be very careful when doing further softforks, making \nsure we will have enough flexibility for further development.\n\nMark Friedenbach 於 2015-08-08 14:56 寫到:\n\u003e It is not a bug that you are unable to selectively choose these\n\u003e features with higher version numbers. The version selection is in\n\u003e there at all because there is a possibility that there exists already\n\u003e signed transactions which would violate these new rules. We wouldn't\n\u003e want these transactions to become unspendable. However moving forward\n\u003e there is no reason to selectively pick and choose which of these new\n\u003e consensus rules you want to apply your transaction.\n\u003e On Aug 8, 2015 11:51 AM, \"jl2012 via bitcoin-dev\"\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e BIP68 rules and some of the BIP62 rules are applied only if the tx\n\u003e\u003e version is \u003e=2 and \u003e=3 respectively. Therefore, it is not possible\n\u003e\u003e to create a tx which follows BIP62 but not BIP68. If we introduce v4\n\u003e\u003e tx later, BIP62 and BIP68 will all become mandatory.\n\u003e\u003e \n\u003e\u003e Some rules, e.g. \"scriptPubKey evaluation will be required to\n\u003e\u003e result in a single non-zero value\" in BIP62, will cause trouble when\n\u003e\u003e we try to introduce a new script system with softfork.\n\u003e\u003e \n\u003e\u003e I suggest to divide the tx version field into 2 parts: the higher 4\n\u003e\u003e bits and lower 28 bits.\n\u003e\u003e \n\u003e\u003e BIP62 is active for a tx if its highest bits are 0000, and the\n\u003e\u003e second lowest bit is 1.\n\u003e\u003e \n\u003e\u003e BIP68 is active for a tx if its highest bits are 0000, and the\n\u003e\u003e third lowest bit is 1.\n\u003e\u003e \n\u003e\u003e So it will be easier for us to re-purpose the nSequence, or to take\n\u003e\u003e advantage of malleability in the future. If this is adopted, the\n\u003e\u003e nSequence high bit requirement in BIP68 becomes unnecessary as we\n\u003e\u003e could easily switch it off.\n\u003e\u003e \n\u003e\u003e The low bits will allow 28 independent BIPs and should be ample for\n\u003e\u003e many years. When they are exhausted, we can switch the high bits to\n\u003e\u003e a different number (1-15) and redefine the meaning of low bits. By\n\u003e\u003e that time, some of the 28 BIPs might have become obsoleted or could\n\u003e\u003e be merged.\n\u003e\u003e \n\u003e\u003e (I'm not sure if there are other draft BIPs with similar\n\u003e\u003e interpretation of tx version but the comments above should also\n\u003e\u003e apply to them)\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 [1]\n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "af71033de639ea8be554c47ce5d2a7dbd56dac4b52d669ed5115f3a4f8c75541a7700d0f71201f05dfb89e40f71579327e7b73b60d9b4e3d2dbadc5edbd19456"
}