6 ms·
A blockchain is secure because in order to "hack" into the database you need to have 51% of the computational power on the network to create the longest chain.
by omarforgotpwd 9y ago
A blockchain is secure because in order to "hack" into the database you need to have 51% of the computational power on the network to create the longest chain. In a large network like Bitcoin or Ethereum the massive computational power of the network ensures generating 51% of the compute power of the network is near impossibly expensive. How secure is a private blockchain? If there are only a few servers the network could be destroyed by just unplugging a few machines, or plugging in a few more.
- ym705 9y agoI 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 agoI 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 agoExactly. 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 agoTrust 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 agoWell, 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 agoThe 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 agoIf 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.
- 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 agoNot necessarily a miner collusion in China, just one of the authorized miners spinning 1,000 EC2 instances to make a 51% attack.
- LeoPanthera 9y ago> In a large network like Bitcoin or Ethereum the massive computational power of the network ensures generating 51% of the compute power of the network is near impossibly expensive. This is an aside, but of the 26 currently active bitcoin mining pools, you'd only need to compromise the top 4 to have >50% mining power. Perhaps a little social engineering could bring that down to 3. I wonder how difficult that would actually be.
- omarforgotpwd 9y agoYes, but those miners have invested so much capital into their mining hardware, software, electricity, etc that they have a strong incentive to make sure that doesn't happen. If an attacker were to gain control of 51% of the network Bitcoin would quickly become worthless or at least drop sharply in price making the whole attack pretty worthless. Not only is it very difficult to get to 51%, there are strong incentives for the relevant parties to make sure such a thing doesn't happen. If entire mining pools were hijacked with malicious mining software, someone would catch on and likely pull the plug on those machines before massive damage could be done.
- deleted 9y ago[deleted]
- jjn2009 9y agoThis is true of proof of work but this isn't necessarily true of all blockchain implementations. Under certain conditions BFT can be maintained without systems such as proof of work.
- jgord 9y agoSomething that hasn't been done much yet, but probably will as the space matures, is for a blockchain to reuse another blockchain as its "timestamp" generator. eg. A 'MyCoin' miner grabs the latest 10 blocks off the main, say, Ethereum blockchain, and includes those hashes as proof they began their block mining _after_ those main blocks were mined, then adds their own proof-of-work on top, winning the block-solve lottery to add the next block to the blockchain. This could potentially reduce the amount of relative advantage a dominant miner has ( others can provide a math analysis ) This approach can also save electricity, as it puts the miners on a mutual 'duty-cycle' where MyCoin miners are only busy running cryptohashes for a fraction of the time between blocks. Another nice side-effect of this 2-tier mining is that the block generation times are spaced more evenly over time. [ They move towards a normal distribution around the average time, rather than uniformly - a result of the 'law of large number's, which states roughly that the average of uniform 'flat' distributions approaches a normal bell curve around the mean ]. Currently Bitcoin blocks sometimes arrive after 1 minute, other times only after 19 minutes, with mean 10mins maintained by adjusting difficulty. So the bitcoin time between blocks variance is high ( Litecoin adds blocks 4x as often @ 2.5mins, Ethereum ~10secs on average, but all with quite high variance ) which can surprise users.
- askmike 9y agoProof of existence is a major problem at the moment. Everyone around me (at an EU bank) wants to do this on bitcoin or ethereum main net, but right now banks are not allowed to touch these networks from the regulators (from a "miners are service providers, they need to be KYCed" perspective).
- just_one_time_ 9y agoThank you. I have been wondering what the specific reason was that Banks still have Bitcoin at arms length. Odd that it is for such a nonsensical reason, no like the bank needs to know the ISP of everyone of their users when they log in.
- deleted 9y ago[deleted]
- decentralised 9y agoPrivate blockchains have client nodes in a closed network or otherwise require some form of "API key" to be procured from the chain's owner to be able to connect. In this case, because there is centralisation of trust, the 51% attack is not possible as there is only one mining node or, otherwise, only one "actor" can actually add blocks to the chain with as many nodes as needed. This is the case with Ripple, for instance.
- 6nf 9y agoSo why bother with a blockchain at all?
- decentralised 9y agoYou mean what are the benefits of a private blockchain? The trust model is different but all other capabilities are kept intact, so in the case of Ethereum you would still have the distributed singleton and immutable code that will always execute in the same way anywhere in the network, at any point in time. For established businesses entering the space, the privacy of closed network compensates the absence of "secrets" to some extent. It is also quite useful as a training ground because of course the technology is still in its infancy.
- 6nf 9y agoSo what's the use case?
- decentralised 9y agoStore and transfer of digital assets?
- 6nf 9y agoYou don't need a blockchain to do that