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.tet...@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 over a > window of X blocks. Its something any full node could easily keep track of. > And as long as hour-level or day-level granularity is acceptable, I wouldn't > think there'd be any need to incorporate mempool information (if that 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 <michaelfolk...@gmail.com> > 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.tet...@gmail.com> wrote: >> > >> > Thanks for the Summary Michael! >> > >> > It seems like fee-sensitive timelocks weren't discussed too much in the >> > 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 >> > would be a great way to substantially increase the resilience of the LN to >> > temporary periods of fee congestion, even potentially long-running periods >> > that last weeks. It might even help in non-temporary fee market increases >> > by giving 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 >> > <bitcoin-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/018841.html >> >> >> >> A reminder was posted to the bitcoin-dev mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html >> >> >> >> The conversation log for the workshop is here: >> >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> >> >> I’ll summarize what was discussed during the meeting but please 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 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’t >> >> 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’t 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’s lost funds went to the miner >> >> instead of the attacker isn’t 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’ 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 “evicttx” RPC to remove a transaction from the 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/019074.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. 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’t present a problem for them. There could well >> >> be engineering work required in advance of the possible change being >> >> made. >> >> >> >> Next week’s meeting >> >> >> >> Next week’s 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: michaelfolk...@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: michaelfolk...@gmail.com >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: michaelfolk...@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
