Date: Sat, 25 May 2019 03:56:22 +0000
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <NtcMB87WFBKpIzRKHh5bbEeBFGITr2k0qAgmrSE97X30gYJI2RRldrNdeL8X3e50N9N-m6cbuPistWniu3gadi3LuF7oYLltuINj2heepVw=@protonmail.com>
In-Reply-To: <CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@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>
	<vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
	<CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@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,

I believe I have caught the general point.
Indeed, I agree that this is useful, but it is *not* useful for these cases=
:

1.  CoinJoin - the initial funding transaction must be signed by the partic=
ipants anyway after checking that the output is correct.
    Further any spend that is not a signature spend is going to defeat the =
purpose of CoinJoin trying to be private by imitating "typical" spends: if =
`OP_CHECKOUTPUTSHASHVERIFY` path is used, you have just lost the CoinJoin p=
rivacy by reducing anonymity set.
2.  Channel Factories - the initial funding transaction must be signed by t=
he participants anyway after each initial sub-channel initial commitment / =
initial update+state transaction is signed.

In both above cases, the issue of users dropping out during the step of sig=
ning the initial funding transaction is unavoidable even with `OP_CHECKOUTP=
UTSHASHVERIFY`.

For congestion control, and for general "I promise to set this up later" as=
 in c*stodial-service-directly-to-channel etc., I already agree this is use=
ful.

My objection lies *only* with the above two cases, wherein `OP_CHECKOUTPUTS=
HASHVERIFY` does not really improve things, as you *still* need to coordina=
te multiple signers anyway.

You have convinced me already that the other cases are good example usages =
of this opcode.

Regards,
ZmnSCPxj


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 Saturday, May 25, 2019 5:15 AM, Jeremy <jlrubin@mit.edu> wrote:

> ZmnSCIPxj,
>
> I think you're missing the general point, so I'm just going to respond to=
 one point to see if that helps your understanding of why OP_COSHV is bette=
r than just pre-signed.
>
> The reason why MuSig and other distributed signing solutions are not acce=
ptable for this case is they all require interaction for guarantee of payou=
t.
>
> In contrast, I can use a OP_COSHV Taproot key to request a withdrawal fro=
m an exchange which some time later pays out to a lot of people, rather tha=
n having to withdraw multiple times and then pay. The exchange doesn't have=
 to know this is what I did. They also don't have to tell me the exact inpu=
ts they'll spend to me or if I'm batched or not (batching largely incompati=
ble with pre-signing unless anyprevout)
>
> The exchange can take my withdrawal request and aggregate it to other pay=
ees into a tree as well, without requiring permission from the recipients.
>
> They can also -- without my permission -- make the payment not directly i=
nto me, but into a payment channel between me and the exchange, allowing me=
 to undo the withdrawal by routing money back to the exchange over lightnin=
g.
>
> The exchange can take some inbound payments to their hot wallet and move =
them into cold storage with pre-set spending paths. They don't need to use =
ephemeral keys (how was that entropy created?) nor do they need to bring on=
 their cold storage keys to pre-sign the spending paths.
>
> None of this really works well with just pre-signing because you need to =
ask for permission first in order to do these operations, but with OP_COSHV=
 you can, just as the payer without talking to anyone else, or just as the =
recipient commit your funds to a complex txn structure.
>
> Lastly, think about this in terms of DoS. You have a set of N users who r=
equest a payment. You build the tree, collect signatures, and then at the L=
AST step of building the tree, one user drops out. You restart, excluding t=
hat user. Then a different user drops. Meanwhile you've had to keep your fu=
nds locked up to guarantee those inputs for the txn when it finalizes.
>
> In contrast, once you receive the requests with OP_COSHV, there's nothing=
 else to do. You just issue the transaction and move on.
>
> Does that make sense as to why a user would prefer this, even if there is=
 an emulation with pre-signed txns?