Replies (22)
The point wasn't that I like Peter Todd. It was that the action laid bare the inaccuracy that BIP-110 can in any way prevent the hosting of CSAM on chain, making all of the moralistic crusading very clearly a bad faith argument.
I do happen to like what Knots was prior to this whole op_return drama, and would have liked to see it continue growing. Instead, it's been turned into a sideshow. Over the inclusion of a harm reduction measure that costs more to use than more harmful alternatives.
This whole charade has been an own goal of epic proportions, and an immense waste of resources and brainpower. Policy filters may not solve much entirely but with enough of a userbase they'd have made things too unpredictable for what some of the nonsense can tolerate. This forking meanwhile has ensured that this won't be an issue. Rather than fight spam, I expect the outcome of it to actually be more of the fillip garbage and utxo bloat. All while leaving anyone who wants to put abusive images on chain no less impeded than they were.
When Todd puts out his demurrage BIP in a few years these cucks will fully support it.
🎯
It will be another "nothigburger" for them ...
You do get that his comment was about quite a few decades in the future, and was posed as an alternative to leaving the network unsecured by enough hashrate to defend against 51% attacks, right?
Please don't keep making me defend Peter. But that comment of his wasn't the attack some like to make it out as.
Nor would it likely refer to anything in his lifetime, as we have block subsidy until 2140. Ironically perhaps, it WOULDN'T offend '21 million maxis for liferz', only 21 million maxis forevererz.
That said it'd not be something I'd explore lightly. But it would be better than bitcoin ceasing to securely produce new blocks. Personally though I think if we get to 2140 and blockspace isn't alarmingly scarce Bitcoin will have already failed. Even with the L2's, at least bases on what we currently are playing with. Everyone jumping on custodial solutions or things like Liquid would pose problems.
I also think given it'd be a hardfork anyway, I'd just shrink blocksize. If people aren't using 4 MB, may as well go down with it.
Defend Peter Todd harder. Its funny. Both of you can also solve the problem of when the Sun goes out of energy, billions of years from now, what should be done. I am sure you have The solution.
I am curious what is your problem if blocks are not full? Because I think its better to have the capacity for more monetary transaction in the future and there is no need the blocks to be full.
If miners aren't incentivized to mine, they won't spend the energy to mine. If bitcoin still has value but mining doesn't, it becomes more economical to attack Bitcoin than to defend it.
The sanctity of ledger permanence is more important than the sanctity of a hard limit. I pray we never need to make that choice.
Exploring multiple future eventualities and contingencies is how you design sanely for the future so we don't get another repeat of, say, taproot wizardry.
Much like planning for a quantum future that in all likelihood will never arrive.
Knowing this is the trade off will have us perhaps think twice before really exploring L2's (or opcodes to enable said L2's), if they should be theorized, that would somehow permanently break the mining value proposition.
And no, I don't oppose CTV or CSFS, still talking purely hypothetical.
Again. Whats your problem of half full blocks?
We both know most of the incentives for different entities in Bitcoin and it works beautifully. Also spam produces negligible fees. But my questio is about the blocksize.
I do think comparing 2140 to billions of years from now though is pretty telling of a high time preference though. 2140 is grandkids' lifetime right now.
For that are needed smart people like Satoshi.
Not stupid cunts like Peter Todd who can't define what spam is and is the original spam relayer with his librerlay malware.
Satoshi was the first one to "spam" bitcoin judging by what Knotis understand by spam.
Wrong judging. Check OP_RETURN defaults of Bitcoin Knots. 42 Bytes
We align with Satoshi that Bitcoin is Freedom Money.
And still Bitcoin Knots gives you the ability to set it yourself to whatever value you want.
Insufficiently full blocks leave no incentive to pay fees. Which leads to near zero fees. Which knocks hashrate offline. Knock down enough and you can expect reorgs and double spends.
The subsidy protects us from this for the next century and change. After that we have to see where this goes.
Meanwhile, you keep bringing this back to spam, like I run core or something. Pretty clear that I don't. I just reject the idea that BIP-110 is going to solve, or even be a beneficial measure, in addressing it. Filters send a message, and Knots WAS getting more adoption, until the whole camp decided to crash out on this CSAM narrative, and push a chainsplitting fork which doesn't even prevent CSAM.
If filters were to do their job, they'd have needed a supermajority of the network to use them. BIP-110 guaranteed that will not happen in the foreseeable future.
Like I said, huge own-goal.
Maybe this can help you visualize the abuse on Bitcoin from spam.
And don't forget that every Byte in every block is stored on more than 100 000 different computers / nodes.
Thats the COST that is typically not calculated.
BitcoinIsFuture
Lets see how a monetary transaction looks like and how an OP_RETURN spam that takes 100s to 1000s times more space look like.
I am sure you will notice the difference. Spam is disgusting.
1. This is how a Bitcoin monetary transaction looks like
2. This is how OP_RETURN transaction looks like
and the spam waste of space goes on and on like that
Yes, I agree that filters need more than 80% to work properly but they worked like that for 15 years.
Yes they don't prevent miners putting larger OP_RETURNs directly but now BIP110 will that job.
CSAM is valid concern more for some people less for others, it is a concern. Especially now with Epstein revelations we see there is demand for that disgusting stuff.
Core changed totally. Before they repelled Vitalik and he created the mother of all shitcoins - Ethereum. He wanted to build it on Bitcoin and we see what fucking piece of shit Ethereum is. Now Citrea, Peter Thiel, Jameson Slopp, the compromised Core devs, Adam Back and other shitcoiners want to turn Bitcoin into Ethereum 2.0.
That is MADNESS. MADNESS and STUPIDITY.
Miners will be fine if Bitcoin is valuable. Miners won't mine it if Bitcoin becomes a memecoin. The value of Bitcoin is as Freedom Money.
Spam devalues Bitcoin and is one the of the biggest threads and risks.
Small fees make Bitcoin more usable for more people. We compete with banks, with Visa and we are better and cheaper.
Waste of space that costs 4x as much. When a determined spammer (who is being paid by the marks they've conned for whatever token or NFT or whatever else it is they're selling) spams the chain when there isn't op_return, they still use the data space (actually more, due to the fact that it's spread over multiple transactions) AND bloat the UTXO set.
Just because your enemy is wrong doesn't make your solution correct. I agree with you we'd all be better without spammers. Where we disagree is that BIP-110 can solve the problem. I don't say this particularly gleefully; it'd be nice if it were this easy. Though as a separate matter, the rushed roll out of it is what really makes it doomed for failure. But you don't need to take my word for that -- it'll play out quite visibly when it attempts to chainsplit with woefully insufficient hashrate behind it later this year.
Honestly The CAT is more likely to be effective solution. I can't say I'm behind it because of the implications it seems to have regarding property rights (though I have heard the valid comparison to the Satoshi-era inflation bug). But it hits spammers right in the incentives, rather than just playing this whack-a-mole game of telling them to find new and more harmful places to put their arbitrary data.
While all of this is bothersome like mosquitoes the bigger concern would be a determined attacker throwing transactions just over the dust limit by the millions into dummy UTXO's in a concerted effort to destroy Bitcoin, rather than simply attempting to throw the equivalent of graffiti all over it. I'm not entirely sure whether something like The CAT would be the best approach to this, or considering an alternative method of handling UTXO's altogether, such as that used by Libbitcoin, where the set is not maintained as such, but rather the validation is done from the chain at the time of validation. The Core/Knots way of doing things has thus far been the more economical approach, but there is a UTXO set size at which this could conceivably stop being the case based on my understanding.
We have means to fight spammers and we should do it.
Yes The Cat uses the spammers methodology against them so its a clever attack on spammers.
About BIP110 it is very useful too:
BitcoinIsFuture
Running BIP110 on Bitcoin Knots because Bitcoin is Freedom Money 🤙
https://github.com/bitcoin/bips/pull/2017#pullrequestreview-3384767316
"I'm generally supportive of the changes in this BIP. Aside from minor nitpicks in language, the 34 byte scriptPubKey restriction I think will prove to be quite valuable in addressing the larger concern of DoS blocks / poison blocks that impose such high computational costs on nodes that a single block would take 30 minutes to verify on decent hardware instead of taking about a second. This is an even larger threat to Bitcoin than either CSAM or quantum, because I've read that CSAM has already been present on Bitcoin for a very long time, and quantum computers aren't anywhere near good enough to be a threat, and may never be, whereas DoS blocks could be introduced by miners who take direct submissions without sufficient checks at any time.
It's been pointed out that disabling OP_SUCCESS in Tapscript would conflict with adding new signature verification opcodes in future BIPs that might use them to add quantum resistance, but I would point out that the semantics around existing opcodes could simply be altered to preserve compatibility with BIP 110. For example, instead of creating new sets of OP_CHECKSIG opcodes to support new signature schemes, the semantics of existing OP_CHECKSIG opcode could simply be adjusted to accept imperatively inputs of varying lengths, a form of overloading / polymorphism / or duck typing. While it could be argued that a more declarative approach is superior in cryptographic contexts, I don't weight that concern as heavily as the larger concern over DoS blocks, and as such, I'm supportive of this approach.
My only major objection is that this is temporary. I'm not very comfortable with either temporary soft forks or default node expiry because it forces users to act instead of delaying action, which I think delaying action is perfectly fine and reasonable as the protocol matures. It also reminds me too much of the "difficulty bomb" based monetary policy used to coerce Ethereum miners to adopt new code from the Ethereum foundation or else. That said, if BIP 110 were activated as is, I would still be supportive, and I would also support reactivating it in the future as a more permanent feature of Bitcoin.
At a high level, this proposal reminds me in spirit of early versions of my original P2QRH proposal. I just think it could use a little more polish, but I see it as being directionally correct."
