From mboxrd@z Thu Jan  1 00:00:00 1970
Delivery-date: Wed, 18 Mar 2026 03:19:03 -0700
Received: from mail-oa1-f61.google.com ([209.85.160.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC7YL44NVYFRBCPY5HGQMGQE47IG6QI@googlegroups.com>)
	id 1w2nzR-0000P4-9s
	for bitcoindev@gnusha.org; Wed, 18 Mar 2026 03:19:02 -0700
Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-4171f9bd717sf6689373fac.0
        for <bitcoindev@gnusha.org>; Wed, 18 Mar 2026 03:19:00 -0700 (PDT)
ARC-Seal: i=3; a=rsa-sha256; t=1773829135; cv=pass;
        d=google.com; s=arc-20240605;
        b=LluUJCOFMUbIfbc+uFJ5HDmqtNaVcURWQYYZn2SQq5M/lH6NetX2fRM7mc9Igh7W/4
         iDKLC17AuJWTHLe7gAUZyGxDIVUkGGN7kUXByIXEcdfYgR/+dDlSbm8Vog/WukY+7RE5
         a3ToGKRNP9EL9lh9rxpCaTpS1ax6AQbS6pLXotjKmjL0jdV9lyMygGcAzfKYERyBN63U
         NAGHlLtE2EAxm0ZnFOKlA+Ba11k/RUvc6Cf+mQq3p/3k1qvPoMOtHG27itsaY/tCKqdq
         b1/Da9qEOYvHKrYSqbSU5SRUR8wWoayUlJRisnBmQdfhShwWV3uqrdjVpiBK9La/3nI4
         KqQw==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=tdKqsGKswqFYjd/QE75livJa2U/VHRNRKF1vVkq7QEY=;
        fh=MDxdsfDz+BCJ7zvEpvHBxCgftIlOR7fAepAwqrJoe/8=;
        b=d86xnIwt4ULzQ7T8kL0UwSfQq9QB63hPxkLdi1UT8COXqH7ZxeeOutrlG0KI8hsrNW
         a64bg38mCs1+um3YBxP6oz/q07kWrX+C+KRJpVljTqoi8sB0hUaHSVUUGm4yQ6m6u+X8
         mQWdqqDefnj0lh7u/+So1ESukKcleqdeh8rRHjy8+TbmM0rGbZjyB0PbMMl7WOMlZXAD
         ly6hHiNWphQyAzU1GDxUczpMIP4jh71gUAseBxtWQ7xcfgDX/AT+DJMY9MZeXvUUNUZu
         bVqns8PQBCeIKuV4RYN6Jkb+toc9mbw0Dss9lvt0QTM/J+MlgaYsxnouWpRbpfKkUqXQ
         n2og==;
        darn=gnusha.org
ARC-Authentication-Results: i=3; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=YvKeaKbq;
       arc=pass (i=1);
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20251104; t=1773829135; x=1774433935; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tdKqsGKswqFYjd/QE75livJa2U/VHRNRKF1vVkq7QEY=;
        b=fiUXCfD0xw2dih23ggrfMC5l2fJZxGO0VOckziqqsIhgRkvt4coyvvI42ChRhs4GOt
         VDnqVKOxGNO1Cv47fSD/I8JaRAY2nAWBMl+G14Tj2JC4s4mkvepPWKdVoYLIEAiOJAv0
         P9FGJPCcY+REV9tWyiP+KBcXWmlAG7nPlSlubX2gDQnA4NYMRjThMpazqsVb+6gioD9y
         sy4ySzxc5nk4eihvLSSqtuNGXI3wBl8NK0eUvNQaJ9bURFrWIdQqPOg4SEtodtqX2VxZ
         30Oyfzvw4isze5ulkAaTPd+ZCb1zKgfcKE4EYqZgascldugcFRw/dlJ+1B8dCuu9gUhG
         +a0g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1773829135; x=1774433935; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=tdKqsGKswqFYjd/QE75livJa2U/VHRNRKF1vVkq7QEY=;
        b=HntkyJazvpsPARE4vM8FK3WSwwTVi7WQsmtDDtWqIdimUO5pmh/6d59xJDHiy4uUl+
         9OyapHmo2K472OsuMGiyqvWhSVOzTq6dyWGi2Q1P3L+F03QIQFxzE8h8/pdyG/xI6U8+
         Dj8lod6Ly+EIuzpw8wU2q0FgEmZsO3bzmaFtgRio6W2ydSJgSirRVQC69nG8l/a+W0HR
         Dw9BhweXLkSFKWXqu+odARPK/4z+41YQJsiRM96Njqi4CagGCeEKCRsvbODolLj+rlUR
         cmAjVA2eAXmAZysnsJLEP3HHV5wBSdS6veSVxRuJkYQwHqkElMVBm9IfjAYNjQnZAOkj
         PeCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1773829135; x=1774433935;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=tdKqsGKswqFYjd/QE75livJa2U/VHRNRKF1vVkq7QEY=;
        b=UGsXbfaS6bJIVty3XOyjp+LaYeOUStKQpPTNzs6PEljTRQMOGUSPkjJ4NIibxzjjnn
         gorxJKrlLPehddjqRYb1cWQxUwM8+Jds0LpAIEhkKKcnbQYinzuGSLWAzYR67ZSpyQOj
         Uz7wW1dXzDf199lprT6Dh2xmVRZfcl4mATwBBa9yehfjKsdPPUfhyYsNWJsBDgl+15At
         zTQW3rPUwR+Mp+ayTAngyZggTQ6uB5Lwb0iD0plgTCz2I5k02IDx2/7pBCwQusfZkbvu
         PwI+RW5NWRzk1SKZuQYiv+eiTfRa8RacqMBbYph58vqlVLvWhJi2/uK20jgZ3tP5dAm3
         DTUw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=3; AJvYcCW6UPvedvlxQKQ49PZcBkKU1p2r5L6mNKCRkdi0qSFOJ6BC6rSiatIT84w/X/ooW0DeK7/T6w0Tx3pa@gnusha.org
X-Gm-Message-State: AOJu0YzP84USTj94t2wag8eMkT2dxnWyBLteRT9bFlcpOeimaSOegWo4
	UzUQzmeulR1tO9TA0KN8WO0KxuV72Ww3Tnvp/IusikbO9weT9Ff/0wSF
X-Received: by 2002:a05:6870:a78a:b0:40e:deac:4248 with SMTP id 586e51a60fabf-41bb017b334mr4178066fac.3.1773829134438;
        Wed, 18 Mar 2026 03:18:54 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GinSg2d9Sh6P9yJinGRRZRWd7ZR/gzO1NMvSqhFhP0Uw=="
Received: by 2002:a05:6871:4319:b0:417:38a0:280 with SMTP id
 586e51a60fabf-41bd5904e6dls232626fac.1.-pod-prod-00-us-canary; Wed, 18 Mar
 2026 03:18:49 -0700 (PDT)
X-Received: by 2002:a05:6808:d48:b0:463:a42c:503a with SMTP id 5614622812f47-467b94ac242mr1726451b6e.14.1773829128973;
        Wed, 18 Mar 2026 03:18:48 -0700 (PDT)
Received: by 2002:a05:600c:899:b0:483:6d47:ea7 with SMTP id 5b1f17b1804b1-486f488003dms5e9;
        Tue, 17 Mar 2026 22:25:07 -0700 (PDT)
X-Received: by 2002:a05:600d:103:b0:485:4388:3492 with SMTP id 5b1f17b1804b1-486f443d53amr20689235e9.11.1773811506021;
        Tue, 17 Mar 2026 22:25:06 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1773811506; cv=pass;
        d=google.com; s=arc-20240605;
        b=FfU5/MlEdATUr+48jByWGwkyI6LjfNpu0ELNsm9Dbg4LE/r92paVQmVFOK1cvF3fel
         dANb+zEmCNYpnmBRckIwK3qflNOQ4pmXL5IhXN1VivUqJ5lMFLP8vROQW8mby1SJw0P0
         z29vr9IqM1iNGIj0Pqg+13uprTZnj2+6HXeR+ZoqQ/E1GqMZkXnr6EutgYlSDopeAPoY
         fvfU8nkjdMFypwhFbqRvWS36xytCmXCUWvxBq3czKVKYv79CvDlug8jOlzMplX9XWZ38
         CoW86fGoVKdk2H3Im9QbQQoAjf7/Dp/1FYQzSvmD/gtNZKOGwDYs6olrvIoIbTMsOxLy
         aG2w==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=tbKJ1Rf+OMA+jFGobWyY9ET55Eh1rAzq796d+zQ8wa0=;
        fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=;
        b=EpqVIpba29HD+GOWT54+dNh/cxPfz4gMNbgEm5EBvH/8C7vtRGwmtdyZJcxD+5cAwV
         NTC0nAaGAH/7bF8I4vtphyYb/5wCvybc7Bt7uJrUW65kqTorNrkaQ/AaT38KWZd3j/cO
         MYYEzwsat+o6ex2Sj1fD/5T+eUN3G95v6fg6/3lj85ZoqsJvYKKbtJ8WkwLc8Fj7ut22
         xYFjreuW6VfEKN8SWYn/2is0wil1ueNYfM0sRmC1QZv3gsFJQOrwyjI0KHkZ+Uf4DqKr
         jTBfP5i8bTPCt/q8g31Gm3i6v0gnbRG6NpIwroJTEXGwcKfke/m1pC5wep6dRrhS+bua
         HvPw==;
        dara=google.com
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=YvKeaKbq;
       arc=pass (i=1);
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com. [2a00:1450:4864:20::135])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-486f45f80d4si177235e9.0.2026.03.17.22.25.05
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 17 Mar 2026 22:25:05 -0700 (PDT)
Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) client-ip=2a00:1450:4864:20::135;
Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5a27a7f711eso222768e87.2
        for <bitcoindev@googlegroups.com>; Tue, 17 Mar 2026 22:25:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1773811505; cv=none;
        d=google.com; s=arc-20240605;
        b=k7NM0NqkK75tNLVYJ1ZxL8AluzV6ZIzIF/LucQeUeDLVF4+TSh/qdzLp6KUDwFDqbO
         sJyJXxY1/ZZmwx5y8YcKH0CoF7xC9nwho3WLxbodwdOCPOlz9H7RLS2pEXp2V2Wf7jau
         24k4U/v4Du9zAXKggTcyZV3U8COiSv0Qq+TffHQp+5wI5Bsat24JKs4a9MC6gwK+4UE+
         kwUsPzVzF+4KUryTn6eJLnruf8LPM2TPCP4Ix8gmQIprjnRQdSlu4NERvltEVhenwzFJ
         gBm/iRM4swl1iXOMWnIrdehs+8cgVHriEc5ZfgpvUD2DHnH1K8uqc0dY9bKCjRJiVUsI
         W5RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=tbKJ1Rf+OMA+jFGobWyY9ET55Eh1rAzq796d+zQ8wa0=;
        fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=;
        b=FJZmxYxTw6FO6X7pUWjXVCLBuJrJFTGsRMhQTWHKqzzi+GyeZV0lxvwxF84NVB4cpK
         ccqi9lk+1Bf6biTAW9i7QIElFbukNvkRwPtl2ovaisayfYMDY78p00AtDwEDBHbGGuzN
         pVL+T/YDtx3aqvRbPkYWzdjPtErYF4MH5CyqPLGL/viMNqi3ZUHzZiq2ovcPVmTgrqE9
         TNDwFfSiDaUNtFAP36iUZFWnAIDLFyM7KGrFeq3CQa8WFxOzz1frwWLle9i11dCQs68l
         suvF/xNRWd6BY/S5ISjZHDEzq601cn8Q3oGuQgSqRd29reCJcqUqEX4QoBwyy2aUEFGf
         RUAw==;
        dara=google.com
ARC-Authentication-Results: i=1; mx.google.com; arc=none
X-Gm-Gg: ATEYQzw44YBXoU6Uj05nmxwUyNO96w46MrPbkwuQvBz2d2r52jhO7RDChNAEf8QfKfe
	D/aIDAkfxEaOCLI26LxwC7bWjK4dJ1wCTJeVctYDwGl13wijwb7IL+vP8ur3Re5y+Vph+iUkQA3
	EiSFHQenC4bYDunaEaqv2xAbjqG/+5kA9Hb7wknmrntApnQSZW270lwTQvg6lwbRHM5AcqIDsle
	g9AydhnktnWTJalG7Qh7KNmgvj2kyne4E0O11TcDyQ686KZy4hcVI+cVLtUAmgWMgvvJFL3JlIQ
	S4ljJKbp79upRx6bGA==
X-Received: by 2002:a05:6512:8002:20b0:59e:5c8f:a5 with SMTP id
 2adb3069b0e04-5a27959cbd1mr542685e87.4.1773811504625; Tue, 17 Mar 2026
 22:25:04 -0700 (PDT)
MIME-Version: 1.0
References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com>
 <CALkkCJbcUur0kao0=B2QQvQmM210O1TB_JkEkWLDqmzboqsN9Q@mail.gmail.com>
 <cc649b36-0ee1-4a87-b135-f5ad5a38b232n@googlegroups.com> <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com>
 <ee240078-88c6-4961-8412-489a77012038n@googlegroups.com> <CACgYNOJEDekgg_wA9AS2FHRB=xp=wC2BdzD4hHK2rHXWvrZQ=A@mail.gmail.com>
 <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com> <171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com>
 <fc83173c-f4b3-4a2e-a662-dd6eecebb7ban@googlegroups.com>
In-Reply-To: <fc83173c-f4b3-4a2e-a662-dd6eecebb7ban@googlegroups.com>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Wed, 18 Mar 2026 06:24:53 +0100
X-Gm-Features: AaiRm53GKUzgXJVpLkbMuoDCHTmpgtHGbC4K2Hpgx8WS6P1rugnM3UwVg8ViLmc
Message-ID: <CACgYNOK-QK6c2+LiO-Tgy48SJs12iV5XSM+Htpt5GSFrkZUAWg@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH)
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a1bd10064d45accf"
X-Original-Sender: saintwenhao@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=YvKeaKbq;       arc=pass
 (i=1);       spf=pass (google.com: domain of saintwenhao@gmail.com designates
 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--000000000000a1bd10064d45accf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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=C5=82=
(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=E2=80=AFPM UTC-3 waxwing/ AdamISZ w=
rote:
>
>> 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 I=
RC.
>> I'm sure others, including the taproot designers, discussed this issue w=
ell
>> 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 =3D =
H(R,
>> P, m) with P the public key. This makes a pubkey recovery algorithm of t=
he
>> type that we have in our legacy ECDSA signatures, impossible. It's a poi=
nt
>> of not-only-historical interest that the original Schnorr signature desi=
gn
>> 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 befo=
re
>> .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that h=
as
>> big implications for perhaps the biggest application of Schnorr in Bitco=
in,
>> which is aggregation; aggregation in a bitcoin context means *aggregatin=
g
>> arbitrary, new, ephemeral keys*, not keys previously recorded in some
>> certificate registry or whatever. You're not going to get sensible versi=
ons
>> 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 le=
ss
>> 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=E2=80=AFAM 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 =E2=80=94 which is simply not goi=
ng 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 woul=
d 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 efficienc=
y 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 e=
ach,
>>>> 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, s=
o 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 pu=
shed
>>>> in DER signatures, because of BIP-66, and as computing power is gettin=
g
>>>> better and better, your signatures could be smaller in the future, whi=
le 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=C5=
=82(a):
>>>>
>>>>> To clarify the design intent: P2SKH is not a stripped-down Taproot =
=E2=80=94
>>>>> it is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compa=
ct
>>>>> 20-byte hash commitment, no script path, single-key payments), and th=
e only
>>>>> change is replacing ECDSA with the same Schnorr signature scheme Tapr=
oot'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 efficien=
cy 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 =E2=80=94 I fully acknowledge this. Li=
ke
>>>>> 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 th=
e time
>>>>> comes, users migrate =E2=80=94 the same way P2PKH and P2WPKH users wi=
ll 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 =E2=80=94 this is not a new trade-off, it is the same one Tap=
root already
>>>>>> made.
>>>>>>
>>>>>> This is not true. Taproot has 2 modes; its key-spend path is 12 byte=
s
>>>>>> more bloated than your solution, yes. but Taproot can "dynamically" =
chose
>>>>>> whether to use the key-spend path or the script-spend path. Your sol=
ution
>>>>>> 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=C3=A5ndag 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-secu=
re key
>>>>>>> spend path that is only quantum secure if never spent? Or did I
>>>>>>> missunderstand?
>>>>>>>
>>>>>>> m=C3=A5ndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habov=C5=
=A1tiak:
>>>>>>>
>>>>>>>> Taproot specifically did not do this for good reasons that are wel=
l
>>>>>>>> documented. I recommend you to read documentation first before att=
empting
>>>>>>>> to make changes.
>>>>>>>>
>>>>>>>> D=C5=88a po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com>
>>>>>>>> nap=C3=ADsal(a):
>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> I'd like to propose a new native SegWit output type: Pay to
>>>>>>>>> Schnorr Key Hash (P2SKH).
>>>>>>>>>
>>>>>>>>> =3D=3D The problem =3D=3D
>>>>>>>>>
>>>>>>>>> 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, maki=
ng 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.
>>>>>>>>>
>>>>>>>>> =3D=3D The proposal =3D=3D
>>>>>>>>>
>>>>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes, sam=
e
>>>>>>>>> as P2WPKH). Spending requires a single 64-byte Schnorr signature.
>>>>>>>>> Verification works by key recovery: given the signature (R, s) an=
d the
>>>>>>>>> challenge e =3D TaggedHash("P2SKH/challenge", R.x || hash160(P.x)=
 || msg),
>>>>>>>>> the verifier recovers P =3D e^-1 * (s*G - R) and checks that hash=
160(P.x)
>>>>>>>>> matches the program. The sighash reuses the BIP341 transaction di=
gest, so
>>>>>>>>> cross-version replay is prevented by the scriptPubKey commitment.
>>>>>>>>>
>>>>>>>>> The result is the smallest combined footprint of any current
>>>>>>>>> single-key output type =E2=80=94 a 22-byte output with a 64-byte =
witness =E2=80=94 while
>>>>>>>>> keeping the public key off-chain until spending.
>>>>>>>>>
>>>>>>>>> =3D=3D Tradeoffs =3D=3D
>>>>>>>>>
>>>>>>>>> The key-recovery step costs roughly one extra field inversion and
>>>>>>>>> scalar multiplication compared to direct Schnorr verification. Th=
is is the
>>>>>>>>> price of the 12-byte output size reduction.
>>>>>>>>>
>>>>>>>>> =3D=3D Open questions =3D=3D
>>>>>>>>>
>>>>>>>>> 1. BIP360 also claims witness version 2. If both proposals
>>>>>>>>> advance, one needs to move. Version 3 seems like a natural altern=
ative for
>>>>>>>>> P2SKH.
>>>>>>>>> 2. Naming =E2=80=94 "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/3cb9e07984b571e9510370ab7=
e7218620be580dc/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 Googl=
e
>>>>>>>>> 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-a=
d6c-2ddfe68ec73en%40googlegroups.com
>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-=
ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>> 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, sen=
d
>>>>> 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=3Demail&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>> --
> 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-dd6e=
ecebb7ban%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6=
eecebb7ban%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail 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.

--000000000000a1bd10064d45accf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; You were of course in fact pubkey-prefixing here (wit=
h the hash-160 of P)<br><br>Yes, I also thought about that. But then, it me=
ans after around 2^80 operations, you could have a potential RIPEMD-160 col=
lision in the future. Which also means, that 160-bit hashes may be later un=
safe anyway. And if you pick 256-bit ones, then putting x-value pubkey give=
s the same size.<br><br>Also, I wonder if collisions in P2SH will be used a=
s a &quot;wrapped Taproot&quot;. Because then, instead of building some MAS=
T, it could be possible to simply prepare a collision, and use older addres=
ses in that way. Then, Alice can for example use &quot;&lt;pubkeyA&gt; OP_C=
HECKSIG&quot;, and Bob can use &quot;&lt;time&gt; OP_CHECKLOCKTIMEVERIFY OP=
_DROP &lt;pubkeyB&gt; OP_CHECKSIG&quot;. If applying HASH160 to both script=
s will give the same 160-bit value, then each party could use a different S=
cript, to spend coins from the same P2SH address.</div><br><div class=3D"gm=
ail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">wt.,=
 17 mar 2026 o 20:01=C2=A0waxwing/ AdamISZ &lt;<a href=3D"mailto:ekaggata@g=
mail.com">ekaggata@gmail.com</a>&gt; napisa=C5=82(a):<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div>Hi sashabeton,</div><div><br></d=
iv><div>Apologies - I didn&#39;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!</div><div><br></div>=
<div>(maybe someone found it interesting tho&#39; , lol).</div><div><br></d=
iv><div>Cheers,</div><div>AdamISZ/waxwing</div><br><div class=3D"gmail_quot=
e"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, March 17, 2026 at 3:0=
0:50=E2=80=AFPM UTC-3 waxwing/ AdamISZ wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div>Hi sashabeton,</div><div><br></div><div>=
&gt; Honestly, this idea might have had better timing a few years ago.</div=
><div><br></div><div>No I don&#39;t think so; it was discussed at the time =
(specifically, pubkey recovery). I remember bringing it up in the taproot r=
eview sessions on IRC. I&#39;m sure others, including the taproot designers=
, discussed this issue well before I thought about it :)</div><div><br></di=
v><div>Perhaps this clarifies it for other mailing list readers:</div><div>=
<br></div><div>BIP340 Schnorr signatures are the form of Schnorr signature =
which has what is commonly termed &quot;pubkey prefixing&quot;; the challen=
ge hash is e =3D H(R, P, m) with P the public key. This makes a pubkey reco=
very algorithm of the type that we have in our legacy ECDSA signatures, imp=
ossible. It&#39;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 t=
he time when ECDSA was being designed to avoid the Schnorr patent, and late=
r, it was a point of considerable contention amongst various system designe=
rs, whether pubkey prefixing was needed or not.</div><div><br></div><div>Pu=
bkey prefixing makes all of the security reductions much more meaningful, s=
ince it can make the concept of &quot;resistant to forgery&quot; 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&#39;t used before .. t=
his is sorta kinda true for non-pubkey-prefixed Schnorr). And that has big =
implications for perhaps the biggest application of Schnorr in Bitcoin, whi=
ch is aggregation; aggregation in a bitcoin context means *aggregating arbi=
trary, new, ephemeral keys*, not keys previously recorded in some certifica=
te registry or whatever. You&#39;re not going to get sensible versions of M=
uSig without pubkey prefixing, because you couldn&#39;t stop adversaries ma=
king up malicious keys that they don&#39;t have to commit to.</div><div><br=
></div><div>Without that kind of aggregation scheme (and see e.g. DahLIAS a=
nd CISA, if you don&#39;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, st=
ill not nothing, it&#39;s on sounder theoretical foundations).</div><div><b=
r></div><div>Cheers,</div><div>AdamISZ/waxwing</div><div><br></div><div cla=
ss=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, March=
 17, 2026 at 6:32:12=E2=80=AFAM UTC-3 sashabeton wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Hi everyone,<br><br>After reading a=
ll the feedback, I think it&#39;s time to accept that this proposal has no =
realistic path forward.<br><br>For it to make sense, the new address type w=
ould need to be adopted by the entire ecosystem almost instantly =E2=80=94 =
which is simply not going to happen.<br><br>Honestly, this idea might have =
had better timing a few years ago. Today, the landscape has moved on, and I=
 don&#39;t think pushing this further would be a good use of anyone&#39;s t=
ime.<br><br>I want to thank everyone who took the time to read, review, and=
 respond.<br><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmai=
l_attr">On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&g=
t; The goal is giving users who are already happy with the P2WPKH model (no=
 script spending, simple single-key payments) the witness efficiency of Sch=
norr<br><br></div><div dir=3D"ltr">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 byte=
s.<br><br>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&#39;t reveal y=
our private key to anyone else. It would require around 2^33 operations, so=
 it is doable on CPUs.<br><br>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 ze=
roes 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&#39;t have any way to go belo=
w 64 bytes.</div><br><div class=3D"gmail_quote"></div><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">pon., 16 mar 2026 o 17:12=C2=A0=
sashabeton &lt;<a rel=3D"nofollow">sashabe...@gmail.com</a>&gt; napisa=C5=
=82(a):<br></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">To clarify the design intent: P2SKH is not a strip=
ped-down Taproot =E2=80=94 it is P2WPKH upgraded to Schnorr. The starting p=
oint is P2WPKH (compact 20-byte hash commitment, no script path, single-key=
 payments), and the only change is replacing ECDSA with the same Schnorr si=
gnature scheme Taproot&#39;s key-path uses. That&#39;s it.<br><br>The goal =
is giving users who are already happy with the P2WPKH model (no script spen=
ding, 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&#39;t need.<br><br>P2SKH is not quantum-resistant =E2=80=94 I full=
y 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 =E2=80=94 the same way P2PKH and P2WPKH =
users will have to.<br><br><div class=3D"gmail_quote"><div dir=3D"auto" cla=
ss=3D"gmail_attr">On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;=C2=A0

<span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;f=
ont-size:small">In that use case P2TR key-path spending offers no scriptabi=
lity either =E2=80=94 this is not a new trade-off, it is the same one Tapro=
ot already made.<br></span><br>This is not true. Taproot has 2 modes; its k=
ey-spend path is 12 bytes more bloated than your solution, yes. but Taproot=
 can &quot;dynamically&quot; chose whether to use the key-spend path or the=
 script-spend path. Your solution fully removes the script spend path, so y=
ou&#39;re not really optimizing an equally capable solution, you&#39;re opt=
imizing for only 1 part of it.<div><br></div><div>Removing scriptability fo=
r 12 bytes could possibly be warranted in some specific cases (I&#39;m sure=
 there are cases), but it&#39;s not a fair comparison against Taproot or BI=
P360. 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 wil=
l eventually break.<br><br>Do you have any plan on how one could quantum se=
cure the funds in P2SKH?</div><div class=3D"gmail_quote"><div dir=3D"auto" =
class=3D"gmail_attr">m=C3=A5ndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You are saving=
 12 bytes by removing all the scriptability, OP-code upgradeability and bas=
ically locking yourself to a non-quantum-secure key spend path that is only=
 quantum secure if never spent? Or did I missunderstand?<br><br><div class=
=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">m=C3=A5ndag 16 mars=
 2026 kl. 12:25:57 UTC+1 skrev Martin Habov=C5=A1tiak:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">Taproot specifical=
ly did not do this for good reasons that are well documented. I recommend y=
ou to read documentation first before attempting to make changes.</div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">D=C5=88a p=
o 16. 3. 2026, 11:48 sashabeton &lt;<a rel=3D"nofollow">sashabe...@gmail.co=
m</a>&gt; nap=C3=ADsal(a):<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"></blockquote></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi everyone,<br><br>I&#39;d like to propos=
e a new native SegWit output type: Pay to Schnorr Key Hash (P2SKH).<br><br>=
=3D=3D The problem =3D=3D<br><br>The two most relevant output types today e=
ach solve half the problem:<br>- P2WPKH has a compact 22-byte scriptPubKey,=
 but uses ECDSA and puts the full 33-byte compressed public key in the witn=
ess (~108 witness bytes per input).<br>- P2TR uses Schnorr signatures (64-b=
yte 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.<br><br>Neither type achieves both a compact ou=
tput and a compact witness simultaneously.<br><br>=3D=3D The proposal =3D=
=3D<br><br>P2SKH uses OP_2 &lt;hash160(P.x)&gt; as the scriptPubKey (22 byt=
es, same as P2WPKH). Spending requires a single 64-byte Schnorr signature. =
Verification works by key recovery: given the signature (R, s) and the chal=
lenge e =3D TaggedHash(&quot;P2SKH/challenge&quot;, R.x || hash160(P.x) || =
msg), the verifier recovers P =3D 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.<br><b=
r>The result is the smallest combined footprint of any current single-key o=
utput type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80=94 whil=
e keeping the public key off-chain until spending.<br><br>=3D=3D Tradeoffs =
=3D=3D<br><br>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.<br><br>=3D=3D Open questio=
ns =3D=3D<br><br>1. BIP360 also claims witness version 2. If both proposals=
 advance, one needs to move. Version 3 seems like a natural alternative for=
 P2SKH.<br>2. Naming =E2=80=94 &quot;P2SKH&quot; follows the established pa=
ttern but &quot;P2TRKH&quot; has been suggested to emphasise Schnorr/taproo=
t lineage. Opinions welcome.<br><br>Full draft: <a href=3D"https://github.c=
om/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md" =
rel=3D"noreferrer nofollow" target=3D"_blank">https://github.com/sashabeton=
/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md</a><br>PoC imp=
lementation: <a href=3D"https://github.com/bitcoin/bitcoin/pull/34826" rel=
=3D"noreferrer nofollow" target=3D"_blank">https://github.com/bitcoin/bitco=
in/pull/34826</a><br><br>Thanks in advance for any feedback.<br>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow">bitcoindev+...@googlegroups.com</a>.=
<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer nofollow" target=3D"=
_blank">https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6=
c-2ddfe68ec73en%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.<br></block=
quote></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" target=3D"_blank">htt=
ps://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012=
038n%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5XSM%2BHtpt5GSFrkZUAWg%=
40mail.gmail.com</a>.<br />

--000000000000a1bd10064d45accf--