From mboxrd@z Thu Jan  1 00:00:00 1970
Delivery-date: Wed, 18 Mar 2026 10:15:07 -0700
Received: from mail-oo1-f60.google.com ([209.85.161.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRBDN35PGQMGQEJ5ILY3Y@googlegroups.com>)
	id 1w2uU5-0006D9-7X
	for bitcoindev@gnusha.org; Wed, 18 Mar 2026 10:15:06 -0700
Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-67bd1b31789sf1481052eaf.0
        for <bitcoindev@gnusha.org>; Wed, 18 Mar 2026 10:15:04 -0700 (PDT)
ARC-Seal: i=3; a=rsa-sha256; t=1773854099; cv=pass;
        d=google.com; s=arc-20240605;
        b=ku0kGwuIA/uEqFrqOaugzEFF6OL084wnthKMHt1+siDoIY/ntUfq2deXi/pIiErU1m
         ih2HRGAu5/IQvFQdH3ZyRRrIxb7POA4xo29EO3hLLs14hAQFsZJuhI/G3V52Ovj48/Cg
         +Y3nW7IZeLyP2jRZ8abG5YaHs1RKIlqB7dK838olH2l34mkXzO2bBc13kKKOMs0P0D8b
         zMpxmgu5SS2LyIhlsRQllW2Yw09oAUCMwt3f8j308GSXiBaN8ufUEK9zhHkyWups/++o
         ZvC76OI2dnK+3DsvwtWfxkTRH6ttWBZbpDXyrM0+uKm8YpIuiknaydsY9sHbpoOhffpx
         c8KA==
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=t46dECWz/kMPXMuodeLETubmc6i9sSx8xUJz6HglkXc=;
        fh=qW5v2fHzUyJ1Qq69OiTGJb2ZHOx+tnWOCoeHSAdkNzc=;
        b=eKd4oJmp/TBEVtk7O5qC86By0x5wmotdMbVJqa0dPN8oVuNMPSF9yuoaj1kyWJrnY6
         2EZEyp9GnBcqFA87bJnDdl8DRv5WEBoF+DKmwklttsMc56xiZ9HKMIuso7vq3rB7+nd4
         9W/0zRT+fgfchZhen27F4QNuziG2Zup4mEoSL1PQftTSzaoddyZOVAnpc83iv7w6PIAW
         cx1YsjvGvNPA2p3sT/QnoBynuQoMJ4pxUmOcmE6YZ5eJiQd+hauBErG00WMnNyluS8NK
         UCUv5rUOK9nvOPI5OTndjBjEVFKmA51s+RowrYm+CU9podEfgA+zKxfOFuhY3AAZidXi
         rDyg==;
        darn=gnusha.org
ARC-Authentication-Results: i=3; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=R4wGb8Xs;
       arc=pass (i=1);
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=eth3rs@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=1773854099; x=1774458899; 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=t46dECWz/kMPXMuodeLETubmc6i9sSx8xUJz6HglkXc=;
        b=h+v+KRUVjzDSuZXkSrQnD0OCVE6MiMBNNFPTo+27rO4ZtRsfpv2HLqR6HKQrGM1Tf4
         eEI8EZ2mkOVm4kFNWe6SIlJQtYZk/k6i9Kjw+/Wizkky1HeAJ4advH4zEHqWW4aKbik/
         PZAtxaNEvvDnCK9NaiT92D70u6W1ALsaUP377o9Msu1OUUKwVz84mtVJzSVMrlfY1Rvk
         I4ns5k9RPYF9nLmGKr/85CKC/Os8LOKlB/l2XQn4+bKrGjUQLKxbPKYASRmDf5nJnoRh
         TM5U4lRjX5kpHSlaUT383FLo9soonIis8kmiKmxxaHWG83KMyCDVyj3HgTzU43QKx6Mn
         mPrw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1773854099; x=1774458899; 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=t46dECWz/kMPXMuodeLETubmc6i9sSx8xUJz6HglkXc=;
        b=CQcdnTCkLkBYdfuMtnyq0hY5d5h9QCrnFwi06ZvKXnusZRGMXl8k8DVX/jqDKTT4NJ
         nAo2DErmbozvIhG5Kqrt9pjy25YbamzQo2/htZl1shLPJYwrpDRgcyrLd8HFAMUeLn4j
         2/Q0KR1vnNfdwkdK6yXI0V9RjOz77doCUVOkeeayDEcwaWfHd7LW62iCgqMs+LaFyrlP
         +4rhGOITHvQsEp94xXZvTkai6fG1o2typkmq4mw+vZ9z7bt3oxW6zHnYL0Vm+MRFP85C
         QQizgXKTfsDqt1gxyxbcw8bRaYuMrIBjx6xfN9805kPoAM2uihMx1vjUuvEQJ+uHjTVw
         tskg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1773854099; x=1774458899;
        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=t46dECWz/kMPXMuodeLETubmc6i9sSx8xUJz6HglkXc=;
        b=QnQuqmxxTeNWmvmNxWYVfc4Kk0xsA2ZvjW8zQh4LKyGZlv/Lczq45P5FIjSbgxgLex
         Eft6jMFJb9Gueb+rX/c/1PblJSWfo++9R1Jd/UHezlRB5EQA6nMqCpXvIx8RwldEVzZb
         jb2IUEOV+14I19hFXOPIZbWUQc8v5Qy0WWqMPE3wjYC1jkHxesmNomoBn20Md2EJAge0
         PqENwwzlxjHGSbsDCYlXFm2D1tCg50ERtsCpcisAc0afZRQmTA8tYLi1skM5FNJHqK+H
         a2nqrkGMLauFJQIcYSC6BROTb+IV1vzZW4NJnKUBf7ubCuNCiKrmDHAVrVw0eNhj+fWa
         7PvQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=3; AJvYcCWbXmOMr8+9vLVd/iML/S/G76OUUQG4pbv+M9PS/eLcWqPga9mXXW0h6ebfLnhUa9QwFgoIoRqWnbxv@gnusha.org
X-Gm-Message-State: AOJu0Yy606CBAXgA8Ywx2rz2kykCNzN3IBet+el+Jw+zDC1lbHvjNUZ4
	03De3MvK5+X/h9AID3OaaeOvFpwZiU6Ng+/6KYOUzwBJJCp5mdh28QVN
X-Received: by 2002:a05:6820:4b06:b0:67b:f1f1:1abd with SMTP id 006d021491bc7-67c0db3cb74mr2973646eaf.54.1773854098500;
        Wed, 18 Mar 2026 10:14:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Flhba7bzWElFhxKUE8jhp8DwTH/uTCDXlQt2cDGv1ALw=="
Received: by 2002:a4a:db63:0:b0:67b:b390:cf44 with SMTP id 006d021491bc7-67bd971f647ls1795645eaf.0.-pod-prod-06-us;
 Wed, 18 Mar 2026 10:14:53 -0700 (PDT)
X-Forwarded-Encrypted: i=3; AJvYcCUd7EVhU4bTYwyS9eDnMVnJwwdOpHXcitbTf3I708fprf2gxZnZmvr4fqfSxO9CaYhU+7XVe2d1ITrW@googlegroups.com
X-Received: by 2002:a05:6808:6d84:b0:467:1e7b:72d8 with SMTP id 5614622812f47-467ba1f238dmr2201745b6e.7.1773854093256;
        Wed, 18 Mar 2026 10:14:53 -0700 (PDT)
Received: by 2002:a05:6808:6556:10b0:467:4299:91ac with SMTP id 5614622812f47-467bb5c89c5msb6e;
        Wed, 18 Mar 2026 08:50:40 -0700 (PDT)
X-Forwarded-Encrypted: i=3; AJvYcCUgCjVCDOQMY04T+BQFJsQdnpKSO9TfraufftWIHunJkf/Vr2u+R++tCHf8UvSOGulkXD/PRgKd0/p4@googlegroups.com
X-Received: by 2002:a05:7022:660b:b0:11b:9386:8264 with SMTP id a92af1059eb24-129a7106e9cmr1938591c88.41.1773849038722;
        Wed, 18 Mar 2026 08:50:38 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1773849038; cv=pass;
        d=google.com; s=arc-20240605;
        b=UCWk1/o23KYU0OMErH949shOq5dQys93yyg3Bjp5shBnENz4BPzj3KSqc4blK0ppRS
         yYQhLgP7cgYVQr4T7Fh+eFB2ChoaSgFvGOG62GcW+0RP3LApI6GvqUTOei8sGEzN/fkx
         lr/z3tnbxcmLx7x8RyJd5MxlDOohCFypTWnlq1okgbEXktjpV8pZl0Kr92uqZOjcjsu7
         cyyPSOMDxVnh5lzxp4yF+H73w4jVEn5rmXfYKp4l8pauj72y27tJu7Mvm5hwVgNuDvk1
         lmTW3pyh/dmrG6yL4PvlhnizYMckhQnkgvq3xDJABoxO5WCDXvlQbOHm/ffBBEW/Cj49
         SKbA==
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=YA6F1ihqK/jfq1Lr22caisra87KhHqEHlCtAl5cxDOA=;
        fh=FXumyfqI/UFPcZ3kpoFzvpjxVCJKQvWuSqajrulCxq4=;
        b=biDXUWmXgAJn/yhSwW2TDVVpreeTf54oDsJOfUIx5UNgHZFMcycsju54YNa0wpaCla
         Eq5IL/USgfmolitZbBOYggqu3Fw+51EWxHorQqOYaCiz1VWPBhguVFZfOZsY9b58PjmI
         3Sq595RJTDmtmqFLtqXxjRj8ldMQ/FYdSDQOizDdsouMXsVIo7cchwfq0SCCd7U22EBY
         Ng3BeexG2ItWk0Lsw/tKRpZ3iGQiNxalC+rkGBTGXybUkNA+VzwmLkXHOHttph+DvkXa
         ajC2rOolk98Jgb1+gWvmfk9y3ZceCh9tbFcF4XiUzxqS39e1K7Ws2V0mpEz/gZuLHaVI
         skKQ==;
        dara=google.com
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=R4wGb8Xs;
       arc=pass (i=1);
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com. [2607:f8b0:4864:20::62e])
        by gmr-mx.google.com with ESMTPS id a92af1059eb24-129a7237a04si97047c88.2.2026.03.18.08.50.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 18 Mar 2026 08:50:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) client-ip=2607:f8b0:4864:20::62e;
Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-2a871daa98fso53386915ad.1
        for <bitcoindev@googlegroups.com>; Wed, 18 Mar 2026 08:50:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1773849038; cv=none;
        d=google.com; s=arc-20240605;
        b=ID6XimQ4gv3TsWOnjpiBbHSTvFwptlSS3HAhzctkm5itx5+e2lyx+VAieqNrjH1/EW
         G+SGP/CmrYRThSATAzEroAPBWdmmw5/EClAM0oz8XPfLo/Mplgm/Zy6lbwB3M5waWjR/
         QX1Uj4KBzpY+4YvUyOzUwJ2Ou89ZMcaa5ZGzhDgMnj+bFdmcauf9K0fpCz8D7ONI3OiE
         Mg4GiJ4z8HozgSKzVrj+omQEyrHf28cD61YbL0xdxUi6QwdnNNLqBvE63biU6qJg1mEI
         6HaG0alZaekRaA0ml9LhJ5zGzlUG9M8aWRUGQW0PIdlwuDaXPz0yBPLCzbgYZd/rWOpS
         I9iA==
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=YA6F1ihqK/jfq1Lr22caisra87KhHqEHlCtAl5cxDOA=;
        fh=FXumyfqI/UFPcZ3kpoFzvpjxVCJKQvWuSqajrulCxq4=;
        b=kh7jJQNvted/GpuCabzN0thEHBrKhk7ILQbf3ej0a5fXX6ezmrcfzd8nY1n9cmSdFY
         /rLbQIu2HQdonPgzWFeAh/9O3o7wBHQjmMLqPaoyE8x3NtEHA9u60bQq5Bf2HlMHGnj8
         CelntAcA3dceVI6oo6GbGu6PkB+3nYrdQgq5TR1TANS7O+ljC0429cndCBoRjwEvwiO3
         4WlYykdCAbmY9NpLDTGw/u+BXfhAihVqw9rgpSA+dH6ZhpbilesN2PxC3ENm+tmMPYua
         wLXS8dNbHWbMzXK3rMQYRKn3yfW3Y8FzxnXpRguH0hd5BIf/+/eFCsPyVuzXbJUhPpaU
         Plww==;
        dara=google.com
ARC-Authentication-Results: i=1; mx.google.com; arc=none
X-Forwarded-Encrypted: i=1; AJvYcCXOyLWwu7iVjunap1dvbrW1Ayw5yQ3Mw9q7wh9IcLchKWSLJC+zgprvc5glYNeKC1CpvesWuuOWXg9g@googlegroups.com
X-Gm-Gg: ATEYQzw9iYVsGeXRCxyw2hyVlmSF87hjoOdU8kLV8NQ2gRV71bMGVAkmUbx1rHMk3rD
	b8tQF6UDb8fNES2P+w1bNiaT3F7WZyTWzLpOLAt1mw6LReOL/Sbon1xpT/jbYC3Mb4DYwL+qWtW
	zgqnDEXaiVtQoe4O2Zc45W8YHMuwG2AUOQ+H0r+TyQIpvvGEjBJlng3561H2aJs1S/fPAt5VGll
	UPyinDveRYwXojr10RaP0F/Gjj5XVQbw/tYcPWjGfMy/4nEGP4QvS58JznYNy2QNNa9DszTZqPK
	PNBZJmBPPzCjPUdWtxqFn+DBdT5yCXbzYPK9WstAjODp6UEmAddjjfmDJelhwMdxKu0yH9SFYqi
	H0CONaBpN6AiWLCLXir5k/2NpzrNDYmC8YngUqGuu/Bo582fywpQCZyw/jgkvfziTAVJrWNHEv5
	ci7LcmyGmpxStS3Qj7UQImwTa+XseR/FJ4sLm7TF6hJkWxuqT/WfdQMoIjj+giB65C09YETcDTR
	cezXVpD3w==
X-Received: by 2002:a17:903:32c5:b0:2b0:5795:9eb1 with SMTP id
 d9443c01a7336-2b06e21be32mr43509055ad.0.1773849037843; Wed, 18 Mar 2026
 08:50:37 -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> <CACgYNOK-QK6c2+LiO-Tgy48SJs12iV5XSM+Htpt5GSFrkZUAWg@mail.gmail.com>
In-Reply-To: <CACgYNOK-QK6c2+LiO-Tgy48SJs12iV5XSM+Htpt5GSFrkZUAWg@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Wed, 18 Mar 2026 11:50:00 -0400
X-Gm-Features: AaiRm50lu0J03JGIu1hXi_8ha60tlZYexLyTbZGQGxhvso3QTwn7P90yGBoqV7I
Message-ID: <CAEM=y+U2C7m6-uoPksR5ZTEzSO=KCvi3AjcQ0vD6uUH_am9=KA@mail.gmail.com>
Subject: "wrapped Taproot" from RIPEMD-160 collisions, Was: [bitcoindev] [BIP
 proposal] Pay to Schnorr Key Hash (P2SKH)
To: Saint Wenhao <saintwenhao@gmail.com>
Cc: "waxwing/ AdamISZ" <ekaggata@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000c9316d064d4e69ca"
X-Original-Sender: eth3rs@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=R4wGb8Xs;       arc=pass
 (i=1);       spf=pass (google.com: domain of eth3rs@gmail.com designates
 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=eth3rs@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 (/)

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

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
 =3D 2^45 terabytes
=3D ~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=E2=80=AFAM 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 simp=
ly
> 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 HASH16=
0
> to both scripts will give the same 160-bit value, then each party could u=
se
> 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 =
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 =3D=
 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 po=
int
>>> of not-only-historical interest that the original Schnorr signature des=
ign
>>> 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 o=
f
>>> considerable contention amongst various system designers, whether pubke=
y
>>> 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" muc=
h
>>> 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 bef=
ore
>>> .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that =
has
>>> big implications for perhaps the biggest application of Schnorr in Bitc=
oin,
>>> which is aggregation; aggregation in a bitcoin context means *aggregati=
ng
>>> arbitrary, new, ephemeral keys*, not keys previously recorded in some
>>> certificate registry or whatever. You're not going to get sensible vers=
ions
>>> of MuSig without pubkey prefixing, because you couldn't stop adversarie=
s
>>> 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 l=
ess
>>> 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 go=
ing 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 furt=
her
>>>> would be a good use of anyone's time.
>>>>
>>>> I want to thank everyone who took the time to read, review, and respon=
d.
>>>>
>>>> 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 mode=
l
>>>>> (no script spending, simple single-key payments) the witness efficien=
cy 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, tha=
t
>>>>> 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 p=
ushed
>>>>> in DER signatures, because of BIP-66, and as computing power is getti=
ng
>>>>> better and better, your signatures could be smaller in the future, wh=
ile 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 (comp=
act
>>>>>> 20-byte hash commitment, no script path, single-key payments), and t=
he only
>>>>>> change is replacing ECDSA with the same Schnorr signature scheme Tap=
root'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 efficie=
ncy 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. L=
ike
>>>>>> 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 t=
he time
>>>>>> comes, users migrate =E2=80=94 the same way P2PKH and P2WPKH users w=
ill 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 Ta=
proot 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 "dynami=
cally"
>>>>>>> chose whether to use the key-spend path or the script-spend path. Y=
our
>>>>>>> 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 quantu=
m
>>>>>>> upgrade at some point, this upgrade is kind of (in my personal
>>>>>>> interpretation) doubling down to the part that will eventually brea=
k.
>>>>>>>
>>>>>>> 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-sec=
ure 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
>>>>>>>>> well documented. I recommend you to read documentation first befo=
re
>>>>>>>>> attempting 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, mak=
ing outputs
>>>>>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspen=
t output.
>>>>>>>>>>
>>>>>>>>>> Neither type achieves both a compact output and a compact witnes=
s
>>>>>>>>>> simultaneously.
>>>>>>>>>>
>>>>>>>>>> =3D=3D The proposal =3D=3D
>>>>>>>>>>
>>>>>>>>>> P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 bytes,
>>>>>>>>>> same as P2WPKH). Spending requires a single 64-byte Schnorr sign=
ature.
>>>>>>>>>> Verification works by key recovery: given the signature (R, s) a=
nd 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 has=
h160(P.x)
>>>>>>>>>> matches the program. The sighash reuses the BIP341 transaction d=
igest, 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 an=
d
>>>>>>>>>> scalar multiplication compared to direct Schnorr verification. T=
his 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 alter=
native for
>>>>>>>>>> P2SKH.
>>>>>>>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but =
"P2TRKH"
>>>>>>>>>> has been suggested to emphasise Schnorr/taproot lineage. Opinion=
s welcome.
>>>>>>>>>>
>>>>>>>>>> Full draft:
>>>>>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab=
7e7218620be580dc/p2skh.md
>>>>>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/3482=
6
>>>>>>>>>>
>>>>>>>>>> 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=3Demail&utm_source=3Dfoot=
er>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --
>>>>>> 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-841=
2-489a77012038n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>>> .
>>>>>>
>>>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd6=
eecebb7ban%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/fc83173c-f4b3-4a2e-a662-dd=
6eecebb7ban%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/CACgYNOK-QK6c2%2BLiO-Tgy48SJ=
s12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48S=
Js12iV5XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.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/=
CAEM%3Dy%2BU2C7m6-uoPksR5ZTEzSO%3DKCvi3AjcQ0vD6uUH_am9%3DKA%40mail.gmail.co=
m.

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

<div dir=3D"ltr"><div dir=3D"ltr">Saint Wenhao,<br><br>&gt;=C2=A0

Also, I wonder if collisions in P2SH will be used as a &quot;wrapped Taproo=
t&quot;.<br><br>I love this idea. The cost to so this is about=C2=A02^81 no=
t 2^80.<br><br>You aren&#39;t trying to find any collision, you are trying =
to find a collision for Alice&#39;s script and Bob&#39;s script. If you a g=
iant lookup table of 2^80 Alice Script hashes, you could try Bob Script has=
hes 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 d=
o this in 2^80.5 calls, assuming HASH-160 has no cryptanalytic weaknesses t=
hat make collisions easier.<br><br>This lookup table would be absurdly huge=
:=C2=A02^80 * (20+12) bytes<br>=C2=A0=3D 2^45 terabytes <br>=3D ~100 trilli=
on 1 TB harddrives<br><br>You can use time-memory tradeoffs here. In fact t=
his=C2=A0is the same hash collision problem that colliderscript deals with.=
=C2=A0 See ColliderScript: Covenants in Bitcoin via 160-bit hash collisions=
 <a href=3D"https://eprint.iacr.org/2024/1802.pdf">https://eprint.iacr.org/=
2024/1802.pdf</a>=C2=A0appendix E and F in the CollidierScript paper for eq=
uations you can use to find an exact value.<br><br>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). Assumin=
g you built an ASICs for this, it would cost=C2=A0between $100,000 and $2 m=
illion in electricity per collision. This is much cheaper than the cost for=
 colliderscript because colliderscript must account for some other paramete=
rs that don&#39;t matter here.</div><div dir=3D"ltr"><br></div><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Wed, Mar 18, 2026 at 6:18=E2=80=AFAM Saint Wenhao &lt;<a href=3D"mailt=
o:saintwenhao@gmail.com">saintwenhao@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; You wer=
e of course in fact pubkey-prefixing here (with the hash-160 of P)<br><br>Y=
es, I also thought about that. But then, it means after around 2^80 operati=
ons, you could have a potential RIPEMD-160 collision in the future. Which a=
lso 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.<br><br>Also,=
 I wonder if collisions in P2SH will be used as a &quot;wrapped Taproot&quo=
t;. Because then, instead of building some MAST, it could be possible to si=
mply prepare a collision, and use older addresses in that way. Then, Alice =
can for example use &quot;&lt;pubkeyA&gt; OP_CHECKSIG&quot;, and Bob can us=
e &quot;&lt;time&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP &lt;pubkeyB&gt; OP_CHEC=
KSIG&quot;. 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 th=
e same P2SH address.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">wt., 17 mar 2026 o 20:01=C2=A0waxwing/ AdamISZ &lt;<a h=
ref=3D"mailto:ekaggata@gmail.com" target=3D"_blank">ekaggata@gmail.com</a>&=
gt; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div>Hi sashabeton,</div><div><br></div><div>Apologies - I didn&#39;t =
read your proposal carefully. You were of course in fact pubkey-prefixing h=
ere (with the hash-160 of P), so my entire saga about pubkey prefixing is n=
ot actually relevant!</div><div><br></div><div>(maybe someone found it inte=
resting tho&#39; , lol).</div><div><br></div><div>Cheers,</div><div>AdamISZ=
/waxwing</div><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">On Tuesday, March 17, 2026 at 3:00:50=E2=80=AFPM UTC-3 waxwing/ Ad=
amISZ 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"><di=
v>Hi sashabeton,</div><div><br></div><div>&gt; Honestly, this idea might ha=
ve 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 review sessions on IRC. I&#39;m su=
re others, including the taproot designers, discussed this issue well befor=
e I thought about it :)</div><div><br></div><div>Perhaps this clarifies it =
for other mailing list readers:</div><div><br></div><div>BIP340 Schnorr sig=
natures are the form of Schnorr signature which has what is commonly termed=
 &quot;pubkey prefixing&quot;; the challenge hash is e =3D H(R, P, m) with =
P the public key. This makes a pubkey recovery algorithm of the type that w=
e have in our legacy ECDSA signatures, impossible. 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 the time when ECDSA was being desi=
gned 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.</div><div><br></div><div>Pubkey prefixing makes all of the s=
ecurity reductions much more meaningful, since it can make the concept of &=
quot;resistant to forgery&quot; much more wide-ranging and powerful (in sho=
rt, imagine the idea that you can make up a schnorr signature for some arbi=
trary key that wasn&#39;t used before .. this is sorta kinda true for non-p=
ubkey-prefixed Schnorr). And that has big implications for perhaps the bigg=
est 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&#39;=
re not going to get sensible versions of MuSig without pubkey prefixing, be=
cause you couldn&#39;t stop adversaries making 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 and CISA, if you don&#39;t actuall=
y care about multisig for whatever reason; it could end up being very impor=
tant for Bitcoin scaling anyway), Schnorr is a lot less of an upgrade to ou=
r signing algorithm (though to be fair, still not nothing, it&#39;s on soun=
der theoretical foundations).</div><div><br></div><div>Cheers,</div><div>Ad=
amISZ/waxwing</div><div><br></div><div class=3D"gmail_quote"><div dir=3D"au=
to" class=3D"gmail_attr">On Tuesday, March 17, 2026 at 6:32:12=E2=80=AFAM U=
TC-3 sashabeton 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-lef=
t:1ex">Hi everyone,<br><br>After reading all the feedback, I think it&#39;s=
 time to accept that this proposal has no realistic path forward.<br><br>Fo=
r it to make sense, the new address type would need to be adopted by the en=
tire ecosystem almost instantly =E2=80=94 which is simply not going to happ=
en.<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 fur=
ther would be a good use of anyone&#39;s time.<br><br>I want to thank every=
one who took the time to read, review, and respond.<br><br><div class=3D"gm=
ail_quote"><div dir=3D"auto" class=3D"gmail_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;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">&gt; The goal is giving users who a=
re already happy with the P2WPKH model (no script spending, simple single-k=
ey payments) the witness efficiency of Schnorr<br><br></div><div dir=3D"ltr=
">If you have a DER signature, then it can take from 9 to 73 bytes. In Schn=
orr signatures, it is set to 64 or 65 bytes.<br><br>In practice, you can ha=
ve 71 bytes without grinding, which means, that by using a CPU to grind r-v=
alue 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 your private key to anyone else. I=
t would require around 2^33 operations, so it is doable on CPUs.<br><br>Whi=
ch 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 ju=
st staying with P2WPKH. And, as leading zeroes are not pushed in DER signat=
ures, because of BIP-66, and as computing power is getting better and bette=
r, your signatures could be smaller in the future, while in Schnorr signatu=
res, you won&#39;t have any way to go below 64 bytes.</div><br><div class=
=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">pon., 16 mar 2026 o 17:12=C2=A0sashabeton &lt;<a rel=3D"nofoll=
ow">sashabe...@gmail.com</a>&gt; napisa=C5=82(a):<br></div></div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To clari=
fy the design intent: P2SKH is not a stripped-down Taproot =E2=80=94 it is =
P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte h=
ash commitment, no script path, single-key payments), and the only change i=
s replacing ECDSA with the same Schnorr signature scheme Taproot&#39;s key-=
path uses. That&#39;s it.<br><br>The goal is giving users who are already h=
appy with the P2WPKH model (no script spending, simple single-key payments)=
 the witness efficiency of Schnorr without forcing them onto a 34-byte outp=
ut type designed for a richer feature set they don&#39;t need.<br><br>P2SKH=
 is not quantum-resistant =E2=80=94 I fully acknowledge this. Like P2WPKH, =
it relies on secp256k1 and will need to be migrated once post-quantum schem=
es are deployed in Bitcoin. But until that happens, it serves the same user=
s as P2WPKH today, just more efficiently. When the time comes, users migrat=
e =E2=80=94 the same way P2PKH and P2WPKH users will have to.<br><br><div c=
lass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Monday, 16 M=
arch 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" target=
=3D"_blank">bitcoindev+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&amp;utm_source=3Dfooter" target=3D"_blank">http=
s://groups.google.com/d/msgid/bitcoindev/CACgYNOK-QK6c2%2BLiO-Tgy48SJs12iV5=
XSM%2BHtpt5GSFrkZUAWg%40mail.gmail.com</a>.<br>
</blockquote></div></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/CAEM%3Dy%2BU2C7m6-uoPksR5ZTEzSO%3DKCvi3AjcQ0vD6uUH_am9%3DKA%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/bitcoindev/CAEM%3Dy%2BU2C7m6-uoPksR5ZTEzSO%3DKCvi3AjcQ0vD6uUH_a=
m9%3DKA%40mail.gmail.com</a>.<br />

--000000000000c9316d064d4e69ca--