public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ethan Heilman <eth3rs@gmail•com>
To: Brandon Black <freedom@reardencode•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Post Quantum Signatures and Scaling Bitcoin
Date: Fri, 4 Apr 2025 15:22:32 -0400	[thread overview]
Message-ID: <CAEM=y+UtU_FTX-bc6uRmJ1iwk_cNwQJOe-d0hGBrawewNiimJg@mail.gmail.com> (raw)
In-Reply-To: <Z_AoU94vMDskLJ4Z@console>

> I'm curious your thoughts on the long term incentive changes for node
runners of such a scheme.
> [...] Such a disjunction between the cost of transaction verification during
relay vs. during block validation also represents a further externality
imposed on node runners which is not compensated (as node runners do not
gain fees for verifying and relaying transactions, and their primary
benefit comes in the form of finality by verifying blocks).

That's an important question to figure out.
I don't frame the problem as the difference in costs between running a
full relay or block only. If we could make blocks-only nodes free to
run without changing the costs for full relay, I'd be in favor of
that. I frame it as running a full relay shouldn't be too expensive,
hopefully no more expensive than it is today.

In theory the transaction aggregation approach could help in two ways:

1. If most transactions are aggregated prior to entering the mempool
then we might be able to reduce verification costs for full relay and
only slightly increase the bandwidth costs.

2. Relay nodes could do the aggregation themselves for users and
collect fees for performing this service and performing relay. The
fact that aggregation is one way, once a relay node performs it,
another relay could not pull the transactions together, allowing each
step in the aggregation pipe to collect fees. I don't have a detailed
design for how this would work. Do you have any thoughts on how such a
design would work?




On Fri, Apr 4, 2025 at 2:43 PM Brandon Black <freedom@reardencode•com> wrote:
>
> Hi Ethan,
>
> Interesting idea for bringing PQ cryptography to bitcoin without
> sacrificing throughput or IBD cost.
>
> On 2025-04-04 (Fri) at 12:29:46 -0400, Ethan Heilman wrote:
> > 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'm curious your thoughts on the long term incentive changes for node
> runners of such a scheme.
>
> Currently, running a node in full relay vs. blocks only isn't a
> significant resource difference. Only the smallest of nodes operate in
> blocks only mode afaik. With a scheme like this, the delta would expand
> significantly, potentially weakening the transaction relay network.
>
> Such a disjunction between the cost of transaction verification during
> relay vs. during block validation also represents a further externality
> imposed on node runners which is not compensated (as node runners do not
> gain fees for verifying and relaying transactions, and their primary
> benefit comes in the form of finality by verifying blocks).
>
> All the best,
>
> --
> --Brandon

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUtU_FTX-bc6uRmJ1iwk_cNwQJOe-d0hGBrawewNiimJg%40mail.gmail.com.


  reply	other threads:[~2025-04-06 11:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04 16:29 Ethan Heilman
2025-04-04 17:17 ` Dustin Ray
2025-04-05 20:40   ` 'Eli Ben-Sasson' via Bitcoin Development Mailing List
2025-04-04 18:43 ` Brandon Black
2025-04-04 19:22   ` Ethan Heilman [this message]
2025-04-05 17:39 ` Matt Corallo
2025-04-14 13:47 ` Pieter Wuille
2025-04-14 19:35   ` Ethan Heilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEM=y+UtU_FTX-bc6uRmJ1iwk_cNwQJOe-d0hGBrawewNiimJg@mail.gmail.com' \
    --to=eth3rs@gmail$(echo .)com \
    --cc=bitcoindev@googlegroups.com \
    --cc=freedom@reardencode$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox