pull down to refresh
0 sats \ 8 replies \ @standardcrypto 23h \ parent \ on: Gmax's theocratic populist sex prohibition analogy for filters bitcoin
IIUC, the argument is that the end effect of something like knots being popular is mining centralization. The mechanism of it is a bit subtle; I think pieter wiulle goes into it in his big post about why core lifted the op return restriction. (And it's repeated in many other places)
Let's see if I can recapitulate. If nodes can't predict blocks (same as predicting fees) then neither can small miners. So big miners have an advantage, because everybody is sending their "non monetary / spam" transactions to them. So eventually you wind up with a few big pools instead of pool diversity, and then it's easier for the state to impose its will on the big pools. Yeah I think that was the argument and it's convincing to me.
You might not like Greg's tone, he's definitely pissed, but that doesn't make him wrong.
You need nodes to be able to predict blocks / fees, and knots gets in the way of it. That's it.
Also lukejr is an authoritarian tool, but even if he wasn't you still need to predict blocks and fees. hashtag: Knots is the spam.
The problem with this argument is that it reeks of a lab experiment, like these complex dynamics exist in a vacuum and will play out entirely as predicted, and that there are no possible countermeasures that could be deployed that would satisfy node runners who don't want to relay non-monetary transactions and who want to influence the quantity of spam that gets validated.
Greg is the authoritarian tool. Always has been, since I was arguing with him on Reddit in 2015.
Its time for knots and other implementations to get in the way.
reply
I think it's good to have more than one client, and am fine with people running knots.
With the current fee landscape, nobody will have trouble getting their transactions in a block, whichever client they use. As fees (hopefully rise), using knots will be seen by its own users as more and more of a hassle and a hair shirt, and they will gradually migrate to other clients that have a sane mempool policy.
Luke is a nuisance. Gmaxwell has his rough edges, but he doesn't have his minions spamming the knots git repo with pull requests and argumentation.
I guess everyone use the client they like and we just see what happens.
reply
It is not good to have multiple clients.
"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." --SN, 2010
Bitcoin Core, the satoshi client, is fine.
reply
man satoshi said that but is it really true?
what terrible thing happens if nosea aren't in lockstep? the only thing I can think of is stale blocks (fork risk) and fees become hard to estimate. am I missing anything?
reply
The irony is that they are using this quote as support for the idea that monetary transactions will outbid spam.
Which is it defer to expertise or the word of Satoshi?
Spam exists or it doesn't?
If spam is defined as the consensus layer then we can just change consensus to service more markets for distributed data storage, everybody wins!
But the reality is that bitcoin gets it's value from the fact that it is so hard to use it for anything other than money.
If you can just outbid the moneyness at the level of block space then bitcoin is nothing but a proof of stake shitcoin, where the people who control the chain are the people who pay the miners the most. But there is no reason to believe that those people would be people using bitcoin as money.
CoreCoin is just a "trust me bro" scam.
reply
Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network.
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.
The problem here is that Core developers are actively stating that there is no such thing as spam, validity is the only criteria, which is a complete and explicit shift away from Satoshi's and the community's intention and understanding for 15 years.
Core developers are breaking the social contract, leading inevitably to the menace of multiple implementations.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.
Nowhere here does he include jpegs, runes, or short videos. He could have, but he didn't.
The problem is that Core developers and their advocates here are lying about the distinction between monetary and non-monetary transactions, because we have been infected by shitcoiners whose own projects failed in the shitcoin distributed database market.
And Core is playing brinkmanship, extorting the community. Anyone who cannot distinguish spam from monetary transactions should in good conscience walk away from the repo until other developers step up, let it sit, let it go through a dormant period, until the dust settles on this.
By forcing the idea that bitcoin is just a distributed database they are creating the scenario where people invested in a monetary network have to fight to protect their investment.
Fees on their own simply won't outcompete spam on fees, not when lightning and other means of transacting bitcoin exist on L2. When there is a scarce resource (block space) people will create all kinds of competitions to exhaust that resource, as a sort of prize, a sorting mechanism.
reply
I wish you would direct your anger at the vandals, not at the janitors.
reply
But the janitors are saying there is no such thing as litter!!!
To be clear, this was a statement from a younger core developer on a recent podcast who seems to have been one of the instigators of this ridiculous debate.
Wuille and Maxwell wouldn't have said there is no such thing as spam just because it cannot be defined deterministically.
The softer position of the spam-apologists is that it exists but will be tamed by fees, which is not a position based upon evidence given the amount of capital invested in shitcoins to date, and the intense historical pressure there has been for bitcoin to support spam as a serviceable market rather than maintaining hostility.
The distributed database on a Blockchain shitcoins only exist because bitcoin is hostile to them.
To hear so many so-called Bitcoiners, who want to be on the winning team but also the winning team has to do what they want, which always fails, to destroy the distinction between monetary and non-monetary transactions and just let the market sort it out.
Satoshi said "There are other things we can do if necessary"
But now Core Devs want to use that same quote out of context to suggest that there was never ever a plan to do anything other than let fees sort it out.
Bullshit!!!
Any Core developer or so-called Bitcoiner who denies the distinction monetary and non-monetary transactions, and therefore the existence of spam as a concept, should fork off, bow out, they are not Bitcoiners. Not because I said so, but because they don't understand bitcoin or want to change what it is against the will of everyone who has invested the 1000 hours to understand and invest in it, technically, financially, intellectually, reputationally, or in any other way.
reply