Transfer omnicoins via HTLC or Multi-input Tx

[D4nte]

Follow-up of #666. See notes

We need to understand whether Omnilayer wallets[1][2] recognise transfer of ownership through bitcoin scripts (HTLC) or through multi-input transactions.

DoD:

• [x] Create a transaction spending from multiple inputs, 1 for Alice (USDT) and 1 for Bob (BTC) and swaps the ownership, i.e. spends to Alice (BTC) and spends to Bob (USDT).
• [x] Create P2WSH HTLC on testnet and verify that OL wallets recognize transfer of ownerships
• [x] If P2WSH fails, try with P2SH
• [x] If either succeed, Open ticket to write RFC comit-network/RFCs#33 & comit-network/RFCs#36

Child of #663 Blocked by #724 [1]https://www.omniwallet.org/ [2]https://github.com/OmniLayer/omnicore

[D4nte]

What we learned - Alice sells omnicoins to Bob for BTC (same chain swap)

PoC: https://github.com/comit-network/comit-rs/pull/757

Information needed

• alice_address: address that owns the OmniToken, this is where Alice will receive BTC (tech limitation)
• bob_address: address that owns BTC, will be used for BTC change
• bob_address2: "final" address for Bob, this is where Omni Token will be sent

Inputs

1. Alice Omni alice_address (ordering matters, this must be the first input)
2. Bob BTC bob_address

Outputs

• Bob Change BTC bob_address (must be present in inputs to not have Omni Tokens transferred to)
• Alice BTC alice_address (must be present in inputs to not have Omni Tokens transferred to)
• Bob Omni bob_address2 (new address where Omni Token are sent)
• OP_RETURN Omni Payload

Other considerations

1. We could have Bob receive his BTC change and Omni Tokens at the same address, this can easily be done and could be left to Bob to decide (for example, we could say that Bob builds the transaction and can decide between 2 formats)
2. What if Bob does wants to use several UTXO to provide BTC? It should not be an issue is that something we want to double check now?
3. What about bech32? -> latest version of omnicored (v0.3.1) does not support this address format

Dust

Bitcoind enforces that spendable UTXO have enough value to be spent. If it's under this value then it is what we commonly call dust. In bitcoind, it's actually defined in term of dustRelayFee and it is set by default to 3000 satoshis-per-kilobytes`. For normal transaction, the minimum value is 546sat. 294sat for segwit.

However, in regtest and testnet, dust is ignored! This is due to the fact that -acceptnonstdtxn is activated by default on these chains. This can be deactivated via -acceptnonstdtxn=0.

Finally, this is only for spendable UTXO. As OP_RETURN UTXOs are not spendable, they do not need dust.

See:

• Dust min value calculation
• Dust is not activated for regtest and testnet 1 & 2

[D4nte]

All PoC are now demonstrated in #772

What we learned is that by adding omnilayer payload in an OP_RETURN output it is possible to lock omnilayer tokens in an HTLC (P2SH or P2SH(P2WSH)) and then redeem them to a normal P2PKH.

What we can also ponder is that I chose to use our testing suite and bitcoinjs-lib to proceed with this PoC as I thought that updating comit-rs and bsieve would be too much overhead. However, we created COMIT exactly for this kind of experience so maybe (next time?) we need to do our PoC in COMIT and discover/remove all obstacle that makes such work hard (e.g., being able to not have to override bsieve for a PoC?)

[thomaseizinger]

What we can also ponder is that I chose to use our testing suite and bitcoinjs-lib to proceed with this PoC as I thought that updating comit-rs and bsieve would be too much overhead. However, we created COMIT exactly for this kind of experience so maybe (next time?) we need to do our PoC in COMIT and discover/remove all obstacle that makes such work hard (e.g., being able to not have to override bsieve for a PoC?)

I think it would be good to have a brainstorming/discussion session (can you organize one please @D4nte?) about this where you (@D4nte) can first present your approach for this PoC and we can then discuss possibilities of how we can change COMIT to make this easier.

[D4nte]

What we can also ponder is that I chose to use our testing suite and bitcoinjs-lib to proceed with this PoC as I thought that updating comit-rs and bsieve would be too much overhead. However, we created COMIT exactly for this kind of experience so maybe (next time?) we need to do our PoC in COMIT and discover/remove all obstacle that makes such work hard (e.g., being able to not have to override bsieve for a PoC?)

I think it would be good to have a brainstorming/discussion session (can you organize one please @D4nte?) about this where you (@D4nte) can first present your approach for this PoC and we can then discuss possibilities of how we can change COMIT to make this easier.

Booked for 27 Feb.

[D4nte]

After discussion, we will open 2 RFCs:

1. New protocol for BTC/OL Token swap comit-network/RFCs#36
2. RFC-003 for OL Token (cross chain) comit-network/RFCs#33