LNPBP-2: remove support for non-SegWit outputs

[dr-orlovsky]

Originally we wanted to support all possible output types; however it may be improper to promote usage of non-SegWit output types. If some software is not supporting SegWit it is probably should be limited from using RGB as well (from political, not technical perspective).

[fedsten]

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.

[dr-orlovsky]

No, there is no technical benefit from limiting to SegWit only

[fedsten]

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.

[MaxHillebrand]

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.

[dr-orlovsky]

@MaxHillebrand what do you think regarding potential downside indicated by @fedsten?

[MaxHillebrand]

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.

[dr-orlovsky]

@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.

[dr-orlovsky]

@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.

[Kixunil]

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.

[dr-orlovsky]

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)

[Kixunil]

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.

[dr-orlovsky]

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.

[MaxHillebrand]

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.