📅 Original date posted:2023-08-11
🗒️ Summary of this message: The function "is_segwit()" should return true for transactions that match the witness program structure defined in BIP141, including both version 0 segwit outputs and version 1 taproot outputs. There should be a separate function for differentiating v0 vs taproot scripts, and consideration should be given to nested witness programs inside P2SH. The naming scheme for differentiating these programs should be clear and documented.
📝 Original message:
Transactions should be considered segwit if they match the witness program structure of "A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes" as defined in [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program). This would return true for version 0 segwit outputs as well as version 1 taproot outputs.
I would propose a different function for differentiating v0 vs taproot scripts. Bitcoin core uses an [enum](https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.h#L51), of which you can use something similar. Core also uses a different [enum](https://github.com/bitcoin/bitcoin/blob/master/src/outputtype.h) for wallet logic, but it has a highly confusing naming scheme which imo should be avoided.
Additionally, witness programs nested inside P2SH need to be considered. The context in which these are interpreted depends on whether or not they should be differentiated from other P2SH, as is shown with the 2 separate enums from core. It is possible that this would cause some ambiguity, and it should be explicitly documented how such functions would return for different types of programs. These nested programs should technically also be considered segwit for a simple `is_segwit`, as they have segregated witness data.
v0 is the most common way of referring to version 0 segwit.
Symphonic
------- Original Message -------
On Friday, August 11th, 2023 at 4:45 AM, Tobin Harding via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> Question for OG bitcoin API designers please.
>
> If you were to see the following function
>
> `is_segwit()`
>
> would you assume it returns `true` or `false` for a p2tr transaction?
>
> Currently we (rust-bitcoin) are being liberal with the use of `v0` but
> its a pretty ugly. Is there an official, or widely used, name for segwit v0?
>
> Thanks,
> Tobin.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
symphonicbtc [ARCHIVE] /
npub1tz…445mf
2023-08-12 09:56:45
in reply to nevent1q…vc0r
Author Public Key
npub1tzuhwyatcrnucyyk70tf5qk3tg9n2uu94pxq9744epejuuzqf5rqw445mfPublished at
2023-08-12 09:56:45Event JSON
{
"id": "101ec45f95909361dc22d7ec7788148f88cd09fd92cac3826799d9e53c4c8cf1",
"pubkey": "58b97713abc0e7cc1096f3d69a02d15a0b357385a84c02fab5c8732e70404d06",
"created_at": 1691834205,
"kind": 1,
"tags": [
[
"e",
"64ca1bd3fbb204c1049c0bc82688fa0a61c9ecff2f6316123a3f7b3f057b0127",
"",
"root"
],
[
"e",
"2ab07f5d13a27d92d4249589e2226c057e0c74e5f17123d2e844cac9e76e35e2",
"",
"reply"
],
[
"p",
"84b9f546d71d299f7ac093ade3da2a2a18c117c49f0462a856084d8f1a6422cb"
]
],
"content": "📅 Original date posted:2023-08-11\n🗒️ Summary of this message: The function \"is_segwit()\" should return true for transactions that match the witness program structure defined in BIP141, including both version 0 segwit outputs and version 1 taproot outputs. There should be a separate function for differentiating v0 vs taproot scripts, and consideration should be given to nested witness programs inside P2SH. The naming scheme for differentiating these programs should be clear and documented.\n📝 Original message:\nTransactions should be considered segwit if they match the witness program structure of \"A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes\" as defined in [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program). This would return true for version 0 segwit outputs as well as version 1 taproot outputs.\n\nI would propose a different function for differentiating v0 vs taproot scripts. Bitcoin core uses an [enum](https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.h#L51), of which you can use something similar. Core also uses a different [enum](https://github.com/bitcoin/bitcoin/blob/master/src/outputtype.h) for wallet logic, but it has a highly confusing naming scheme which imo should be avoided.\n\nAdditionally, witness programs nested inside P2SH need to be considered. The context in which these are interpreted depends on whether or not they should be differentiated from other P2SH, as is shown with the 2 separate enums from core. It is possible that this would cause some ambiguity, and it should be explicitly documented how such functions would return for different types of programs. These nested programs should technically also be considered segwit for a simple `is_segwit`, as they have segregated witness data.\n\nv0 is the most common way of referring to version 0 segwit.\n\nSymphonic\n\n\n------- Original Message -------\nOn Friday, August 11th, 2023 at 4:45 AM, Tobin Harding via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\n\u003e Question for OG bitcoin API designers please.\n\u003e\n\u003e If you were to see the following function\n\u003e\n\u003e `is_segwit()`\n\u003e\n\u003e would you assume it returns `true` or `false` for a p2tr transaction?\n\u003e\n\u003e Currently we (rust-bitcoin) are being liberal with the use of `v0` but\n\u003e its a pretty ugly. Is there an official, or widely used, name for segwit v0?\n\u003e\n\u003e Thanks,\n\u003e Tobin.\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",
"sig": "4713efe9f7c67b0036aad1dab19b51ed6a29362c1d4ce4cee16245bf7eb95001244d86323ee34e5c7f91822ecf88ee32881413c0bf265d77946caed3aab31585"
}