8 ms·

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

77 points by tbv 9y ago

hagreet 9y ago
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.
- pfraze 9y ago
  You don't use decentralized consensus in this model. It's a single node that's maintaining the blockchain state. Monitors actively watch the blockchain to make sure the node doesn't deviate from the code contract. If there is a fork in the blockchain, that'd be because the single node created that fork in an attempt to create two versions of the state-- that's a break in the contract and it would be viewed as a fatal corruption event.
  - hagreet 9y ago
    So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?
    - pfraze 9y ago
      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 blockchains called censorship.) If the node just didn't run your request, you'd be locked out with no evidence. It's not unsolveable, though - you could combat this by using a 3rd party proxy which records the traffic, and thus can back up your claim that you're being censored. 2. That the node won't just shut down. To combat this, you'd need a procedure for moving to a new hosting node. Not impossible either, but you'd need to decide for your userbase what kind of process would make them most comfortable. The blockchain state is there to be cloned at any time.
      - EGreg 9y ago
        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?
        pfraze 9y ago
        Choosing another node won't involve consensus in the way that consensus is described in distributed networks. You'd handle that ideally by a prior agreement -- eg, "if this node corrupts, it's going to go into arbitration via a trusted third party, who will then decide who will resume operating the network."
        wyldfire 9y ago
        IMO this new design is "fine w/me" in the way that ethereum is "fine w/me." If people want a not-so-decentralized cryptocoin that's not-so-trustless, then so be it. If it handles transactions faster, better, cheaper, and with less emissions, then so be it. Unfortunately bitcoin's popularity/ubiquity makes it superior (for the time being) and hard to unseat. Other (decentralized) altcoins make really great improvements over bitcoin but never became (and perhaps never will become) as popular as bitcoin.
      - bmcusick 9y ago
        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 odds of them all going offline at the same time or cooperating to deny a specific user's transactions are very low.
        deleted 9y ago
    - rocqua 9y ago
      Yes, if you can handle forks as long as you can detect them, centralized consensus is a decent solution with much lower costs that PoW. This is essentially how CT-logs work, where we consider it sufficient to detect a falsely-issued certificate, even though we cannot prevent such issuance.
- EGreg 9y ago
  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.
  - Zaak 9y ago
    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?
    - EGreg 9y ago
      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.
      - 9y ago
wmf 9y ago
The catch is at the end: "There are some downsides to losing decentralized consensus. A ledger-backed service could manipulate the order in which it handles requests, or reject some requests altogether, and clients would have a hard time proving it." Calling that a "secure ledger" is kind of a stretch.
- pfraze 9y ago
  There's aaalways a catch. See my response to hagreet. Neither of those problems are unfixable.
  - kybernetikos 9y ago
    Incidentally, I think there may be a product here that could be sold to financial institutions. Check out https://www.hyperledger.org/ https://www.hyperledger.org/ https://www.r3.com/ https://www.r3.com/ There are lots of other 'private blockchain' distributed ledgers being pitched right now to financial institutions and to me the distributed aspect of them seems like a bit of an inconvenient and unnecessary complication for those use cases.
Proven 9y ago
Geee, what a dangerous fool... What good is the ability to tell whether something is shit or fake or completely out of service when I can’t update or restore or correct it? That is totally vulnerable in terms of DoS, state actor confiscation, and censorship. Awful!!!
EGreg 9y ago
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.
- pfraze 9y ago
  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.
  - EGreg 9y ago
    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/ 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 https://news.ycombinator.com/item?id=15646385)
- rocqua 9y ago
  A very quick look at ripple leads to my following interpretation. "ripple is voting with a consensus level of 80%, so it can tolerate byzantine failure of 20% of all nodes". My question is then, how does this deal with sibyl attacks. That is, how does it prevent me from just creating a large amount of participants. Similarly, what happens when nodes 'leave' the system. Say we have 200 nodes, then the consensus level is 160 nodes. What happens when 10 nodes stop responding? Are we forever stuck with the consensus level of 160 or does it ever drop to 152 nodes? In the first case, we are inevitably careening towards faulty nodes forming 20% of all required votes. In the second, we can enforce consensus by censoring other nodes.
karl_gluck 9y ago
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 https://en.wikipedia.org/wiki/Linked_timestamping
- pfraze 9y ago
  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.
bmcusick 9y ago
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.
- wmf 9y ago
  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.
  - pfraze 9y ago
    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.
    - dozzie 9y ago
      > 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.
kybernetikos 9y ago
It's fun to see this here after I've just spent some of the afternoon 'pitching' 'Centralised Ledger Technology'. Single source of truth, verifiable, secure, permissioned, efficient, scalable, the advertising copy writes itself (or would if you needed it to, rather than just taking any of the copy from hyperledger or simlar and fixing it up a bit). Any of the people selling private block chain solutions will generally tell you that there needs to be a strong political actor within a 'business network' that can insist on the use of the distributed ledger. The truth of course is that Mr Car Loader or Mr Fruit Picker who is lent on to run a node on the distributed ledger really couldn't care less about whether they are verifying other peoples transactions or not, they'd be just as happy with a web site that they fill the details in, or a signed email system. Indeed, they might ask - why should I be expected to run computation to secure bits of the value chain I never see, I just care about confirming what I've received and what I've passed on, and I can do that by digitally signing a transfer note. I don't particularly think that using a central secure ledger is surprising or new, but I do think that politically the furor around DLT (and who knows, maybe one day CLT too) has provided us with a fantastic political opportunity to actually fix some of the horrendousness in financial software systems. To my mind, even if the relevant technological change is pretty minor or nonexistent, this is an opportunity for us to replace a bunch of miserable systems duct taped together with more modern systems that have externally accessible APIs baked in from the start.
DINKDINK 9y ago
>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? <snore> 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 https://en.wikipedia.org/wiki/World_energy_consumption >Because you don’t need permission to buy hashing power and participate in Bitcoin, there’s no way a “51% attack” can be stopped, except by outbuying your competitors Incorrect, this author doesn't understand the miner<->node relationship. Miners do what users value or else users change the consensus system they value. DoubleSHA256->Script or Equihash etc etc >In Bitcoin, acceptance of a change is signaled by the miners - once some percent of the miners agree, the change is accepted. This means that hashing power is used as a measure of voting power, and so the political system is essentially plutocratic. Incorrect again. The author is mistaking how consensus-level changes, that users want, are coordinated among miners. BIP 9 was a method where users said "we'll wait for you all miners to coordinate amongst yourself a consensus change" which was used to delay. In the future Bitcoin will use BIP 8 which is "Miners prepare to have your old consensus rejected at flag point X or else your blocks will be orphaned. >Bitcoin has been wildly unstable, with controversies and forks happening quarterly. The bitcoin network is stable as a table. Bitcoin can't deny anyone from creating their own fork from consensus. This is a critical feature not bug, to be able to easily exit from the system. It prevents lock in that plague trusted third parties. >I’d explain proof-of-stake here, except that I don’t totally understand it yet. If you don't understand the second most prominent proposal for decentralized consensus, why are you writing a critique about blockchains? PoS is inherently broken from an economic perspective because it is no more "efficient" than PoW. Marginal Cost = Marginal Revenue. If you have an incentive mechanism that says, "Do X and you get Y money" you're going to spend X<Y amount of economic work to get Y money. http://www.truthcoin.info/blog/pow-cheapest/ http://www.truthcoin.info/blog/pow-cheapest/ PoW = destroy X value in fiat space to gain Y value in Bitcoin space PoS = destroy X value in Ethereum-PoS space (via TVoM, meat-space work) to gain Y value in Ethereum-PoS The value in PoW is that it's very hard to 'more efficiently' consume electricity than your competitor. All that PoS does is push that wasted work into hidden area or human space. >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. Ah, So digicash. Which when it went out of business the market died because there was no coordinator any more to check double spends. Let's assume that the business never can go out of business. If I want to destroy the network, I can compromise one system and control the entire state of the database. Ok let's assume the system is uncompromisible. Oops the state just censored your 'secure' ledger because someone did something with it that the political class didn't like. "We'll host it in a country with 'just' laws" There is no such thing as "the public good" where all people benefit from a certain action. There will always be winners and losers in any policy decision. Now value is sapped from the system by constantly having to pay lawyers to defend your rights from encroachment by the state. The author is right to question if everyone application needs to run on a blockchain (hint: they don't). But if you need trustless, robust, decentralized, uncensorable state to be agreed on by multiple parties, you're gonna need a blockchain
dozzie 9y ago
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.
75dvtwin 9y ago
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 https://eprint.iacr.org/2015/007

77 points by tbv 9y ago

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.

pfraze 9y ago
You don't use decentralized consensus in this model. It's a single node that's maintaining the blockchain state. Monitors actively watch the blockchain to make sure the node doesn't deviate from the code contract. If there is a fork in the blockchain, that'd be because the single node created that fork in an attempt to create two versions of the state-- that's a break in the contract and it would be viewed as a fatal corruption event.
- hagreet 9y ago
  So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?
  - pfraze 9y ago
    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 blockchains called censorship.) If the node just didn't run your request, you'd be locked out with no evidence. It's not unsolveable, though - you could combat this by using a 3rd party proxy which records the traffic, and thus can back up your claim that you're being censored. 2. That the node won't just shut down. To combat this, you'd need a procedure for moving to a new hosting node. Not impossible either, but you'd need to decide for your userbase what kind of process would make them most comfortable. The blockchain state is there to be cloned at any time.
    - EGreg 9y ago
      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?
      - pfraze 9y ago
        Choosing another node won't involve consensus in the way that consensus is described in distributed networks. You'd handle that ideally by a prior agreement -- eg, "if this node corrupts, it's going to go into arbitration via a trusted third party, who will then decide who will resume operating the network."
        wyldfire 9y ago
        IMO this new design is "fine w/me" in the way that ethereum is "fine w/me." If people want a not-so-decentralized cryptocoin that's not-so-trustless, then so be it. If it handles transactions faster, better, cheaper, and with less emissions, then so be it. Unfortunately bitcoin's popularity/ubiquity makes it superior (for the time being) and hard to unseat. Other (decentralized) altcoins make really great improvements over bitcoin but never became (and perhaps never will become) as popular as bitcoin.
    - bmcusick 9y ago
      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 odds of them all going offline at the same time or cooperating to deny a specific user's transactions are very low.
      - deleted 9y ago
  - rocqua 9y ago
    Yes, if you can handle forks as long as you can detect them, centralized consensus is a decent solution with much lower costs that PoW. This is essentially how CT-logs work, where we consider it sufficient to detect a falsely-issued certificate, even though we cannot prevent such issuance.
EGreg 9y ago
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.
- Zaak 9y ago
  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?
  - EGreg 9y ago
    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.
    - 9y ago

wmf 9y ago

The catch is at the end: "There are some downsides to losing decentralized consensus. A ledger-backed service could manipulate the order in which it handles requests, or reject some requests altogether, and clients would have a hard time proving it." Calling that a "secure ledger" is kind of a stretch.

pfraze 9y ago
There's aaalways a catch. See my response to hagreet. Neither of those problems are unfixable.
- kybernetikos 9y ago
  Incidentally, I think there may be a product here that could be sold to financial institutions. Check out https://www.hyperledger.org/ https://www.hyperledger.org/ https://www.r3.com/ https://www.r3.com/ There are lots of other 'private blockchain' distributed ledgers being pitched right now to financial institutions and to me the distributed aspect of them seems like a bit of an inconvenient and unnecessary complication for those use cases.

Proven 9y ago

Geee, what a dangerous fool... What good is the ability to tell whether something is shit or fake or completely out of service when I can’t update or restore or correct it? That is totally vulnerable in terms of DoS, state actor confiscation, and censorship. Awful!!!

EGreg 9y ago

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.

pfraze 9y ago
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.
- EGreg 9y ago
  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/ 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 https://news.ycombinator.com/item?id=15646385)
rocqua 9y ago
A very quick look at ripple leads to my following interpretation. "ripple is voting with a consensus level of 80%, so it can tolerate byzantine failure of 20% of all nodes". My question is then, how does this deal with sibyl attacks. That is, how does it prevent me from just creating a large amount of participants. Similarly, what happens when nodes 'leave' the system. Say we have 200 nodes, then the consensus level is 160 nodes. What happens when 10 nodes stop responding? Are we forever stuck with the consensus level of 160 or does it ever drop to 152 nodes? In the first case, we are inevitably careening towards faulty nodes forming 20% of all required votes. In the second, we can enforce consensus by censoring other nodes.

karl_gluck 9y ago

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 https://en.wikipedia.org/wiki/Linked_timestamping

pfraze 9y ago
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.

bmcusick 9y ago

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.

wmf 9y ago
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.
- pfraze 9y ago
  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.
  - dozzie 9y ago
    > 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.

kybernetikos 9y ago

It's fun to see this here after I've just spent some of the afternoon 'pitching' 'Centralised Ledger Technology'. Single source of truth, verifiable, secure, permissioned, efficient, scalable, the advertising copy writes itself (or would if you needed it to, rather than just taking any of the copy from hyperledger or simlar and fixing it up a bit). Any of the people selling private block chain solutions will generally tell you that there needs to be a strong political actor within a 'business network' that can insist on the use of the distributed ledger. The truth of course is that Mr Car Loader or Mr Fruit Picker who is lent on to run a node on the distributed ledger really couldn't care less about whether they are verifying other peoples transactions or not, they'd be just as happy with a web site that they fill the details in, or a signed email system. Indeed, they might ask - why should I be expected to run computation to secure bits of the value chain I never see, I just care about confirming what I've received and what I've passed on, and I can do that by digitally signing a transfer note. I don't particularly think that using a central secure ledger is surprising or new, but I do think that politically the furor around DLT (and who knows, maybe one day CLT too) has provided us with a fantastic political opportunity to actually fix some of the horrendousness in financial software systems. To my mind, even if the relevant technological change is pretty minor or nonexistent, this is an opportunity for us to replace a bunch of miserable systems duct taped together with more modern systems that have externally accessible APIs baked in from the start.

DINKDINK 9y ago

>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? <snore> 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 https://en.wikipedia.org/wiki/World_energy_consumption >Because you don’t need permission to buy hashing power and participate in Bitcoin, there’s no way a “51% attack” can be stopped, except by outbuying your competitors Incorrect, this author doesn't understand the miner<->node relationship. Miners do what users value or else users change the consensus system they value. DoubleSHA256->Script or Equihash etc etc >In Bitcoin, acceptance of a change is signaled by the miners - once some percent of the miners agree, the change is accepted. This means that hashing power is used as a measure of voting power, and so the political system is essentially plutocratic. Incorrect again. The author is mistaking how consensus-level changes, that users want, are coordinated among miners. BIP 9 was a method where users said "we'll wait for you all miners to coordinate amongst yourself a consensus change" which was used to delay. In the future Bitcoin will use BIP 8 which is "Miners prepare to have your old consensus rejected at flag point X or else your blocks will be orphaned. >Bitcoin has been wildly unstable, with controversies and forks happening quarterly. The bitcoin network is stable as a table. Bitcoin can't deny anyone from creating their own fork from consensus. This is a critical feature not bug, to be able to easily exit from the system. It prevents lock in that plague trusted third parties. >I’d explain proof-of-stake here, except that I don’t totally understand it yet. If you don't understand the second most prominent proposal for decentralized consensus, why are you writing a critique about blockchains? PoS is inherently broken from an economic perspective because it is no more "efficient" than PoW. Marginal Cost = Marginal Revenue. If you have an incentive mechanism that says, "Do X and you get Y money" you're going to spend X<Y amount of economic work to get Y money. http://www.truthcoin.info/blog/pow-cheapest/ http://www.truthcoin.info/blog/pow-cheapest/ PoW = destroy X value in fiat space to gain Y value in Bitcoin space PoS = destroy X value in Ethereum-PoS space (via TVoM, meat-space work) to gain Y value in Ethereum-PoS The value in PoW is that it's very hard to 'more efficiently' consume electricity than your competitor. All that PoS does is push that wasted work into hidden area or human space. >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. Ah, So digicash. Which when it went out of business the market died because there was no coordinator any more to check double spends. Let's assume that the business never can go out of business. If I want to destroy the network, I can compromise one system and control the entire state of the database. Ok let's assume the system is uncompromisible. Oops the state just censored your 'secure' ledger because someone did something with it that the political class didn't like. "We'll host it in a country with 'just' laws" There is no such thing as "the public good" where all people benefit from a certain action. There will always be winners and losers in any policy decision. Now value is sapped from the system by constantly having to pay lawyers to defend your rights from encroachment by the state. The author is right to question if everyone application needs to run on a blockchain (hint: they don't). But if you need trustless, robust, decentralized, uncensorable state to be agreed on by multiple parties, you're gonna need a blockchain

dozzie 9y ago

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.

75dvtwin 9y ago

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 https://eprint.iacr.org/2015/007