feichtinger

The question still remains: what should the standard look like? And I think right now there’a not enough agreement on what the Web should be to make standardisation effective.

An interesting idea! I think that was one of the original goals of the VPRI project (http://vpri.org) — very high-level executable specs that encoded the meaning rather than worried about performance. IIRC, their 2D graphics library was about 45 LOC (https://raw.github.com/wiki/damelang/nile/socal.pdf)

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

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.

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.

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.

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.

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.

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.

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 basic difference is that we're trying to cover the complete online banking experience, not just ways to organise and visualise transactions (although that's a part of it too). The big thing missing from Mint for us is payments.

Bunsn generally feels like an app where you can get stuff done. It also works with banks outside of the US and Canada and doesn't require your bank log in details.