* [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support @ 2021-06-17 17:01 Michael Folkson 2021-06-22 18:01 ` Billy Tetrud 0 siblings, 1 reply; 5+ messages in thread From: Michael Folkson @ 2021-06-17 17:01 UTC (permalink / raw) To: Bitcoin Protocol Discussion 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: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support 2021-06-17 17:01 [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support Michael Folkson @ 2021-06-22 18:01 ` Billy Tetrud 2021-06-22 18:21 ` Michael Folkson 0 siblings, 1 reply; 5+ messages in thread From: Billy Tetrud @ 2021-06-22 18:01 UTC (permalink / raw) To: Michael Folkson, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5840 bytes --] 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: 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 > [-- Attachment #2: Type: text/html, Size: 7403 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support 2021-06-22 18:01 ` Billy Tetrud @ 2021-06-22 18:21 ` Michael Folkson 2021-06-22 18:26 ` Billy Tetrud 0 siblings, 1 reply; 5+ messages in thread From: Michael Folkson @ 2021-06-22 18:21 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion 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> 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: 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support 2021-06-22 18:21 ` Michael Folkson @ 2021-06-22 18:26 ` Billy Tetrud 2021-06-22 18:40 ` Michael Folkson 0 siblings, 1 reply; 5+ messages in thread From: Billy Tetrud @ 2021-06-22 18:26 UTC (permalink / raw) To: Michael Folkson; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7899 bytes --] > 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 <michaelfolkson@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.tetrud@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: 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 > [-- Attachment #2: Type: text/html, Size: 10347 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support 2021-06-22 18:26 ` Billy Tetrud @ 2021-06-22 18:40 ` Michael Folkson 0 siblings, 0 replies; 5+ messages in thread From: Michael Folkson @ 2021-06-22 18:40 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion 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 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 <michaelfolkson@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.tetrud@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: 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 -- Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-22 18:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-17 17:01 [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support Michael Folkson 2021-06-22 18:01 ` Billy Tetrud 2021-06-22 18:21 ` Michael Folkson 2021-06-22 18:26 ` Billy Tetrud 2021-06-22 18:40 ` Michael Folkson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox