Welcome!

1) Full Featured: 2-Party Pay

Motivation

With money, you can not give up control until the completion of the exchange.
This is why all other cryptos fail as money. They give up control.

“But what about sending Dash to a multisig like 2-Party? Isn’t the user giving up control?”
My response is “No. You are adding control for another.”

This Adding Control is what creates the incentive for the other party and also proves to them that you are committed.
But YOU still have control. The 2-Party funds can’t go anywhere without your approval.

The distinction is, you may add control for others, but you never relinquish your control until you are satisfied with the exchange, and that voluntary relinquishing of control concludes the exchange.

It doesn’t matter how private your crypto is, if you Do Not maintain control throughout the exchange, you CAN NOT create the incentive structures necessary to become Money.

Features

This implementation exchanges Encrypted Public Keys, so 2-Party Pay is private like DashPay.  (Requires initial invite sequence)

1) End-to-End Encrypted (E2EE) messenger – the 2 parties involved can send/receive messages from each other prior to having a shared 2-Party, so they can negotiate conditions and terms.

2) Requests have 3 parts(Amount, Pay Incentive/Over-collateral, and Vesting)

1. Amount – what is transferred from buyer to seller on successful conclusion of exchange.
2. Pay Incentive/Over-collateral (0% to 100%) – this is what the buyer adds to the Request to ensure they, the buyer, will release the funds after the goods/service have been received. OR.. You could think of it as an over-collaterization. (I will include an example of both use-cases below.)
3. Vesting – this is where the seller matches a portion (0% to 100%) of whatever the buyer puts in the 2-Party, so the buyer knows that the seller is also committed to the exchange.  Vesting is based on combined Amount and Pay Incentive/Over-collateral total.

3) Pay Outs – (Variable or Partial)

1. Variable – payouts can send different amounts to different recipients.
2. Partial – payouts can be distributed in parts or as multiple payments from a single 2-Party.

Examples

Example #1:

You are browsing Facebook Marketplace or Craigslist, and there is someone across town selling a wood pellet smoker/grill for 10 Dash with free drop off.
You see on the post it says, “Dash Name – GrillGuy123”

You go to 2-Party Pay and search his Name and send an invite with a message: “Inquiry to Wood Pellet smoker for 10 Dash.”
If he accepts your invite then you can conduct an E2E encrypted conversation and arrange the 2-Party for paying.

In the private messaging, you say, “I will pay 10 Dash with a 20% Pay Incentive, if you do a 50% Vesting.”
GrillGuy123 responds, “Sure.” And sends a request for 12 Dash, and he attached an incomplete TX with 6 Dash for Vesting. Vesting is based on the Amount plus the Pay Incentive.

You accept the request and now have a 2-Party for 18 Dash with GrillGuy123.
(10 for Amount from you, 2 for Pay Incentive from you, 6 for Vesting from them)

So GrillGuy123 drops off the grill at your house, and you ensure it is what was advertised. You then go to the 2-Party and release the funds.

This will return the 2 Dash from the Pay Incentive back to you, and release the 16 Dash (Amount + Vesting) to GrillGuy123.


Example #2:

You decide to book a one month stay at a beach condo.
The condo owner policy says there is also a 1 month over-collateral required in case of damages in addition to the total amount and that they do 50% Vesting.

So you exchange invites and request the month of April.
The condo owner sends a Request of 40 Dash (20 for Amount and 20 for Over-Collateral for possible damages) and they have included a 20 Dash (50% Vesting) incomplete TX.

So you then accept and there is a 2-Party with 60 Dash total. (40 from you, 20 from them)

Upon arrival at the check-in desk, you get handed the keys and can go to your room and release the initial Payment and their Vesting. So release 40 Dash(20 is the Amount and 20 is their Vesting.)

There is still 20 Dash left in the 2-Party for Over-Collateral.

- ASIDE -
Another variant could be that you pay by the week. So release 25 total ( 5 is the Amount for the first week of 4 weeks and 20 is their vesting.) This would be a set of partial payments.
- END OF ASIDE -

So at the end of the month there is 20 Dash left in the 2-Party. You have caused no damages but as you pull the suitcase off the bed, you knock the lamp off the night stand and break it.

You inform the check-out desk clerk as you leave, and they say thank you and that it will be assessed in the final checkout billing within 24 hours.

So that afternoon, you see a payout offer, from the 20 Dash left in the 2-Party, for 19 Dash returned and 1 Dash retained for damages. And you hit accept and this returns the 19 Dash to you and 1 Dash to your host for the lamp.


Development Hurdles

Hurdle #1:
To implement the Encrypted Public Key exchange and maintain new public keys for each 2-Party, the issue that arises is the same issue of trying to implement the DashPay Data Contract with the SDK.

There are currently only SyncWorkers and BIP44 Workers, but you need DIP15 Workers, because it is a different Hierarchical Deterministic (HD) path to track in the wallet.
DIP15 - (e.g. m(userA)/9'/5'/15'/0'/(userA's unique id)/(userB's unique id)/index)

2-Party Pay could use these same DIP15 Workers, in order for it to work. 2-Party Pay would simply use a different HD Path.
Being able to reuse the Wallet Workers would be very advantageous for development.

Hurdle #2:

Also the Vesting would also require its own reuse of something similar to BIP44 workers, just implemented using a separate but identical HD path structure.

With Vesting, I envision something similar to CoinJoined funds in the Dash Core Wallet. So instead of coinjoined and non-coinjoined funds, you have “spendable” funds and “pledged” funds.

The “Pledged” funds are what are used in Vesting. These Vesting amounts are “sent” in requests as incomplete TXs and must not be accidentally spent.

By using a separate HD Path from BIP44, the wallet can track separately the pledged funds. Additionally, if after a period of time the other party you are negotiating with, does not respond nor accept the offer, you can simply send the amount from the pledged funds back to the spendable funds. This will void the request and make the funds spendable again.

**To sum up the hurdles, there need to be flexible generalized Workers for dealing with HD paths and expanding wallet functionality.**

With these features, 2-Party Pay could even be used on Web2 by anyone giving their Dash Name!


2) Detached Identities

Motivation

Detached Identities – a new level of anonymity that can be used by any P2P Data Contract and even improves upon a Data Contract like DashPay.

The difference between Detached Identities and regular Identity usage is not only can your communications be private, but now no one will know who you connect with, and no one will know who connects to you. (Except the person you are connecting with, they will know you by your Dash Name.)

You have complete anonymity from everyone except the people you are connecting with.


How Detached Identities Work

A wallet (mnemonic) can have multiple identities, but any two identities coming from the same wallet (controlled by the same person). This is Not known to the network.

Easiest to explain with examples.

So this example illustrates the old way (without detached identities): With DashPay, the identity with a name creates a document for the DashPay Invite that contains an encrypted Public Key for whomever is the another name/identity.

New Way: With Detached Identities, a wallet will have multiple identities, one identity will have the DPNS name document, but no documents will be created from that Identity. The other identities called “detached identities” will send documents to others. ("send" is a bad characterization, create documents with indexes that are queriable by the intended recipient.)

For a data contract like DashPay using a detached Identity: These documents will contain encrypted Public Keys but not only that. (This is where detached Identities become powerful.)

The Detached Identities will "send" encrypted signatures from the Identity with the Name, this will prove to the other person that the person with this name is "sending" them a document, but only that other person will know who the document is from. Because Only the Recipient can Unencrypt the Signature.

And if the recipient sends an invite back in the same way. No one but the two involved will know that they are communicating and working together.
Now all documents and Data Contracts interaction will be completely anonymous(no one knows who sent it) and private(no one else can read it) on the Dash Platform network.

But people can still connect directly to each other, but now privately and anonymously.

And if you are worried that if someone knows that a detached identity is associated with you(maybe someone whom you are communicating with has had their wallet’s mnemonic compromised), just like a wallet can have multiple identities so too can it have multiple detached identities. Your level of privacy and anonymity are solely dependent  upon how may different detached identities you purchase.

For example, if you connect to 5 people and use one Detached Identity. The 5 people you connect with through that single Detached Identity would know about the 4 others whom you are connecting with, but the communication is still private for each, just not anonymous.

But if you connect to 5 people and use 5 different Detached Identities with one for each person. Then no one you connect with would know about anyone else, you are connecting with.

Each Detached Identity is like its own private encrypted sandbox of anonymity for you to connect to others with.


Development Hurdles

There are 2 hurdles.
#1 : Creating a Detached Identity in a secure way.
#2 : Modifying a Data Contract to function through Detached Identities.

I will discuss Hurdle #1 here, because Hurdle #2 is something that is handled by the developer implementing it by understanding which signatures that need to be encrypted and is described above.

Hurdle #1

The main point of weakness in Detached Identities is in the funding of the identity, whether that be the creation or topup. (Never send a credit transfer to a Detached Identity.)

So the funding of a Detached Identity must always come from coinjoined funds. This is not something that is too difficult, but it is required.

Let me give a simple implementation, but better UX can be constructed using the same principles.

The way I envision this working is very simply:

1) Either a wallet has both coinjoin and detached identity capabilities.
2) Or a user puts their wallet mnemonic(12-words) into 2 wallets, one with coinjoin and another with detached identity capabilities

When you create a Detached Identity, the wallet will give you an address to send coinjoined funds to, and lots of warnings: “Only send CoinJoined Funds to Detached Identity Funding Address!”

Like Pledged Funds from 2-Party, there will be a separate HD Path for Detached Identities Funding Keys for addresses, I envision this will be different but identical structure to DIP 13 Identity Funding keys (e.g. m/9'/5'/5'/1'/0).

So when you send funds to the Detached Identity Funding Address, you can create a new Detached Identity. The Identity Creation or TopUp will only pull funds from UTXOs that include the address to that specific Detached Identity Funding Address.

The BIP44 Workers will never know about the funds at these addresses, so the wallet cannot spend from them.
And the Detached Identities will only pull from these specific addresses, so funding will never give away the owner of the Detached Identity.

(This all may be what DIP9 Feature 4 is implementing, I am saying it explicitly here.)

**There will need to be a UTXO or Address specification parameter in the Identity Creation/TopUp function for this to work.**


3) Pay Groups

What are Pay Groups?

A Pay Group is a Data Contract that allows a number of Dash users to form a multisig wallet together. And each member has equal share, but the multisig can be m-of-n so its flexible.

Pay Groups are known by the members of the Pay Group. (e.g. Adam1, Bill2, Charles3, David4 are the members so it’s the “Adam1, Bill2, Charles3 and David4 - Pay Group”)

Pay Groups can receive money together, and they spend from their shared funds, and have an encrypted group chat.

Pay Groups can be used in a private or public way. I will be focusing on public usage for now, such as, creating a DAO proposal to receive to a Pay Group address.

Purpose/Motivation

What I see moving forward are developers or development groups creating their own integrated Name-Wallet and Approach #2 Frontends for Dash Entrepreneurs to use.

A company or group of people could take what I have done (Name-Wallet/Approach #2) and expand the inventory capability to hundreds of items and also integrate maybe through smart contracts the calculation for weight of items being purchased, so the shipping cost can be accurate. They could get 100s of Dash Entrepreneurs that use their frontends.

Or I hope that someone or group makes a (Name-Wallet/Approach #2) that utilizes Quick Pay https://www.dashcentral.org/p/DashMoney-New-Pay-Contracts-Q4-2024 (explained in earlier proposal) and the Name-Wallet is implemented as an Android or iOS app. So like a small cafe could take orders in their Approach #2 and then receive payments through Quick Pay for in-person purchases.

The possibilities and the design choices are too numerous. I will not be building all the different possibilities, I couldn’t even get close to doing it anyway.

Maybe these new Dash Companies get funding through Dash Platform Token Market by launching a token OR the DIF OR direct funding from the DAO using a Pay Group.

- Why would they get direct funding from DAO? -
Perhaps someone is able to create libraries for the Proxy Accounts and other Data Contracts which multiple Dash Companies will use when creating their custom Name-Wallet/Approach #2.

There could be many different layers to the development, and if development is not funded from the DAO, then it could become closed source. There is much to consider.

How it Works/Features

Any member of the Pay Group can start it. The one that starts the Pay Group, sends other members an invite document, an encrypted xPubKey, and a encrypted public/private key pair for private communication.

Each member of the Pay Group will find the invite when they go to their Pay Group Dapp.
When the other members accept the invite, they will create their own invite with an encrypted public key for each of the other members, and record the other members’ Public Keys in their own document.

Once all the members have joined. They can participate in a group chat and form multisig pay scripts to receive payments.

The encrypted communication would also serve to coordinate the signatures to process the payment of the Pay Group’s funds.

When forming a public payment address or script hash, each member of the Pay Group will list the redeem script hashes(for addresses), and I envision each member of the Pay Group will just have a running list of script hashes with the top hash of the list being the most recently created one. (This is dev talk stuff)

Every Pay Group member should have the same list of script hashes, but the members won’t all update to a new one at the same time, so the most recent script hash that all the members have published to their list should be used and this should be verified by checking all the members.

Development Hurdles

If you wanted to enter into a 2-Party Pay with a Pay Group, there would need to be a new pay script (opcode implementation) like Pay-to-Multi-Script-Hash OR Pay-to-Script-of-Scripts

This would be so that a 2-Party Pay could be formed whether the participants are another Pay Group or an individual.


----    ----    ----    ----    ----    ----    ----    ----
Each of the above ideas have great potential and 2-Party Pay is vital, but below is the reason I put this proposal out early.

The following ideas coalesced on 29 January 2025.
----    ----    ----    ----    ----    ----    ----    ----


** Admin Groups **

An Admin Group is a Pay Group “PLUS” an Admin Identity.

Difference between a Pay Group and an Admin Group?

The Admin Group has an Admin Identity, and it is this Admin Identity which bridges the Pay Group into all the Platform capabilities that any Dash user can utilize.

And this Admin Identity starts the Pay Group a little different.
Any member can create the Admin Group. They begin by creating a separate identity. This identity is what will become the Admin Identity.

The separate identity sends an invite to each member of the Admin Group like a Pay Group.
BUT this is the difference, this separate identity also sends encrypted, the private keys of the separate identity. Now each member has control of the Identity.

I call the identity shared with the group, the Admin Identity.

- A quick back and forth to explain -

“So wait.. If an Admin Group has an identity that its members share, then can the Admin Group have a DASH NAME like the Admin Identity has a DPNS document?!”  - YES

“Then could an Admin Identity/Group run an Approach #2 Merchant Frontend?” - YES

“If an Admin Group operated a Merchant Frontend, then could I enter into a 2-Party with an Admin Group like a B2C?” - YES

“Could an Admin Group enter into a 2-Party with another Admin Group like a B2B?” - YES


Let me give a bigger example combined with even more new ideas..

- ASIDE -
Everything described as ‘local processing’ could just be a smart contract, but I want to show another way that has its own merits.
- END OF ASIDE -

-START OF EXAMPLE-
A customer logs into their Dash Wallet to purchase something they saw online from a Dash Merchant. (This Dash Merchant is a Admin Group running their own custom Merchant Frontend.)

Lets say this merchant deals with boats or side-by-side ATVs. (As this is a much higher value exchange, it will function differently than any Approach #2 Frontend I have built.)

The customer first creates a detached identity. (This gives the customer privacy and anonymity.)

The customer goes to the merchant’s website to get the merchant’s Dash name to place an order and sees there is a membership requirement.

The customer gets the Merchant’s Admin Group – Dash Name: “Public-Merchant123” for example.

The customer then sends a “Membership Request” via a "Quick Pay-like" dapp. (Quick Pay is where you transfer an NFT document to a merchant, who then creates an NFT for purchase.)

So, the customer sends a request NFT  to the Admin Group: “Public-Merchant123”. And the Admin Group generates an membership NFT for the customer to purchase.

Then the customer purchases the membership.(This is just purchasing an NFT with Platform credits, the membership cost is to cover the expenses of the Admin Group’s Platform usage for the customer’s orders, lets say the customer requested 2 orders in their membership request, so costs could vary for memberships)

Because the Admin Group could be dealing with 100s or 1000s of customers. They will have be able to filter the spam, and the Membership NFT is the mechanism to deal with the signal to noise.

- ASIDE -
What is also interesting is the Admin Group would not have to process each membership manually, nor would they have to pay to use smart contracts. They could just use ‘local processing.’

This is just ‘in-wallet computing’, because you already have the verified data.
‘Local processing’ can be a very simple in-wallet function that once the wallet receives a new verified ‘membership request’, the wallet automatically creates a ‘Membership NFT’ for purchase.

Any member of the Admin Group can facilitate these “local processing - administrative duties.” (This is where "Admin" Identity got its name)

And upon logging into the wallet, a report pops up of the functions performed:

Membership Status for Admin Group - “Public-Merchant123”:
10 customers have requested membership.
10 membership NFTS for their purchase have been created. (COMPLETE)
 
Since previous login, 4 memberships NFTs have be successfully purchased.

2 membership NFT requests have expired after one month,
   -Request and Membership NFTs have been deleted and credits recovered. (COMPLETE)

(i.e. This is so that if let’s say a month’s time goes by, but the user does not purchase the membership, the Admin Group can just delete both documents(request and membership NFTs) and recoup the expense of attempting to establish the membership.)

Order Status for Admin Group - “Public-Merchant123”:
3 new customer messages awaiting response.

Pending Your Approval:
4 orders have been completed and 2-Party funds have been released by customer.
Please click “Approve” to apply your signature to transfer funds from these orders (Orders displayed in a list) to the Admin Group’s multisig.

• So you may wonder why do this in “local processing” instead of smart contracts. There are 2 benefits to “local processing”: it’s private and no gas cost. So unless you want the processing to be public for some reason then “local processing” would be the better choice.
• And all you have to do is one of the members of the Admin Group just has to open their wallet. The “local processing” can handle finding and establishing the status of the orders with a few queries based on the structure of the data contracts.

- END OF ASIDE -

Once the customer user has a membership NFT.  Because the purchase is of higher value, perhaps the purchasing/ordering is a bit more involved. With your membership NFT, maybe there is an encrypted token.

Which you use to log in to merchant’s custom frontend, where you discuss what you want with a customer service representative(AI or human). Such as what you looking for, explains available options, discuss warranties or adding insurance, and shipping or pick-up options.

And the actual purchase and exchange still occurs through Dash, when the customer accepts the order/request and conducts a 2-Party Pay with the merchant Admin Group.

So this form of merchant/customer interaction could be used for many different things: boats, ATVs,  vehicles, second passports or online doctor visits.
-END OF EXAMPLE-

- ASIDE -
About Security : Lets say an Admin Group  (3-of-4 mulitsig) has one of the 4 members get their wallet compromised, so a wallet and admin identity keys!

So what could a hacker/malicious actor do to the funds? Worse is drain the credit balance of the Admin Identity. (this will be a much smaller balance as it controls only the credits for Admin Group Platform state transitions.)
But the funds in all the 2-Parties would be completely safe.

Any other actual member of the Admin Group can disable the Admin Identity to prevent further harm.

Then the 3 remaining actual members of the Admin Group can safely finish any 2-Party Pays with customers.
-END OF ASIDE -

An Admin Group will just be integrated like it’s one of multiple wallets in the wallet application.

So similar to how you can have multiple detached identities for your personal usage, you can also be a part of multiple Admin Groups.

This is part of the power of Platform as each identity can find the documents and pay contracts that it is a part of, simply with a few queries.

The membership NFT and local processing were just additional ideas that I thought really took it to the next level. The membership NFT is to prevent spam and there are so many situations that the membership could be used for. And the local processing, because your wallet already has the structured data, the wallet already knows the next step to perform, it is simple and powerful.

Because I don’t think that Dash as Money will be limited to a few simple niche purchasing options, but will be used by a multitude of businesses both large and small, even the smallest, the individual!

All the ideas mentioned above, none of them, are even remotely possible on any other network.

And there are no new technological breakthroughs to make these ideas come to fruition.

It’s just Data Contracts, Identities, Pay-to-Script, and HD paths. I have confidence, all of this can work.

DashMoney Development Roadmap

April – Work on Pay Groups. (1 month)
May – Work on Admin Identity for Admin Groups (1 month)
June – TBD (based on SDK status and any unforeseen difficulties)

If the new DCG SDK is not yet ready for implementing the proofs and proxy accounts with identities, which seems to be the case, then I will shift this all forward a month.

And do the work for proofs and proxy accounts, I planned for March 2025 to whenever the SDK is ready enough to start implementing with.


- In Closing -


No stable coins(FIAT) or 3rd party intermediaries for conversion, and no relying on middleman to conduct transactions.  

Dash is the medium of exchange.

This will work because economics is powered by the simple and unyielding fact that in a voluntary exchange, Both Parties Benefit.

Money is Medium of Exchange and No one gets to expand upon Money’s Scarcity.

There are no advances or improvements on money.

All “improvements” result in failure and always will, because money is the most powerful computation force in the universe. And any “improvement” only destroys the computation mechanism that emerges from a true P2P sound money.

P2P sound money results in the network effect of millions or billions of the most powerful and efficient quantum computers in the universe. Only man in his ignorance could think he could do better. Improvements upon money are nothing more than the folly of man’s pride.


And with Dash Evolution, we are close now.

Evolution is not an end, its a process.  And where does it go? There has always been only one destination, Money.

If Money is the goal of Dash Evolution, how do we get people use it? How do we get people to earn it?
The chicken and the egg is solved By starting at the beginning of the evolution process.

We have to go WAY back. Back to single cell organisms that work together and are beneficial to one another and cooperate in a voluntary way.
So we have to operate in a P2P way. One person to another person, and that is only where it starts.

For this is certain,

“Money is a simple idea. It can be known and understood by even the most humble of minds.”

And maybe that is why no one in crypto has been able to get it right.

..for hiding these things from the learned and the clever and revealing them to little children.
Yes, Father, for that is what it pleased You to do.




--
-

-