Evolution - Masternode Quorums and thin clients

[greensheep]

I do not fully understand how the masternode quorums are chosen. The DashPay paper contains a reference to http://www.dashpay.io/whitepaper.pdf which does not exist. Has this been a doc with additional information about this technology? Still available somewhere?

Summarizing from the evolution paper:
- selection of quorum group is deterministic based on a proof-of-work hash
- the chosen MNs process the DAPI request in parallel
- each MN signs the response which is then forwarded to the original requester (end user)
- the result of all MNs must be the same for the request to succeed

For the following I assume a website that offers payment using DASH DAPI and a user that wants to do a payment on this website using the browser on his desktop.

Questions:
1. Which proof-of-work hash is used as seed to determine the quorum group for a DAPI request?
2. How does the end user (the browser) verify that the quorum was chosen correctly? As far as I see this would at least require a) access to Quorum Chain and b) a way to verify that this Quorum Chain is correct and current. I do not see how a stateless client as a browser can have this.
3. How can the end user be sure that website does not steal his password? Assuming the DAPI runs using JS in the browser doing all the encryption/decryption there, how can the user be sure this is the correct DAPI code running?
4. The DAPI doc says "End-User Opens https://dapi.dash.org which connects to a random masternode". Does this mean https://dapi.dash.org is a website run by Dash Foundation or is dapi.dash.org just a RR DNS to all masternodes? If the second, it cannot use https as this would require the MN to have a certificate. Should this be http?

 

[moocowmoo]

Hi Greensheep,

Sorry for the delay, been busy preparing for Miami.
Here's some answers to your questions:

I do not fully understand how the masternode quorums are chosen. The DashPay paper contains a reference to http://www.dashpay.io/whitepaper.pdf which does not exist. Has this been a doc with additional information about this technology? Still available somewhere?

That whitepaper can be found here: https://dashpay.atlassian.net/wiki/display/DOC/Whitepaper

Summarizing from the evolution paper:
- selection of quorum group is deterministic based on a proof-of-work hash
- the chosen MNs process the DAPI request in parallel
- each MN signs the response which is then forwarded to the original requester (end user)
- the result of all MNs must be the same for the request to succeed

For the following I assume a website that offers payment using DASH DAPI and a user that wants to do a payment on this website using the browser on his desktop.

Questions:
1. Which proof-of-work hash is used as seed to determine the quorum group for a DAPI request?

The last x11 hash, current blockchain tip, is the entropy for the deterministic selection of the current quorum set.

2. How does the end user (the browser) verify that the quorum was chosen correctly? As far as I see this would at least require a) access to Quorum Chain and b) a way to verify that this Quorum Chain is correct and current. I do not see how a stateless client as a browser can have this.

The quorum selection is deterministic, so can be calculated network-wide using the current (or historical) network metadata.
It is combined and hashed (sha-256) with the masternode funding transaction ids, and the ages of the funding transactions to arrive at a deterministic list. This algorithm incorporates intermediate sorting to arrive at a quorum consisting of masternodes spanning several age categories to prevent dominating a future quorum by setting up a large number of new masternodes.

I'm not sure we're going to need a quorum chain at all anymore, but I'll have to ask Evan about this again. I've been busy working on the soda machine project. Things change daily!

3. How can the end user be sure that website does not steal his password? Assuming the DAPI runs using JS in the browser doing all the encryption/decryption there, how can the user be sure this is the correct DAPI code running?

I know that the merchant website would initiate a payment request and that the DAPI funds transaction would come from a wallet implementation, but I'm not clear on how that will work yet.

I do know that credentials would never be shared with a merchant to invoke a DAPI command by proxy.
I also know that javascript is not a secure execution environment and will be treated as such.

4. The DAPI doc says "End-User Opens https://dapi.dash.org which connects to a random masternode". Does this mean https://dapi.dash.org is a website run by Dash Foundation or is dapi.dash.org just a RR DNS to all masternodes? If the second, it cannot use https as this would require the MN to have a certificate. Should this be http?

The plan is to be RR DNS to all masternodes.
And yes, SSL certificates for each masternode and a CA chain are planned.

 

[greensheep]

That whitepaper can be found here: https://dashpay.atlassian.net/wiki/display/DOC/Whitepaper

Thanks!

The quorum selection is deterministic, so can be calculated network-wide using the current (or historical) network metadata.
It is combined and hashed (sha-256) with the masternode funding transaction ids, and the ages of the funding transactions to arrive at a deterministic list. This algorithm incorporates intermediate sorting to arrive at a quorum consisting of masternodes spanning several age categories to prevent dominating a future quorum by setting up a large number of new masternodes.

But this is my point: A think client does not have the historical network metadata. So it somehow has to bootstrap it with information given by the masternode it connects to without having to trust the masternode.

The plan is to be RR DNS to all masternodes.
And yes, SSL certificates for each masternode and a CA chain are planned.

So, each masternode has a different SSL certificate? Who generates this certificates?

As these things still seem a lot in flux: What is the current state of development? How do we make sure that new ideas get peer reviewed?

 

[moocowmoo]

But this is my point: A think client does not have the historical network metadata. So it somehow has to bootstrap it with information given by the masternode it connects to without having to trust the masternode.

The current quorum algorithm uses the last 20 block hashes to select the quorum set.
When a new tip occurs, a new masternode is added to the quorum set and the oldest (by block height) is dropped from the set.
Thin clients (SPV) will need at least the last 10 block hashes in order to qualify the quorum selection for their DAPI result validation.

So, each masternode has a different SSL certificate? Who generates this certificates?

The certs will be generated (and tied to collateral vins) by the masternodes and signed by a network CA via quorum when provisioned.
The details of that are still being figured out.

As these things still seem a lot in flux: What is the current state of development? How do we make sure that new ideas get peer reviewed?

Yes, evolution is definitely in its early stages. This is a long-term project.
The papers on https://www.dash.org/evolution/ will be updated periodically.

Evolution is being developed on https://github.com/dashpay/dash/tree/v0.13.0.x

But, v12.1 is the current priority/next release target https://github.com/dashpay/dash/tree/v0.12.1.x