Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning lists, Let me propose the below radical idea: * `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with: * 1 RETURN * higher-`nSequence` replacement * DER-encoded pubkeys * unrestricted `scriptPubKey` * Payee-security-paid-by-payer (i.e. lack of P2SH) * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends * transaction malleability * probably many more So let me propose the more radical excision, starting with SegWit v1: * Remove `SIGHASH` from signatures. * Put `SIGHASH` on public keys. Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate). `OP_CHECKSIG` and friends then look at the *public key* to determine sighash algorithm rather than the signature. As we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`. However, we can then utilize the many many ways to hide public keys away until they are needed, exemplified in MAST-inside-Taproot. I propose also the addition of the opcode: OP_SETPUBKEYSIGHASH * `sighash` must be one byte. * `pubkey` may be the special byte `0x1`, meaning "just use the Taproot internal pubkey". * `pubkey` may be 33-byte public key, in which case the `sighash` byte is just prepended to it. * `pubkey` may be 34-byte public key with sighash, in which case the first byte is replaced with `sighash` byte. * If `sighash` is `0x00` then the result is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit. This retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment. This is done by using the script: OP_SETPUBKEYSIGHASH OP_CHECKSIG Then the sighash can be put in the witness stack after the signature, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so. This is malleability-safe as the signature still commits to the `SIGHASH` it was created for. However, by default, public keys will not have an attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`). This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed. Would this not be a superior solution? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev wrote: > 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]. Hey Christian, thanks for the write up! > ## Open questions > The questions that remain to be addressed are the following: > 1. General agreement on the usefulness of noinput / anyprevoutanyscript / > anyprevout[?] > 2. Is there strong support or opposition to the chaperone signatures[?] > 3. The same for output tagging / explicit opt-in[?] > 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the > confusion and make for simpler discussions in the end. I think there's an important open question you missed from this list: (1.5) do we really understand what the dangers of noinput/anyprevout-style constructions actually are? My impression on the first 3.5 q's is: (1) yes, (1.5) not really, (2) weak opposition for requiring chaperone sigs, (3) mixed (weak) support/opposition for output tagging. My thinking at the moment (subject to change!) is: * anyprevout signatures make the address you're signing for less safe, which may cause you to lose funds when additional coins are sent to the same address; this can be avoided if handled with care (or if you don't care about losing funds in the event of address reuse) * being able to guarantee that an address can never be signed for with an anyprevout signature is therefore valuable; so having it be opt-in at the tapscript level, rather than a sighash flag available for key-path spends is valuable (I call this "opt-in", but it's hidden until use via taproot rather than "explicit" as output tagging would be) * receiving funds spent via an anyprevout signature does not involve any qualitatively new double-spending/malleability risks. (eltoo is unavoidably malleable if there are multiple update transactions (and chaperone signatures aren't used or are used with well known keys), but while it is better to avoid this where possible, it's something that's already easily dealt with simply by waiting for confirmations, and whether a transaction is malleable is always under the control of the sender not the receiver) * as such, output tagging is also unnecessary, and there is also no need for users to mark anyprevout spends as "tainted" in order to wait for more confirmations than normal before considering those funds "safe" I think it might be good to have a public testnet (based on Richard Myers et al's signet2 work?) where we have some fake exchanges/merchants/etc and scheduled reorgs, and demo every weird noinput/anyprevout case anyone can think of, and just work out if we need any extra code/tagging/whatever to keep those fake exchanges/merchants from losing money (and write up the weird cases we've found in a wiki or a paper so people can easily tell if we missed something obvious). Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning aj, > On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote: > > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > > `OP_CHECKSIG_WITHOUT_INPUT`. > > I don't think there's any meaningful difference between making a new > opcode and making a new tapscript public key type; the difference is > just one of encoding: > > 3301AC [CHECKSIG of public key type 0x01] > 32B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key] > > > This new opcode ignores any `SIGHASH` flags, if present, on a signature, > > (How sighash flags are treated can be redefined by new public key types; > if that's not obvious already) Thank you for this thought, I believe under tapscript v0 we can give `OP_1` as the public key to `OP_CHECKSIG` to mean to reuse the internal Taproot pubkey, would it be possible to have some similar mechanism here, to copy the internal Taproot pubkey but also to enable new `SIGHASH` flag for this particular script only? This seems fine, as then a Decker-Russell-Osuntokun funding tx output between nodes A, B, and C would have: * Taproot internal key: `P = MuSig(A, B, C)` * Script 1: leaf version 0, ` OP_CHECKSIG` Then, update transactions could use `MuSig(A,B,C)` for signing along the "update" path, with unique "state" keys. And cooperative closes would sign using `P + h(P | MAST( OPCHECKSIG)) * G`, not revealing the fact that this was in fact a Decker-Russell-Osuntokun output. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning Christian, > > - A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction > > Output, confirmed onchain > > - A "translator transaction" spending the above and paying out to a > > SegWit v16 output-tagged output, kept offchain. > > - Decker-Russell-Osuntokun update transaction, signed with > > `SIGHASH_NOINPUT` spending the translator transaction output. > > - Decker-Russell-Osuntokun state transaction, signed with > > `SIGHASH_NOINPUT` spending the update transaction output. > > That is very much how I was planning to implement it anyway, using a > trigger transaction to separate timeout start and the actual > update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo > there shouldn't be an issue here :-) My understanding is that a trigger transaction is not in fact necessary for Decker-Russell-Osuntokun: any update transaction could spend the funding transaction output directly, and thereby start the relative timelock. At least, if we could arrange the funding transaction output to be spendable directly using `SIGHASH_NOINPUT` or variants thereof. > > Again, the more important point is that special blockchain > > constructions should only be used in the "bad" unilateral close case. > > In the cooperative case, we want to use simple plain > > bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot > > SegWit v1 addresses, to increase the anonymity set of all uses of > > Decker-Russell-Osuntokun and other applications that might use > > `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple > > bip-schnorr-signed n-of-n cases when the protocol is completed > > successfully by all participants). > > While I do agree that we should keep outputs as unidentifiable as > possible, I am starting to question whether that is possible for > off-chain payment networks since we are gossiping about the existence of > channels and binding them to outpoints to prove their existence anyway. * Lightning supports unpublished channels, so we do not gossip some outpoints even though they are in fact channels underneath. * I confess the existence of unpublished channels in the spec fails to summon any reaction other than incredulity from me, but they exist nonetheless, my incredulity notwithstanding. * Historical channels that have been cooperatively closed are no longer normally gossiped, so the fact that they used to be channels is no longer widely broadcast, and may eventually be forgotten by most or all of the network. * This means anyone who wants to record the historical use of Lightning will have to retain the information themselves, rather than delegating it to fullnodes everywhere. > > Not the strongest argument I know, but there's little point in talking > ideal cases when we need to weaken that later again. The point of ideal cases is to strive to approach them, not necessarily achieve them. Just as a completely unbiased rational reasoner is almost impossible to achieve, does not mean we should give up all attempts to reduce bias. Outpoints that used to be channels, but have now been closed using cooperative closes, will potentially no longer be widely gossiped as having once been channels, thus it may happen that they will eventually be forgotten by most of the network as once having been channels. But if the outpoints of those channels are specially marked, then that cannot be forgotten, as the initial block download thereafter will have that history indelibly etched forevermore. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote: > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. I don't think there's any meaningful difference between making a new opcode and making a new tapscript public key type; the difference is just one of encoding: 3301AC [CHECKSIG of public key type 0x01] 32B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key] > This new opcode ignores any `SIGHASH` flags, if present, on a signature, (How sighash flags are treated can be redefined by new public key types; if that's not obvious already) Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
ZmnSCPxj writes: > To elucidate further --- > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. > > This new opcode ignores any `SIGHASH` flags, if present, on a > signature, but instead hashes the current transaction without the > input references, then checks that hash to the signature. > > This is equivalent to `SIGHASH_NOINPUT`. > > Yet as an opcode, it would be possible to embed in a Taproot script. > > For example, a Decker-Russell-Osuntokun would have an internal Taproot > point be a 2-of-2, then have a script `OP_1 > OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden > script, but cooperative closes would use the 2-of-2 directly. > > Of note, is that any special SCRIPT would already be supportable by Taproot. > This includes SCRIPTs that may potentially lose funds for the user. > Yet such SCRIPTs are already targetable by a Taproot address. > > If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not > so concerned about Taproot abuse? That would certainly be another possibility, which I have not explored in detail so far. Due to the similarity between the various signature checking op-codes it felt that it should be a sighash flag, and it neatly slotted into the already existing flags. If we go for a separate opcode we might end up reinventing the wheel, and to be honest I feared that proposing a new opcode would get us into bikeshedding territory (which I apparently failed to avoid with the sighash flag anyway...). The advantage would be that with the sighash flag the spender is in charge of specifying the flags, whereas with an opcode the output dictates the signature verification modalities. The downside is the increased design space. What do others think? Would this be an acceptable opt-in mechanism that addresses the main concerns? Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
ZmnSCPxj writes: > I rather strongly oppose output tagging. > > The entire point of for example Taproot was to reduce the variability > of how outputs look like, so that unspent Taproot outputs look exactly > like other unspent Taproot outputs regardless of the SCRIPT (or lack > of SCRIPT) used to protect the outputs. That is the reason why we > would prefer to not support P2SH-wrapped Taproot even though > P2SH-wrapping was intended to cover all future uses of SegWit, > including SegWit v1 that Taproot will eventually get. That is a bit reductive if you ask me. Taproot brings a number of improvements such as the reduction of on-chain footprint in the collaborative spend case, the hiding of complex logic in that case, and yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be to make everything look identical to the outside observer, but saying that separating outputs into two coarse-grained domains is equivalent to throwing the baby out with the bath-water :-) That being said, I should clarify that I would prefer not having to make special accomodations on top of the raw sighash_noinput proposal, for some perceived, but abstract danger that someone might shoot themselves in the foot. I think we're all old enough not to need too much handholding :-) Output tagging is my second choice, since it minimizes the need for people to get creative to work around other proposals, and minimizes the on-chain footprint, and finally chaperone signatures are my least preferred option due to its heavy-handed nature and the increased cost. > Indeed, if it is output tagging that gets into Bitcoin base layer, I > would strongly suggest the below for all Decker-Russell-Osuntokun > implementations: > > * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, > confirmed onchain > * A "translator transaction" spending the above and paying out to a SegWit > v16 output-tagged output, kept offchain. > * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` > spending the translator transaction output. > * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` > spending the update transaction output. That is very much how I was planning to implement it anyway, using a trigger transaction to separate timeout start and the actual update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo there shouldn't be an issue here :-) > The point regarding use of a commonly-known privkey to work around > chaperone signatures is appropriate to the above, incidentally. In > short: this is a workaround, plain and simple, and one wonders the > point of adding *either* chaperones *or* output tagging if we will, in > practice, just work around them anyway. Exactly, why introduce the extra burden of chaperone signatures or output tagging if we're just going to sidestep it? > Again, the *more* important point is that special blockchain > constructions should only be used in the "bad" unilateral close case. > In the cooperative case, we want to use simple plain > bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot > SegWit v1 addresses, to increase the anonymity set of all uses of > Decker-Russell-Osuntokun and other applications that might use > `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple > bip-schnorr-signed n-of-n cases when the protocol is completed > successfully by all participants). While I do agree that we should keep outputs as unidentifiable as possible, I am starting to question whether that is possible for off-chain payment networks since we are gossiping about the existence of channels and binding them to outpoints to prove their existence anyway. Not the strongest argument I know, but there's little point in talking ideal cases when we need to weaken that later again. >> Open questions >> >> --- >> >> The questions that remain to be addressed are the following: >> >> 1. General agreement on the usefulness of noinput / anyprevoutanyscript / >> anyprevout. While at the CoreDev meeting I think everybody agreed that >> these proposals a useful, also beyond eltoo, not everybody could be >> there. I'd therefore like to elicit some feedback from the wider >> community. > > I strongly agree that `NOINPUT` is useful, and I was not able to attend > CoreDev (at least, not with any human fleshbot already known to you --- I > checked). Great, good to know that I'm not shouting into the void, and that I'm not just that crazy guy trying to get his hairbrained scheme to work :-) >> 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. > > No opposition, we will just work around this by publishing a common > known private key to use for all chaperone signatures, since
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
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning lists, Let me summarize concerns brought up: * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output. I propose the below instead: * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`. * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`. Then, on usage: * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence. * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`. This solves both concerns: * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it. * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`. Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy. But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me. Would this alternate proposal hold better muster? Regards, ZmnSCPxj > I do have some concerns about SIGHASH_NOINPUT, mainly that it does introduce > another footgun into the bitcoin protocol with address reuse. It's common > practice for bitcoin businesses to re-use addresses. Many exchanges [1] reuse > addresses for cold storage with very large sums of money that is stored in > these addreses. > > It is my understanding with this part of BIP118 > > >Using NOINPUT the input containing the signature no longer references a > >specific output. Any participant can take a transaction and rewrite it by > >changing the hash reference to the previous output, without invalidating the > >signatures. This allows transactions to be bound to any output that matches > >the value committed to in the witness and whose witnessProgram, combined > >with the spending transaction's witness returns true. > > if an exchange were to once produce a digital signature from that cold > storage address with a SIGHASH_NOINPUT signature, that signature can be > replayed again and again on the blockchain until their wallet is drained. > This might be able to mitigated since the signatures commit to outputs, which > may be small in value for the transaction that SIGHASH_NOINPUT was used. This > means that an exchange could move coins from the address with a larger > transaction that spends money to a new output (and presumably pays a higher > fee than the smaller transactions). > > ### Why does this matter? > > It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain > protocols like Lightning. This gives us the building blocks for enforcing > specific offchain states to end up onchain [2]. > > Since this tool is useful, we can presume that it will be integrated into the > signing path of large economic entities in bitcoin -- namely exchanges. Many > exchanges have specific signing procedures for transactions that are leaving > an exchange that is custom software. Now -- presuming wide adoption of off > chain protocols -- they will need to have a _second unique signing path that > uses SIGHASH_NOINPUT_. > > It is imperative that this second signing path -- which uses SIGHASH_NOINPUT > -- does NOT get mixed up with the first signing path that controls an > exchanges onchain funds. If this were to happen, fund lost could occur if the > exchange is reusing address, which seems to be common practice. > > This is stated here in BIP118: > > >This also means that particular care has to be taken in order to avoid > >unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be used, > >unless it is explicitly needed for the application, e.g., it MUST NOT be a > >default signing flag in a wallet implementation. Rebinding is only possible > >when the outputs the transaction may bind to all use the same public keys. > >Any public key that is used in a NOINPUT signature MUST only be used for > >outputs that the input may bind to, and they MUST NOT be used for > >transactions that the input may not bind to. For example an application > >SHOULD generate a new key-pair for the application instance using NOINPUT > >signatures and MUST NOT reuse them afterwards. > > This means we need to encourage onchain hot wallet signing procedures to be > kept
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
I do have some concerns about SIGHASH_NOINPUT, mainly that it does introduce another footgun into the bitcoin protocol with address reuse. It's common practice for bitcoin businesses to re-use addresses. Many exchanges [1] reuse addresses for cold storage with very large sums of money that is stored in these addreses. It is my understanding with this part of BIP118 >Using NOINPUT the input containing the signature no longer references a specific output. Any participant can take a transaction and rewrite it by changing the hash reference to the previous output, without invalidating the signatures. This allows transactions to be bound to any output that matches the value committed to in the witness and whose witnessProgram, combined with the spending transaction's witness returns true. if an exchange were to once produce a digital signature from that cold storage address with a SIGHASH_NOINPUT signature, that signature can be replayed again and again on the blockchain until their wallet is drained. This might be able to mitigated since the signatures commit to outputs, which may be small in value for the transaction that SIGHASH_NOINPUT was used. This means that an exchange could move coins from the address with a larger transaction that spends money to a new output (and presumably pays a higher fee than the smaller transactions). ### Why does this matter? It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain protocols like Lightning. This gives us the building blocks for enforcing specific offchain states to end up onchain [2]. Since this tool is useful, we can presume that it will be integrated into the signing path of large economic entities in bitcoin -- namely exchanges. Many exchanges have specific signing procedures for transactions that are leaving an exchange that is custom software. Now -- presuming wide adoption of off chain protocols -- they will need to have a _second unique signing path that uses SIGHASH_NOINPUT_. It is imperative that this second signing path -- which uses SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that controls an exchanges onchain funds. If this were to happen, fund lost could occur if the exchange is reusing address, which seems to be common practice. This is stated here in BIP118: >This also means that particular care has to be taken in order to avoid unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be used, unless it is explicitly needed for the application, e.g., it MUST NOT be a default signing flag in a wallet implementation. Rebinding is only possible when the outputs the transaction may bind to all use the same public keys. Any public key that is used in a NOINPUT signature MUST only be used for outputs that the input may bind to, and they MUST NOT be used for transactions that the input may not bind to. For example an application SHOULD generate a new key-pair for the application instance using NOINPUT signatures and MUST NOT reuse them afterwards. This means we need to encourage onchain hot wallet signing procedures to be kept separate from offchain hot wallet signing procedures, which introduces more complexity for key management (two keychains). One (of the few) upsides of the current Lightning penalty mechanism is that fund loss can be contained to balance of the channel. You cannot do something in the current protocol that will effect your funds outside of that channel. With SIGHASH_NOINPUT, that property changes. ### A side note In general, i think we should start disallowing uses of the SIGHASH protocols that have unexpected behavior. The classic example of this is SIGHASH_SINGLE [3]. I get uneasy about adding more footguns to the protocol, which with current network behavior (address re-use) SIGHASH_NOINPUT would be a big one. [1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html [2] - https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote: > 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
