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 CAA917F9 for ; Thu, 17 May 2018 17:36:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3EAA5A3 for ; Thu, 17 May 2018 17:36:09 +0000 (UTC) Received: by mail-qk0-f174.google.com with SMTP id d125-v6so4262860qkb.8 for ; Thu, 17 May 2018 10:36:09 -0700 (PDT) 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=uCk+3+1WI2RoD1FFfOx2Ri6qiMKshCHTds+m8+vXC4s=; b=tHytSiZ31epwECunUaKuB+Nr4f1XxQ1g40+wMBCazzBhdN6RCH9jM/0m/z7UaCx7YQ gB2MQI3C6x2gMg/ilfsKHyHL7oFLG+sI4dU6wEEC8xPTeCWI8buZakkaVBB3FxINdpb/ p9O8R9ixdL56r4psIUQhXyVx/grPWfB53P5rvWOKUAPSD3JrLNzdwrBrgrcq4LisEH1r 2gQXmUJrsHKgWO2JBQL0FAkrWWQq+2xqFjlGX7bZn3Yl45U51yADA3tksQa0kDDSlNOC JTn3/Fl6h6i7t7cgq4DFjiz8T7k+cibZeAqXAGist0YINWH/xoaOv1gZWb3gkui2vJWM n44g== 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=uCk+3+1WI2RoD1FFfOx2Ri6qiMKshCHTds+m8+vXC4s=; b=aDipdrTkNxFs3hT6gwIcoUzQauQWZHqlvTGUjEe0V4iZk4+MHSzmOSTA7JcmzLQpNd scbQLYWMaPe955ABbtiMuyH/IbN2jdWC2kfzIJK7FoNMa+bfIc8QbryoUKueA9Wxn0hU FchFMhrr5k51l6mSDKeF1VwsKPDHz72jpSFAN0iMZEJKVMSHoSY/8NlAdufkKE0aNQY9 2yN55nsaY72LzIM9jnXVfPUKyJPLofztnx/KQIw9W9IvsZLXz7hG5SCmZ9OcBw4Bg/hV LomrUOl7HESbxFnRVOTNtOAvxwH2rDu+YWzneR69rv/2ITUSFu95F0j0VsUD3jGCqfu2 F/nQ== X-Gm-Message-State: ALKqPwcdM9V/9t/CNQR3yUK60rbOrLYvjj1L9NTAsezhN8eQoRqo8AZ2 mGM4r06mXgD+vvWNvO8/8/I= X-Google-Smtp-Source: AB8JxZr+sKZRzHNN4Z6ap5zvgQ82d/AZwQqFpOXpS9/8bhn7zwaGu2FLoSCnRF+FugBQAFV5ZfHQUw== X-Received: by 2002:a37:1f14:: with SMTP id f20-v6mr5728919qkf.391.1526578568329; Thu, 17 May 2018 10:36:08 -0700 (PDT) Received: from localhost (parkc133.p.subnet.rcn.com. [206.71.234.160]) by smtp.gmail.com with ESMTPSA id u21-v6sm4296021qki.63.2018.05.17.10.36.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 10:36:07 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , Bitcoin Protocol Discussion , Rusty Russell , Bitcoin Protocol Discussion In-Reply-To: References: <87po25lmzs.fsf@rustcorp.com.au> <201805100227.42217.luke@dashjr.org> <87vabnq9ui.fsf@rustcorp.com.au> Date: Thu, 17 May 2018 13:35:53 -0400 Message-ID: <87h8n6i3ra.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 Subject: Re: [bitcoin-dev] Making OP_TRUE standard? 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, 17 May 2018 17:36:09 -0000 ZmnSCPxj via bitcoin-dev writes: > Good morning Rusty and list, > >> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is >> interesting, >> >> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need >> this >> >> at all (though others still might). > > We might still want this in general in Lightning; for instance we > could make every funding transaction include such an output. If it > turns out, our initial feerate estimate for the funding transaction is > low, we can use the `OP_TRUE` for fee-bumping. This is a win for > Lightning since the funding transaction ID remains the same (even in > Decker-Russell-Osuntokun, the trigger transaction is signed with > `SIGHASH_ALL`, and refers to a fixed funding transaction ID). > > Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a > new different channel and RBF the old funding transaction with a new > higher-feerate funding transaction, then keep track of which one gets > confirmed deeply (there is a race where a miner discovers a block > using the older funding transaction before our broadcast of the new > funding transaction reaches it). > > (we could also feebump using the change output of the funding > transaction, but such a change output might not exist for all funding > transactions.) This would only really help in the case of the funding tx not having a change output, which I believe will be very rare. In the case of a change output we can simply do a CPFP which includes the change output.