public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ethan Heilman <eth3rs@gmail.com>
To: Richard Myers <rich@gotenna.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout
Date: Tue, 1 Oct 2019 10:27:21 -0400	[thread overview]
Message-ID: <CAEM=y+Vm=UW4-UGV4zVJQY8mdT=9Ljr9kVcfQovtzjRcx33L=w@mail.gmail.com> (raw)
In-Reply-To: <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>

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


  parent reply	other threads:[~2019-10-01 14:27 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 13:23 [bitcoin-dev] Continuing the discussion about noinput / anyprevout Christian Decker
2019-09-30 16:00 ` ZmnSCPxj
2019-09-30 23:28   ` ZmnSCPxj
2019-10-01 14:26     ` Christian Decker
2019-10-01 14:45     ` Anthony Towns
2019-10-01 15:42       ` ZmnSCPxj
2019-10-01 14:20   ` Christian Decker
2019-10-01 15:35     ` ZmnSCPxj
2019-10-03  9:42       ` Christian Decker
2019-10-01 12:23 ` Chris Stewart
2019-10-01 13:31   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-03 10:01     ` Christian Decker
2019-10-03  9:57   ` Christian Decker
     [not found] ` <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
2019-10-01 14:27   ` Ethan Heilman [this message]
2019-10-01 15:14   ` Chris Stewart
2019-10-03 10:30     ` Christian Decker
2019-10-01 15:59 ` [bitcoin-dev] " Anthony Towns
2019-10-02  2:03   ` ZmnSCPxj
2019-10-03  1:47     ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2019-10-03  3:07       ` ZmnSCPxj
2019-10-03 15:05     ` [bitcoin-dev] OP_CAT was " Ethan Heilman
2019-10-03 23:42       ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-04  0:48         ` Ethan Heilman
2019-10-04  5:02           ` Jeremy
2019-10-04  7:00             ` ZmnSCPxj
2019-10-04 18:33               ` Jeremy
2019-10-04 11:15             ` Peter Todd
2019-10-04 18:40               ` Jeremy
2019-10-05 15:49                 ` Peter Todd
2019-10-06  8:46                   ` ZmnSCPxj
2019-10-06  9:12                     ` Peter Todd
2019-10-06  7:02       ` Lloyd Fournier
2019-10-09 16:56       ` Andrew Poelstra
2019-10-02 15:11   ` [bitcoin-dev] " s7r
2019-10-03 11:08   ` Christian Decker
2019-10-05 10:06     ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEM=y+Vm=UW4-UGV4zVJQY8mdT=9Ljr9kVcfQovtzjRcx33L=w@mail.gmail.com' \
    --to=eth3rs@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=rich@gotenna.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox