📅 Original date posted:2017-04-20
📝 Original message:Since BIP 141's version bit assignment will timeout soon, and needing renewal,
I was thinking it might make sense to make some minor tweaks to the spec for
the next deployment. These aren't critical, so it's perfectly fine if BIP 141
activates as-is (potentially with BIP 148), but IMO would be an improvement if
a new deployment (non-BIP148 UASF and/or new versionbit) is needed.
1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity
with incomplete zero-input transactions, which has been a source of confusion
for raw transaction APIs. 0xFF would normally indicate a >32-bit input count,
which is impossible right now (it'd require a >=158 GB transaction) and
unlikely to ever be useful.
2. Relax the consensus rules on when witness data is allowed for an input.
Currently, it is only allowed when the scriptSig is null, and the scriptPubKey
being spent matches a very specific pattern. It is ignored by "upgrade-safe"
policy when the scriptPubKey doesn't match an even-more-specific pattern.
Instead, I suggest we allow it (in the consensus layer only) in combination
with scriptSig and with any scriptPubKey, and consider these cases to be
"upgrade-safe" policy ignoring.
The purpose of the second change is to be more flexible to any future
softforks. I consider it minor because we don't know of any possibilities
where it would actually be useful.
Thoughts?
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:00:32
in reply to nevent1q…qfty
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:00:32Event JSON
{
"id": "ac142179aef57f3214a0f6c21542cee985fd407a3d81d90ce6ee38a011796560",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160832,
"kind": 1,
"tags": [
[
"e",
"b2e271630ada747e7675f2dbedf7f4e89d042296cfe7851a4a9e00682faad187",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2017-04-20\n📝 Original message:Since BIP 141's version bit assignment will timeout soon, and needing renewal, \nI was thinking it might make sense to make some minor tweaks to the spec for \nthe next deployment. These aren't critical, so it's perfectly fine if BIP 141 \nactivates as-is (potentially with BIP 148), but IMO would be an improvement if \na new deployment (non-BIP148 UASF and/or new versionbit) is needed.\n\n1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity \nwith incomplete zero-input transactions, which has been a source of confusion \nfor raw transaction APIs. 0xFF would normally indicate a \u003e32-bit input count, \nwhich is impossible right now (it'd require a \u003e=158 GB transaction) and \nunlikely to ever be useful.\n\n2. Relax the consensus rules on when witness data is allowed for an input. \nCurrently, it is only allowed when the scriptSig is null, and the scriptPubKey \nbeing spent matches a very specific pattern. It is ignored by \"upgrade-safe\" \npolicy when the scriptPubKey doesn't match an even-more-specific pattern. \nInstead, I suggest we allow it (in the consensus layer only) in combination \nwith scriptSig and with any scriptPubKey, and consider these cases to be \n\"upgrade-safe\" policy ignoring.\n\nThe purpose of the second change is to be more flexible to any future \nsoftforks. I consider it minor because we don't know of any possibilities \nwhere it would actually be useful.\n\nThoughts?\n\nLuke",
"sig": "f5a3c19e6badc9facf49849a7a663093ebdc85265311b5a9b45d5649db75013eb4e4decad86f48a4411732b1032d8ccb14c6a5e4d2763a9e440a251d21f3851e"
}