MCIP Draft - Optional Tombstone Block

[UkoeHB]

No description provided.

[cbeck88]

I think this MCIP would be stronger if it included a more detailed discussion of motivation and discussion of possible alternatives.

The MCIP points out that having a tombstone block means that clients can be sure that their transaction is now dead, and not have to accommodate the possibility that it may still happen (and invalidate another transaction with the same TxOut's).
This is useful and the MCIP doesn't propose an alternative way for clients to get this.

The MCIP cites as motivation:

(e.g. for multisig/MPC, some atomic swap methods, and most payment channel approaches)

It seems that multisig could also work by having clients communicate out-of-band and all sign a payload. We are currently planning to do something like in connection to group signatures for confidential token ids. Does long-lived / slow transactions really help with this in practice?

For atomic swaps, I would love to hear some examples of atomic swap methods that need this and why they are better or worse than other methods that don't need this. AFAIK cross-chain atomic swaps are still very much a research problem and not used significantly in practice.

For payment channels, the main one I can think of is something like lightning network. But the main reason to use something like that is because the layer 1 is not fast enough or has fees that are too high to accommodate payment use-cases. MobileCoin doesn't have this problem so there is probably no use-case for building payment channels on top of the MobileCoin blockchain.

---

The other thing that is confusing to me is, the MCIP really means that consensus gets to decide the tombstone block arbitrarily and not the client, so these transactions may not actually be "slow", it just means "you don't know at what point this transaction will be discarded".

If one of these use-cases actually requires slow transactions to work, then I'm not sure this MCIP will actually help them.

[UkoeHB]

The other thing that is confusing to me is, the MCIP really means that consensus gets to decide the tombstone block arbitrarily and not the client, so these transactions may not actually be "slow", it just means "you don't know at what point this transaction will be discarded".

A slow transaction is a transaction that takes a while to construct, not one that is allowed/expected to sit around in the node cache for a long time. It's pretty much impossible to have an escrowed digital marketplace without slow 2-of-3 multisig transactions (txs that can take weeks to construct from initial partial signatures to the full signature).

IMO it is pointless to implement multisig for MobileCoin unless this MCIP is implemented first.

This is useful and the MCIP doesn't propose an alternative way for clients to get this.

The expectation is if you set tombstone_block = 0, then you are giving nodes the freedom to decide when a tx is dead. In practice, this will be close to the normal tombstone period of 100 blocks if best practices are followed.

For atomic swaps, I would love to hear some examples of atomic swap methods that need this and why they are better or worse than other methods that don't need this. AFAIK cross-chain atomic swaps are still very much a research problem and not used significantly in practice.

I don't know much about atomic swaps, just that they require a series of tx construction events, where some txs are not submitted immediately. Here are two resources: 1, 2.

[cbeck88]

I see, I understand much better now, thank you. This is like, the tx is signed first by one party but then more interaction is needed and so it can't be submitted immediately.

Maybe consensus can tell the client the invented tombstone block when they submit it? So that the client can still know when it is dead

[UkoeHB]

Maybe consensus can tell the client the invented tombstone block when they submit it? So that the client can still know when it is dead

Idk if this is needed. It is just the current block + 100.