Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B2F43C000B for ; Thu, 17 Jun 2021 17:02:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 94D3783ED3 for ; Thu, 17 Jun 2021 17:02:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2QZRCiJoud for ; Thu, 17 Jun 2021 17:02:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by smtp1.osuosl.org (Postfix) with ESMTPS id A0D7483EC2 for ; Thu, 17 Jun 2021 17:02:11 +0000 (UTC) Received: by mail-ot1-x32b.google.com with SMTP id 66-20020a9d02c80000b02903615edf7c1aso6776538otl.13 for ; Thu, 17 Jun 2021 10:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=ZT9IAHHc0IrhcJ83nq6t8lB82A9jgzg7XQDftZz2PJg=; b=Ultq+AY55DHGmkifhq7bMsswUlB3WsIxa3joVDazcEhIKhOl5LU7mkpEYGVG7/jT+N v51juE88Fb86Iie78vJ213AlBqlX5z/AO/spbSKrjQPGLZCnJigCUlJpiyrA1wYTirUk 6VvuI6E6qsCXfA6hn75rB4PjgdIup7bBWdwy9u9IZY4lK99opx3BKwCDadbV0xXnRrdS m4VgbAD2+587M2sBkhu8Wtfy37lyxqsUvTremaS0Tg2n/g5m+xt5kAPWIA/2rDKMHi06 YMD18yTU0gYBpv8ggdaX5LIHrtT89FeRLiDP7P3RTW2Z8FUAbB+2Xz702g9L9EtdIJ85 myOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=ZT9IAHHc0IrhcJ83nq6t8lB82A9jgzg7XQDftZz2PJg=; b=rW9dFnDoani/os6MjvK04GYWH8cdKpSX5VhPJAl/7fG0LSdL4uU2oy7B11lgc1R1kX STQIQVsZo1C9dd0Cs4yGz/LNZmnJYpoBQK09LwK0GLL6SvH1jumdcLW0qJMWqgbduTEl ul7VrPr6NlGVQ3RW6nFfH4QcZ2hr3kmSrtmmW7RzWi0UAqJ5u9z4Fs8f3ezD/yGksw5E hxHNetbR+TdFHDh3y/3i3JVt0YG6smOzIPWTljigYWggKA85CpaQTkgLM6+S7KRgEdkW bqQXUM/+UVZAc60YFNjO7dxOUCWaTahYhQILGAQkRVXDwY72n9iVEVXaAhW840YXtFsg YfVA== X-Gm-Message-State: AOAM533qFxBCOSoYW1BOAfAolectjk2Y1lQEx3yZrbXUo9GBDlgI6IfJ OcjXTFY2tikBx7f7KoVesGHewDrOXqDrPXUUNAPBsSKQXsQ= X-Google-Smtp-Source: ABdhPJzGklmNTfp9Cf1QlClaXBKHotcqRukaSIHdt4tTd28THjAu896aUtRviRE7cH5rkl6VXahaPzaJ1SUwOmvGdKo= X-Received: by 2002:a9d:443:: with SMTP id 61mr5531919otc.305.1623949330213; Thu, 17 Jun 2021 10:02:10 -0700 (PDT) MIME-Version: 1.0 From: Michael Folkson Date: Thu, 17 Jun 2021 18:01:59 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Jun 2021 20:14:21 +0000 Subject: [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: Thu, 17 Jun 2021 17:02:12 -0000 The workshop was previously announced by ariard on the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.h= tml A reminder was posted to the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.ht= ml 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 please ref= er 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 never 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 direct line to a miner) and knowing a victim=E2=80=99s lost funds went to the mine= r 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 first 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 would 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 attempting 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 L2 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 the mem= pool 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/019074.ht= ml 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. As 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 services relying on zero confirmations) to check that this possible eventual move to full RBF doesn=E2=80=99t present a problem for them. There could we= ll 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. --=20 Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3