5 ms·

I recommend reading this: https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/ https://blog.ethereum.org/2015/08/07/on-public-and-private-b..

by ym705 9y ago

I recommend reading this: https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/ https://blog.ethereum.org/2015/08/07/on-public-and-private-b... . In a private blockchain the reading and writing permissions are controlled, therefore only selected nodes can write to it. "The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply." I guess you could still have attack from authorized nodes in your own organization?

gburt 9y ago
I read the article and he doesn't really answer why this is beneficial. If you have an arbiter of truth, isn't it just a really inefficient database?
- omarforgotpwd 9y ago
  Exactly. A blockchain is supposed to provide a set of guarantees so the nodes don't have to trust each other. If there is already trust, why bother with a blockchain in the first place? If there isn't trust, then there's definitely a possibility that one of the untrusted parties could try and attack or disrupt and the shared ledger.
  - askmike 9y ago
    Trust is not always so black and white (as on the open internet where anonymous people try to scam each other), in a lot of business cases there are different levels of trust which needs to be handled in a different way.
omarforgotpwd 9y ago
Well, if you only need to maintain transactions within your own organization and there is full trust, why not just use a simple SQL database to record transactions instead of a much more expensive and complex blockchain? If there are multiple parties, what's to stop one of the nodes from, say, buying 1000 GPU instances on EC2 and massively increasing their hashing power. Even if you have some type of network control settings that only allow certain nodes access to the network, the proof of work could be distributed and you could just proxy the answer back to the machine that has access to the network.
- wmf 9y ago
  The case for private ledgers is coordination among a moderate number of non-anonymous mostly-untrusted entities. (Whether this case ever exists is left as an exercise for the reader.) They can't use a central database but they don't need mining either; variants of BFT can be used that work as long as (n/2)+1 entities are honest.
  - eterm 9y ago
    If things are non-anonymous, you are far far better off having highly fungible but also highly audited databases. Make it easy to do but also easy to undo anything, while also having a very large amount of transparency in the system so any "bad actor" can be dealt with swiftly. That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly. Abusing the system then no longer becomes a technical challenge so it removes the possibility that someone with the right technical prowess can "break" the system. Robbing a bank is the easiest thing in the world, just walk in and ask for money, it's getting away with it that's difficult.
    - askmike 9y ago
      > That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly. I work for a bank on blockchain projects. It's almost never this simple. You'd be suprised how much banking is paper based right now for the simple reason that no party wants a central solution controlled by any other party.
      - mercer 9y ago
        That's fascinating. Could you tell more about that, or maybe provide a link to more information? I find the topic interesting, and as a geek am inclined to find blockchain stuff cool and useful, but I know very little about the real-world situation/concerns.
buckie 9y ago
> The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply. That's just wrong. Dangerously so. Maybe I'm just missing something in his protocol spec and he didn't really mean mining... I've discussed this attack vector in more depth here[1]. Even if you made the mining function signing the block with your sk it'd still be wrong. Even if you forced the sk holder to have that same sk protect something really valuable, it would still be wrong... just have a larger disincentivize. The whole point of mining is that it's non-auditable (w.r.t. who is physically mining) -- the only real metric you get is the speed of success which you can always mask by not releasing a block immediately. That's why PoW is a cockroach of a consensus protocol. In the "we roll a dice to see who gets to append to the ledger next" metaphor for consensus, deterministic and PoS both require you to know the number of sides the dice have before you roll them. In PoW, you don't figure out the number of sides until after. [1]: http://kadena.io/blog/MiningInPrivate.html http://kadena.io/blog/MiningInPrivate.html
ghgr 9y ago
Not necessarily a miner collusion in China, just one of the authorized miners spinning 1,000 EC2 instances to make a 51% attack.

by ym705 9y ago

gburt 9y ago

I read the article and he doesn't really answer why this is beneficial. If you have an arbiter of truth, isn't it just a really inefficient database?

omarforgotpwd 9y ago
Exactly. A blockchain is supposed to provide a set of guarantees so the nodes don't have to trust each other. If there is already trust, why bother with a blockchain in the first place? If there isn't trust, then there's definitely a possibility that one of the untrusted parties could try and attack or disrupt and the shared ledger.
- askmike 9y ago
  Trust is not always so black and white (as on the open internet where anonymous people try to scam each other), in a lot of business cases there are different levels of trust which needs to be handled in a different way.

omarforgotpwd 9y ago

Well, if you only need to maintain transactions within your own organization and there is full trust, why not just use a simple SQL database to record transactions instead of a much more expensive and complex blockchain? If there are multiple parties, what's to stop one of the nodes from, say, buying 1000 GPU instances on EC2 and massively increasing their hashing power. Even if you have some type of network control settings that only allow certain nodes access to the network, the proof of work could be distributed and you could just proxy the answer back to the machine that has access to the network.

wmf 9y ago
The case for private ledgers is coordination among a moderate number of non-anonymous mostly-untrusted entities. (Whether this case ever exists is left as an exercise for the reader.) They can't use a central database but they don't need mining either; variants of BFT can be used that work as long as (n/2)+1 entities are honest.
- eterm 9y ago
  If things are non-anonymous, you are far far better off having highly fungible but also highly audited databases. Make it easy to do but also easy to undo anything, while also having a very large amount of transparency in the system so any "bad actor" can be dealt with swiftly. That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly. Abusing the system then no longer becomes a technical challenge so it removes the possibility that someone with the right technical prowess can "break" the system. Robbing a bank is the easiest thing in the world, just walk in and ask for money, it's getting away with it that's difficult.
  - askmike 9y ago
    > That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly. I work for a bank on blockchain projects. It's almost never this simple. You'd be suprised how much banking is paper based right now for the simple reason that no party wants a central solution controlled by any other party.
    - mercer 9y ago
      That's fascinating. Could you tell more about that, or maybe provide a link to more information? I find the topic interesting, and as a geek am inclined to find blockchain stuff cool and useful, but I know very little about the real-world situation/concerns.

buckie 9y ago

> The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply. That's just wrong. Dangerously so. Maybe I'm just missing something in his protocol spec and he didn't really mean mining... I've discussed this attack vector in more depth here[1]. Even if you made the mining function signing the block with your sk it'd still be wrong. Even if you forced the sk holder to have that same sk protect something really valuable, it would still be wrong... just have a larger disincentivize. The whole point of mining is that it's non-auditable (w.r.t. who is physically mining) -- the only real metric you get is the speed of success which you can always mask by not releasing a block immediately. That's why PoW is a cockroach of a consensus protocol. In the "we roll a dice to see who gets to append to the ledger next" metaphor for consensus, deterministic and PoS both require you to know the number of sides the dice have before you roll them. In PoW, you don't figure out the number of sides until after. [1]: http://kadena.io/blog/MiningInPrivate.html http://kadena.io/blog/MiningInPrivate.html

ghgr 9y ago

Not necessarily a miner collusion in China, just one of the authorized miners spinning 1,000 EC2 instances to make a 51% attack.