Nostr Web Client

Nobody is going to force anyone to bridge their sats to Citrea though. Why shouldn't they try building it? Alpen Labs is doing something very similar, without even requiring more than 89 bytes OP_RETURN

BitcoinIsFuture 3mo ago

When Bitcoin Node runners take their decision which nodes to run, they need the truth.

I am showing the disgusting intentions that Citrea has and major Cardano shitcoiner saying he is after Bitcoin's liquidity and excited about Citrea work.

Other than that, every shitcoiner is allowed to attack Bitcoin. Like Jameson Lopp is doing it or as we see Peter Todd and his Core friends are doing it.

Also, no one protested OP_RETURN of 42 or 83 Bytes for legitimate uses - hashes etc. 100 000 Bytes is ABUSE and ATTACK on Bitcoin.

But we know the milicious actions started in 2024 so it clear Core is compromised.

nostr:nevent1qqsdjrc25c869xh06pu8ke70m8lyzyfe6zmegef4u57huvar34wrrmqppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qg4waehxw309aex2mrp0yhx27rfwsh8qatz9uqjq7uu

nostr:nevent1qqspkj82ulzayrvp3cpsxurmm7yvmkak99jgyjetay6qc439m52d4lcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qgcwaehxw309aex2mrp0yhxvmm4de6xz6tw9enx6tcxfglvj

Reply to this note

Please Login to reply.

Discussion

epsql 3mo ago

Yeah I unfortunately agree that 100kb OP_RETURN was not needed at all, I think everyone was going to be comfortable with limits up even maybe 250 bytes, enough to use Bitcoin as a data availability layer for rollups.

For my part I'm not updating past Core 29.0, Knots is great to have as it shows that the community is all but complacent

BitcoinIsFuture 3mo ago

Why do you think its "unfortunate" to disagree with Core?

We verity, we don't trust.

The unfortunate thing is that you are trying to excuse what Citrea is doing. (Also Citrea needed 160 Bytes but that is irrelevant now, they are malicius compnay trying to turn Bitcoin into Ethereum like shitcoin - their intentions shown in the article and verified by Cardano's Hoskinson)

As you say there are companies that respect the Bitcoin ethos and design their technology to use lets say less than 83 Bytes in OP_RETURN.

Thank you for not running the malicious Core V30.

This is what Bitcoin is and its values are. And not because I have posted it but because majority of Bitcoiners are saying it. Those values have been ATTACKED by Core devs. Core devs CENSORED Bitcoin contributes on Github for mentioning Citrea. Core devs ATTACK Bitcoin Knots node runners. And their lies, their lies about filters ....

nostr:nevent1qqs2ljyfhp7jms0vahrgunwuqcgxn6m4hyesx4ykxvq03ncp5xnuq7qppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qgcwaehxw309aex2mrp0yhxvmm4de6xz6tw9enx6tcr7udtg

epsql 3mo ago

I think it's great to disagree with Core. It's unfortunate that they chose to pursue this change because it doesn't seem to be necessary at all and it has caused a lot of chaos within the community, which was frankly the last thing we needed. Nevertheless, Bitcoin is made to survive adversity and it's up to node runners to guarantee its success in the long term.

As for Citrea, I'm not excusing them or anything. I think development on Bitcoin should be permissionless, so let them try build new stuff. They can turn Bitcoin into Ethereum only if the vast majority of users actually think that's valuable and start bridging their sats to their L2. I have no reason to believe this is going to happen.

The other unfortunate thing is that Citrea has developed its protocol in such a way as to require more than 80 bytes of arbitrary data, meaning they are going to publish it on the witness instead of as an OP_RETURN output. Had they been less careless with their technical choices, we would probably not be here. Hence my use of the term "unfortunate".

BitcoinIsFuture 3mo ago

And here is the key.

Core ALLOWED the spam that currently abuses Bitcoin by not fixing it with Luke's PR. So Citrea abusing Bitcoin is direct effect of malicious Core devs actions.

"The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining. Since the end of 2022, however, attackers have found a way to bypass this limit by obfuscating their spam inside OP_FALSE OP_IF patterns instead of using the standardized OP_RETURN. This remains under active exploitation to a degree very harmful to Bitcoin even today.

A straightforward way to address this is to simply fix the bug (#28408), but that was (inappropriately) closed due to social attacks."

https://github.com/bitcoin/bitcoin/pull/28408

https://github.com/bitcoin/bitcoin/issues/29187

nostr:nevent1qqsdk7fgvx6jdt5ss2sqa0wqxdu3v925m9ge5kwhxmca3nw4gtr3eqcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj77uzl0g

epsql 3mo ago

I'm familiar with these points. I am not sure that fixing the current instantiation of inscriptions via OP_FALSE OP_IF checks would be enough though. There are ways ways to embed arbitrary data and it seems to be the only option to remove the possibility entirely is to only allow a set of well known transaction types, much more restrictive than what Core currently categorizes as "standard".

BitcoinIsFuture 3mo ago

They are already fixed in Bitcoin Knots. And Knots is working fine.

All legitimate transactions and use cases can be tested but as for monetary transactions that transfer value, its all fine.

Restrictions is when someone takes away your options - deprecations first, removal second.

One thing to notice is that Bitcoin Knots gives you the FREEDOM to put whatever value in OP_RETURN you like. Think about that too.