From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 561D8AA5 for ; Sat, 25 May 2019 03:56:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9D2AA9 for ; Sat, 25 May 2019 03:56:30 +0000 (UTC) Date: Sat, 25 May 2019 03:56:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1558756588; bh=jEb/SIEZ523lLeXWIyOcRlIWDVITjfO4/nSgy1intlA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=E4O1vvlkfe5AwpdA0qMtn4jDSkW8LVCFTq4gWZwAZ4g+XhQh/4TokxeOFaavUDLui znaR9RqIf+F6mwQ2sSRycsY+6jHtmGOeeHjuKMOQARtthhVEkQzaZpLu6MTDfls7/q FImwrGLVcyjgqt+cdod7Qsrybkidm3CqZId6toBE= To: Jeremy From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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, 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 X-Mailman-Approved-At: Sat, 25 May 2019 12:05:39 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2019 03:56:32 -0000 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 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?