diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-03-27 01:46:15 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-03-27 01:46:23 +0000 |
| commit | 9e1f97f654ab2734f18bab2479139cba3fc179a0 (patch) | |
| tree | bf5eb7b9f0ba2bca21fcd610e6da4dcc9bbb51b0 | |
| parent | 8e9a6ea86cf0459c0353a7bf3507fd580ebe4a00 (diff) | |
| download | pi-bitcoindev-9e1f97f654ab2734f18bab2479139cba3fc179a0.tar.gz pi-bitcoindev-9e1f97f654ab2734f18bab2479139cba3fc179a0.zip | |
Re: [bitcoin-dev] Statechain implementations
| -rw-r--r-- | fa/52d01f581222399b43d6ee708644dd06d04276 | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/fa/52d01f581222399b43d6ee708644dd06d04276 b/fa/52d01f581222399b43d6ee708644dd06d04276 new file mode 100644 index 000000000..9bdf3127d --- /dev/null +++ b/fa/52d01f581222399b43d6ee708644dd06d04276 @@ -0,0 +1,111 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 5B1A6C0177 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <rsomsen@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <j37G_ywUw4UA7J2iEXurAk8Vq-QA3toUz3sakqEiYHqbpqF1DEK0riorbuZW_UkMCkNS-KKCDNPec7ogpchdg8hYPjPh_gzAGwfbY72e_p4=@protonmail.com> +In-Reply-To: <CAPv7TjbAfLHFZgSvCTSG2rS6oZinyd6VWrT3U8Y++PL=Jm6igA@mail.gmail.com> +References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com> + <79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com> + <CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com> + <87369v6nw3.fsf@gmail.com> + <CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com> + <CAPv7TjbAfLHFZgSvCTSG2rS6oZinyd6VWrT3U8Y++PL=Jm6igA@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +Cc: "tom@commerceblock.com" <tom@commerceblock.com>, + Greg Sanders <gsanders87@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |