From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B2CF1C000E for ; Tue, 22 Jun 2021 18:40:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A13B7605EB for ; Tue, 22 Jun 2021 18:40:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEhICyDN8Ohd for ; Tue, 22 Jun 2021 18:40:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4F1FA605D3 for ; Tue, 22 Jun 2021 18:40:31 +0000 (UTC) Received: by mail-oi1-x22e.google.com with SMTP id x196so395787oif.10 for ; Tue, 22 Jun 2021 11:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=34dzzb1Tb6A4lPIOrw9Z46Mun3Kb744SH93XKVl42qo=; b=k//hI6FkLzqTXiW0mPuGUN8xvMhIb9o/4wPe0ZUIDKdayIE082Le8LcTzA2+qMufp9 Q1o/h3NmbfirXJmoMV89e9VWKSlIT2688ee78jOZeIijldzLxFByFeF+zkeG63SLRFoa +SEmfC5BPlMj+b8ux2WN1RmZhnIqZsHX7Mgcfu2HPNOSXegP7ebKw1dNlBGaD1lNBPOo lqirvK3zUVR10Y0r7pZ/MfnWw0mhSbJJmBxaSIRufo4o/xbVn9xydwHDeSKFrFkCV/6q fClLYkITS6mThKSWI+ftvc2Se7DnqE3qVRLK0gfiPSIH4bYROXVc4kEFbB8iHUdYxC9m qOgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=34dzzb1Tb6A4lPIOrw9Z46Mun3Kb744SH93XKVl42qo=; b=awI041HXIW8ln8VqRWRVQ6S5OgJiiE+UR/qu7HXKv9NfUFjb/dt4rAknmXyoPsJSbt 1cKjUrylkJE8cKCUzJDQWHWzbFiKbAP5z9tsIRqpu5cZLoz1m9EcU8nZCFtLndQSJfP8 4yaM0zT362aHnFUAFdFoo5bSjR2veW9yhrnAPL/vVJqqgpZ+s0rq7XKkZfJ3g75zjb+k PIGB1Gb9+lYbG4xJMUEIfUsX1mKPkF4/zilSjL6mDU0h0BCe6cTNSHJv0Nl9JbfREOCM 8s2yOjrGfA/8CqWSfjRunKwjIyzTrmxEOWx7s/b6lzDRrJQqPYb+OTJYzTFH7PAFu9bn t3YA== X-Gm-Message-State: AOAM5327RehDNYYaHJRH21YB57YrRln2EENroUxJxzNPBRsMml+g3eT8 xb2cBRlJ3WGMXlg0SdzgIFOPaRhMxzePiwZ4KKw= X-Google-Smtp-Source: ABdhPJyMKWgceSIGO5IOunVHvXodX0l4CnPRzqjo8fB0waVmNH//7TxgFOSYfSSTju9VPH1cEujtg+L9afKrjKZkJoE= X-Received: by 2002:a05:6808:13c5:: with SMTP id d5mr100554oiw.163.1624387230279; Tue, 22 Jun 2021 11:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Folkson Date: Tue, 22 Jun 2021 19:40:19 +0100 Message-ID: To: Billy Tetrud Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 23 Jun 2021 02:51:04 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] =?utf-8?q?Tuesday=E2=80=99s_IRC_workshop_on_L2_onch?= =?utf-8?q?ain_support?= 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: Tue, 22 Jun 2021 18:40:32 -0000 Sure, feel free to continue on this thread for discussion of fee sensitive timelocks. I'll start a new thread for a summary of today's second workshop. On Tue, Jun 22, 2021 at 7:26 PM Billy Tetrud wrote= : > > > where is the current network fee rate obtained from and how is it fed = into the script? > > It could be obtained as something like the median transaction fee rate ov= er a window of X blocks. Its something any full node could easily keep trac= k of. And as long as hour-level or day-level granularity is acceptable, I w= ouldn't think there'd be any need to incorporate mempool information (if th= at were even possible without introducing new attack vectors). Let me know = if this isn't an appropriate thread to discuss this in. > > On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson wrote: >> >> Hey Billy >> >> No, fee sensitive timelocks weren't discussed at any length in the >> workshop. The workshops are obviously time limited but if they spur >> future discussion and drafted proposals (whether they need soft forks >> or not) outside of the workshops that would be great. This idea was >> raised in the meeting by Ruben Somsen so maybe Ruben has given them >> some thought. Making timelocks conditional on the current fee rate >> seems challenging to me (where is the current network fee rate >> obtained from and how is it fed into the script?) but I haven't >> sketched out exactly how they would work. >> >> A reminder that the second workshop (on package relay and fee bumping) >> starts at 19:00 UTC today (30 minutes after I've sent this, there may >> be a delay before it is published to the mailing list). >> >> Thanks >> Michael >> >> On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wr= ote: >> > >> > Thanks for the Summary Michael! >> > >> > It seems like fee-sensitive timelocks weren't discussed too much in th= e workshop, unless I'm missing something. I also don't see any downside to = it discussed (other than that it needs a soft-fork). It seems like that wou= ld be a great way to substantially increase the resilience of the LN to tem= porary periods of fee congestion, even potentially long-running periods tha= t last weeks. It might even help in non-temporary fee market increases by g= iving participants extra time to use some fee-bumping technique to close or= restructure their channels to compensate for the elevated fee market. >> > >> > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev wrote: >> >> >> >> The workshop was previously announced by ariard on the bitcoin-dev >> >> mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/01= 8841.html >> >> >> >> A reminder was posted to the bitcoin-dev mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019= 068.html >> >> >> >> The conversation log for the workshop is here: >> >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> >> >> I=E2=80=99ll summarize what was discussed during the meeting but plea= se refer >> >> to the L2 zoology repo ariard has set up for background context and >> >> additional notes: https://github.com/ariard/L2-zoology >> >> >> >> General considerations >> >> >> >> I think it is worth first reiterating the obvious that there will >> >> never be perfect security guarantees on network transaction fee rates >> >> or transaction relay. Network fee rates can in theory go up to >> >> anything (upper limit of infinity) and will always to some degree be >> >> inherently unpredictable. In addition transaction acceptance can neve= r >> >> be guaranteed even if you attempt a direct connection to a miner. At >> >> the same time L2 protocols (e.g. Lightning and DLCs) elevate >> >> transaction propagation and inclusion in a time sensitive mined block >> >> to a security assumption from what used to just be a usability >> >> assumption (BlueMatt). Within those confines these workshops are >> >> attempting to strengthen that security assumption knowing that >> >> guaranteeing it is out of reach. >> >> >> >> There are considerations that blocked transaction propagation isn=E2= =80=99t >> >> necessarily a problem for the victim if it is also blocked for the >> >> attacker. In addition some successful attacks present an opportunity >> >> for the victim to divert their funds to miner fees (e.g. scorched >> >> earth) ensuring the attacker doesn=E2=80=99t financially benefit from= the >> >> attack (harding). Personally I would argue neither of these present >> >> much assurance to the victim. Out of conservatism one should assume >> >> that the attacker has greater resources than the victim (e.g. a direc= t >> >> line to a miner) and knowing a victim=E2=80=99s lost funds went to th= e miner >> >> instead of the attacker isn=E2=80=99t of much comfort to the victim (= other >> >> than potentially presenting a disincentive for the attack in the firs= t >> >> place). This is obviously further complicated if the miner is the >> >> attacker. In addition any incentive for miners to not mine >> >> transactions to wait for a potential pay-all-to-fee are troubling >> >> (t-bast). >> >> >> >> New(ish) ideas >> >> >> >> RubenSomsen brought up the idea of fee sensitive timelocks, they woul= d >> >> need a soft fork. ariard briefly discussed the idea of a transaction >> >> relay overlay network. harding stated his opinion that we should be >> >> leaning more on miners=E2=80=99 profit incentive rather than attempti= ng to >> >> normalize mempool policy (e.g. >> >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/= 002664.html). >> >> t-bast raised the prospect of mining pools exposing public APIs to >> >> push them transactions directly. >> >> >> >> The impact of changes to Bitcoin Core on L2 protocols >> >> >> >> Some changes to Core (e.g. some privacy improvements) can conflict >> >> with the goal of minimizing transaction propagation times. >> >> Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L= 2 >> >> developers a way to write regression tests against the latest builds >> >> of bitcoind. He added that L2 devs should write automated regression >> >> test suites against bitcoind exposed RPC commands. t-bast would like = a >> >> bitcoind =E2=80=9Cevicttx=E2=80=9D RPC to remove a transaction from t= he mempool on >> >> regtest. >> >> >> >> Full RBF >> >> >> >> In advance of the workshop ariard posted to the mailing list a >> >> proposal for full RBF in a future version of Bitcoin Core: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019= 074.html >> >> >> >> Progress in this direction has been attempted in the past (e.g. >> >> https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out >> >> that even with full RBF it is trivial to create mempool partitions. A= s >> >> long as RBF has a fee rate increase minimum an attacker can trivially >> >> split the mempool by broadcasting two conflicting transactions with >> >> the same fee. >> >> >> >> ariard plans to contact businesses (e.g. Lightning onboarding service= s >> >> relying on zero confirmations) to check that this possible eventual >> >> move to full RBF doesn=E2=80=99t present a problem for them. There co= uld well >> >> be engineering work required in advance of the possible change being >> >> made. >> >> >> >> Next week=E2=80=99s meeting >> >> >> >> Next week=E2=80=99s meeting (Tuesday 22nd June, 19:00 UTC, >> >> #l2-onchain-support, Libera) will be on fee bumping and package relay >> >> that glozow has recently been working to advance in Bitcoin Core. >> >> >> >> -- >> >> Michael Folkson >> >> Email: michaelfolkson@gmail.com >> >> Keybase: michaelfolkson >> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> -- >> Michael Folkson >> Email: michaelfolkson@gmail.com >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --=20 Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3