A decentralized trustless instant payment protocolI would like to develop a trustless instant payment protocol (a sort of decentralized banking system) that would allow instant transfer of funds between users. Deposits and withdrawals (to and from the network) would be no more instant than the usual transactions, but would allow transaction to be processed off chain. The latest agreed balance would be enforceable by either party at any time and transactions would be atomic.
I don't have the necessary competency to manage such a project, i.e. manage the project, its development, the maintenance, testing and so on. I can certainly help in a number of ways, but someone (or some people) who have managed such projects before is needed to proficiently bring that project to life... if it happens to be achievable.
My first attempt at describing the protocol follows. Please tell me what you think, ask if anything isn't clear, and let me know if you think you can help.
Summary:In a first step, one-to-one relationship is established, which I will call a cell. The parties create a multisig address, agree to the amounts to be deposited, sign a timelocked refund, then send their deposit as agreed. Until that timelock, they can prepare and sign balance-updates without using the blockchain. At any time, either party can force the current balance to be enforced at the timelock, or else both may just agree to pay out the balances earlier.
In a second step cells can publish their existence, p2p, so that a path can be created between members of different cells. Say Alice and Bob are cell 1 and Bob and Charlie are cell 2, then Alice could transfer funds to Charlie through Bob.
In a third step, applications that requires a balance to be instantly updated can be built in top if it and can extend to instant cross-blockchain trading, gambling, auctions, etc.
Network:So to balance the potential of transfer, it might me preferable to share a cell with a bunch or other users, rather than with few.
For example, say five people want to deposit 1000mBTC each. They create one cell for every one-to-one possible combination, which is 10 cells. Each member will then deposit 250mBTC in each cell, which will put a total of 500mBTC in each cell.
Then when Alice wants to send 200mBTC to Bob, so she request every member to transfer 50mBTC to Bob, and she herself does so. Assuming everyone collaborated, then we have the new following balances:
Alice:200mBTC <=> Everyone else:300mBTC
Bob:300mBTC <=> Everyone else:200mBTC
Alice has 4x 200mBTC = 800mBTC,
Bob has 4x 300mBTC = 1200mBTC, and
Everyone else has 2x 250mBTC + 200mBTC + 300mBTC = 1000mBTC
Instead of dropping her balance from 250/250 to 50/450 with bob, she drops it to she (200/300).
Such collaboration between users would allow for fair bankroll to everyone. If they further collaborate so that cell 1 resets on Monday, cell 2 on Tuesday and so on, then deposits and withdrawals could flow nicely while being very inexpensive on the blockchain.
Some may require fee, but such fee would be subject to offer and demand. And the users themselves would benefit from the fees anyway. Perhaps mini-banks could raise, but they would need liquidity and would be competing with their customers... which is a weird concept.
Key features:1. Totally trustless, any balance remaining is guaranteed to be sent to the legitimate holder, at least eventually;
2. No third party; at most chains of direct transfers; (the chain may breaks, but no one may lose but the one who breaks the chain)
3. Atomic transactions;
4. Allow cross-blockchain transactions.
Downsides:1. It can requires considerable liquidity. Each party must make a deposit prior to any transfer; a deposit to a bank requires the bank to deposit with the customer so that the customer may receive any such instant transfer through it.
2. If one party stops cooperating, the other party needs to wait until a timelock to get its balance back.
3. The cells must reset at least at every timelock, i.e. while funds may be locked in the cell until the timelock, they must absolutely be unlocked before the said timelock for both parties to remain safe. The longer the cell can be used, the longer the funds may remain locked.
4. Cells must be live and online to operate... though I guess that is to be expected in a decentralised system.
The technical stuff:Initialization of a cell: (updated)
1. They create two multiSig addresses, multiSig1 and multiSig2;
2. They choose two password each (pwd1 and pwd2)
3. They prepare a transaction (txA1) that sends both deposits to multiSig2, which sigX+pwd1Y+pwd2Y would unlock; (updated)
4. They prepare a timelocked transaction (txB1) that return the original balance from multisig2.
5. Both sign txB1;
6. They do NOT sing txA1, they will use sigX+pwd1X if they need it; (updated)
7. Both send their initial deposits, to multiSig1.
Transations: (list of ransaction, most of which will only exist outside the blockchain) (updated)
| Transactions | inputs | outputs |
| txInit | original deposits | multiSig1, pwd1 |
| txA1 | multiSig1, pwd1; | multiSig2, pwd1+pwd2 |
| txB1 | multiSig2, signatures; | return (original) balances to withdrawal addresses |
| txC1 | multiSig2, pwd1+pwd2; | unlock all deposits |
| txA2 | multiSig1, pwd1; | multiSig3, pwd1+pwd3 |
| txB2 | multiSig3, signatures; | return new balances to withdrawal addresses |
| txC2 | multiSig2, pwd1+pwd3; | unlock all deposits |
| ... | | |
| txE | multiSig1, signatures | return final balances to withdrawal addresses |
(updated)
Outputs to multiSig1 and up are redeemable with (sigA and sigB) and (pwd1A or pwd1B)
Outputs to multiSig2 and up are redeemable with (sigA and sigB) or (sigA and pwd1A+pwd2B) or (sigB and pwd1B+pwd2A)
"multiSigN, pwdX" indicates that one or two passwords are used for that transaction;
"multiSigN, signatures" indicates that both parties are signing the transaction;
All txB have the same timelock.
Transfer of funds within a cell: (updated)
1. They agree to a new balance;
2. They create a new multiSig address, multiSig3;
3. They choose another password (pwd3)
4. They prepare a transaction (txA2) that sends both deposits to multiSig3, which sigX+pwd1Y+pwd3Y would unlock;
5. They prepare a timelocked transaction (txB2) that returns the new balance from multiSig3, using both signatures.
6. Both sign txB2,
(transaction is still incomplete, non-enforceable)
7. They do NOT sing txA1, they will use sigX+pwd1X if they need it;
(transaction is in intermediary state. Both txA1 or txA2 are valid and legal, either party may broadcast either)
8. Each party reveals its pwd2. They consider the new balance to be official only after they verified that the password hash matches the one provided for txA1 output.
(the transaction is complete, new balance is official)
9a. Either party can send txA2 using their pwd1 and pwd2 (or pwdn) to then claim the latest balance at timelock with txB2 (or txBn).
9b. If either party used txA1 (or a previous txAn), he would forfeit its balance because the other party has the password (from #8) and its pwd1, thus can create txC1 and so claim all deposits before the timelock of txB1(or txBn).
10. The process is repeated for any subsequent balance update, with new txAn, txBn and pwdn.
11. They prepare and sign txE with the final balance; to be broadcasted immediately.
At any time, both parties can decide to close the cell and sign an immediate withdrawal transaction txE; that should be long enough before the timelock to avoid attempts of successfully broadcasting an outdated (txA+txB) when the timelock arrives.
Transferring funds between cells:Alice and Bob are in cell 1,
Bob and Charlie are in cell 2, and
Alice wants to transfer funds to Charlie, through Bob.
1. Charlie chooses a password to accept/redeem the transfer and send the hash of that password to Alice.
2. Alice and Bob cerate a new set of transactions where balances after the transfer are returned, and where the transferred amount is sent to an output that is redeemable by either (sigAlice+sigBob) or (sigBob+pwd)
3. Alice and Bob sign a timelocked refund of the output of the transfer, sending the fund back to Alice in case the transfer would not complete.
4. Bob and Charlie make a new-balance agreement, (txAn+txBn)
5. They make a txB which sends the respective as of after the transfer, and the transferred amount to an output redeemable only by (sigCharlie+pwd)
6. Bob and Charlie sign it,
7. Charlie discloses its pwd to Bob;
8. Bob and Charlie have a new-balance agreement that merges the transfer to the regular balance.
If Bob stopped collaborating, Charlie would be able to get both its balance and the transfer;
If Charlie stopped collaborating, Bob can publish txA[n-1] and txB[n-1] (because pwd[n-1] has still not been disclosed, thus txC[n-1] cannot be made) to unlock Alice's funds, then wait for the timelock to claim back the latest balance from txB[n-1]
If transfer is not successful with Charlie, then Bob and Alice just sign new balance where the transfer is cancelled.
If Charlie accept the transfer, then Bob can then present the password to Alice, proving that Bob accepted the transfer, then Alice and Bob may have a new-balance agreement, removing the transferred amount from Alice's balance, or simply apply it when a new transactions balance-update initiated.
Notes:That only the txE transactions, the deposit and the withdrawals need to appear in the blok chain if everything is done neatly. If not, one more transaction is required whereas (txAn+txBn) are used if the other party stops collaborating; or (txAx+txCx) is used if one party illegally broadcast an outdated txA.
If any party is no longer available to sign a final transaction txE, long enough before the timelock, the other party should broadcast txAn so to avoid the yet non-responding party broadcasting an outdated txA shortly before (or after) the timelock so that he could successfully claim an old balance.
