Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transfer omnicoins via HTLC or Multi-input Tx #691

Closed
D4nte opened this Issue Jan 23, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@D4nte
Copy link
Member

D4nte commented Jan 23, 2019

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:

  • 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).
  • Create P2WSH HTLC on testnet and verify that OL wallets recognize transfer of ownerships
  • If P2WSH fails, try with P2SH
  • 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 D4nte added this to the Sprint 7 🇦🇺🦐🔥 milestone Jan 23, 2019

@bonomat bonomat changed the title Transfer omnicoins via HTLC Transfer omnicoins via HTLC or Multi-input Tx Jan 29, 2019

@D4nte D4nte self-assigned this Feb 7, 2019

@D4nte

This comment has been minimized.

Copy link
Member Author

D4nte commented Feb 13, 2019

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

PoC: #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:

@D4nte

This comment has been minimized.

Copy link
Member Author

D4nte commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Member

thomaseizinger commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Member Author

D4nte commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Member Author

D4nte commented Feb 26, 2019

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

@D4nte D4nte closed this Feb 26, 2019

@wafflebot wafflebot bot removed the review label Feb 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.