Date: Thu, 23 May 2019 03:45:39 +0000
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
In-Reply-To: <CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
	<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
	<CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
	<CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
	proposal
Precedence: list

Good morning Jeremy,


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Wednesday, May 22, 2019 4:10 PM, Jeremy <jlrubin@mit.edu> wrote:

> > * I do not think CoinJoin is much improved by this opcode.
> > =C2=A0 Typically, you would sign off only if one of the outputs of the =
CoinJoin transaction is yours, and this does not really improve this situat=
ion.
>
> Coinjoin benefits a lot I think.
>
> Coinjoin is improved because you can fit more users into the protocol and=
 create many more outputs at lower cost or include more participants. Ideal=
ly a coinjoin creates a lot of outputs so that the ownership is smeared mor=
e, but this has a cost at the time of the coinjoin.

But the separate outputs still need to be published at some point in the fu=
ture.
Further, ideally CoinJoin should be as indistinguishable from normal transa=
ctions as possible.
(admittedly, the equal-sized outputs often recommended for CoinJoin tend to=
 blatantly signal "this is a CoinJoin!!", but in any case that "should" be =
fixed with some kind of future Confidential Transactions)

>
> Coinjoin is also improved because you don't reveal the outputs created by=
 the coinjoin until some time, perhaps very far in the future, when you nee=
d the coin. In fact, you only need to reveal where you're moving the coins =
to participants in your subtree because participants need only verify their=
 branch.

The same technique of congestion control can still be used with only an "or=
dinary" MuSig of all participant keys on the output of the "funding" transa=
ction, forming a sort of very tiny CoinJoinXT.
This has the advantage that the MuSig is indistinguishable from 1-of-1 spen=
ds, which is important for a privacy technique like CoinJoin.
Even in the future and we have published the output-side transaction of the=
 CoinJoin, the transaction chain *could* be interpreted as "one person cons=
olidated all his coins in an ordinary 1-of-1 UTXO, then spent on several th=
ings at once" whereas use of the `OP_CHECKOUTPUTSHASHVERIFY` is a blatant "=
several people agreed to put in their coins provided these outputs were on =
the second transaction, i.e. some kind of attempt at hiding their coins".

>
> It also makes the protocol more stable with respect to input choice. This=
 is because, similar to how NOINPUT may work, OP_COSHV outputs are spendabl=
e without knowing what the TXID will be. Therefore if someone changes their=
 input or non segwit spend script, it won't break the presigned txns. This =
also means that all the inputs can be ANYONECANPAY, so there is no need to =
reveal your inputs before anyone else.
>
> This culminates in being able to open channels from a coinjoin safely, I =
believe this is difficult/impossible to do currently.

This is already *technically* possible, though no software exists to do so =
(sorry, we have bugs between interop of c-lightning and lnd that take up ou=
r debugging time already, we cannot spare it for this *yet*).

SegWit by itself already allows child transactions to be signed before pare=
nt transactions are signed.
This safety underlies *all* offchain protocols.
See: https://zmnscpxj.github.io/offchain/generalized.html
This is sufficient to ensure that channels can be opened from whatever tran=
sactions you want, though having to interop with other software that *also*=
 has to coordinate with other participants in a different protocol is much =
more difficult than having to interop with other software using the same pr=
otocol.

Finally, `SIGHASH_ANYPREVOUT` can *also* do this, since the txid becomes mo=
oted.
And `SIGHASH_ANYPREVOUT` *also* enables a better offchain update mechanism =
(Decker-Russell-Osuntokun, more commonly known as "eltoo") whereas I am una=
ble to derive a similar offchain update mechanism using `OP_CHECKOUTPUTSHAS=
HVERIFY` (though possibly for lack of trying).

>
> > * Using this for congestion control increases blockchain usage by one T=
XO and one input, ending up with *more* bytes onchain, and a UTXO that will=
 be removed later in (we hope) short time.
> > =C2=A0 I do not know if this is a good idea, to increase congestion by =
making unnecessary intermediate transaction outputs, at times when congesti=
on is a problem.
>
> This is a good idea because it improves QoS for most users.
>
> For receiving money pending spendable but confirmed payment (i.e. certifi=
ed checks) is superior to having unconfirmed funds.
>
> For sending money, being able to clear all liabilities in a single txn de=
creases business exposure to fee variance and confirmation time variance. E=
.g., if I'm doing payroll in Bitcoin I will pay big fines if I am a day lat=
e. If I have 10,000 employees this might be painful if fees are currently u=
p.
>
> It also helps to have a backlog of low priority txns to support the fee m=
arket.
>
> Overall block bandwidth utilization is fairly spikey, so having long term=
 well known outputs that are not time sensitive can be used to better utili=
ze bandwidth.
>
> The total extra bandwidth btw is really small given the expansion factor =
optimizations available.

Okay, you have convinced me regarding this point, at least.

> > * Channel factories created by this opcode do not, by themselves, suppo=
rt updates to the channel structure.
> > =C2=A0 But such simple "close only" channel factories can be done using=
 n-of-n and a pre-signed offchain transaction (especially since the entitie=
s interested in the factory are known and enumerable, and thus can be induc=
ed to sign in order to enter the factory).
>
> I'm not really an expert at Bitcoin Lightning, but this basic mechanism s=
hould work.
> Imagine the script at a leaf node:
>
> Taproot([Alice, Bob], [OP_COSHV <H(H(2 coins to uncooperative script))>]
>
> where uncooperative script is:
>
> Taproot([Alice, Bob], ["1 week" CHECKSEQUENCEVERIFY DROP  OP_COSHV <H(H(P=
ay alice 2 coins))>)
>
> Cooperative closing skips the extra transactions. Updates are signed agai=
nst the uncooperative script with repudation. E.g.:
>
> =C2=A0 =C2=A0 HASH160 <revokehash> EQUAL
> =C2=A0 =C2=A0 IF
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <Bob's pubkey>
> =C2=A0 =C2=A0 ELSE
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "1 week" CHECKSEQUENCEVERIFY DROP
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <Alice's pubkey>
> =C2=A0 =C2=A0 ENDIF
> =C2=A0 =C2=A0 CHECKSIG
>
> It can even be optimized by letting the uncooperative script branches in =
the leaf be blaming Alice or Bob.
>
> Does that not work?

Possibly, but the point is that an n-of-n MuSig will work just as well and =
we would not need to reveal the Taproot key (33 bytes) and the specific scr=
ipt containing the output hash (1+32 bytes) we want, we just have to reveal=
 a single 64-byte signature.

My objection here is simply that n-of-n already exists, it will work alread=
y using that (and it is much more likely to be assured of getting into base=
 layer).

Again, we only need to use SegWit and sign transactions in reverse order to=
 ensure proper operation.
This is already what is done for normal channel opens (the initial commitme=
nt transactions are signed first, then the funding transaction is signed an=
d confirmed onchain).

Regards,
ZmnSCPxj