path: root/64/a045ba0ad05ff817085916d0c4a94845a261fc

Delivery-date: Fri, 04 Apr 2025 09:34:43 -0700
Received: from mail-oi1-f186.google.com ([209.85.167.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRBGEUYC7QMGQEBQFRX5Q@googlegroups.com>)
	id 1u0k0A-0002wu-2v
	for bitcoindev@gnusha.org; Fri, 04 Apr 2025 09:34:43 -0700
Received: by mail-oi1-f186.google.com with SMTP id 5614622812f47-3fab1478893sf593981b6e.2
        for <bitcoindev@gnusha.org>; Fri, 04 Apr 2025 09:34:42 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1743784476; cv=pass;
        d=google.com; s=arc-20240605;
        b=cyE/u/0MCI+aOFoB8dcVvkG/A8wE11Xi6c2U4dAG8MH02xgbwbAct8ngMHsYaR1for
         67IIxvr0srxF6ViYSf0XrP6Kj78B676xkl3NMZLsDQpDbW/EoAFfxtddEXRHdGI0+Vwm
         I5Qc8n+eaIgIk95yRTyOt5NkuA//YmpiV1UF2UedWTzNNGoSh9WOxfJhKb27pxW8jASM
         w4uDdUVZaaquNioMiXLL5RkBZQtOVj0bsGQEirC8UuekpQa0g47rJUlpx8i6ZmhdeGgq
         QZwwp8zc17yRR56uiok6dIgAapNSWroRAAeD3JAnQv6vccRmW6TJxk7UNFStBRw0Bieg
         216w==
ARC-Message-Signature: i=2; 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:content-transfer-encoding:to
         :subject:message-id:date:from:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=UHt/ru/4xE27oDrHSmtbY1S8C2DRcZZMO0geH1h9/0k=;
        fh=Hc8uL8m6NW9bZgKqTlSAL7RCSoHDwtRJ0m0PYqC5EH8=;
        b=jPfqt5o06wp9EgFyqWR5mqPtMCWZKP7BdapxS1vP7Z6mO7f4R681SRgVHooSzcsIl4
         z/4DeYd+vm9Cfx1orsbgq2/wz9uPWof7pWxBSaFvU4BqMGQ5hhth21sFoc7iHKQI9Xcv
         wqjGo4PPIpc2bS0QI3Z41kH4ygEP/M5Jrf822wCjTZHyWQpQUjGyStPJPyUiXP2X9+Gh
         D1RWiLIfbMJ0J2fdLG7RzDYCryY2+gu14lKZBpBDgDi3AJOn5H0BonTJJeQ77U1AMNwI
         QmRTs+fOMP9zY0OCLRYqQW/g43dhMDwC44/HRnsrrQR6o3L2mTJghEfym6PIOTharow1
         QvuQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Tbzh9gKm;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52d 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=20230601; t=1743784476; x=1744389276; 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:content-transfer-encoding:to:subject:message-id
         :date:from:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=UHt/ru/4xE27oDrHSmtbY1S8C2DRcZZMO0geH1h9/0k=;
        b=b8Xf/O6tlvF+UM4KL2xEdXYoDXI4TNiiHaNbIjk9Rsd+6W6iz8oKWfeNh1lK291v95
         xAvUBP1MUL2N8M04UVlEufPQse4m4kA0oopjRpQQ2QwlHz8cwg0Z+oe2vwWnk3pVOhlS
         ZuLnMT03q/BxkIsDRlcoyITS8DnoaE7/hSY0BgeSoPNiflN9L3mTB/TNQxV2x1Oyrd/D
         mN68ZrZ9HOy7rfupIZmOgpyzF6Khqr4itumqnyWgKffe9painpjjfxAVDoEbbuaOPZl3
         vbBRylIvSwseNs8jwhDCo6xWTUvNbQhxG+zLXZm6h8nN5XO2ULWm6XlNVNKad4ArawL3
         6e6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1743784476; x=1744389276; 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:content-transfer-encoding:to:subject:message-id
         :date:from:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=UHt/ru/4xE27oDrHSmtbY1S8C2DRcZZMO0geH1h9/0k=;
        b=biuuLHFfLJo8cBrwAzj+KFk7uWQ8lcvLdEWINakrxlU+LW9OaVBfq54xtcLKgssDCY
         P1/M8c2D3oLi0mYdtjkO30DU1LISTqrcxZ5yJeU0WBQB+rPI5jcQ5/q0P6VTlMW6AHFU
         Uzi5r+C/hZgJv6VCwgCqcfF4Lv70cz1keMGUpVZ1uJ7idxPFXUsmy+wxZrUEOKuabL92
         Gzsk/62chgeHlJ6HBeN3BBzVTTEpr1qtA5YyHC98m2eKxZojPPWs+CWXCRLnUzZJknVW
         vZ6fqfHmK9zriuoO6woRTV5Au+Ovk8ZIrzK0Bx0Hso6z74OrB/PzzOAXFM7hb+DhwEx5
         CZdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1743784476; x=1744389276;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:to:subject:message-id
         :date:from:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=UHt/ru/4xE27oDrHSmtbY1S8C2DRcZZMO0geH1h9/0k=;
        b=aZNoT5noYrgxIZE44jwvuptbD9z7RHinghzkVlRfa3MP7UWYxMshBpsqr7nJPz7qQx
         vJbTSMOvo5tBL+xTJM17E8+Pag/Ue6yT5093hvf1YeuwBnsEwaw6wvgA6LSOJRzH6Kmk
         ROPSQSHd85wL93kxrWqSUBucaFf3LEXRxmXCzwFMjSViaXWU9HYUNq0GHHnZmXYhuaDP
         9tyDFhf9wenD0hsJWsgfU1c1VOUQsDQuKflmdiH1OrbfsrKLu3lvRglg2sOBJHzYpFUz
         acH1S8IKZX83Ix4YvNVX3uyVgtq718WCFi3RYrMD2P1cMFzbEZRQn38h13+cpFO0TkLp
         iOBw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVuRvTzWRvxH+bdXO9F4RlRTGSzr3K7uTAIsB9qhbGCg0R5VrZoiQmTaO5ypetavnL9E+ODv1SsO7Z6@gnusha.org
X-Gm-Message-State: AOJu0Yxigs/8R3JFysYMdU9WwTn/QrC/t6dSaKNrBE/fUAnZSjx2l5Th
	bH1Rf7UIBa+V+A6rNbYC+JeCbkhtwrUMaM0lAhfR/728z0XLcZot
X-Google-Smtp-Source: AGHT+IFMmmdx9OhDd945JQunUNxNfvKkhbyfuDzYd4VJsiBy731A/esf3ltmniaVB9ktvlGO2VZFbw==
X-Received: by 2002:a05:6808:6a96:b0:3fb:7114:4ba7 with SMTP id 5614622812f47-4004562003dmr2263969b6e.25.1743784476014;
        Fri, 04 Apr 2025 09:34:36 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJbyPx2U2KIduA1OFLqedv/cILoxyLRHXP2tf6OQFhmgw==
Received: by 2002:a4a:e904:0:b0:602:40ed:5c6f with SMTP id 006d021491bc7-60409e7069dls603214eaf.0.-pod-prod-06-us;
 Fri, 04 Apr 2025 09:34:32 -0700 (PDT)
X-Received: by 2002:a05:6808:3989:b0:3f9:aeb6:6eac with SMTP id 5614622812f47-40045620058mr2545655b6e.30.1743784472372;
        Fri, 04 Apr 2025 09:34:32 -0700 (PDT)
Received: by 2002:a05:600c:1c8e:b0:43d:85ca:231a with SMTP id 5b1f17b1804b1-43eb34435d3ms5e9;
        Fri, 4 Apr 2025 09:30:25 -0700 (PDT)
X-Received: by 2002:a05:600c:450d:b0:439:6118:c188 with SMTP id 5b1f17b1804b1-43ed0c6e894mr35410095e9.19.1743784223810;
        Fri, 04 Apr 2025 09:30:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1743784223; cv=none;
        d=google.com; s=arc-20240605;
        b=MtnY8HsXXsEJVR3Bw3HhzMeYiJlSfobP0Sa1aKpeHh5ng/RSfMpgsWcjrlxqQ1AX30
         AmKAd6IebBKXyx5/yvVd4VlAhpCjWZQ2uiHSgOwkFU6lX0Jvv9iMmQLWgdUvGgm445Vf
         hM40ttsER3eJIt84K4d1nbzuN3NBosC2C5JVZqALXXEj6K2W6UdY8BXrz47+z7SE2dys
         +S/GP6r9Gb/lndWImd5ozXGfwj4xRBou5lMe+MqhtwlbmJR8b/6BvA4Ujoed8zc7pfZv
         v1O8+BKKw3kK0mYsL9mMpZqKPY8zbuI4jXBELZSgzAAwU5fnqqwqbLD1JFCnPpxT3IWp
         Hd2w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:to:subject:message-id:date:from
         :mime-version:dkim-signature;
        bh=ycS484WHqyAQcdS80E4ZFGI3VJaOhDgqveSoiGnDt/k=;
        fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
        b=Nrn/IOBvKQFdHe4eW4b1vAcbwMFoJ1QGqtKqGVj95YRVS72jSNSGE1vn2vOuNj1gI1
         Zvw/wuF9ctQm4htbjHo6iWMtD3mCvgKTNLRdq8MPDHzHGwSd/WEkldm1UwExFCqwsEWA
         m9/v/UO2MqEYQwv3bYbobUFOW2HACQdATFKnlUf+ksOEggxG87uWogDFvVlNfBZsd20F
         kuS9j3KA0bGsBoh+UKJKmX8I34u2aLbuXOY1wc1P/ZsoLcJxtyhppaPJKfKQWn2svUEe
         cTBJnx3EKXq5uPysNbfIvCh1bFyIwVNxVHkpRUsMkw3nJbwg18EMV4rQ3Z1IzjPiMpR0
         Tp1g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Tbzh9gKm;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52d 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-ed1-x52d.google.com (mail-ed1-x52d.google.com. [2a00:1450:4864:20::52d])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43ea97959f7si6709335e9.1.2025.04.04.09.30.23
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 04 Apr 2025 09:30:23 -0700 (PDT)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) client-ip=2a00:1450:4864:20::52d;
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5e5c9662131so3632690a12.3
        for <bitcoindev@googlegroups.com>; Fri, 04 Apr 2025 09:30:23 -0700 (PDT)
X-Gm-Gg: ASbGncsCfgPKZ9JAw1XG91I4Jz7/+6RrwTEkwYSHeZJfrhkW7c1RrX2oT6FY5faeV9S
	UbNusHUMo1l52okdvSN0Rt6f4H5wBkN005DBnlF7XVMWgVtuAE8GC6RCdUXAlh718XIOS2O5+dQ
	mO+K4MqEe3wX3KpXqEN8Hh1et14oE=
X-Received: by 2002:a17:907:3e10:b0:ac3:8790:ce75 with SMTP id
 a640c23a62f3a-ac7d6cbd72bmr312830966b.10.1743784222758; Fri, 04 Apr 2025
 09:30:22 -0700 (PDT)
MIME-Version: 1.0
From: Ethan Heilman <eth3rs@gmail.com>
Date: Fri, 4 Apr 2025 12:29:46 -0400
X-Gm-Features: ATxdqUFX8GEo2aDHYpM_T81yVkwXSV3DSd11guvPY7fSwP6YEtkD9fwmBdbc83I
Message-ID: <CAEM=y+XMLuGH-MAfkYanfbU3Ynduw54jDVguKxgO2xEtnSEkZg@mail.gmail.com>
Subject: [bitcoindev] Post Quantum Signatures and Scaling Bitcoin
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=Tbzh9gKm;       spf=pass
 (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52d 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 (/)

I strongly believe Bitcoin will need to move to PQ signatures in the
near future. The rest of this email is premised on this belief.

PQ (Post Quantum) signatures present a problem for Bitcoin:

First, they are large. Of the three proposed in BIP-360 [0], the
smallest is 1.5kb for the public key + signature [1]. Without a
discount this represents a massive reduction in Bitcoin's transaction
volume due to the increase in transaction size of Bitcoin payment
using such signatures.
- Second, even if we discount PQ signatures and public keys so that
the maximum number of transactions that can fit in a block is
unchanged we still have the problem that these blocks and transactions
will be an order of magnitude bigger. If it is the case that we can
handle these extra bytes without degrading performance or
decentralization, then consider the head room we are giving up that
could be used for scalability.

Beyond this there is also the risk that techniques could be developed
to encode JPEGs and other data in these discounted PQ signatures or
public keys. BIP-360 takes steps to make an abuse of this discount
more difficult by requiring that a PQ signature and public key can
only be written to the blockchain if they verify. We do not need PQ
Signatures to be completely =E2=80=9CJPEG resistant=E2=80=9D, they just nee=
d PQ
signatures to not enable significantly cheaper storage than payments.
The degree to which the proposed PQ signature algorithms resist being
repurposed as a storage mechanism is an open question and worth
investigating.

If it turned out PQ signatures could be used to encode data very
cheaply, then Bitcoin faces the dilemma that if you discount PQ
signatures, you make the JPEG problem worse and may price out the
payment use case. If you don't discount PQ, you price out most people
from sending payments in Bitcoin since non-PQ witness data can be used
for storage

I want to draw the community's attention to a solution that could not
only address these problems but also increase Bitcoin=E2=80=99s scalability
(and privacy):

Non-interactive Transaction Compression (NTC) for Transactions
supporting PQ signatures. This is sometimes called Non-Interactive
Witness Aggregation (NIWA) [2].

This would require a new transaction type supporting PQ signatures.
The miner of a block would then pull out the signatures and hash
pointers from transactions to compress transaction data and
non-interactively aggregate all the PQ signatures in all the
transactions in a block, replacing them with one big STARK (STARKS are
a form of SNARK which is PQ). This would make PQ signatures
significantly smaller and cheaper than ECDSA and schnorr signatures.

Consider the following back of the envelope math:

2 bytes per Input =3D 2 bytes per TXID, 0 bytes per signature
37 bytes per output =3D 32 bytes pubkey hash + 5 bytes value (max 2.8m
BTC per output)

1-input-2-output transaction would be: 2 + 2*37 =3D 76 bytes
(4,000,000/76)/(60*10) =3D ~87 txns/sec

You could shave some bytes off the value, or add some bytes to the
TXID. [3] provides a more detailed estimate, proposing 113.5 weight
units (WU) for a 1-input-2-output transaction with no address reuse.
However it does not consider TXID compression. If desired an
account-based model could push this even further to 12 bytes per
transaction per block [4]. This would enable approximately
4,000,000/(12*60*10) =3D 555 txns/second.

A secondary benefit of having on-chain PQ payments only be ~76 bytes
in size is that it fundamentally changes the pricing relationship
between payments and on-chain JPEG/complex contracts. The problem with
on-chain JPEGs is not that they are possible, but that they are price
competitive with payments. At ~76 bytes per payment or better yet ~76
bytes per LN channel open/close, JPEGs no longer present the same fee
competition to payments as payments become much cheaper.

Such a system would present scaling issues for the mempool because
prior to aggregation and compression, these transactions would be 2kb
to 100kb in size and there would be a lot more of them. It is likely
parties producing large numbers of transactions would want to
pre-aggregate and compress them in one big many input, many output
transactions. Aggregating prior to the miner may have privacy benefits
but also scalability benefits as it would enable cut-throughs and very
cheap consolidation transactions. ~87/txns a second does not include
these additional scalability benefits.

Consider an exchange that receives and sends a large number of
transactions. For instance between block confirmations customers send
the exchange 10 1-input-2-output transactions in deposits and the
exchange sends out 10 1-input-2-output transactions in withdrawals.
The exchange could consolidate all of the outputs paying the exchange,
including chain outputs, into one output and do the same for inputs.
This would reduce not just size, but also validation costs.

(10 * 2 + 20 * 2 * 37) + (10 * 2 + 20 * 2 * 37)  =3D 3000 bytes
becomes
(10 * 2 + 11 * 2 * 37) + (2 + 11 * 2 * 37) =3D 1650 bytes

If constructing these proofs turned out to be as expensive as
performing POW, it would make block generation not progress free.
Essentially you'd have a two step POW: proof generation and then the
actual POW. Such a scenario would be very bad and cause the biggest
miner to always be the one that generates blocks. A critical
assumption I am making is that such proof generation is not
particularly expensive in the scheme of POW. I am optimistic that
proof generation will not be this expensive for two reasons

There are PQ signature schemes which support non-interactive
aggregation such as LaBRADOR [5]. Thus, the STARK wouldn=E2=80=99t need to
perform the block-wide signature aggregation and would only need to
perform transaction compression, cut throughs and consolidation.

We could make use of recursive STARKs [8] to allow miners to
parallelize proof generation to reduce latency or to decentralize
proof generation. Users creating transactions could perform
non-interactive coinjoins with other users or settlement/batching.
This would not only take proof generation pressure off of the miners
and reduce the strain on the mempool but in some circumstances it
would provide privacy if used with payjoin techniques like receiver
side payment batching [7].

The approach we are proposing treats the STARK the miner produces as
free from a blocksize perspective. This is important for bootstrapping
because it means that fees are significantly cheaper for a
transaction, even if it is the only compressed transaction in the
block. This encourages adoption. Adoption helps address the chicken
and egg problem of wallets and exchanges not investing engineering
resources to support a new transaction type if no one is using it and
no one wants to use it because it isn't well supported. By having a
single format, built into the block we both accelerate the switch over
and prevent a fragmented ecosystem that might arise from doing this in
Bitcoin script. Fragmentation reduces the scalability benefits because
validators have to validate multiple STARKs and reduces the privacy
benefits because there are many coinjoins, rather than each being a
coinjoin.

Even if our approach here turns out to be infeasible, we need a way to
reduce the size of PQ signatures in Bitcoin. The ability to move
coins, including the ability to move coins that represent JPEGs, is
the main functionality of Bitcoin. If we make storage/JPEG too price
competitive with the ability to transfer coins, we destroy that
essential functionality and decrease the utility of Bitcoin for
everyone. Currently moving coins securely requires at least one 64
byte signature, which is an unfortunate tax on this most vital of all
use cases. I believe removing that tax with signature aggregation will
be beneficial for all parties.

Consider the world of PQ signatures in Bitcoin without STARKs:
 - The large size of PQ signatures will make it more expensive for
users to use them prior to the invention of a CRQC (Cryptographically
Relevant Quantum Computer). This means that most outputs will not be
protected by PQ signatures. Once a CRQC arises there will be a rush to
move funds under the protection of PQ signatures but due to the large
size of PQ signatures the fees will be too expensive for most outputs.
Users will instead need to move their funds to centralized custodial
wallets that can use a small number of outputs. In such a world it
will be much harder and expensive to self-custody.
- Without a solution here the large sizes of PQ signatures will limit
Bitcoin's functionality to move coins using on-chain payments. This
will also favor centralized custodians and erode the decentralized
nature of Bitcoin.

None of this is an argument against adopting BIP-360 or other PQ
signatures schemes into Bitcoin. On the contrary, having PQ signatures
in Bitcoin would be a useful stepping stone to PQ transaction
compression since it would allow us to gain agreement on which PQ
signature schemes to build on. Most importantly, in the event of a
CRQC being developed it will be far better to have uncompressed PQ
signatures in Bitcoin than none at all.

Acknowledgements:
These ideas arose out of correspondence with Hunter Beast. I want to
thank Neha Narula, John Light, Eli Ben-Sasson for their feedback,
Jonas Nick for his feedback and his idea to use LaBRADOR for signature
aggregation, Tadge Dryja for suggesting the term =E2=80=9CJPEG resistance=
=E2=80=9D and
his ideas around its feasibility. I had a number of fruitful
discussions over lunch with members of the MIT DCI and on the Bitcoin
PQ working group. These acknowledgements should not be taken as an
agreement with or endorsement of the ideas in this email.

[0]: Hunter Beast, BIP-360: QuBit - Pay to Quantum Resistant Hash
(2025) https://github.com/bitcoin/bips/pull/1670/files#
[1]: Benchmark Report: Post-Quantum Cryptography vs secp256k1
https://github.com/cryptoquick/libbitcoinpqc/blob/main/benches/REPORT.md
[2]: Ruben Somsen, SNARKs and the future of blockchains (2020)
https://medium.com/@RubenSomsen/snarks-and-the-future-of-blockchains-55b820=
12452b
[3]: John Light, Validity Rollups on Bitcoin (2022)
https://github.com/john-light/validity-rollups/blob/main/validity_rollups_o=
n_bitcoin.md
[4] Vitalik Buterin, An Incomplete Guide to Rollups (2021)
https://vitalik.eth.limo/general/2021/01/05/rollup.html
[5]: Aardal, Aranha, Boudgoust, Kolby, Takahashi, Aggregating Falcon
Signatures with LaBRADOR (2024) https://eprint.iacr.org/2024/311
[6]: Gidi Kaempfer, Recursive STARKs (2022)
https://www.starknet.io/blog/recursive-starks/
[7]: Dan Gould, Interactive Payment Batching is Better (2023)
https://payjoin.substack.com/p/interactive-payment-batching-is-better
[8] John Tromp, Fee burning and Dynamic Block Size (2018)
https://lists.launchpad.net/mimblewimble/msg00450.html

--=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%2BXMLuGH-MAfkYanfbU3Ynduw54jDVguKxgO2xEtnSEkZg%40mail.gmail.com.