[Feature] Decentralized trustless trading using atomic swaps

[jeroz1]

I'd like to request for nodes to allow sending partial txes to each other.

This allows a decentralized store for atomic swap buy and sell orders. Any node that is enabled to receive and send these txes could see them and allow users to pick them up and complete them if they want to take this buy or sell order.

Once the tx is complete, miners can grab them and write them into blocks on the chain.

Discuss! :D

[jeroz1]

Some brainstorm thoughts from Blondfrogs:

1. First, add in a service flag for the nodes. Pick a bit that hasn't been assigned to anything. When nodes connect to each other they send their service flags to each other. This is how nodes will know who to broadcast the partial txes to.
2. Have a -partialtx=1 or something assigned and if this is assigned, the node will have the flag that it accepts partial transactions
3. Create a new network message = parttx(?)
4. This new message contains transactions (partial txes)
5. When you connect to a node, if that node service flag has partial txes active, send that node all partial txes you have. Mark those txes as sent to that node, so you don't keep sending them over and over to the same nodes
6. When a new partial tx comes in, relay it to all nodes you are connected to that have the service flag set.
7. On each node, you should check the transaction to see if there is an input that belongs to your wallet. If there is, you should store it. Showing a notification or flag to the user, so they can sign it.
8. You could create a GUI for listing these transactions, and signing them.
9. Also have the ability to sign them via rpc -> signpartialtx txhash
10. You need the ability to broadcast partial txes. GUI and RPC probably.
11. You need to build some sort of antispam mechanism.
12. Partial txes need to be cleared once signed and/or a given timeout(?)

[ben-abraham]

Would be an awesome feature to have a running pool of signed partials built-in to the nodes, would enable direct client integration and easily support future rpc commands like getswaps or something similar. A signed partial can pass a validity test before being accepted, quick criteria would be

• One VIN/VOUT
• vin[0] is signed as SINGLE|ANYONECANPAY

Note: this effectively makes the VIN UTXO a unique identifier for an order as well since those are unique themselves.

For context a signed partial is about 192 Bytes (varies a little it seems), so 1MB of memory could store ~5.5k signed partials in an ideal case.

The biggest outstanding question to me, is how to handle the situation where a second order for the same UTXO comes into the pool, what behavior should be allowed and how bad is the surface area for manipulation if we have a mechanism for updating orders. (ie: miners could change their logic to ignore sale-order resubmissions at a higher listing price for example. the old signed partial is valid as long as the UTXO is, so they could just execute the old one instead of the newer more expensive one)

[ben-abraham]

7. On each node, you should check the transaction to see if there is an input that belongs to your wallet. If there is, you should store it. Showing a notification or flag to the user, so they can sign it.

The signed partial only has the single VIN from the creating party on it, so a user's wallet would have to check "do I have enough funds/assets to meet the require VOUT" to determine if they can sign it, at which point they add their side of inputs/outputs, and sign/complete the transaction. Which means they would see a LOT of orders, anything that have enough RVN to purchase.

I wonder if some kind of query + subscribe/notify system would be needed where a user could specifically look at an asset's buy/sell orders (remember quantities are fixed, so you might not always take bid price) and/or even subscribe to updates (which would allow for client-sided limit orders)

[hans-schmidt]

It is possible to custom-write an extension to the bitcoin p2p protocol for this purpose as BF describes. But a few years ago I remember there was a proof-of-concept done for bitcoin-cash to show that it was fairly straight-forward to apply Libp2p (which is what IPFS uses for p2p communication) to the bitcoin network for a variety of add-on applications. That provides a lot of capability out-of-the-box.

The project is still here: https://github.com/bonedaddy/overlaynetwork And Libp2p is here: https://docs.libp2p.io/