meeting-logs

19:01 <@ariard> #startmeeting
19:01 < RubenSomsen> hi
19:01 < t-bast> hi everyone
19:01 <@ariard> welcome all, main motivation of those transaction relay workshops meetings is that more and more funds in the ecosysem are locked in L2s                                                                                                                                 
19:02 <@ariard> and those ones are relying on currently-super-weak assumptions around tx-relay/mempool behavior
19:02 <@ariard> which provoke a bunch of less-or-more funny security issues
19:03 <@ariard> 1st question: what are the security risks of non-propagating transactions for Lightnings/L2s ?
19:03 <@ariard> feel free to grab the mic if you have answers :)
19:03 < t-bast> easy answer: can be quite costly if controlled by an attacker :D
19:03 < gleb> One risk is missing the timelock window in which you can claim funds
19:03 < rgrant> are we asking about tx pinning or high fee rates clogging a mass exodus?
19:04 <@ariard> t-bast: what's the worst-case if your transaction propagation by an attacker?
19:04 < t-bast> not being able to get your htlc-success tx confirmed means those funds can be stolen
19:04 < harding> Well, if all transactions aren't propagating, that seems bad for everyone in Bitcoin.  :-)
19:04 < darosior> rgrant: about non-propagation, when your transaction doesn't get to miners' nodes through the P2P network.
19:04 < t-bast> so you can lose whatever is the max pending htlc value you allowed in that channel
19:04 <@ariard> rgrant: yep, we're talking abou pinning or high fee rates
19:04 < darosior> harding: yes for L2s it means direct loss of funds :/
19:04 < BlueMatt> harding: sure, but only lightning elevated it to a security assumption from a usability assumption :p
19:05 <@ariard> harding: good point, though what's the difference between regular transactions and time-sensitive ones (are pointed by gleb)
19:05 < darosior> (or reduction of assumptions, depending on the L2)
19:05 < harding> I think the problem is more selective propagation, where you can't get a transaction to a miner but maybe your counterparty can.                                                                                                                                        
19:05 < Chris_Stewart_5> In the case of DLCs, it can mean falling back to the refund clause of the DLC rather than the rightful settlement transaction being confirmed onchain                                                                                                           
19:06 <@ariard> harding: can you elaborate on this ? i would more qualify this when you have shared-utxo spent by pre-signed transactions
19:06 < gleb> harding: not necessarily, because it might be fine for an attacker to clog all transactions for X time (and benefit from it much later after X)                                                                                                                            
19:07 <@ariard> ihmo, the issue is when the "can't get a transaction to a miner" is controlled by your counterpary
19:07 < michaelfolkson> There is a non-ideal race whenever propagation unblocks (assuming widespread propagation blockage before)
19:07 < harding> ariard: if you can't propagate a transaction during a priviledged period of time, it's true that a timelock might expire, but that doesn't necessarily mean the attacker gets the funds---at that point, you can pay all to fees to deny them a profit.                 
19:07 < t-bast> good point, even though I agree with harding that the most common case is probably selective propagation delays
19:08 <@ariard> harding: right, but in practice in Lightning balance outputs are splitted from fee-bumping ones, at least with anchor
19:08 <@ariard> i mean i can't burn my htlc outputs to fees if we're approaching the end of the timelock window
19:09 < rgrant> https://bitcoinops.org/en/topics/transaction-pinning/
19:09 < harding> ariard: you could just give miners your private keys for the htlc outputs.
19:09 < darosior> harding: if you are able to re-sign the transaction, yes. Not the case for a watchtower and you might be offline (actually wallets are, most of the time, for vaults). And even again if your second transaction can propagate to the miner too..                      
19:09 <@ariard> further, your counterpary being able to draw you to burn your fee-bumping reserve is imo a DoS
19:10 < gleb> Do you guys think the time-locked issue is the only bad scenario, or are we missing something else?
19:10 <@ariard> rgrant: yep, see also t-bast's https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
19:10 < RubenSomsen> Fee-sensitive timelocks can help in theory, where the timelock gets delayed when fees are high
19:10 < gleb> My guess that everything else boils down to the general "tx propagation block" which also applies for l1 yeah
19:10 <@ariard> RubenSomsen: though about it, but you will need a softfork for this?
19:10 <@ariard> *thought
19:11 < RubenSomsen> Yeah, wouldn't know how to do it without a soft fork
19:11 < darosior> ariard: yes there is a weird incentive depending on how much you are going to feebump. It may incentivize a miner, knowing the code you run to always try to censor your transaction first for you to burn your fee reserve. But it's way less probable or a concern than regular propagation that we are discussing, still :)
19:11 < freddie_kr> wouldn't that break some lightning assumptions?
19:11 <@ariard> rgrant: yep, see https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
19:11 < freddie_kr> you'd need to change all of your time locks based on fee env, sounds messy
19:11 < harding> darosior: if there's any possible series of transaction where a private key will be able to spend all of your funds, you can give miners all that information to motivate them to prevent your attacker from receiving stolen funds.                                    
19:11 < gleb> darosior: again, miners can also do same to the regular bitcoin txs? :)
19:12 <@ariard> darosior: yep, miner attacks on L2s we still have few years to whistle
19:12 < t-bast> gleb: I think it's only time-locked related, but it can be done indirectly by delaying the parent (LN commit tx) of a child CLTV tx - not sure this subtlety is important, but worth mentioning                                                                          
19:12 <@ariard> harding: it does assume some kind of perfect communication broadcast to all miners
19:12 <@ariard> and bitcoin protocol assumes that miners can join the set of PoW signers at anytime?
19:12 < darosior> gleb: yes. But eg as a WT you are way more inclined to burn more in fees (and your algo is likely public) if otherwise it means fund loss! (rather than usability loss)                                                                                                
19:13 <@ariard> t-bast: this is super important, i've far more worried with pinning at the commitment-level, rather than htlc-level one
19:13 < harding> ariard: sure, although if you have a long time left in your timelock, you only need communication with a subset of miners.
19:14 < harding> Sorry if I'm dragging the conversation off topic; burning all in fees is a bad outcome, it's just less bad than letting the attacker succeed.                                                                                                                           
19:14 < t-bast> ariard: indeed, in effect blocking the commit tx affects *all* its child delayed txs (at least when they use an absolute delay). So block one tx, get many txs worth of stolen funds                                                                                     
19:14 <@ariard> harding: not really it's quite the 2nd question
19:14 < darosior> harding: yes but if you burn too much you incentivize them to censor the first non-feebumped tx.
19:14 <@ariard> Can we amend Lightning and other contract protocols to reduce reliance on non-normative rules ?
19:15 < llfourn> what is a "non-normative" rule?
19:15 < t-bast> harding: I agree on the scorched earth principle, if honest participants have a way to burn the funds instead of letting them go to the attacker, it's slightly better (but still far from ideal)                                                                        
19:15 < gleb> can you define a non-normative rule?
19:15 <@ariard> harding: one pitfall i see to this approach, to make the scortched approach more efficient you have an interest to disclose the private key as early as possible                                                                                                         
19:15 < harding> darosior: yes, maybe.  In that case, individual miners are working against each other (intsead of being uniformly motivated to mine the highest-fee tx).                                                                                                                
19:16 <@ariard> llfourn: a rule which isn't considered as consensus by _your_ node
19:16 <@ariard> harding: and as same time, as a LN node you might try redundant broadcast, fee-bumping as the timelocks is coming closer to expiration                                                                                                                                   
19:16 < llfourn> yes I think LN needs to be secure under the Bitcoin protocol!
19:16 < gleb> In other words, can we make Lightning not rely on network broadcast?
19:16 < Chris_Stewart_5> policy or consensus ariard ?
19:16 < darosior> Chris_Stewart_5: typically policy
19:17 < llfourn> with mempool eviction rules and fee bumping included in
19:17 <@ariard> remember you don't have perfect knwoledge why the transaction is not confirming, it might be an internet outage, in that case bad idea to disclose private keys                                                                                                          
19:17 < harding> ariard: indeed, although only if you worry that you'll only have access to a small subset of miners.  If you think you'll have access to most miners, then a pay-all-to-fee transaction should be quite profitable and so be mined quickly.                             
19:17 < michaelfolkson> harding: I would disagree. If I'm losing all my money I don't really care who I lose it to. Only way it is better is if it disincentivizes the attack
19:17 <@ariard> Chris_Stewart_5: yes, imo non-normative rule is a policy one
19:18 < darosior> harding: pay-all-to-fee is not doable for all L2s
19:18 < darosior> And is a slippery slope
19:18 <@ariard> michaelfolkson: that's a good point, it increases incentives for a miner to attack L2s
19:18 < harding> michaelfolkson: that's very game theoretic logical of you; I don't think I've ever met someone before who would prefer their attacker get the proceeds than other people who are positively supporting the system (miners in this case).
19:19 < t-bast> the issue with pay-all-to-fee is that all miners have an incentive to *not* mine transactions (unless blocks aren't full) to wait for a potential pay-all-to-fee
19:19 <@ariard> gleb: we talk about some kind of tx-relay overlay deployed by LN node, like reuse LN communications but you still have issues with bridging to miners
19:19 < harding> darosior: it's fundamentally possible if you can disclose your private keys for the same ultimate effect.
19:19 <@ariard> proposed by cdecker a while back
19:19 < darosior> harding: you need availability of the signers in order to do that
19:20 < michaelfolkson> harding: Not prefer attacker gets it, just totally indifferent
19:20 <@ariard> and bypass the csv timelocks with current lightning design?
19:20 < harding> darosior: oh, you mean pay-all-utxo-value to fee?  I mean pay all of your balance to fee.
19:20 < freddie_kr> ariad: how would tx relay overlay on LN help if those txns eventually need to get back into mempools? we could send txns all across the LN network, but if they don't meet RBF checks then they won't be accepted anyway
19:20 < glozow> ariard: do u have a link to that tx relay overlay proposal? i’m interested
19:20 < harding> michaelfolkson: ok, my point stands; I don't think I've ever met anyone that indifferent.
19:20 <@ariard> glozow: will find old lightning-dev logs after the meeting :)
19:20 < darosior> harding: oh, all your fee-bumping wallet balance? Sorry, i misunderstood. Then it's doable but still need a lot of care as it could be exploited by a miner.
19:21 < glozow> ariard: thank you!
19:21 <@ariard> freddie_kr: yes that's the issue with bridging to miners, ultimately your transaction have to be accepted by miners
19:21 < Chris_Stewart_5> harding: I don't think this works with protocols with a predetermined tx graph (DLC). you don't have the option to pay "your balance" until a settlement tx or refund tx has been confirmed, and in that case, why do it? 
19:21 < t-bast> the high-level idea for l2 relay is simple, you send txs to your peers over LN messages, they add it to their bitcoin node's mempool (or not) and propagate to their LN peers as well
19:21 < t-bast> but it requires miners to be on that network to be useful
19:22 < harding> darosior: sorry, I'm thinking of the case where Mallory and Bob have a payment channel; Mallory is doing some shenanigans to prevent it from closing in the proper state; Bob can spend all to fee by simply giving miners the private key needed to claim his HTLC output.
19:22 < Chris_Stewart_5> In the case of DLC, my goal as the losing party is to censor the settlement tx for as long as possible, so i can broadcast the timelocked refund tx
19:22 < darosior> harding: ok so it's payment channel specific. Yes, i agree that it's better game theory wise.
19:23 <@ariard> t-bast: yep, maybe delay propagation to your mempool as it can be privacy-breaking, but as i don't think we discuss further than that
19:23 < freddie_kr> t-bast: wouldn't that bump bandwidth requirements quite a lot? we need to relay every tx on LN, because we don't know what will be attacked, and are probably also being relayed by our bitcoin nodes?
19:23 < darosior> But in practice..
19:23 <@ariard> harding: still how do you know that Mallory is doing shenanigans and that's not another issue, like your transction not meeting the mempool min feerate
19:23 < t-bast> freddie_kr: yes, each node would probabilistically relay, or allocate some predefined bandwidth, so it's quite imperfect, it doesn't give you any guarantee that it will reach miners
19:24 < harding> Chris_Stewart_5: maybe you're right, but I'm doubtful.  I'd be happy to discuss scenarios after the meeting where I have time to diagram stuff out in ascii art.
19:24 < Chris_Stewart_5> harding: :+1:
19:24 <@ariard> harding: also a concern with multi-party output?
19:25 < harding> ariard: I can't guarantee that you would know, but there are ways you might know, e.g. by monitoring your own mempool or asking other users via bitcoin or (e.g.) LN P2P query or something.
19:25 < freddie_kr> t-bast: I see, wouldn't some of the concerns about attackers partitioning mempools transfer to this new relay layer, just based on bandwidth?
19:25 <@ariard> harding: if you want to take time about drawing out a sound proposal, as it's quite a divergence from current LN, i would be glad to do an in-depth review :)
19:25 < t-bast> freddie_kr: yes it would, TBH I'm quite doubtful that this L2-relay really helps
19:26 < harding> ariard: nope!
19:26 < harding> :-)
19:26 < freddie_kr> t-bast: thanks for clarifying!
19:26 <@ariard> okay, if no one wants this a new Lightning/L2 security model, personnally i'm not going to propose it
19:26 <@ariard> :)
19:27 < harding> I do think we should be using miners profit incentive more for stuff rather than trying to normalize mempool policy (which not entirely possible), e.g. things like https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
19:27 <@ariard> harding: i agree we should keep mempool policy tight, but we still have the mempool min feerate issue to consider for transaction with pre-signed feerate
19:28 <@ariard> which can happen even without adverserial setting
19:28 < t-bast> harding: I liked that idea a lot, but how likely is it that miners would both running custom code to claim those?
19:28 < darosior> Or even just RBF.
19:28 < t-bast> *would bother
19:28 < harding> Sorry, I'm not sure what problem that is.  ariard
19:28 < Chris_Stewart_5> I think i disagree with that idea. using miners for profit incentive leads to a zero sum game for you and your counterparty. You both end up paying all hte money in fees to the miner
19:28 < harding> t-bast: depends how much money is in it for them, I suspect.
19:28 < Chris_Stewart_5> In the worst case, that is better than giving your counterparty everything, but it is negilibly better because i have no money
19:28 < darosior> Chris_Stewart_5: which incentives them to not attack you in the first place
19:28 < harding> t-bast: it took them a few weeks to run taproot and there was no direct incentive for that.
19:28 < t-bast> Chris_Steward_5: an interesting twist on this is that it incentivizes layer 2 players to also be miners and benefit here
19:29 <@ariard> harding: Let's say mempools are congestioned and you're able to broadcast a commitment transaction with pre-signed feerate as it's under most of network min feerate
19:29 < harding> ariard: ah, ok.
19:29 <@ariard> at the same time you do have a HTLC to cancel backward as you're a LN routing node
19:29 < t-bast> harding: true, but here if that only happens under attacks and is meant to prevent it, it's likely they will almost never benefit from it
19:29 < harding> I'd call that the presiged feerate problem.
19:29 <@ariard> harding: i think this can happen, even without assuming backward/forward node being malicious ?
19:29 < harding> presigned*
19:30 <@ariard> yep this one
19:30 < Chris_Stewart_5> darosior: Who? Your counterparty? It depends on the stakes and the risk-reward ratio for your counterparty to attack you. For instance, in a Lighnting channel with all the liquidity  on my side, the counterparty has a strong incentive to attack me. 
19:30 < darosior> Like the name :) But even if you don't entirely pre-sign the feerate (eg ANYONECANPAY) you still rely on policy for a feebumped transaction to relay toward the miners.
19:31 <@ariard> right, you still rely on them to apply some kind of replace-by-fee
19:31 < darosior> Chris_Stewart_5: right, but it's more in the DOS category than the theft one then (since they don't expect to gain anything). But i see your point 
19:32  * darosior looks for the current topic question
19:32 < harding> t-bast: maybe.  OTOH, what if every mining pool in the future is making its miner payouts in LN and also using that large volume of channels to serve as a highly-used routing node?  Then they have an incentive to run LN-network-protecting software.
19:32 < Chris_Stewart_5> darosior: I think it is most certaintly theft. They are broadcasting a revoked state and are using their leverage as they have little to lose and a lot to gain. This is why the lightning spec requires (still hopefully?) certain amounts of balances on each side of the channel 
19:33 <@ariard> does anyone think we can remove any assumption from mempool behavior to make secure L2s?
19:33 < harding> (I'm not sure what we're talking about any more, I'm going to quiet down for five minutes so others can talk.)
19:33 <@ariard> let's move to next question so
19:33 < darosior> Chris_Stewart_5: yes it's still present in the spec
19:34 <@ariard> if we agree that tx-relay/mempool rules are critical for L2s, how to increase transparency and stability of those ones across the ecosystem?
19:34 <@ariard> Or should L2s deploy their own overlay networks and lobby miners to have mempools compatible with their protocol
19:35 < t-bast> ariard: I think that not relying on mempool behavior at all would be a great goal to achieve but is probably too limiting
19:36 < llfourn> We really want to do a good job of making L1 work well for L2 without extra assumptions about miners and overlay networks IMO
19:36 < Chris_Stewart_5> So my understanding (haven't actually done this myself) is bitcoin core supports testmempoolaccept rpcs now? Are breaking changes to this documented in release notes? (forgive me if obvious answer)
19:36 <@ariard> t-bast: but i think ultimately we can't as blockspace demand is dynamic, you should be always ready to fee-bump, and you need at least a minimal fee-bumping policy supported across the network
19:36 < darosior> To answer the question, i believe that in the long run alternate propagation networks that are hopefully not private (for fee estimate) nor centralized (for obvious DOS issue) would help since we can't rely on the policy of a single propagation network.
19:36 <@ariard> let's say we want to mimize CVE-2020-26895 kind of bugs in the future, what is required?
19:36 < t-bast> ariard: yes I agree, we do need assumptions here otherwise there isn't much we can build
19:37 < Chris_Stewart_5> ariard: link please?
19:37 < glozow> imo mempool behavior should aim to be as compatible with what miners what as possible, miners should be getting the transactions they want when tx relay is working properly
19:37 <@ariard> to remember, lnd's high-s sig
19:37 <@ariard> Chris_Stewart_5: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html
19:37 < llfourn> ariard: write software correctly :)
19:37 < Chris_Stewart_5> llfourn: ugh! I've been doing it wrong all these years :P
19:37 < darosior> ariard: a comprehensive list of assumption in order to be able to reason about and review code that rely on them.
19:38 < freddie_kr> darosior: what would a public, decentralised relay layer look like that's different to the mempool? surely we just run into the same issues
19:38 < prayank> ariard: CVE could have been avoided if BIP was implemented without changes. Not sure of this is offtopic but I still don't know why is inherited signalling not implemented?
19:38 < harding> I think LN as currently designed has a significant advantage over current mempools by assocating an identity with non-trivial cost with each node.
19:38 < darosior> ariard: this list, if shared among the growing ecosystem of L2s, could also benefit as an advertisement that base layer could politely try not to break
19:38 <@ariard> darosior: here one assumption : a user should be able to verify "future" acceptance of its transaction by the mempool
19:38 < Chris_Stewart_5> I think we as a L2 community should really encourage new L2 devs to write automated regression test suites against bitcoind exposed rpc commands. I'm a little surprised that the CVE ariard linked was not caught by this
19:39 < michaelfolkson> glozow: And miners want to receive all transactions so they can choose which ones to include in a block? Or miners want the transactions with the max total fees?
19:39 <@ariard> prayank: read the link, that's another CVE :/
19:39 < darosior> ariard: which one tho :p
19:39 < Chris_Stewart_5> It also requires you to write new test harnesses for _new_ versions of bitcoind 
19:39 < harding> That identity makes it an appealing choice for an overlay network that can carry transactions which could be used as DoSes against a identityless systems like bitcoind.
19:39 < _aj_> freddie_kr: an L2-specific layer could take into account L2 logic to prevent spam, while the L1-mempool layer has to be more generic
19:39 < darosior> RPC is quite limited. I recommended functional test with regtest setups simulating the different scenarii
19:39 < prayank> ariard: Okay I thought you mentioned inherited signalling
19:40 <@ariard> glozow: what transactions miners "wants" ? intuitevely i would say one with a higher-feerate, and this assumption might not be respected with current LN
19:40 < _aj_> freddie_kr: eg, L2 logic might say "this is a penalty tx over an invalid lightning close, there won't be any more replacements, so who cares if it's only 0.1 sat/vbyte more in fee rate" when the generic L1 layer couldn't say that
19:40 < glozow> michaelfolkson: ariard: yes i mean, best as in highest fee. package relay remedies the fact that smaller mempools will not always have the transactions with the best fees.
19:41 <@ariard> Chris_Stewart_5: you have no way to test mempool acceptance of timelocked transactions rightn now but glozow is working on it
19:41 < glozow> ^ya
19:41 < darosior> s/recommended/recommend/ typo
19:41 < Chris_Stewart_5> darosior: If I understand the CVE that ariard linked to, this should have been caught by simple automated tests no? I also think encouraging the community to write automated test suites, we will see some best practices emerge. I guess this forces people to formalize (and yell loudly hopefully!) when bitcoind introduces new changes to policy
19:41 <@ariard> darosior: yes i agree on a conservative list of assumptions which can serve as a bedrock for L2 design and being enforced as policy by the base layer
19:42 < freddie_kr> _aj_: right, but once we get down to base layer the mempool is indifferent. So the idea would be to assist spreading the penalty tx as quickly as possible?
19:42 < darosior> Chris_Stewart_5: yes, good point actually we should probably be testing against "bitcoind-nightly" (latest master) in integration tests so that we can yell loudly before it's released and used on the network :p
19:42 <@ariard> Chris_Stewart_5: i had a standardness bug in RL too, and wasn't able to test it because libbitcoin_consensus doesn't export standards flag right now
19:42 < t-bast> But if we design and deploy a lightning tx broadcast overlay network, and get miners to run software to receive txs over that propagation network, what happens for other L2 protocols? We can't have 1 propagation network per L2 protocol...
19:43 <@ariard> Chris_Stewart_5: see https://github.com/bitcoin/bitcoin/pull/18797
19:43 < harding> t-bast: you only need an overlay network when the regular bitcoind network is insufficient.
19:43 < freddie_kr> Does anybody know of libraries/ projects that allow easy testing of L2 solutions against different fee environments? I'd be interested to know what the various projects do.
19:43 < darosior> ariard: testmempoolaccept soon-to-be the libbitcoinconsensus of standardness rules :p
19:43 < t-bast> harding: yes but you need miners to be on all relay networks, which is unlikely, isn't it?
19:43 <@ariard> darosior: 2 weeks :p
19:44 < darosior> freddie_kr: i stole C-lightning's functional test suite FWIW. Bitcoin Core has a nice one too.
19:44 < Chris_Stewart_5> it is nice to hear you are working on this glozow . I think that would be valuable
19:44 <@ariard> t-bast: yes the "we can't have 2 propagation network per L2 protocol" is the main reason to have a shared list of assumptions implemented by the base layer
19:44 < freddie_kr> darosior: thx, will check them out!
19:44 < harding> t-bast: you could use the overlay network to short-circuit relay policy between regular routing nodes, e.g. think about it in comparison with amiti's work on tx rebroadcasting logic.
19:44 <@ariard> beyond benefiting of current decentralization of tx-relay network
19:45 < _aj_> ariard: there isn't really a shared list of assumptions at the base layer, though -- every node can have a different policy. can certainly have some recommendations on what's sensible though...
19:46 < Chris_Stewart_5> glozow: i think a set of test rpcs to "set bitcoind network state (full mempool, certain block height etc)" would be very valuable. Maybe timelocks are the first iteration of that. Just my 2 sats
19:46 <@ariard> _aj_: and that's the big question, should we draw out a shared list of assumptions, which is ultimately enforced as a social layer, in the sense of a mempool acceptance API, clearly documented in Core
19:47 <@ariard> doesn't mean you can diverge from it, but you're going to loose economic traffic of L2 if you do so
19:47 < michaelfolkson> Chris_Stewart_5: Or full blocks on Signet with a resulting fee market
19:47 < glozow> Chris_Stewart_5: i think what i’m aiming for (suggested by harding) will allow an absolute height/MTP input by user, and diable relative timelocks between txns in the package
19:47 < t-bast> Chris_Stewart_5: something that I've found lacking in bitcoind RPCs when testing its behavior is an "evicttx" RPC to remove a transaction from the mempool on regtest
19:47 <@ariard> like i'm not going to use your full-node implementation if undocumented mempool changes are realized at each release
19:48 <@ariard> Chris_Stewart_5: actually you may also bypass feerate, for e.g 2nd stage HTLC outputs pairs are signed with 0-fee in lastest version of anchor iirc
19:49 < harding> ariard: I find it unlikely that standardized node mempool policy is going to be a feature users highly rank when choosing between different full nodes.  Even if it is, the software implementing the non-standard choices will probably spin it as better.
19:50 < michaelfolkson> harding: Agreed
19:50 < darosior> ariard: +1. But you can also have opinionated implementations, and that's why i think we need alternative propagation networks as the Bitcoin network could become less reliable for policy if some opinionated re-implementation of the P2P layer start being used. That would be arguably good for Bitcoin (if they use something like libbitcoin kernel
19:50 < darosior> work for consensus, obviously) but not so good for the assumptions of L2s.
19:51 < darosior> Yes, agree with harding.
19:51 <@ariard> harding: let's turn the question from a base-layer viewpoint, what should you do when you're changing the mempool and it lowers the security of any Bitcoin application/L2s ?
19:51 < Chris_Stewart_5> My understanding with some of the privacy work done around propogatin on bitcoin core can actually negatively affect propogation times for time sensistive L2s. Does anyone have thoughts on this? How do we balance these two use cases
19:52 < Chris_Stewart_5> maybe this is a repeat
19:52 < llfourn8> harding: so far most nodes are running standard rules so there is reason to be optimistic?
19:52 < harding> ariard: write a weekly newsletter that reports on any major changes to bitcoind's policy so that L2 developers can offer input into them and, if necessary, change their software.  Or at least that sounds something like an idea I once had...
19:52 < darosior> Chris_Stewart_5: it's already the case, see the mempool partition example on ariard's mail(s)
19:52 < _aj_> ariard: the only benefit most nodes get from relaying is "i relay their txs, so they relay mine" and "i know about the txs before the block arrives so i get the block faster" ; and the tradeoff is "i don't want to waste bw/cpu validating txs that will never get mined" ; not really an economic consideration unless you're a miner ; and miners just want high fee rates, and quick propogation to other 
19:52 < _aj_> miners?
19:52 < t-bast> If we want to go down alternative propagation, why not simply have mining pools expose public APIs to push them txs?
19:53 < darosior> Chris_Stewart_5: ie you should already today modify your bitcoind to aggressively broadcast if you want to not give the advantage for propagation to the attacker (who is going to do that) 
19:53 < darosior> (in theory)
19:53 < harding> t-bast: that seems likely to result in mining centralization due to software only contacting the APIs of the largest mining pools.
19:53 <@ariard> harding: and i'm really thankful for this, but in practice bitcoind's changes are going to be merged then L2s devs are going to be aware about them, and doesn't solve the issue about emergency changes ?
19:54 < darosior> t-bast: what harding said + less reliable fee estimation for everyone
19:54 < harding> ariard: emergency changes are emergencies; you have to hope the people handling those are professional and will reach out, but there's nothing you can do otherwise.
19:55 <@ariard> _aj_: i agree on the benefits you're mentioning, but i'll add another one, "i improve my fee-estimation by guessing block demand"
19:55 < michaelfolkson> ariard: L2 devs are effectively consulted unless it is an emergency change. In which case Core devs have deemed it is more important to fix than have long consultation process?
19:55 < _aj_> ariard: there's generally a fair time between "change gets merged" and "change is in a release" and "change is widely deployed on the p2p network" though, and plenty of opportunity to revert the change before it's in a release
19:55 < glozow> _aj_: i agree. economic consideration is “i want to know which txns miners will mine, and miners have economic considerations”
19:56 < t-bast> darosior: agree on the centralization, but the less reliable fee estimation is a drawback of *any* alternative propagation network, isn't it?
19:56 < michaelfolkson> Again I agree with harding. Other than information distribution and wide discussion there doesn't seem to be anything else to be done
19:56 < darosior> t-bast: at least you could aggregate. If the data is private and not available, you are doomed
19:57 <@ariard> _aj_: right, assuming you've enough eyes to catch that's a safety-critical codepath for someone with a deployed ecosystem on top of it
19:58 < Chris_Stewart_5> I think the nightly bitcoind build idea could be interesting. This gives L2 devs a way to write regression tests against the latest builds of bitcoind. Who knows if anyone will actually do it though. For all i know, these nightlies are already publish :man_shrugging:
19:58 <@ariard> harding: w.r.t to emergency, there is a really open question, "how do we know which protocols are affected?"
19:58 < harding> ariard: we don't, we can't.
19:59 <@ariard> harding: and imo that's where a list of shared assumptions will be helpful, just check anything which is relying on it, shrug about the rest
19:59 < harding> ariard: and we usually don't need to, that's the advantage of developing in the open.  If there's an emergency, then again all you can do is hope that the person who needs the information receives it.
20:00 <@ariard> harding: right, bitcoin is a permissible system, you can't constrain folks to build stuff on weak assumptions but maybe you can nudge them towards on a more reliable subset ?
20:01 < harding> ariard: if you're desingin a L2 protocol that's really worried about emeregency changes to mempool policy, what you can probably do is design around really long timelocks, that way when you learn about the emergency change, you still have weeks or months to get it fixed before things fall apart.  But if you're going to use timelocks on the order of hours or days, then you're implicitly vulnerable to node emergencies.
20:02 < _aj_> harding: you can run your own network of nodes that you don't upgrade, and do try to connect to at least some miners?
20:02 <@ariard> harding: yep but my position you can do far better there if yhe L2 protocol is build with a dynamic upgrade mechanism and the base-layer project do have a reall security policy to pre-disclose patch if it touches sensible areas
20:02 < harding> ariard: your main concern seems to be Bitcoin Core developers changing mempool policy and rolling it out, but even in the case of emergency roll outs like 0.16.2 (?), it took weekes before that node become the majority of the network.  Mempool isn't changing that fast in general.
20:02 < harding> (Unless it's the case that a bunch of nodes are DoS'd into oblivion).
20:03 < rgrant> I'd also like to promote OP_VER as changing some censorship/pinning issues: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
20:03 < harding> s/Mempool isn't changing that fast/Mempool *policy* isn't changing that fast/
20:03 <@ariard> harding: let's say we introduce some really-nasty DoS in package-relay and we have to deploy in emergency on the base-layer, how to minimize windblows for L2s?
20:03 < harding> ariard: ask L2 devs for help.
20:03 < harding> I don't think I have anything to add on this topic.
20:04 <@ariard> because you have the other concern of LN node operators mass closing channels, and congestioning the mempool
20:05 < darosior> Let's move to the next question?
20:06 <@ariard> darosior: yep, sure i think it was a set of "tx-relay" assumptions a L2 protocol designer could rely on, and specifically a path to realize them in practice
20:06 <@ariard> but i think we have a lot of divergence on this subject
20:07 <@ariard> before to switch to full-rbf, on coordinated security disclosure, as any L2 dev input on how to ease them :) ?
20:08 < darosior> I have no idea personally. Do you?
20:08 <@ariard> for e.g, should bitcoin core has a security bulletin process when you have security issues affecting downstream projects
20:09 <@ariard> darosior: well reverse-engineering L2 protocol in my free-time https://github.com/ariard/L2-zoology/tree/master/protocols
20:09 <@ariard> to guess when something is broken :p
20:09 <@ariard> okay let's switch to full-rbf
20:10 <@ariard> w.r.t to current RBF policy as documented by BIP125, i think it's raising issues for multi-party funded transactions
20:10 <@ariard> as explained here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
20:10 < darosior> On the coordination for disclosure, maybe this list of assumptions shared by all L2s could also contain some contact info of L2s with non-trivial amount of funds locked in on mainnet?
20:11 < rgrant> darosior: the hit list
20:11 <@ariard> darosior: that's my thinking, maybe a special security ml with those folks on it, more a thing to talk about during core meetings
20:12 < darosior> Yes and to submit to alternate implementations, if some ever emerge :)
20:12 <@ariard> imho it's a matter of each full-node project to have a security policy for downstream projects
20:12 < darosior> Yes
20:13 < michaelfolkson> Having not been involved in the security disclosure process but knowing how fiendishly difficult it is I don't have any educated opinions :)
20:13 < BlueMatt> ariard: full-rbf doesn't really materially impact the security model of most l2s, though? Especially without package relay.
20:14 < harding> I'm all in favor of full-rbf, or this as an intermediate https://github.com/bitcoin/bitcoin/pull/10823 , but what BlueMatt said.
20:14 < darosior> BlueMatt: iirc it impacted DLCs? Not sure, mostly repeating
20:14 <@ariard> BlueMatt: easing malicious mempool-partitions, i've an attack scenario here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
20:14 < darosior> Oh sorry
20:14 < darosior> I was confused.
20:14 < BlueMatt> ariard: you can still very, very trivially create mempool partitions
20:14 <@ariard> and likely a building block for attacks on fee-estimator in the futuee
20:14 < BlueMatt> ariard: I dont see how full-rbf changes that
20:14 < BlueMatt> as much as I like full-rbf
20:15  * BlueMatt -> bbl
20:15 <@ariard> BlueMatt: at least now you're conflicting transactions must have the same feerate level
20:15 < BlueMatt> i mean its just not complicated to do the same attacks w/o full rbf
20:15 <@ariard> so it increases the cost for an attacker, though i agree i've never had time to dig deeply into this and come up with numbers on what is realizable
20:16 <@ariard> BlueMatt: yeah my thinking we might have to care about mempool partitions in the future as it can damage L2s but maybe too an early phenomena (as i said in my full-rbf proposal this afernoon)
20:17 <@ariard> anyway, what's folks thinking on full-rbf in general ?
20:18 < t-bast> From an L2 dev's point of view I'm leaning towards it, but I haven't thought hard enough on the potential downsides for bandwidth or partitions
20:18 < BlueMatt> ariard: full-rbf does not at all change the ability of an attacker to create a mempool partition
20:18 < michaelfolkson> ariard: What are the arguments against? Which businesses are still using zero conf and might oppose this?
20:19 < rgrant> slimming pull/10823, i didn't find a reason it wasn't merged.
20:19 <@ariard> BlueMatt: i don't pretend it removes the ability of an attacker to create a mempool partition, it just reduce out of its toolbox the cheapest trick (opt-out from RBF)
20:19 < BlueMatt> ariard: again, I dont think it is even the cheapest trick.
20:20 < BlueMatt> I agree we should do it, but I dont think it factors into this conversation in the slightest.
20:20 < rgrant> michaelfolkson: BitPay was a vocal opponent to RBF, if i recall.
20:20 < michaelfolkson> rgrant: That was a long time ago. Are some of the Lightning onboarding services using zero conf?
20:21 <@ariard> BlueMatt: yeah policy divergence from a version to another one? well opt-out RBF is the cheapest trick, widely playable against the majority of the network i can think of
20:21 < darosior> michaelfolkson: Bitrefill iirc
20:21 < BlueMatt> ariard: same-fee two transactions?
20:21 < michaelfolkson> darosior: Yeah I had heard that
20:21 < BlueMatt> as long as rbf has *a* feerate increase minimum (which it always will), you can trivially split the mempool by just broadcasting two conflicting transactions with the same fee
20:21 <@ariard> BlueMatt: opt-out RBF is cheaper, the opt-out RBF transactions in network mempols can have a far lower fee than the ones seen in miner mempols?
20:22 < BlueMatt> maybe? but only very marginally. also policy divergence, yes, plus chain limits, etc,e tc
20:22 < BlueMatt> maybe it costs a few more transactions, but thats not a lot at all
20:23 < t-bast> michaelfolkson: we are using 0-conf in Phoenix, on funding transactions *we* make, so the user trusts that we won't double-spend - having full-rbf doesn't impact us negatively at all
20:23 <@ariard> michaelfolkson: it's a bit easier to trigger double-spend attack against services relying on zero-conf, though the easiness is defined here by a pure engineering cost of writing down a correct toolchain to mass-connect and broadcast conflicting transactions
20:23 < BlueMatt> not to mention we'll find more bugs in core if we try to assume that transactions that an attacker controls/can build a package of/can rbf are expected to be replacable
20:23 < BlueMatt> I just dont think core will ever be in a position to "support" that
20:23 <@ariard> BlueMatt: i know there is a lot of way to partition mempools, if anyone has time to do security research i can share how you can attack a LN node from then
20:23 < rgrant> what i'd like to see in discussions like these (nothing against the present organizers - just stating to get the idea out) is a collaboratively edited document with known reasons for and against specific proposals.  i know we're gathering knowledge and requirements now, but i feel like things get lost in the wall of text.
20:24 <@ariard> rgrant: i shared a proposal on the ml this afternoon with more context : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
20:25 <@ariard> rgrant: i'll edit meetings logs and keep track of for/against arguments :)
20:25 < rgrant> ariard: somehow i missed the link, so thanks!  
20:26 <@ariard> okay we'll see if anyone yells against full-rbf this time, proposing the change a year from now should let time for services to adapt
20:26 <@ariard> i think we're approaching the end of the meeting
20:27 <@ariard> next week, we'll focus on package-relay, unless the conclusion of this meeting is Core mempool should be extended at all to support L2 :p
20:27 < michaelfolkson> Contacting the businesses too, good to hear that Phoenix not impacted
20:28 <@ariard> michaelfolkson: yep on my todo to contact known business relying on zero-confs in a strong way
20:28 < glozow> we're allll 👏 in this 👏 together
20:28 <@ariard> #endmeeting