Pre-proposal: decentralized contract system on top of Dash

[stev-rodr]

A decentralized contract system is an application that makes it possible to everyone to create contracts between individuals and companies.

Imagine a situation where a landlord has tenants, but also pay contractors to execute work on his properties. The landlord would create a contract with each of his tenant. The contract would state the address of the apartment, and all the conditions. It would also state the conditions that could make the contract end and the amount of money that the tenant would need to pay, on a monthly basis. It would also contain a start and end date.

When signing such a contract, the tenant would need to pay the contract the agreed amount. Every month, the landlord would have access to the contract's money.

The landlord would also create contracts with his contractors. Upon creation, the landlord would need to set a price for the contract and upload Dash to the contract. When a contractor finishes a job, he would receive the Dash compensation automatically.

Globally, every contracts would be encrypted and stored on the decentralized network. In case of a dispute, the contract would get decrypted and the community would be able to vote who is right and/or wrong.

The decrypted contracts would also stay decrypted forever. Therefore, if someone gets a very high level of "bad behaviour" while interacting with a contract, the community would know that this entity might provide bad quality output.

Of course, it would be possible to create a new "identity" in the network, but then, we would know that this person didn't execute any contract successfully, therefore the risk of dealing with this entity would be higher.

This system would be used by everyone doing business with others. It would add transparency in business and provide an automatic way of paying people. It would also serve as an automatic bookkeeping system.

To make the system easier to use, I would also build a web interface and a mobile application.

I think that this system would make Dash easier to use by the mainstream community and therefore increase adoption.

EDIT: If you have any comment or concerns regarding this proposition, please elaborate in the comments.

This is also a draft of what I'd like to build. After exchanging comments with the community, I'll write the real proposition, with budgets and milestones.

 

[TroyDASH]

Anything we do with contracts cannot use the top global masternode layer to resolve all disputes.

I was thinking initially you were talking about building an autonomous smart contract system, like a Counterparty for Dash, but I don't think that's what you mean?

 

[stev-rodr]

Anything we do with contracts cannot use the top global masternode layer to resolve all disputes.

I was thinking initially you were talking about building an autonomous smart contract system, like a Counterparty for Dash, but I don't think that's what you mean?

Yes, that's actually what I meant. Basically, I would build a separate decentralized system to let people create their contracts and upload information/media to their contracts. The resolution system would reside in this new decentralized system/database. However, the only possible currency people would be able to pay a contract with would be Dash.

Did I answer your question properly?

EDIT: Added: The resolution system would reside in this new decentralized system/database.

 

[methusaleh]

Hi this is certainly interesting but when you say "new decentralized system/database" what's the incentive for parties hosting this new decentralised system if this is planned as distinct from the MN network? Maybe this will be covered in the white paper you mentioned on the slack?

 

[stev-rodr]

Hi this is certainly interesting but when you say "new decentralized system/database" what's the incentive for parties hosting this new decentralised system if this is planned as distinct from the MN network? Maybe this will be covered in the white paper you mentioned on the slack?

Yes, I was planning on adding this information in the white paper but I can answer it now since you asked the question .

Basically, there will be small fees associated to fund contracts. So, when a contract gets funded, a percentage of the fees would go to pay the node owners. Fees would be paid in Dash, obviously.

EDIT: Please keep in mind that some contracts won't have funds associated to them. These contracts won't have fees associated to them. However, the node owners won't know if there is rewards associated with a contract before processing them.

So, when funds will be associated with a contract, the node owners will earn a reward. Otherwise, they will process the transaction for free.

Please note that it will be possible to calculate how much rewards (in dash) the node owners earns, on average, per processed contracts.

Did I answer your question properly?

 

[GrandMasterDash]

I'll leave others to discuss the details, but I will say, whatever smart contracts system is introduced into dash, it must have formal verification at it's core. If you can convince me of that then we're halfway there.

 

[stev-rodr]

I'll leave others to discuss the details, but I will say, whatever smart contracts system is introduced into dash, it must have formal verification at it's core. If you can convince me of that then we're halfway there.

I agree. Verification will be done using public/private encryption keys and data. Basically, everyone interacting with contracts will have a private key. Every time a new contract is created/updated, the message will be encrypted using the private key. The encrypted message will also contain a signature and a public key.

Therefore, when a node receives a new contract or an updated one, he will be able to "ask" the user: is this contract addition/modification from you? The user will then validate the message with its private key. If it works, he'll answer "yes, it came from me and its valid". Otherwise, it'll deny it.

I'm trying to be very high-level in this explanation right now. I don't want to be too technical. The goal of this pre-proposal is to validate ideas. A more technical document will be created with the real proposal. In this technical whitepaper, Ill explain how handshakes between users and nodes will work, to validate contract transactions.

Did I answer your question properly?

 

[GrandMasterDash]

I agree. Verification will be done using public/private encryption keys and data. Basically, everyone interacting with contracts will have a private key. Every time a new contract is created/updated, the message will be encrypted using the private key. The encrypted message will also contain a signature and a public key.

Therefore, when a node receives a new contract or an updated one, he will be able to "ask" the user: is this contract addition/modification from you? The user will then validate the message with its private key. If it works, he'll answer "yes, it came from me and its valid". Otherwise, it'll deny it.

I'm trying to be very high-level in this explanation right now. I don't want to be too technical. The goal of this pre-proposal is to validate ideas. A more technical document will be created with the real proposal. In this technical whitepaper, Ill explain how handshakes between users and nodes will work, to validate contract transactions.

Did I answer your question properly?

That's not formal verification. It's mathematical models to prove correctness. It's a very specific, highly engineered and very important field of work. In all likelihood, The DAO incident could of been avoided if they'd used formation verification / methods. You'd need to know things like Z notation / Ocaml etc.

 

[stev-rodr]

That's not formal verification. It's mathematical models to prove correctness. It's a very specific, highly engineered and very important field of work. In all likelihood, The DAO incident could of been avoided if they'd used formation verification / methods. You'd need to know things like Z notation / Ocaml etc.

Ill have a look at this, thanks! If you can point me to links that would also be very greatly appreciated. Otherwise Ill just use google. Thanks!

 

[GrandMasterDash]

https://en.wikipedia.org/wiki/Z_notation

 

[stev-rodr]

https://en.wikipedia.org/wiki/Z_notation

I believe you are right. After writing the white paper, Ill explain/write the software's behaviour in Z-notation to get peer approved. Ill add this in the milestones for the proposal. Thanks for the suggestion!

A few links:

https://staff.washington.edu/jon/z-book/what-is-z.html

https://staff.washington.edu/jon/z/z-examples.html

http://teaching.csse.uwa.edu.au/units/CITS2220/readings/zrm.pdf

https://alimanfoo.wordpress.com/2007/01/29/writing-formal-specifications-using-z-notation/

https://staff.washington.edu/jon/z/glossary.txt

https://staff.washington.edu/jon/z/toolkit.txt

https://www.latex-project.org/

EDIT: grammar

 

[methusaleh]

Yes, I was planning on adding this information in the white paper but I can answer it now since you asked the question .

Basically, there will be small fees associated to fund contracts. So, when a contract gets funded, a percentage of the fees would go to pay the node owners. Fees would be paid in Dash, obviously.

EDIT: Please keep in mind that some contracts won't have funds associated to them. These contracts won't have fees associated to them. However, the node owners won't know if there is rewards associated with a contract before processing them.

So, when funds will be associated with a contract, the node owners will earn a reward. Otherwise, they will process the transaction for free.

Please note that it will be possible to calculate how much rewards (in dash) the node owners earns, on average, per processed contracts.

Did I answer your question properly?

Thanks yes it does answer my question. I really like the idea and I'm not currently seeing any insurmountable issues with the execution of it as yet. Erring towards a 'Yes' from me

 

[akhavr]

Every month, the landlord would have access to the contract's money.

How exactly?

Globally, every contracts would be encrypted and stored on the decentralized network. In case of a dispute, the contract would get decrypted and the community would be able to vote who is right and/or wrong.

What incentive "the community" would have to vote? Who will be that community? Existing MNO?

 

[Vedran Yoweri]

EDIT: Please keep in mind that some contracts won't have funds associated to them. These contracts won't have fees associated to them. However, the node owners won't know if there is rewards associated with a contract before processing them.

ddos?

 

[stev-rodr]

Thanks yes it does answer my question. I really like the idea and I'm not currently seeing any insurmountable issues with the execution of it as yet. Erring towards a 'Yes' from me

That sounds great. Thanks for your input!

 

[stev-rodr]

How exactly?

When creating a contract that receives money, the contract creator will be able to add a dash address, if the conditions are met and there is dash in it, the dash will be transfered to that address automatically. Therefore, the landlord will receive its dash.

What incentive "the community" would have to vote? Who will be that community? Existing MNO?

Ill go deeper in the white paper on this subject, but here's a quick explanation. When 2 entities do not agree on a contract, another contract will be automatically created and a percentage of the money of the first contract will be sent to it. Everyone in the "contracts" community will be invited to participate in this new contract.

People will have x days to vote on the matter. Everyone that voted will receive a share of the dash inside that new contract. To avoid quick "yes" or "no", people will have to explain why they vote the way they do and they will be able to debate with each others.

If the community voted for a party, that party will receive the remaining balance of its contract. If the community voted against both, the entity that funded the contract will receive its money back.

Like I said, Ill explain more in the white paper but it'll pretty much work that way.

Did I answer your questions properly?

 

[stev-rodr]

ddos?

Ill make sure that we have protections to prevent this. Ill have protections per ip address and per user/entity that interact with the network. If a given ip address/user executes too many commands on the network over x amount of seconds, his ip address/account will be added to the network's blacklist for x amount of seconds and its requests will be blocked automatically, without being processed.

If the ip address/user continues to ddoss, the amount of time this person gets blacklisted will increase.

 

[akhavr]

When creating a contract that receives money, the contract creator will be able to add a dash address, if the conditions are met and there is dash in it, the dash will be transfered to that address automatically. Therefore, the landlord will receive its dash.

So there would be some flexible logic involved? If yes, then there definitely is a need of a formally provable scripts, as you've been commented above.

Ill go deeper in the white paper on this subject, but here's a quick explanation. When 2 entities do not agree on a contract, another contract will be automatically created and a percentage of the money of the first contract will be sent to it. Everyone in the "contracts" community will be invited to participate in this new contract.

How you'll handle a sybil attacks? What will prevent me (either being a party in the contract or not) to create thousands of handles in the "contracts" community and up/or downvote the desired outcome? Requirements of posting of simple explanation won't suffice, since (a) there would be noone to formally check them and (b) AI now can generate as reallistically looking gibberish as you'd like.

Looking forward to a whitepaper.

 

[stev-rodr]

So there would be some flexible logic involved? If yes, then there definitely is a need of a formally provable scripts, as you've been commented above.

Yes, there will be some logic/parameters that the contract creator will be able to setup. Ill make sure to create a z-notation model to back it up like stated above.

How you'll handle a sybil attacks? What will prevent me (either being a party in the contract or not) to create thousands of handles in the "contracts" community and up/or downvote the desired outcome? Requirements of posting of simple explanation won't suffice, since (a) there would be noone to formally check them and (b) AI now can generate as reallistically looking gibberish as you'd like.

Looking forward to a whitepaper.

That's a very good question. The quick answer is that every vote won't have the same value. If a user, that voted for a lot of disputes in the past, and was right on the outcome at 99%, his opinion will be valued much more than someone that voted and was right at 2%. I'll also take in effect the amount of contracts the user voted on in the past, among other variables.

Also, please note that each user per unique ip address will be able to vote. Therefore, if a bot tries to create a ton of users and tries to vote using 1 ip address, only 1 vote will be calculated.

We'll also have a blacklist of ip addresses that will be voted by the community. Ip address ranges that belong to cloud servers, like amazon AWS, will be blacklisted, making it very hard to host a bot to attack the voting outcome.

Of course, attackers might have a bot net, but then each vote would probably have very little leverage because of their past votes.

Ill make sure to explain this very well in the white paper. Did I answer your question properly?

 

[akhavr]

I think IP address blacklisting/whitelisting won't work. And it's too much hastle to maintain them manually. A kind of PoW/PoS/ProofOfSomething scheme would be more viable.