+Return-Path: <jl2012@xbt.hk>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 719F9E7A

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 21 Dec 2018 15:37:25 +0000 (UTC)

+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6

+Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB9AD177

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 21 Dec 2018 15:37:24 +0000 (UTC)

+ARC-Seal: i=1; a=rsa-sha256; t=1545406632; cv=none; d=zoho.com; s=zohoarc;

+ b=jvW2ni5BfSCvlYxacasyT7g+cIGHBFCboKDt6cyniP/9jgsNOAVQYYETT8ry12OjJvHcIRTgApVe6xZvDagXIgTnmGXKKBV1FjdUPKGWtT/belbZ1r+D5c5SU1fyNu/VjrDaTU3oR4v0Bc9U/EXfpy5c+vRPagHopDZWTgXgGlo=

+ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;

+ s=zohoarc; t=1545406632;

+ h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;

+ bh=Z7ZmYzRIH7rN64Vktjyq+kC/C8q33ymPoNw1vh6y9OY=;

+ b=ZBZIcmGCaDe30EdNUVzQPPmt2rRWZPXDciTPbg9/lvVaV08kw7ki4awn8QEEZH56zYdI6gMwfTg5yfBzcfzZJGFfaHbQ6z4ECmIU7wiKTgiYyniHm1InVYHA9F+r5sDfzNST8K8srqDCU4bKM2ma5KxcTI9VxkLH6A0qOdhfCUc=

+ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;

+ spf=pass smtp.mailfrom=jl2012@xbt.hk;

+ dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>

+Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])

+ by mx.zohomail.com with SMTPS id 1545406631564256.77185132031;

+ Fri, 21 Dec 2018 07:37:11 -0800 (PST)

+Content-Type: text/plain;

+ charset=utf-8

+Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))

+From: Johnson Lau <jl2012@xbt.hk>

+In-Reply-To: <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>

+Date: Fri, 21 Dec 2018 23:37:05 +0800

+Content-Transfer-Encoding: quoted-printable

+Message-Id: <34B38940-524D-42B9-8A67-6A62DCE04665@xbt.hk>

+References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>

+ <8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+X-Mailer: Apple Mail (2.3445.100.39)

+X-ZohoMailClient: External

+X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE

+ 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: Fri, 21 Dec 2018 23:30:36 +0000

+Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>

+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 <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Fri, 21 Dec 2018 15:37:25 -0000

+

+

+

+> On 21 Dec 2018, at 7:40 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

+>=20

+> Good morning Johnson,

+>=20

+>> The proposed solution is that an output must be =E2=80=9Ctagged=E2=80=9D=

+ for it to be spendable with NOINPUT, and the =E2=80=9Ctag=E2=80=9D must =

+be made explicitly by the payer. There are 2 possible ways to do the =

+tagging:

+>=20

+> First off, this is a very good idea I think.

+>=20

+>=20

+>> While this seems fully compatible with eltoo, is there any other =

+proposals require NOINPUT, and is adversely affected by either way of =

+tagging?

+>=20

+>=20

+> It prevents use of SIGHASH_NOINPUT to support walletless offchain =

+protocols.

+> =

+https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.ht=

+ml

+> =

+https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015926.ht=

+ml

+>=20

+> In brief, this idea of "walletless offchain software" is motivated by =

+the fact, that various onchain wallets exist with many features.

+> For instance, privacy-enhancement as in Samourai/Wasabi/etc.

+> And so on.

+> There are requests to include such features in e.g. Lightning =

+software, for example: =

+https://github.com/ElementsProject/lightning/issues/2105

+> But it is enough of a challenge to implement Lightning, without the =

+additional burden of implementing nice onchain features like coin =

+control and change labelling.

+>=20

+> It would be best if we can retain features from an onchain wallet, =

+while using our coin on an offchain system.

+> Further, it would allow onchain wallet developers to focus and gain =

+expertise on onchain wallet features, and, vice versa, for offchain =

+walletless software developers to focus on offchain software features.

+>=20

+> The core idea comes from the way that offchain systems need to be set =

+up:

+>=20

+> 1. First we agree on a (currently unconfirmed) txid and output number =

+on which to anchor our offchain system (the funding transaction).

+> 2. Then we sign a backout transaction (the initial commitment =

+transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, =

+or the initial kickoff-settlement transactions for =

+Decker-Russell-Osuntokun) spending the agreed TXO, to return the money =

+back to the owner(s) in case some participant aborts the setting up of =

+the offchain system.

+> 3. Then we sign and broadcast the funding transaction.

+>=20

+> Unfortunately, the typical onchain wallet has a very simple and atomic =

+(uncuttable) process for making transactions:

+>=20

+> 1. Make, sign, and broadcast transaction with an output paying to the =

+desired address.

+>=20

+> Thus a typical onchain wallet cannot be used to set up a funding =

+transaction for an offchain system.

+>=20

+> Now suppose we take advantage of `SIGHASH_NOINPUT`, and modify our =

+offchain system setup as below:

+>=20

+> 1. First we agree on a N-of-N pubkey on which to anchor our offchain =

+system (the funding address).

+> 2. Then we sign (with SIGHASH_NOINPUT) a backout transaction (the =

+initial commitment transactions under Poon-Dryja, or the timelock =

+branches for CoinSwapCS, or the initial kickoff-settlement transactions =

+for Decker-Russell-Osuntokun), spending the agreed funding address, to =

+return the money back to the owner(s) in case some participant aborts =

+the setting up of the offchain system.

+> 3. Make, sign, and broadcast transaction with an output paying to the =

+funding address. This step can be done by any typical onchain wallet.

+>=20

+> Note that only the starting backout transaction is *required* to sign =

+with `SIGHASH_NOINPUT`.

+> For instance, a Poon-Dryja channel may sign succeeding commitment =

+transactions with `SIGHASH_ALL`.

+> Finally, only in case of disaster (some participant aborts before the =

+offchain system is set up) is the `SIGHASH_NOINPUT` backoff transaction =

+broadcasted.

+> A "normal close" of the offchain system can be signed with typical =

+`SIGHASH_ALL` for no fungibility problems.

+>=20

+> With this, an offchain system need not require its implementing =

+software to implement its own wallet.

+> Further, onchain wallets can directly put its funds into an offchain =

+system, without requiring an onchain transfer to an offchain software =

+wallet.

+>=20

+> This can be helpful when building overall software.

+> We might take any commodity onchain wallet and any commodity offchain =

+software, and we can integrate them easily to create a seamless wallet =

+experience that allows spending and receiving onchain and offchain.

+> Further, improvements in one software component do not require =

+re-building of the other software component.

+>=20

+> --

+>=20

+> That said:

+>=20

+> 1. For Lightning and similar systems, the fact that the Lightning =

+node will give you an address that, when paid using any commodity =

+onchain wallet, opens a channel, means that people will make wrong =

+assumptions.

+> In particular, they are likely to assume that address reuse is safe =

+and will attempt to "refill" their channel by paying to the same address =

+again in the future.

+> =46rom this alone, we can immediately see that this idea is =

+pointless.

+> 2. Dual-funding, which for some reason is asked for as a feature, =

+cannot be done with this anyway.

+> 3. It may be better to provide some standard way of signing =

+transactions without broadcasting them.

+> This would still allow similar separation of concerns between =

+onchain and offchain software components.

+>=20

+> So output tagging still seems fine to me, even if this particular use =

+cannot be supported.

+>=20

+> Regards,

+> ZmnSCPxj

+>=20

+>=20

+

+Generally speaking, I think walletless protocol is needed only when you =

+want to rely a third party to open a offchain smart contract. It could =

+be coinswap, eltoo, or anything similar.

+

+However, since NOINPUT still commits to the input value, if the third =

+party paid an unexpected value, even off by 1 satoshi, the smart =

+contract is toast. It is not uncommon as some exchanges would deduct =

+fees from withdrawal amount. Since we don=E2=80=99t have a social norm =

+to require the payer to always pay the exact requested amount, the =

+exchange might not be liable for the loss.

+

+It is of course possible to have a NOINPUT_NOAMOUNT, but I can=E2=80=99t =

+see any chance for this being accepted.

+

+So, unless the payer is liable for paying a wrong amount, walletless =

+contract opening is unreliable.

+

+Johnson=

+

+