
Show HN: Hyperledger – Open Payments Protocol - danoprey
http://hyperledger.com/
======
nessence
Hyperledger's home page talks about a protocol, pools, consensus, security,
and decentralization, however, none of those features exist in the codebase.
Proof of work and distributed networks are why bitcoin and others are more
complex than a list of node URLs and a simple database model.

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.

~~~
feichtinger
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.

------
drcode
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!

~~~
danoprey
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!

------
EGreg
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.

------
haberman
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.

~~~
drcode
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.

~~~
ThomPete
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.

------
sorbits
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?

~~~
feichtinger
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.

~~~
sorbits
> 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).

------
abc123xyz
Is this Ripple in disguise? Who are the people behind this project??

~~~
danoprey
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](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.

~~~
mrb
_" 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?

~~~
feichtinger
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.

~~~
chipsy
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...](http://phys.org/news/2014-04-econophysics-antimoney-financial-
crisis.html)

------
admax88q
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?

~~~
feichtinger
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...](http://zoo.cs.yale.edu/classes/cs426/2012/bib/bracha85asynchronous.pdf)

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/](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.

~~~
regularfry
> 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.

------
deweller
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)

------
tonetheman
Seriously I am too stupid to even know what this is... even after I read the
FAQ. :(

~~~
danoprey
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.

~~~
tonetheman
I did finally get that it was like a distributed setup for a ledger. Thanks
for the extra explanation!

------
haarts
How does it compare with Open Transactions
([http://opentransactions.org](http://opentransactions.org))?

~~~
fiatjaf
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.

------
fiatjaf
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/](http://www.wired.com/2009/06/e-gold/)

(I mean, not exactly this, but something like this.)

------
poseid
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?

~~~
FatalBaboon
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

------
mkrecny
@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?

------
placeybordeaux
Doesn't seem like their trust model really assumes rational agents.

~~~
feichtinger
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.

------
cjg
danoprey - it's not clear to me what the URL is for when creating a new
ledger. Can you clarify?

~~~
feichtinger
Hi cjg,

The service is currently running on four nodes:

[http://hyperledger-staging-1.herokuapp.com](http://hyperledger-
staging-1.herokuapp.com) [http://hyperledger-
staging-2.herokuapp.com](http://hyperledger-staging-2.herokuapp.com)
[http://hyperledger-staging-3.herokuapp.com](http://hyperledger-
staging-3.herokuapp.com) [http://hyperledger-
staging-4.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...](https://github.com/hyperledger/hyperledger-
cli/blob/master/bin/hyperledger#L31)

------
qatrix
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:)

~~~
danoprey
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!

