Nostr Web Client

I don't get it entirely... They also have to censor if the data is in a bogus output of a multisig tx, in that case its even worse since it becomes part of the utxo set. Right? Or am I missing something?

nomadshiba⚡ 4mo ago

i don't get what you are talking about. both are being kept on the blockchain. and he is talking about storage.

knots have patches for filtering all kinds of storage exploits.

not to mention, pruned nodes are just relays, not really useful most of the time. utxo is just a pointer to an output. based on how you implement your node, they are not a big issue.

issue is the blockchain abuse, and size.

its the lack of new patches against taproot exploits in core. and then now the malicious updates coming to core.

Reply to this note

Please Login to reply.

Discussion

krisl 4mo ago

I am slowly starting to understand this a bit more, so there are two main ways to store data in the bitcoin blockchain (right?).

1. OP_RETURN - provably unspendable, the data is not part of the utxo set and can be pruned (even if you have a full node you could prune this in theory, since it doesn't affect consensus).

2. Encoding it in outputs - creating outputs with scriptPubKey that look spendable syntactically but are actually unspendable in practice. From Bitcoin’s point of view, these outputs look like valid spendable coins, so they get added to the UTXO set. But since the “keys” to spend them don't exist, they are forever unspendable. That means they sit in the UTXO database forever, wasting space and resources for every full node.

So lets say some illegal data enters the chain and the police visits you because you run a full node, or you are a miner...etc. In case of OP_RETURN you can dump that data since it doesn't affect consensus. In case the data is in the outputs you can't just dump it, because it affects consensus.

So to my understanding, lets assume there will always be people that want to spam the chain and they will find a way to do so and spamming in the outputs can't be prevented anyway. It seems wiser to let them use OP_RETURN (doesn't hurt as much) instead of spamming the utxo set (it hurts).

Am I missing something?

Btw are these patches enabled in knots by default or do you need to set it in the config?

nomadshiba⚡ 4mo ago

OP_RETURN goes to scriptPubKey. instead of sending it to an spendable script or address type like OP_1, OP_2 etc.

everywhere you can put data can be a data storage. for example i can store data in my browser history just by using page titles. does it make sense? no. but i can do it. best way to block data storage is wait for it. wait for a method to show up. then bam patch it. don't let it get big, or mainstream. kill it on the spot. this is what bitcoin core has been doing until 2 years ago. after taproot nothing got patched. and now they are removing older patches.

as i said input spending an output, just gives a pointer to it. and if that output not spent yet, you can spend it. based on implementation, it can also just be a boolean on the output.

if you are a miner and you wanna prune older blocks and just keep a list of UTXOs, you can also prune spendable outputs. like OP_FALSE OP_IF that stores data. because you know it can't be spent, so no point to store it. BUT somebody has to store it.

the whole point of a blockchain is proving something happened globally, with timestamp and order. its not designed to store blob data, and its not best at storing blob data. normally you would store the blob data somewhere else, like blossom, then take the hash and put it on the blockchain. and now you can verify it. you timestamped it.

you wouldn't use blockchain itself as blob storage in any other context. because it doesn't make sense. you would store it on a. blob storage, and put the hash on the blockchain to prove it, log it.

but now since THEY CAN store it on the blockchain, and forget about it, they are just doing that.

if a data is lost you can't rebuild the blockchain. block hash changes. somebody has to store the full blockchain.

whole point of bitcoin is decentralization, and if you make running a node harder, then you make the network less decentralized.

that's what makes bitcoin special, its the biggest, yet i can run it on my laptop.

in an ideal world most of the people would run their own node.

but nobody works to make running a node easier for normal people. im talking in terms of software, and the way blockchain stored. nobody trying to think "how can we make this consume less storage so more people can run it".

instead they keep adding more stuff to it. make it little by little harder to run. if you ran a node recently, you might have noticed it takes longer to sync blocks from the last two years. its nuts.

---

i kinda vent here but you can also watch mechanics videos on youtube, instead of listening random people like me. before asking questions to random people who might not be well informed, i suggest you watch mechanic first.

https://youtube.com/@bitcoinmechanic/videos

krisl 4mo ago

Thanks for the explanation, no problem for venting :)

I am curious if its even possible to prevent this, since the data is being hiding with creative methods. Lets say you make a filter to prevent jpegs in the taprot witness data, but then the spamers just change it to png, or just invent some new encoding that is always dodging the filter.

What do you think?

nomadshiba⚡ 4mo ago

its more about blob data than image formats. and they build an ecosystem.

the same way they decode the data. you can also detect them. if your ecosystem is unreliable and constantly being patched against, it will not grow. i think there is also a discussion on knots about using plugins for filters. so people can write scripts to filter stuff and dont have to know C to filter things.

i also work on making my own node/client implementation, trying to solve things i mentioned above. but that's outside of this topic. and its too early to talk about it.

krisl 4mo ago

Thats cool, will be happy to test it out when it matures. Thanks for your views, I appreciate your answers, you made me understand a bit more about this.