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.

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.