Interledger (but possibly not ILP) is a necessary component of the financial blockchain.

[cmbartley]

"...a number of prerequisites for blockchain to fulfill its potential in financial services – and beyond. Key among these is achieving a standard way of implementing the technology. A shared ledgering technology that can provide a consistent view across the broad business network needs a standard way of transferring ledger data. Organisations will participate in multiple ledgers – an FX network, a bond network, et cetera. Just as the internet and intranets share the same technology, so the blockchain proposition needs interoperability to function. In this context, the recently announced open ledger project being orchestrated by the Linux Foundation is critical. Under an open governance model, this project will develop an enterprise grade, open source distributed ledger framework" -- Banking On the BlockChain [Finextra Whitepaper]

[T8493]

Of course ILP is not necessary component of any blockchain.

How is your quote related to this?

[cmbartley]

18 minutes ago, T8493 said:

Of course ILP is not necessary component of any blockchain.

How is your quote related to this?

I meant a necessary component of the broader financial blockchain network (connecting different distributed ledgers), not any singular blockchain. I've looking for evidence as to whether OpenLedger will compete with ILP or not and this quote seemed to suggest that it will.

Edited February 24, 2016 by cmbartley

[JoelKatz]

I haven't seen that quote in context, but it seems to be equating interoperability in the sense of different ledgers using similar software with interoperability in the sense of the ability to coordinate operations on multiple block chains. Bitcoin and many alt coins are interoperable in the first sense, using nearly identical software, but that doesn't make it any easier to manage assets on different blockchains or coordinate operations across blockchains.

[cmbartley]

34 minutes ago, JoelKatz said:

I haven't seen that quote in context, but it seems to be equating interoperability in the sense of different ledgers using similar software with interoperability in the sense of the ability to coordinate operations on multiple block chains. Bitcoin and many alt coins are interoperable in the first sense, using nearly identical software, but that doesn't make it any easier to manage assets on different blockchains or coordinate operations across blockchains.

Okay, a bit unclear to me as well. I'm trying to get a sense for whether Hyperledger/OBC is looking to be the DL hub that sits at the center private consortiums with different use cases OR whether they want to also be the bridge that links individual private and semiprivate ledgers. My sense is that they're looking to be former and create flexible ledgering protocol that can be adapted to the needs private and semiprivate consortiums but every once in a while I see a quote that suggests otherwise. Seems that Ripple believes that their ILP can serve as the bridge between ledgers and are continuing development as such. And I'm sure that if you know, you can't say what IBM/Linux/DAH/Hyperledger's specific strategy is...

Edited February 24, 2016 by cmbartley

[JoelKatz]

1 hour ago, cmbartley said:

Okay, a bit unclear to me as well. I'm trying to get a sense for whether Hyperledger/OBC is looking to be the DL hub that sits at the center private consortiums with different use cases OR whether they want to also be the bridge that links individual private and semiprivate ledgers. My sense is that they're looking to be former and create flexible ledgering protocol that can be adapted to the needs private and semiprivate consortiums but every once in a while I see a quote that suggests otherwise. Seems that Ripple believes that their ILP can serve as the bridge between ledgers and are continuing development as such. And I'm sure that if you know, you can't say what IBM/Linux/DAH/Hyperledger's specific strategy is...

The Hyperledger project is open. While the individual participant's motivations aren't necessarily known to all, the project holds meetings that are not secret. As I understand the project's goals, they're hoping to create a toolkit that can be easily used to piece together private blockchain implementations. This way, you can implement a private blockchain for some specific use case without having to adapt code specialized to a different purpose or write everything yourself.

I haven't heard interoperability in the sense of coordinated operations across ledgers specifically stated as a project goal, but it would be really strange if they didn't implement any such capability. And even if they didn't, surely someone would. If nobody else does, Ripple would likely add ILP support to whatever they wind up producing. Many designs don't even require any special support. For example, nobody ever did anything specific to Bitcoin to make it support ILP, but ILP works with Bitcoin because Bitcoin's transactions have enough flexibility to permit implementing what ILP requires. Any scheme that supports reasonably flexible smart contracts should be able to support ILP too.

Ripple doesn't have any particular reason to care what ledgers/blockchains people use to hold and trade assets. We like the idea of people implementing new ledgers or using schemes based on cryptographic primitives because that will make supporting ILP easier and it also helps clear regulatory hurdles and other obstacles that Ripple may encounter. Our focus is on ILP as way of coordinating operations across ledgers and XRP as a vehicle/intermediary asset.

Personally, I love the technology behind blockchains, but I don't quite understand the role of private/permissioned ledgers. Most of the use cases I've heard seem forced or artificial. Many of them are fake use cases of the "well, what if you need X" form without stating the actual use case where you in fact need X. I understand the use case for open ledgers -- no central authority permits things that can't be done any other way. But if you need a central authority or cooperative entity to manage the membership of the group of participants and the evolution of the system, I don't see why that central authority shouldn't just run the system using traditional methods like VISA, Swift, and DTCC do.

[Phintech]

4 hours ago, JoelKatz said:

The Hyperledger project is open. While the individual participant's motivations aren't necessarily known to all, the project holds meetings that are not secret. As I understand the project's goals, they're hoping to create a toolkit that can be easily used to piece together private blockchain implementations. This way, you can implement a private blockchain for some specific use case without having to adapt code specialized to a different purpose or write everything yourself.

I haven't heard interoperability in the sense of coordinated operations across ledgers specifically stated as a project goal, but it would be really strange if they didn't implement any such capability. And even if they didn't, surely someone would. If nobody else does, Ripple would likely add ILP support to whatever they wind up producing. Many designs don't even require any special support. For example, nobody ever did anything specific to Bitcoin to make it support ILP, but ILP works with Bitcoin because Bitcoin's transactions have enough flexibility to permit implementing what ILP requires. Any scheme that supports reasonably flexible smart contracts should be able to support ILP too.

Ripple doesn't have any particular reason to care what ledgers/blockchains people use to hold and trade assets. We like the idea of people implementing new ledgers or using schemes based on cryptographic primitives because that will make supporting ILP easier and it also helps clear regulatory hurdles and other obstacles that Ripple may encounter. Our focus is on ILP as way of coordinating operations across ledgers and XRP as a vehicle/intermediary asset.

Personally, I love the technology behind blockchains, but I don't quite understand the role of private/permissioned ledgers. Most of the use cases I've heard seem forced or artificial. Many of them are fake use cases of the "well, what if you need X" form without stating the actual use case where you in fact need X. I understand the use case for open ledgers -- no central authority permits things that can't be done any other way. But if you need a central authority or cooperative entity to manage the membership of the group of participants and the evolution of the system, I don't see why that central authority shouldn't just run the system using traditional methods like VISA, Swift, and DTCC do.

 

[Guest Haydentiff]

On 2/23/2016 at 4:10 PM, JoelKatz said:

I don't quite understand the role of private/permissioned ledgers.

I sort of hate myself for bringing this up again, but what exactly do you see as a permissioned ledger and why don't you consider Ripple to be permissioned? 

Tim Swanson said that anonymous validators are unable to be a legally official register of assets. Is this true?  If identity is a requirement to participate meaningfully in the system, how big of a leap is it to add other requirements (criminal background check, credit score, etc)?

I know we went through this ad nauseum on the XRPTalk forum. It sucks not having access those posts. @tommytrain had a lot of great replies that eventually turned into this article http://www.americanbanker.com/bankthink/ripples-overlooked-path-to-decentralization-1075603-1.html?pg=1.

 

[JoelKatz]

3 hours ago, Haydentiff said:

I sort of hate myself for bringing this up again, but what exactly do you see as a permissioned ledger and why don't you consider Ripple to be permissioned? 

I generally consider a permissioned ledger to be one where the set of validators/miners is maintained by an authority (or ledger) whose permission is needed to be added to that set and where permission is needed to access the ledger, submit transactions, and hold assets.

On Ripple's consensus ledger, no permission is needed to connect to the servers, submit transactions, hold assets, and so on. There is no central arbiter of who can and cannot use the system. Any participant can trust any validator they wish without any need to obtain anyone else's permission or to get agreement on the identity of all participants.

 

Quote

Tim Swanson said that anonymous validators are unable to be a legally official register of assets. Is this true?  If identity is a requirement to participate meaningfully in the system, how big of a leap is it to add other requirements (criminal background check, credit score, etc)?

 

I think it's true but it's kind of a red herring. No system, other than a legal system, can ever guarantee that what that system reports is legally enforceable. That really only leaves two kinds of systems:

1) You can have systems like Bitcoin where the system is really all that there is and there are few, if any, legal obligations. In this case, if you have a balance on the system, it should be very highly reliable. But if the system reports something bogus, you're totally screwed and have no recourse at all. You can't even get a court order that the system will recognize but can only go after the actors, if you can find them.

2) You can have systems like Ripple (for assets issued by "real" companies) where the system is just one record of actual legal obligations. In this case, if the system says you have a balance, there is always a chance that the counterparty or legal system will deem that balance unenforceable. But if the system does something wrong or runs off the rails, the participants can contain the damage and enforce sane results.

I don't think one of these is right and the other wrong. Ripple provides 1 (in the form of XRP) and 2 ( in the form of everything else).

 

Quote

I know we went through this ad nauseum on the XRPTalk forum. It sucks not having access those posts. @tommytrain had a lot of great replies that eventually turned into this article http://www.americanbanker.com/bankthink/ripples-overlooked-path-to-decentralization-1075603-1.html?pg=1.

 

I've kind of come around a little bit on private/permissioned ledgers. I do see a use case where you want the equivalent of a consortium but don't want to have to have the consortium have employees, assets, operations, and so on. So you can create a system that works entirely by Byzantine agreement. The initial participants do have to agree on who the initial participants are and what the initial rules will be. But they can do everything after that (add participants, remove participants, change rules) by Byzantine agreement.

[Guest Haydentiff]

10 minutes ago, JoelKatz said:

I generally consider a permissioned ledger to be one where the set of validators/minors is maintained by an authority whose permission is needed to be added to that set and where permission is needed to access the ledger, submit transactions, and hold assets.

On Ripple's consensus ledger, no permission is needed to connect to the servers, submit transactions, hold assets, and so on. There is no central arbiter of who can and cannot use the system. Any participant can trust any validator they wish without any need to obtain anyone else's permission or to get agreement on the identity of all participants.

Thanks, @JoelKatz!

Are there "rules" for running a validator?  If I don't have the network topology configured correctly, can I still connect to the servers?

[Guest Haydentiff]

I read that in order to run a validator that participates in the Consensus process, you need to "Enable Validation".  Can you remain anonymous through that process, @nikb?

ETA: I'm not able to tell if it's possible to remain anonymous when "enabling validation", but this thread contains a lot info about identity and validators:

 

[Twarden]

17 minutes ago, Haydentiff said:

If I don't have the network topology configured correctly, can I still connect to the servers?

I can answer this portion of your question.  If your configuration is not proper, your may still be able to receive inbound connections from peers and receive ripple ledgers but perhaps your systems offset will be incorrect.  In cases such as these, you will submit partial validations to the network which have a good chance of being proposed when that round of consensus has ended.  You may also find that your rippled server cannot access the correct last closed ledger, so your validator will have a very high disagreement rate, but some remaining data in those partial validations may end up in agreement with the network.  

The short answer is yes but you will not be contributing much to the network if your configuration results in a greater rate of disagreement than agreement.

Edited April 12, 2016 by Twarden

[JoelKatz]

1 hour ago, Haydentiff said:

Are there "rules" for running a validator?  If I don't have the network topology configured correctly, can I still connect to the servers?

 

You can connect with any configured topology. With a non-broken topology, you will never see a ledger as validated unless everyone else will also eventually see it as validated. With an optimum topology, you will recognize ledgers that everyone will eventually see as validated more quickly.

 

1 hour ago, Haydentiff said:

I read that in order to run a validator that participates in the Consensus process, you need to "Enable Validation".  Can you remain anonymous through that process, @nikb?

ETA: I'm not able to tell if it's possible to remain anonymous when "enabling validation", but this thread contains a lot info about identity and validators:

 

 

If you enable validation, you will begin publishing validations that are signed with your validating private key and that others can verify with your public key. You can manually tie this to an identity if you want, and if you go to http://validators.ripple.com/ you can see the identities for validators that choose to associate them on the rightmost column.

Usually, the easiest way to establish some kind of reputation that would give people reason to trust you not to collude is to associate your validating public key with some identity. That could be an anonymous identity, for example, you could include it in your signatures on a forum that permits anonymous posts.

People could also, if they wished to, include some number of totally anonymous validators in their UNL based just on historical performance. But this is a bit risky since you'd have no good reason to think they weren't all under common administration and thus could collude to form an attack.

[Guest Haydentiff]

1 minute ago, JoelKatz said:

That could be an anonymous identity, for example, you could include it in your signatures on a forum that permits anonymous posts.

People could also, if they wished to, include some number of totally anonymous validators in their UNL based just on historical performance. But this is a bit risky since you'd have no good reason to think they weren't all under common administration and thus could collude to form an attack.

Thank you (again!).

I don't care about being anonymous (the cat is out of the bag as far as the forum goes, lol), I just wanted to know if it was possible, mostly to argue with people.

[tommytrain]

I've kind of come around a little bit on private/permissioned ledgers. I do see a use case where you want the equivalent of a consortium but don't want to have to have the consortium have employees, assets, operations, and so on. So you can create a system that works entirely by Byzantine agreement. The initial participants do have to agree on who the initial participants are and what the initial rules will be. But they can do everything after that (add participants, remove participants, change rules) by Byzantine agreement.

I try to track Tim's thinking and the Bitcoin crowd's counterarguments closely and I think I have narrowed down where the essential disconnect is. It doesn't help that the original problem statement of Bitcoin: "censorship resistant digital cash" or as Richard Gendal Brown says "no one can stop me from spending my money" isn't necessarily an accurate or helpful problem to solve for the heavily regulated world of institutional finance.

Part of the game theory proof of Bitcoin's validator network relies on the assumption that validators will behave in an economically rational manner, and the only factors for this economic choice reside within relative performance on the network and the subsequent blockchain rewards ecosystem. For all their hype and bluster about Bitcoin being "math-based" this is an awfully soft assumption to stake an entire market economy on and far too soft for an industry with high levels of risk aversion.

The consolidation of miners and control of mining pools to Chinese miners has reached north of 65%, largely on the back of subsidized energy and chip production, an externality which has already tipped he scales of the game theory far beyond level. So powerful is the miners sway, the developers must hold summits to seek approval and backing for minor changes to the protocol which might affect their profit margins. The centralization of risk dependencies onto foreign entities where circumstances are beyond control of participants or developers and could change momentarily is simply an unacceptable architecture.

Sent from my iPad using Tapatalk