From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 39E22C0171 for ; Fri, 31 Jan 2020 03:42:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 2816C203B0 for ; Fri, 31 Jan 2020 03:42:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMLtt0I5ouaN for ; Fri, 31 Jan 2020 03:42:14 +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 silver.osuosl.org (Postfix) with ESMTPS id D1D0B20017 for ; Fri, 31 Jan 2020 03:42:13 +0000 (UTC) Date: Fri, 31 Jan 2020 03:42:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1580442130; bh=eY3HbPgP0iGXwKyhBLNFb7lX5BvIP7m3daII0gDuwpc=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=Pylhbebfz/w3Dmxy0+Lq/xSMb1KAOgNNiEIgeIthsAQuWRg+EbGD3V3tv1ZSa81Cq aT2XwGI3dnBPR6DEV+mhL2U93bOzzjm9GBB39+evzxw6ZE5wK7xuCah3phU67N0HFv VTUAazIQ+fJy5O7R9pP35V5BPuXVBgaGaj+ZqGyQ= To: bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [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: Fri, 31 Jan 2020 03:42:17 -0000 Good morning list, During LNConf 2019, Jack Mallers presented about hedging of onchain fees, w= hich he argues is necessary in order to have a smooth experience interfacin= g between onchain and offchain (in particular, when closing and opening cha= nnels). The exact mechanism proposed was to construct a futures market on onchain f= eerates, with miners taking short positions on fees (they are naturally lon= g on fees) while users take long positions on fees (they are naturally shor= t on fees). I observe that what the users effectively experience is similar to a consta= nt feerate (indeed the positions the user takes up are arranged such that t= he user takes a constant feerate for a vast majority of the expected future= outcomes). This is effectively an insurance policy against increases in feerate. Let me then propose a specific mechanism for feerate insurance against onch= ain feerate spikes. Let us suppose that the user Alice, has 500000 satoshi, and has to pay Bob = 400000 satoshi. Further, Alice and Bob have a fee insurance provider Ingrid. Ingrid assures Alice and Bob that 600 satoshi is sufficient to confirm the = payment from Alice to Bob within 4 blocks. Ingrid also happens to have a 800000 satoshi output lying around. At current blockheight B, Alice and Ingrid then arrange a series of transac= tions: nLockTime: B+1 nSequence: RBF enabled, no relative locktime. inputs: Alice 5000000, Ingrid 800000 outputs: Bob 400000 Alice 99400 Ingrid 800400 fee: 200 nLockTime: B+2 nSequence: RBF enabled, no relative locktime. inputs: Alice 5000000, Ingrid 800000 outputs: Bob 400000 Alice 99400 Ingrid 800200 fee: 400 nLockTime: B+3 nSequence: RBF enabled, no relative locktime. inputs: Alice 5000000, Ingrid 800000 outputs: Bob 400000 Alice 99400 Ingrid 800001 fee: 599 nLockTime: B+4 nSequence: RBF enabled, no relative locktime. inputs: Alice 5000000, Ingrid 800000 outputs: Bob 400000 Alice 99400 Ingrid 797000 fee: 3600 Basically, if the first transaction is able to be included in the next bloc= k immediately, then Ingrid is able to earn the most of the fee paid by Alic= e. However, as more blocks pass without the transaction getting committed, the= transaction in the mempool is replaced by transactions that bump up the fe= e, until the time limit is reached and Ingrid pays out significantly in ord= er to ensure the payment pushes through. As far as I can tell, this mechanism will also work for CPFP-style transact= ions. In general, the insurance provider Ingrid will be a miner. -- In the original context, this is generally about fast confirmation of chann= el closes. At the time that a commitment transaction is made, it is uncertain if the f= eerate for it would still remain valid for some future spike. The safest is that, if the counterparty is offline, if the feerate spikes, = we should drop the channel unilaterally onchain before it rises so high tha= t the commitment transaction cannot be confirmed in a timely manner. However, if the feerate then settles lower afterwards, we have already broa= dcasted the channel closure will no longer be able to use the fund on Light= ning. Unfortunately, the mechanism described above requires absolute locktimes, w= hich would impose a maximum lifetime on channels, which we would like to av= oid. Thus, the mechanism cannot be used for Lightning closes. For the Lightning case, what we want is something like: * Ingrid assures Alice and Bob that the close transaction can be confirmed = at any time, for only N satoshi. The previous mechanism described is nearer to: * Ingrid assures Alice that the transaction can be confirmed up to B blocks= from now, for only N satoshi. The issue is that relative locktimes require that a transaction be confirme= d, and it is transaction itself that we want to assure. Thus, we cannot use relative locktimes for any kind of fee-insurance mechan= ism. Thus, we must somehow tie down the blockheight at which we start our countd= own, and so we cannot use this for Lightning closes, since Lightning closes= must be freely doable at any time. Still, the mechanism might be useful for onchain transactions to help reass= ure users (which is why I send this post to bitcoin-dev). Regards, ZmnSCPxj