SOIP 3824: Improvements to orderbook protocol

[vladiuz1]

This is not really a proposal but rather a ticket that hopefully will spawn other tickets that eventually will polish orderbook and create protocol that the swaps are not only atomic but also practical.

Right now every swap is preceding with an order in the orderbook. The orderbook is advertised in a pubsub channel in a decentralised way.

However at the moment there are major problems with SO atomic swaps

Problems

• Key length. Key length attack may still be possible on some of the pairs. This has to be fixed. https://github.com/swaponline/MultiCurrencyWallet/issues/3772

• All SO swaps are mono-directional. The cross-chain swaps always start with bitcoin deposit. Big problem if you want to determine the order of the swap depending on your market role: taker or maker.

• No incentive to start the swap. There is no incentive for the second deposit to be ever executed, which creates a possibility of fee attack, where one could accept orders indefinitely and exhausting market maker balances with fees paid for making first deposit.

• Possibility of withdrawal due to exchange rate. There is no fine for withdrawing from a swap in a case where exchange rate changes in favour of no execution leading to losses from the other party. This is a different problem from the previous, as a party may start the swap and then delay it for sometime eventually withdrawing if exchange rate doesn't bring enough profit.

• No incentive to finish the swap sooner. Once the first deposit is made there is no incentive on either side of the swap to complete the swap sooner. Actually right now there is rather a reverse incentive to wait enough time for the swap to complete to maximise the spread or withdraw if the rate is unfavourable.

[vladiuz1]

Considerations

When we solve the problems mentioned in the ticket we need to keep in mind who SO is for.

It's for people who want the convenience of a hot wallet without huge concern to security, yet fans of decentralisation and non-custodial wallets and crypto exchanges. Our users are not traders, and SO is not an exchange or a highly secure wallet. To end-users SO is a a crypto an equivalent of cash clip you keep in your pocket with the functionality of atomic swaps.

Since users of the cash clip are quite niche, in order to offer decentralised exchange we need to distinguish between market makers and market takers. These are completely different user segments with different goals and tools required.

• Market takers are regular users who use the swaps for convenient and decentralised exchange.
• Market makers are seeking opportunities to make profit.

We shall solve the problems mentioned in the ticket keeping these factors in mind.

Market makers shall have instruments to make money on arbitrage, we can safely assume market makers would be willing to put down a stake as guarantee to their fair trading.

Market takers are looking for convenience to make a swap as fast as possible. Since swaps are performed in 4 stages, we can assume they would be willing to trade decentralisation for usability within reason.

[vladiuz1]

Swap Protocol Solution Brief

Alice is a wallet user who wishes to swap her coins (e.g. sells BTC and buys ETH). Alice is a Market Taker, simply enters the amount of BTC she wants to buy. SO automatically picks the best offer from advertised orders by protocol, calculates exchange rate, and amount of ETH she is going to get.

Bob is a Market Maker running an arbitrage bot that seeks opportunities to turn profits while competing with other market makers for clients by offering more attractive rates.

Bob has signed an offer to sell a minimum of 1 ETH and maximum of 100 ETH at a rate of 50 ETH for 1 BTC.

Alice accepts an offer by signing a json object with offer meta data that includes the BTC amount she wants to sell (1) and wallet she wants to receive her ETH to:

POST /request
Body-Hash: 0xec577daf6f688addbbd920478d4d2ebb
Signature: [signature_for_hash]

{
    "offer-hash": "0x32d00f53460f222733bfaf343ef7693a",
    "spend-amount": 1,
    "spend-symbol": "BTC",
    "spend-address": "1rULxmvdtHACFXWWT1WcbqyynZTe1xHDF",
    "receive-amount": 50,
    "receive-address": "0x07910f3adca830aaaeaa1dbc43c836a40da876f3",
    "receive-symbol": "ETH",
    "stamp": 1608790200
}

The request is signed by private key of bitcoin spend address (1rULxmvdtHACFXWWT1WcbqyynZTe1xHDF).

Bob accepts request by sending this object signed by his Ethereum:

POST /accept
Body-Hash: 0x63fd198416e17347696a3ddb6a806e25
Signature: [signature_for_hash]

{
    "request-hash": "0xec577daf6f688addbbd920478d4d2ebb",
    "spend-amount": 50,
    "spend-symbol": "ETH",
    "spend-address": "0x851C09E79Bc97F3C4F4B5bB6B73Ec2Eaf8405275",
    "receive-amount": 1,
    "receive-address": "3LSn6xpJeYrVyHAc2qv4dbQyDbdja9xnym",
    "receive-symbol": "BTC",
    "stamp": 1608790201,
    "secret-hash": "0x46968e3f7fe7ecaedcc64b1381447af4"
}

The accept object hash is signed by Bob's profile private key.

Alice now makes a deposit with BTC HTLC contract using the secret hash provided by Bob.

to be continued

[noxonsu]

• тейкер (юзер) - важно удобство. морозит 1ый, заморозить чуть больше денег на случай если он не зарелизит секрет быстро.
• мейкер - важно не слить бюджет. штраф за медленный депозит (из за медленной комиссии) . штраф за не депозит.

htlc контракт с двумя секретами?