* [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
@ 2025-05-24 21:07 Jonathan Voss
2025-05-27 14:16 ` Pieter Wuille
2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
0 siblings, 2 replies; 7+ messages in thread
From: Jonathan Voss @ 2025-05-24 21:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5806 bytes --]
It seems to me that most participants in the current debate/controversy
agree (or at least once previously agreed) with the premise that using the
Bitcoin network for storing non-monetary data is an unintended use case for
the Bitcoin protocol. The original compromise was to place a hash within an
OP_RETURN so that people could commit to some data using the "distributed
timestamp server" in a way that could be dropped from the UTXO set.
Promulgation of the data so committed was left as an exercise for the
person using OP_RETURN, and some use cases (e.g. OpenTimestamps) do not
require it. However, the recent discussion premised upon Citrea's
Clementine Bridge evidences primarily that the relaying capabilities of the
Bitcoin network itself are sufficiently useful for L2 designers that there
is an incentive to bypass standardness restrictions for the sake of
reliably promulgating data -- at least in the case of Citrea, they say they
need to quickly and widely disseminate 140+ bytes of arbitrary ZKP data to
recover from an invalid protocol state, and the utility of that ZKP data
very quickly decreases after it has been confirmed and processed. The
community is split between those who want to do something to mitigate the
harm of stuffing arbitrary data into non-provably unspendable taproot
outputs and those who do not want to engage in the caching in-mempool and
promulgation of non-monetary data.
There is nothing in the Bitcoin protocol to incentivize or compensate node
operators for storing and relaying this data, so to align incentives, I
propose adding a configurable data blob relay service to the Bitcoin
network protocol with the following properties:
1) Each blob relayed must have a sha256 (or double sha256, whichever is
easier to implement) matching an OP_RETURN output contained within a valid
txn in the mempool.
2) Each blob relayed must have a length of X bytes or less (default of 1 KB
to comfortably sit within most MTUs). Optionally, blobs above this size
could require an additional burn fee, or this could be uncapped.
3) The relevant txn in the mempool must contain a single OP_RETURN with
exactly the bytes 0xFFFFFFFFFFFFFFFF followed by the blob hash.
4) The relevant txn in the mempool must burn sats at a configurable rate of
sats/100 bytes of blob size + a rate of sats per txn output by assigning
those sats to the OP_RETURN output. (Defaults should be something low like
20 and 50, respectively.)
5) The relevant txn in the mempool must pay a fee rate of at least the
average fee rate of the previous 10 blocks. If that average fee rate rises
before the txn is confirmed, the blob can be dropped from the cache or
given a higher probability of being pruned.
The data blob will then be cached on nodes and remain there as long as the
relevant txn is still valid according to the above rules and has not been
confirmed by more than 5 blocks. Thereafter, the probability it is dropped
from the cache will be semi-proportional to the inverse of the burned fee
rate: sort blobs by ascending number of confirmations and descending burn
rate, then pop from the list and drop from the cache until the cache size
limit is reached. (Cache size limit will be configurable, with a default of
1 GB.)
The burning of sats compensates node operators through deflation (assuming
that most node operators own bitcoins), aligning the incentives. The
minimum fee rate requirement prevents data blobs from sticking around in
perpetuity for transactions that are unlikely to be included in blocks,
also incentivizing miners to mine these transactions quickly enough that
the data can be dropped from the relay cache reasonably quickly. If
necessary, probabilistic sharding could be accomplished during the cache
pruning phase using rendezvous hashing to create an additional sorting
metric that sorts all matching blobs to the front of the list or applies a
modifier to another sorting metric; i.e. rendezvous hash hit results in a
lower index thus reducing the likelihood of the blob being dropped.
Then merge the data carrier style changes from Luke-jr to filter
inscription reveal transactions to disincentivize misusing the blockchain
for replicating ephemeral data. By providing a reliable relay mechanism,
anyone who previously used inscriptions can adapt their protocol to
indefinitely store the arbitrary data relayed by the network and just point
at the OP_RETURN to prove the data commitment made it onto the Bitcoin
blockchain or re-broadcast the blob in a new compliant txn. The
inscription+ordinals system can then be adapted accordingly since it is a
contrived system anyway: either require the committed data to specify the
index of the output to inscribe + the inscribed data, or just assign it to
the first sat of the first non-OP_RETURN output.
This relay policy upgrade would require at a minimum a new feature bit flag
in the version message, a new inv_vector type, and a new message type. A
high-bandwidth mode optimization could be to transmit the txn and matching
blob in a single new message type, but having nodes request the blob after
parsing a valid txn for this system would probably be sufficient. All
parameters can be tweaked, but I think the concept is reasonably solid.
What do y'all think? Would such a system even be worth pursuing
conceptually as part of a compromise to resolve this debate?
--
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/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6221 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-24 21:07 [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss
@ 2025-05-27 14:16 ` Pieter Wuille
2025-05-27 16:40 ` Jonathan Voss
2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
1 sibling, 1 reply; 7+ messages in thread
From: Pieter Wuille @ 2025-05-27 14:16 UTC (permalink / raw)
To: Jonathan Voss; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5097 bytes --]
Hi Jonathan,
On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss <k98kurz@gmail•com> wrote:
> It seems to me that most participants in the current debate/controversy agree (or at least once previously agreed) with the premise that using the Bitcoin network for storing non-monetary data is an unintended use case for the Bitcoin protocol.
I believe that is fair.
> The community is split between those who want to do something to mitigate the harm of stuffing arbitrary data into non-provably unspendable taproot outputs and those who do not want to engage in the caching in-mempool and promulgation of non-monetary data.
Do you mean "and those who *do* want to engage in caching ..."? If so, I think this misses the point somewhat. My view isn't that I *want* (or want others) to cache/relay non-financial transactions. It's that I believe that intentionally instituting or maintaining a relay policy that does not match what is making it reliably into blocks anyway is both:
- largely ineffective (because people can create software with other policies, or submit directly to miners)
- harmful on itself (because it slows down block propagation, breaks various DoS protections in relay by being unable to reason about what is likely to be confirmed, hurts fee estimation, and makes it more profitable for miners to offer private submission which if widely adopted would hurt the ability for smaller miners to enter the market).
While the benefit, even if effective, is minimal: blocks are reliably full, and were reliably full long before data-storage schemes became popular, thus nodes are processing the same amount of data anyway. In fact, nodes with policies that diverge from block content will process more data, as to them, blocks will contain more unexpected transactions that they still have to process anyway.
My dislike for non-financial use is/was twofold, and neither case is really aided by diverging relay policies today:
- Often a bad fit for the technology, chosen because of ease of design ("just dump your backups on chain"), but would due to inefficiency of the design by priced out sooner or later anyway. This was far more an issue when demand for block space was low, and blocks were not reliably full. And this was also where the existing OP_RETURN policies originated: as a way to discourage building solutions that used the very cheap block space at the time, as it wouldn't last anyway. This is far less a concern today, because block space prices are higher, and more alternatively and more appropriate technologies are commonplace.
- Because it's a use case driven by collateral hype ("NFTs on Bitcoin!") which I feel are dumb, and perhaps hurts Bitcoin's reputation by association with it. However, I very much believe - and hope - Bitcoin can be used effectively for things I (or you, or others) do not approve of. Censorship resistance is the entire point of the design, and it cuts both ways.
Perhaps this was all clear, and your statement was just aiming to be brief, but I wanted to make sure you're not misinterpreting the view as *liking* non-financial transactions.
> There is nothing in the Bitcoin protocol to incentivize or compensate node operators for storing and relaying this data, so to align incentives, I propose adding a configurable data blob relay service to the Bitcoin network protocol with the following properties:
I think you are under the mistaken impression that the disagreement is about what set of transactions should be acceptable on the network, and then crafting a policy that matches that.
To me (and this is just my impression, I don't want to speak for anyone else) the core dispute is about whether a diverging relay policy, even if just mildly effective in discouraging use cases, is beneficial or harmful to the network. What you're suggesting is instituting even more policy, which is an even larger burden to comply with than what exists today, even if it somehow expands what use cases are permitted. To me, that is worse than doing nothing, as it'll even more effectively encourage people to bypass any software implementing such policies, whether that is by the development of even easier and cheaper ways to submit directly to miners, or by incentivizing the development or promotion of software that doesn't have these policies.
> What do y'all think? Would such a system even be worth pursuing conceptually as part of a compromise to resolve this debate?
I do not consider this to be a compromise at all. It is embracing the failed notion that policy should only relay transactions that people like.
--
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/jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 7037 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-24 21:07 [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss
2025-05-27 14:16 ` Pieter Wuille
@ 2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-05-27 16:51 ` Jonathan Voss
1 sibling, 1 reply; 7+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-05-27 16:02 UTC (permalink / raw)
To: Bitcoin Development Mailing List; +Cc: Jonathan Voss
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On Sat, May 24, 2025 at 5:33 PM Jonathan Voss <k98kurz@gmail•com> wrote:
> However, the recent discussion premised upon Citrea's Clementine Bridge
> evidences primarily that the relaying capabilities of the Bitcoin network
> itself are sufficiently useful for L2 designers that there is an incentive
> to bypass standardness restrictions for the sake of reliably promulgating
> data -- at least in the case of Citrea, they say they need to quickly and
> widely disseminate 140+ bytes of arbitrary ZKP data to recover from an
> invalid protocol state, and the utility of that ZKP data very quickly
> decreases after it has been confirmed and processed.
Does your proposal actually solve this problem? Posting the 140 bytes of
data to the blockchain works as a public bulletin board because the actual
data within the block is what is ultimately guaranteed to be disseminated
to all participants. With your proposal, a transaction with an OP_RETURN
containing a hash of data could end up being mined without the relevant
transaction ever even being relayed through the Bitcoin network.
--
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/CAMZUoK%3Dmux6u%3Df_b0yLb6nvJp41H7iPg7G%2BdLO5xT94kbDybjQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2090 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-27 14:16 ` Pieter Wuille
@ 2025-05-27 16:40 ` Jonathan Voss
0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Voss @ 2025-05-27 16:40 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6912 bytes --]
Hi Pieter,
My goal was to design an additional relay service that would allow for a
more integrated and seamless use of existing, noncontroversial capabilities
so that the controversial uses would be obsoleted, thus rendering the
current controversy moot. I will address your points below.
On Tuesday, May 27, 2025 at 11:49:00 AM UTC-4 Pieter Wuille wrote:
Do you mean "and those who *do* want to engage in caching ..."? If so, I
think this misses the point somewhat. My view isn't that I *want* (or want
others) to cache/relay non-financial transactions. It's that I believe that
intentionally instituting or maintaining a relay policy that does not match
what is making it reliably into blocks anyway is both:
- largely ineffective (because people can create software with other
policies, or submit directly to miners)
- harmful on itself (because it slows down block propagation, breaks
various DoS protections in relay by being unable to reason about what is
likely to be confirmed, hurts fee estimation, and makes it more profitable
for miners to offer private submission which if widely adopted would hurt
the ability for smaller miners to enter the market).
Relay policy is largely effective. If not, then why are there
proportionally so few non-standard transactions in blocks? Why is the dust
limit generally respected if it is an ineffective relay policy? While I
agree with the sentiment that inconsistency between relay policy and
consensus is not ideal, the reality is that we live in a non-ideal world.
Relay policies have been historically adopted out of pragmatic concerns.
With regard to fee estimation, is the mempool actually used for this in
practice? I have heard conflicting claims on this topic and have not yet
dived into the Core source code to figure out this particular issue. The
most recent argument I have heard about this is that Core actually uses
confirmed transactions from recent blocks to estimate fees rather than the
mempool; if that is indeed the case, then the fee estimation argument is
pointless; if not, then it is a marginal concern -- in practice, fee
estimation has always sucked, and the case of it possibly sucking a bit
more is not a substantial change in the status quo.
For slowing block propagation, is this a realistic concern? Has anyone done
any simulation studies or analyzed real world data to determine the impact
on block propagation of datacarrier-size relay filters? If so, I would
appreciate a citation. But if not, then this remains a purely theoretical
problem.
Moreover, if Core decides to make filters less restrictive and thereby
encourage the promulgation of transactions that do not comply with existing
standardness filters, does that not make the problem worse by increasing
the number of previously non-standard transactions that old nodes will have
to download to verify new blocks? Does this not force node operators to
upgrade for the sake of maintaining performance? By enabling the
propagation of previously non-standard transactions, logically the result
will be more of these transactions entering blocks, which just makes the
problem worse without full compliance of the whole network in updating
relay policy.
While the benefit, even if effective, is minimal: blocks are reliably full,
and were reliably full long before data-storage schemes became popular,
thus nodes are processing the same amount of data anyway. In fact, nodes
with policies that diverge from block content will process more data, as to
them, blocks will contain more unexpected transactions that they still have
to process anyway.
If a relay service similar to the one I proposed is implemented, then there
will be no need for this additional data to be downloaded to verify blocks.
All that nodes will need to download is the transaction containing the
OP_RETURN commitment, which they will already have because it fits all
existing standardness filters. The additional relay service only needs ~10%
node adoption to be sufficiently reliable for L2 protocols to utilize, and
it will not negatively impact the performance of nodes that do not opt-in
to providing this additional relay service.
Perhaps this was all clear, and your statement was just aiming to be brief,
but I wanted to make sure you're not misinterpreting the view as *liking*
non-financial transactions.
Understandable. The primary concerns regarding non-financial transactions
should be technical rather than aesthetic. On this we agree.
I think you are under the mistaken impression that the disagreement is
about what set of transactions should be acceptable on the network, and
then crafting a policy that matches that.
To me (and this is just my impression, I don't want to speak for anyone
else) the core dispute is about whether a diverging relay policy, even if
just mildly effective in discouraging use cases, is beneficial or harmful
to the network. What you're suggesting is instituting even more policy,
which is an even larger burden to comply with than what exists today, even
if it somehow expands what use cases are permitted. To me, that is worse
than doing nothing, as it'll even more effectively encourage people to
bypass any software implementing such policies, whether that is by the
development of even easier and cheaper ways to submit directly to miners,
or by incentivizing the development or promotion of software that doesn't
have these policies.
Are you suggesting that all relay policy filters be removed? Or that relay
policy be abandoned as a concept entirely? What I suggested, if
implemented, would not place a significant burden on L2 protocols: place
the sha256 of arbitrary data into an OP_RETURN that fits within the
standardness policies of ~99% of the network, then send the arbitrary data
to the nodes that volunteer to relay it. The burden would be the cost of
developing and maintaining this additional relay service, but the burden on
L2 protocol users would not be significantly greater than use of
inscriptions or the like. The policy would be tuned so that arbitrary data
would be cheaper to promulgate via this additional relay service than it
would be to include in inscriptions or raw outputs, so there would be no
incentive to bypass this system -- it is purely added value for L2 protocol
users.
-- Jonathan
--
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/48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8474 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
@ 2025-05-27 16:51 ` Jonathan Voss
2025-05-27 23:10 ` Dave Scotese
0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Voss @ 2025-05-27 16:51 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2669 bytes --]
My understanding is that Citrea is using a ZKP proof to recover from an
invalid protocol state. Whatever data gets into the blockchain, the onus is
on the Citrea-compatible nodes to do the actual validation -- Bitcoin
itself has no part in this other than distributing the data. Adding a new
relay service for promulgating data that is provably committed to in an
OP_RETURN would not be a significant additional burden to the L2 protocol
if this additional relay service is adopted by a sufficient proportion of
nodes, and L2 protocol participants would have an incentive to run this new
relay service for their own benefit, so they would likely already have the
data cached by the time the transaction is confirmed. I don't have any hard
numbers on this, but my conjecture is that L2 protocols would run enough
relays themselves for the system to be viable, and the clear segregation
between arbitrary data ephemerally cached and monetary data permanently
stored will be enough incentive for many node operators to also adopt it.
On Tuesday, May 27, 2025 at 12:05:51 PM UTC-4 Russell O'Connor wrote:
> On Sat, May 24, 2025 at 5:33 PM Jonathan Voss <k98...@gmail•com> wrote:
>
>> However, the recent discussion premised upon Citrea's Clementine Bridge
>> evidences primarily that the relaying capabilities of the Bitcoin network
>> itself are sufficiently useful for L2 designers that there is an incentive
>> to bypass standardness restrictions for the sake of reliably promulgating
>> data -- at least in the case of Citrea, they say they need to quickly and
>> widely disseminate 140+ bytes of arbitrary ZKP data to recover from an
>> invalid protocol state, and the utility of that ZKP data very quickly
>> decreases after it has been confirmed and processed.
>
>
> Does your proposal actually solve this problem? Posting the 140 bytes of
> data to the blockchain works as a public bulletin board because the actual
> data within the block is what is ultimately guaranteed to be disseminated
> to all participants. With your proposal, a transaction with an OP_RETURN
> containing a hash of data could end up being mined without the relevant
> transaction ever even being relayed through the Bitcoin network.
>
>
--
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/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3444 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-27 16:51 ` Jonathan Voss
@ 2025-05-27 23:10 ` Dave Scotese
2025-05-28 13:16 ` Greg Sanders
0 siblings, 1 reply; 7+ messages in thread
From: Dave Scotese @ 2025-05-27 23:10 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5046 bytes --]
As far as I can tell, the resource being wasted is the bandwidth of those
who are (currently kind enough to be) maintaining the network. They are
giving away that bandwidth for free, and I think they ought to be
compensated for it, but until enough of it is "wasted", the demand for such
compensation will remain too low for that problem to be solved. Everyone
who broadcasts a transaction offers the miners the chance to earn a fee,
and those miners seem to me to be the only ones with the right incentive to
solve the problem (because if it gets bad enough, they don't get valuable
bitcoin transactions to mine quickly enough). I believe that in time,
miners will develop a way of privately compensating transaction relayers
for this reason. I would very much enjoy seeing the propagation of data
grow as a market on its own in which nerds like me could participate simply
by leaving their internet-connected machines on all the time and
maintaining the software that runs it.
Protecting Bitcoin from becoming that market and perhaps crowding out its
financial utility might not be such a good idea, but distributing Bitcoin
technology has vastly lowered the cost of financial transactions for
everyone. If we need two networks, one for stuff like what Citrea is doing
and the other for finance with a technological fence around it, I'm all for
it. Has Citrea heard of nostr?
Dave Scotese
On Tue, May 27, 2025 at 10:18 AM Jonathan Voss <k98kurz@gmail•com> wrote:
> My understanding is that Citrea is using a ZKP proof to recover from an
> invalid protocol state. Whatever data gets into the blockchain, the onus is
> on the Citrea-compatible nodes to do the actual validation -- Bitcoin
> itself has no part in this other than distributing the data. Adding a new
> relay service for promulgating data that is provably committed to in an
> OP_RETURN would not be a significant additional burden to the L2 protocol
> if this additional relay service is adopted by a sufficient proportion of
> nodes, and L2 protocol participants would have an incentive to run this new
> relay service for their own benefit, so they would likely already have the
> data cached by the time the transaction is confirmed. I don't have any hard
> numbers on this, but my conjecture is that L2 protocols would run enough
> relays themselves for the system to be viable, and the clear segregation
> between arbitrary data ephemerally cached and monetary data permanently
> stored will be enough incentive for many node operators to also adopt it.
>
> On Tuesday, May 27, 2025 at 12:05:51 PM UTC-4 Russell O'Connor wrote:
>
>> On Sat, May 24, 2025 at 5:33 PM Jonathan Voss <k98...@gmail•com> wrote:
>>
>>> However, the recent discussion premised upon Citrea's Clementine Bridge
>>> evidences primarily that the relaying capabilities of the Bitcoin network
>>> itself are sufficiently useful for L2 designers that there is an incentive
>>> to bypass standardness restrictions for the sake of reliably promulgating
>>> data -- at least in the case of Citrea, they say they need to quickly and
>>> widely disseminate 140+ bytes of arbitrary ZKP data to recover from an
>>> invalid protocol state, and the utility of that ZKP data very quickly
>>> decreases after it has been confirmed and processed.
>>
>>
>> Does your proposal actually solve this problem? Posting the 140 bytes of
>> data to the blockchain works as a public bulletin board because the actual
>> data within the block is what is ultimately guaranteed to be disseminated
>> to all participants. With your proposal, a transaction with an OP_RETURN
>> containing a hash of data could end up being mined without the relevant
>> transaction ever even being relayed through the Bitcoin network.
>>
>> --
> 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/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--
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/CAGLBAhc6QG5H5BXPg%3DNy5dR563YwL%2BiB22%2BP%3Dusam5Ev9F0TDg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6502 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
2025-05-27 23:10 ` Dave Scotese
@ 2025-05-28 13:16 ` Greg Sanders
0 siblings, 0 replies; 7+ messages in thread
From: Greg Sanders @ 2025-05-28 13:16 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5621 bytes --]
> If we need two networks, one for stuff like what Citrea is doing and the
other for finance with a technological fence around it, I'm all for it. Has
Citrea heard of nostr?
Citrea, like Lightning, is relying on Bitcoin's proof of publication to
ultimately move bitcoin. Moving the data elsewhere would change the L2's
security model drastically.
Greg
On Tuesday, May 27, 2025 at 7:15:06 PM UTC-4 Dave Scotese wrote:
> As far as I can tell, the resource being wasted is the bandwidth of those
> who are (currently kind enough to be) maintaining the network. They are
> giving away that bandwidth for free, and I think they ought to be
> compensated for it, but until enough of it is "wasted", the demand for such
> compensation will remain too low for that problem to be solved. Everyone
> who broadcasts a transaction offers the miners the chance to earn a fee,
> and those miners seem to me to be the only ones with the right incentive to
> solve the problem (because if it gets bad enough, they don't get valuable
> bitcoin transactions to mine quickly enough). I believe that in time,
> miners will develop a way of privately compensating transaction relayers
> for this reason. I would very much enjoy seeing the propagation of data
> grow as a market on its own in which nerds like me could participate simply
> by leaving their internet-connected machines on all the time and
> maintaining the software that runs it.
>
> Protecting Bitcoin from becoming that market and perhaps crowding out its
> financial utility might not be such a good idea, but distributing Bitcoin
> technology has vastly lowered the cost of financial transactions for
> everyone. If we need two networks, one for stuff like what Citrea is doing
> and the other for finance with a technological fence around it, I'm all for
> it. Has Citrea heard of nostr?
>
> Dave Scotese
>
> On Tue, May 27, 2025 at 10:18 AM Jonathan Voss <k98...@gmail•com> wrote:
>
>> My understanding is that Citrea is using a ZKP proof to recover from an
>> invalid protocol state. Whatever data gets into the blockchain, the onus is
>> on the Citrea-compatible nodes to do the actual validation -- Bitcoin
>> itself has no part in this other than distributing the data. Adding a new
>> relay service for promulgating data that is provably committed to in an
>> OP_RETURN would not be a significant additional burden to the L2 protocol
>> if this additional relay service is adopted by a sufficient proportion of
>> nodes, and L2 protocol participants would have an incentive to run this new
>> relay service for their own benefit, so they would likely already have the
>> data cached by the time the transaction is confirmed. I don't have any hard
>> numbers on this, but my conjecture is that L2 protocols would run enough
>> relays themselves for the system to be viable, and the clear segregation
>> between arbitrary data ephemerally cached and monetary data permanently
>> stored will be enough incentive for many node operators to also adopt it.
>>
>> On Tuesday, May 27, 2025 at 12:05:51 PM UTC-4 Russell O'Connor wrote:
>>
>>> On Sat, May 24, 2025 at 5:33 PM Jonathan Voss <k98...@gmail•com> wrote:
>>>
>>>> However, the recent discussion premised upon Citrea's Clementine Bridge
>>>> evidences primarily that the relaying capabilities of the Bitcoin network
>>>> itself are sufficiently useful for L2 designers that there is an incentive
>>>> to bypass standardness restrictions for the sake of reliably promulgating
>>>> data -- at least in the case of Citrea, they say they need to quickly and
>>>> widely disseminate 140+ bytes of arbitrary ZKP data to recover from an
>>>> invalid protocol state, and the utility of that ZKP data very quickly
>>>> decreases after it has been confirmed and processed.
>>>
>>>
>>> Does your proposal actually solve this problem? Posting the 140 bytes
>>> of data to the blockchain works as a public bulletin board because the
>>> actual data within the block is what is ultimately guaranteed to be
>>> disseminated to all participants. With your proposal, a transaction with
>>> an OP_RETURN containing a hash of data could end up being mined without the
>>> relevant transaction ever even being relayed through the Bitcoin network.
>>>
>>> --
>> 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+...@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
--
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/2a40a751-d0d1-4dc8-9dd5-67b7652ed8b8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8182 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-05-28 15:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-24 21:07 [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss
2025-05-27 14:16 ` Pieter Wuille
2025-05-27 16:40 ` Jonathan Voss
2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-05-27 16:51 ` Jonathan Voss
2025-05-27 23:10 ` Dave Scotese
2025-05-28 13:16 ` Greg Sanders
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox