Comments (13)
@MaxHillebrand Also, it’s quite funny, but since there is no concept of “address” at the level of Bitcoin blockchain, it’s completelly unused by RGB assets/state (i.e. Bech32 address encoding does not provide any benefits since there are no addresses to encode in SegWit or old-fashioned way). The state is attached to specific Txids/vouts, and donot require the use addresses at all. Moreover, there is a WIP proposal to use LN-styled “invoices”, getting the rid of “addresses” in general for all RGB-related stuff (including on-chain transfers).
Addresses present a “UX”-incentivisation for public key re-use, which is certainly a bad practice, giving a feeling of some permanent “account” to a non-advanced users.
from lnpbps.
I was thinking about this issue for a long time and my proposal is the following:
- LNPBP1-4 are generic commitment protocols not linked to any specific application: nether RGB not any else. They are "free to use", and it's up to a particular application which of outputs to support. So I propose to remove requirement to support all types of output from the text, and specify directly that it's up to a specific protocol to decide; LNPBP-2 will define how any output type can be used for storing commitment; but which types of outputs MUST be used — it's not a part of LNPBP-2
- With RGB, let's make a decision near the release of the protocol, taking into the account situation with Taproot of that stage.
I think a strong argument against deprecating non-SegWit outputs is that we can't really differentiate P2SH from P2W(SH/PK)-in-P2SH outputs before they spent, so there is no strong technical ways of deprecating non-SegWit outputs.
from lnpbps.
In this case I am not in favour of the proposal, as I see the previously mentioned case as a valid motivation to use legacy outputs.
from lnpbps.
I'd go as far as to deprecate anything < SegWit v1 (not to be confused with v0) once it gets activated. The privacy benefits it brings are too big to ignore.
from lnpbps.
So I propose to remove requirement to support all types of output from the text, and specify directly that it's up to a specific protocol to decide.
ACK, I have contemplated this too, and this seems to be not a decision that the protocol designers should force on implementation devs.
from lnpbps.
Some people may want to use legacy transaction to consume more vbytes and help the block stay smaller, but if limiting RGB to SegWit can help in reducing the complexity of the implementation it seems like a good idea to do so.
from lnpbps.
No, there is no technical benefit from limiting to SegWit only
from lnpbps.
Concept ACK.
Though @dr-orlovsky, I would guess that native SegWit only [and future taproot] might indeed be a reduction of spec and code complexity.
Plus, it makes sense, with malleability fix [better unconfirmed tx usage] + fee savings.
from lnpbps.
@MaxHillebrand what do you think regarding potential downside indicated by @fedsten?
from lnpbps.
To keep the block size small might be a valid side concern, however, I do not think this justifies increasing the spec / code complexity and neglecting all the numerous benefits of segwit [other than the witness discount]. I would say that:
Benefits of SegWit only
- Less edge cases in the specification
- Less code
- Malleability fix, useful for working with chains of unconfirmed children.
- Witness discount for cheaper fees
- Superior bech32 address format [typo detection, lower case etc.]
- Future upgradeability to taproot
- Smaller BIP158 block filters for private and efficient light clients.
Disadvantages of SegWit only
- Users are "forced" to have above mentioned "benefits", no legacy support
- Increase generated block size
I can speak from experience of working on Wasabi Wallet, which is native SegWit [single pubkey] only, and this GREATLY reduces complexity. Imho, the benefits outweigh the drawbacks to a large extend.
from lnpbps.
@MaxHillebrand Most of the mentioned benefits will still be present if we support the legacy format. The only exclusion is the first two points; however the code is already written and the spec is generic, not having special branches for non-SegWit cases. So not supporting SegWit at this stage means to delete some existing code and directly state that non-SegWits are prohibited. However we have to maintain OP_RETURN to be compatible with hardware wallers.
from lnpbps.
Yeah, but it will take at least a year; and we'll release until then. And it will be a hardfork, which we can't afford for client-validated model (will break the whole network)
from lnpbps.
Yeah, I knew that it's not coming soon, didn't realize it'd be such huge breakage. I guess it'd still be worth trying to provide the tooling for new version later and discourage use of the old one in new instances.
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-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
- Should RGB schema enforce lower bounds on meta fields? HOT 2
- Mitigation of Sybil attacks in LN HOT 3
- 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.