From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 87905C0171 for ; Sat, 1 Feb 2020 00:39:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 57EE586144 for ; Sat, 1 Feb 2020 00:39:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLveHvfr4WA7 for ; Sat, 1 Feb 2020 00:39:51 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 2722684CC2 for ; Sat, 1 Feb 2020 00:39:50 +0000 (UTC) Date: Sat, 01 Feb 2020 00:39:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1580517587; bh=UWqTwtpohHg2JJylMvlXgmMA2uCV96Q+jYYziiyEmas=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=q2Twq7ZbuokTsDejvGAk9ZkrZRkQYOl9KxQAps27XdrKv51g7B/SluQZCwlQo1nBK EZIKc49bwbiGlokFzKtf6zRitiCMDZcny95dSiJP31nHR0rg/0NZ+Br2Klxjh7EIq8 diEH+rTwftZQm5Ib1BqW71lxBwVcSty3A54bu2h8= To: "David A. Harding" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2XX6GT0e_q6BTo0HQnromtAwL6A9MGW-RCE-G9Ge-pKlreanboQQW1izVYxVXl3aqRQSG1xoOmNIcgFHNXDVfUI_DXzyUuxJiajhDpSP73I=@protonmail.com> In-Reply-To: <20200131210129.ufnjxb2x7wllhcuw@ganymede> References: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com> <20200131210129.ufnjxb2x7wllhcuw@ganymede> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Onchain fee insurance mechanism 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: Sat, 01 Feb 2020 00:39:53 -0000 Good morning David, > On Fri, Jan 31, 2020 at 03:42:08AM +0000, ZmnSCPxj via bitcoin-dev wrote: > > > Let me then propose a specific mechanism for feerate insurance against = onchain feerate spikes. > > [...] > > At current blockheight B, Alice and Ingrid then arrange a series of tra= nsactions: > > > > nLockTime: B+1 > > nSequence: RBF enabled, no relative locktime. > > inputs: Alice 5000000, Ingrid 800000 > > outputs: > > Bob 400000 > > Alice 99400 > > Ingrid 800400 > > fee: 200 > > > > > > [...] > > Ingrid is able to rescind this series of pre-signed transactions at any > time before one of the transactions is confirmed by double spending her > UTXO (e.g. via a RBF fee bump). If Alice needs to trust Ingrid to honor > the contract anyway, they might as well not include Ingrid's input or > output in the transaction and instead use an external accounting and > payment mechanism. For example, Alice and Ingrid agree to a fee > schedule: > > > height: B+1 > > fee: 200 > > > > height: B+2 > > fee: 400 > > > > height: B+3 > > fee: 599 > > > > height: B+4 > > fee: 3600 > > > > Then they wait for whichever version of the transaction to confirm and > one of them remits to the other the appropriate amount (either 400, 200, > or 1 base unit to Ingrid, or 3,000 base units to Alice). This > remittance can be done by whatever mechanism they both support (e.g. an > onchain transaction, an LN payment, or just credit on an exchange). > > Since it's possible to achieve equivilent security (or lack thereof) > without the locktime mechanism, I don't think the locktime mechanism > adds anything to the idea of hedging fees---and, as you note, it suffers > from incompatibility with some cases where users would be especially > eager to obtain feerate insurance. Indeed, the rescindability is a flaw. I will now do something really evil: I will attempt to patch this flaw with= out considering that the patch will of course have other detrimental side e= ffects. Rather than have the Ingrid-input (and output) be solely under the control = of Ingrid, it is a 2-of-2 with Ingrid and Alice. Long before the Alice->Bob transaction, Alice has already commissioned the = services of Ingrid. They have already agreed on the specs of the insurance policy, and in parti= cular, have agreed that this agreement terminates at some future data. At setup, Alice and Ingrid create a claim transaction for Ingrid, with `nLo= ckTime` set to the agreed-upon end-of-insurance-contract, which allows Ingr= id to reclaim the original fund. Then, at height B when Alice wants to send to Bob, they create the series o= f timelocked transactions, with the Ingrid output similarly having an `nLoc= kTime`d transaction that lets Ingrid reclaim the earned funds. Against this patched scheme, of course, new problems arise: * During times of low fees, Alice can just create a non-insured transaction= directly on the blockchain, denying Ingrid its earnings. * During times of high fees, Ingrid can go offline and refuse to provide si= gnatures needed for the insured transactions, denying Alice its service. * This is significant if Alice prepaid for the insurance contract. Thus, as we can see, patching a flawed protocol still leaves us with a flaw= ed protocol. -- On the other hand, the above "Spilmanizing" of the protocol leads to a poss= ible insurance policy for Lightning channel closures. At the same time as channel establishment between Alice and Bob, Alice also= starts an insurance contract with Ingrid. Alice prepays Ingrid, using a CoinJoined transaction that spends from Alice= and Ingrid inputs, with the combined premium plus Ingrid inputs value put = in an output locked to Alice && Ingrid, and a maximum contract lifetime (an= `nLockTime`d transaction that claims the Alice&&Ingrid output and returns = the fund, plus insurance premium, to Ingrid). Then, at each commitment transaction signing, there is an additional unencu= mbered but tiny output that Alice can claim immediately (obviously this req= uires a change in the BOLT spec). Ingrid and Alice create an insurance transaction with high feerate, which s= pends the above tiny output, and spends the Alice&&Ingrid output, deducting= the fees from the Alice&&Ingrid output and returning what is left to Ingri= d. Then, if Alice decides to drop the unilateral close onchain: * If fees are low at the time that unilateral close, then Alice can just cl= aim the tiny output itself. * Alice is incentivized to do so because it means she will still control = that tiny output. * Ingrid can then reclaim its fund, plus the premium, at the end of the i= nsurance contract lifetime. * If fees are high at the time that unilateral close, then Alice can sacrif= ice the value of the tiny output and attach the insurance transaction with = high feerate. Further: * If on a new commitment transaction, Ingrid does not cooperate, then Alice= can drop onchain *and* punish Ingrid by dropping the previous commitment a= nd also broadcasting the insurance transaction. * Alice has to sacrifice its tiny output to do so, but it would be worth = it to punish Ingrid and deter this non-cooperation. * When the insurance contract lifetime is near, Alice and Ingrid can renew = the contract by cooperatively spending the Alice&&Ingrid output to a new Al= ice&&Ingrid output (possibly with some payment from Alice to renew the cont= ract). * This gives an upper bound for what Alice will pay to ensure its channel i= s closeable at any time very quickly, which is the entire point. Regards, ZmnSCPxj