>I don't find too compelling the potential problem of a 'bad wallet designer', >whether lazy or dogmatic, misusing noinput. I think there are simpler ways to >cut corners and there will always be plenty of good wallet options people can >choose.
I want to second this. The most expensive part of wallet design is engineering time. Writing code that uses a new sighash or a custom script with a OP_CODE is a very large barrier to use. How many wallets support multisig or RBF? How much BTC has been stolen over the entire history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE vs ECDSA nonce reuse? On Tue, Oct 1, 2019 at 9:35 AM Richard Myers <r...@gotenna.com> wrote: > > Thanks Christian for pulling together this concise summary. > >> 1. General agreement on the usefulness of noinput / anyprevoutanyscript / >> anyprevout. > > > I certainly support the unification and adoption of the sighash_noinput and > anyprevoutput* proposals to enable eltoo, but also to make possible better > off-chain protocol designs generally. > > Among the various advantages previously discussed, the particular use case > benefits from eltoo I want to take advantage of is less interactive payment > channel negotiation. > > In talking with people about eltoo this summer, I found most people generally > support adding this as an option to Lightning. The only general concern I > heard, if any, was the vague idea that rebindable transactions could be > somehow misused or abused. > > I believe when these concerns are made more concrete they can be classified > and addressed. > > I don't find too compelling the potential problem of a 'bad wallet designer', > whether lazy or dogmatic, misusing noinput. I think there are simpler ways to > cut corners and there will always be plenty of good wallet options people can > choose. > > Because scripts signed with no_input signatures are only really exchanged and > used for off-chain negotiations, very few should ever appear on chain. Those > that do should represent non-cooperative situations that involve signing > parties who know not to reuse or share scripts with these public keys again. > No third party has any reason to spend value to a multisignature script they > don't control, whether or not a no_input signature exists for it. > >> 2. Is there strong support or opposition to the chaperone signatures >> introduced in anyprevout / anyprevoutanyscript? I think it'd be best to >> formulate a concrete set of pros and contras, rather than talk about >> abstract dangers or advantages. > > > As I mentioned before, I don't think the lazy wallet designer advantage is > enough to justify the downsides of chaperone signatures. One additional > downside is the additional code complexity required to flag whether or not a > chaperone output is included. By comparison, the code changes for creating a > no_input digest that skips the prevout and prevscript parts of a tx is much > less intrusive and easier to maintain. > >> 3. The same for output tagging / explicit opt-in. What are the advantages >> and >> disadvantages? > > > I see the point ZmnSCPxj makes about tagged outputs negatively impacting the > anonymity set of taproot transactions. The suggested work around would impose > a cost to unilateral closes of an additional translation transaction and not > using the work around would cause a hit to anonymity for off-chain script > users. I feel both costs are too high relative to the benefit gained of > preventing sloppy reuse of public keys. > >> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the >> confusion and make for simpler discussions in the end. > > > I believe they should be merged. I also think both chaperone signatures and > output tagging should become part of the discussion of security alternatives, > but not part of the initial specification. > > I understand the desire to be conservative with protocol changes that could > be misused. However, with just taproot and taproot public key types the > anyprevout functionality is already very opt-in and not something that might > accidentally get used. Belt-and-suspender protections like chaperone > signatures and tagged outputs have their own impacts on code complexity, > on-chain transaction sizes and transaction anonymity that also must be > considered. > > I believe efforts like descriptors will help people follow best practices > when working with complex scripts without pushing extra complexity for safety > into the consensus layer of bitcoin. Anywhere we can make core code simpler, > and handle foot-guns in higher level non-consensus code, the better. > > _______________________________________________ >> >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
