path: root/d8/4eb96d9fe4df810213c1e0fb74ce7e1f8ccad9

Return-Path: <chris@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CEBC1762
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 15:15:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com
	[209.85.160.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 669538AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 15:15:09 +0000 (UTC)
Received: by mail-qt1-f172.google.com with SMTP id d16so1455640qtq.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 01 Oct 2019 08:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=suredbits-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=HyCp+2/1v7RFc9xeckQzqSkvyIV9VewCqV9LYPK7Gd8=;
	b=K8bcfIPODCTH1NHMSIJmKC0vXKUMZk3OMABxEu8qIlK3RMRudYuyHoBd30jFXtA5gI
	rY4Kf45JIZocoKEAWrb4cM3TijbY87sIaBxE/zngkMXqUfeG2VqFnV+S2YewATD/DyKW
	JW4PQRwk6DUYrb+ohkZMoF68VnrJCiQoB/hIiMTnk1k8xqiD9HA7Bz8eZsbCwzIzqgBV
	M5oRMDyiJAbPBxWe4MS2fHKDIFJeMuODW7jtkvvF97BuA67dCkqB+L2bsbdQMd/H6ahr
	Fbh/+BO86/zutpeYKhH32K8tI1OoCgzym2rlGyFvaP8+XMJMiOisdiTraF0YNKPbtpi8
	s1rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=HyCp+2/1v7RFc9xeckQzqSkvyIV9VewCqV9LYPK7Gd8=;
	b=JF8f5744PgriofloJXOY0zZOkpPkbGwqKVBzKGjpjYLm25UqhFVGIg32+hHJgm+mha
	AGyEOT3XTSHnNol/DrYddFPeGhNZqB+lQl5yekADiWzxdS1tDrca36XJREXfq0qY4kJK
	GdLx+tEAsbkYU99LMGOxQSzxR7ZNTfdlQ5R58VcA6+eZv88qzZAF30deI9QT+S7szZjs
	TjjiwuRc7bl8EY3l3DbKT7dkNcNZMaNgRFqDXBPu8q2ocVJQKDkQLGyS3T/E06HPhQTc
	afOGbb8FisqBl4wEOb8f+l8LzY4hKiX20U7s/mr64miT9lttHlcovjkQG1tqXnoD42SE
	uMDQ==
X-Gm-Message-State: APjAAAUlT/H80EoaOB9+tGEXE509GsYnRGIQe8yZUfzN0S2XQptygbbF
	q6AzmjHAWUG8eBWsKn9J7Ol6jp7C8tcyDdmRuF0Tdg==
X-Google-Smtp-Source: APXvYqzNnrKoKzaHmzTlKEuTx+h4G3FXm7baen7kzwlveQkfcReCoI1l05GXiK39dmXiClsTQcI5dxoZNJF7DhZWom8=
X-Received: by 2002:ac8:2a75:: with SMTP id l50mr31640488qtl.137.1569942908270;
	Tue, 01 Oct 2019 08:15:08 -0700 (PDT)
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: Chris Stewart <chris@suredbits.com>
Date: Tue, 1 Oct 2019 10:14:56 -0500
Message-ID: <CAFQwNuxRcwOh9AUWXMonDM=7AgiHMym-TtuaHS_-6RFKcnNgZQ@mail.gmail.com>
To: Richard Myers <rich@gotenna.com>
Content-Type: multipart/alternative; boundary="0000000000005d8df60593dad1a7"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DOS_RCVD_IP_TWICE_B, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 01 Oct 2019 16:10:25 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 15:15:12 -0000

--0000000000005d8df60593dad1a7
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005d8df60593dad1a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; I don&#39;t find too compelling the potential pr=
oblem of a &#39;bad wallet=20
designer&#39;, whether lazy or dogmatic, misusing noinput. I think there ar=
e
 simpler ways to cut corners and there will always be plenty of good=20
wallet options people can choose.</div><div><br></div><div>In my original p=
ost, the business that I am talking about don&#39;t use &quot;off the shelf=
&quot; wallet options. It isn&#39;t a &quot;let&#39;s switch from wallet A =
to wallet B&quot; kind of situation. Usually this involves design from grou=
nd up with security considerations that businesses of scale need to conside=
r (signing procedures and key handling being the most important!). <br></di=
v><div><br></div><div>&gt;Because scripts signed with no_input signatures a=
re only really=20
exchanged and used for off-chain negotiations, very few should ever=20
appear on chain. Those that do should represent non-cooperative=20
situations that involve signing parties who know not to reuse or share=20
scripts with these public keys again. No third party has any reason to=20
spend value to a multisignature script they don&#39;t control, whether or=
=20
not a no_input signature exists for it.</div><div><br></div><div>Just becau=
se some one is your friend today, doesn&#39;t mean they aren&#39;t necessar=
ily your adversary tomorrow. I don&#39;t think a signature being onchain re=
ally matters, as you have to give it to your counterparty regardless. How d=
o you know your counterparty won&#39;t replay that SIGHASH_NOINPUT signatur=
e later? Offchain protocols shouldn&#39;t rely on &quot;good-will&quot; for=
 their counter parties for security. <br></div><div><br></div><div>&gt;As I=
 mentioned before, I don&#39;t think the lazy wallet designer advantage=20
is enough to justify the downsides of chaperone signatures. One=20
additional downside is the additional code complexity required to flag=20
whether or not a chaperone output is included. By comparison, the code=20
changes for creating a no_input digest that skips the prevout and=20
prevscript parts of a tx is much less intrusive and easier to maintain.</di=
v><div><br></div><div>&gt;<span class=3D"gmail-im"></span>I want to second =
this. The most expensive part of wallet design is<br>
engineering time. Writing code that uses a new sighash or a custom<br>
script with a OP_CODE is a very large barrier to use. How many wallets<br>
support multisig or RBF? How much BTC has been stolen over the entire<br>
history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE<br>
vs ECDSA nonce reuse</div><div><br></div><div>I actually think lazy wallet =
designer is a really compelling reason to fix footguns in the bitcoin proto=
col. Mt Gox is allegedly a product of lazy wallet design. Now we have non-m=
alleable transactions in the form of segwit (yay!) that prevent this exploi=
t. 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 wa=
s offering an alternative that circumvents the vulnerability all together. =
<br></div><div><br></div><div>Ethan made a great point about SIGHASH_NONE o=
r SIGHASH_SINGLE -- which have virtually no use AFAIK -- vs the ECDSA nonce=
 reuse which is used in nearly every transaction. The feature -- ECDSA in t=
his case -- was managed to be done wrong by wallet developers causing fund =
loss. Unfortunately we can&#39;t protect against this type of bug in the pr=
otocol.<br></div><div><br></div><div>If things aren&#39;t used -- such as S=
IGHASH_NONE or SIGHASH_SINGLE -- it doesn&#39;t matter if they are secure o=
r insecure. I&#39;m hopefully that offchain protocols will achieve wide ado=
ption, and I would hate to see money lost because of this. Even though they=
 aren&#39;t used, in my OP I do advocate for fixing these.<br></div><div><b=
r></div><div>&gt; understand the desire to be conservative with protocol ch=
anges that=20
could be misused. However, with just taproot and taproot public key=20
types the anyprevout functionality is already very opt-in and not=20
something that might accidentally get used. Belt-and-suspender=20
protections like chaperone signatures and tagged outputs have their own=20
impacts on code complexity, on-chain transaction sizes and transaction=20
anonymity that also must be considered.</div><div><br></div><div>I&#39;m ma=
king 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 s=
upport this. I&#39;m hoping the &quot;lazy wallet designers&quot; -- or per=
haps people that don&#39;t follow bitcoin protocol development as rabidly a=
s us :-) -- can see that nuance. <br></div><div><br></div><div>-Chris<br></=
div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 1, 2019 at 8:36 AM Richard My=
ers &lt;<a href=3D"mailto:rich@gotenna.com">rich@gotenna.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div dir=3D"auto">Thanks=C2=A0Christian for pulling together this concise=
 summary.</div><div dir=3D"auto"><br><div dir=3D"auto"><div dir=3D"auto"><d=
iv class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
1.=C2=A0 General agreement on the usefulness of noinput / anyprevoutanyscri=
pt /<br>
=C2=A0 =C2=A0 anyprevout.=C2=A0<br></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto" style=3D"font-famil=
y:sans-serif">I certainly support the unification and adoption of the sigha=
sh_noinput and anyprevoutput* proposals to enable eltoo, but also to make p=
ossible better off-chain protocol designs generally.=C2=A0</div><div dir=3D=
"auto" style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=
=3D"font-family:sans-serif">Among the various advantages previously discuss=
ed, the particular use case benefits from eltoo I want to take advantage of=
 is less interactive payment channel negotiation.</div><div dir=3D"auto" st=
yle=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-fa=
mily:sans-serif">In talking with people about eltoo this summer, I found mo=
st people generally support adding this as an option to Lightning. The only=
 general concern I heard, if any,=C2=A0 was the vague idea that rebindable =
transactions could be somehow misused or abused.</div><div dir=3D"auto" sty=
le=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-fam=
ily:sans-serif">I believe when these concerns are made more concrete they c=
an be classified and addressed.</div><div dir=3D"auto" style=3D"font-family=
:sans-serif"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif">I=
 don&#39;t find too compelling the potential problem of a &#39;bad wallet d=
esigner&#39;, 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.</div><div dir=3D"auto" style=3D"font-family:san=
s-serif"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif">Becau=
se scripts signed with no_input signatures are only really exchanged and us=
ed for off-chain negotiations, very few should ever appear on chain. Those =
that do should represent non-cooperative situations that involve signing pa=
rties 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 the=
y don&#39;t control, whether or not a no_input signature exists for it.</di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto"><di=
v class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
2.=C2=A0 Is there strong support or opposition to the chaperone signatures<=
br>
=C2=A0 =C2=A0 introduced in anyprevout / anyprevoutanyscript? I think it&#3=
9;d be best to<br>
=C2=A0 =C2=A0 formulate a concrete set of pros and contras, rather than tal=
k about<br>
=C2=A0 =C2=A0 abstract dangers or advantages.<br></blockquote></div></div><=
/div><div dir=3D"auto"><br></div><div>As I mentioned before, I don&#39;t th=
ink the lazy wallet designer advantage is enough to justify the downsides o=
f chaperone signatures. One additional downside is the additional code comp=
lexity required to flag whether or not a chaperone output is included. By c=
omparison, the code changes for creating a no_input digest that skips the p=
revout and prevscript parts of a tx is much less intrusive and easier to ma=
intain.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto=
"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
3.=C2=A0 The same for output tagging / explicit opt-in. What are the advant=
ages and<br>
=C2=A0 =C2=A0 disadvantages?<br></blockquote></div></div></div><div dir=3D"=
auto"><br></div><div>I see the point ZmnSCPxj makes about tagged outputs ne=
gatively impacting the anonymity set of taproot transactions. The suggested=
 work around would impose a cost to unilateral closes of an additional tran=
slation transaction and not using the work around would cause a hit to anon=
ymity for off-chain script users. I feel both costs are too high relative t=
o the benefit gained of preventing sloppy reuse of public keys.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto"><div class=3D"gma=
il_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4.=C2=A0 Shall we merge BIP-118 and bip-anyprevout. This would likely reduc=
e the<br>
=C2=A0 =C2=A0 confusion and make for simpler discussions in the end.</block=
quote><div><br></div><div>I believe they should be merged. I also think bot=
h chaperone signatures and output tagging should become part of the discuss=
ion of security alternatives, but not part of the initial specification.</d=
iv><div><br></div><div>I understand the desire to be conservative with prot=
ocol changes that could be misused. However, with just taproot and taproot =
public key types the anyprevout functionality is already very opt-in and no=
t something that might accidentally get used. Belt-and-suspender protection=
s like chaperone signatures and tagged outputs have their own impacts on co=
de complexity, on-chain transaction sizes and transaction anonymity that al=
so must be considered.</div><div><br></div><div>I believe efforts like desc=
riptors=C2=A0will help people follow best practices when working with compl=
ex scripts without pushing extra complexity for safety into the consensus l=
ayer of bitcoin. Anywhere we can make core code simpler, and handle foot-gu=
ns in higher level non-consensus code, the better.=C2=A0</div><div><br></di=
v><div>_______________________________________________<br></div></div></div=
></div><div dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote" dir=
=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" rel=3D"noreferre=
r noreferrer noreferrer noreferrer" target=3D"_blank">Lightning-dev@lists.l=
inuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"=
_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a=
><br>
</blockquote></div></div></div></div>
</div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--0000000000005d8df60593dad1a7--