Nostr Web Client

1.) It is always possible to store non financial data in Bitcoin. Pubkeys have to be stored and pubkeys can be jpegs. And there is no way to tell if they are jpegs.

2.) storing jpegs in pubkeys is expensive for anyone running a node. Since there is no way to tell it's a jpeg and since it can be possibly spent later, nodes have to store the outputs in a data structure called utxo set forever

3.) if there is a way to store the jpegs in a way that tells node runners "you don't need to keep this shit, it cannot be spent" and the sender pays the miners for it anyway, it's better to provide this options

4.) filters don't remove jpegs, they move jpegs to option 1 which is worse for everyone

5.) because of 1, there will always be jpegs in Bitcoin.

6.) because of consensus rules allowing mining of longer jpeg outputs, the filters won't do chicken shit. If someone wants to store a jpeg, they find the cheapest way to do it. Normally people put the tx to a shared mempool and miners mine whatever is most profitable from the mempool. But if nodes are stubborn and don't relay, and miners want to make money, they will make it possible for another way to submit a tx that will make their operation more profitable.

As a result of these, you should be running Core v30 and block filteroors on social media to keep your sanity.

Reply to this note

Please Login to reply.

Discussion

63f1576a... 2mo ago

Honest question:

Why do we need to remove the limit on the size of OP_RETURN? (sorry if I'm not using the correct verbiage, hope you catch my drift?)

The Daniel 🖖 2mo ago

See point 4.

vinney...axkl 2mo ago

point 4 is "they're gonna be there anyway, accept it and accomodate them in the way that's least bad for everyone", more or less, right?

i can understand that thinking, but it doesn't explain increasing the size vs simply doing nothing

The increased size is the same as what consensus enforces.

If you block it on relay level in P2P but allow in consensus, you make an incentive to submit txs outside of mempool. That breaks a few things such as fee estimation - you base the fees required based on what transactions are pending to be mined. If you can't see them, your fee estimation is wrong.

Relay policy and consensus policy should be the same, that works best for everyone and does not incentivize backroom deals with miners.

vinney...axkl 2mo ago

how would you escape homogeneity in that setup?

63f1576a... 2mo ago

hmm, while (I think) I understand that logic, I don't understand why this supposed need of homogeneity overrides the need to have a blockchain as free of non-monetary data as possible (if that makes sense).

Shouldn't we have tried to limit the amount of data before letting it come to this point?

Again, honest question.

If you free it from non monetary data stored in one way, you don't go into a reality where there will be less non monetary data. You go into reality where it's stored in the worse way.

If people want to store data, they will (and they will pay for it). And they will probably use the cheapest way. So it's quite good, if the cheapest way was not bloating the chain state.

There is no reality without spam.

vinney...axkl 2mo ago

could you use the same rationale in an analogy to email spam from the perspective of someone hosting their own email account? This isn't some kind of trap; I'm curious how you would frame the analogy (with regards to spam filters, expected amount of spam emails and storing them, etc.)

I don't think it works for email. It would work if the sender paid fees to the receiver.

👏👏👏

leadbyexample 2mo ago

this is the argument that goes "hey a thief could just come with a bulldozer to crash your bullet proof windows and tear down the safe from your walls, you are a big idiot if you don't leave the windows open and your credit card+pin on the table"

Nope.

Probably logical dynamic thinking is too troublesome. Try with a bit more brainpower investment.

leadbyexample 2mo ago

see, if you are debating something, and you do not agree with the other person, saying "I am smarter than you so your argument is invalid" is not a valid argument, it's just rude.

You did not make an argument, you said a random unrelated metaphor.

Akashi Hyogo 2mo ago

Let me challenge you a bit :D.

It is not the storing part that is most concerning to knotzis. It is the "distribution" part.

For scheme to become distribution scheme the decoding (data blob -> jpeg) part has to be published/known.

If it is published/known it can be blocked on policy level (if most miners agree to adopt filters for whatever reason)

If you look at this situation this way, it is always possible to at least fight this problem.

Would we prevent all spam? Definitely not.

But we would prevent any VC backed jpeg scheme and most of popular organic schemes (ordinals inscriptions)

If we achieved that knotzis would be definitely satisfied.

All they need to do is persuade big majority of hashrate.

My claim is that:

- the easines and clarity of your argument here is mostly straw man.

- there are no solutions only trade-offs (including your position)

It's not possible. That's an information theory thing, not an opinion.

You can store it encrypted and later reveal the key. Breaking any filter.

If this is the only way, in a dynamic world (which we live in), this will be the way that will be done.

Ok, now I understand at least one issue with filteroors. They don't understand that this problem is dynamic.

They think like statists do. I don't want X, so I ban X.

That's not how the world works. You have to ask a different questions - I don't want X, if I ban X, what would people that were doing X do next? And if it is worse than X, the rational thing is - don't ban X, I don't want them to do the worse thing!

I don't want spam, but since it is in principle not possible to ban it in a permissionless financial network, since spam can always be embedded in the transactions, we want the spam in the least disturbing way. I.e. op_return.

Not understanding this is low IQ thinking.

Wonteet Zebugs 2mo ago

What the low IQ crowd like you fails to understand is that you are not an island. There's a society around you, whether you like it or not.

There's a legal and moral difference between bad content being put on chain in weird and clever ways versus bad content being officially allowed and relayed.

You may not see the difference but the rest of society will. And that will be bad for bitcoiners.

Core is the one that radically changed bitcoin with v30. There was no necessity and no emergency to change bitcoin radically. It was working fine.

Still working fine. All this shit is made up

NokSuKao 2mo ago

This is what I have learned:

1)Using pubkeys for this reason is inefficient and expensive, which is good. Don’t make it easy to put spam into the blockchain.

2) It’s not a burden if the amount of this transactions is very low. Which from my understanding is the case.

3) Keep it inefficient to put spam into the blockchain

(see 1)

4) Filters are necessary. Not only is it more difficult/inefficient to put spam into the blockchain (as you mentioned) the other thing is that the community gives a signal to all participants that spam isn’t a use case of Bitcoin. Acting against may result in loss of reputation (social costs). Spammers should have to use inefficient loopholes to put spam into the blockchain Its only a burden if people are using the pubkey method considerably.

6) Make mining decentralized and this won’t be the case I guess. Also the profits of Mara with its slipstream service is low from what I have heard(not sure). So will there be an incentive in the long run? And you have to consider the loss of reputation a miner will suffer from doing things that Bitcoin is not designed for. Will they really do everything just for short term profits?

Don’t update, make a statement to the core team not to force controversial changes into Bitcoin. If in the future the Blockchain is flooded with fake pubkeys lets reassess.

Akashi Hyogo 2mo ago

The problem with point 1) is, that it is much more taxing on nodes then on spammers.

If you want to sync the chain in any reasonable time all the unspent utxo set has to be loaded in RAM.

It is already a few GB which has basically killed most of Rpi nodes.

Exactly.

That's why it's better to provide a way to store that is other than this. Because if there is no other way, it will be done this way

NokSuKao 2mo ago

I‘m running a raspberry pi with 8GB ram. Took me about 2.5 days to synchronize. What is acceptable I think.

NokSuKao 2mo ago

And if I correctly understand, Bitcoin core only uses 512MB ram for the UTXO set the rest is stored on the ssd and fetched if needed. I do not see a problem with ram or disk space unless the number of those transactions will rise considerably.

With op_return, the utxo set does not grow at all. With pubkey data, it will grow forever.

NokSuKao 2mo ago

Yes if there will be a significant amount of those transactions which is doubtable as there are cheaper ways (exploiting SegWit).

1) It is inefficient, but it should be. And that's the point of this point. There should be better options. This point is about anchoring the fact that in no way it is possible to block spam, this option is always here and unstoppable.

2.) no, the value does not matter. Utxo has to be saved in utxo set if it is spendable. It can be an anchor output, so you can't prune it, that would break lightning for example.

3.) yes, keep it inefficient, but more efficient than the option that bloats the utxo set. Prunable outputs are better than bloating utxo set.

4.) spammers don't give a shit about their reputation, they wear it proudly. This doesn't work. They just have a different mindset and they don't care about being excluded from the true bitcoiner tribe.

6.) miners should not care about reputation, the point of pow is removing the need for reputation and replacing it with profit incentive. Also, the miners choose to reveal their identity, but they can choose to mine completely anonymously, removing any reputation costs.

For shareholder, the main reputation is if the operation is profitable. And that's a good thing.

Luke de Wolf 2mo ago

I'd like to engage with you in good faith here. I hope you don't block me as a filteroor.

If the majority of the non-financial data (I like that terminology, by the way) is using some kind of exploit (OP_FALSE OP_IF or baremultisig, for example) then why is it bad to simply fix the exploit? These were not intended features, and in some cases the potential for abuse was raised ages ago.

I really don't see what the problem is with making arbitrary data as expensive as possible. Encode what you want in pubkeys, I guess. Pay full price for it. No discount. No multisig optimization.

I just don't buy that we have to stick to the existing consensus rules just because they are the existing consensus rules. If something is being abused, why can't we change it?

Again, I hope you take this reply in good faith.

Because spam in pubkeys make nodes expensive to run. Unspent transaction outputs basically need to fit into ram. I'd rather store the monkey jpeg on 4tb hard drive or delete it if I'm running a pruned node than to buy more RAM to run a node.

For this to be the case, this way of storing monkey jpegs (in pubkeys) has to be more expensive than other options.

So that means there has to be a cheaper way that works.

Luke de Wolf 2mo ago

So what is wrong with closing off the currently abused exploits and leaving OP_RETURN only?

Regardless, wanting less UTXO bloat is the best argument for this that I've heard. It would be nice if Core focused on that as the messaging.

leadbyexample 2mo ago

UTXO set doesn't need to be stored in RAM.

RAM is used to cache UTXOs that are actually used, so they must be actually spendable (hence no fake pubkeys) and then get spent at some point in time, because a UTXO that is not moved, will after a while be removed from the RAM cache and relegated to disk storage forever, never needing to be fetched again.

Still can't be pruned. Still has to be in a data structure that you need to be eventually able to search. There's no way to tell if pubkey will be spent on the future.

leadbyexample 2mo ago

I can produce another analogy 😊

Just kidding.

I played with AI to make some simulations.

So let's assume one could either store garbage at 1sat/vB, or at 10sat/vB (let's say it will be uneconomical to go beyond10 for sick shitcoinining spammers).

Let's also consider that while OP_RETURN has basically just its storage costs, using fake pubkeys carries larger overhead per unit of shitcoinery size, plus each fake pubkey output requires its dust limit 546sats to be locked forever, same thing as paying a fee.

Long story short, no matter the total garbage size (I queried for 1kb, 20kb and 100kb) at 10sat/vB, using fake pubkeys instead of OP_RETURN means spending about 3x the cost per shitcoin size unit, but other than that you're also paying 10sat/vB which is not cheap.

At 1sat/vB (more realistic at current feerates), using fake pubkeys costs a whopping 18x OP_RETURN.

I understand shitcoiners do not care about messing with the UTXO set, but they do care about spending as little as possible.

Are we sure it's a good idea to give them a cheaper, better alternative to do that, which was not available before?

Do you know what the cobra effect was?

Yes, I know the cobra effect.

Please remember the shitcoiners were happily paying a lot:

During the peak of Bitcoin ordinals and inscriptions activity in early May 2023 (particularly around May 7-9), the fee rates paid for transactions, including those for inscriptions and ordinals, typically ranged from approximately 100 to 700 sats per vByte.

While it's a good idea to increase the price to be just a bit cheaper than the worst option, the filters don't do that.

The criminal liability is mostly FUD. Node runners are not even held criminally liable for accepting sanctioned transactions as valid. And the 'it's continuous' is mostly bullshit. Also, it's not a real problem, no one really wants to store cp in Bitcoin. Why spreading the fud now? If it happens, you just prune it from your node or don't answer the request for that particular tx in p2p if it comes to that. It won't.

I don't think there is a way to prune just OP_RETURN, i need a Full Node with TXINDEX enabled so a can't delete JPEGS.

With spam filters i can try to block JPEGS and i think on long term Miners who accept SPAM directly will loose hashrate in the future.

Just a little part of UTXO set is in RAM, most of it is on storage.

The idea of wrong estimator fee because i don't see the transaction, it' a fake problem.

This is my opinion

If you need non pruned node, you will store spam regardless of how it's encoded. Your node would be slower though, using a larger data structure is more computationally complex.

Many people can run a pruned node.

Op_return spam vs utxo set spam - clear winner for op_return in both cases.

Mining pools that get more btc from fees will gain hashrate, not lose it. From the off band tx they will include only those that pay more than those in the mempool. And since you can mine each block anonymously, it doesn't matter for them.. If I have a miner, I want most sats per hashrate.

0.01% of revenue now is by fees, miner wants just the coinbase.

All bitcoiners who have a powerful ASIC choose non spam mining pool.

Everyone else miners thinks More spam=more blockchain problems=less btc value.

No one wants spam neither miners....I hope

Nope, spam censoring pools are in a minority. Fee revenue is low now because the blocks are empty, but it can be significant source of revenue for the miners, check may 2023 at the peak of spam activity.

Some blocks had more in fees than coin subsidy and miners happily mined spam to collect the fees. It would be irresponsible for revenue not to.

In a way, spam solves the security budget problem :)

Today offchain transactions are the majority, lightning, custodial services, ecash, fedimint.

I hope layer 1 will never reach that kind of fees.

Miners will be on the right side...I hope 😁

The idea of wrong estimator fee because i don't see the transaction, it' a fake problem.

- why? How do you think the fee estimation works?

The percentage of spam transactions is less than 5% each block now, and spam transactions use 0.X fees, so they have low priorities

j bbc xkb 2mo ago

1.) That is the basis of the argument regarding attack surface increase - you cant be liable, if you can‘t tell what a random set of pubkeys stringed together might make - very different from a continouus100kb file.

2.) True, but strawman to the discussion at hand. Same is true after coreV30.

3.) True for Spam - though it has to be saved to drive for non-pruned nodes; wrong for attack surface angle, because miners have policies for turning illicit content down (due to obvious risks).

4.) True but strawman. It isn‘t about the JPEG, it is about the centralization risk inherent due to the noderunners opting out to be file storage providers for the legal risk of the files they store.

5.) True.

6.) Wrong, due to orphanage risk in slower block propagation for blocks including txs from private mempools not relayed by the p2p network.

run corev30 - for me inconclusive at best

I wouldn’t block or unfollow them, unless if all they post about is this shit. I really liked Luke and Matthew Kratter, but now that all they say is filter, I am not following them anymore.

Honestly, I never liked Luke, even before it was cool to not like Luke. I think he was always insane. Not my cup of tea.

I don't know who Matthew Kratter is.

Matthew runs the Bitcoin University.

Luke was eccentric, so much so that his quirks became the subject of friendly jokes among friends. I saw them as the kind of eccentricities typical of genius. But he’s become too consumed by ego in this controversy, one that they themselves turned into a controversy.