From: Bob Burnett <bob.burnett@barefootmining•com>
To: Pieter Wuille <bitcoin-dev@wuille•net>
Cc: Sjors Provoost <sjors@sprovoost•nl>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position
Date: Wed, 21 May 2025 17:19:26 +0000 [thread overview]
Message-ID: <BY5PR03MB5171E2D9B1EE022DC9715E17969EA@BY5PR03MB5171.namprd03.prod.outlook.com> (raw)
In-Reply-To: <vi5JgqhluYrppUFAXJ_5OKePwUkfF1u5Mdtdc89NUziVAd6hElH5D27rjXA25Kolsh4vbWoWbij6-uax3Ws60T1jZ9UEO35UPcpGVP5XYvk=@wuille.net>
[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]
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 <bitcoin-dev@wuille•net>
Date: Wednesday, May 21, 2025 at 10:47 AM
To: Bob Burnett <bob.burnett@barefootmining•com>
Cc: Sjors Provoost <sjors@sprovoost•nl>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position
You don't often get email from bitcoin-dev@wuille•net. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Bob,
On Wednesday, May 21st, 2025 at 9:44 AM, Bob Burnett <bob.burnett@barefootmining•com> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/BY5PR03MB5171E2D9B1EE022DC9715E17969EA%40BY5PR03MB5171.namprd03.prod.outlook.com.
[-- Attachment #2: Type: text/html, Size: 15480 bytes --]
next prev parent reply other threads:[~2025-05-21 17:24 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-03 5:14 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-01 3:01 ` Anthony Towns
2025-05-02 18:56 ` Greg Tonoski
2025-05-05 6:04 ` Bitcoin Error Log
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
2025-05-05 21:45 ` Peter Todd
2025-05-05 23:55 ` Greg Maxwell
2025-05-25 15:53 ` waxwing/ AdamISZ
2025-05-20 16:26 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-20 23:12 ` Greg Maxwell
2025-05-21 2:10 ` Bob Burnett
2025-05-21 7:41 ` [bitcoindev] " Sjors Provoost
2025-05-21 13:38 ` Bob Burnett
2025-05-21 14:47 ` Pieter Wuille
2025-05-21 17:19 ` Bob Burnett [this message]
2025-05-21 17:52 ` Pieter Wuille
2025-05-21 18:12 ` Bob Burnett
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-05 9:18 ` Anthony Towns
2025-05-05 21:34 ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
2025-05-06 8:56 ` Sjors Provoost
2025-05-07 20:42 ` James O'Beirne
2025-05-02 20:43 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
2025-05-04 20:04 ` Nagaev Boris
2025-05-05 11:42 ` Greg Maxwell
2025-05-05 14:32 ` Nagaev Boris
2025-05-05 21:30 ` Peter Todd
2025-05-05 14:05 ` Greg Maxwell
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>
2025-05-07 1:20 ` pithosian
2025-05-07 11:32 ` Greg Maxwell
[not found] ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
2025-05-07 16:55 ` pithosian
2025-05-12 13:47 ` [bitcoindev] " Anthony Towns
2025-05-14 15:54 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
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=BY5PR03MB5171E2D9B1EE022DC9715E17969EA@BY5PR03MB5171.namprd03.prod.outlook.com \
--to=bob.burnett@barefootmining$(echo .)com \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=sjors@sprovoost$(echo .)nl \
/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