Comments (6)
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.
Related Issues (20)
- Make data type constants part fo the standard HOT 1
- Upgrade LNPBP-4 with merke trees
- LNPBP-2 references to an outdated stage of commitment procedure of LNPBP-1 HOT 2
- LNPBP-1 lacks standardization of public key serialization format HOT 6
- Cover multiple instances of the same pubkey in LNPBP-1 and 2 standards
- Allow bulletproof implementation upgradability in RGB schema HOT 1
- LNPBP-31: ElGamal on Secp256k1
- Write Tapret commitments standard HOT 4
- Test vectors HOT 1
- Write specification for opret-based RGB in BOLT lightning
- ticker doesn't allow numbers HOT 2
- decide future of current RGB21 implementation HOT 1
- Add contract media global state HOT 2
- RGB: Use i64 instead of i32 for Timestamps in interface standards HOT 6
- RGB-21 Schema: What should be the limit of the length of the name field? HOT 2
- RGB-21 Schema: Custom token data formatting HOT 2
- LNPBP-2: Miniscript determinism can't be used for key tweaks HOT 1
- LNPBP-2: Upgrade miniscript version requirement to v5.0.0 tagged commit
- LNPBP-38: Add support for Bifrost
- RGBv2: Reduce anchor entropy bit size by merging with txid data
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lnpbps.