* [bitcoin-dev] segwit naming ambiguity
@ 2023-08-11 4:45 Tobin Harding
2023-08-11 7:38 ` symphonicbtc
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Tobin Harding @ 2023-08-11 4:45 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] segwit naming ambiguity
2023-08-11 4:45 [bitcoin-dev] segwit naming ambiguity Tobin Harding
@ 2023-08-11 7:38 ` symphonicbtc
2023-08-11 7:49 ` Antoine Poinsot
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: symphonicbtc @ 2023-08-11 7:38 UTC (permalink / raw)
To: Tobin Harding, bitcoin-dev
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] segwit naming ambiguity
2023-08-11 4:45 [bitcoin-dev] segwit naming ambiguity Tobin Harding
2023-08-11 7:38 ` symphonicbtc
@ 2023-08-11 7:49 ` Antoine Poinsot
2023-08-11 10:06 ` Pavol Rusnak
2023-08-11 13:45 ` Andrew Poelstra
3 siblings, 0 replies; 5+ messages in thread
From: Antoine Poinsot @ 2023-08-11 7:49 UTC (permalink / raw)
To: Tobin Harding; +Cc: bitcoin-dev
Hey Tobin,
I would assume `is_segwit()` is true for P2TR, since Taproot is Segwit.
I'm not aware of a different term for "is P2WPKH or P2WSH" that "is Segwit v0". Maybe look into Murch's BIP about wording? He could have a better name for Segwit v0 there.
Cheers,
Antoine
------- Original Message -------
On Friday, August 11th, 2023 at 6:45 AM, Tobin Harding via bitcoin-dev <bitcoin-dev@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] segwit naming ambiguity
2023-08-11 4:45 [bitcoin-dev] segwit naming ambiguity Tobin Harding
2023-08-11 7:38 ` symphonicbtc
2023-08-11 7:49 ` Antoine Poinsot
@ 2023-08-11 10:06 ` Pavol Rusnak
2023-08-11 13:45 ` Andrew Poelstra
3 siblings, 0 replies; 5+ messages in thread
From: Pavol Rusnak @ 2023-08-11 10:06 UTC (permalink / raw)
To: Tobin Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
Here's my idea for a clean API:
1. `is_segwit()` returns true for a p2tr output
2. a function `segwit_version()` which returns an int according to segwit
version used
3. helper functions like `is_p2wpkh()`, `is_p2tr()`, `is_p2wsh()` for all
script types which all return a bool
On Fri, 11 Aug 2023 at 08:41, Tobin Harding via bitcoin-dev <
bitcoin-dev@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best Regards / S pozdravom,
Pavol "Stick" Rusnak
Co-Founder, SatoshiLabs
[-- Attachment #2: Type: text/html, Size: 1897 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] segwit naming ambiguity
2023-08-11 4:45 [bitcoin-dev] segwit naming ambiguity Tobin Harding
` (2 preceding siblings ...)
2023-08-11 10:06 ` Pavol Rusnak
@ 2023-08-11 13:45 ` Andrew Poelstra
3 siblings, 0 replies; 5+ messages in thread
From: Andrew Poelstra @ 2023-08-11 13:45 UTC (permalink / raw)
To: Tobin Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Fri, Aug 11, 2023 at 02:45:57PM +1000, Tobin Harding via bitcoin-dev 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?
>
As others have said, I think `is_segwit` should match all segwit
versions. Pavol also sorta answered your "widely used name" question
though he didn't draw attention to it -- segwit v0 outputs are called
"p2wsh" or "p2wpkh".
But I don't know any term that covers "p2wsh or p2wpkh but not p2tr".
Other than "segwit_v0", which we are currently using, and which I agree
is a bit of a mouthful.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-08-11 13:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-11 4:45 [bitcoin-dev] segwit naming ambiguity Tobin Harding
2023-08-11 7:38 ` symphonicbtc
2023-08-11 7:49 ` Antoine Poinsot
2023-08-11 10:06 ` Pavol Rusnak
2023-08-11 13:45 ` Andrew Poelstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox