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 31254E46 for ; Mon, 24 Dec 2018 11:47:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22A71D3 for ; Mon, 24 Dec 2018 11:47:43 +0000 (UTC) Date: Mon, 24 Dec 2018 11:47:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1545652060; bh=8miS8Yd9WGqd4iKxu1msm0Q5tnCshPfErBcmICCm/wk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=tj58X/j/7O648NBYMRBLSMvat6AeFYFnHUX8QpAhEZp6faVEgZOMXlbitTS24dQxT S6n43pIdV+xyGnzS7l9KCZiLEgkrQRI2XwJoLXIMjILdZNLn0GzZHrW8baxVO/t7IU uoFmQUHZELXElpmub+HTwUvbD2MFlDW1mIYZlYtI= To: Johnson Lau From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com> <34B38940-524D-42B9-8A67-6A62DCE04665@xbt.hk> 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: Mon, 24 Dec 2018 14:47:55 +0000 Cc: bitcoin-dev 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: Mon, 24 Dec 2018 11:47:45 -0000 Good morning Johnson, Indeed, manual operation is risky. However the intent is to reduce the requirements on commodity wallets in or= der to integrate them into a combined onchain and offchain UI. A boutique protocol would reduce the number of existing onchain wallets tha= t could be integrated in such UI. If we could make walletless offchain software in such method, *any* existin= g wallet with an API to programmatically send arbitrary amount to arbitrary= address can be integrated into such UI. This could include hardware wallets. 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 Sunday, December 23, 2018 12:56 AM, Johnson Lau wrote: > > On 22 Dec 2018, at 10:25 PM, ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > Good morning Johnson, > > > > > Generally speaking, I think walletless protocol is needed only when y= ou want to rely a third party to open a offchain smart contract. It could b= e coinswap, eltoo, or anything similar. > > > > I think a third party would be pointless in general, but then I am stro= ngly against custodiality. > > The idea is that you have some kind of hardware wallet or similar "some= what cold" storage that you control yourself, and crate channels for your h= ot offchain Lightning wallet, without adding more transactions from your so= mewhat-cold storage to your hot offchain Lightning wallet on the blockchain= . > > Then you could feed a set of addresses to the hot offchain wallet (addr= esses your somewhat-cold storage controls) so that when channels are closed= , the funds go to your somwhat-cold storage. > > I also doubt that any custodial service would want to mess around with = deducting funds from what the user input as the desired payment. I have not= seen a custodial service that does so (this is not a scientific study; I r= arely use custodial services); custodial services will deduct more from you= r balance than what you send, but will not modify what you send, and will p= revent you from sending more than your balance minus the fees they charge f= or sending onchain. > > Even today, custodial services deducting from your sent value (rather t= han the balance remaining after you send) would be problematic when interac= ting with merchants (or their payment processors) accepting onchain payment= s; the merchant would refuse to service a lower value than what it charges = and it may be very technically difficult to recover such funds from the mer= chant. > > I expect such a custodial service would quickly lose users, but the wor= ld surprises me often. > > Regards, > > ZmnSCPxj > > If the users are expected to manually operate a hardware wallet to fund t= he channel, they might do stupid things like using 2 wallets to make 2 txs,= thinking that they could combine the values this way; or =E2=80=9Crefillin= g=E2=80=9D the offchain wallet with the address, as you suggested. While I = appreciate the goal to separate the coin-selecting wallet with the offchain= wallet, I am not sure if we should rely on users to do critical steps like= entering the right value or not reusing the address. Especially, the setup= address should be hidden from user=E2=80=99s view, so only a very few = =E2=80=9Cintelligent advanced users" could try to refill the channel. > > If we don=E2=80=99t rely on the user as the bridge between the hardware w= allet and the offchain wallet, we need a communication protocol between the= m. With such protocol, there is no need to spend the setup TXO with NOINPUT= .