Hacker News Reader

Comment by sillysaurusx | Hacker News Reader

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.

View on HN

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...

Reply on news.ycombinator.com