package-relay-meeting-log.txt

[2021-06-22 19:00:47] <ariard> hi
[2021-06-22 19:00:52] <glozow> hi!
[2021-06-22 19:00:54] <harding> hi
[2021-06-22 19:00:54] <suredbits> hi
[2021-06-22 19:00:58] <michaelfolkson> hi
[2021-06-22 19:01:01] <t-bast> hi!
[2021-06-22 19:01:13] <ariard> #startmeeting
[2021-06-22 19:01:22] * suredbits → Chris_Stewart_5
[2021-06-22 19:01:28] <darosior> hi
[2021-06-22 19:02:23] <ariard> will try to do a different meeting format, like sharing the question and give time to everyone to share their thoughts?
[2021-06-22 19:02:39] <glozow> sounds good!
[2021-06-22 19:02:58] <t-bast> sgtm
[2021-06-22 19:03:07] <harding> +1
[2021-06-22 19:03:11] <ariard> what problem(s) package-relay aim to solve at the base-layer :) ?
[2021-06-22 19:03:52] → rgrant joined (~rgrant@user/rgrant)
[2021-06-22 19:03:53] <ariard> (feel free to take the mic!)
[2021-06-22 19:04:19] <rgrant> hi
[2021-06-22 19:04:26] <michaelfolkson> A CPFP transaction not making into a block speedily to make sure a justice transaction gets confirmed
[2021-06-22 19:04:54] <glozow> i see package relay as a way of correcting current limitations wrt evaluating transactions as candidates for mempool. namely, that we want the best transactions in our mempool, but we aren't always able to see their true feerate by looking at them one at a time
[2021-06-22 19:04:57] <t-bast> A simple problem that comes to mind is allowing the recipient of a tx to fee bump that tx without the sender having to do anything, in all cases (initial tx fee below mempool min fee)
[2021-06-22 19:05:00] <darosior> Avoid rejecting a set of transactions from your mempool that could be included in a block by a rationale miner
[2021-06-22 19:05:06] <glozow> (best being, what miners want)
[2021-06-22 19:05:36] <t-bast> I like darosior's way of putting it
[2021-06-22 19:05:53] <Chris_Stewart_5> When you want a utxo to have a series of state transitions to happen atomically
[2021-06-22 19:06:25] <harding> Chris_Stewart_5: hmm, I don't actually like that definition.  I don't think package relay can help with that.
[2021-06-22 19:06:51] <harding> I.e., it's always possible for the parent to be confirmed without the child even if that's not fee-rational.
[2021-06-22 19:06:53] <rgrant> i would define package relay as small hints for what's otherwise a hard-to-compute problem.
[2021-06-22 19:07:04] <Chris_Stewart_5> from an application developer perspective, that is what i want
[2021-06-22 19:07:06] <ariard> to me, i think package-relay can help to propagate branch of transactions with a low-feerate root
[2021-06-22 19:07:38] <Chris_Stewart_5> if this isn't for app devs, then ignore me :-)
[2021-06-22 19:07:50] <harding> Chris_Stewart_5: oh, sure, atomicity guarantees are always a nice thing to have; I just don't think it's possible for package relay to provide that.
[2021-06-22 19:07:50] <ariard> rgrant: can you explain more :) ?
[2021-06-22 19:08:10] <michaelfolkson> Chris_Stewart_5: What is an example of the state transitions? A UTXO is either locked/unlocked or unspent/spent?
[2021-06-22 19:08:53] <Chris_Stewart_5> michaelfolkson: funding tx -> commitment tx -> htlc txs is an example IMO. In DLC world, funding tx -> CET (contract execution tx)
[2021-06-22 19:09:20] <michaelfolkson> Oh ok, so chains of transactions basically
[2021-06-22 19:09:23] <glozow> Chris_Stewart_5: I'm here because I want to hear what devs building on top of bitcoin core want from package relay
[2021-06-22 19:09:37] <harding> Chris_Stewart_5: it certainly is for application developers; I just don't know how to achieve what I think you want.
[2021-06-22 19:09:45] <t-bast> Chris_Stewart_5: but do you mean that you'd want the whole chain of txs to be confirmed in the same block?
[2021-06-22 19:09:46] <rgrant> ariard: first, i too like darosior's definition, but in addition to that package relay is a way for someone to suggest a set that algorithms would otherwise need to be searching for.
[2021-06-22 19:09:47] <Chris_Stewart_5> I think my definition might be a little incorrect, but hopefully it gets the point across
[2021-06-22 19:10:05] <harding> At least symettrically; you can guarantee a parent is confirmed before a child but not the other way around.
[2021-06-22 19:11:01] <Chris_Stewart_5> Well i think at minimum accepted into the mempool A block would be even better 
[2021-06-22 19:11:55] <ariard> rgrant: hmmm do you mean block assemblage algorithms?
[2021-06-22 19:12:09] <glozow> perhaps a guarantee that package relay could provide is that your transactions get propagated as intended, so you're not stuck with a wrong execution path because you couldn't get your tx to a miner in time
[2021-06-22 19:12:11] <t-bast> I think that batching confirmation in the same block isn't a job for package relay, but ensuring it makes sense to relay them together to other mempools should be
[2021-06-22 19:12:41] <harding> t-bast: agreed.
[2021-06-22 19:13:24] <rgrant> can someone link me to glozow's appropriate branch or pull request?
[2021-06-22 19:13:30] <glozow> rgrant: I agree in the sense that, after nodes are able to do package validation, package relay serves as a hint of "hey, u should run these transactions through package validation rather than individual tx validation"
[2021-06-22 19:13:40] <Chris_Stewart_5> glozow: Yeah, i think the worst case is my commitment tx makes it into the mempool, but my htlc txs can't for some reason. That means my "package" isn't getting relayed IMO. 
[2021-06-22 19:13:42] <ariard> t-bast: i think the makes sense notion is interesting, because it might differ in function of the receiver's mempool you're considering
[2021-06-22 19:13:56] <glozow> rgrant: i have a list here https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add#1-package-validation-and-package-specific-policies
[2021-06-22 19:14:14] <ariard> like should you assemble package based on mempool min feerate or should you assemble package based on sender-defined feerate?
[2021-06-22 19:14:16] <glozow> Chris_Stewart_5: that makes sense
[2021-06-22 19:15:12] <t-bast> ariard: I agree, it's quite hand-wavy because we have to accept that the network is heterogeneous and we can't have a rule that will make sense for everybody
[2021-06-22 19:15:30] <michaelfolkson> Chris_Stewart_5: And in DLC world you want the funding tx and CET in the same block?
[2021-06-22 19:15:46] <rgrant> ariard: i do see package relay and block assemblage as related, but i can see how just paying to send messages through the flood network might not always rely on acceptance in a block.
[2021-06-22 19:16:12] <Chris_Stewart_5> michaelfolkson: No, that was a bad example on my part. Perhaps a fee bumping spend from the CET though. I think lightning makes more sense with these analogies because there is 3 layers of tx. Funding, commitement, and htlc/penalty txs
[2021-06-22 19:16:24] <rgrant> ariard: if there's any chance for message not expected to land in blocks to go through, that could burden the network (and LN would be able to handle it better)
[2021-06-22 19:17:00] <michaelfolkson> Chris_Stewart_5: Ok thanks, makes sense
[2021-06-22 19:18:03] <ariard> t-bast: sure i meant more as a local node mechanism, what could be the different triggers of a package generation? e.g you have transaction A of which the feerate doesn't pass Alice's `feefilter`, and you have multiple childs of A present in your mempool
[2021-06-22 19:18:25] <glozow> Chris_Stewart_5: so in that use case, a 2-transaction package would work?
[2021-06-22 19:19:01] <glozow> to CPFP fee-bump the CET?
[2021-06-22 19:20:01] <michaelfolkson> glozow Chris_Stewart_5: With DLCs there are lots of alternative transactions but only only one can get confirmed (afaiu). So yeah a 2 transaction package with the "winning" transaction and the CPFP
[2021-06-22 19:20:15] <Chris_Stewart_5> glozow: Yes. We have built in refund transactions for the case that an oracle disappears. If you do not get your CET confirmed before this refund tx, you could possibly lose funds.
[2021-06-22 19:20:37] <t-bast> glozow: reading through your link, I think LN would have enough flexibility with `Two generations only, with 1 or more sponsored parents + 1 sponsoring child`, and could get away with `Simply 1 parent + 1 child` if we forget about batching (and accept being a little less fee efficient)
[2021-06-22 19:21:07] <ariard> rgrant: though "not expected to land in blocks" is relative of your mempool top feerate, should you relay low-feerate transaction still higher than your peers's mempool min feerate?
[2021-06-22 19:21:29] <rgrant> do we have simple rules yet like "if packages cause eviction of some number of bytes from the mempool, then the average feerate of the bytes added must be higher than te average feerate of the bytes evicted?
[2021-06-22 19:21:32] <t-bast> ariard: I didn't realize you were asking about the node logic to build packages when relaying, I was just thinking as a higher layer user of that feature
[2021-06-22 19:21:46] <glozow> t-bast: awesome! 😍
[2021-06-22 19:22:09] <Chris_Stewart_5> glozow: thanks for the link, will read through later
[2021-06-22 19:22:11] <harding> Chris_Stewart_5: out of curiousity, how tight are the typical bounds on the refund?  LN has been setting very tight bounds (e.g. 40 blocks or less) to prevent attacks where funds can be locked up for long amounts of time.  I think DLCs can probably use much loose bounds (e.g. 1000s of blocks maybe) and so would be fundamentally much less vulnerable to feerate management problems and pinning attacks.
[2021-06-22 19:22:22] <ariard> rgrant: yes that's already how LimitMempoolSize works iirc
[2021-06-22 19:22:27] <darosior> glozow: don't want to derail the meeting but have you thought about a package-based CBlockPolicyEstimator? If CPFP is used a lot it seems to me that it could bias the estimation. Hmm i'd have to think more about it.
[2021-06-22 19:23:03] <t-bast> glozow: does `Two generations only, with 1 or more sponsored parents + 1 sponsoring child` create more technical problems than `Simply 1 parent + 1 child` for you? Or do they have the same drawbacks for layer 1 (with slightly more implementation complexity)?
[2021-06-22 19:23:04] <glozow> darosior: i must admit i haven't thought about it - I hardly knew `CBlockPolicyEstimator` existed until very recently 😅 
[2021-06-22 19:23:53] <michaelfolkson> And you could have an alternative competing package if the initial CPFP wasn't effective? A CPFP package that RBFs the previous (too low fee) CPFP package?
[2021-06-22 19:23:54] <darosior> ok :) i'll look into it, maybe smarter people actually solved this years ago as often!
[2021-06-22 19:24:01] <rgrant> ariard: then relay rules should be aligned well enough with block acceptance rules that you should relay a fairly-low feerate transaction that is higher than your peer's min feerate.
[2021-06-22 19:24:39] <ariard> t-bast: so as a higher-layer user you can broadcast A then high-feerate B, but in your mempool you might already have A and another child C, with a lower-feerate
[2021-06-22 19:25:10] <glozow> t-bast: 2 gen multi parent single child is a significant simplification, actually. it is slightly more complex than parent+child but still makes me very happy to hear
[2021-06-22 19:25:14] → murchandamus joined (~murch@user/murch)
[2021-06-22 19:25:20] <Chris_Stewart_5> harding: the refund is user configurable. We haven't really decided on what best policy is yet. But i think your analysis is probably correct. We have a new type of DLCs in pipeline called "disjoint union" DLCs where you can have logic like "liqudiation threshold breached where i liquidate collateral at $30,000" OR a certain time threshold is met. This opens the question of what happens
[2021-06-22 19:25:23] <Chris_Stewart_5> when the liquidation threshold is reached slightly before the time threshold. I haven't thought too deeply about this in the package relay context
[2021-06-22 19:25:31] <ariard> and if you package-relay the pair {A,C}, which might be higher than your peers's mempool min feerate it can still downgrades its odds of confirmation?
[2021-06-22 19:25:32] * murchandamus → murch
[2021-06-22 19:26:14] <t-bast> ariard: for LN it's not an issue because you usually are the only one to be able to broadcast A, so people couldn't sneak in C before B if you put them as a package `A + B`
[2021-06-22 19:26:15] <harding> Chris_Stewart_5: does the oracle do the timekeeping or do you use MTP?
[2021-06-22 19:26:29] <t-bast> ariard: (A being a commit tx or htlc tx)
[2021-06-22 19:26:46] <Chris_Stewart_5> harding: they can be two separate oracles, attesting to independent events and completely unaware of each other. The DLC is built custom client side.
[2021-06-22 19:26:50] <ariard> michaelfolkson: yes you mean RBF-package in case of competing LN's commitment transactions
[2021-06-22 19:26:53] <t-bast> glozow: great, good to know!
[2021-06-22 19:27:11] → livestradamus joined (~quassel@user/livestradamus)
[2021-06-22 19:27:21] <rgrant> glozow: thanks for the link, very helpful!  i don't understand why we can't support RBF in packages.  is that an implementation limitation or a policy limitation?
[2021-06-22 19:27:56] <t-bast> ariard: but someone else could relay `A+C` once you've broadcast `A+B`, you're right, but in that case RBF rule to get B to replace C should save us, doesn't it?
[2021-06-22 19:27:56] <ariard> rgrant: ah might question was more oriented if it would make sense to not broadcast your whole mempool content to save on bandwidth, but that's quite a side-topic
[2021-06-22 19:28:03] <glozow> rgrant: it's a simplification that makes package validation easier to implement and reason about
[2021-06-22 19:28:12] <harding> Chris_Stewart_5: ok.  To me, as long as the timekeeping is being done by an oracle, then I think your only concern related to package acceptance is still related to the refund condition, and I think that's a case where DLCs are in a much healthier position than current LN.
[2021-06-22 19:28:14] <Chris_Stewart_5> harding: in general, oracles are blockchain agnostic. The same oracle for DLCs works on zcash, litecoin, bitcoin, bcash etc. No network specific configurations oracle side
[2021-06-22 19:28:53] <glozow> is BIP125 RBF for packages something that we want?
[2021-06-22 19:29:17] <Chris_Stewart_5> probably ETH lol
[2021-06-22 19:29:18] <michaelfolkson> rgrant: There are lots of DoS vectors that Suhas, glozow, ariard have to wrestle with when trying to implement this
[2021-06-22 19:29:30] <ariard> t-bast: you broadcast A+B at first time, your peer broadcast C spending A's remote anchor output then you fee-bump/rebroadcast with A+D, i think it can happen?
[2021-06-22 19:29:51] <t-bast> glozow: it depends, in a `parents + single child` package I think we do need to be able to replace the child with RBF (but not the parents)
[2021-06-22 19:30:45] <t-bast> ariard: I'm hoping this scenario can happen too! :)
[2021-06-22 19:30:56] <harding> glozow: I think some type of replacement for packages will be important in the long run.  Otherwise, even in the best case, you're limited to (n-1)/x feebumps where n is the descendent limit and x is the number of parties in a protocol who can fee bump a commitment or whatever transaction.
[2021-06-22 19:31:02] <ariard> glozow: yeap i think so otherwise your counterparty might have a low-feerate package already in the mempool?
[2021-06-22 19:31:22] <darosior> glozow: if we limit the size to 2, we can just RBF the child the non-package way?
[2021-06-22 19:31:27] <glozow> t-bast: i think that's perfectly doable now if you've got the package in, and the child doesn't already have descendants in the mempool
[2021-06-22 19:31:50] <ariard> t-bast: yes but now you're back to the issue of your mempool assemblage logic potentially lured to relay a lower-feerate package than the one expected?
[2021-06-22 19:32:51] <t-bast> glozow: and if the child has descendants, can we rely on the current BIP125 rule to still replace it or does it add new issues?
[2021-06-22 19:32:57] <harding> I take back what I just said, I think darosior has it right.
[2021-06-22 19:32:57] <ariard> darosior: right, but your expected parent might have been evicted in between, and we can assume you don't have global view of the mempool?
[2021-06-22 19:33:40] <glozow> t-bast: darosior: yeah, it's just a BIP125 RBF of the child.
[2021-06-22 19:33:47] <harding> ariard: oh, good point.
[2021-06-22 19:34:03] <t-bast> ariard: I see what you mean, I hadn't thought about that. If packages are small (two generations) is it really an issue though?
[2021-06-22 19:35:06] <harding> ariard: what I understand you to be saying is that commitment tx A is currently in the mempool along with anchor spend B giving it fees.  You want to increase the fees by creating B' but, in the meantime, A has been replaced by A'.
[2021-06-22 19:35:53] <glozow> can you make a child for A' or no?
[2021-06-22 19:36:00] <ariard> t-bast: well your counterparty can downgrade the feerate of your expected package? so maybe the package assemblage logic should just search for the best feerate subset among your in-mempool chain of transactions?
[2021-06-22 19:36:02] <darosior> ariard: wait but eviction would be based on the entire package? If you need to RBF, RBF the child. If it so happens that the package was evicted re-broadcast the entire package. I don't see how it differs from current behaviour
[2021-06-22 19:36:11] <harding> glozow: yes, but you don't know about A'.
[2021-06-22 19:36:13] <t-bast> glozow: in the case of LN yes, we can, so it may save us
[2021-06-22 19:36:21] <ariard> harding: yes exactly
[2021-06-22 19:36:43] <t-bast> but as harding says, we can't know if it's a revoked commit tx (and we may have thousands of versions of the tx, so can't blindly try them all)
[2021-06-22 19:36:49] <harding> glozow: so if you relay A->B', your fee bump works, but if you just relay B' it can't bind to A.
[2021-06-22 19:37:28] <t-bast> ariard: I think that would make sense (searching for the best feerate subset)
[2021-06-22 19:37:29] <glozow> ah so you might want to submit B' as a single transaction to get the RBF, but you want to relay {A, B'} together to tell peers to validate them as a package
[2021-06-22 19:37:36] <darosior> ok got it.
[2021-06-22 19:37:59] <ariard> darosior: sure you can re-broadcast the entire package though you need a replacement rule for this one to replace an-already in-mempool chain of transactions?
[2021-06-22 19:38:00] <harding> That's kind of a nasty problem, though, because it requires relay nodes to relay {A,B'} as a package even through nodes that already know about A.
[2021-06-22 19:38:27] <ariard> harding: yep bad for bandwidth :/
[2021-06-22 19:38:37] <glozow> right, i think we should trim packages when we already know about a transaction in it
[2021-06-22 19:38:40] <darosior> Yes. It might be a pretty limiting factor if we ever want to increasing package size
[2021-06-22 19:38:48] <glozow> also i don't think we should relay entire transactions when talking about packages on p2p
[2021-06-22 19:39:01] <t-bast> glozow: but you don't know if your peer knows about it, so you may need to relay as a package to your peers, don't you?
[2021-06-22 19:39:56] <harding> ariard: is this related to your criticism on https://github.com/bitcoin/bitcoin/pull/22252 ?  I was having trouble understanding your concern from a quick skim, but this makes sense to me.
[2021-06-22 19:40:10] <t-bast> I'd see that as an argument for `single parent + single child` instead of `multiple parents + single child`, to limit bandwidth waste
[2021-06-22 19:40:38] <glozow> i have perhaps a different view of package relay? I think all you need to do is communicate hints about when to use package validation. so I'm thinking you don't need to relay the transactions themselves, just the wtxids of transactions you think should be package validated. and tx relay still happens the normal way
[2021-06-22 19:40:38] <ariard> t-bast: well we track per-peer announced txids in `filterInventoryKnown`
[2021-06-22 19:40:57] <ariard> assuming you rely on the INV announcement mechanism
[2021-06-22 19:41:08] <rgrant> glozow: that's my intuition as well
[2021-06-22 19:41:16] <glozow> like, package relay is less about communicating transactions, and more about communicating how to validate them
[2021-06-22 19:41:25] <t-bast> ariard: but you can't know if the tx has been evicted since your peer last announced it had it?
[2021-06-22 19:42:14] <ariard> harding: yes your counterparty might have a same-txid-different-txid lower-feerate proposal already in the mempool?
[2021-06-22 19:42:26] <t-bast> glozow: in that case you'd send B + A's txid, and your peer can then ask you to send A if it doesn't have it to validate it as a package on its side?
[2021-06-22 19:42:50] <harding> glozow: how far away do your hints travel?  If they just go to your direct peer, then I think this problem exists where Alice wants to send {A, B'} to Bob who knows about {A, B} to miner Carol who knows about {A'}.  The hint to Bob doesn't help and Bob doesn't know to send a hint to Carol, so B' never gets to her for mining.
[2021-06-22 19:42:52] <glozow> t-bast: yeah. they can still request the transactions they need
[2021-06-22 19:43:21] <t-bast> glozow: at first glance, it makes sense to me and shouldn't be very wasteful in terms of bandwidth/latency
[2021-06-22 19:43:36] <ariard> glozow: agree we can rely on TX messages, it's more the INV-GETDATA that might be updated?
[2021-06-22 19:45:00] <ariard> t-bast: right, you're not aware of the replacement happening in your peer's mempool
[2021-06-22 19:45:04] <glozow> ariard: mm, right. I don't have a BIP proposal or anything, just don't think we should worry too much that bigger packages take up more bandwidth
[2021-06-22 19:45:11] <glozow> harding: oo hm, hadn't thought about that
[2021-06-22 19:45:30] <harding> glozow: me neither!  Hat tip to ariard!
[2021-06-22 19:45:53] <livestradamus> http://audiobookbay.nl/
[2021-06-22 19:45:57] <t-bast> And Carol doesn't even know that B's parent conflicts with A' if we only send A's txid at first
[2021-06-22 19:46:06] <livestradamus> Oops wrong window sorry for the link
[2021-06-22 19:46:27] <ariard> livestradamus: you can stay if you're interested :p
[2021-06-22 19:47:01] <livestradamus> I'll catch up, it's night time here
[2021-06-22 19:47:17] <rgrant> harding: do we need to make some claim of "achievable average feerate of this package" when sending hints?  then Bob would say "i don't have a tx that achievesthat feerate, send B'".
[2021-06-22 19:48:09] <t-bast> I agree with rgrant, I think it makes sense to send a feerate hint so that your peer can decide whether it makes sense to fetch the rest of the package or not
[2021-06-22 19:48:11] <harding> rgrant: I don't think so, I think as long as we can hint that the package is over the peer's BIP133 minrelayfeerate, we're ok.
[2021-06-22 19:49:03] <ariard> glozow: well i think the question of "does bigger package take more bandwidth is function of the package announcement mechanism ?" like if you say explicit package hints with the whole list of wtxids to atomically validate
[2021-06-22 19:49:16] <rgrant> harding: then why doesn't Bob ask for B'?  and why doesn't the miner build {A B'}?
[2021-06-22 19:49:30] <t-bast> actually maybe it doesn't solve what I think it solves since your peer doesn't even know whether your package conflicts with some of the txs in his mempool until he fetched the whole package...
[2021-06-22 19:49:36] <glozow> harding: so what we want is Bob to replace B with B', and then sends {A, B'} to Carol, who replaces A' with A, then does {A, B'} ?
[2021-06-22 19:50:09] <glozow> maybe when you get your package hint, first you try all of them as replacements, and then you package validate...
[2021-06-22 19:50:12] <harding> rgrant: Bob does ask for B', but when he tries sending it to Carol, she considers it an orphan.
[2021-06-22 19:50:35] <harding> glozow: correct.
[2021-06-22 19:50:35] <michaelfolkson> Full nodes don't calculate the average fee rate (satoshis per vbyte) in a block do they? Wallets typically get network fee rate stats from centralized APIs?
[2021-06-22 19:50:51] <ariard> t-bast: i believe one downside of feerate-based announcement mechanism is you need to announce the utxo, so maybe you leak a bit of bandwidth hmmm?
[2021-06-22 19:51:01] <t-bast> but Bob could send A's txid as a hint? Is there a reason *not* to send it (unless your peer already said he had seen A)?
[2021-06-22 19:51:35] <t-bast> ariard: yes exactly, we'd need to send the utxo to check for conflicts, and it may be a rabbit hole if we follow that logic further...
[2021-06-22 19:52:17] <rgrant> harding: oh, i may be misunderstanding notation.  i assumed that Carol would evict A' from the block's consideration if {A B'} has high enough feerate.  what am i missing?  was A' already buried in a block?
[2021-06-22 19:52:43] <harding> t-bast: I guses the only reason not to send it is that we're possible talking about a massive increase in INV overhead here by announcing all the parents of every transaction with mempool ancestors.
[2021-06-22 19:53:42] <t-bast> harding: of course, but if we're limiting package to `1 parent + 1 child` is it still too much?
[2021-06-22 19:54:12] <t-bast> harding: it feels like whenever we'll try to be clever and omit the hint, there will be an edge case where propagation stops
[2021-06-22 19:54:42] <harding> t-bast: I don't know, I think that's the kind of thing that would need to be backtested against typical mempool contents, and we'd want to talk to gleb about how that would affect erlay's assumptions.
[2021-06-22 19:54:45] <glozow> so what we might want is 1 parent + 1 child, with RBF enabled?
[2021-06-22 19:55:04] <rgrant> what if packages are never retouched by nodes along the flood network?  what if they live or die as they were initially injected?
[2021-06-22 19:55:06] <harding> rgrant: sorry, it is an awful ad hoc notation.
[2021-06-22 19:56:12] <ariard> michaelfolkson: you mean something as per-block feerate ? nope i can't remember doing that though block feerate information is consumed by the fee estimator
[2021-06-22 19:56:28] <t-bast> I think that 1 parent + 1 child, with RBF enabled at the package level (I can send `A + B` to replace `A' + B'`) should give a wide enough design space for L2 protocols (maybe they wouldn't be the most fee efficient because they couldn't batch, but we'd live with it)
[2021-06-22 19:57:05] <t-bast> It feels like having bigger packages will have too much potential negative impact on layer 1
[2021-06-22 19:57:54] <glozow> t-bast: i think that's doable
[2021-06-22 19:58:17] <harding> glozow: relaying 1+1 as a package seems like it would be powerful, but it would have to allow for the parent already having other children in the mempool (e.g. through standard BIP125 rules).
[2021-06-22 19:58:50] <glozow> harding: right
[2021-06-22 19:59:07] <ariard> rgrant: well i did this approach in my PoC a while back but it's super DoSy as you have to cache the package ids...(and didn't figure out a robust mitigation)
[2021-06-22 19:59:38] <glozow> many fun whiteboarding sessions to come
[2021-06-22 20:00:04] <rgrant> ariard: understood.  it would be cool if we could pull hints from a paid network like LN.
[2021-06-22 20:00:04] <glozow> should we talk about replacing witnesses as well? ariard do you think that's appropriate to discuss here?
[2021-06-22 20:00:16] <harding> I guess for txid hints in packages, you don't need to use the full txid, you can use something like BIP152 short ids.
[2021-06-22 20:00:19] <t-bast> glozow: that's great, I think that almost any L2 protocol can always design two-steps process where the first tx has a feerate of 0 and the second is there to set the fees
[2021-06-22 20:00:25] <harding> That would save lots of bandwidth.
[2021-06-22 20:00:45] <glozow> harding: oo!
[2021-06-22 20:01:11] <ariard> t-bast: here a new chan type for you :)
[2021-06-22 20:02:03] <ariard> glozow: yes for sure, though iirc 19645 was orthogonal from package-relay discussion at time, though maybe we should consider as one now?
[2021-06-22 20:02:10] <glozow> t-bast is t-best
[2021-06-22 20:02:24] <glozow> ariard: yeah. i think it's relevant, especially since we're talking about having replacements with packages
[2021-06-22 20:02:26] <harding> lol
[2021-06-22 20:03:22] <glozow> 19645: https://github.com/bitcoin/bitcoin/pull/19645
[2021-06-22 20:03:29] <darosior> michaelfolkson: and where do these services get this estimation from? either a broken mempool estimation or a bitcoind's estimation: https://bitcoin.stackexchange.com/a/96491/101498 . Note also how relying on a centralized fee est service for L2 is a huge SPOF
[2021-06-22 20:03:50] <ariard> t-bast: i believe there is an awful edge-case in our orphan logic which would recommend to do always 1-CSV in chain of transactions with competing interest, here  https://github.com/bitcoin/bitcoin/pull/21148#discussion_r587522262 though need more thinking :/
[2021-06-22 20:04:08] <darosior> michaelfolkson: but to answer your question no it does not compute the feerate of an entire block
[2021-06-22 20:04:52] <ariard> glozow: i agree it's relevant, though maybe a reduction of the issue is already having wtxid-replacement at the transaction level?
[2021-06-22 20:05:05] <t-bast> ariard: thanks for the link, I'll look into that
[2021-06-22 20:05:34] <glozow> ariard: yeah, having it at the single-transaction level is probably the harder part
[2021-06-22 20:05:34] <harding> ariard: in 19645, I just quick skimmed the diff and it looks like it's using the regular replacement rules, e.g. higher feerate, higher absolute fee?
[2021-06-22 20:05:36] <t-bast> ariard: I think CSV-1 is usually acceptable for L2 protocols
[2021-06-22 20:05:44] <harding> ariard: is that correct?
[2021-06-22 20:06:14] <ariard> harding: yes it's not modifying bip125 rule so unless you have `incrementalrelayfee`=0 wtxid-replacement won't work
[2021-06-22 20:06:51] <ariard> like rbf rule 4 requires to increase the absolue fee, but that's locked-in in the same-txid part of any tx?
[2021-06-22 20:06:52] <glozow> for witness replacement, i don't think it should go through the normal route. perhaps a similar evaluation of whether it's paying for its bandwidth, but it wouldn't need to rip anything out of mempool. you'd just need to update ancestor/descendant entries
[2021-06-22 20:07:05] <michaelfolkson> darosior: Thanks. An unlimited sized mempool would be best for network fee rate monitoring but if you had smaller mempool network fee rate in block(s) might be useful (I think...)
[2021-06-22 20:07:31] <harding> ariard: oh, right, I'm dumb.
[2021-06-22 20:08:14] <ariard> glozow: ah that's interesting never considered the approach of conserving the branch of transaction
[2021-06-22 20:08:31] <ariard> yep i like it, more conservative with the bandwidth
[2021-06-22 20:09:12] <harding> Yeah, I'd be supportive of that approach as long as it was increasing the feerate by some amount to limit bandwidth wasting.
[2021-06-22 20:09:41] <glozow> yeah. witness needs to shrink enough to bump the feerate by at least min relay fee
[2021-06-22 20:09:53] <glozow> you'd just go through and change the ancestor/descendant sizes of the entries
[2021-06-22 20:09:55] <ariard> yeah it would move rule 4 from a check on a relay fee in absolue fee to one in feerate? like with a ratio?
[2021-06-22 20:10:19] <glozow> mhm, absolute fee wouldn't change, so that rule wouldn't make as much sense for witness replacement
[2021-06-22 20:10:39] <glozow> ratio of witness data to nonwitness data?
[2021-06-22 20:10:48] <glozow> or old witness data to new witness data?
[2021-06-22 20:11:50] <ariard> glozow: i mean a feerate ratio, though it's really intuitive
[2021-06-22 20:11:53] <t-bast> in practice though I'm not sure there is a lot of room to change the witness enough to meaningfully influence the feerate, as what you put in the witness is probably very constrained (in order to correctly satisfy scripts), isn't it?
[2021-06-22 20:12:03] <harding> t-bast: taproot.
[2021-06-22 20:12:20] <ariard> like let's say your wtxid-replacement must pay 10% more in feerate than the replaced one, something like this hmmm?
[2021-06-22 20:12:24] <t-bast> harding: oh, right, that activated :D
[2021-06-22 20:12:36] <t-bast> well not activated but locked in
[2021-06-22 20:12:53] <glozow> i think there's also the idea of someone trying to pin your transaction with a very bloated witness?
[2021-06-22 20:12:54] <t-bast> good point, I'm not thinking with a taproot mindset yet
[2021-06-22 20:13:07] <glozow> so either they're not pinning it very much, or you'll be able to do a significant witness shrink?
[2021-06-22 20:13:09] <harding> t-bast: tapscripts can be unlimited in size, so with current rules you could in theory go from a ~100,000 vbyte witness to an empty witness.
[2021-06-22 20:13:16] <michaelfolkson> Can someone give me the TL;DR on replacing witnesses? You broadcast a witness and then work out you could have used a cheaper witness?
[2021-06-22 20:13:17] <ariard> t-bast: if you're spending the 30th in depth tapscript gonna be hard to be most fee-efficient than the first one :) ?
[2021-06-22 20:13:52] <t-bast> harding: yeah so you need to carefully take this into account when designing your tree
[2021-06-22 20:14:08] <harding> michaelfolkson: it's more a case of you have a UTXO shared by two parties (e.g. LN) and Alice's witness for her branch is 1,000 vbytes but Bob's is only 250 vbytes.
[2021-06-22 20:14:22] <ariard> michaelfolkson: yep for example a 1-1 + timelock is shorter than a 4-4 multisig?
[2021-06-22 20:14:47] <harding> t-bast: if you're near the limits, yeah, but we obviously can't support many people creating 100,000 vbyte transactions.
[2021-06-22 20:15:17] <ariard> harding: oooh, forget about that so yeah it's kind of a pinning vector as glozow pointed out?
[2021-06-22 20:15:21] <t-bast> It's interesting, I didn't realize that this is a very important point to take into account when designing L2 protocols on top of Taproot
[2021-06-22 20:15:27] <rgrant> michaelfolkson: an adversary forces CPFP consideration with a large witness, so you need to either create another level of CPFP, or propose a smaller package.
[2021-06-22 20:15:32] <harding> t-bast: miniscript should tell you your worst case tx size, so anyone using that should be safe.
[2021-06-22 20:15:54] <t-bast> harding: thanks for the explanations!
[2021-06-22 20:17:10] <harding> glozow: I don't know how bad the witness pinning risk is because, in a contract protocol, only your counterparties can do that and y'all agreed to the contract up front, so hopefully somebody ran it through miniscript and looked at what the worst case witness size was.
[2021-06-22 20:17:48] <michaelfolkson> harding: And in your example you want to use Bob's witness instead of Alice's witness even though Alice's witness was previously broadcast?
[2021-06-22 20:18:22] <ariard> glozow: hmmm we might have a theoritical issue in the future with the in-place replacement approach where a bigger witness is smaller in feerate than the replaced one but override package-limits, like an annex tag
[2021-06-22 20:18:23] <harding> For something like LN, the best case is going to be a taproot keypath spend (16 vbyte witness) and the worst case is going to be, what, 150 vbyte witness?  That's not a huge difference, I think, even when fees are very high.
[2021-06-22 20:18:30] <ariard> (super-edgy-case)
[2021-06-22 20:18:46] <ariard> harding: agree it's more defense-in-depth here?
[2021-06-22 20:19:07] <glozow> harding: ah, i didn't know you could see worst case witness size :O
[2021-06-22 20:19:44] <harding> ariard: yeah, and we do want make it easier for people to get smaller transactions confirmed.  It's good for the contract protocol users and it's good for everyone else too.
[2021-06-22 20:20:00] <harding> glozow: miniscript is AMAZING.
[2021-06-22 20:20:05] <michaelfolkson> glozow: I didn't know that either
[2021-06-22 20:20:14] <darosior> harding: +1, no +2 even
[2021-06-22 20:20:52] <michaelfolkson> A distribution of witness sizes (including means, medians etc)? Lol
[2021-06-22 20:21:53] <ariard> wanna chat about package-relay in the context of N-party, like more than 2?
[2021-06-22 20:22:13] <glozow> ariard: er what do you mean by annex tag and override package-limits? sorry
[2021-06-22 20:22:16] <glozow> ariard: yes sure
[2021-06-22 20:23:07] <ariard> glozow: well the bip341 annex could allow a small witness to have its feerate inflated due to a special marker
[2021-06-22 20:23:35] <ariard> and then you could have a same-txid-different-wtxid coming after with a lower feerate but higher vbytes size, just overflow package limits?
[2021-06-22 20:23:55] <ariard> but not sure it's worthy to mind, it's assuming some soft-fork to define the annex
[2021-06-22 20:23:59] <harding> ariard: I don't think that's correct.
[2021-06-22 20:24:08] <darosior> Not yet
[2021-06-22 20:24:11] <t-bast> ariard: does N party change anything? As long as the N parties collaborate on one tx, N>2 should be the same as N=2, doesn't it?
[2021-06-22 20:24:18] <darosior> But it was a proposed idea
[2021-06-22 20:24:26] <harding> ariard: first, feerate is purely a policy concept and annex operates at the consensus level.
[2021-06-22 20:24:37] <ariard> harding: ah sorry, which part?
[2021-06-22 20:24:46] <harding> ariard: second, an annex can increase the weight of a transaction; it cannot decrease it.
[2021-06-22 20:24:48] <darosior> harding: iirc aj suggested it could be a soft fork for giving a meaning to annex
[2021-06-22 20:25:29] <darosior> (for context this is because the ratio of sigop per WU was moved to consensus in Taproot and instead of stuffing your witness to pass the limit you could just set the annex to a given value)
[2021-06-22 20:26:00] <harding> If you can't decrease the weight of a transaction and a new witness can't change its absolute fee, then I don't believe you can increase the feerate by increasing the size of a transaction.
[2021-06-22 20:26:47] <darosior> Sorry i misread what ariard said, i thought it was about *lowering* the feerate.
[2021-06-22 20:27:23] <harding> (Obviously, because feerate is a policy concept, you can write economically irrational transaction selection code, but I don't think that's what's being described here.)
[2021-06-22 20:27:52] <ariard> harding: but the replacement witness might not have an annex ? where the replaced said-annex would artificially bump the WU
[2021-06-22 20:28:10] <ariard> though not sure it's worthy to go further, we're talking about something without consensus-meaning for now
[2021-06-22 20:28:34] <harding> ariard: hmm, I'll look into that more, but agree we're getting far afield now.
[2021-06-22 20:29:16] <ariard> ah right assuming the artificial-WU-bump is reflected in our mempool policy, we should be good, forget about what i was saying
[2021-06-22 20:29:40] <glozow> sooo i've gathered that it would be really beneficial to have replacements enabled, 1 parent + 1 child packages? and we should get cracking on witness replacements.
[2021-06-22 20:30:01] <t-bast> glozow: ACK, ship it ;)
[2021-06-22 20:30:10] <harding> glozow: SGTM.
[2021-06-22 20:30:18] <darosior> glozow: this is what i got too
[2021-06-22 20:30:20] <rgrant> does anything prevent my node from proposing package {A B}, and {B C}?
[2021-06-22 20:30:33] <rgrant> (as a way to propose {A B C}?
[2021-06-22 20:31:07] <ariard> yep SGTM, though we might have to reconsider RBF rule 3 and the higher-fee requirement
[2021-06-22 20:31:14] <ariard> s/and/on/g
[2021-06-22 20:31:23] <t-bast> rgrant: would it be different from proposing {A B} and then simply adding C?
[2021-06-22 20:31:28] <glozow> wonderful, thank you! I really really appreciate you all providing this info :D
[2021-06-22 20:31:50] <harding> ariard: rule three doesn't require a higher fee, at least as written, it requires an equal or greater fee.
[2021-06-22 20:32:04] <t-bast> rgrant: it feels to me that the goal of package relay here is really to get A to propagate
[2021-06-22 20:32:16] <harding> ariard: please don't tell my I screwed that up too.  :-(
[2021-06-22 20:32:22] <harding> s/my/me/
[2021-06-22 20:32:52] <ariard> harding: well if you combine with rule 4 that's a higher fee requirement ;)
[2021-06-22 20:33:02] <rgrant> t-bast: yeah, okay.  it just feels a bit wrong to only solve one level, so intuitively i want to push for more.  but there are other proposal for that.
[2021-06-22 20:33:38] <ariard> assuming the default setting of `incrementalrelayfee` ?
[2021-06-22 20:33:47] <t-bast> rgrant: I think that if you got {A B} to propagate as a package, it usually means that if A had been confirmed, B would have propagated on its own, so C wouldn't add anything. But I may be missing some cases though.
[2021-06-22 20:33:47] <ariard> of 1000 sat per KB iirc
[2021-06-22 20:34:28] <darosior> ariard: but it's a feerate
[2021-06-22 20:34:33] <glozow> rgrant: no, i don't think {A, B} + {B, C} would work if, for example, A and B were zero fee and C was supposed to pay for both
[2021-06-22 20:34:37] <t-bast> rgrant: and if A has been evicted, the {B C} package wouldn't propagate because it would be an orphan package
[2021-06-22 20:34:41] <rgrant> t-bast: well, if neither A nor B are enough, then you need {A B C}.  but yeah my question wasn't well formed because then {A B} won't happen.
[2021-06-22 20:34:53] <t-bast> rgrant: got it
[2021-06-22 20:34:56] <glozow> that's not a "perfect" package relay but it would make it a bit harder to implement
[2021-06-22 20:35:29] <t-bast> rgrant: I think it shouldn't fundamentally restrict the design space for L2 protocols (but I may be wrong)
[2021-06-22 20:35:55] <t-bast> rgrant: what we'd do with a chain of 3 txs, we should be able to split into packages of 2 at a time
[2021-06-22 20:36:17] <darosior> ariard: for the absolute fee i'm pretty sure it's >= old_abs_fee
[2021-06-22 20:36:40] <t-bast> rgrant: at potentially the cost of a 1-block relative delay somewhere and a bit more fees to pay, but that's an ok trade-off IMHO
[2021-06-22 20:36:47] <rgrant> t-bast: once we get into BIP119, then some of the MAST possibilities are not resolved in one transaction, but may ratchet state through several on-chain transactions.
[2021-06-22 20:36:55] <ariard> darosior: yeah i was thinking about nDeltaFees < ::incrementalRelayFee
[2021-06-22 20:37:32] <darosior> Gotta run now. Thanks for working on this and participating glozow. And thanks ariard for organizing, i think your efforts moved things forward :) 
[2021-06-22 20:37:40] <t-bast> rgrant: OP_CTV is on my rabbit hole list, but I don't have enough context on that one yet!
[2021-06-22 20:37:57] <rgrant> darosior: CU
[2021-06-22 20:38:05] <ariard> darosior: thanks for participating
[2021-06-22 20:38:08] <ariard> yeah let's end here
[2021-06-22 20:38:13] <ariard> #endmeeting
[2021-06-22 20:38:30] <t-bast> Thanks ariard for organizing, glozow for the work on package relay, and everyone for their comments and time spent thinking about this!
[2021-06-22 20:38:36] <t-bast> I learnt a lot tonight, thanks for that
[2021-06-22 20:38:40] <rgrant> +1
[2021-06-22 20:38:43] <michaelfolkson> +1
[2021-06-22 20:38:52] <harding> ariard: thanks for organizing!  glozow thanks for the nice notes and all the package acceptance and relay work!
[2021-06-22 20:39:37] <glozow> +1, thank you ariard for organizing :) it would've taken me a looooong time if i had to muster up the courage to ask people individually what kind of packages they want hahahaha
[2021-06-22 20:39:48] <glozow> and thanks everyone for the very thoughtful input
[2021-06-22 20:40:09] <michaelfolkson> I'll write up a summary for the mailing list in next couple of days (unless someone else wants to take that job, if they do let me know)
[2021-06-22 20:40:20] <ariard> Hopefully all the mempool-related L2s issues will be clearer, though happy to be over with meetings and gonna focus on other stuff now :) 
[2021-06-22 20:40:48] <michaelfolkson> Can you add the conversation log to a gist and share the link again ariard?
[2021-06-22 20:41:02] <ariard> michaelfolkson: that would be nice, yeah sure will send you the conversation log
[2021-06-22 20:41:50] ⇐ t-bast quit (~t-bast@user/t-bast): Quit: Leaving
[2021-06-22 20:41:51] <glozow> ariard: not to be pushy, but is witness replacement / #19645 something you're looking to get back to soon?
[2021-06-22 20:42:20] ← rgrant left (~rgrant@user/rgrant): Leaving...
[2021-06-22 20:45:24] <ariard> glozow: feel free to take it and refine like you wanna, i've to catch up on the LDK-side :)
[2021-06-22 20:46:28] <glozow> ariard: i might explode from having too much fun 😝
[2021-06-22 20:47:38] <ariard> glozow: no worries, you'll do great :)
[2021-06-22 21:00:37] ⇐ Alexandre_Chery quit ([email protected]): Quit: Client closed
[2021-06-23 03:01:04] → stonefox joined (~stonefox@user/stonefox)
[2021-06-23 07:08:11] → gleb joined ([email protected])
[2021-06-23 08:16:03] ← livestradamus left (~quassel@user/livestradamus): https://quassel-irc.org - Chat comfortably. Anywhere.