MIME-Version: 1.0
References: <87wodp7w9f.fsf@gmail.com>
	<CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
In-Reply-To: <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Tue, 1 Oct 2019 10:27:21 -0400
Message-ID: <CAEM=y+Vm=UW4-UGV4zVJQY8mdT=9Ljr9kVcfQovtzjRcx33L=w@mail.gmail.com>
To: Richard Myers <rich@gotenna.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

>I don't find too compelling the potential problem of a 'bad wallet designe=
r', whether lazy or dogmatic, misusing noinput. I think there are simpler w=
ays to cut corners and there will always be plenty of good wallet options p=
eople 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 a=
nd anyprevoutput* proposals to enable eltoo, but also to make possible bett=
er off-chain protocol designs generally.
>
> Among the various advantages previously discussed, the particular use cas=
e benefits from eltoo I want to take advantage of is less interactive payme=
nt channel negotiation.
>
> In talking with people about eltoo this summer, I found most people gener=
ally support adding this as an option to Lightning. The only general concer=
n I heard, if any,  was the vague idea that rebindable transactions could b=
e somehow misused or abused.
>
> I believe when these concerns are made more concrete they can be classifi=
ed and addressed.
>
> I don't find too compelling the potential problem of a 'bad wallet design=
er', 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 sig=
ning 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 scr=
ipt 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 i=
s enough to justify the downsides of chaperone signatures. One additional d=
ownside 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 m=
uch less intrusive and easier to maintain.
>
>> 3.  The same for output tagging / explicit opt-in. What are the advantag=
es 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 gaine=
d 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 a=
nd output tagging should become part of the discussion of security alternat=
ives, but not part of the initial specification.
>
> I understand the desire to be conservative with protocol changes that cou=
ld be misused. However, with just taproot and taproot public key types the =
anyprevout functionality is already very opt-in and not something that migh=
t accidentally get used. Belt-and-suspender protections like chaperone sign=
atures and tagged outputs have their own impacts on code complexity, on-cha=
in 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 saf=
ety into the consensus layer of bitcoin. Anywhere we can make core code sim=
pler, 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