It's pretty obvious what they're doing: pressuring the credit card companies to lower interchange fees. Or at the very least, not raise them further.

Completion is good.

Elections matter.

Like Phoenix, being willing to come back is likely due to the new administration (though new tech would help too).

I had the same experience myself. Except it was in Italy, 10 years ago, and playing football... 70 year old Italian men were better than me...

Actually, maybe the problem wasn't me getting old...

The same people also want a cashless society.

Psychopaths.

Probably something like half of the military units and other charities accepting donations accept Bitcoin – there's been a lot of problems with companies like PayPal freezing accounts. Also you can buy and sell BTC (and other currencies) AML/KYC free in Ukraine. It's pretty common for things like computer stores to accept stablecoins as payment too.

Note that technically P2Pool is already live: people are still running the first version of P2Pool, and very occasionally it finds blocks. This works because the Bitcoin protocol is backwards compatible: a soft fork doesn't prevent old miners from continuing to mine.

What you're talking about is the new version.

Don't be so confident that renewables are going to fail due to this issue. Grid inertia is a real problem. But spinning generators aren't the only way to get it. With better designs, solar inverters, wind, and batter backup can all provide inertia too. And of course, in some places they're just installing motor-generator flywheels to provide inertia too.

Limiting OP_Return outputs would be a soft fork. Also, an utterly pointless soft fork: you can easily bypass any consensus limit we could reasonably come up with, e.g. with unspendable outputs.

The whole point of OP_Return was to encourage people to use a less harmful, prunable, output format rather that growing the UTXO set.

Note that prostitution is legal in Australia.

You learned that today? Sheesh.

My first full-rbf fork of Bitcoin Core with preferential peering was released in 2014.

In this particular case, definitely not. Even with the "prove your bytes aren't arbitrary data" soft fork proposal they're doing something valuable enough to make grinding bytes feasible.

Because this type of Citrea transaction is time sensitive. Only two major mining pools mine oversized OP_Returns right now. That means there's a decent chance this type of Citrea transaction – a tx that responds to fraud – would fail to be mined.

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

Censorship, stifling information, is always more difficult than spreading it.

tl;dr: you could make data publication much more expensive by requiring transactions to prove that data in them isn't arbitrary. But even that will not totally stop data publication. Also, not all “spam” requires data to be published.

Also important to mention: Libre Relay automatically peers with other Libre Relay nodes. So even with only a small minority of Libre Relay nodes, transactions still propagate reliably.

You do not understand what Citrea is doing.

They're not storing data or committing data. They're provably publishing data. They need to do this because their protocol needs to ensure that other actors in the protocol get that data in the non-cooperative case.

Lightning does the same thing: if an HTLC transaction goes on chain, collecting the HTLC forces you to publish the pre-image on the chain, ensuring he next person in the path can find the pre-image and use it themselves to collect their HTLC.

OpenTimestamps is not a solution for the problem Citrea is facing. They need a proof-of-publication: proof that data was widely published.

OpenTimestamps just doesn't solve that problem, and fundamentally can't.

Lightning uses this concept too: HTLCs are a proof of publication mechanism too. If they go on chain, the transaction ensures that the pre-image is made publicly available, ensuring the next entity learns the pre-image that they need to collect their funds.

Dumb comment.

Citrea is using perfectly standard transactions right now; we can't stop them.

In the process, Citrea occasionally creates unprunable outputs that bloat the UTXO set. We would prefer that they use OP_Return instead. They can't at the moment, as they need more than 80 bytes of data.

You can't. The UTXO set itself, what your node stores, doesn't tell you anything useful about why a transaction was created.

You have to think about this for yourself, e.g. by looking at projects using Bitcoin and understanding what they're doing and why.

That's called a commitment. Commitments alone are insufficient for all use cases. Sometimes you need to provably publish data.

Lightning, for example, needs to provably publish digest pre-images to work.