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 542021469; Thu, 14 Mar 2019 12:01:26 +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 27F1C82F; Thu, 14 Mar 2019 12:01:25 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id d6so3805475eds.2; Thu, 14 Mar 2019 05:01:25 -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=vuhPnIC/DUoFDAJ/M7VI5hOBCO/DiMblOO1c9LNQzbQ=; b=MbJLWObVGQJUiRa2dGvVwHEH+ysd+4oCssyBwXs8hzPk5Pr9ltc2yuBEIKmybCPa7V xBf3JE26d57k6cltRqUNBhP18Pt0dGiKOzo1G1EqdSkj13hS7Y3aAKM3bGGB+SNbpI38 +o8Rw12bYXHHn0FZg81FA1/+hRRlK0ROUOlnrhXiMiFVNqR8u1+LCAakL8olkbCVf0IS mdWC3qwLGA2O9w9EHebi07di870pPl/CS91PDKt0bKgq090qSNlJ4pLkzTRzP2oWlXyZ I3nVJBqXspehb2KnC4mh+1SXb9sQbk6b/wtjj8IU/0ARiFmahRNysawLECEmShWyiyNd ZDMA== 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=vuhPnIC/DUoFDAJ/M7VI5hOBCO/DiMblOO1c9LNQzbQ=; b=oG8IT/wa7XR8yQYqSaz5pBuqqHTIeEygRPL9XsHI4beGYrZ70PbcUmPQnBA292puqh jdXM2CpBq3Y7+8UEeibhMNWhaY9Qhm+VcG9aN3rQXBsO3tTL3++N0clOpMW739JKkVF/ 6u1mOs9263eztklXmZRDP0iH5gJ8wBylibGPgIEZQ1bnEncdMMc0s0CJ3Iwz6fBA2FRi FmpNG3Rg0dApDvb9XMEqvLXoJ/Pj3649O2S/lUUue3IyzRt6fsNMSCYZE8+8QUFvHrAG zeTGnAop0lmq1mumeCT+yftGlXSfEuFzZavTVVak/6cRF+IL/OCa6T8cj3LNWuLxvZFC nJaA== X-Gm-Message-State: APjAAAUO/rRt1LfG4EojL0AsvZ0JlUO6MtNOeTtNlZxfi6x9PvpzXXga KN4S6Qfwv4OfBwWWcB0xA7A= X-Google-Smtp-Source: APXvYqwDUZ6NXbA9mXHn6/3CTe6YH1+A6ZC3s+a0CKztVR9FVwUggSosOJ54tW/ZV5n2G4TExiH/dg== X-Received: by 2002:a17:906:54d:: with SMTP id k13mr2654079eja.207.1552564883543; Thu, 14 Mar 2019 05:01:23 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:c11f:6203:8f52:52eb]) by smtp.gmail.com with ESMTPSA id m30sm1402654eda.84.2019.03.14.05.01.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Mar 2019 05:01:22 -0700 (PDT) From: Christian Decker To: Anthony Towns , ZmnSCPxj In-Reply-To: <20190314072456.br2leoiae6zs2jv2@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <20190313111050.qj3s6utpl2x34sam@erisian.com.au> <20190314072456.br2leoiae6zs2jv2@erisian.com.au> Date: Thu, 14 Mar 2019 13:00:56 +0100 Message-ID: <87mulx3bt3.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 X-Mailman-Approved-At: Thu, 14 Mar 2019 12:11:36 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" , "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety 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, 14 Mar 2019 12:01:26 -0000 Anthony Towns writes: > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput), > so if you used a tagged output, you could do everything normal taproot > address could, but also do noinput sigs for them. > > So you might have: > > funding tx -> cooperative claim > > funding tx -> update 3 [TAGGED] -> settlement 3 -> claim > > funding tx -> update 3 [TAGGED] -> > update 4 [TAGGED,NOINPUT] -> > settlement 4 [TAGGED,NOINPUT] -> > claim [NOINPUT] > > In the cooperative case, no output tagging needed. I might be missing something here, but how do you bind update 3 to the funding tx output, when that output is not tagged? Do we keep each update in multiple separate states, one bound to the funding tx output and another signed with noinput? If that's the case we just doubled our storage and communication requirements for very little gain. An alternative is to add a trigger transaction that needs to be published in a unilateral case, but that'd increase our on-chain footprint.