MIME-Version: 1.0
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
In-Reply-To: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 18 Dec 2018 00:48:15 +0900
Message-ID: <CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Precedence: list

Hi Johnson,

The design considerations here seem similar to the ML discussion of
whether Graftroot should be optional [1].

>While this seems fully compatible with eltoo, is there any other proposals=
 require NOINPUT, and is adversely affected by either way of tagging?

As far as I can tell it should be compatible with Statechains [2],
since it pretty much mirrors Eltoo in setup.

My understanding is somewhat lacking, so perhaps I am missing the
mark, but it is not completely clear to me how this affects
fungibility if taproot gets added and the setup and trigger tx for
Eltoo get combined into a single transaction. Would the NOINPUT
spending condition be hidden inside the taproot commitment?

Cheers,
Ruben Somsen

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006=
.html
[2]  https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_state=
chains_offchain_transfer_of/

On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> NOINPUT is very powerful, but the tradeoff is the risks of signature repl=
ay. While the key holders are expected not to reuse key pair, little could =
be done to stop payers to reuse an address. Unfortunately, key-pair reuse h=
as been a social and technical norm since the creation of Bitcoin (the firs=
t tx made in block 170 reused the previous public key). I don=E2=80=99t see=
 any hope to change this norm any time soon, if possible at all.
>
> As the people who are designing the layer-1 protocol, we could always bla=
me the payer and/or payee for their stupidity, just like those people laugh=
ed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The e=
xisting bitcoin script language is so restrictive. It disallows many useful=
 smart contracts, but at the same time prevented many dumb contracts. After=
 all, =E2=80=9Csmart=E2=80=9D and =E2=80=9Cdumb=E2=80=9D are non-technical =
judgement. The DAO contract has always been faithfully executed. It=E2=80=
=99s dumb only for those invested in the project. For me, it was just a com=
edy show.
>
> So NOINPUT brings us more smart contract capacity, and at the same time w=
e are one step closer to dumb contracts. The target is to find a design tha=
t exactly enables the smart contracts we want, while minimising the risks o=
f misuse.
>
> The risk I am trying to mitigate is a payer mistakenly pay to a previous =
address with the exactly same amount, and the previous UTXO has been spent =
using NOINPUT. Accidental double payment is not uncommon. Even if the payee=
 was honest and willing to refund, the money might have been spent with a r=
eplayed NOINPUT signature. Once people lost a significant amount of money t=
his way, payers (mostly exchanges) may refuse to send money to anything oth=
er than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without =
possibility of NOINPUT)
>
> The proposed solution is that an output must be =E2=80=9Ctagged=E2=80=9D =
for it to be spendable with NOINPUT, and the =E2=80=9Ctag=E2=80=9D must be =
made explicitly by the payer. There are 2 possible ways to do the tagging:
>
> 1. A certain bit in the tx version must be set
> 2. A certain bit in the scriptPubKey must be set
>
> I will analyse the pros and cons later.
>
> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and s=
hould not be tagged. This makes it indistinguishable from normal 1-of-1 utx=
o. The trigger tx, which spends the setup utxo, should be tagged, so the up=
date txs could spend the trigger utxo with NOINPUT. Similarly, all update t=
xs should be tagged, so they could be spent by other update txs and settlem=
ent tx with NOINPUT. As the final destination, there is no need to tag in t=
he settlement tx.
>
> In payer=E2=80=99s perspective, tagging means =E2=80=9CI believe this add=
ress is for one-time-use only=E2=80=9D Since we can=E2=80=99t control how o=
ther people manage their addresses, we should never do tagging when paying =
to other people.
>
> I mentioned 2 ways of tagging, and they have pros and cons. First of all,=
 tagging in either way should not complicate the eltoo protocol in anyway, =
nor bring extra block space overhead.
>
> A clear advantage of tagging with scriptPubKey is we could tag on a per-o=
utput basis. However, scriptPubKey tagging is only possible with native-seg=
wit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Other=
wise, *all* P2SH addresses would become =E2=80=9Crisky=E2=80=9D for payers)=
 This should be ok for eltoo, since it has no reason to use P2SH-segwit in =
intermediate txs, which is more expensive.
>
> Another problem with scriptPubKey tagging is all the existing bech32 impl=
ementations will not understand the special tag, and will pay to a tagged a=
ddress as usual. An upgrade would be needed for them to refuse sending to t=
agged addresses by default.
>
> On the other hand, tagging with tx version will also protect P2SH-segwit,=
 and all existing wallets are protected by default. However, it is somewhat=
 a layer violation and you could only tag all or none output in the same tx=
. Also, as Bitcoin Core has just removed the tx version from the UTXO datab=
ase, adding it back could be a little bit annoying, but doable.
>
> There is an extension to the version tagging, which could make NOINPUT ev=
en safer. In addition to tagging requirement, NOINPUT will also sign the ve=
rsion of the previous tx. If the wallet always uses a randomised tx version=
, it makes accidental replay very unlikely. However, that will burn a few m=
ore bits in the tx version field.
>
> While this seems fully compatible with eltoo, is there any other proposal=
s require NOINPUT, and is adversely affected by either way of tagging?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev