Delivery-date: Mon, 14 Apr 2025 06:54:25 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.21 as permitted sender) client-ip=109.224.244.21;
Date: Mon, 14 Apr 2025 13:47:31 +0000
To: Ethan Heilman <eth3rs@gmail.com>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Post Quantum Signatures and Scaling Bitcoin
Message-ID: <p8kWp-qhHYIB-nMWGHI5GJ65j2Ve_apGJXG3QByimJrGHKcyrfZII1OG0I40KJMCyeV-HDuhLfg-29S3nfKu1k9cUbvtJ_N5n2x9jmopRxA=@wuille.net>
In-Reply-To: <CAEM=y+XMLuGH-MAfkYanfbU3Ynduw54jDVguKxgO2xEtnSEkZg@mail.gmail.com>
References: <CAEM=y+XMLuGH-MAfkYanfbU3Ynduw54jDVguKxgO2xEtnSEkZg@mail.gmail.com>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Ethan,

thank you bringing this up. I'm unconvinced about the practicality, but I'm=
 happy to see thinking and discussion in this area.

Two points addressed below:

On Friday, April 4th, 2025 at 12:29 PM, Ethan Heilman <eth3rs@gmail.com> wr=
ote:

> 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.

I don't disagree with the overall point raised here, but I do think it's wo=
rth distinguishing between the "size" (bandwidth/storage) and "computation"=
 (CPU/IO) aspects of scalability.

If it turns out to be the case that PQ schemes need more on-chain size, but=
 have lower per-byte computation cost, a reasonable argument could be made =
that a higher discount factor for PQ data is acceptable. I don't know what =
the trade-off here ought to be, and this does not diminish your "JPEG resis=
tance" argument, but I did want to point out that just counting size isn't =
the only constraint here.

> 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.

I don't think pre-aggregation (beyond a single-transaction-wide one) is rea=
listic, as it effectively breaks in-mempool transaction replacement, turnin=
g every pre-aggregated group of transactions that is being relayed together=
 into an atomic package that must be taken or not as a whole. Consider for =
example the case where transactions P, C1, and C2 are relayed, with C1 and =
C2 depending on P. One node sees P and C1, but not C2, they may pre-aggrega=
te prior to relay. Another node sees P and C2, but not C1, they may pre-agg=
regate those prior to relay. These two packages (P+C1, P+C2) cannot be comb=
ined, so we've effectively forced the network/miners to choose between one =
of C1 or C2, unless the individual transactions are still available somewhe=
re.

I fear this is a very fast way to cause mining without direct-to-miner tran=
saction submission from users to become uncompetitive, making entering the =
mining business permissioned, and effectively removing the point of having =
a decentralized consensus mechanism in the first place.

--=20
Pieter

--=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/=
p8kWp-qhHYIB-nMWGHI5GJ65j2Ve_apGJXG3QByimJrGHKcyrfZII1OG0I40KJMCyeV-HDuhLfg=
-29S3nfKu1k9cUbvtJ_N5n2x9jmopRxA%3D%40wuille.net.