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 0E9EF8F5 for ; Wed, 19 Dec 2018 22:09:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 81D217C for ; Wed, 19 Dec 2018 22:09:56 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id h15so23044edb.4 for ; Wed, 19 Dec 2018 14:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=93G6SmFnHeSaqZaHBIYOn9SCiW4Fi1OttV1gnZsl4D8=; b=SahHrdcVix7wjks4ygCuVKKsRtEYLxASwAiX7fBO+EFiolU5ULh6l1Yi9GfXrUHMeu jIMFYB3ZtWDxOgowe97Pg7T2GLnj0tjD9hfIszvVEQmyROmJC+pT9qg4kUzPjHxhm2w2 EvDNso532NIHP9gLJc0q/WyBTLzMDwKyqOXm9cldgMyNSt6wO5Mp1hx5jF8Mk/JIs6z7 rt2IsJzi2UflLdBHOnFXCxVJaaV16tyfvJlRVovBn2pyuQNd0Ze+QnRBC0kQO1zpYLse wxoTGhyAc7J4WQ9tWXxC+HGuZSy2dm4lDSC1DKEELOnUbBZ9BvZsvAPdx4b8zzOyeUxC fcEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=93G6SmFnHeSaqZaHBIYOn9SCiW4Fi1OttV1gnZsl4D8=; b=YipaINDUQDwb0jk9XikCMj1QegrJenaxph94yJZIUfXmj7Tp4VWakYqoxzexUe73I5 ZLpMdH5BcrqZMtfQEoJXa/WppXcKTyd+jByyqyAQzvYE2sJiF4+TKtmE4AEnj2CN9PHj wNET6YvMIZXz32QBSL9/GNN+J4V0CyU5Z8X/l2dRjSFZfCgIEO7QC2XdCWDcp0M7y2am uAx6ktqwPVTj2QZzxJAFhM6Ya/lGqHX8nJS0zRuk4gACIkXxpODk7lLT3uvJAG9JIZR1 H1elqGxDI27hRHrO7SuaayadLVUADUArCuM5YqZNG+5/GOxenXThN+ZOjvCrn06rToHo TOFA== X-Gm-Message-State: AA+aEWbuw+gUk/ONrbaJwYORzHHc/pdHcb7BPB44lTs8b5e3O1joIPMr q9Yc/xN59y7MYR45mnKD9LY= X-Google-Smtp-Source: AFSGD/Udll2fFeq4hcxQcahe8+4Qy0mPZ9O6I+KXQL8ozXRfmvvGKePK3zZIWMr1HOsK8yw3jo1aBw== X-Received: by 2002:a50:f098:: with SMTP id v24mr21306736edl.78.1545257395083; Wed, 19 Dec 2018 14:09:55 -0800 (PST) Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe]) by smtp.gmail.com with ESMTPSA id b46sm5722117edd.94.2018.12.19.14.09.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 19 Dec 2018 14:09:53 -0800 (PST) From: Christian Decker To: Ruben Somsen , Bitcoin Protocol Discussion , Johnson Lau , Bitcoin Protocol Discussion In-Reply-To: References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> Date: Wed, 19 Dec 2018 23:09:50 +0100 Message-ID: <87efadp3rl.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, 20 Dec 2018 21:58:07 +0000 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: Wed, 19 Dec 2018 22:09:57 -0000 Ruben Somsen via bitcoin-dev writes: > Hi Johnson, > > The design considerations here seem similar to the ML discussion of > whether Graftroot should be optional [1]. > >>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging? > > As far as I can tell it should be compatible with Statechains [2], > since it pretty much mirrors Eltoo in setup. > > My understanding is somewhat lacking, so perhaps I am missing the > mark, but it is not completely clear to me how this affects > fungibility if taproot gets added and the setup and trigger tx for > Eltoo get combined into a single transaction. Would the NOINPUT > spending condition be hidden inside the taproot commitment? I'm not aware of a way to combine the setup and trigger transaction. The trigger transaction was introduced in order to delay the start of the timeouts until a later time, to avoid having an absolute lifetime limit and having really huge timeout. If we were to combine the trigger transaction with the setup transaction (which is broadcast during channel creation), all of those timeouts would start counting down immediately, and we could just skip the trigger transaction altogether. It'd be more interesting to combine update and trigger transactions in a sort of cut-through combination, but that doesn't seem possible outside of Mimblewimble. Cheers, Christian