Comment by vvillena | Hacker News Reader

Comment by vvillena | Hacker News Reader

Parent Full thread

Blockchains don't have a concept of a "current undisputed state". If you managed to create a longer (and valid) Bitcoin chain on your own than the longest one there is at this very moment, and publish it, all other clients will start using it as the new longest chain. And if two equally long chains are published at about the same time, and clients get split, things will probably get resolved in the next block. So, most of the time, the current longest chain won't probably change, and if you discount, say, the 6 newest blocks (using bitcoin as an example), then it will definitely not change. So, the "undisputed state" and the "current state" are actually separate concepts in a PoW blockchain.

Regarding storage, you argument that transactions shouldn't matter, since the important thing is the state. But then we're back to the fundamental problem. Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.

Don't assume blockchains are bitcoin or BTC like systems.

I talk about the "current and undisputed or better indisputable (final) state". Bitcoin does not have this. Hence it can not function without history. This is a property of BTC not one of blockchains in general.

Plenty other systems have a current state and a final state and there is no "better state" that can comer around and replace it. Final really means final. Its often called a closed ledger. Other systems have checkpoints and what not to reach a similar goal.

BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state.

>Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.

You have no choice. Either you agree with the current final state or you dont use the blockchain. Your choice is to use it or not. You choice is not to validate or not or validate and fix something if its wrong.

The act of validating doesn't do anything. No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all.

Also its not created out of thin air. It was validated by the code. If there is a mistake it is there because of the code people used back when it happened. If you were there running your node it would have made the same mistake. whats the point to find it now? (beside the fact that it was already found and fixed) It doesn't change the state the state is final. Bugs happen. If you assume cheating however then well you should assume someone would have screamed back when it happens so you would already know that someone cheated somehow. Whats the point of validating it? you already know you dont want to use that chain. Zero reason to detect the cheating yourself.

We know pretty well from all incidents where blockchains had to be "fixed" there is no way someone would find an unknown incident by the placebo validation act.

No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all.

I'm a bit of a blockchain noob, but isn't this the opposite of how blockchain works?

What I mean is, yes, you can design it the way you're saying, but doesn't that open you up to double-spend attacks and enforced centralization? You need a central ledger at that point, since your "final state" has to come from somewhere.

I'm confused but intrigued.

EDIT: Ah, https://news.ycombinator.com/item?id=27259783 points out the problems with this approach much more eloquently than I did.

If you have a final state double-spend attacks are actually impossible. They are based on the fact that someone can insert a transaction then "overwrite" it by providing a longer chain where the transaction didn't happen or went somewhere else.

This is only ever possible if there is no final state.

Also not sure why you would need centralization for what. Simplified a final state is when a majority declares it as final not a central entity does that. A double spend would have to include both transaction into the final sate which obviously would violate the systems rules. You cant move the same balance again when you already move it away. So that just wont happen because the code does not allow it. The second Tx is simply invalid just like if you would try to move more coins than you have.

If you want to read more about final consensus see https://xrpl.org/consensus-network.html There are ofc other project with similar concepts this is just the oldest.

Why do you need a blockchain at all then? This is what I really don't get. If you have your "majority" available at all times they just agree on account balances and call it a day. Just like WebMoney did circa 1998.

You dont need a blockchain its a misleading term. There are distributed ledgers that dont requires a chain of blocks.

Also majority in a decentral system is not that simple. It can be done with FBA (Federated Byzantine Agreement). If that's the case, then yes, account balances are simply agreed on and they call it a day (or technically its called a closed ledger). Then they add the next. Now ledger are blocks of data and the best way to order them is to chain them with hashes depending on the previous ledger (block). And we are back to "blockchain". Its still misleading the "magic" part isn't the chain of blocks. Its the fact that the double spending problem can be solves without an arbiter of truth.

>Just like WebMoney did circa 1998.

I dont know about the technical way this was implemented back then but most likely the system was operated by a single entity. There is some kind of master balance database and the all other sync with that. A double spending can be prevented by rules applies to the master DB. AKA a write-sync is denied if it violates the balance rules. This is easy to do centralizes and obviously who ever controls it can circumvent the rules if he wants to.

> Simplified a final state is when a majority declares it as final not a central entity does that.

A majority of what? How do you know if you really have a majority or someone is faking a lot of identities and/or hiding a lot of real ones from you?

And if you later find out you had the wrong "majority" what do you do, if the state is final from your perspective?

A majority of nodes who listen to each other (mutual agreement).

>How do you know if you really have a majority or someone is faking a lot of identities and/or hiding a lot of real ones from you?

You decide in advance from which nodes you want to have a majority agreement. It doesn't matter how many are out there only the ones you listen to matter (for you). However if you choose 1000 nodes and 900 of them are offline then your node will halt because it can not reach a majority. In other words you are forced to listen to reliable nodes if you want to have a reliable node. Also if you listen to 10 but they are all owned by a single person. He can lie to your node. In other words you are forced to listen to nodes operated by different entities. In reality there are for example companies, universities, maybe states non-profit organizations etc. Anyone who wants to use it has aligned interest to not collude with others especially competing entities like 2 different banks or payment provider.

This leads to a core of nodes who mostly all listen to each other. If you want to know the final state without even running a node this would be it. You ask as man nodes as possible form that core of nodes. What the core or nodes made final is final.

Spinning up thousands of nodes dont matter. No one will listen to them. They can all listen to each-other then you essentially created a fork. No one cares, you can no affect what is final and you cant fool anyone unless the voluntary listen to your nodes.

>.... hiding a lot of real ones from you?

The node network is p2p with signed messages there is no hiding. There is relaying ofc so each messages can go the fastest way possible but due to privet/public key encryption there is no tampering possible. If a node would block traffic it just goes another way. If a node "disappears" its considered offline so it is ignored but only if the rest still reaches majority. If too many go offline the network halts until majority can be reached again.

>And if you later find out you had the wrong "majority" what do you do, if the state is final from your perspective?

There can not be a "wrong majority" unless you listen to the wrong network of nodes. If you intentionally dont listen to the current core of the network you basically choose to listen to another network aka a fork.

Its like if you listen to BCH instead of BTC you are free to do so.

https://xrpl.org/consensus-principles-and-rules.html#how-con...

> BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state.

You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example.

N.B. this issue is nuanced in PoS due to the complete absence of a quantitative fork ranking protocol. The PoW blockchains pow1, pow2, pow3 can be algorithmically ranked according to cumulative hash difficulty unfakeable sans external input (electricity). High difficulty == high certainty. Conversely, the PoS blockchains pos1, pos2, pos3, cannot be compared sans external information/trust. All theoretical finality in PoS is based on trust in central authorities — this type of “finality” is similar to the finality you have in a particular OSS project’s Git history, insofar as the history is dictated by trusted authorities in all cases.

As many commentators have quipped historically, you can build centralized systems on top of decentralized ones, but the reverse isn’t true.

>You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example.

Whats the point? No one wants that beside that LN needs BTC on chain Tx which if you dont arbitrary define as final after some blocks makes it exactly the same - not final.

PoS/PoW is rather irrelevant. we already have solutions to make blocks/ledgers final its doesn't need PoW or PoS its just a properties that BTC doesn't have because it was designed without. There is no fundamental reason why it cant have it.

I don’t quite catch your point. The chances your brain continues functioning over the next twelve minutes is not 100%, but 100% less some infinitesimally small fraction. 99.999999...% is as close physical reality ever comes to 100%.

> PoS/PoW is rather irrelevant

It’s an incredibly relevant fact that PoS blockchains pos1, pos2, pos3 cannot be compared without overtly trusting central authorities to give you the “correct” answer. Conversely, the PoW blockchains pow1, pow2, and pow3 can be objectively ranked by cumulative hashrate using simple mathematical comparisons.

Contrary to popular belief — and despite the endless handwaiving PoS acolytes engage in over social media — PoS blockchains continue to lack a meaningful answer to this predicament which doesn’t boil down to overtly trusting central authorities. Which begs the question: why do they need a blockchain at all?

All block chains in practice require trusting central authorities (trust the code, trust the protocol, trust the math behind it, trust the hardware, trust people to honor their off-chain transactions, trust authorities to help when they don't etc.) so this whole fantasy about 'trustless systems' is meaningless anyway.

You can't create trustless electronic systems for humans. There is simply too much complexity in even the simplest hardware and software for any single person to be able to understand without trusting others. And this doesn't just apply to the 'unwashed masses', but to every single CS researcher, OS programmer or Linus Torvalds.

This is blatantly false. Bitcoin doesn't require anything at all besides the idea of a most work chain humanity produced. You just pick it and that's it. You cant pick wrong, there is no chain bigger.

All other cryptos are a fantasy and cannot provide any comparable guarantees.

>You cant pick wrong, there is no chain bigger.

It happened multiple times that a longer change was discoed shortly after. So in reality you have to wait some blocks to reduce the risk of a longer chain to almost zero.

Also the trust you missed is that you have to TRUST that at least 50% of the work is produces and controlled (pool owner) by honest humans, because if not they could collude and re-org/double-spend. which essentially means you will pick the wrong chain because they make you think its the longest while secretly mining a longer chain that will eventually repalce the once you picked. There is absolutely no way you would know before its to late so you blindly trust that from an unknown number of people the majority is honest.

If you take mining pools into account you trust a hand full of people who control them.

>All other cryptos are a fantasy and cannot provide any comparable guarantees.

Obvious nonsense, other tech has defined finality. Not pick the longest and if a longer shows up later you switch. These systems provide MORE guarantees.

How do you, personally, know that the chain is correct? Have you ever checked the hashes? Have you ever checked the transactions? Have you ever proved that the math they use is correct? Have you ever read the code for any BTC client?

You're trusting an awful lot of assumptions much more complex than 'the longest chain is right'.

How do you ensure that you got the correct code? Without the correct consensus rules that are encoded in the software, you can't be sure if the blockchain you are following is the right one.

> PoS blockchains pos1, pos2, pos3 cannot be compared without overtly trusting central authorities to give you the “correct” answer.

I have seen you make this point before on here but I don't see how that is true. Can you elaborate? Don't PoS chains typically choose forks based on how much is staked? Last time we discussed this you never explained what is wrong with that approach.

When the PoW chain ‘pow’ forks into pow1 and pow2 with both sides claiming to be the original ‘pow’, the general public can compare the cumulative hashrate of pow1 and pow2 to ascertain legitimacy (see: Bitcoin v Bcash, 2016).

In PoW, external input to the system — electricity — powers hashrate. Electricity is altogether foreign to the context of cryptocurrency, and by necessitating the wasting of electricity on one fork over another, PoW consensus systems ensure miners can vote on only one side of a fork without bearing additional costs.

When the PoS chain ‘pos’ forks into pos1 and pos2, however, with both sides claiming to be the original ‘pos’, there is no hashrate to base our decision on. External inputs are never burned in any PoS chain’s forward progress.

If a Bitcoin v Bcash political fork were to unfold in a pure PoS context, the general public would be faced with a situation where both pos1 and pos2 chains were equally secure. If pos1 claimed to be the rightful heir to the ‘pos’ title while defensively slashing pos2 sympathizers, it wouldn’t harm pos2’s ability to make forward progress on the pos2 chain while pos2 also slashes pos1 sympathizers and equally claims to be the rightful heir to the ‘pos’ title.

It’s as if an OSS project forked with both forks claiming to be the real thing. If both sides are steadfast, it is ultimately up to the public to pick winners and losers based on nothing besides social signaling. See: 2015-2017 block size debate in Bitcoin for pitfalls to this.

Notice how no math is involved whatsoever in the decision to pick pos1 over pos2.

Notice how human intervention is inherently required to reach a decision as to which side of the pos1/pos2 split is given title to ‘pos’.

Pure PoS consensus is substantially similar to Git repos. If people are just going to trust a nebulous human hierarchy to resolve disputes like this, then the system is de facto permissioned, and a public blockchain isn’t required.

I don't understand how the situations you are describing are different between PoW and PoS.

In either case, after a fork, sympathizers of chain A or chain B will start mining/staking on the chain they like.

In either case, members of the public who just want the chain with the most security can pick the one with the most energy burned or most coin-days staked (that's the "hash rate" equivalent/external input with which to base your decision on).

What is the difference? How is human intervention inherently required in the PoS case any more or less than it's required in the PoW case?

If “coin-days staked” is massively higher on one side of a PoS chain fork, that doesn’t impact the other side’s security in the way PoW hashrate imbalances would.

To use a real world example, Bitcoin PoW mining consumes in excess of 100 Terawatt hours of electricity per year. If Bitcoin were to undergo a repeat of 2016 today, and the Bcash blockchain were to be serviced by miners consuming less than 10% of the energy spend of the incumbent (Bitcoin), Bcash could be easily 51% attacked.

But in the PoS corollary to Bitcoin v Bcash, coin-days staked would have no bearing on Bcash’s ability to continue making forward progress. Just so long as it remained difficult to either disrupt 1/3 of Bcash validators or acquire 51% of it, Bcash would continue functioning perfectly well (see: Jude C. Nelson [1]). At that point the rightful heir to the Bitcoin title would have to be determined socially. It could not be determined without top-down human intervention.

[1]: https://news.ycombinator.com/item?id=26810619

> But in the PoS corollary to Bitcoin v Bcash, coin-days staked would have no bearing on Bcash’s ability to continue making forward progress.

How wouldn't it? The ongoing coin-days staked in that fork specifically is what allows it to continue making forward progress. Just like how in a PoW fork, the ongoing consumption of energy in that specific fork is what determines the security of that fork.

The argument you link in that other thread is interesting but it doesn't appear to be exactly what you are talking about. They seem to be describing an attack where nodes are taken offline by the attacker.

> The ongoing coin-days staked in that fork specifically is what allows it to continue making forward progress.

Coin-days staked has no bearing on a pure PoS chain’s risk of being 51% attacked, nor does it have any bearing on the risk 1/3 or more of its validators get disrupted. Not so with PoW hashrate: enormous hashrate imbalances between forked PoW chains directly translate into decreased data immutability per the risk of deep chain reorgs.

Those risks are simply not present in the PoS corollary.

There is nothing wrong with it, the only trusted component is (obviously) in terms of the initial distribution of the staked coins, which is the central feature of proof of stake.

Reply on news.ycombinator.com