Show HN: Hyperledger – Open Payments Protocol(hyperledger.com)
hyperledger.com
Show HN: Hyperledger – Open Payments Protocol
http://hyperledger.com/
44 comments
Hi nessence,
Thanks for your comments! There's obviously a bit of a gap between the proposed details and the implementation at the moment. Having said that, the framework for all of the features you mention are there at the moment, even if the implementation could do with some improving.
Our contention is that replicated HTTP services can provide a trustworthy base for a payments system, so the system is based on REST interfaces and signatures. There's no custom p2p protocol, it's just signed, broadcast HTTP messages. The current staging pool is running on 4 nodes and issuances and transactions aren't processed until at least 3 of them sign the message. The nice thing about signed HTTP messages is that there's a lot of infrastructure and tooling out there that can take advantage of this right off the bat.
The pools themselves aren't inherently private (although they could be, and at the moment we're the only ones running staging nodes) so there's not really a pool owner. Healthy, trustworthy pools should have nodes being run by completely disparate parties, and that's something we're working on getting running.
As for verification, all transfers and issuances are signed by the clients, and all requests are signed by the consensus nodes, and all of that information is public. The CLI doesn't really expose this very well and could definitely do with some work, but basically if queried, a node should be able to show the complete list of transactions that lead to a balance, each one signed by the clients and the nodes. If it can't do that, it's a misbehaving node and should be removed.
One thing that is missing in the code at the moment is primary/replica states and ordering of transactions. That's our next big chunk of work. Proof-of-work does a few things in Bitcoin, but ordering transactions is a big part of that and we think that a primary/replica system can do that without the overheads of proof-of-work.
Finally, I don't quite follow your concern about RSA public keys. I was thinking of moving to NaCl for keys/signatures, but that's an implementation detail at the moment and the protocol could support multiple algorithms. I think 2048-bit RSA keys is okay for now. MD5 signing of the public key is also an implementation detail and might be changed in the future, but I feel it's a pretty reasonable default to start with.
Hope that answers your concerns! Let me know if not.
Thanks for your comments! There's obviously a bit of a gap between the proposed details and the implementation at the moment. Having said that, the framework for all of the features you mention are there at the moment, even if the implementation could do with some improving.
Our contention is that replicated HTTP services can provide a trustworthy base for a payments system, so the system is based on REST interfaces and signatures. There's no custom p2p protocol, it's just signed, broadcast HTTP messages. The current staging pool is running on 4 nodes and issuances and transactions aren't processed until at least 3 of them sign the message. The nice thing about signed HTTP messages is that there's a lot of infrastructure and tooling out there that can take advantage of this right off the bat.
The pools themselves aren't inherently private (although they could be, and at the moment we're the only ones running staging nodes) so there's not really a pool owner. Healthy, trustworthy pools should have nodes being run by completely disparate parties, and that's something we're working on getting running.
As for verification, all transfers and issuances are signed by the clients, and all requests are signed by the consensus nodes, and all of that information is public. The CLI doesn't really expose this very well and could definitely do with some work, but basically if queried, a node should be able to show the complete list of transactions that lead to a balance, each one signed by the clients and the nodes. If it can't do that, it's a misbehaving node and should be removed.
One thing that is missing in the code at the moment is primary/replica states and ordering of transactions. That's our next big chunk of work. Proof-of-work does a few things in Bitcoin, but ordering transactions is a big part of that and we think that a primary/replica system can do that without the overheads of proof-of-work.
Finally, I don't quite follow your concern about RSA public keys. I was thinking of moving to NaCl for keys/signatures, but that's an implementation detail at the moment and the protocol could support multiple algorithms. I think 2048-bit RSA keys is okay for now. MD5 signing of the public key is also an implementation detail and might be changed in the future, but I feel it's a pretty reasonable default to start with.
Hope that answers your concerns! Let me know if not.
Haven't looked into the product yet, but I have to say the web page itself is one of the most beautiful I've seen, from a pure aesthetic standpoint- No dumb animation, uncluttered, distinctive, consistent theming with appropriate use of color, full use of available viewport space, thumbs up to the designer!
Wow. Well thank you for putting a huge smile on my face. Very kind comment and extremely appreciated. Thought it would make a nice change from all the flat design sites out there. I hope your experience with everything else is as good!
I beleve this misses the point. We have always been able to place "small amounts of trust" in smalltime credit issuers. The point of bitcoin etc. is that there is no need to trust ANYONE. When someone you trust betrays the trust you need recourse. Here, there isn't a way for someone to betray your trust, it would take massive effort, so you can rely On the system to transfer money without resorting to legal remedies later and having to allow for fraud.
I am only a dabbler in cryptocurrencies, but let me attempt to compare/contrast this with Bitcoin. Corrections welcome.
Bitcoin is peer-to-peer. Anyone can join as a peer at any time. When you want to spend some Bitcoin, you sign a transaction and send it to your peers, who relay the transaction to other peers if the transaction looks valid to them. But the transaction isn't considered "committed" until it becomes part of the blockchain.
Peers in the network race to create the next block in the blockchain by proof of work. Whoever creates the next valid block first wins, but for a block to be valid it has to contain a solution to a CPU-intensive problem. The reward for winning the race to create a block is that you get to "mint" some brand new bitcoins to yourself, though the number of new bitcoins in each block is predetermined on a deflationary schedule. Anyone who controls over half of the CPU power can control the blockchain.
Hyperledger is not peer-to-peer, it has "nodes" which have to be invited/allowed on the network. Each node has a public/private keypair, and for a transaction to be valid it has to be signed by a node. Nodes only sign transactions if they can achieve consensus with other nodes that the transaction is valid and doesn't double-spend. So you don't have to wait for the next block to get transaction confirmation, you just want to get a node's signature on your transaction
The "Practical Byzantine Fault Tolerance" consensus algorithm can continue to function even if up to 1/3 of the nodes are actively trying to subvert it. Apparently bad nodes can be detected and expelled (how?), but if more than 1/3 of nodes suddenly become malicious, double-spending is possible. So you don't want to invite a node unless you trust it.
Also, instead of a predetermined schedule for minting new coins, the model is that someone can issue units at any time. This must require a consensus too?
Benefits of Hyperledger vs. Bitcoin: Hyperledger can confirm transactions faster since the PBFT algorithm can achieve consensus a lot faster than it takes to build a block (or 2 or 3, to be safe) in Bitcoin. When a transaction is signed by a node, that is a positive confirmation that it was accepted by the network, rather than Bitcoin's less dependable "longest chain wins" rule.
Benefits of Bitcoin vs. Hyperledger: Bitcoin, being truly peer-to-peer, does not require the same management of deciding what nodes to trust and allow onto the network, and expelling them when they turn malicious.
Bitcoin is peer-to-peer. Anyone can join as a peer at any time. When you want to spend some Bitcoin, you sign a transaction and send it to your peers, who relay the transaction to other peers if the transaction looks valid to them. But the transaction isn't considered "committed" until it becomes part of the blockchain.
Peers in the network race to create the next block in the blockchain by proof of work. Whoever creates the next valid block first wins, but for a block to be valid it has to contain a solution to a CPU-intensive problem. The reward for winning the race to create a block is that you get to "mint" some brand new bitcoins to yourself, though the number of new bitcoins in each block is predetermined on a deflationary schedule. Anyone who controls over half of the CPU power can control the blockchain.
Hyperledger is not peer-to-peer, it has "nodes" which have to be invited/allowed on the network. Each node has a public/private keypair, and for a transaction to be valid it has to be signed by a node. Nodes only sign transactions if they can achieve consensus with other nodes that the transaction is valid and doesn't double-spend. So you don't have to wait for the next block to get transaction confirmation, you just want to get a node's signature on your transaction
The "Practical Byzantine Fault Tolerance" consensus algorithm can continue to function even if up to 1/3 of the nodes are actively trying to subvert it. Apparently bad nodes can be detected and expelled (how?), but if more than 1/3 of nodes suddenly become malicious, double-spending is possible. So you don't want to invite a node unless you trust it.
Also, instead of a predetermined schedule for minting new coins, the model is that someone can issue units at any time. This must require a consensus too?
Benefits of Hyperledger vs. Bitcoin: Hyperledger can confirm transactions faster since the PBFT algorithm can achieve consensus a lot faster than it takes to build a block (or 2 or 3, to be safe) in Bitcoin. When a transaction is signed by a node, that is a positive confirmation that it was accepted by the network, rather than Bitcoin's less dependable "longest chain wins" rule.
Benefits of Bitcoin vs. Hyperledger: Bitcoin, being truly peer-to-peer, does not require the same management of deciding what nodes to trust and allow onto the network, and expelling them when they turn malicious.
I think a case can be made for a system like this that uses "consensus nodes" but at the end of the day this approach leads to something like an amphibious car: It's not the best car, and it's not the best boat.
I think it's better, instead, to use bitcoin for some activities and to use a central payment processor for other activities. The central selling points of Hyperledger are "transaction speed" and "low fees"... Why not just use centralized Bitcoin off-chain transactions for these situations, which are even faster and likely even cheaper?
Usually if you want a transaction to be confirmed in under 10 minutes and for a small fee, you're dealing with a transaction under 100 dollars, in which case trusting a central server that is driving off-chain transactions is not a problem.
EDIT: Reflecting more on this, I think a case can be made for a hyperledger-like system beyond a centralized off-chain mechanism, but the problem it solves is small enough that I couldn't imagine using it in the short term. In the long term, something like this may be useful.
I think it's better, instead, to use bitcoin for some activities and to use a central payment processor for other activities. The central selling points of Hyperledger are "transaction speed" and "low fees"... Why not just use centralized Bitcoin off-chain transactions for these situations, which are even faster and likely even cheaper?
Usually if you want a transaction to be confirmed in under 10 minutes and for a small fee, you're dealing with a transaction under 100 dollars, in which case trusting a central server that is driving off-chain transactions is not a problem.
EDIT: Reflecting more on this, I think a case can be made for a hyperledger-like system beyond a centralized off-chain mechanism, but the problem it solves is small enough that I couldn't imagine using it in the short term. In the long term, something like this may be useful.
I guess the answer to that would be that you don't want central control obut you still want to curate who get's to participate.
As I understand it, it is required that people trading units in a ledger trust the ledger’s creator not to issue new units to enrich themselves.
If so, is that much different from using a central service and trust its creator?
If so, is that much different from using a central service and trust its creator?
Hi sorbits,
Yes, you must have some trust in the ledger owner, although, as mentioned in another post, depending on the type of asset it may not be such as issue.
We built the system so that the issuing rules and payment guarantees were separate because we think that's a good thing. We have some ideas as to how we can improve trust and transparency in issuing parties in the future, but that can evolve separately from the payment rules.
Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust and resilience against faults (malicious or not). From the other point of view, if you are an honest issuer (and most should be!) you don't have to worry about creating a trustworthy and reliable payments platform.
Yes, you must have some trust in the ledger owner, although, as mentioned in another post, depending on the type of asset it may not be such as issue.
We built the system so that the issuing rules and payment guarantees were separate because we think that's a good thing. We have some ideas as to how we can improve trust and transparency in issuing parties in the future, but that can evolve separately from the payment rules.
Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust and resilience against faults (malicious or not). From the other point of view, if you are an honest issuer (and most should be!) you don't have to worry about creating a trustworthy and reliable payments platform.
> Yes, you must have some trust in the ledger owner
Then I fail to see the advantage of a decentralised system, as we can let the ledger owner sign each transaction, instead of a consensus.
> although, as mentioned in another post, depending on the type of asset it may not be such as issue.
Can you elaborate or point me to that comment?
> Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust
I would consider the ledger owner’s signature more trustworthy than multiple third party signatures.
> and resilience against faults (malicious or not).
Making it decentralised has a much larger attack (and bug) vector, so I wouldn’t conclude that decentralised in itself is an advantage (which I think is really what you are saying).
Then I fail to see the advantage of a decentralised system, as we can let the ledger owner sign each transaction, instead of a consensus.
> although, as mentioned in another post, depending on the type of asset it may not be such as issue.
Can you elaborate or point me to that comment?
> Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust
I would consider the ledger owner’s signature more trustworthy than multiple third party signatures.
> and resilience against faults (malicious or not).
Making it decentralised has a much larger attack (and bug) vector, so I wouldn’t conclude that decentralised in itself is an advantage (which I think is really what you are saying).
Is this Ripple in disguise?
Who are the people behind this project??
There are lots of similarities but also some very key differences.
The main one being that there is no native currency like XRP, so there is no risk of a similar situation to the current fiasco arising.
hyperledger is designed to be far more light weight and flexible than Ripple, meaning that instead of just being a conduit to trade other assets, hyperledger allows organisations to also issue their own assets, which they have complete control over.
We also have a different notion of pools. Anyone can create their own consensus pool with its own membership requirement rules or features, such as private transaction.
We achieve consensus by a slight different method. More info on this to come, please check the FAQ: http://www.hyperledger.com/faqs.html#ripple
Currently we are a small team of two, myself on the business/marketing side (we will be building commercial products on top of the open project, just as any user could) and feichtinger who is the main technical side. A bit more info on the contact page. Happy to answer any specifics here.
The main one being that there is no native currency like XRP, so there is no risk of a similar situation to the current fiasco arising.
hyperledger is designed to be far more light weight and flexible than Ripple, meaning that instead of just being a conduit to trade other assets, hyperledger allows organisations to also issue their own assets, which they have complete control over.
We also have a different notion of pools. Anyone can create their own consensus pool with its own membership requirement rules or features, such as private transaction.
We achieve consensus by a slight different method. More info on this to come, please check the FAQ: http://www.hyperledger.com/faqs.html#ripple
Currently we are a small team of two, myself on the business/marketing side (we will be building commercial products on top of the open project, just as any user could) and feichtinger who is the main technical side. A bit more info on the contact page. Happy to answer any specifics here.
"there is no risk of a similar situation to the current fiasco arising"
Actually there is. The Ripple fiasco arised because the creator (jed) owned a large amount of XRP, and decided to sell large quantities of it, hence crashing the market. In hyperledger, organisations can issue their own assets, therefore can own a large quantity, therefore can crash the market by selling a lot.
Hyperledger as a platform is technically independent of and will survive such market crashes, but this is kind of irrelevant since the currencies/assets it enables the creation of are exactly vulnerable to all the same flaws that XRP is vulnerable to. Ultimately the users of hyperledger don't care about the platform, but care about the value, fungibility, liquidity of the currencies/assets.
Furthermore, it seems to me hyperledger is not decentralized at all. IIUC the issuance of the currencies/assets is 100% controlled by the rules defined by the organisations that created these currencies/assets, so who would guarantee me for example that organisation X is not going to issue 100 billion more units of currency Y tomorrow?
Actually there is. The Ripple fiasco arised because the creator (jed) owned a large amount of XRP, and decided to sell large quantities of it, hence crashing the market. In hyperledger, organisations can issue their own assets, therefore can own a large quantity, therefore can crash the market by selling a lot.
Hyperledger as a platform is technically independent of and will survive such market crashes, but this is kind of irrelevant since the currencies/assets it enables the creation of are exactly vulnerable to all the same flaws that XRP is vulnerable to. Ultimately the users of hyperledger don't care about the platform, but care about the value, fungibility, liquidity of the currencies/assets.
Furthermore, it seems to me hyperledger is not decentralized at all. IIUC the issuance of the currencies/assets is 100% controlled by the rules defined by the organisations that created these currencies/assets, so who would guarantee me for example that organisation X is not going to issue 100 billion more units of currency Y tomorrow?
Hi mrb,
That's a great point, but at this stage I do think there's a critical distinction between something that's inherent to the platform and something that sits on top of it. Right now we're really focusing only on building the platform and ensuring that it's eventually widely used and trusted.
We have some thoughts about systems for building trust in issuing parties, but that's a long way off!
There are some non-currency assets which can be recorded on hyperledger which don't necessarily have the same concerns. For example, stocks in a company, airline miles, or phone credit.
That's a great point, but at this stage I do think there's a critical distinction between something that's inherent to the platform and something that sits on top of it. Right now we're really focusing only on building the platform and ensuring that it's eventually widely used and trusted.
We have some thoughts about systems for building trust in issuing parties, but that's a long way off!
There are some non-currency assets which can be recorded on hyperledger which don't necessarily have the same concerns. For example, stocks in a company, airline miles, or phone credit.
The discussion of "self-issued assets" brings to mind the Schmitt/Schacker/Braun antimoney paper[0], which defines a mechanism of self-issued debt that operates as a "bicurrency" with a market exchange rate. Very mind-bending stuff.
[0] http://phys.org/news/2014-04-econophysics-antimoney-financia...
[0] http://phys.org/news/2014-04-econophysics-antimoney-financia...
For anyone interested in cutting-edge cryptocurrency protocols, I recommend checking out the Delegated Proof of Stake protocol by Invictus:
http://bitshares.org/documentation/group__dpos.html
http://bitshares.org/documentation/group__dpos.html
Seriously I am too stupid to even know what this is... even after I read the FAQ. :(
Haha. Perhaps we need to update our intro then, as I highly doubt that's true! Essentially, hyperledger is a decentralised set of servers (owned and operated by lots of different people). Each server has the same collection of ledgers, accounts and balances, as each other, i.e., they have consensus over who owns what. When there is a transaction between accounts, the client that controls the account notifies one server, which then checks this is possible with all other servers. Each client and server sign every request they make, so fraudulent transactions can be detected easily and bad clients or servers can be blacklisted.
I did finally get that it was like a distributed setup for a ledger. Thanks for the extra explanation!
I'm no expert but I guess Bitcoin-like system for internet payment?
it's like ripple without the XRP
How does it compare with Open Transactions (http://opentransactions.org)?
I've tried, but never came to understand Open Transactions, but I understood this without even reading. If they are similar, OT made a really poor job explaining itself.
Open Transactions is definitely a similar project and has some really sophisticated financial features. However, our aim is a little different; we want to focus on one thing -- ledgers -- and ensure that it's as simple and easy-to-use as possible, but with a high level of trust because the service is replicated by a number of different parties.
Maybe this is the framework for people wanting to issue gold currencies and not be stopped by the government: http://www.wired.com/2009/06/e-gold/
(I mean, not exactly this, but something like this.)
(I mean, not exactly this, but something like this.)
nicely done! I like the easy overview on creating accounts and making transfers.
i am wondering, when everything is free and open-source here, how is the business model?
i am wondering, when everything is free and open-source here, how is the business model?
The answer lies at the end of the page:
> premiumpool is our commercially supported pool. Restrictions and requirements for operating a consensus node are more stringent and claims made by ledgers are audited. For more information, please Get in Touch
> premiumpool is our commercially supported pool. Restrictions and requirements for operating a consensus node are more stringent and claims made by ledgers are audited. For more information, please Get in Touch
Thanks a lot!
As the other commenter noted, our only plan to directly monetise the project is via a commercially supported premium consensus pool. However, long term we do plan to set up a commercial entity to build on top of hyperledger (in the same way that anyone could) to offer various related services. This are all in far too early stages to share just yet though, I'm afraid!
As the other commenter noted, our only plan to directly monetise the project is via a commercially supported premium consensus pool. However, long term we do plan to set up a commercial entity to build on top of hyperledger (in the same way that anyone could) to offer various related services. This are all in far too early stages to share just yet though, I'm afraid!
@danoprey @feichtinger
First: congrats, this looks fabulous.
Second: can you walk us through one real world example of how a startup might use Hyperledger to do something useful?
First: congrats, this looks fabulous.
Second: can you walk us through one real world example of how a startup might use Hyperledger to do something useful?
Doesn't seem like their trust model really assumes rational agents.
Rational agents in what sense? Consensus pool membership will not be a free for all and running a node will have costs, so we the only people who have incentive to run a node should be those who have an interest in seeing the pool succeed.
Of course, people who want to see the pool fail could run malicious nodes, but given appropriate membership restrictions and that fact that all an attack can do is pause the pool temporarily the incentive there should be pretty low.
Of course, people who want to see the pool fail could run malicious nodes, but given appropriate membership restrictions and that fact that all an attack can do is pause the pool temporarily the incentive there should be pretty low.
Can you elaborate on this? I'm not clear what you mean either.
danoprey - it's not clear to me what the URL is for when creating a new ledger. Can you clarify?
I think you mean the URL in the ledger creation command, e.g., 'hyperledger ledger register newcoin https://newcoin.com'. This would just be the official site of the asset or company, like bitcoin.org is for bitcoin. Currently, this is just used so people can get extra information, but it could be used in the future to remove spam currencies if there is no official site (although we would not be able to do this ourselves, it would require the consent of the entire consensus pool).
Hi cjg,
The service is currently running on four nodes:
http://hyperledger-staging-1.herokuapp.com http://hyperledger-staging-2.herokuapp.com http://hyperledger-staging-3.herokuapp.com http://hyperledger-staging-4.herokuapp.com
You can create a ledger by POSTing to /ledgers at one of those 4 nodes and it will be replicated on the other nodes. The CLI is very rough at the moment but is probably the best place to see how to construct a valid message: https://github.com/hyperledger/hyperledger-cli/blob/master/b...
The service is currently running on four nodes:
http://hyperledger-staging-1.herokuapp.com http://hyperledger-staging-2.herokuapp.com http://hyperledger-staging-3.herokuapp.com http://hyperledger-staging-4.herokuapp.com
You can create a ledger by POSTing to /ledgers at one of those 4 nodes and it will be replicated on the other nodes. The CLI is very rough at the moment but is probably the best place to see how to construct a valid message: https://github.com/hyperledger/hyperledger-cli/blob/master/b...
I think it will be very useful for start-ups for who are hard and too much job to develop payment system. Maybe try it in the further:)
Thanks a lot. Payment networks can be extremely complicated so we all benefit by working on the same underlying layer, as long as it is truly open. Please do and let us know how you get along!
The FAQ dismisses 51% attack quite quickly, while casually mentioning that it's vulnerable to a 33% attack.
What prevents an malicious actor from getting 34% of nodes, and then turning them all bad at the same moment?
What prevents an malicious actor from getting 34% of nodes, and then turning them all bad at the same moment?
Thanks for taking the time to read through!
The wording on that could be improved a little because there's a bit of a distinction between total computing power and number of nodes.
It's a proven result that in asynchronous systems with potentially malicious nodes, 1/3 is the maximum number of faulty replicas that can be tolerated. Here's a paper with a proof: http://zoo.cs.yale.edu/classes/cs426/2012/bib/bracha85asynch...
Bitcoin mixes things up a bit by also taking into account total computing power, but is still vulnerable to attacks where more than 33% of nodes are controlled, like selfish mining: http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
If more than 33% of nodes are compromised at the same time the good nodes will not accept bad transactions, they will simply wait until the consensus pool is fixed or removed and then continue normally.
Of course, with enough nodes it should be very unlikely for an attacker to get control of that many nodes at once.
The wording on that could be improved a little because there's a bit of a distinction between total computing power and number of nodes.
It's a proven result that in asynchronous systems with potentially malicious nodes, 1/3 is the maximum number of faulty replicas that can be tolerated. Here's a paper with a proof: http://zoo.cs.yale.edu/classes/cs426/2012/bib/bracha85asynch...
Bitcoin mixes things up a bit by also taking into account total computing power, but is still vulnerable to attacks where more than 33% of nodes are controlled, like selfish mining: http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
If more than 33% of nodes are compromised at the same time the good nodes will not accept bad transactions, they will simply wait until the consensus pool is fixed or removed and then continue normally.
Of course, with enough nodes it should be very unlikely for an attacker to get control of that many nodes at once.
> Of course, with enough nodes it should be very unlikely for an attacker to get control of that many nodes at once.
I wouldn't bet on it. Look at the warnings that have gone out about the last couple of Rails RCE vulnerabilities: attackers can scan the entire Internet for vulnerable apps in a faster time than many sysadmins can get the upgrade deployed. Now, imagine this: a potential attacker, ahead of time, finds a way to reliably remotely fingerprint the version of Rails you've released as hyperledger. One scan later, they're sitting on a list of the IP addresses of some large proportion of hyperledger installs. All they now need to do is wait for the right vulnerability to be announced (or find it themselves), and then it's a race to gain control before a) the Rails team publishes a patch, b) you release a new version of hyperledger with the patch applied (or can announce that the patch doesn't break things via a gem upgrade), c) more than 66% of the sysadmins jump on the announcement. In the time for a), b) and c) to happen, they need to i) run a single exploit, and ii) simultaneously generate a bad transaction, across the servers they now control.
a), b), and c) are humans. i) and ii) are a for loop in a single bash script. That's not a race I'd want to be on the wrong side of.
I wouldn't bet on it. Look at the warnings that have gone out about the last couple of Rails RCE vulnerabilities: attackers can scan the entire Internet for vulnerable apps in a faster time than many sysadmins can get the upgrade deployed. Now, imagine this: a potential attacker, ahead of time, finds a way to reliably remotely fingerprint the version of Rails you've released as hyperledger. One scan later, they're sitting on a list of the IP addresses of some large proportion of hyperledger installs. All they now need to do is wait for the right vulnerability to be announced (or find it themselves), and then it's a race to gain control before a) the Rails team publishes a patch, b) you release a new version of hyperledger with the patch applied (or can announce that the patch doesn't break things via a gem upgrade), c) more than 66% of the sysadmins jump on the announcement. In the time for a), b) and c) to happen, they need to i) run a single exploit, and ii) simultaneously generate a bad transaction, across the servers they now control.
a), b), and c) are humans. i) and ii) are a for loop in a single bash script. That's not a race I'd want to be on the wrong side of.
The same thing stopping 34% of banks all going bad at the same moment: the number of banks
> bad nodes are automatically detected and expelled quickly
I'd be curious how the detection mechanism works
> bad nodes are automatically detected and expelled quickly
I'd be curious how the detection mechanism works
Well, that would partly depend on the consensus pool as they may have their own blacklisting mechanisms, but broadly every message in the system is signed by the client making the request, and the consensus node passing it on. Every signature is published, so consensus nodes passing on messages that were incorrectly signed can be detected very easily. There are other attacks (not forwarding any messages is a simple one) that can be used, so pools will have to implement their own policies on timeouts/uptime etc.
[deleted]
After looking through code, a number of concerns are also raised:
- key pairs use RSA - identities are based on MD5 of RSA public key - no p2p protocol for nodes - lack of proof of work (more on that below)
As-is, the project is a rails application which references accounts by MD5 of the public key, a postgresql database, and a REST client. In other words -- basic rails ledger app plus some PKI.
I see a significant issue with hyperledger, in that the pools are, by nature, private. The only verification a client can perform is the SSL certificate. A pool owner, if they wish, could change the account balance on all of their private nodes and there would be no public record of the change or the previous history. Yes this would require collusion of some kind, but even for 10k nodes, such data can be changed in seconds. Without a blockchain, how could anyone prove otherwise?
I see the potential for companies like quickbooks, paypal, or even banks, to create public REST interfaces for their account ledgers. This seems inexpensive for a bank to do (compared to a p2p network), and, we'd have the trust of the bank. This is money after all, so, I'd trust the bank over a psuedo-private network.
Looking forward to see how hyperledger will approach the problems described above. I would be surprised if the end-result isn't similar to bitcoin.