Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pfrazee.github.io

Post reply on HN
Print view View original

51–60 of 61 posts

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

#51

Post by 3pt14159 »

bmcusick wrote: post #40
3pt14159 wrote: post #33

Earlier quoted context omitted.

What I do not understand is why we couldn't build this onto a web of trust + proof of stake. It may require some more state during resolution, and might even require falling back to automatic service denial if there is a severe network interruption (say in the event of nuclear war), but I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 5…

> I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 51% of the stake that network can prune the excess data (all the signatures) Because of Sybil attacks. > So in your example, if Alice signs both transactions and she doesn't have the funds to fulfil both of them the transaction causes Alice to lose 100% of her money. Remember, the goal…

Short of an adversary having greater than 50% of the coins I don’t really see how a sylbi attack is relevant.

As for Bob isn’t he assured once he sees inclusion of his transaction into the 51% signed dag? Also Alice’s punishment is only for double spending before inclusion into the dag. On second thought it should go to the miners, not just get zapped into the void.

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

#52

Post by EGreg »

Zaak wrote: post #17
EGreg wrote: post #11

Earlier quoted context omitted.

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?

Yes, stop caring about double spend as long as it happens in long term forks. After some point, two different forks become two different communities. Similarly when you restrict gene flow between species which are physically separated, they often can't interbreed anymore. It's called allopatric speciation. There is evidence it happens in nature.

What you should do is have each community have its own internal currency, and then have global payments be powered by a federated system. Like the internet works.

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

#53

Post by dozzie »

The author apparently doesn't understand sh&t about the computer science background of blockchain, since he constantly throws "decentralized consensus" term to mean as a wrong thing. Blockchain does not do that (consensus problem, as stated by computer science, requires the protocol to actually terminate with an output; then, Lamport et al. in their original paper over thirty years ago proved an impossibility theorem that blockchain would break if it was solving the stated consensus problem).

All that blockchain does is to timestamp documents (transactions), the purpose of which is to tell which of the two documents was earlier. Then, the only purpose of proof of work and its derivatives is to artificially slow down signing the documents (transactions), so everybody would have about the same processing speed. This single assumption (that no single entity has computing power comparable to a significant portion of all the others combined) is what allows to choose longer chain in the case of double-spend incidents. When this one breaks, the whole protocol breaks.

There are also other dumb ideas, like that "blockchain is supposed to have a single linear history of transactions". It's not. It would if there was only one party that issues the transactions, so of every two transactions one would be marked as earlier than the other. It's wrong, since there can be incomparable transactions (usually concerning unrelated wallets).

> With proof-of-work, you can have multiple computers make additions to a blockchain without having them trust each other. That’s decentralized consensus.

No. That's distributed timestamping. Again, consensus is totally different problem (and well-defined at that), but author apparently doesn't know that.

> Instead of a network of miners, you use a single host. That host maintains a secure ledger which contains the host state and its activity log, including all requests and their results. That ledger is then published for clients to actively sync and monitor.

Congratulations, you have developed a centralized timestamping service and you have discovered that centralized service is functionally equivalent to a distributed one. Mind you, you're not the first to think about those.

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

#54

Post by dozzie »

pfraze wrote: post #21
wmf wrote: post #18

Earlier quoted context omitted.

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.

Actually I appreciate the defense, but that's not what I'm claiming. I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Single nodes don't have the problems of uncertain ordering or conflict resolution because they can provide strict consensus.

> I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain.

Do you also claim that a one-way hash function only gives a minor gain over a B-tree? Because document timestamping and establishing consensus are different problems.

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

#55

Post by Zaak »

EGreg wrote: post #52
Zaak wrote: post #17

Earlier quoted context omitted.

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?

Yes, stop caring about double spend as long as it happens in long term forks. After some point, two different forks become two different communities. Similarly when you restrict gene flow between species which are physically separated, they often can't interbreed anymore. It's called allopatric speciation. There is evidence it happens in nature. What you should do is have each community have its own internal currency…

Ok, I can see not worrying about permanent forks. How do you deal with double spending in short-term forks that will soon be merged?

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

#56

Post by EGreg »

Zaak wrote: post #55
EGreg wrote: post #52

Earlier quoted context omitted.

Yes, stop caring about double spend as long as it happens in long term forks. After some point, two different forks become two different communities. Similarly when you restrict gene flow between species which are physically separated, they often can't interbreed anymore. It's called allopatric speciation. There is evidence it happens in nature. What you should do is have each community have its own internal currency…

Ok, I can see not worrying about permanent forks. How do you deal with double spending in short-term forks that will soon be merged?

Well, if there is a period that your transaction might get reversed, then the seller can't send you the stuff. Or, maybe you need a reputation system for buyers and sellers and so on (what eBay does) along with chargeback systems figuring out whether to let the transaction be reversed.

Typically, that period is until the next consensus. In Ripple, the consensus eventually takes place but sometimes may take up to a minute. In Bitcoin it may take 30 minutes. You are never quite sure that everyone "phoned in", but presumably if the network participants announce themselves on the network then you can know when a supermajority has "phoned in". If they haven't - you've got a fork baby.

You can also get a fork if they phone in but start a second consensus somewhere else lol.

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

#57

Post by pdkl95 »

dozzie wrote: post #54
pfraze wrote: post #21

Earlier quoted context omitted.

Actually I appreciate the defense, but that's not what I'm claiming. I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Single nodes don't have the problems of uncertain ordering or conflict resolution because they can provide strict consensus.

> I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Do you also claim that a one-way hash function only gives a minor gain over a B-tree? Because document timestamping and establishing consensus are different problems.

A proper hash function provides a lot more than a timestamp. A service with a B-tree (or other traditional database) can rewrite history. Even if have a copy of the db, it's difficult to prove that your version is the service rewrote their version.

If a service wrote all transactions into a log in a way that allows for easy verificatio9n of the validity (including order), and the parties using the service regularly check that log, those parties can demonstrate that the service is acting correctly.

Questions about transaction order and consensus are separate problems, which may not be necessary, depending on the nature of the service. The point, I believe, is that some problems only need some of the features usually associated with "blockchains". We are only beginning to find the interesting uses for Merkle trees, and thus shouldn't blindly use the current bitcoin-style design when the current problem could use something similar,

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

#58

Post by 75dvtwin »

I would agree that many use cases that imply a distributed ledger, do not need a proof-of-work.

Perhaps cryptocurrency still need it, but not many of the 'non-cryptocurrency' use cases.

My argument is centered around a following nuance:

If the use case allows to assume that 'originator' of a particular event is trusted, then the distribution of that event across multiple untrusted servers/access points, does not require a proof-of-work.

The example of how this works is explained in paper " Balloon: A Forward-Secure Append-Only Persistent Authenticated Data Structure

by Tobias Pulls and Roel Peeters

Abstract: We present Balloon, a forward-secure append-only persistent authenticated data structure. Balloon is designed for an initially trusted author that generates events to be stored in a data structure (the Balloon) kept by an untrusted server, and clients that query this server for events intended for them based on keys and snapshots.

" https://eprint.iacr.org/2015/007

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

#59

Post by dreit1 »

bmcusick wrote: post #45
pfraze wrote: post #6

Earlier quoted context omitted.

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…

If I can make a suggestion, you might want to look into the structure of the blockchain networks that use a network of known super-nodes to watch and verify each other. If you have hundreds of known, diverse nodes distributed globally (run by very different institutions like Harvard, Bank of America, the Vatican, the Red Cross, the Gates Foundation, the House of Saud, etc. etc.) they can all watch each other, and the…

This is called delegated byzantine fault tolerance, and what blockchains like NEO and ARK use this, or a variation of it to provide consensus. Token holders basically "elect" the super nodes, and if any begin to act untrustworthy they are "voted out." I'm a fan of this consensus styles because blockchains become semi centralized over time. Maybe not in the technical full validating node way, but certainly politically centralized.

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

#60

Post by neilwilson »

DINKDINK wrote: post #42

>it would be profitable for Bitcoin miners to burn through over 24 terawatt-hours of electricity annually So 0.02%[1] of the global per annum energy consumption? I'll gladly trade that to run an economy without violence and bring financial inclusion to 6 billion unbanked people. [1] 24/109613*100 https://en.wikipedia.org/wiki/World_energy_consumption >Because you don’t need permission to buy hashing power and partici…

"If you have an incentive mechanism that says, "Do X and you get Y money" you're going to spend XThat assumes you know what Y money is worth, when in reality you don't.

If you do X then Y money is worth X by definition because you won't let go of Y money for any less than X value in exchange unless you are forced to.

Post reply on HN