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 1896F13EB; Thu, 3 Oct 2019 10:33:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69881189; Thu, 3 Oct 2019 10:33:53 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id f20so1958045edv.8; Thu, 03 Oct 2019 03:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=63bNKWxh3uKk7QOmVCHuU5suOus0H7KJcBswx6cFbq0=; b=OS3IWElytJt7NOimbGhqFIjNWHtpYmumJRRBM5aqMsDfJHaupLlLWaAf8Sb4Xxh+w+ 7x7j/4sk5KGi9gGnwlVTuRojhrDxs0m+0z2e+lWprM8t6qGJQLbeTpzJtEJLYS0tQQtp vD/QzoVBU8AeEZmAikwWqXrM6+LeQe0bZnlqkXHWeaQg0DJ9FaacMh/zWMPRQbrLPrqj JkVkQF4bOGfabVuJgG59zF0Q7hTR3Bjg0ht9VG5/hpfT+r4v74FviV5pH8ZONKi2AL3+ 11n+6AdBTMzC/5NpXYQykF7GKulUwyk4jCRWbLpevaPxy09SH0RGUR5+GxYmjCqPekJV FYNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=63bNKWxh3uKk7QOmVCHuU5suOus0H7KJcBswx6cFbq0=; b=DbKQ7kkuiGQbYe/RGmI1NnAOl85h4TdH+gTqRh1pPHl1dUFh30Nhvp5usKY4NGSdl4 EkMEnKNPPWSXxUrhZ+4QMQMDdgTeLJZa34cSRxLyzq4oXfVtuks5PbFgoaRIPTfz121a sw0HjYakAzDf2m8bcVoq1vRB+U/INPD1oDXdxyORqHT4PGWnjNiOg2VOvN0m6D04pSDU CDQPyKDihO+S1gQ2qqkiZrzHDS8rOVMUfWyN/wOXTR3VewUefItOOnw6/o4YdfjSVsCk AOJs49vYelXM+3mG36oli/wgx/BYISLvcF3GFMkeAxOzzoro4t2H8eiV8z/QHt1kzzkm XP8Q== X-Gm-Message-State: APjAAAUEz0arwUU1X90fpvhIkKocGjjPMXVdjaoS2bmhRfjPNae8qBXK E3/HnOnt7Nj1IX/Ct4xCddc= X-Google-Smtp-Source: APXvYqzjADeGgzqFj8rPG/aYD+qYXpI6PY/nyO/gaVwait/b51zMDkIzNWKu0X8WZukx4VQgcPGmpw== X-Received: by 2002:a50:da44:: with SMTP id a4mr8778559edk.120.1570098832033; Thu, 03 Oct 2019 03:33:52 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532]) by smtp.gmail.com with ESMTPSA id h38sm391970edh.13.2019.10.03.03.33.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 Oct 2019 03:33:51 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , Bitcoin Protocol Discussion , Chris Stewart In-Reply-To: References: <87wodp7w9f.fsf@gmail.com> Date: Thu, 03 Oct 2019 12:01:58 +0200 Message-ID: <87imp66tbd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Christian Decker via bitcoin-dev , "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: Thu, 03 Oct 2019 10:33:54 -0000 ZmnSCPxj via bitcoin-dev writes: > Good morning lists, > > Let me summarize concerns brought up: > > * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. > * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output. > > I propose the below instead: > > * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`. > * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`. > > Then, on usage: > > * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence. > * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`. > > This solves both concerns: > > * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it. > * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`. > > Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy. > But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me. > > Would this alternate proposal hold better muster? Intriguing idea, this would be an invisible tagging, since the opt-in to noinput and friends is hidden inside the committed script, which only gets revealed whenever we actually need it. For eltoo this would mean that the funding output would be invisibly tagged, and the cooperative close would use the taproot pubkey, while the uncooperative close, which would require noinput opt-in, reveals the script, proving prior opt-in, and provides a matching signature. If I'm not mistaken this would require AJ's alternative pubkey encoding (0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?