Nostr Web Client

The whole op return thing is all about having one or more transaction relay networks. If you don’t want to relay some transactions but do want to know meta data about them for accurate fee estimation, go ahead and connect to a libre node and drop any tx you don’t want to relay after noting its size and fee rate.

Libre nodes will relay enough shunned transactions to save bitcoin mining centralization from slipstream type OoB payment pressure.

I think I’ll run a libre node on this principle. It shouldn’t take too many to bypass nodes participating in transaction shunning… nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm has a good head about these things.

Reply to this note

Please Login to reply.

Discussion

𝕞𝕪𝕡𝕒𝕥𝕙𝕥𝕠𝕗𝕚𝕣𝕖 3mo ago

Why dont you just use solana. Its better for other transaction types?

Dr. Bitcoin, MD 3mo ago

I don’t understand your question. This is about protecting bitcoin from unwise transaction shunning…

The balance of incentives for bitcoin participants is a complex one. Miners know we don’t like it when bitcoin centralizes…remember when a mining pool disbanded when they controlled ½ the network? Such altruism may not hold in the corporate mining environment.

Karadenizli 3mo ago

There's no problem with there being multiple decentralized mempools. If every user is filtering to their own standards, it's perfectly fine for transactions to drop if almost no nodes want to relay it. And I would make this argument for any filter. Even those I disagree with. If every participant chose their own filters and literally no one wants to relay a terrorist TX, this isn't a failure of bitcoin. Bitcoin allows very small minorities to bypass both mempool and mining censorship. 3% of relays can propagate a block that the rest censor. If not even 3% of the network wants anything to do with you, you might be the problem.

Dr. Bitcoin, MD 3mo ago

Agreed.

The main issue to how to couple transaction shunning with something effective to stop profits for miners through out of band payments. This is a both or none type scenario.

Karadenizli 3mo ago

I don't think you need to go out of your way to prop up a libre relay network. If you run knots, there's no difference to you whether a spammer uses core or Mara pool. Its gonna be negligible on fee rates (and thus miner centralization) unless theres more spam as a percentage of transactions, than miners willing to mine them as a percentage of global hashpower.

Mara, in running a private mempool, is gonna have to take personal responsibility for what they mine, and their gains from mining spam will probably be outweighed by losses from filtering out non OFAC compliant TXs.

Dr. Bitcoin, MD 3mo ago

Making unusually profitable transactions available to all miners in the goal.

Karadenizli 3mo ago

If the current fee rate is 10 s/b, a spammer isn't gonna pay 30 s/b to mara. They will just pay 11 and broadcast to the libre relays. The more of a gap there is, the more incentives for miners to defect and mine these span TXs. It's market incentives all the way down.

Dr. Bitcoin, MD 3mo ago

Which is why relaying spam makes sense

Karadenizli 3mo ago

What I'm saying is, let the market handle it and cast your vote based on what you wish to see on the chain. Don't make up complicated hypotheticals to explicitly do something against your values for the greater good.

Dr. Bitcoin, MD 3mo ago

And what I’m saying is that doing so causes the problem that nobody wants.

Peter Todd 3mo ago

Thanks!

Although I do have to point out that Libre Relau is actually almost identical to Core, because Core has removed pretty much every non-technical restriction on transactions. So in practice just running Core is almost the same. At the moment the only difference compared to the upcoming v30 release is relaying transactions using the Taproot annex, and replace-by-fee-rate; I do need to get around to removing the dust limit. But that breaks a lot of tests and there isn't a lot of demand for doing that.

Libre Relay is in a way more of a piece of performance art, proving that censorship/filtering is a bad path to go down. It shows what's possible, even if in practice it's very close to Core.

But yes, people running this piece of performance art is a useful statement in of itself! So thank you!

7fc62867... 3mo ago

Run the node that aligns best with your personal values, and be fully aware of what you are choosing.

TLDR; the core issue behind the Knots vs. Core v30 debate, excluding the personal attacks, can be summarized as Knots = “Bitcoin is only money” whereas Core v30 = “The Bitcoin blockchain is free data storage, and Bitcoin is also money”.

The main consideration is whether you want your node to relay only financial transactions or also arbitrary data that will be recorded on the blockchain. Knots focuses on relaying financial transactions, filtering out as much spam as reasonably possible - but it cannot block all spam. In contrast, the new Core v30 will relay the existing spam currently encountered by the network (like older Core versions already relay) and introduces a new way for spammers - such as VC-funded startups - to exploit nodes for free data storage without paying additional miner fees to bypass node filters.

Relaying and storing arbitrary data also increases legal risks for node operators compared to channeling that data through the large miners’ choke-points (e.g. via slipstream). Those large mining companies can be held accountable for the arbitrary data they choose to include in the blockchain that nodes refused to relay, creating an incentive for them to avoid mining the most awful content.

OneNostrich 3mo ago

Core team introduced Inscriptions bug being exploited by spammers, refused to fix it, and then use the resulting UXTO bloat as leverage to argue for a very spam friendly "fix" (100k payload plus subsat fees).

Dr. Bitcoin, MD 3mo ago

I hear people saying that as if it were true and meaningful. I don’t deny there is a new place to stuff data and it’s easier from a mental perspective, but it’s not like there weren’t other places to stuff data before en masse.

Thinking about ways to discourage OoB payments to preserve the utility of transaction shunning…reputational damage might be the only way.

Something like “miner xyz just included a nonstandard transaction paid for out of band and shame on them…”

We need something to make slipstream unprofitable, otherwise shunning based on standardness criteria is doomed to fail.