We saw magic of speculation, now We should see the magic of real use

Thanks R8... I did not know it was Red Hat core. Red Hat is US Navy funded.

--

Any installation of Ripple software will the following:

1: the organizations developers would review the source code

2: the organizations developers would create the hardware and operating system environment for production system

3: the organizations developers would create a secure development environment

4: the organizations developers would decide how to securely 'deliver' the Ripple software to production servers

5: the organizations developers would compile the Ripple software

...

And that is just the beginning.

...

I would consider using Qnix, a Canadian company and I think still owned by Blackberry RIM. Qnix is a hardened OS and runs in secure environments. What would be interesting would be to take Qnix Mobile OS and configure Ripple software for the mobile environment. 

:-)

--

I guess lastly, Ripple must have a flavour of say RippleD that is not open source. They would do this so that their customer base could readily validate the core source code and extend it without having to reassess the bare metal core.

--

If anyone wants to fund a Qnix installation for research purposes I would be interested in participating. Maybe those 3-letter organizations monitor these threads.

:-)

7 minutes ago, Max Entropy said:

Thanks R8... I did not know it was Red Hat core. Red Hat is US Navy funded.

--

Any installation of Ripple software will the following:

1: the organizations developers would review the source code

2: the organizations developers would create the hardware and operating system environment for production system

3: the organizations developers would create a secure development environment

4: the organizations developers would decide how to securely 'deliver' the Ripple software to production servers

5: the organizations developers would compile the Ripple software

...

And that is just the beginning.

...

I would consider using Qnix, a Canadian company and I think still owned by Blackberry RIM. Qnix is a hardened OS and runs in secure environments. What would be interesting would be to take Qnix Mobile OS and configure Ripple software for the mobile environment. 

:-)

That's really great suggestion,  I hope one of you guys see @Max Entropy's messages above to combine rippled into a OS Platform and offer the whole thing as one simple installable. @JoelKatz @Tim @warpaul Calling your attention.  I know you guys must be busy, but you got to read this when u get a chance. 

Just by doing this, we will avoid so many seen and unseen security pitfalls etc. Important suggestion. and making Mobile version of it, is nothing short of starting a 'node-everywhere' strategy. The international resiliency, diver spreading of nodes and node count would all sky rocket. 

Yes, an exploratory way to do this would be a VM appliance package... say using Qnix <some flavour>. The appliance could then be downloaded and run as is... Without configuration or provisioning.

1 hour ago, Max Entropy said:

For example, I do not think for a minute that the Bank of England, say, if they operated a RippleD installation would be running vanilla Ripple software... either in the RippleD compiled installation, or in the Eco-system around it, or on the OS in question, which Ripple says is, Ubuntu.

The same would true of the Bank of Canada. Each will be unique in ways. What will be common will be the protocol, and transaction representations.

I am just not sure what to make of this... what differences do you expect in the software, beyond changes to the configuration file to account for things like file paths and open ports, would you expect a bank to make to the source code of the rippled?

Do you honestly think that they will have a patchset that they maintain and apply to the source code on a regular basis? To what end would they do such a thing?

I can tell you that all the Ripple partners that I am aware of run stock ('vanilla' as you call it) rippled, with most of them opting for the compiled packages that Ripple provides.  

At Ripple, we use a combination of different operating systems, including RHEL, CentOS and Ubuntu. I know we have a repo that included the hardening recipes we applied in our own installs (https://github.com/ripple/chef-os-hardening) but I think that we no longer use those and the repo is a bit out of date. Consider looking at the upstream of that repo (https://github.com/dev-sec/chef-os-hardening).

1 hour ago, Max Entropy said:

I guess lastly, Ripple must have a flavour of say RippleD that is not open source. They would do this so that their customer base could readily validate the core source code and extend it without having to reassess the bare metal core.

We do not. What you see on https://github.com/ripple/rippled is what you get. Fun fact: we install rippled on the Ripple servers using the RPM files that we make available to the public, and which are linked in every version's release notes. We've even documented the process that we use: https://ripple.com/build/rippled-setup/#installing-rippled.

1 hour ago, Max Entropy said:

I would consider using Qnix, a Canadian company and I think still owned by Blackberry RIM. Qnix is a hardened OS and runs in secure environments. What would be interesting would be to take Qnix Mobile OS and configure Ripple software for the mobile environment. 

Qnix? Are you thinking of QNX? I don't think that's a good platform for rippled. QNX is a real-time O/S and while it is great for certain applications, general purpose computing isn't one of those. Frankly, I'd consider porting rippled to OpenBSD before I'd consider porting it to QNX. 

Hi NikB,

Yes, of course... I use the Qnix term to reference its UNIX origins. To my knowledge it is the OS that is the most hardened today. Of course, it is a real time OS. I have used parts of this OS in robotics for communications processes for stuff in the remote harsh conditions with relatively low power that require secure communications. I do not see a problem using Qnix for a Ripple node, especially a mobile node. Qnix is already the dominant OS in mobile environments. It is for reasons of security, robustness, low power and secure communications that are of interest.

The argument that real time processing disadvantages the Ripple software is not valid.

--

With regard to the vanilla Ripple software release process, I expect that will change. There will be different versions, just as Microsoft has different versions of its servers and applications (MS Exchange, Directory) for different customers. I have had several foreign embassies use our software for their worlds and these releases are highly customized for secure messaging communications. They do their own builds and the extensions... very paranoid and secure.

I can not imagine messaging to be more secure than financial software.

Back to potential XRP use cases...

There are probably better uses for XRP than payments, but some of the newer payment methods really suck.I don't know why everyone hates QR codes. I like them.  I've only used them for Bitcoin purchases, but it's been an easy and smooth experience. My son even made a comment the other day after using Bitcoin to purchase a game online from Steam -"QR codes make everything easier."

I went out to eat the other day and the bill came with a QR code. I'm not embarrassed to admit I was super excited to try it out. I scanned the QR code (after downloading a QR scanner app) and was sent to a 3rd party payment provider -NCR Pay. I had to create an account (pain) and store my credit card into (ick) before attempting to pay the bill. The waitress said she hates it when people pay online because she doesn't receive a notification that the bill was paid. It can take up to 20 minutes to show up and she has to log into something to check. I tried to pay that stupid bill for like 20 minutes. It seemed like I was stuck in some weird circular loop and I was unsure if I was paying over and over again. The waitress logged into the system from her end and saw there was an error with the security code on the back of my credit card. No such error appeared on my end and there wasn't even a field to enter that security number. I ended up having to give the waitress my credit card to pay the bill.

I went across the street to my favorite brewery right after. I bought a beer using Bitcoin in less than a minute. The waitress brought a device (looked like a Kindle) with a QR code,  I opened my Bitcoin wallet, scanned the QR code, all of the fields were autopopulated on my screen and I simply swiped to the left to accept the charge. The device the waitress was using immediately registered my payment. Easy peasy. I didn't have to register with a 3rd party or plaster my credit card info all over the place. Push payments, especially for online payments, are the way to go for peace of mind.

That is all.

#ProofOfBeer

Back to more use cases...

I think of 'machines' as un-banked.

I would like to see mesh networks of machines transacting remotely, globally independent of humans. In this context I think there are way more use cases.

An example would be in transportation systems, wherein monitoring and real time payments could be transacted from the field... say containers in a Singpore ship yard. The utility of Qnix Mobile would make sense as the OS is already dominant these fields.

--

The plus... is that machines never need beer... they just work.

22 minutes ago, Max Entropy said:

Yes, of course... I use the Qnix term to reference its UNIX origins. To my knowledge it is the OS that is the most hardened today. Of course, it is a real time OS. I have used parts of this OS in robotics for communications processes for stuff in the remote harsh conditions with relatively low power that require secure communications. I do not see a problem using Qnix for a Ripple node, especially a mobile node. Qnix is already the dominant OS in mobile environments. It is for reasons of security, robustness, low power and secure communications that are of interest.

The argument that real time processing disadvantages the Ripple software is not valid.

Please note: I didn't say that real-time processing would disadvantage Ripple; I said I don't think QNX is a good platform for rippled. I see no inherent advantages that QNX-qua-QNX has that would be of benefit.

As I said, from a security perspective, I think that it makes a lot more sense to port rippled to OpenBSD. YMMV. I'm also not sold argument about "secure communications": what secure communications facilities do you imagine a stock rippled server needs and how is QNX better at providing them than, say, RedHat Enterprise Linux? 

29 minutes ago, Max Entropy said:

With regard to the vanilla Ripple software release process, I expect that will change. There will be different versions, just as Microsoft has different versions of its servers and applications (MS Exchange, Directory) for different customers. I have had several foreign embassies use our software for their worlds and these releases are highly customized for secure messaging communications. They do their own builds and the extensions... very paranoid and secure.

I can not imagine messaging to be more secure than financial software.

There are several reasons for Microsoft to offer multiple versions of certain software. Some are good and rooted in a real need; others are mostly financial.  I don't think any of those reasons are applicable to the case of rippled. At least as far as I can see anyways.

But if partners wish to compile rippled from source, they can. I won't say all, since I don't know that for sure, but I do feel confident i saying that most don't. What's more, I doubt that that will change. And I very much doubt that any Ripple partner will maintain a set of patches that they will apply on top of the official Ripple release, before compiling.

P.S.: You may not know, but in a previous life, I developed secure messaging and storage software that is used by government agencies. So I know how that works too. But I digress...

21 minutes ago, Max Entropy said:

Back to more use cases...

I think of 'machines' as un-banked.

I would like to see mesh networks of machines transacting remotely, globally independent of humans. In this context I think there are way more use cases.

An example would be in transportation systems, wherein monitoring and real time payments could be transacted from the field... say containers in a Singpore ship yard. The utility of Qnix Mobile would make sense as the OS is already dominant these fields.

Yep. This is exactly right: "Internet of Things" + Payments. I think there's huge, untapped potential in that field.

Well without debating this in public, I am sure that once Ripple gets past the demo/prototype stage and focused on product delivery, then the real discussion about security, stability and robustness will become apparent. Or stated differently, I would not allow a 'stock' build of anyone's software into a secure financial environment. Maybe your customers will.

I am not usually wrong about these things...just early.

46 minutes ago, Haydentiff said:

Back to potential XRP use cases...

There are probably better uses for XRP than payments, but some of the newer payment methods really suck.

I'm with you there, Tiffany. I see stores deploy new and "innovative" payment methods and all they amount to is a layer (of varying thickness and quality) on top of the existing system... that makes no sense to me and doesn't appeal to me. About the only such system that I'm even inclined to use is Apple Pay, and that's only because it is more secure than the alternative and actually means I get to carry one less thing around; so I tolerate it because most of the time it actually improves on the experience.

I really want to see more innovation in the payment space. There's no reason for the future of payments to be like the past of payments just, you know... without cards and wires. We need to think out of the box and change the game.

4 minutes ago, Max Entropy said:

Well without debating this in public, I am sure that once Ripple gets past the demo/prototype stage and focused on product delivery, then the real discussion about security, stability and robustness will become apparent. Or stated differently, I would not allow a 'stock' build of anyone's software into a secure financial environment. Maybe your customers will.

I am not usually wrong about these things...just early.

Yeah, this isn't the right thread for this topic, although the discussion is certainly interesting and I wouldn't mind having it. I predict an epic 300-page thread!

NikB... performance related question...

When you did your RippleD performance tuning did you use a 'stock' compiler or an optimizing compiler, such as Intel?

- Was the hardware optimized ?

Our packages are compiled with gcc with high optimizations enabled, but not requiring specific hardware features (e.g. AVX). I, personally, prefer both gcc and clang to Intel's icc. If someone wanted to squeeze some more performance, they could certainly compile it with the compiler of their choice (provided it supported C++14) and at any optimization level they choose.

Preemptive comment: yes, some entities might want to compile with full hardware-specific optimizations enabled. However I have to point out that the default install of rippled uses very little CPU - my validator & full-history node is churning along at 5% and occasionally spikes to 7%. And this is on a last-generation Intel i3.