RGB: Solving non-determinism in tx output order for witness transactions about lnpbps HOT 6 CLOSED

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.

from lnpbps.

We should pay attention to the topics discussed in discreetlogcontracts/dlcspecs#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.

from lnpbps.

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.

from lnpbps.

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

from lnpbps.

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.

from lnpbps.

Closed after thorough discussion over several dev calls with the final decision not to address this issue, since due to #46 (comment) this is a non-issue

from lnpbps.