public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dave Scotese <dscotese@litmocracy.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
Date: Tue, 27 May 2025 16:10:07 -0700	[thread overview]
Message-ID: <CAGLBAhc6QG5H5BXPg=Ny5dR563YwL+iB22+P=usam5Ev9F0TDg@mail.gmail.com> (raw)
In-Reply-To: <a484ae6a-33d6-4704-8356-c0ed1e5ae376n@googlegroups.com>

[-- 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 --]

  reply	other threads:[~2025-05-27 23:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2025-05-28 13:16       ` Greg Sanders

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='CAGLBAhc6QG5H5BXPg=Ny5dR563YwL+iB22+P=usam5Ev9F0TDg@mail.gmail.com' \
    --to=dscotese@litmocracy.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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