> 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 <free...@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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUtU_FTX-bc6uRmJ1iwk_cNwQJOe-d0hGBrawewNiimJg%40mail.gmail.com.
