Re: [Lightning-dev] Continuing the discussion about noinput / anyprevout
Chris Stewart writes: >> 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. > > In my original post, the business that I am talking about don't use "off > the shelf" wallet options. It isn't a "let's switch from wallet A to wallet > B" kind of situation. Usually this involves design from ground up with > security considerations that businesses of scale need to consider (signing > procedures and key handling being the most important!). In this case I'd hope that the custom wallet designers/developers are well-versed in the issues they might encounter when implementing their wallet. This is especially true if they decide to opt into using some lesser known sighash flags, such as noinput, that come with huge warning signs (I forgot to mention that renaming noinput to noinput_dangerous is also still on the table). >>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. > > Just because some one is your friend today, doesn't mean they aren't > necessarily your adversary tomorrow. I don't think a signature being > onchain really matters, as you have to give it to your counterparty > regardless. How do you know your counterparty won't replay that > SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on > "good-will" for their counter parties for security. > >>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. > >>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 > > I actually think lazy wallet designer is a really compelling reason to fix > footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy > wallet design. Now we have non-malleable transactions in the form of segwit > (yay!) that prevent this exploit. We can wish that the Mt Gox wallet > designers were more aware of bitcoin protocol vulnerabilities, but at the > end of the day the best thing to do was offering an alternative that > circumvents the vulnerability all together. It's worth pointing out that the transaction malleability issue and the introduction of a new sighash flag are fundamentally different: a wallet developer has to take active measures to guard against transaction malleability since it was present even for the most minimal implementation, whereas with sighash flags the developers have to actively add support for it. Where transaction malleability you just had to know that it might be an issue, with noinput you actively have to do work yo expose yourself to it. I'd argue that you have to have a very compelling reason to opt into supporting noinput, and that's usually because you want to support a more complex protocol such as an off-chain contract anyway, at which point I'd hope you know about the tradeoffs of various sighash flags :-) > Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have > virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly > every transaction. The feature -- ECDSA in this case -- was managed to be > done wrong by wallet developers causing fund loss. Unfortunately we can't > protect against this type of bug in the protocol. > > If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it > doesn't matter if they are secure or insecure. I'm hopefully that offchain > protocols will achieve wide adoption, and I would hate to see money lost > because of this. Even though they aren't used, in my OP I do advocate for > fixing these. I do share the feeling that we better make a commonly used sighash flag as useable and safe as possible, but it's rather unrealistic to have a developer that is able to implement a complex off-chain system, but fails to understand the importance of using the correct sighash flags in their wallet. That being said, I think this
Re: [Lightning-dev] Continuing the discussion about noinput / anyprevout
> 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. In my original post, the business that I am talking about don't use "off the shelf" wallet options. It isn't a "let's switch from wallet A to wallet B" kind of situation. Usually this involves design from ground up with security considerations that businesses of scale need to consider (signing procedures and key handling being the most important!). >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. Just because some one is your friend today, doesn't mean they aren't necessarily your adversary tomorrow. I don't think a signature being onchain really matters, as you have to give it to your counterparty regardless. How do you know your counterparty won't replay that SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on "good-will" for their counter parties for security. >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. >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 I actually think lazy wallet designer is a really compelling reason to fix footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy wallet design. Now we have non-malleable transactions in the form of segwit (yay!) that prevent this exploit. We can wish that the Mt Gox wallet designers were more aware of bitcoin protocol vulnerabilities, but at the end of the day the best thing to do was offering an alternative that circumvents the vulnerability all together. Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly every transaction. The feature -- ECDSA in this case -- was managed to be done wrong by wallet developers causing fund loss. Unfortunately we can't protect against this type of bug in the protocol. If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it doesn't matter if they are secure or insecure. I'm hopefully that offchain protocols will achieve wide adoption, and I would hate to see money lost because of this. Even though they aren't used, in my OP I do advocate for fixing these. > 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'm making the assumption that the business has decided to use this feature, and in my OP I talk about the engineering decisions that will have to be made support this. I'm hoping the "lazy wallet designers" -- or perhaps people that don't follow bitcoin protocol development as rabidly as us :-) -- can see that nuance. -Chris On Tue, Oct 1, 2019 at 8:36 AM Richard Myers 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
Re: [Lightning-dev] Continuing the discussion about noinput / anyprevout
>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 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 >
Re: [Lightning-dev] Continuing the discussion about noinput / anyprevout
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] Continuing the discussion about noinput / anyprevout
With the recently renewed interest in eltoo, a proof-of-concept implementation [1], and the discussions regarding clean abstractions for off-chain protocols [2,3], I thought it might be time to revisit the `sighash_noinput` proposal (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5]. (sorry for the long e-mail. I wanted to give enough context and describe the various tradeoffs so people don't have to stitch them together from memory. If you're impatient there are a couple of open questions at the bottom) Both proposals are ways to allow rebinding of transactions to new outputs, by adding a sighash flag that excludes the output when signing. This allows the transaction to be bound to any output, without needing a new signature, as long as output script and input script are compatible, e.g., the signature matches the public key specified in the output. BIP-118 is limited to explaining the details of signature verification, and omits anything related to deployment and dependency on other proposals. This was done in order not to depend on bip-taproot which is also in draft-phase currently, and to allow deployment alongside the next version of segwit script. `bip-anyprevout` builds on top of BIP-118, adding integration with `bip-taproot`, chaperone signatures, limits the use of the sighash flag to script path spends, as well as a new pubkey serialization which uses the first byte to signal opt-in. I'd like to stress that both proposals are complementary and not competing, which is something that I've heard a couple of times. There remain a couple of unclear points which I hope we can address in the coming days, to get this thing moving again, and hopefully get a new tool in our toolbox soon(ish). In the following I will quote a couple of things that were discussed during the CoreDev meeting earlier this year, but not everybody could join, and it is important that we engage the wider community, to get a better picture, and I think not everybody is up-to-date about the current state. ## Dangers of `sighash_noinput` An argument I have heard against noinput is that it is slightly less complex or compute intensive than `sighash_all` signatures, which may encourage wallet creators to only implement the noinput variant, and use it indiscrimi- nately. This is certainly a good argument, and indeed we have seen at least one developer proposing to use noinput for all transactions to discourage address reuse. This was also mentioned at CoreDev [6]: > When [...] said he wanted to write a wallet that only used SIGHASH\_NOINPUT, > that was pause for concern. Some people might want to use SIGHASH\_NOINPUT as > a > way to cheapen or reduce the complexity of making a wallet > implementation. SIGHASH\_NOINPUT is from a purely procedural point of view > easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're hashing > less. It's way faster. That concern has been brought to my attention and it's > something I can see. Do we want to avoid people being stupid and shooting > themselves and their customers in the foot? Or do we treat this as a special > case where you mark we're aware of how it should be used and we just try to > get that awareness out? Another issue that is sometimes brought up is that an external user may attempt to send funds to a script that was really part of a higher-level protocol. This leads to those funds becoming inaccessible unless you gather all the participants and sign off on those funds. I don't believe this is anything new, and if users really want to shoot themselves in the foot and send funds to random addresses they fish out of a blockexplorer there's little we can do. What we could do is make the scripts used internally in our protocols unaddressable (see output tagging below), removing this issue altogether. ## Chaperone signatures Chaperone signatures are signatures that ensure that there is no third-party malleability of transactions. The idea is to have an additional signature, that doesn't use noinput, or any of its variants, and therefore needs to be authored by one of the pubkeys in the output script, i.e., one or more of the participants of the contract the transaction belongs to. Concretely in eltoo we'd be using a shared key known to all participants in the eltoo instance, so any participant can sign an update to rebind it to the desired output. Chaperone signatures have a number of downsides however: - Additional size: both the public key and the signature actually need to be stored along with the real noinput signature, resulting in transfer, computational and storage overhead. We can't reuse the same pubkey from the noinput signature since that'd require access to the matching privkey which is what we want to get rid of using noinput in the first place. - Protocols can still simply use a globally known privkey, voiding the benefit of chaperone signatures, since third-parties can sign again. I argue that third-party
