📅 Original date posted:2019-10-01
📝 Original message:
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191001/f57d3131/attachment-0001.html>;
Richard Myers [ARCHIVE] /
npub12j…hfxgj
2023-06-09 12:56:23
in reply to nevent1q…7wry
Author Public Key
npub12jllrss5nmygfhg7j9ztk2te80t96kumx7cllfc29skut6phqh5qfhfxgjPublished at
2023-06-09 12:56:23Event JSON
{
"id": "2fcecaf41c715c011d7de6ca666cb48e45eceaa4bc9fcb5ff74354976f6f8856",
"pubkey": "54bff1c2149ec884dd1e9144bb29793bd65d5b9b37b1ffa70a2c2dc5e83705e8",
"created_at": 1686315383,
"kind": 1,
"tags": [
[
"e",
"48ac94f25d69b5552a61cf65f0074ea88d3094770ab039b5a4f1eaa1b21d7c6d",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2019-10-01\n📝 Original message:\nThanks Christian for pulling together this concise summary.\n\n1. General agreement on the usefulness of noinput / anyprevoutanyscript /\n\u003e anyprevout.\n\u003e\n\nI certainly support the unification and adoption of the sighash_noinput and\nanyprevoutput* proposals to enable eltoo, but also to make possible better\noff-chain protocol designs generally.\n\nAmong the various advantages previously discussed, the particular use case\nbenefits from eltoo I want to take advantage of is less interactive payment\nchannel negotiation.\n\nIn talking with people about eltoo this summer, I found most people\ngenerally support adding this as an option to Lightning. The only general\nconcern I heard, if any, was the vague idea that rebindable transactions\ncould be somehow misused or abused.\n\nI believe when these concerns are made more concrete they can be classified\nand addressed.\n\nI don't find too compelling the potential problem of a 'bad wallet\ndesigner', whether lazy or dogmatic, misusing noinput. I think there are\nsimpler ways to cut corners and there will always be plenty of good wallet\noptions people can choose.\n\nBecause scripts signed with no_input signatures are only really exchanged\nand used for off-chain negotiations, very few should ever appear on chain.\nThose that do should represent non-cooperative situations that involve\nsigning parties who know not to reuse or share scripts with these public\nkeys again. No third party has any reason to spend value to a\nmultisignature script they don't control, whether or not a no_input\nsignature exists for it.\n\n2. Is there strong support or opposition to the chaperone signatures\n\u003e introduced in anyprevout / anyprevoutanyscript? I think it'd be best to\n\u003e formulate a concrete set of pros and contras, rather than talk about\n\u003e abstract dangers or advantages.\n\u003e\n\nAs I mentioned before, I don't think the lazy wallet designer advantage is\nenough to justify the downsides of chaperone signatures. One additional\ndownside is the additional code complexity required to flag whether or not\na chaperone output is included. By comparison, the code changes for\ncreating a no_input digest that skips the prevout and prevscript parts of a\ntx is much less intrusive and easier to maintain.\n\n3. The same for output tagging / explicit opt-in. What are the advantages\n\u003e and\n\u003e disadvantages?\n\u003e\n\nI see the point ZmnSCPxj makes about tagged outputs negatively impacting\nthe anonymity set of taproot transactions. The suggested work around would\nimpose a cost to unilateral closes of an additional translation transaction\nand not using the work around would cause a hit to anonymity for off-chain\nscript users. I feel both costs are too high relative to the benefit gained\nof preventing sloppy reuse of public keys.\n\n4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the\n\u003e confusion and make for simpler discussions in the end.\n\n\nI believe they should be merged. I also think both chaperone signatures and\noutput tagging should become part of the discussion of security\nalternatives, but not part of the initial specification.\n\nI understand the desire to be conservative with protocol changes that could\nbe misused. However, with just taproot and taproot public key types the\nanyprevout functionality is already very opt-in and not something that\nmight accidentally get used. Belt-and-suspender protections like chaperone\nsignatures and tagged outputs have their own impacts on code complexity,\non-chain transaction sizes and transaction anonymity that also must be\nconsidered.\n\nI believe efforts like descriptors will help people follow best practices\nwhen working with complex scripts without pushing extra complexity for\nsafety into the consensus layer of bitcoin. Anywhere we can make core code\nsimpler, and handle foot-guns in higher level non-consensus code, the\nbetter.\n\n_______________________________________________\n\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191001/f57d3131/attachment-0001.html\u003e",
"sig": "ce4b5a455e11b510f2e18ea7be0d0da5a14343bc8d2eaf603b7de12a66c8239bcc0acb88e98ea8a9cb51d008afca17864c8b20c822a7d25411ad61d1b0897ca2"
}