The vitriol that Bitcoin evokes from HN commenters can really only be explained by jealousy, the environmental concern is just a cover for covetousness.
Obviously some people are jealous that they didn’t hold Bitcoin earlier and make a lot of money.
But equally, people who hold Bitcoin now are incentivized to dismiss any critique of Bitcoin, since they stand to profit directly from Bitcoin’s reputation.
Therefore the motivations of all participants must be borne in mind, and no ad hominem carries any special weight since all participants have incentives for motivated reasoning.
I remember when I first heard of Bitcoin. I quite frankly found it technically intimidating. It was a totally new concept. I didn't get it. I took my own discomfort as a sort of signal that it was really important; something totally new. So I studied it. I had to put time and effort to read the books, play with the code... Eventually I got it and found it to be one of the most elegant pieces of technology and sociology of my lifetime.
I think a lot of geeks never made that first push past the intimidation. As the value has gone up, the sour grapes have as well. This is a group of people that should have been first on the wagon, but instead many of us found out the hard way we weren't on the cutting edge as much as we liked to think. Myself included, I have some Bitcoin but I'm not a BTC millionaire, like I would have been had I pushed harder through my intimidation faster.
I too wish I’d made more effort to buy it earlier. Presumably that sentiment applies to the majority of humans on earth, whether you are now a Bitcoin millionaire or not.
There is something to say for incentives. The positive incentive loop is what drives adoption, innovation, security etc.
If I come across something that works without PoW, is safe against quantum computers and somehow eliminates the threat of forks (seems impossible), I'll invest in that.
You fell for the meme...
Energy consumption as compared to what? What energy sources? This line of argumentation feels very misleading to me and always has because it is presented with a very specific framing. Here's an alternative framing for example:
https://unchained-capital.com/blog/bitcoin-does-not-waste-en...
At least you sold high, so good on you!
The pedigree of the team behind it is ridiculous, most notably its creator: Silvio Micali - one of the co-inventors of zero-knowledge proofs as well as other cryptographic primitives.
EDIT: it's not quantum-safe yet, but that's a problem they're actively researching, and given the team they seemed credibly positioned to solve it.
See: https://www.algorand.com/resources/blog/chris_peikert_joins_... and https://www.algorand.com/resources/blog/algorand-contributes...
Intentional forking as a feature is ofc still possible. Validators owner who disagree with an amendment to the point that if it is accepted they would want to stay on the "old chain" and thus fork it, can simply remove the "yes" votes from their validator list essentially ignoring their votes and thus separate from each other. By the time one cluster enabled an amendment and the separated cluster does not, a fork happens*. This requires some kind of coordination and is unlikely to happen unexpected. A largely unpopular amendment would simply not reach the 80%. And one that reached 80% is unlikely to be consider so bad by the remaining 20% that they would want to fork. But the possibility is there it just never happened in the 8+ years its running.
*ofc it would also go the other way around. An amendment that wont reach 80% could also cause a cluster to intentionally separate and enable it there which would also case a fork.
The question was: "What exactly is the "threat" of forks?"
Your answer seems to be the answer to the question "How can we prevent forks?"
"Uncertainty" is certainly getting at some sort of answer, but falls short as you're not really explaining what kind of uncertainty and why it's bad in the first place.
Yes uncertainty was the answer. If a fork happens you dont know which side is going to die or if both keep going on. You dont know which sides coin someone wants if he wants to be paid in the coin named prior to the fork. You may not even know there is a fork because it happen on accident and is only discovered after it happened.
I would say this is the "threat" the "bad part" and it is bad because it is unwanted by most users of the system but that's just my opinion. There is now way to proof its unwanted by most user nor does that mean its bad for everyone. So this goes nowhere. If you think its good I'm happy to agree that this is purely an opinion.
A controlled/planed intentional fork seems to be what I assume most people would want but that again is "good" solely because its my opinion.
Hence my message pointed out the fact that we can have the "good" part about forks without the "bad" part about forks if the system prevents the "bad kind" of forks to happen. Your message already pointed out the benefit of forking and preventing unintentional forking would not affect these benefits.
Now to the other part which was really just an example how another system managed to prevent unintentional forking without preventing forking itself. I'm sure there are tons of other solutions so the fact that you don't seem to like this one is kinda irrelevant, it was just the example that I know best and was probably the first around.
Still gonna "fact check" this because why not^^ You seem to be confusing stuff. I wont go any further into a discussion about that tho because quite frankly its all out there to read for anyone who cares. It not my goal to shill stuff or prevent people from reading and believing whatever FUD they choose. Everything can be verified, no need to trust what I tell you, its all public since many many years.
First, the XRPL is not a cryptocurrency and I never said it is, its a distributed ledger. XRP is a cryptocurrency/digital asset/token whatever you wanna call it. There is no consent over the definition for these words so its not really debatable.
The XRPL is however definitely "properly decentralized" regardless of what FUD you may have read about it. Decentralization is rather well defined and whether something is or isn't can be objectively "measured". Although I ofc dont know what _your personal_ definition for "properly decentralized" may be, its decentralized as in no single point of failure or control exists in the system. If you use another definition then it may or may not fit. But this is the most common simplified definition.
For a system that has to "decentralized" reach 80% agreement this means at least 3 independent entities are necessary to make it de-facto decentral. However, 2 colluding would break this already so obviously more than 3 is wanted. 3 would be the theoretical minimum. How many _you personally_ want to have to make it "properly decentralized" _for you_ isn't really a debatable topic, its an opinion. More is objectively better and less than 3 is objectively not decentral anymore.
The XRPL currently has about 30 _legally independent_ validator operators. There is no means to measure independents however. And no means to evaluate what would be needed to make 80% collude. BUT its important to know that colluding would not give them any financial benefit, in fact it would just stop the XRPL from working, which they all voluntary choose to support so that does not make much sense.
There is no double spending or the like possible if someone gains control over 80% of the validators. It could be turned off or they could push an amendment though that does whatever they want but its all public. No honest node can be tricked into breaking its own rules and add any kind of invalid transaction, reverse something or allow double spend. No amount of control can change the code that runs on the other validators. Assuming you dont trust anyone, you have to run your own node and then you can only be fooled if someone takes over your node at which point there is no way to prevent you from being fooled anyway.
If a collusion or take over would happen is would be a situation where a fork would be unavoidable and ofc wanted. Every honest participant would obviously choose the side that didn't push some amendment trough that somehow benefits someone. So there would be a fork with everyone who doesn't wanna play by the rules and the "main chain". This immediately renders the whole collusion useless as they have full control now but only on their own chain that no one cares about and are excluded from voting on the "main chain".
But overall its a purely theoretical scenario. There is no incentive to gain control if you cant do anything useful with it as the honest participants would just fork and exclude the compromised parties. Same if they would turn it off. It would just be a matter of time before the non-compromised parties ignore the offline ones so they can reach 80% consent again.
>(XRP and the XRP Ledger [Ripple])
That makes no sense
- XRP is the token in the XRP Ledger
- The XRPL is the whole system, the "blockchain", the DLT
- rippled is the name of the C++ implementation of the XRPL
- Ripple is a company that currently maintains the source code of XRPL reference implementation (rippled), which is open for anyone including for contribution. They are not controlling the XRPL. They are not controlling the code. Just like controlling the bitcoin GitHub repo does not control bitcoins code or the network.
Ripple also runs validators and in the early days they ran all of them so it was not decentralized according to the definition above. Over time more and more validators joined so Ripple no longer has any special power.
So far exactly 1 amendment was accepted with over 80% quorum without ripples positive votes. That means Ripple could not prevent that amendment from being enabled - they got overruled/over-voted.
Ripple also holds a lot of XRPs that however gives them no special rights or control over the XRPL. Most of these XRPs are in a time escrows.
Hope that clarifies some stuff you may have head. There is always XRPL.org for more in detail information. And like I said its not the only system that prevents unintentional forking.
It’s not too late, you can get back in, though you will have a tax bill. Maybe it can be a wash trade.
But if FUD that’s dishonest about bitcoin mining scared you off then you haven’t learned enough about bitcoin yet.
This us how bitcoin seeks the strongest hands. HFSP
While bitcoin is a record of transactions, and as such a database, it was not created to be a database.
Did you read the OP article?
My take is HN commenters try to typically reason through articles with thought and an open mind. I would wager there are so many bitcoin bros who hype ad nausea that beckons the skepticism you see here.
The argument was that PoW can not not scale. Its an obvious objectively verifiable fact and its completely irrelevant what kind of environmental side effects bitoin has or will have in the future. For all we know it could run on fusion reactors and biodegradable ASICS only and it still would not scale.
Bitcoin can and has scaled. And that is a fact, from Segwit and Taproot to Lightning the capacity and cost have improved dramatically.
Compared to FBA solutions with block times in the single digit seconds and TPS way over 1000 These improvements are as irrelevant as its gets. There is no proposed way to make bitcoin scale to any level that would make it useful on a global scale. And the fun part is, even a proposal that could do this would not go trough. It would just lead to another fork.
But, I think that one way the "energy per transaction" framing is misleading, is for exactly the "if you scaled up the transactions, the power use would scale proportionally" idea. First, it isn't clear to me that it is even possible to scale up the transaction rate without either making the security worse or substantially modifying the design (or possibly both), but if you did manage increase the transaction rate, it isn't clear to me that this would impact the total energy use rate at all.
Well, ok, it might influence the power used by influencing the price or the issuance rate. But, aside from that, I expect that the power use would be determined by whether someone profits by increasing the amount that they spend on power in order to mine bitcoin. This doesn't depend on the transaction rate. Err, ok, I suppose technically if the transaction rate were higher, miners might get more transaction fees, and really the relevant thing is issuance rate + transaction fee rate, but I suspect that the average transaction fee would decrease if the number of transactions were increased, so that impact should be small I think, because those two should largely cancel out.
Hm, ok, so if the transaction fees are determined essentially as an auction, what is the effect on the average fee per transaction, of multiplying the number of items (slots in the block) available per amount of time? I think this depends on the demand curve for transactions. I don't know what that curve looks like. If we pretend that it is linear (just pulling that out of a hat. Though I guess if we zoom in far enough it should look locally linear, unless we zoom in too far and then it will look piecewise constant due to discrete numbers of people... whatever.), then, --- I should get back to work, shouldn't be doing this calculation right now.