From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5B1A6C0177 for ; Fri, 27 Mar 2020 01:46:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4AE43888D5 for ; Fri, 27 Mar 2020 01:46:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0wiwBQ0KzJW for ; Fri, 27 Mar 2020 01:46:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by whitealder.osuosl.org (Postfix) with ESMTPS id 267BC88783 for ; Fri, 27 Mar 2020 01:46:21 +0000 (UTC) Date: Fri, 27 Mar 2020 01:46:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1585273578; bh=Pj8NZbgXaVU02LPOTrdTRJFEF8AJOXm6opLuykosAW0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=miqwARwNz2Z+uEuEYtdS4X7xBo2DJiHN+tfpTb1j+TE3KwxQVwOe+0Wyy4pgNsWNa tmyaQySfqw5d3WqVUUT72oZkg24LQqShIm3KDrHcB3zKLHxEeUw6Nl3GMoTv0SBRB/ H0P1JiVfukk4ldbGmriiuFSI4PwPe0O0/tqUFF+U= To: Ruben Somsen , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com> <87369v6nw3.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tom@commerceblock.com" , Greg Sanders Subject: Re: [bitcoin-dev] Statechain implementations X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 01:46:23 -0000 Good morning Ruben, > Hey Christian, > > Thanks for chiming in :) > > >It might be worth adopting the late fee binding we have in eltoo > > That is where my thinking originally went as well, but then I remembered = that this alters the txid, causing the settlement tx to become invalid. Wha= t I am suggesting should be functionally the same (albeit less space-effici= ent): a secondary output that can be spent by anyone, which can be used to = fee bump the kickoff tx with CPFP. I believe this same idea was considered = for Lightning as well at some point. Do you happen to recall if there was s= ome kind of non-standardness issue with it? Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you = can use an `OP_TRUE` `redeemScript`, for instance. Using an `OP_TRUE` `redeemScript` would allow any third party to make you c= ry by opportunistically spending such an output. For example your Bitcoin-network peer could notice you broadcasting such a = transaction with an `OP_TRUE` output, see you spend that output with a CPFP= -RBF-ed child transaction, then instead of further broadcasting the child t= ransaction, instead broadcast a non-RBF child transaction with tiny fee, so= that it and its parent transaction will be accepted into mempools but woul= d not be replaceable with a higher-feerate child transaction (because not R= BF-flagged). Thus, some portion of mempools will contain this poisoned low-fee child tra= nsaction and prevent the parent from being confirmed (because the parent+ch= ild fees are not enough to justify being put in a block). Which I suppose is an argument for Full RBF aka ignore-the-RBF-flag-and-alw= ays-RBF. The solution that I remember being proposed for this in Lightning was to gi= ve each participant its own attach-your-fees output that only that particip= ant can spend, which works for Lightning because the set of participants in= a channel is permanently fixed, but probably not for statechains. -- The broadcasting of the kickoff simply means that the first stage cannot be= easily changed, and you might still be able to make further updates by upd= ating only the later stages, until the last stage is confirmable, so the ki= ckoff being broadcast simply creates a "dead man walking" statechain. However, the implementation complexity would probably increase tremendously= . Regards, ZmnSCPxj