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 95FE3157B; Tue, 1 Oct 2019 14:27:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0FF56189; Tue, 1 Oct 2019 14:27:57 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id q10so8149789pfl.0; Tue, 01 Oct 2019 07:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ly0SIGZuTJwLSQFEmaopXmbEw0r0Q6KVyRq9bZNDZNQ=; b=vBuhRSa5rrPPUor/DSkZKXFVRn0Dk3E07c7eBIhh9kDv2q9NPiB58OPPO8HajAVVoQ feoAS2F/E93KdPxLJEf5roXdDHg58qOhRwbfovxX6aTAEe63KWgi0wSWJz5KtqgFBTVk y9nNOgE4D7Kx2lvjRUhZmjZxsFnKzBkN7XDTmTdkLXJ9Lsc32nqL1w1OBpVy3+5buGE4 tvSDHnqXigIUzuNkrMVUxM3vFjeKJ0UGeB8DKa8vhb9yFflr8eN5nb8JUbvTfHn1Bnwa 00PM2ui2GP6LnY8bckIjDjglzKXpcx8DaBwSbgcmfP1LqOX4DCJbas7GfvqSXfWdOMp5 o42A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ly0SIGZuTJwLSQFEmaopXmbEw0r0Q6KVyRq9bZNDZNQ=; b=B3oW609EeGJECVWCRv5BTfWpRqrdvGNg1TgTN/S0QlZoxv9mD/v6ZVdunB0wwp7ZaK tFaqPr6hnbWpiocSN9G+9dLrQqY7/5z8BFbBHwFS2CMUmwCjE/3awDNFkJBhYvyl7yWF 5VzkFbV4N6IsCFRHXxxDJnpEZLxnNQ6By0El9ibbBgnLUsxjkTfxrTtJfM2kgdvCY2d+ V7+eG4m2w0CoElONCKsUu1UhWlAQoecuT7DObkwCKfbeSMgDJp4s+QNhSYLzQRbUAhH+ iu16nyxzmxZFwrnCpx1M7RpQQl/p05kpFHMtnncs6ahzfJftf24OEtcnuPzrSVestts5 GhGw== X-Gm-Message-State: APjAAAV88rBu2Jcyyud3e5SvcCn4KN0GxOYqmszOgG+CFZor/TT8N3Fw n7Harf5moY8Rc6yOD8LospFknNQSJEWh3ZOkNms= X-Google-Smtp-Source: APXvYqy6dQuc5TFJ3Op5DuWXZFXNkCN5jrLyCOmn89wBubaPZEYIO2Fvi5sF9ub75xyeBe0LCwkUFSQHz4Uj89aLZyo= X-Received: by 2002:aa7:9dc8:: with SMTP id g8mr19430683pfq.156.1569940077366; Tue, 01 Oct 2019 07:27:57 -0700 (PDT) MIME-Version: 1.0 References: <87wodp7w9f.fsf@gmail.com> In-Reply-To: From: Ethan Heilman Date: Tue, 1 Oct 2019 10:27:21 -0400 Message-ID: To: Richard Myers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, 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 Cc: Bitcoin Protocol Discussion , lightning-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout 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: Tue, 01 Oct 2019 14:27:58 -0000 >I don't find too compelling the potential problem of a 'bad wallet designe= r', whether lazy or dogmatic, misusing noinput. I think there are simpler w= ays to cut corners and there will always be plenty of good wallet options p= eople can choose. I want to second this. The most expensive part of wallet design is engineering time. Writing code that uses a new sighash or a custom script with a OP_CODE is a very large barrier to use. How many wallets support multisig or RBF? How much BTC has been stolen over the entire history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE vs ECDSA nonce reuse? On Tue, Oct 1, 2019 at 9:35 AM Richard Myers wrote: > > Thanks Christian for pulling together this concise summary. > >> 1. General agreement on the usefulness of noinput / anyprevoutanyscript= / >> anyprevout. > > > I certainly support the unification and adoption of the sighash_noinput a= nd anyprevoutput* proposals to enable eltoo, but also to make possible bett= er off-chain protocol designs generally. > > Among the various advantages previously discussed, the particular use cas= e benefits from eltoo I want to take advantage of is less interactive payme= nt channel negotiation. > > In talking with people about eltoo this summer, I found most people gener= ally support adding this as an option to Lightning. The only general concer= n I heard, if any, was the vague idea that rebindable transactions could b= e somehow misused or abused. > > I believe when these concerns are made more concrete they can be classifi= ed and addressed. > > I don't find too compelling the potential problem of a 'bad wallet design= er', whether lazy or dogmatic, misusing noinput. I think there are simpler = ways to cut corners and there will always be plenty of good wallet options = people can choose. > > Because scripts signed with no_input signatures are only really exchanged= and used for off-chain negotiations, very few should ever appear on chain.= Those that do should represent non-cooperative situations that involve sig= ning parties who know not to reuse or share scripts with these public keys = again. No third party has any reason to spend value to a multisignature scr= ipt they don't control, whether or not a no_input signature exists for it. > >> 2. Is there strong support or opposition to the chaperone signatures >> introduced in anyprevout / anyprevoutanyscript? I think it'd be best= to >> formulate a concrete set of pros and contras, rather than talk about >> abstract dangers or advantages. > > > As I mentioned before, I don't think the lazy wallet designer advantage i= s enough to justify the downsides of chaperone signatures. One additional d= ownside is the additional code complexity required to flag whether or not a= chaperone output is included. By comparison, the code changes for creating= a no_input digest that skips the prevout and prevscript parts of a tx is m= uch less intrusive and easier to maintain. > >> 3. The same for output tagging / explicit opt-in. What are the advantag= es and >> disadvantages? > > > I see the point ZmnSCPxj makes about tagged outputs negatively impacting = the anonymity set of taproot transactions. The suggested work around would = impose a cost to unilateral closes of an additional translation transaction= and not using the work around would cause a hit to anonymity for off-chain= script users. I feel both costs are too high relative to the benefit gaine= d of preventing sloppy reuse of public keys. > >> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce = the >> confusion and make for simpler discussions in the end. > > > I believe they should be merged. I also think both chaperone signatures a= nd output tagging should become part of the discussion of security alternat= ives, but not part of the initial specification. > > I understand the desire to be conservative with protocol changes that cou= ld be misused. However, with just taproot and taproot public key types the = anyprevout functionality is already very opt-in and not something that migh= t accidentally get used. Belt-and-suspender protections like chaperone sign= atures and tagged outputs have their own impacts on code complexity, on-cha= in transaction sizes and transaction anonymity that also must be considered= . > > I believe efforts like descriptors will help people follow best practices= when working with complex scripts without pushing extra complexity for saf= ety into the consensus layer of bitcoin. Anywhere we can make core code sim= pler, and handle foot-guns in higher level non-consensus code, the better. > > _______________________________________________ >> >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev