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 66C5A3DC4 for ; Thu, 31 Jan 2019 06:04:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAF7DA8 for ; Thu, 31 Jan 2019 06:04:15 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1gp5SM-0008NE-F0; Thu, 31 Jan 2019 16:04:12 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 31 Jan 2019 16:04:05 +1000 Date: Thu, 31 Jan 2019 16:04:05 +1000 From: Anthony Towns To: ZmnSCPxj , Bitcoin Protocol Discussion Message-ID: <20190131060405.e7hefirxcars4bpu@erisian.com.au> References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com> <34B38940-524D-42B9-8A67-6A62DCE04665@xbt.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 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: Thu, 31 Jan 2019 17:00:54 +0000 Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging 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: Thu, 31 Jan 2019 06:04:16 -0000 On Mon, Dec 24, 2018 at 11:47:38AM +0000, ZmnSCPxj via bitcoin-dev wrote: > A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI. Seems like PSBT would be a sufficient protocol: 0) lightning node generates a PSBT for a new channel, with no inputs and a single output of the 2-of-2 address 1) wallet funds the PSBT but doesn't sign it, adding a change address if necessary, and could combine with other tx's bustapay style 2) lightning determines txid from PSBT, and creates update/settlement tx's for funding tx so funds can be recovered 3) wallet signs and publishes the PSBT 4) lightning sees tx on chain and channel is open That's a bit more convoluted than "(0) lightning generates an address and value, and creates NOINPUT update/settlement tx's for that address/value; (1) wallet funds address to exactly that value; (2) lightning monitors blockchain for payment to that address" of course. But it avoids letting users get into the habit of passing NOINPUT addresses around, or the risk of a user typo'ing the value and losing money immediately, and it has the benefit that the wallet can tweak the value if (eg) that avoids a change address or enhances privacy (iirc, c-lightning tweaks payment values for that reason). If the channel's closed cooperatively, it also avoids ever needing to publish a NOINPUT sig (or NOINPUT tagged output). Does that seem a fair trade off? Cheers, aj