Live data from Hacker News

On blockchains and why secure ledgers don't require proof-of-work

pfrazee.github.io

11–20 of 61 posts

Re: On blockchains and why secure ledgers don't require proof-of-work

#11
post #2

So if there is no proof of work how do you avoid forks? The author says something about splits being detectable but that doesn't really help us decide on which side of the split is correct.

I think this obsession with consensus is a fad.

Forks are ok as long as they can be merged in the short term.

If something forks for a long time and stays forked, there is hardly any reason to establish a total order during the merge!

Think of an IRC netsplit for example. One that happens for a few seconds may attempt to merge back the chats in some fair order they were made, in diff forks.

But if the netsplit happens for a whole day, or month, no one really gives a crap about ordering messages across forks. The merge is too complex! In fact, the resulting conversation would be MORE nonsensical than if you correctly rendered the split conversations as a DAG in the client.

Similarly, if bitcoin forks into bitcoin cash or whatever, and enough validators accept it, I get to "double-spend" my new money now. Proof-of-work is no panacea. If we religiously want consensus then no transaction can ever be truly confirmed - there is always a chance some larger fork comes along and undoes all transactions on my fork going back a whole month. Interplanetary File System has to deal with this.

The problem is that we still haven't evolved our thinking about currencies as DAGs and keep worrying about the double spend problem and turn to global consensus to fix it.

Re: On blockchains and why secure ledgers don't require proof-of-work

#12
post #9

Straw man. Blockchain consensus algorithms don't only use proof of work. We have proof of stake, delegated proof of stake like LISK, proof of Correctness like Ripple (my personal favorite), and so on. No need for a wasteful arms race just to elect a leader who can be DDOSed.

I absolutely do respond to alternatives to proof of work in my post, thank you very much! And I agree that they may be valuable, but I'm skeptical, and you can reread my post to see why. And, by the by, the DDOS argument is a strawman, because we already survive DDOSes in services every day.

Re: On blockchains and why secure ledgers don't require proof-of-work

#13
post #6
post #4

Earlier quoted context omitted.

So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?

Semi-trusted. You have total transparency into whether the node is following the rules of the code contract. The node could not, for instance, change values in the DB without doing so via the contract, and that would be logged for all to see. Very important for something like a key server. There are two things you have to trust, which I mention in the post. 1. That the node is not denying writes. (What's sometimes in…

Sure it can - it can just start reporting different things to different validators.

At this point the validators compare notes and gossip a proof that the node's been acting up. And then they need to elect another node, which requires... consensus!

Oh and the central node can also become unavailable and DDOSed, how are you going to add transactions to the ledger then?

Re: On blockchains and why secure ledgers don't require proof-of-work

#14
Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states.

Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles.

WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or receives both transactions, he can't just look at them and determine one of them is fake. Neither is fake. He needs a way of arbitrating who actually has the bitcoin now - Bob or Charles.

PoW is that arbitration process. Dave looks at the competing blockchains (one with Bob having received it, and one with Charles having received it) and can trust that everyone in the world will respect the chain with greater PoW behind it.

Paul's system has no way of addressing this other than "trust the central authority to process transactions in the order they receive them". Thanks, pal, that's called e-cash, and was invented by David Chaum in 1983.

Re: On blockchains and why secure ledgers don't require proof-of-work

#15

Security can be extremely simple and efficient when you just have to trust a third party. The author is describing Linked Timestamping [1], which has been detailed since the early 90's. Removing the need for trust is what takes all the energy. [1] https://en.wikipedia.org/wiki/Linked_timestamping

Well, no, I'm not describing Linked Timestamping (hereafter LT), because LT is a system for creating trustable timestamps, and I'm talking about a system for auditing the state and operation of a service. Hash/block chains are common and going to get more common. LT, Git, Certificate Transparency, Bitcoin, and now what I'm describing.

And, further, I'm not suggesting you trust a third party, but if you feel I am, please point specifically at where.

Re: On blockchains and why secure ledgers don't require proof-of-work

#16
post #12
post #9

Straw man. Blockchain consensus algorithms don't only use proof of work. We have proof of stake, delegated proof of stake like LISK, proof of Correctness like Ripple (my personal favorite), and so on. No need for a wasteful arms race just to elect a leader who can be DDOSed.

I absolutely do respond to alternatives to proof of work in my post, thank you very much! And I agree that they may be valuable, but I'm skeptical, and you can reread my post to see why. And, by the by, the DDOS argument is a strawman, because we already survive DDOSes in services every day.

You're right, you do mention proof of stake and dismiss it quickly. There is also delegated proof of stake, where validators can elect a leader without needing a proof of work arms race.

But you should really look at Ripple's consensus and study it:

https://ripple.com/build/xrp-ledger-consensus-process/

As well as HashGraph. Both of these do NOT require proof of work!

But in any case I think consensus is the wrong long term goal for technology powering currencies and other things. See my other comment in this thread regarding that (https://news.ycombinator.com/item?id=15646385)

Re: On blockchains and why secure ledgers don't require proof-of-work

#17
post #11
post #2

So if there is no proof of work how do you avoid forks? The author says something about splits being detectable but that doesn't really help us decide on which side of the split is correct.

I think this obsession with consensus is a fad. Forks are ok as long as they can be merged in the short term. If something forks for a long time and stays forked, there is hardly any reason to establish a total order during the merge! Think of an IRC netsplit for example. One that happens for a few seconds may attempt to merge back the chats in some fair order they were made, in diff forks. But if the netsplit happen…

How are you going to merge if you have different spends on the forks you're trying to merge? It's not a matter of whether or not you care about ordering. It's a matter of one branch's spend being invalidated by the spend in the other branch.

If the answer is to stop caring about double spend, how do you anticipate that working?

Re: On blockchains and why secure ledgers don't require proof-of-work

#18

Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states. Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles. WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or…

I think the point is that, hypothetically, some non-financial systems don't require ordering or conflict resolution and thus such systems don't need PoW.

Re: On blockchains and why secure ledgers don't require proof-of-work

#19

Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states. Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles. WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or…

> Paul's system has no way of addressing this other than "trust the central authority to process transactions in the order they receive them". Thanks, pal, that's called e-cash, and was invented by David Chaum in 1983.

Flatly wrong. Decentralized consensus is not a necessity to create trustless operation. Monitoring service operation via a secure ledger provides trustless operation. As I said, the point of PoW is to provide strict transactional consistency in a decentralized network. You're just describing that process mechanically.

Re: On blockchains and why secure ledgers don't require proof-of-work

#20

Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states. Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles. WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or…

There is value in a blockchain beyond a ledger of currency, and some of that value still remains when using a centralized service.

Specifically, if you want to offer a service where you can guarantee non-repudiation a centralized blockchain is a great solution. By non-repudiation, in the scenario of a double-spend whomever signed both transactions is 'on the hook' for both. This doesn't work for currency but works for systems where it is sufficient to prove your servicer screwed you over.

Post reply on HN