RGB: Solving non-determinism in tx output order for witness transactions

[dr-orlovsky]

Witness transaction, closing a single-use-seal with some assigned RGB state, must contain commitment to the new state. This is done by tweaking public key(s) in one of it's outputs according to LNPBP-3; the specific output is defined by some constant genesis-based factor (hash of genesis) and transaction fee. However this collides with deterministic transaction output ordering (BIP-69): if transaction contains two or more outputs with the same amount (like in CoinJoin), public key modification may change their order with 1 - 1/no_of_same_amont_outpus probability. However, re-ordering is impossible: untweaking key in one output and tweaking the other will change the order back, leading to potential deadlocks.

Possible solutions:

1. Break deterministic ordering: negative impact on privacy in a small number of cases
2. Re-tweak in cycle until the solutions is found; if deadlock is reached failback to variant 1
3. Tweak all outputs with the same amount. Most private and deterministic, however will require wallets to maintain more additional information

Affected protocols:

• Lightning channels
• CoinJoin
• Bitcoin Wallets implementing BIP-69 (very rare)

[dr-orlovsky]

The preliminary decision from the dev call on the Aug 26 2020: leave option 1 as a default and if a better algorithm will be found, introduce it later with LN feature flag. The final decision will be taken on the next call on the 2nd of Sept 2020.

[rajarshimaitra]

Summary of Devcall Date: Aug 26 2020.

RGB requires Deterministic Transaction Ordering (LNPBP3) to solve double spending of assets. This deterministic positioning clashes with BIP69 lexicographic ordering of TxOuts. Deciding between two ordering options involves tradeoffs in various areas including privacy, computation cost, usability etc. A brief tradeoff description of obove mentioned options are presented below for future refernce and discussions.

Starting with

Option 3: Tweak all outputs with the same amount. Most private and deterministic, however will require wallets to maintain more additional information

• possibly non-viable.
• Other TxOuts can have different purpose which we dont know or care about. Assuming their spending wallet will be aware about RGB data is a strong assumption with major operational risk.
• Requires tweak data to be supplied to other wallets which wants to spent other TxOuts in the same transaction. Which is major privacy negetive.
• Infeasible for coinjoin as other TxOut owners are anonymous.

Option 2: Re-tweak in cycle until the solutions is found; if deadlock is reached failback to variant 1

• Possibly workable but has some problems.
• Requires a lot of business logic to handle all possible edge cases.
• Computaionally costly to iterate over the tweaking procedure.
• Leads to onchain privacy leak anyway if solution isn't found.

Option 1: Break BIP69 in favour of LNPBP3

• Intentionally breaking BIP69 to preserve LNPBP3 will lead chain-analysis to identify LN closing transactions containing RGB assets.
• Leakage is only limited to LN channels (or any mechanism where BIP69 is expected).
• Onchain privacy unaffected as BIP69 is not requirement for regular Bitcoin transactions.
• Preserves existing protocol implementation in LNPBP3.
• RGB will be incompatible with BIP69.

Discussing over the above tradeoffs, consensus emerged around Option 1. Implmentation will be kept LNPBP3 compliant breaking the BIP69 compatiblity. Further reasearch can be pursued to find BIP69 compatible determinsitic transaction ordering, which can be implemented in RGB in future by using a feature flag.

Please comment below if there were anything that I missed.

[dr-orlovsky]

We should pay attention to the topics discussed in https://github.com/discreetlogcontracts/dlcspecs/issues/18 and the fact that LN has moved from using BIP-69 to a different mechanism: https://twitter.com/niftynei/status/1237535101509971968

I think this is clearly better for both privacy (larger anonymity set, all transactions are non-distinguishable whether they use this mechanism or not) and for RGB tweaking and resolves our issue.

[rajarshimaitra]

Well, this then basically solves the entire problem for us. We can stick to LNPBP3 without worrying about privacy loss.

[dr-orlovsky]

Yes, it is. I will leave the issue open till the next dev call in case someone will find something we are missing here, and will close it after.

[dr-orlovsky]

Closed after thorough discussion over several dev calls with the final decision not to address this issue, since due to https://github.com/LNP-BP/LNPBPs/issues/46#issuecomment-691464000 this is a non-issue