None of my comments insinuate that deals would not be public or that all users 
and all miners would not have access to this service.  The product/service I am 
working on would be public and anyone could participate.  A world in which 
there is no ability for users to have some level of certainty about access to 
future blockspace and the cost of that blockspace is not one that, imo, can 
scale to the levels that I believe we all hope to attain.  Blockspace 
can/should act like any other commodity (think corn or soybeans) in which 
sellers (miners) mitigate risk and lock in long term revenue streams, and 
consumers (users) can guarantee their future access and the cost of that 
access.  Blockspace acting as purely a real-time, spot market is not one that I 
feel is capable of scaling to global levels.  I am not disputing this should be 
done in public not private.  All of that said, my main point right now is that 
about keeping configurability and flexibility for template creators (and 
certainly node-runners too.)

From: Pieter Wuille <[email protected]>
Date: Wednesday, May 21, 2025 at 10:47 AM
To: Bob Burnett <[email protected]>
Cc: Sjors Provoost <[email protected]>, Bitcoin Development Mailing List 
<[email protected]>
Subject: Re: [bitcoindev] Removing OP_Return restrictions: Devil's Advocate 
Position
You don't often get email from [email protected]. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Hi Bob,

On Wednesday, May 21st, 2025 at 9:44 AM, Bob Burnett 
<[email protected]> wrote:

On your other point regarding non-standard, I think you may have misunderstood 
my point.  For me, the issue in the future in not about services for 
non-standard transactions but about giving users a mechanism whereby they can 
get assurances about future access and cost of block space.  For instance, a 
user of block space (ex. Swan, River, Coinbase) might know that they will have 
a lot of demand for block space in October because they are going to be doing a 
major marketing campaign then.  The campaign would result in a lot of UTXO 
consolidation and self-custody.  The problem for them is that sitting here in 
May they have no idea how much demand there will be for block space and what 
the cost of that block space will be.  By getting the right arrangement with a 
miner (or coalition of miners), they will be able to get guarantees of access 
to October block space and lock in cost for that space.   (While this exact 
scenario is just an example, I can say that I am already working on some 
similar things.)

I think this is a rather remarkable response, and it undermines any opinion you 
might have about transaction relay policy.

To me, the primary reason why I feel divergence between relay policy and the 
set of transactions actually being mined is worrisome is because it 
incentivizes private transaction submission to miners. If that becomes 
commonplace enough that a substantial portion of income is due to it, it may 
result in an inability for new small miners to enter the mining landscape in a 
permissionless manner, as they will not be competitive without income from 
private submission.

The presence of non-publicly-enforced business deals about future block space 
is a manifestation of the exact same danger, but arguably more imminent. I 
recognize the use case, but the demand for it, or rather the feasibility of 
obtaining it, sounds to me like an serious potential threat to Bitcoin. And I 
don't know what can really be done about it, except more decentralized mining.

Sorry to say, but if your point is "we don't care about the public network's 
relay policy, because we'll just mine what our big direct customers want 
anyway", then you are quite literally what we need to prevent.

--
Pieter

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/BY5PR03MB5171E2D9B1EE022DC9715E17969EA%40BY5PR03MB5171.namprd03.prod.outlook.com.

Reply via email to