Closed dr-orlovsky closed 3 years ago
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.
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
Option 2: Re-tweak in cycle until the solutions is found; if deadlock is reached failback to variant 1
Option 1: Break BIP69 in favour of LNPBP3
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.
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.
Well, this then basically solves the entire problem for us. We can stick to LNPBP3 without worrying about privacy loss.
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.
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
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:
Affected protocols: