path: root/1a/1cb310b1c4291dedb00ca71db065a35a6a7b5d

Return-Path: <michaelfolkson@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B2CF1C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 18:40:31 +0000 (UTC)
Received: by mail-oi1-x22e.google.com with SMTP id x196so395787oif.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAFvNmHSYD0yZhMJC=ceBZw86+-HyZ3mj19Tx3svfZ7Gxn3FiRg@mail.gmail.com>
 <CAGpPWDYi0Cqm7JjM5CuNOutA4UpDsQS_3Nta+SmVSPxe3jaOog@mail.gmail.com>
 <CAFvNmHQjVs02AncYmGUipwt9cG+QvHpimmuMwYT1wRoQ4HiNiw@mail.gmail.com>
 <CAGpPWDaUDeNNwBUELnQ0xUDSkDTWv6vgEqVu1Sg7uNWOkKM+_g@mail.gmail.com>
In-Reply-To: <CAGpPWDaUDeNNwBUELnQ0xUDSkDTWv6vgEqVu1Sg7uNWOkKM+_g@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Tue, 22 Jun 2021 19:40:19 +0100
Message-ID: <CAFvNmHT96AHwgcQejF+5QLdPVvLPEXFbsG5vP7tF7=AA3CzMKA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <billy.tetrud@gmail.com> 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 <michaelfolkson@gmail.co=
m> 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 <billy.tetrud@gmail.com> 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 <bitco=
in-dev@lists.linuxfoundation.org> 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