path: root/cc/dd39fae6293dcba4605f340b78da1755dc190a

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D828120F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 13:31:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
	[185.70.40.133])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B21D8B1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 13:31:54 +0000 (UTC)
Date: Tue, 01 Oct 2019 13:31:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1569936710;
	bh=oxcnbxOkYoQRQcplJGG2RDuszfI6gggojYewyBM//WA=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=pEZ6VxCdr7on/G+Uu7qSlHRIsPreOvDrwSnRumI3EzSyFp+0ioHdO1CHWTJGZ1k9b
	cJ9tudrmfq+DO1yqH8ddVoKrsxzrjGgpqFQyzcu4AiWZF9J4OpEmDj6L7s3zttI1aX
	g0A9olbGuBnKUU43En03PUDg/hsU1Vqec4vpuFa8=
To: Chris Stewart <chris@suredbits.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bMt69zMSAH_2zekGjg56k6MWFMwWkjKMdUjqHQ5eN7c5ONixWZ0s2wW4HmILeVjImt6Z2K5fPa6GKGLP_HWThCzFIIu53wvEKTDrGg-YpOQ=@protonmail.com>
In-Reply-To: <CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
References: <87wodp7w9f.fsf@gmail.com>
	<CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM,
	FROM_LOCAL_NOVOWEL, 
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Christian Decker via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-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 13:31:56 -0000

Good morning lists,

Let me summarize concerns brought up:

* Chris concern, is that an ordinary UTXO that is not allocated for `SIGHAS=
H_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 an=
y 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 ou=
tputs, 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 Tapro=
ot 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 comm=
it to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPU=
T` is unuseable to claim it.
* If a UTXO used for an offchain protocol ends up in a cooperative-resoluti=
on 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 specia=
l output used for a Decker-Russell-Osuntokun construction, greatly damaging=
 privacy.
But if this fact is kept secret *unless* the very specific case of unilater=
al 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 introd=
uce another footgun into the bitcoin protocol with address reuse. It's comm=
on practice for bitcoin businesses to re-use addresses. Many exchanges [1] =
reuse addresses for cold storage with very large sums of money that is stor=
ed 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 c=
hanging the hash reference to the previous output, without invalidating the=
 signatures. This allows transactions to be bound to any output that matche=
s 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 st=
orage address with a SIGHASH_NOINPUT signature, that signature can be repla=
yed again and again on the blockchain until their wallet is drained. This m=
ight 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 tran=
saction 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 offcha=
in protocols like Lightning. This gives us the building blocks for enforcin=
g 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 adoptio=
n 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_NOIN=
PUT -- does NOT get mixed up with the first signing path that controls an e=
xchanges onchain funds. If this were to happen, fund lost could occur if th=
e 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 u=
nintentionally 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 possibl=
e 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 transacti=
ons that the input may not bind to. For example an application SHOULD gener=
ate a new key-pair for the application instance using NOINPUT signatures an=
d 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 introdu=
ces more complexity for key management (two keychains).
>
> One (of the few) upsides of the current Lightning penalty mechanism is th=
at fund loss can be contained to balance of the channel. You cannot do some=
thing in the current protocol that will effect your funds outside of that c=
hannel. With SIGHASH_NOINPUT, that property changes.
>
> ### A side note
> In general, i think we should start disallowing uses of the SIGHASH proto=
cols 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 b=
ig one.
>
> [1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
> [2] - https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Sept=
ember/002136.html
> [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/01=
6048.html
>
> On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
>
> > With the recently renewed interest in eltoo, a proof-of-concept impleme=
ntation
> > [1], and the discussions regarding clean abstractions for off-chain pro=
tocols
> > [2,3], I thought it might be time to revisit the `sighash_noinput` prop=
osal
> > (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
> >
> > (sorry for the long e-mail. I wanted to give enough context and describ=
e the
> > various tradeoffs so people don't have to stitch them together from mem=
ory. 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 outpu=
ts, by
> > adding a sighash flag that excludes the output when signing. This allow=
s the
> > transaction to be bound to any output, without needing a new signature,=
 as
> > long as output script and input script are compatible, e.g., the signat=
ure
> > matches the public key specified in the output.
> >
> > BIP-118 is limited to explaining the details of signature verification,=
 and
> > omits anything related to deployment and dependency on other proposals.=
 This
> > was done in order not to depend on bip-taproot which is also in draft-p=
hase
> > currently, and to allow deployment alongside the next version of segwit
> > script. `bip-anyprevout` builds on top of BIP-118, adding integration w=
ith
> > `bip-taproot`, chaperone signatures, limits the use of the sighash flag=
 to
> > script path spends, as well as a new pubkey serialization which uses th=
e first
> > byte to signal opt-in.
> >
> > I'd like to stress that both proposals are complementary and not compet=
ing,
> > which is something that I've heard a couple of times.
> >
> > There remain a couple of unclear points which I hope we can address in =
the
> > coming days, to get this thing moving again, and hopefully get a new to=
ol in
> > our toolbox soon(ish).
> >
> > In the following I will quote a couple of things that were discussed du=
ring
> > the CoreDev meeting earlier this year, but not everybody could join, an=
d it is
> > important that we engage the wider community, to get a better picture, =
and I
> > think not everybody is up-to-date about the current state.
> >
> > ## Dangers of `sighash_noinput`
> >
> > An argument I have heard against noinput is that it is slightly less co=
mplex
> > or compute intensive than `sighash_all` signatures, which may encourage=
 wallet
> > creators to only implement the noinput variant, and use it indiscrimi-
> > nately. This is certainly a good argument, and indeed we have seen at l=
east
> > one developer proposing to use noinput for all transactions to discoura=
ge
> > address reuse.
> >
> > This was also mentioned at CoreDev [6]:
> >
> > > When [...] said he wanted to write a wallet that only used SIGHASH\_N=
OINPUT,
> > > that was pause for concern. Some people might want to use SIGHASH\_NO=
INPUT as a
> > > way to cheapen or reduce the complexity of making a wallet
> > > implementation. SIGHASH\_NOINPUT is from a purely procedural point of=
 view
> > > easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're ha=
shing
> > > less. It's way faster. That concern has been brought to my attention =
and it's
> > > something I can see. Do we want to avoid people being stupid and shoo=
ting
> > > themselves and their customers in the foot? Or do we treat this as a =
special
> > > case where you mark we're aware of how it should be used and we just =
try to
> > > get that awareness out?
> >
> > Another issue that is sometimes brought up is that an external user may
> > attempt to send funds to a script that was really part of a higher-leve=
l
> > protocol. This leads to those funds becoming inaccessible unless you ga=
ther
> > all the participants and sign off on those funds. I don't believe this =
is
> > anything new, and if users really want to shoot themselves in the foot =
and
> > send funds to random addresses they fish out of a blockexplorer there's=
 little
> > we can do. What we could do is make the scripts used internally in our
> > protocols unaddressable (see output tagging below), removing this issue
> > altogether.
> >
> > ## Chaperone signatures
> >
> > Chaperone signatures are signatures that ensure that there is no third-=
party
> > malleability of transactions. The idea is to have an additional signatu=
re,
> > that doesn't use noinput, or any of its variants, and therefore needs t=
o be
> > authored by one of the pubkeys in the output script, i.e., one or more =
of the
> > participants of the contract the transaction belongs to. Concretely in =
eltoo
> > we'd be using a shared key known to all participants in the eltoo insta=
nce, so
> > any participant can sign an update to rebind it to the desired output.
> >
> > Chaperone signatures have a number of downsides however:
> >
> > -   Additional size: both the public key and the signature actually nee=
d to be
> >     stored along with the real noinput signature, resulting in transfer=
,
> >     computational and storage overhead. We can't reuse the same pubkey =
from the
> >     noinput signature since that'd require access to the matching privk=
ey which
> >     is what we want to get rid of using noinput in the first place.
> > -   Protocols can still simply use a globally known privkey, voiding th=
e
> >     benefit of chaperone signatures, since third-parties can sign again=
. I
> >     argue that third-party malleability is a subset of first-party
> >     malleability, and we should protect against first-party malleabilit=
y first
> >     and foremost. My counterparty has the incentive to trick me, a thir=
d-party
> >     may not.
> >
> > On the plus side chaperone signatures certainly address the lazy-wallet=
-dev
> > scenario, and as AJ points out in [bip-anyprevout] we get back the same
> > security guarantees as we had without noinput.
> >
> > From what I remember and the transcript (thanks Kanzure for your awesom=
e work
> > by the way), there was no strong support for chaperone signatures durin=
g the
> > meeting [6], but feedback from people that were not present is needed:
> >
> > > if everyone who wanted to use NOINPUT was convinced there was a probl=
em, then
> > > they would pick the right thing, but clearly people aren't. It's not =
a
> > > foot-gun defense mechanism because it's easily bypassed, and it's eas=
ier to
> > > bypass it than to use it. Whereas for tagged outputs, it's that if yo=
u want
> > > any NOINPUT then you must tag.
> >
> > ## Output tagging
> >
> > One proposal that I found rather fascinating during the discussion in
> > Amsterdam was that we could achieve the same disincentive to use on
> > non-smart-contract cases by simply making the output scripts
> > unaddressable. This can be done by specifying a version of taproot outp=
uts for
> > which the bech32 addressing scheme simply doesn't have a representation=
 [6]:
> >
> > > The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT supp=
orted for
> > > taproot v1 outputs, instead we have a segwit version 16 v16 that supp=
orts
> > > taproot. The reason for v16 is that we redefine bech32 to not cover
> > > v16. There's no addresses for this type of output. If you're an excha=
nge and
> > > receive a bech32 address, you declare it invalid. You make it less us=
er
> > > friendly here; and there shouldn't be an address anyway. You might wa=
nt to see
> > > it on a block explorer, but you don't want to pass it around to anyon=
e.
> >
> > We don't need addresses in our contract constructions because we deal d=
irectly
> > with the scripts. This would also have the desired effect of no allowin=
g
> > generic wallets to send to these addresses, or users accidentally sendi=
ng
> > funds to what was supposed to be a one-off script used internally in th=
e
> > off-chain contract.
> >
> > Notice that this idea was already used by Russell O'Connor when perform=
ing a
> > transaction on elements using his new scripting language simplicity
> > [7]:
> >
> > > For this experimental development, we created an improper segwit vers=
ion,
> > > "version 31" for Simplicity addresses. The payload of this segwit ver=
sion 31
> > > address contains a commitment Merkle root of a Simplicity program to =
control
> > > the UTXO.
> >
> > The concern with output tagging is that it hurts fungibility, marking o=
utputs
> > used in a contract as such and making them identifiable. But maybe it w=
ould be
> > a good idea to create two domains anyway: one for user-addressable
> > destinations which users can use with their general purpose wallets, an=
d one
> > domain for contracts, which users cannot send to directly.
> >
> > This also came up during the CoreDev meeting [ams-coredev]:
> >
> > > these sort of NOINPUT signatures are only things that are within some
> > > application or within some protocol that gets negotiated between part=
icipants,
> > > but they don't cross-independent domains where you see a wallet or a =
protocol
> > > as a kind of domain. You can't tell the difference, is this an addres=
s I can
> > > give to someone else or not? It's all scripts, no real addresses. The=
re are
> > > types of outputs that are completely insecure unconditionally; there =
are
> > > things that are protected and I can give to anyone, you don't want to=
 reuse
> > > it, but there's no security issue from doing so. This is an additiona=
l class
> > > that is secure perfectly but only when used in the right way.
> >
> > ## Open questions
> >
> > The questions that remain to be addressed are the following:
> >
> > 1.  General agreement on the usefulness of noinput / anyprevoutanyscrip=
t /
> >     anyprevout. While at the CoreDev meeting I think everybody agreed t=
hat
> >     these proposals a useful, also beyond eltoo, not everybody could be
> >     there. I'd therefore like to elicit some feedback from the wider co=
mmunity.
> > 2.  Is there strong support or opposition to the chaperone signatures
> >     introduced in anyprevout / anyprevoutanyscript? I think it'd be bes=
t to
> >     formulate a concrete set of pros and contras, rather than talk abou=
t
> >     abstract dangers or advantages.
> > 3.  The same for output tagging / explicit opt-in. What are the advanta=
ges and
> >     disadvantages?
> > 4.  Shall we merge BIP-118 and bip-anyprevout. This would likely reduce=
 the
> >     confusion and make for simpler discussions in the end.
> > 5.  Anything I forgot to mention :-)
> >
> > Cheers,
> > Christian
> >
> > [1] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Sep=
tember/002131.html>
> > [2] <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Septe=
mber/017285.html>
> > [3] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-Aug=
ust/001383.html>
> > [4] <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki>
> > [5] <https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout=
.mediawiki>
> > [6] <http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06=
-noinput-etc/>
> > [7] <https://lists.ozlabs.org/pipermail/simplicity/2019/000018.html>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev