* [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH)
@ 2026-03-16 8:51 sashabeton
2026-03-16 11:12 ` Martin Habovštiak
2026-03-16 11:38 ` Saint Wenhao
0 siblings, 2 replies; 17+ messages in thread
From: sashabeton @ 2026-03-16 8:51 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2508 bytes --]
Hi everyone,
I'd like to propose a new native SegWit output type: Pay to Schnorr Key
Hash (P2SKH).
== The problem ==
The two most relevant output types today each solve half the problem:
- P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the
full 33-byte compressed public key in the witness (~108 witness bytes per
input).
- P2TR uses Schnorr signatures (64-byte witness), but embeds the full
32-byte x-only public key directly in the scriptPubKey, making outputs 12
bytes larger than P2WPKH and exposing the key in every unspent output.
Neither type achieves both a compact output and a compact witness
simultaneously.
== The proposal ==
P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as
P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification
works by key recovery: given the signature (R, s) and the challenge e =
TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier
recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the
program. The sighash reuses the BIP341 transaction digest, so cross-version
replay is prevented by the scriptPubKey commitment.
The result is the smallest combined footprint of any current single-key
output type — a 22-byte output with a 64-byte witness — while keeping the
public key off-chain until spending.
== Tradeoffs ==
The key-recovery step costs roughly one extra field inversion and scalar
multiplication compared to direct Schnorr verification. This is the price
of the 12-byte output size reduction.
== Open questions ==
1. BIP360 also claims witness version 2. If both proposals advance, one
needs to move. Version 3 seems like a natural alternative for P2SKH.
2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has been
suggested to emphasise Schnorr/taproot lineage. Opinions welcome.
Full draft:
https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md
PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826
Thanks in advance for any feedback.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2859 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 8:51 [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) sashabeton @ 2026-03-16 11:12 ` Martin Habovštiak 2026-03-16 11:43 ` Alex 2026-03-16 11:38 ` Saint Wenhao 1 sibling, 1 reply; 17+ messages in thread From: Martin Habovštiak @ 2026-03-16 11:12 UTC (permalink / raw) To: sashabeton; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3384 bytes --] Taproot specifically did not do this for good reasons that are well documented. I recommend you to read documentation first before attempting to make changes. Dňa po 16. 3. 2026, 11:48 sashabeton <sashabeton2007@gmail.com> napísal(a): > Hi everyone, > > I'd like to propose a new native SegWit output type: Pay to Schnorr Key > Hash (P2SKH). > > == The problem == > > The two most relevant output types today each solve half the problem: > - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the > full 33-byte compressed public key in the witness (~108 witness bytes per > input). > - P2TR uses Schnorr signatures (64-byte witness), but embeds the full > 32-byte x-only public key directly in the scriptPubKey, making outputs 12 > bytes larger than P2WPKH and exposing the key in every unspent output. > > Neither type achieves both a compact output and a compact witness > simultaneously. > > == The proposal == > > P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as > P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification > works by key recovery: given the signature (R, s) and the challenge e = > TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier > recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the > program. The sighash reuses the BIP341 transaction digest, so cross-version > replay is prevented by the scriptPubKey commitment. > > The result is the smallest combined footprint of any current single-key > output type — a 22-byte output with a 64-byte witness — while keeping the > public key off-chain until spending. > > == Tradeoffs == > > The key-recovery step costs roughly one extra field inversion and scalar > multiplication compared to direct Schnorr verification. This is the price > of the 12-byte output size reduction. > > == Open questions == > > 1. BIP360 also claims witness version 2. If both proposals advance, one > needs to move. Version 3 seems like a natural alternative for P2SKH. > 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has been > suggested to emphasise Schnorr/taproot lineage. Opinions welcome. > > Full draft: > https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md > PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 > > Thanks in advance for any feedback. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkCJbcUur0kao0%3DB2QQvQmM210O1TB_JkEkWLDqmzboqsN9Q%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4318 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 11:12 ` Martin Habovštiak @ 2026-03-16 11:43 ` Alex 2026-03-16 14:36 ` sashabeton 2026-03-16 15:43 ` Alex 0 siblings, 2 replies; 17+ messages in thread From: Alex @ 2026-03-16 11:43 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3757 bytes --] You are saving 12 bytes by removing all the scriptability, OP-code upgradeability and basically locking yourself to a non-quantum-secure key spend path that is only quantum secure if never spent? Or did I missunderstand? måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: > Taproot specifically did not do this for good reasons that are well > documented. I recommend you to read documentation first before attempting > to make changes. > > Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): > >> Hi everyone, >> >> I'd like to propose a new native SegWit output type: Pay to Schnorr Key >> Hash (P2SKH). >> >> == The problem == >> >> The two most relevant output types today each solve half the problem: >> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the >> full 33-byte compressed public key in the witness (~108 witness bytes per >> input). >> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >> bytes larger than P2WPKH and exposing the key in every unspent output. >> >> Neither type achieves both a compact output and a compact witness >> simultaneously. >> >> == The proposal == >> >> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >> works by key recovery: given the signature (R, s) and the challenge e = >> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >> program. The sighash reuses the BIP341 transaction digest, so cross-version >> replay is prevented by the scriptPubKey commitment. >> >> The result is the smallest combined footprint of any current single-key >> output type — a 22-byte output with a 64-byte witness — while keeping the >> public key off-chain until spending. >> >> == Tradeoffs == >> >> The key-recovery step costs roughly one extra field inversion and scalar >> multiplication compared to direct Schnorr verification. This is the price >> of the 12-byte output size reduction. >> >> == Open questions == >> >> 1. BIP360 also claims witness version 2. If both proposals advance, one >> needs to move. Version 3 seems like a natural alternative for P2SKH. >> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has been >> suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >> >> Full draft: >> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >> >> Thanks in advance for any feedback. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cc649b36-0ee1-4a87-b135-f5ad5a38b232n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 5752 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 11:43 ` Alex @ 2026-03-16 14:36 ` sashabeton 2026-03-16 15:57 ` Martin Habovštiak 2026-03-16 15:43 ` Alex 1 sibling, 1 reply; 17+ messages in thread From: sashabeton @ 2026-03-16 14:36 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 4949 bytes --] On scriptability and OP-code upgradeability: P2SKH is explicitly a single-key output type, the same as P2TR key-path spending. If you need Tapscript or OP-code upgradeability, you use P2TR. P2SKH targets the same use case as P2WPKH today: simple, high-volume payments where you have one key and no script conditions. In that use case P2TR key-path spending offers no scriptability either — this is not a new trade-off, it is the same one Taproot already made. On quantum security: the broader quantum-resistance question is legitimate, but it applies equally to all of Bitcoin's current output types. A proper solution requires a post-quantum signature scheme — a new cryptographic assumption. Until such a scheme is designed, reviewed, and adopted by the network (a multi-year process), there is value in keeping the 20-byte hashed address format that wallets and users already know, while gaining Schnorr efficiency. P2SKH offers exactly that bridge, without waiting for a problem the entire ecosystem has yet to solve. On Monday, 16 March 2026 at 12:57:52 UTC+1 Alex wrote: > You are saving 12 bytes by removing all the scriptability, OP-code > upgradeability and basically locking yourself to a non-quantum-secure key > spend path that is only quantum secure if never spent? Or did I > missunderstand? > > måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: > >> Taproot specifically did not do this for good reasons that are well >> documented. I recommend you to read documentation first before attempting >> to make changes. >> >> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >> >>> Hi everyone, >>> >>> I'd like to propose a new native SegWit output type: Pay to Schnorr Key >>> Hash (P2SKH). >>> >>> == The problem == >>> >>> The two most relevant output types today each solve half the problem: >>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the >>> full 33-byte compressed public key in the witness (~108 witness bytes per >>> input). >>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>> bytes larger than P2WPKH and exposing the key in every unspent output. >>> >>> Neither type achieves both a compact output and a compact witness >>> simultaneously. >>> >>> == The proposal == >>> >>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>> works by key recovery: given the signature (R, s) and the challenge e = >>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>> replay is prevented by the scriptPubKey commitment. >>> >>> The result is the smallest combined footprint of any current single-key >>> output type — a 22-byte output with a 64-byte witness — while keeping the >>> public key off-chain until spending. >>> >>> == Tradeoffs == >>> >>> The key-recovery step costs roughly one extra field inversion and scalar >>> multiplication compared to direct Schnorr verification. This is the price >>> of the 12-byte output size reduction. >>> >>> == Open questions == >>> >>> 1. BIP360 also claims witness version 2. If both proposals advance, one >>> needs to move. Version 3 seems like a natural alternative for P2SKH. >>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>> >>> Full draft: >>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>> >>> Thanks in advance for any feedback. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 7305 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 14:36 ` sashabeton @ 2026-03-16 15:57 ` Martin Habovštiak 0 siblings, 0 replies; 17+ messages in thread From: Martin Habovštiak @ 2026-03-16 15:57 UTC (permalink / raw) To: sashabeton; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 5976 bytes --] Takes ton of engineering effort just to undermine the privacy benefits of Taproot we've all been fighting for. Not worth it in my view. If you want to optimize transaction cost, focus on CISA instead. It has much greater potential than to save 12B per key. Just having two inputs in transaction already saves 64B. Dňa po 16. 3. 2026, 16:45 sashabeton <sashabeton2007@gmail.com> napísal(a): > On scriptability and OP-code upgradeability: P2SKH is explicitly a > single-key output type, the same as P2TR key-path spending. If you need > Tapscript or OP-code upgradeability, you use P2TR. P2SKH targets the same > use case as P2WPKH today: simple, high-volume payments where you have one > key and no script conditions. In that use case P2TR key-path spending > offers no scriptability either — this is not a new trade-off, it is the > same one Taproot already made. > On quantum security: the broader quantum-resistance question is > legitimate, but it applies equally to all of Bitcoin's current output > types. A proper solution requires a post-quantum signature scheme — a new > cryptographic assumption. Until such a scheme is designed, reviewed, and > adopted by the network (a multi-year process), there is value in keeping > the 20-byte hashed address format that wallets and users already know, > while gaining Schnorr efficiency. P2SKH offers exactly that bridge, without > waiting for a problem the entire ecosystem has yet to solve. > On Monday, 16 March 2026 at 12:57:52 UTC+1 Alex wrote: > >> You are saving 12 bytes by removing all the scriptability, OP-code >> upgradeability and basically locking yourself to a non-quantum-secure key >> spend path that is only quantum secure if never spent? Or did I >> missunderstand? >> >> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >> >>> Taproot specifically did not do this for good reasons that are well >>> documented. I recommend you to read documentation first before attempting >>> to make changes. >>> >>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >>> >>>> Hi everyone, >>>> >>>> I'd like to propose a new native SegWit output type: Pay to Schnorr Key >>>> Hash (P2SKH). >>>> >>>> == The problem == >>>> >>>> The two most relevant output types today each solve half the problem: >>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>> per input). >>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>> >>>> Neither type achieves both a compact output and a compact witness >>>> simultaneously. >>>> >>>> == The proposal == >>>> >>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>> works by key recovery: given the signature (R, s) and the challenge e = >>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>> replay is prevented by the scriptPubKey commitment. >>>> >>>> The result is the smallest combined footprint of any current single-key >>>> output type — a 22-byte output with a 64-byte witness — while keeping the >>>> public key off-chain until spending. >>>> >>>> == Tradeoffs == >>>> >>>> The key-recovery step costs roughly one extra field inversion and >>>> scalar multiplication compared to direct Schnorr verification. This is the >>>> price of the 12-byte output size reduction. >>>> >>>> == Open questions == >>>> >>>> 1. BIP360 also claims witness version 2. If both proposals advance, one >>>> needs to move. Version 3 seems like a natural alternative for P2SKH. >>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>> >>>> Full draft: >>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>> >>>> Thanks in advance for any feedback. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkCJZ0UgVGZ%3Du_Uq24E5L80KyEoysRS7ExphyajFe3oURcyw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 8073 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 11:43 ` Alex 2026-03-16 14:36 ` sashabeton @ 2026-03-16 15:43 ` Alex 2026-03-16 16:00 ` sashabeton 1 sibling, 1 reply; 17+ messages in thread From: Alex @ 2026-03-16 15:43 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 4835 bytes --] > In that use case P2TR key-path spending offers no scriptability either — this is not a new trade-off, it is the same one Taproot already made. This is not true. Taproot has 2 modes; its key-spend path is 12 bytes more bloated than your solution, yes. but Taproot can "dynamically" chose whether to use the key-spend path or the script-spend path. Your solution fully removes the script spend path, so you're not really optimizing an equally capable solution, you're optimizing for only 1 part of it. Removing scriptability for 12 bytes could possibly be warranted in some specific cases (I'm sure there are cases), but it's not a fair comparison against Taproot or BIP360. And since we will need quantum upgrade at some point, this upgrade is kind of (in my personal interpretation) doubling down to the part that will eventually break. Do you have any plan on how one could quantum secure the funds in P2SKH? måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: > You are saving 12 bytes by removing all the scriptability, OP-code > upgradeability and basically locking yourself to a non-quantum-secure key > spend path that is only quantum secure if never spent? Or did I > missunderstand? > > måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: > >> Taproot specifically did not do this for good reasons that are well >> documented. I recommend you to read documentation first before attempting >> to make changes. >> >> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >> >>> Hi everyone, >>> >>> I'd like to propose a new native SegWit output type: Pay to Schnorr Key >>> Hash (P2SKH). >>> >>> == The problem == >>> >>> The two most relevant output types today each solve half the problem: >>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the >>> full 33-byte compressed public key in the witness (~108 witness bytes per >>> input). >>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>> bytes larger than P2WPKH and exposing the key in every unspent output. >>> >>> Neither type achieves both a compact output and a compact witness >>> simultaneously. >>> >>> == The proposal == >>> >>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>> works by key recovery: given the signature (R, s) and the challenge e = >>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>> replay is prevented by the scriptPubKey commitment. >>> >>> The result is the smallest combined footprint of any current single-key >>> output type — a 22-byte output with a 64-byte witness — while keeping the >>> public key off-chain until spending. >>> >>> == Tradeoffs == >>> >>> The key-recovery step costs roughly one extra field inversion and scalar >>> multiplication compared to direct Schnorr verification. This is the price >>> of the 12-byte output size reduction. >>> >>> == Open questions == >>> >>> 1. BIP360 also claims witness version 2. If both proposals advance, one >>> needs to move. Version 3 seems like a natural alternative for P2SKH. >>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>> >>> Full draft: >>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>> >>> Thanks in advance for any feedback. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4df4b49e-f8f8-4d6f-b98f-7a4a27902800n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 7033 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 15:43 ` Alex @ 2026-03-16 16:00 ` sashabeton 2026-03-16 16:25 ` Martin Habovštiak ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: sashabeton @ 2026-03-16 16:00 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5957 bytes --] To clarify the design intent: P2SKH is not a stripped-down Taproot — it is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte hash commitment, no script path, single-key payments), and the only change is replacing ECDSA with the same Schnorr signature scheme Taproot's key-path uses. That's it. The goal is giving users who are already happy with the P2WPKH model (no script spending, simple single-key payments) the witness efficiency of Schnorr without forcing them onto a 34-byte output type designed for a richer feature set they don't need. P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, it relies on secp256k1 and will need to be migrated once post-quantum schemes are deployed in Bitcoin. But until that happens, it serves the same users as P2WPKH today, just more efficiently. When the time comes, users migrate — the same way P2PKH and P2WPKH users will have to. On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: > > In that use case P2TR key-path spending offers no scriptability either > — this is not a new trade-off, it is the same one Taproot already made. > > This is not true. Taproot has 2 modes; its key-spend path is 12 bytes more > bloated than your solution, yes. but Taproot can "dynamically" chose > whether to use the key-spend path or the script-spend path. Your solution > fully removes the script spend path, so you're not really optimizing an > equally capable solution, you're optimizing for only 1 part of it. > > Removing scriptability for 12 bytes could possibly be warranted in some > specific cases (I'm sure there are cases), but it's not a fair comparison > against Taproot or BIP360. And since we will need quantum upgrade at some > point, this upgrade is kind of (in my personal interpretation) doubling > down to the part that will eventually break. > > Do you have any plan on how one could quantum secure the funds in P2SKH? > måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: > >> You are saving 12 bytes by removing all the scriptability, OP-code >> upgradeability and basically locking yourself to a non-quantum-secure key >> spend path that is only quantum secure if never spent? Or did I >> missunderstand? >> >> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >> >>> Taproot specifically did not do this for good reasons that are well >>> documented. I recommend you to read documentation first before attempting >>> to make changes. >>> >>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >>> >>>> Hi everyone, >>>> >>>> I'd like to propose a new native SegWit output type: Pay to Schnorr Key >>>> Hash (P2SKH). >>>> >>>> == The problem == >>>> >>>> The two most relevant output types today each solve half the problem: >>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>> per input). >>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>> >>>> Neither type achieves both a compact output and a compact witness >>>> simultaneously. >>>> >>>> == The proposal == >>>> >>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>> works by key recovery: given the signature (R, s) and the challenge e = >>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>> replay is prevented by the scriptPubKey commitment. >>>> >>>> The result is the smallest combined footprint of any current single-key >>>> output type — a 22-byte output with a 64-byte witness — while keeping the >>>> public key off-chain until spending. >>>> >>>> == Tradeoffs == >>>> >>>> The key-recovery step costs roughly one extra field inversion and >>>> scalar multiplication compared to direct Schnorr verification. This is the >>>> price of the 12-byte output size reduction. >>>> >>>> == Open questions == >>>> >>>> 1. BIP360 also claims witness version 2. If both proposals advance, one >>>> needs to move. Version 3 seems like a natural alternative for P2SKH. >>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>> >>>> Full draft: >>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>> >>>> Thanks in advance for any feedback. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 8265 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 16:00 ` sashabeton @ 2026-03-16 16:25 ` Martin Habovštiak 2026-03-24 6:02 ` aaron.recompile 2026-03-16 19:29 ` Alex 2026-03-17 7:23 ` Saint Wenhao 2 siblings, 1 reply; 17+ messages in thread From: Martin Habovštiak @ 2026-03-16 16:25 UTC (permalink / raw) To: sashabeton; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7063 bytes --] It doesn't matter because it competes with Taproot and that is the problem. People should be migrating from old schemes to Taproot to maximize anonset of Taproot, not to $a_new_key_only_scheme or Taproot. Forcing users to use Taproot even if they don't need scripting is a desirable feature and intentional design from the beginning. 12B is justified cost for better privacy. Dňa po 16. 3. 2026, 17:12 sashabeton <sashabeton2007@gmail.com> napísal(a): > To clarify the design intent: P2SKH is not a stripped-down Taproot — it is > P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte > hash commitment, no script path, single-key payments), and the only change > is replacing ECDSA with the same Schnorr signature scheme Taproot's > key-path uses. That's it. > > The goal is giving users who are already happy with the P2WPKH model (no > script spending, simple single-key payments) the witness efficiency of > Schnorr without forcing them onto a 34-byte output type designed for a > richer feature set they don't need. > > P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, it > relies on secp256k1 and will need to be migrated once post-quantum schemes > are deployed in Bitcoin. But until that happens, it serves the same users > as P2WPKH today, just more efficiently. When the time comes, users migrate > — the same way P2PKH and P2WPKH users will have to. > > On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: > >> > In that use case P2TR key-path spending offers no scriptability >> either — this is not a new trade-off, it is the same one Taproot already >> made. >> >> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >> more bloated than your solution, yes. but Taproot can "dynamically" chose >> whether to use the key-spend path or the script-spend path. Your solution >> fully removes the script spend path, so you're not really optimizing an >> equally capable solution, you're optimizing for only 1 part of it. >> >> Removing scriptability for 12 bytes could possibly be warranted in some >> specific cases (I'm sure there are cases), but it's not a fair comparison >> against Taproot or BIP360. And since we will need quantum upgrade at some >> point, this upgrade is kind of (in my personal interpretation) doubling >> down to the part that will eventually break. >> >> Do you have any plan on how one could quantum secure the funds in P2SKH? >> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >> >>> You are saving 12 bytes by removing all the scriptability, OP-code >>> upgradeability and basically locking yourself to a non-quantum-secure key >>> spend path that is only quantum secure if never spent? Or did I >>> missunderstand? >>> >>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>> >>>> Taproot specifically did not do this for good reasons that are well >>>> documented. I recommend you to read documentation first before attempting >>>> to make changes. >>>> >>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >>>> >>>>> Hi everyone, >>>>> >>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>> Key Hash (P2SKH). >>>>> >>>>> == The problem == >>>>> >>>>> The two most relevant output types today each solve half the problem: >>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>> per input). >>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>>> >>>>> Neither type achieves both a compact output and a compact witness >>>>> simultaneously. >>>>> >>>>> == The proposal == >>>>> >>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>>> works by key recovery: given the signature (R, s) and the challenge e = >>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>>> replay is prevented by the scriptPubKey commitment. >>>>> >>>>> The result is the smallest combined footprint of any current >>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>> keeping the public key off-chain until spending. >>>>> >>>>> == Tradeoffs == >>>>> >>>>> The key-recovery step costs roughly one extra field inversion and >>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>> price of the 12-byte output size reduction. >>>>> >>>>> == Open questions == >>>>> >>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>> >>>>> Full draft: >>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>> >>>>> Thanks in advance for any feedback. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_N5AnekaqrG%3DNcnWy1zWUQHQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 9153 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 16:25 ` Martin Habovštiak @ 2026-03-24 6:02 ` aaron.recompile 0 siblings, 0 replies; 17+ messages in thread From: aaron.recompile @ 2026-03-24 6:02 UTC (permalink / raw) To: Martin Habovštiak; +Cc: sashabeton, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 8545 bytes --] Hi, A small observation on the script path objection. The issue seems to come from committing to P rather than to the Taproot output key Q. If instead: Q = P + H(P || merkle_root)·G (as in BIP341) scriptPubKey = OP_2 <hash160(x(Q))> then the Taproot commitment structure is preserved — script path works as in P2TR, key path uses recovery against Q. In other words, the loss of script path is not inherent to hashed-key outputs. It comes from hashing the wrong object. This doesn't address the broader concerns around hash security or deployment. But it might help clarify where the structural break actually is. Aaron Zhang On Mon, Mar 23, 2026 at 2:54 AM Martin Habovštiak < martin.habovstiak@gmail.com> wrote: > It doesn't matter because it competes with Taproot and that is the > problem. People should be migrating from old schemes to Taproot to maximize > anonset of Taproot, not to $a_new_key_only_scheme or Taproot. > > Forcing users to use Taproot even if they don't need scripting is a > desirable feature and intentional design from the beginning. 12B is > justified cost for better privacy. > > Dňa po 16. 3. 2026, 17:12 sashabeton <sashabeton2007@gmail.com> > napísal(a): > >> To clarify the design intent: P2SKH is not a stripped-down Taproot — it >> is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >> 20-byte hash commitment, no script path, single-key payments), and the only >> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >> key-path uses. That's it. >> >> The goal is giving users who are already happy with the P2WPKH model (no >> script spending, simple single-key payments) the witness efficiency of >> Schnorr without forcing them onto a 34-byte output type designed for a >> richer feature set they don't need. >> >> P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, >> it relies on secp256k1 and will need to be migrated once post-quantum >> schemes are deployed in Bitcoin. But until that happens, it serves the same >> users as P2WPKH today, just more efficiently. When the time comes, users >> migrate — the same way P2PKH and P2WPKH users will have to. >> >> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >> >>> > In that use case P2TR key-path spending offers no scriptability >>> either — this is not a new trade-off, it is the same one Taproot already >>> made. >>> >>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>> more bloated than your solution, yes. but Taproot can "dynamically" chose >>> whether to use the key-spend path or the script-spend path. Your solution >>> fully removes the script spend path, so you're not really optimizing an >>> equally capable solution, you're optimizing for only 1 part of it. >>> >>> Removing scriptability for 12 bytes could possibly be warranted in some >>> specific cases (I'm sure there are cases), but it's not a fair comparison >>> against Taproot or BIP360. And since we will need quantum upgrade at some >>> point, this upgrade is kind of (in my personal interpretation) doubling >>> down to the part that will eventually break. >>> >>> Do you have any plan on how one could quantum secure the funds in P2SKH? >>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>> >>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>> spend path that is only quantum secure if never spent? Or did I >>>> missunderstand? >>>> >>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>> >>>>> Taproot specifically did not do this for good reasons that are well >>>>> documented. I recommend you to read documentation first before attempting >>>>> to make changes. >>>>> >>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>> napísal(a): >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>>> Key Hash (P2SKH). >>>>>> >>>>>> == The problem == >>>>>> >>>>>> The two most relevant output types today each solve half the problem: >>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>>> per input). >>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>> >>>>>> Neither type achieves both a compact output and a compact witness >>>>>> simultaneously. >>>>>> >>>>>> == The proposal == >>>>>> >>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>>>> works by key recovery: given the signature (R, s) and the challenge e = >>>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>>>> replay is prevented by the scriptPubKey commitment. >>>>>> >>>>>> The result is the smallest combined footprint of any current >>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>> keeping the public key off-chain until spending. >>>>>> >>>>>> == Tradeoffs == >>>>>> >>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>> price of the 12-byte output size reduction. >>>>>> >>>>>> == Open questions == >>>>>> >>>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>> >>>>>> Full draft: >>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>> >>>>>> Thanks in advance for any feedback. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_N5AnekaqrG%3DNcnWy1zWUQHQ%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_N5AnekaqrG%3DNcnWy1zWUQHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEmKuUFxMi4NUMGrJTc-kMEJ0roS%2BrRP_OwyyNvaoFUP1vEzMA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 11057 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 16:00 ` sashabeton 2026-03-16 16:25 ` Martin Habovštiak @ 2026-03-16 19:29 ` Alex 2026-03-17 7:23 ` Saint Wenhao 2 siblings, 0 replies; 17+ messages in thread From: Alex @ 2026-03-16 19:29 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 6221 bytes --] Okay sorry, I got a bit hyper focused on the comparison with Taproot. måndag 16 mars 2026 kl. 17:12:33 UTC+1 skrev sashabeton: > To clarify the design intent: P2SKH is not a stripped-down Taproot — it is > P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte > hash commitment, no script path, single-key payments), and the only change > is replacing ECDSA with the same Schnorr signature scheme Taproot's > key-path uses. That's it. > > The goal is giving users who are already happy with the P2WPKH model (no > script spending, simple single-key payments) the witness efficiency of > Schnorr without forcing them onto a 34-byte output type designed for a > richer feature set they don't need. > > P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, it > relies on secp256k1 and will need to be migrated once post-quantum schemes > are deployed in Bitcoin. But until that happens, it serves the same users > as P2WPKH today, just more efficiently. When the time comes, users migrate > — the same way P2PKH and P2WPKH users will have to. > > On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: > >> > In that use case P2TR key-path spending offers no scriptability >> either — this is not a new trade-off, it is the same one Taproot already >> made. >> >> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >> more bloated than your solution, yes. but Taproot can "dynamically" chose >> whether to use the key-spend path or the script-spend path. Your solution >> fully removes the script spend path, so you're not really optimizing an >> equally capable solution, you're optimizing for only 1 part of it. >> >> Removing scriptability for 12 bytes could possibly be warranted in some >> specific cases (I'm sure there are cases), but it's not a fair comparison >> against Taproot or BIP360. And since we will need quantum upgrade at some >> point, this upgrade is kind of (in my personal interpretation) doubling >> down to the part that will eventually break. >> >> Do you have any plan on how one could quantum secure the funds in P2SKH? >> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >> >>> You are saving 12 bytes by removing all the scriptability, OP-code >>> upgradeability and basically locking yourself to a non-quantum-secure key >>> spend path that is only quantum secure if never spent? Or did I >>> missunderstand? >>> >>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>> >>>> Taproot specifically did not do this for good reasons that are well >>>> documented. I recommend you to read documentation first before attempting >>>> to make changes. >>>> >>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >>>> >>>>> Hi everyone, >>>>> >>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>> Key Hash (P2SKH). >>>>> >>>>> == The problem == >>>>> >>>>> The two most relevant output types today each solve half the problem: >>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>> per input). >>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>>> >>>>> Neither type achieves both a compact output and a compact witness >>>>> simultaneously. >>>>> >>>>> == The proposal == >>>>> >>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>>> works by key recovery: given the signature (R, s) and the challenge e = >>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>>> replay is prevented by the scriptPubKey commitment. >>>>> >>>>> The result is the smallest combined footprint of any current >>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>> keeping the public key off-chain until spending. >>>>> >>>>> == Tradeoffs == >>>>> >>>>> The key-recovery step costs roughly one extra field inversion and >>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>> price of the 12-byte output size reduction. >>>>> >>>>> == Open questions == >>>>> >>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>> >>>>> Full draft: >>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>> >>>>> Thanks in advance for any feedback. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cce91330-c897-471e-903a-5a3bea7c622dn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 8592 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 16:00 ` sashabeton 2026-03-16 16:25 ` Martin Habovštiak 2026-03-16 19:29 ` Alex @ 2026-03-17 7:23 ` Saint Wenhao 2026-03-17 7:40 ` sashabeton 2 siblings, 1 reply; 17+ messages in thread From: Saint Wenhao @ 2026-03-17 7:23 UTC (permalink / raw) To: sashabeton; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7713 bytes --] > The goal is giving users who are already happy with the P2WPKH model (no script spending, simple single-key payments) the witness efficiency of Schnorr If you have a DER signature, then it can take from 9 to 73 bytes. In Schnorr signatures, it is set to 64 or 65 bytes. In practice, you can have 71 bytes without grinding, which means, that by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, you will get 63 bytes in a DER signature. And that won't reveal your private key to anyone else. It would require around 2^33 operations, so it is doable on CPUs. Which means, that if you want to have smaller signatures, and you are willing to put some Proof of Work into that, then you will get better results by just staying with P2WPKH. And, as leading zeroes are not pushed in DER signatures, because of BIP-66, and as computing power is getting better and better, your signatures could be smaller in the future, while in Schnorr signatures, you won't have any way to go below 64 bytes. pon., 16 mar 2026 o 17:12 sashabeton <sashabeton2007@gmail.com> napisał(a): > To clarify the design intent: P2SKH is not a stripped-down Taproot — it is > P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte > hash commitment, no script path, single-key payments), and the only change > is replacing ECDSA with the same Schnorr signature scheme Taproot's > key-path uses. That's it. > > The goal is giving users who are already happy with the P2WPKH model (no > script spending, simple single-key payments) the witness efficiency of > Schnorr without forcing them onto a 34-byte output type designed for a > richer feature set they don't need. > > P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, it > relies on secp256k1 and will need to be migrated once post-quantum schemes > are deployed in Bitcoin. But until that happens, it serves the same users > as P2WPKH today, just more efficiently. When the time comes, users migrate > — the same way P2PKH and P2WPKH users will have to. > > On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: > >> > In that use case P2TR key-path spending offers no scriptability >> either — this is not a new trade-off, it is the same one Taproot already >> made. >> >> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >> more bloated than your solution, yes. but Taproot can "dynamically" chose >> whether to use the key-spend path or the script-spend path. Your solution >> fully removes the script spend path, so you're not really optimizing an >> equally capable solution, you're optimizing for only 1 part of it. >> >> Removing scriptability for 12 bytes could possibly be warranted in some >> specific cases (I'm sure there are cases), but it's not a fair comparison >> against Taproot or BIP360. And since we will need quantum upgrade at some >> point, this upgrade is kind of (in my personal interpretation) doubling >> down to the part that will eventually break. >> >> Do you have any plan on how one could quantum secure the funds in P2SKH? >> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >> >>> You are saving 12 bytes by removing all the scriptability, OP-code >>> upgradeability and basically locking yourself to a non-quantum-secure key >>> spend path that is only quantum secure if never spent? Or did I >>> missunderstand? >>> >>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>> >>>> Taproot specifically did not do this for good reasons that are well >>>> documented. I recommend you to read documentation first before attempting >>>> to make changes. >>>> >>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> napísal(a): >>>> >>>>> Hi everyone, >>>>> >>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>> Key Hash (P2SKH). >>>>> >>>>> == The problem == >>>>> >>>>> The two most relevant output types today each solve half the problem: >>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>> per input). >>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>>> >>>>> Neither type achieves both a compact output and a compact witness >>>>> simultaneously. >>>>> >>>>> == The proposal == >>>>> >>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>>> works by key recovery: given the signature (R, s) and the challenge e = >>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>>> replay is prevented by the scriptPubKey commitment. >>>>> >>>>> The result is the smallest combined footprint of any current >>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>> keeping the public key off-chain until spending. >>>>> >>>>> == Tradeoffs == >>>>> >>>>> The key-recovery step costs roughly one extra field inversion and >>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>> price of the 12-byte output size reduction. >>>>> >>>>> == Open questions == >>>>> >>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>> >>>>> Full draft: >>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>> >>>>> Thanks in advance for any feedback. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOJEDekgg_wA9AS2FHRB%3Dxp%3DwC2BdzD4hHK2rHXWvrZQ%3DA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 9749 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-17 7:23 ` Saint Wenhao @ 2026-03-17 7:40 ` sashabeton 2026-03-17 18:00 ` waxwing/ AdamISZ 0 siblings, 1 reply; 17+ messages in thread From: sashabeton @ 2026-03-17 7:40 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 8539 bytes --] Hi everyone, After reading all the feedback, I think it's time to accept that this proposal has no realistic path forward. For it to make sense, the new address type would need to be adopted by the entire ecosystem almost instantly — which is simply not going to happen. Honestly, this idea might have had better timing a few years ago. Today, the landscape has moved on, and I don't think pushing this further would be a good use of anyone's time. I want to thank everyone who took the time to read, review, and respond. On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: > > The goal is giving users who are already happy with the P2WPKH model (no > script spending, simple single-key payments) the witness efficiency of > Schnorr > > If you have a DER signature, then it can take from 9 to 73 bytes. In > Schnorr signatures, it is set to 64 or 65 bytes. > > In practice, you can have 71 bytes without grinding, which means, that by > using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, you > will get 63 bytes in a DER signature. And that won't reveal your private > key to anyone else. It would require around 2^33 operations, so it is > doable on CPUs. > > Which means, that if you want to have smaller signatures, and you are > willing to put some Proof of Work into that, then you will get better > results by just staying with P2WPKH. And, as leading zeroes are not pushed > in DER signatures, because of BIP-66, and as computing power is getting > better and better, your signatures could be smaller in the future, while in > Schnorr signatures, you won't have any way to go below 64 bytes. > > pon., 16 mar 2026 o 17:12 sashabeton <sashabe...@gmail.com> napisał(a): > >> To clarify the design intent: P2SKH is not a stripped-down Taproot — it >> is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >> 20-byte hash commitment, no script path, single-key payments), and the only >> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >> key-path uses. That's it. >> >> The goal is giving users who are already happy with the P2WPKH model (no >> script spending, simple single-key payments) the witness efficiency of >> Schnorr without forcing them onto a 34-byte output type designed for a >> richer feature set they don't need. >> >> P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, >> it relies on secp256k1 and will need to be migrated once post-quantum >> schemes are deployed in Bitcoin. But until that happens, it serves the same >> users as P2WPKH today, just more efficiently. When the time comes, users >> migrate — the same way P2PKH and P2WPKH users will have to. >> >> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >> >>> > In that use case P2TR key-path spending offers no scriptability >>> either — this is not a new trade-off, it is the same one Taproot already >>> made. >>> >>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>> more bloated than your solution, yes. but Taproot can "dynamically" chose >>> whether to use the key-spend path or the script-spend path. Your solution >>> fully removes the script spend path, so you're not really optimizing an >>> equally capable solution, you're optimizing for only 1 part of it. >>> >>> Removing scriptability for 12 bytes could possibly be warranted in some >>> specific cases (I'm sure there are cases), but it's not a fair comparison >>> against Taproot or BIP360. And since we will need quantum upgrade at some >>> point, this upgrade is kind of (in my personal interpretation) doubling >>> down to the part that will eventually break. >>> >>> Do you have any plan on how one could quantum secure the funds in P2SKH? >>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>> >>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>> spend path that is only quantum secure if never spent? Or did I >>>> missunderstand? >>>> >>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>> >>>>> Taproot specifically did not do this for good reasons that are well >>>>> documented. I recommend you to read documentation first before attempting >>>>> to make changes. >>>>> >>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>> napísal(a): >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>>> Key Hash (P2SKH). >>>>>> >>>>>> == The problem == >>>>>> >>>>>> The two most relevant output types today each solve half the problem: >>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>>> per input). >>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>>> 32-byte x-only public key directly in the scriptPubKey, making outputs 12 >>>>>> bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>> >>>>>> Neither type achieves both a compact output and a compact witness >>>>>> simultaneously. >>>>>> >>>>>> == The proposal == >>>>>> >>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as >>>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification >>>>>> works by key recovery: given the signature (R, s) and the challenge e = >>>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier >>>>>> recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the >>>>>> program. The sighash reuses the BIP341 transaction digest, so cross-version >>>>>> replay is prevented by the scriptPubKey commitment. >>>>>> >>>>>> The result is the smallest combined footprint of any current >>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>> keeping the public key off-chain until spending. >>>>>> >>>>>> == Tradeoffs == >>>>>> >>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>> price of the 12-byte output size reduction. >>>>>> >>>>>> == Open questions == >>>>>> >>>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>> >>>>>> Full draft: >>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>> >>>>>> Thanks in advance for any feedback. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/967d68e7-ba38-4e28-bc36-bf256a8c85a9n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 11768 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-17 7:40 ` sashabeton @ 2026-03-17 18:00 ` waxwing/ AdamISZ 2026-03-17 18:30 ` waxwing/ AdamISZ 0 siblings, 1 reply; 17+ messages in thread From: waxwing/ AdamISZ @ 2026-03-17 18:00 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 11023 bytes --] Hi sashabeton, > Honestly, this idea might have had better timing a few years ago. No I don't think so; it was discussed at the time (specifically, pubkey recovery). I remember bringing it up in the taproot review sessions on IRC. I'm sure others, including the taproot designers, discussed this issue well before I thought about it :) Perhaps this clarifies it for other mailing list readers: BIP340 Schnorr signatures are the form of Schnorr signature which has what is commonly termed "pubkey prefixing"; the challenge hash is e = H(R, P, m) with P the public key. This makes a pubkey recovery algorithm of the type that we have in our legacy ECDSA signatures, impossible. It's a point of not-only-historical interest that the original Schnorr signature design was H(R, m) not H(R, P, m) and that even around the time when ECDSA was being designed to avoid the Schnorr patent, and later, it was a point of considerable contention amongst various system designers, whether pubkey prefixing was needed or not. Pubkey prefixing makes all of the security reductions much more meaningful, since it can make the concept of "resistant to forgery" much more wide-ranging and powerful (in short, imagine the idea that you can make up a schnorr signature for some arbitrary key that wasn't used before .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that has big implications for perhaps the biggest application of Schnorr in Bitcoin, which is aggregation; aggregation in a bitcoin context means *aggregating arbitrary, new, ephemeral keys*, not keys previously recorded in some certificate registry or whatever. You're not going to get sensible versions of MuSig without pubkey prefixing, because you couldn't stop adversaries making up malicious keys that they don't have to commit to. Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, if you don't actually care about multisig for whatever reason; it could end up being very important for Bitcoin scaling anyway), Schnorr is a lot less of an upgrade to our signing algorithm (though to be fair, still not nothing, it's on sounder theoretical foundations). Cheers, AdamISZ/waxwing On Tuesday, March 17, 2026 at 6:32:12 AM UTC-3 sashabeton wrote: > Hi everyone, > > After reading all the feedback, I think it's time to accept that this > proposal has no realistic path forward. > > For it to make sense, the new address type would need to be adopted by the > entire ecosystem almost instantly — which is simply not going to happen. > > Honestly, this idea might have had better timing a few years ago. Today, > the landscape has moved on, and I don't think pushing this further would be > a good use of anyone's time. > > I want to thank everyone who took the time to read, review, and respond. > > On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: > >> > The goal is giving users who are already happy with the P2WPKH model >> (no script spending, simple single-key payments) the witness efficiency of >> Schnorr >> >> If you have a DER signature, then it can take from 9 to 73 bytes. In >> Schnorr signatures, it is set to 64 or 65 bytes. >> >> In practice, you can have 71 bytes without grinding, which means, that by >> using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, you >> will get 63 bytes in a DER signature. And that won't reveal your private >> key to anyone else. It would require around 2^33 operations, so it is >> doable on CPUs. >> >> Which means, that if you want to have smaller signatures, and you are >> willing to put some Proof of Work into that, then you will get better >> results by just staying with P2WPKH. And, as leading zeroes are not pushed >> in DER signatures, because of BIP-66, and as computing power is getting >> better and better, your signatures could be smaller in the future, while in >> Schnorr signatures, you won't have any way to go below 64 bytes. >> >> pon., 16 mar 2026 o 17:12 sashabeton <sashabe...@gmail.com> napisał(a): >> >>> To clarify the design intent: P2SKH is not a stripped-down Taproot — it >>> is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >>> 20-byte hash commitment, no script path, single-key payments), and the only >>> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >>> key-path uses. That's it. >>> >>> The goal is giving users who are already happy with the P2WPKH model (no >>> script spending, simple single-key payments) the witness efficiency of >>> Schnorr without forcing them onto a 34-byte output type designed for a >>> richer feature set they don't need. >>> >>> P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, >>> it relies on secp256k1 and will need to be migrated once post-quantum >>> schemes are deployed in Bitcoin. But until that happens, it serves the same >>> users as P2WPKH today, just more efficiently. When the time comes, users >>> migrate — the same way P2PKH and P2WPKH users will have to. >>> >>> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >>> >>>> > In that use case P2TR key-path spending offers no scriptability >>>> either — this is not a new trade-off, it is the same one Taproot already >>>> made. >>>> >>>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>>> more bloated than your solution, yes. but Taproot can "dynamically" chose >>>> whether to use the key-spend path or the script-spend path. Your solution >>>> fully removes the script spend path, so you're not really optimizing an >>>> equally capable solution, you're optimizing for only 1 part of it. >>>> >>>> Removing scriptability for 12 bytes could possibly be warranted in some >>>> specific cases (I'm sure there are cases), but it's not a fair comparison >>>> against Taproot or BIP360. And since we will need quantum upgrade at some >>>> point, this upgrade is kind of (in my personal interpretation) doubling >>>> down to the part that will eventually break. >>>> >>>> Do you have any plan on how one could quantum secure the funds in P2SKH? >>>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>>> >>>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>>> spend path that is only quantum secure if never spent? Or did I >>>>> missunderstand? >>>>> >>>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>>> >>>>>> Taproot specifically did not do this for good reasons that are well >>>>>> documented. I recommend you to read documentation first before attempting >>>>>> to make changes. >>>>>> >>>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>>> napísal(a): >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>>>> Key Hash (P2SKH). >>>>>>> >>>>>>> == The problem == >>>>>>> >>>>>>> The two most relevant output types today each solve half the problem: >>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts >>>>>>> the full 33-byte compressed public key in the witness (~108 witness bytes >>>>>>> per input). >>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the >>>>>>> full 32-byte x-only public key directly in the scriptPubKey, making outputs >>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>>> >>>>>>> Neither type achieves both a compact output and a compact witness >>>>>>> simultaneously. >>>>>>> >>>>>>> == The proposal == >>>>>>> >>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same >>>>>>> as P2WPKH). Spending requires a single 64-byte Schnorr signature. >>>>>>> Verification works by key recovery: given the signature (R, s) and the >>>>>>> challenge e = TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), >>>>>>> the verifier recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) >>>>>>> matches the program. The sighash reuses the BIP341 transaction digest, so >>>>>>> cross-version replay is prevented by the scriptPubKey commitment. >>>>>>> >>>>>>> The result is the smallest combined footprint of any current >>>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>>> keeping the public key off-chain until spending. >>>>>>> >>>>>>> == Tradeoffs == >>>>>>> >>>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>>> price of the 12-byte output size reduction. >>>>>>> >>>>>>> == Open questions == >>>>>>> >>>>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has >>>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>>> >>>>>>> Full draft: >>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>>> >>>>>>> Thanks in advance for any feedback. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >>> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/171b3d0e-e694-4ebc-9eeb-bb1917a9da69n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 14367 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-17 18:00 ` waxwing/ AdamISZ @ 2026-03-17 18:30 ` waxwing/ AdamISZ 2026-03-18 5:24 ` Saint Wenhao 0 siblings, 1 reply; 17+ messages in thread From: waxwing/ AdamISZ @ 2026-03-17 18:30 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 11658 bytes --] Hi sashabeton, Apologies - I didn't read your proposal carefully. You were of course in fact pubkey-prefixing here (with the hash-160 of P), so my entire saga about pubkey prefixing is not actually relevant! (maybe someone found it interesting tho' , lol). Cheers, AdamISZ/waxwing On Tuesday, March 17, 2026 at 3:00:50 PM UTC-3 waxwing/ AdamISZ wrote: > Hi sashabeton, > > > Honestly, this idea might have had better timing a few years ago. > > No I don't think so; it was discussed at the time (specifically, pubkey > recovery). I remember bringing it up in the taproot review sessions on IRC. > I'm sure others, including the taproot designers, discussed this issue well > before I thought about it :) > > Perhaps this clarifies it for other mailing list readers: > > BIP340 Schnorr signatures are the form of Schnorr signature which has what > is commonly termed "pubkey prefixing"; the challenge hash is e = H(R, P, m) > with P the public key. This makes a pubkey recovery algorithm of the type > that we have in our legacy ECDSA signatures, impossible. It's a point of > not-only-historical interest that the original Schnorr signature design was > H(R, m) not H(R, P, m) and that even around the time when ECDSA was being > designed to avoid the Schnorr patent, and later, it was a point of > considerable contention amongst various system designers, whether pubkey > prefixing was needed or not. > > Pubkey prefixing makes all of the security reductions much more > meaningful, since it can make the concept of "resistant to forgery" much > more wide-ranging and powerful (in short, imagine the idea that you can > make up a schnorr signature for some arbitrary key that wasn't used before > .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that has > big implications for perhaps the biggest application of Schnorr in Bitcoin, > which is aggregation; aggregation in a bitcoin context means *aggregating > arbitrary, new, ephemeral keys*, not keys previously recorded in some > certificate registry or whatever. You're not going to get sensible versions > of MuSig without pubkey prefixing, because you couldn't stop adversaries > making up malicious keys that they don't have to commit to. > > Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, if > you don't actually care about multisig for whatever reason; it could end up > being very important for Bitcoin scaling anyway), Schnorr is a lot less of > an upgrade to our signing algorithm (though to be fair, still not nothing, > it's on sounder theoretical foundations). > > Cheers, > AdamISZ/waxwing > > On Tuesday, March 17, 2026 at 6:32:12 AM UTC-3 sashabeton wrote: > >> Hi everyone, >> >> After reading all the feedback, I think it's time to accept that this >> proposal has no realistic path forward. >> >> For it to make sense, the new address type would need to be adopted by >> the entire ecosystem almost instantly — which is simply not going to happen. >> >> Honestly, this idea might have had better timing a few years ago. Today, >> the landscape has moved on, and I don't think pushing this further would be >> a good use of anyone's time. >> >> I want to thank everyone who took the time to read, review, and respond. >> >> On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: >> >>> > The goal is giving users who are already happy with the P2WPKH model >>> (no script spending, simple single-key payments) the witness efficiency of >>> Schnorr >>> >>> If you have a DER signature, then it can take from 9 to 73 bytes. In >>> Schnorr signatures, it is set to 64 or 65 bytes. >>> >>> In practice, you can have 71 bytes without grinding, which means, that >>> by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, >>> you will get 63 bytes in a DER signature. And that won't reveal your >>> private key to anyone else. It would require around 2^33 operations, so it >>> is doable on CPUs. >>> >>> Which means, that if you want to have smaller signatures, and you are >>> willing to put some Proof of Work into that, then you will get better >>> results by just staying with P2WPKH. And, as leading zeroes are not pushed >>> in DER signatures, because of BIP-66, and as computing power is getting >>> better and better, your signatures could be smaller in the future, while in >>> Schnorr signatures, you won't have any way to go below 64 bytes. >>> >>> pon., 16 mar 2026 o 17:12 sashabeton <sashabe...@gmail.com> napisał(a): >>> >>>> To clarify the design intent: P2SKH is not a stripped-down Taproot — it >>>> is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >>>> 20-byte hash commitment, no script path, single-key payments), and the only >>>> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >>>> key-path uses. That's it. >>>> >>>> The goal is giving users who are already happy with the P2WPKH model >>>> (no script spending, simple single-key payments) the witness efficiency of >>>> Schnorr without forcing them onto a 34-byte output type designed for a >>>> richer feature set they don't need. >>>> >>>> P2SKH is not quantum-resistant — I fully acknowledge this. Like P2WPKH, >>>> it relies on secp256k1 and will need to be migrated once post-quantum >>>> schemes are deployed in Bitcoin. But until that happens, it serves the same >>>> users as P2WPKH today, just more efficiently. When the time comes, users >>>> migrate — the same way P2PKH and P2WPKH users will have to. >>>> >>>> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >>>> >>>>> > In that use case P2TR key-path spending offers no scriptability >>>>> either — this is not a new trade-off, it is the same one Taproot already >>>>> made. >>>>> >>>>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>>>> more bloated than your solution, yes. but Taproot can "dynamically" chose >>>>> whether to use the key-spend path or the script-spend path. Your solution >>>>> fully removes the script spend path, so you're not really optimizing an >>>>> equally capable solution, you're optimizing for only 1 part of it. >>>>> >>>>> Removing scriptability for 12 bytes could possibly be warranted in >>>>> some specific cases (I'm sure there are cases), but it's not a fair >>>>> comparison against Taproot or BIP360. And since we will need quantum >>>>> upgrade at some point, this upgrade is kind of (in my personal >>>>> interpretation) doubling down to the part that will eventually break. >>>>> >>>>> Do you have any plan on how one could quantum secure the funds in >>>>> P2SKH? >>>>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>>>> >>>>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>>>> spend path that is only quantum secure if never spent? Or did I >>>>>> missunderstand? >>>>>> >>>>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>>>> >>>>>>> Taproot specifically did not do this for good reasons that are well >>>>>>> documented. I recommend you to read documentation first before attempting >>>>>>> to make changes. >>>>>>> >>>>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>>>> napísal(a): >>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr >>>>>>>> Key Hash (P2SKH). >>>>>>>> >>>>>>>> == The problem == >>>>>>>> >>>>>>>> The two most relevant output types today each solve half the >>>>>>>> problem: >>>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and >>>>>>>> puts the full 33-byte compressed public key in the witness (~108 witness >>>>>>>> bytes per input). >>>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the >>>>>>>> full 32-byte x-only public key directly in the scriptPubKey, making outputs >>>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>>>> >>>>>>>> Neither type achieves both a compact output and a compact witness >>>>>>>> simultaneously. >>>>>>>> >>>>>>>> == The proposal == >>>>>>>> >>>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same >>>>>>>> as P2WPKH). Spending requires a single 64-byte Schnorr signature. >>>>>>>> Verification works by key recovery: given the signature (R, s) and the >>>>>>>> challenge e = TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), >>>>>>>> the verifier recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) >>>>>>>> matches the program. The sighash reuses the BIP341 transaction digest, so >>>>>>>> cross-version replay is prevented by the scriptPubKey commitment. >>>>>>>> >>>>>>>> The result is the smallest combined footprint of any current >>>>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>>>> keeping the public key off-chain until spending. >>>>>>>> >>>>>>>> == Tradeoffs == >>>>>>>> >>>>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>>>> price of the 12-byte output size reduction. >>>>>>>> >>>>>>>> == Open questions == >>>>>>>> >>>>>>>> 1. BIP360 also claims witness version 2. If both proposals advance, >>>>>>>> one needs to move. Version 3 seems like a natural alternative for P2SKH. >>>>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" >>>>>>>> has been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>>>> >>>>>>>> Full draft: >>>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>>>> >>>>>>>> Thanks in advance for any feedback. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 15071 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-17 18:30 ` waxwing/ AdamISZ @ 2026-03-18 5:24 ` Saint Wenhao 2026-03-18 15:50 ` "wrapped Taproot" from RIPEMD-160 collisions, Was: " Ethan Heilman 0 siblings, 1 reply; 17+ messages in thread From: Saint Wenhao @ 2026-03-18 5:24 UTC (permalink / raw) To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 13322 bytes --] > You were of course in fact pubkey-prefixing here (with the hash-160 of P) Yes, I also thought about that. But then, it means after around 2^80 operations, you could have a potential RIPEMD-160 collision in the future. Which also means, that 160-bit hashes may be later unsafe anyway. And if you pick 256-bit ones, then putting x-value pubkey gives the same size. Also, I wonder if collisions in P2SH will be used as a "wrapped Taproot". Because then, instead of building some MAST, it could be possible to simply prepare a collision, and use older addresses in that way. Then, Alice can for example use "<pubkeyA> OP_CHECKSIG", and Bob can use "<time> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkeyB> OP_CHECKSIG". If applying HASH160 to both scripts will give the same 160-bit value, then each party could use a different Script, to spend coins from the same P2SH address. wt., 17 mar 2026 o 20:01 waxwing/ AdamISZ <ekaggata@gmail.com> napisał(a): > Hi sashabeton, > > Apologies - I didn't read your proposal carefully. You were of course in > fact pubkey-prefixing here (with the hash-160 of P), so my entire saga > about pubkey prefixing is not actually relevant! > > (maybe someone found it interesting tho' , lol). > > Cheers, > AdamISZ/waxwing > > On Tuesday, March 17, 2026 at 3:00:50 PM UTC-3 waxwing/ AdamISZ wrote: > >> Hi sashabeton, >> >> > Honestly, this idea might have had better timing a few years ago. >> >> No I don't think so; it was discussed at the time (specifically, pubkey >> recovery). I remember bringing it up in the taproot review sessions on IRC. >> I'm sure others, including the taproot designers, discussed this issue well >> before I thought about it :) >> >> Perhaps this clarifies it for other mailing list readers: >> >> BIP340 Schnorr signatures are the form of Schnorr signature which has >> what is commonly termed "pubkey prefixing"; the challenge hash is e = H(R, >> P, m) with P the public key. This makes a pubkey recovery algorithm of the >> type that we have in our legacy ECDSA signatures, impossible. It's a point >> of not-only-historical interest that the original Schnorr signature design >> was H(R, m) not H(R, P, m) and that even around the time when ECDSA was >> being designed to avoid the Schnorr patent, and later, it was a point of >> considerable contention amongst various system designers, whether pubkey >> prefixing was needed or not. >> >> Pubkey prefixing makes all of the security reductions much more >> meaningful, since it can make the concept of "resistant to forgery" much >> more wide-ranging and powerful (in short, imagine the idea that you can >> make up a schnorr signature for some arbitrary key that wasn't used before >> .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that has >> big implications for perhaps the biggest application of Schnorr in Bitcoin, >> which is aggregation; aggregation in a bitcoin context means *aggregating >> arbitrary, new, ephemeral keys*, not keys previously recorded in some >> certificate registry or whatever. You're not going to get sensible versions >> of MuSig without pubkey prefixing, because you couldn't stop adversaries >> making up malicious keys that they don't have to commit to. >> >> Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, >> if you don't actually care about multisig for whatever reason; it could end >> up being very important for Bitcoin scaling anyway), Schnorr is a lot less >> of an upgrade to our signing algorithm (though to be fair, still not >> nothing, it's on sounder theoretical foundations). >> >> Cheers, >> AdamISZ/waxwing >> >> On Tuesday, March 17, 2026 at 6:32:12 AM UTC-3 sashabeton wrote: >> >>> Hi everyone, >>> >>> After reading all the feedback, I think it's time to accept that this >>> proposal has no realistic path forward. >>> >>> For it to make sense, the new address type would need to be adopted by >>> the entire ecosystem almost instantly — which is simply not going to happen. >>> >>> Honestly, this idea might have had better timing a few years ago. Today, >>> the landscape has moved on, and I don't think pushing this further would be >>> a good use of anyone's time. >>> >>> I want to thank everyone who took the time to read, review, and respond. >>> >>> On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: >>> >>>> > The goal is giving users who are already happy with the P2WPKH model >>>> (no script spending, simple single-key payments) the witness efficiency of >>>> Schnorr >>>> >>>> If you have a DER signature, then it can take from 9 to 73 bytes. In >>>> Schnorr signatures, it is set to 64 or 65 bytes. >>>> >>>> In practice, you can have 71 bytes without grinding, which means, that >>>> by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, >>>> you will get 63 bytes in a DER signature. And that won't reveal your >>>> private key to anyone else. It would require around 2^33 operations, so it >>>> is doable on CPUs. >>>> >>>> Which means, that if you want to have smaller signatures, and you are >>>> willing to put some Proof of Work into that, then you will get better >>>> results by just staying with P2WPKH. And, as leading zeroes are not pushed >>>> in DER signatures, because of BIP-66, and as computing power is getting >>>> better and better, your signatures could be smaller in the future, while in >>>> Schnorr signatures, you won't have any way to go below 64 bytes. >>>> >>>> pon., 16 mar 2026 o 17:12 sashabeton <sashabe...@gmail.com> napisał(a): >>>> >>>>> To clarify the design intent: P2SKH is not a stripped-down Taproot — >>>>> it is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >>>>> 20-byte hash commitment, no script path, single-key payments), and the only >>>>> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >>>>> key-path uses. That's it. >>>>> >>>>> The goal is giving users who are already happy with the P2WPKH model >>>>> (no script spending, simple single-key payments) the witness efficiency of >>>>> Schnorr without forcing them onto a 34-byte output type designed for a >>>>> richer feature set they don't need. >>>>> >>>>> P2SKH is not quantum-resistant — I fully acknowledge this. Like >>>>> P2WPKH, it relies on secp256k1 and will need to be migrated once >>>>> post-quantum schemes are deployed in Bitcoin. But until that happens, it >>>>> serves the same users as P2WPKH today, just more efficiently. When the time >>>>> comes, users migrate — the same way P2PKH and P2WPKH users will have to. >>>>> >>>>> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >>>>> >>>>>> > In that use case P2TR key-path spending offers no scriptability >>>>>> either — this is not a new trade-off, it is the same one Taproot already >>>>>> made. >>>>>> >>>>>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>>>>> more bloated than your solution, yes. but Taproot can "dynamically" chose >>>>>> whether to use the key-spend path or the script-spend path. Your solution >>>>>> fully removes the script spend path, so you're not really optimizing an >>>>>> equally capable solution, you're optimizing for only 1 part of it. >>>>>> >>>>>> Removing scriptability for 12 bytes could possibly be warranted in >>>>>> some specific cases (I'm sure there are cases), but it's not a fair >>>>>> comparison against Taproot or BIP360. And since we will need quantum >>>>>> upgrade at some point, this upgrade is kind of (in my personal >>>>>> interpretation) doubling down to the part that will eventually break. >>>>>> >>>>>> Do you have any plan on how one could quantum secure the funds in >>>>>> P2SKH? >>>>>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>>>>> >>>>>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>>>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>>>>> spend path that is only quantum secure if never spent? Or did I >>>>>>> missunderstand? >>>>>>> >>>>>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>>>>> >>>>>>>> Taproot specifically did not do this for good reasons that are well >>>>>>>> documented. I recommend you to read documentation first before attempting >>>>>>>> to make changes. >>>>>>>> >>>>>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>>>>> napísal(a): >>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I'd like to propose a new native SegWit output type: Pay to >>>>>>>>> Schnorr Key Hash (P2SKH). >>>>>>>>> >>>>>>>>> == The problem == >>>>>>>>> >>>>>>>>> The two most relevant output types today each solve half the >>>>>>>>> problem: >>>>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and >>>>>>>>> puts the full 33-byte compressed public key in the witness (~108 witness >>>>>>>>> bytes per input). >>>>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the >>>>>>>>> full 32-byte x-only public key directly in the scriptPubKey, making outputs >>>>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>>>>> >>>>>>>>> Neither type achieves both a compact output and a compact witness >>>>>>>>> simultaneously. >>>>>>>>> >>>>>>>>> == The proposal == >>>>>>>>> >>>>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same >>>>>>>>> as P2WPKH). Spending requires a single 64-byte Schnorr signature. >>>>>>>>> Verification works by key recovery: given the signature (R, s) and the >>>>>>>>> challenge e = TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), >>>>>>>>> the verifier recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) >>>>>>>>> matches the program. The sighash reuses the BIP341 transaction digest, so >>>>>>>>> cross-version replay is prevented by the scriptPubKey commitment. >>>>>>>>> >>>>>>>>> The result is the smallest combined footprint of any current >>>>>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>>>>> keeping the public key off-chain until spending. >>>>>>>>> >>>>>>>>> == Tradeoffs == >>>>>>>>> >>>>>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>>>>> price of the 12-byte output size reduction. >>>>>>>>> >>>>>>>>> == Open questions == >>>>>>>>> >>>>>>>>> 1. BIP360 also claims witness version 2. If both proposals >>>>>>>>> advance, one needs to move. Version 3 seems like a natural alternative for >>>>>>>>> P2SKH. >>>>>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" >>>>>>>>> has been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>>>>> >>>>>>>>> Full draft: >>>>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>>>>> >>>>>>>>> Thanks in advance for any feedback. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 16102 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* "wrapped Taproot" from RIPEMD-160 collisions, Was: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-18 5:24 ` Saint Wenhao @ 2026-03-18 15:50 ` Ethan Heilman 0 siblings, 0 replies; 17+ messages in thread From: Ethan Heilman @ 2026-03-18 15:50 UTC (permalink / raw) To: Saint Wenhao; +Cc: waxwing/ AdamISZ, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 15763 bytes --] Saint Wenhao, > Also, I wonder if collisions in P2SH will be used as a "wrapped Taproot". I love this idea. The cost to so this is about 2^81 not 2^80. You aren't trying to find any collision, you are trying to find a collision for Alice's script and Bob's script. If you a giant lookup table of 2^80 Alice Script hashes, you could try Bob Script hashes until one collides with this lookup table. This should be an additional 2^79.5 work. This means with more storage existing on the planet you can do this in 2^80.5 calls, assuming HASH-160 has no cryptanalytic weaknesses that make collisions easier. This lookup table would be absurdly huge: 2^80 * (20+12) bytes = 2^45 terabytes = ~100 trillion 1 TB harddrives You can use time-memory tradeoffs here. In fact this is the same hash collision problem that colliderscript deals with. See ColliderScript: Covenants in Bitcoin via 160-bit hash collisions https://eprint.iacr.org/2024/1802.pdf appendix E and F in the CollidierScript paper for equations you can use to find an exact value. Using the more realistic memory assumptions from ColliderScript, you could probably get it down to approx, ~2^81 hash queries and 2^56 storage (~4096 1TB harddrives). Assuming you built an ASICs for this, it would cost between $100,000 and $2 million in electricity per collision. This is much cheaper than the cost for colliderscript because colliderscript must account for some other parameters that don't matter here. On Wed, Mar 18, 2026 at 6:18 AM Saint Wenhao <saintwenhao@gmail.com> wrote: > > You were of course in fact pubkey-prefixing here (with the hash-160 of P) > > Yes, I also thought about that. But then, it means after around 2^80 > operations, you could have a potential RIPEMD-160 collision in the future. > Which also means, that 160-bit hashes may be later unsafe anyway. And if > you pick 256-bit ones, then putting x-value pubkey gives the same size. > > Also, I wonder if collisions in P2SH will be used as a "wrapped Taproot". > Because then, instead of building some MAST, it could be possible to simply > prepare a collision, and use older addresses in that way. Then, Alice can > for example use "<pubkeyA> OP_CHECKSIG", and Bob can use "<time> > OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkeyB> OP_CHECKSIG". If applying HASH160 > to both scripts will give the same 160-bit value, then each party could use > a different Script, to spend coins from the same P2SH address. > > wt., 17 mar 2026 o 20:01 waxwing/ AdamISZ <ekaggata@gmail.com> napisał(a): > >> Hi sashabeton, >> >> Apologies - I didn't read your proposal carefully. You were of course in >> fact pubkey-prefixing here (with the hash-160 of P), so my entire saga >> about pubkey prefixing is not actually relevant! >> >> (maybe someone found it interesting tho' , lol). >> >> Cheers, >> AdamISZ/waxwing >> >> On Tuesday, March 17, 2026 at 3:00:50 PM UTC-3 waxwing/ AdamISZ wrote: >> >>> Hi sashabeton, >>> >>> > Honestly, this idea might have had better timing a few years ago. >>> >>> No I don't think so; it was discussed at the time (specifically, pubkey >>> recovery). I remember bringing it up in the taproot review sessions on IRC. >>> I'm sure others, including the taproot designers, discussed this issue well >>> before I thought about it :) >>> >>> Perhaps this clarifies it for other mailing list readers: >>> >>> BIP340 Schnorr signatures are the form of Schnorr signature which has >>> what is commonly termed "pubkey prefixing"; the challenge hash is e = H(R, >>> P, m) with P the public key. This makes a pubkey recovery algorithm of the >>> type that we have in our legacy ECDSA signatures, impossible. It's a point >>> of not-only-historical interest that the original Schnorr signature design >>> was H(R, m) not H(R, P, m) and that even around the time when ECDSA was >>> being designed to avoid the Schnorr patent, and later, it was a point of >>> considerable contention amongst various system designers, whether pubkey >>> prefixing was needed or not. >>> >>> Pubkey prefixing makes all of the security reductions much more >>> meaningful, since it can make the concept of "resistant to forgery" much >>> more wide-ranging and powerful (in short, imagine the idea that you can >>> make up a schnorr signature for some arbitrary key that wasn't used before >>> .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that has >>> big implications for perhaps the biggest application of Schnorr in Bitcoin, >>> which is aggregation; aggregation in a bitcoin context means *aggregating >>> arbitrary, new, ephemeral keys*, not keys previously recorded in some >>> certificate registry or whatever. You're not going to get sensible versions >>> of MuSig without pubkey prefixing, because you couldn't stop adversaries >>> making up malicious keys that they don't have to commit to. >>> >>> Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, >>> if you don't actually care about multisig for whatever reason; it could end >>> up being very important for Bitcoin scaling anyway), Schnorr is a lot less >>> of an upgrade to our signing algorithm (though to be fair, still not >>> nothing, it's on sounder theoretical foundations). >>> >>> Cheers, >>> AdamISZ/waxwing >>> >>> On Tuesday, March 17, 2026 at 6:32:12 AM UTC-3 sashabeton wrote: >>> >>>> Hi everyone, >>>> >>>> After reading all the feedback, I think it's time to accept that this >>>> proposal has no realistic path forward. >>>> >>>> For it to make sense, the new address type would need to be adopted by >>>> the entire ecosystem almost instantly — which is simply not going to happen. >>>> >>>> Honestly, this idea might have had better timing a few years ago. >>>> Today, the landscape has moved on, and I don't think pushing this further >>>> would be a good use of anyone's time. >>>> >>>> I want to thank everyone who took the time to read, review, and respond. >>>> >>>> On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: >>>> >>>>> > The goal is giving users who are already happy with the P2WPKH model >>>>> (no script spending, simple single-key payments) the witness efficiency of >>>>> Schnorr >>>>> >>>>> If you have a DER signature, then it can take from 9 to 73 bytes. In >>>>> Schnorr signatures, it is set to 64 or 65 bytes. >>>>> >>>>> In practice, you can have 71 bytes without grinding, which means, that >>>>> by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, >>>>> you will get 63 bytes in a DER signature. And that won't reveal your >>>>> private key to anyone else. It would require around 2^33 operations, so it >>>>> is doable on CPUs. >>>>> >>>>> Which means, that if you want to have smaller signatures, and you are >>>>> willing to put some Proof of Work into that, then you will get better >>>>> results by just staying with P2WPKH. And, as leading zeroes are not pushed >>>>> in DER signatures, because of BIP-66, and as computing power is getting >>>>> better and better, your signatures could be smaller in the future, while in >>>>> Schnorr signatures, you won't have any way to go below 64 bytes. >>>>> >>>>> pon., 16 mar 2026 o 17:12 sashabeton <sashabe...@gmail.com> >>>>> napisał(a): >>>>> >>>>>> To clarify the design intent: P2SKH is not a stripped-down Taproot — >>>>>> it is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact >>>>>> 20-byte hash commitment, no script path, single-key payments), and the only >>>>>> change is replacing ECDSA with the same Schnorr signature scheme Taproot's >>>>>> key-path uses. That's it. >>>>>> >>>>>> The goal is giving users who are already happy with the P2WPKH model >>>>>> (no script spending, simple single-key payments) the witness efficiency of >>>>>> Schnorr without forcing them onto a 34-byte output type designed for a >>>>>> richer feature set they don't need. >>>>>> >>>>>> P2SKH is not quantum-resistant — I fully acknowledge this. Like >>>>>> P2WPKH, it relies on secp256k1 and will need to be migrated once >>>>>> post-quantum schemes are deployed in Bitcoin. But until that happens, it >>>>>> serves the same users as P2WPKH today, just more efficiently. When the time >>>>>> comes, users migrate — the same way P2PKH and P2WPKH users will have to. >>>>>> >>>>>> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >>>>>> >>>>>>> > In that use case P2TR key-path spending offers no scriptability >>>>>>> either — this is not a new trade-off, it is the same one Taproot already >>>>>>> made. >>>>>>> >>>>>>> This is not true. Taproot has 2 modes; its key-spend path is 12 >>>>>>> bytes more bloated than your solution, yes. but Taproot can "dynamically" >>>>>>> chose whether to use the key-spend path or the script-spend path. Your >>>>>>> solution fully removes the script spend path, so you're not really >>>>>>> optimizing an equally capable solution, you're optimizing for only 1 part >>>>>>> of it. >>>>>>> >>>>>>> Removing scriptability for 12 bytes could possibly be warranted in >>>>>>> some specific cases (I'm sure there are cases), but it's not a fair >>>>>>> comparison against Taproot or BIP360. And since we will need quantum >>>>>>> upgrade at some point, this upgrade is kind of (in my personal >>>>>>> interpretation) doubling down to the part that will eventually break. >>>>>>> >>>>>>> Do you have any plan on how one could quantum secure the funds in >>>>>>> P2SKH? >>>>>>> måndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>>>>>> >>>>>>>> You are saving 12 bytes by removing all the scriptability, OP-code >>>>>>>> upgradeability and basically locking yourself to a non-quantum-secure key >>>>>>>> spend path that is only quantum secure if never spent? Or did I >>>>>>>> missunderstand? >>>>>>>> >>>>>>>> måndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak: >>>>>>>> >>>>>>>>> Taproot specifically did not do this for good reasons that are >>>>>>>>> well documented. I recommend you to read documentation first before >>>>>>>>> attempting to make changes. >>>>>>>>> >>>>>>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com> >>>>>>>>> napísal(a): >>>>>>>>> >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> I'd like to propose a new native SegWit output type: Pay to >>>>>>>>>> Schnorr Key Hash (P2SKH). >>>>>>>>>> >>>>>>>>>> == The problem == >>>>>>>>>> >>>>>>>>>> The two most relevant output types today each solve half the >>>>>>>>>> problem: >>>>>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and >>>>>>>>>> puts the full 33-byte compressed public key in the witness (~108 witness >>>>>>>>>> bytes per input). >>>>>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the >>>>>>>>>> full 32-byte x-only public key directly in the scriptPubKey, making outputs >>>>>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent output. >>>>>>>>>> >>>>>>>>>> Neither type achieves both a compact output and a compact witness >>>>>>>>>> simultaneously. >>>>>>>>>> >>>>>>>>>> == The proposal == >>>>>>>>>> >>>>>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, >>>>>>>>>> same as P2WPKH). Spending requires a single 64-byte Schnorr signature. >>>>>>>>>> Verification works by key recovery: given the signature (R, s) and the >>>>>>>>>> challenge e = TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), >>>>>>>>>> the verifier recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) >>>>>>>>>> matches the program. The sighash reuses the BIP341 transaction digest, so >>>>>>>>>> cross-version replay is prevented by the scriptPubKey commitment. >>>>>>>>>> >>>>>>>>>> The result is the smallest combined footprint of any current >>>>>>>>>> single-key output type — a 22-byte output with a 64-byte witness — while >>>>>>>>>> keeping the public key off-chain until spending. >>>>>>>>>> >>>>>>>>>> == Tradeoffs == >>>>>>>>>> >>>>>>>>>> The key-recovery step costs roughly one extra field inversion and >>>>>>>>>> scalar multiplication compared to direct Schnorr verification. This is the >>>>>>>>>> price of the 12-byte output size reduction. >>>>>>>>>> >>>>>>>>>> == Open questions == >>>>>>>>>> >>>>>>>>>> 1. BIP360 also claims witness version 2. If both proposals >>>>>>>>>> advance, one needs to move. Version 3 seems like a natural alternative for >>>>>>>>>> P2SKH. >>>>>>>>>> 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" >>>>>>>>>> has been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>>>>>>>>> >>>>>>>>>> Full draft: >>>>>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md >>>>>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>>>>>> >>>>>>>>>> Thanks in advance for any feedback. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "Bitcoin Development Mailing List" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU2C7m6-uoPksR5ZTEzSO%3DKCvi3AjcQ0vD6uUH_am9%3DKA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 18832 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) 2026-03-16 8:51 [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) sashabeton 2026-03-16 11:12 ` Martin Habovštiak @ 2026-03-16 11:38 ` Saint Wenhao 1 sibling, 0 replies; 17+ messages in thread From: Saint Wenhao @ 2026-03-16 11:38 UTC (permalink / raw) To: sashabeton; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3955 bytes --] > P2TR uses Schnorr signatures (64-byte witness) I wonder, what do you think about splitting r-value and s-value on the stack. In this way, grinding the signature could make it smaller, just like it was in DER signatures. And then, instead of consuming a single signature, you would have r-value and s-value pushed separately. And optionally, the sighash, as the third element, if it is not the default. And then, by simply checking the size of all elements, it would be known, if we have two stack pushes, or three. Also, if r-value would be handled alone, then it would introduce OP_CHECKSIGFROMSTACK, without any additional opcode, or tricks like OP_CAT. Because then, it could depend on the message being signed. pon., 16 mar 2026 o 11:48 sashabeton <sashabeton2007@gmail.com> napisał(a): > Hi everyone, > > I'd like to propose a new native SegWit output type: Pay to Schnorr Key > Hash (P2SKH). > > == The problem == > > The two most relevant output types today each solve half the problem: > - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts the > full 33-byte compressed public key in the witness (~108 witness bytes per > input). > - P2TR uses Schnorr signatures (64-byte witness), but embeds the full > 32-byte x-only public key directly in the scriptPubKey, making outputs 12 > bytes larger than P2WPKH and exposing the key in every unspent output. > > Neither type achieves both a compact output and a compact witness > simultaneously. > > == The proposal == > > P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, same as > P2WPKH). Spending requires a single 64-byte Schnorr signature. Verification > works by key recovery: given the signature (R, s) and the challenge e = > TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier > recovers P = e^-1 * (s*G - R) and checks that hash160(P.x) matches the > program. The sighash reuses the BIP341 transaction digest, so cross-version > replay is prevented by the scriptPubKey commitment. > > The result is the smallest combined footprint of any current single-key > output type — a 22-byte output with a 64-byte witness — while keeping the > public key off-chain until spending. > > == Tradeoffs == > > The key-recovery step costs roughly one extra field inversion and scalar > multiplication compared to direct Schnorr verification. This is the price > of the 12-byte output size reduction. > > == Open questions == > > 1. BIP360 also claims witness version 2. If both proposals advance, one > needs to move. Version 3 seems like a natural alternative for P2SKH. > 2. Naming — "P2SKH" follows the established pattern but "P2TRKH" has been > suggested to emphasise Schnorr/taproot lineage. Opinions welcome. > > Full draft: > https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md > PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 > > Thanks in advance for any feedback. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOKBQPg3L7XGjHeqydQOEYW1UobwUzqmvraUkWHEcx%2BF9g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4850 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2026-03-24 15:26 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-03-16 8:51 [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) sashabeton 2026-03-16 11:12 ` Martin Habovštiak 2026-03-16 11:43 ` Alex 2026-03-16 14:36 ` sashabeton 2026-03-16 15:57 ` Martin Habovštiak 2026-03-16 15:43 ` Alex 2026-03-16 16:00 ` sashabeton 2026-03-16 16:25 ` Martin Habovštiak 2026-03-24 6:02 ` aaron.recompile 2026-03-16 19:29 ` Alex 2026-03-17 7:23 ` Saint Wenhao 2026-03-17 7:40 ` sashabeton 2026-03-17 18:00 ` waxwing/ AdamISZ 2026-03-17 18:30 ` waxwing/ AdamISZ 2026-03-18 5:24 ` Saint Wenhao 2026-03-18 15:50 ` "wrapped Taproot" from RIPEMD-160 collisions, Was: " Ethan Heilman 2026-03-16 11:38 ` Saint Wenhao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox