--- Day changed Wed Jan 27 2021
00:21 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
01:23 -!- jackk_ [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
02:00 -!- belcher_ is now known as belcher     
02:26 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
02:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
02:26 -!- vasild_ is now known as vasild     
02:55 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews     
02:59 < michaelfolkson> Gonna be reading up on package relay today before glozow PR review club later. Anyone doing the same?
03:00 < michaelfolkson> Design questions: https://github.com/bitcoin/bitcoin/issues/14895
03:01 < michaelfolkson> Bitcoin Optech topic page: https://bitcoinops.org/en/topics/package-relay/
03:13 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
03:14 < michaelfolkson> ariard post on transaction pinning in Lightning: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
03:18 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
03:19 < jonatack> i did a review club on package relay
03:19 < jonatack> https://bitcoincore.reviews/16401
03:20 < jonatack> the notes there link to some good resources
03:20 < michaelfolkson> Ah nice, thanks jonatack! Appears I missed that one
03:34 < michaelfolkson> At least in a Lightning context we are concerned with packages of two transactions. An initial too low fee channel close attempt and an additional higher fee CPFP. I don't see the use case for packages of more than two transactions
03:34 < michaelfolkson> I guess if you were closing multiple Lightning channels you might want to have multiple pairs of transactions in a package
03:36 < michaelfolkson> But the key is pairs. A package of multiple pairs is a nice to have but not a priority
03:37 < michaelfolkson> Unless you need to do a CPFP on a CPFP because the first CPFP didn't have a high enough fee...
03:38 < michaelfolkson> But in that case you'd want to just send a new package with a pair in it I think and assume the old package won't get confirmed
03:40 < michaelfolkson> Maybe packages are useful for vaults, covenants...
03:54 < aj> michaelfolkson: you wouldn't have multiple pairs (probably), you'd have multiple parents all paid for by a single child
03:56 < michaelfolkson> Ah thanks. So that's where the package size gets greater than 2 in a Lightning context
03:56 < michaelfolkson> Makes sense
03:59 < michaelfolkson> Say 5 attempted channel close transactions with too low fee and 1 massive CPFP that makes sure all 5 channels get closed (total 6)
04:39 < michaelfolkson> I always get in a muddle on the failed HTLC motivation for closing a channel. The channel counterparty cheating you and being up against a deadline to get your justice transaction in makes sense to me
04:40 < michaelfolkson> I guess there is also the case where your counterparty is online, willing to close the channel but you can't agree on a fee for closing the channel
04:43 < michaelfolkson> But that ends up being the same scenario as if your counterparty is offline
04:44 < michaelfolkson> Submit the latest commitment transaction with your funds timelocked and potentially too low a fee
04:48 < michaelfolkson> I think the deadline urgency (and hence the need for package relay) only comes into play in the case of counterparty trying to cheat you or the failed HTLC case (you don't get the preimage to the hash in time).
04:50 < michaelfolkson> No urgency/deadline in the counterparty is offline or counterparty won't agree an updated fee with you case (and no need for package relay). Only counterparty cheating or failed HTLC case
04:51 < michaelfolkson> I guess if you make the assumption that the counterparty is definitely honest. If you are uncertain in any way of your counterparty's honest you don't want to take that risk
04:52 < michaelfolkson> *honesty
04:55 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 264 seconds]     
05:07 < glozow> you cannot assume your counterparty is honest
05:08 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews     
05:09 -!- heisenberg_hunt [~Heisenber@27.5.129.111] has joined #bitcoin-core-pr-reviews     
05:17 -!- thomasb06 [~thomasb06@leat141.unice.fr] has joined #bitcoin-core-pr-reviews     
05:19 < michaelfolkson> glozow: Of course you can't when you design Lightning protocol ;) Just trying to lay out the scenarios where you'd need to use package relay
05:19 < michaelfolkson> Lightning protocol would be very easy if you just assumed everyone was honest
05:20 -!- heisenberg [~Heisenber@27.5.130.76] has joined #bitcoin-core-pr-reviews     
05:21 < michaelfolkson> Wouldn't go to chain ever ;)
05:23 -!- heisenberg_hunt [~Heisenber@27.5.129.111] has quit [Ping timeout: 260 seconds]     
05:24 < glozow> oh, I think of package relay as a general p2p enabled thing, not consciously turned on/off by the user. A user would just decide to CPFP. The network would package relay it as appropriate.
05:27 < glozow> I don't think Lightning has channel parties re-negotiate the fees of their closing transactions, cooperative or not, although I may be mistaken
05:28 < michaelfolkson> glozow: I'd have to check if they can currently but they should. A cooperative close is strictly better than a non-cooperative close because there are no timelocks enforced on outputs
05:28 < michaelfolkson> If you can do cooperative close you should. No reason to lock up funds in a output for no reason
05:29 < michaelfolkson> But on the general p2p enabled thing that is what I understood you were taking it, that makes sense
05:30 < michaelfolkson> If your counterparty is willing to change the fee to what you want that is much better than doing a non-cooperative close. (other than a touch more code complexity)
05:34 < glozow> wait like, u switch from a non-cooperative to a cooperative + new fee?
05:35 < glozow> or you're just saying in general try to do cooperative
05:36 < michaelfolkson> In theory you should right? If your counterparty is willing to cooperate and increase the fee
05:36 < michaelfolkson> I don't know what is currently in the specs and the implementations
05:36 -!- heisenberg [~Heisenber@27.5.130.76] has quit [Quit: Leaving]     
05:36 < michaelfolkson> I should look it up
05:37 < michaelfolkson> Basically the hope is that package relay isn't needed the majority of the time. But the whole security model of Lightning hinges on it in a high fee environment
05:38 < michaelfolkson> So really important even if it isn't used that much
05:39 < michaelfolkson> All the tough stuff is in the unhappy paths
05:39 < glozow> yes, I think of it that way. having package relay doesn't mean we use it all the time, but not being able to relay packages makes Lightning more risky in these scenarios
05:41 < michaelfolkson> Yup if you can't get your justice transaction into the chain the security model of Lightning is broken
05:43 < glozow> Just to clarify for pr review club, btw, package relay is relevant but not a prerequisite and I'm not planning on discussing it at length (just in case anyone sees this)
05:45 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:48 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
05:49 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:50 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
05:51 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:52 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
05:54 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:54 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
05:56 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:57 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
05:58 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
05:59 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
06:00 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
06:01 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
06:02 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
06:03 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
06:04 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
06:05 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
06:06 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
06:07 -!- jackk_ [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
06:12 < michaelfolkson> The more I think about Signet the more I think full blocks and variable network fee levels would be great for testing this kind of stuff :)
06:13 < michaelfolkson> Need a transaction generator to fill up Signet blocks
06:31 -!- jadi [~jadi@185.21.77.250] has joined #bitcoin-core-pr-reviews     
06:41 < michaelfolkson> If motivation for package relay is interesting to anyone here's a video that may be helpful. As Gloria said though not needed for the meeting in a couple of hours https://www.youtube.com/watch?v=BXro_sB_kGk
06:51 < thomasb06> michaelfolkson: nice
06:56 -!- jackk_ [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
07:10 -!- Larsson [~l@2804:7f7:a6aa:5213:eb23:68a0:acb6:4e8e] has joined #bitcoin-core-pr-reviews     
07:14 -!- thomasb06 [~thomasb06@leat141.unice.fr] has quit [Remote host closed the connection]     
07:24 < jonatack> michaelfolkson: wow, nice
07:48 < emzy> *watched/liked/subscribed*
07:50 < michaelfolkson> Thanks ;)
08:03 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
08:03 < jonatack> i think we were only 4 or 5 participants in the oct 2019 package relay review club session...things have changed :)))
08:13 -!- worc3131 [~quassel@90.221.179.224] has joined #bitcoin-core-pr-reviews     
08:15 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
08:20 -!- worc3131 [~quassel@90.221.179.224] has quit [Remote host closed the connection]     
08:22 -!- aqquadro [02ee6c29@unaffiliated/aqquadro] has joined #bitcoin-core-pr-reviews     
08:25 < ariard> michaelfolkson: beyond assuming your counterparty is cheating you, you have disaster scenarios like mempool congestion and counterparties being under network outage, so you might have to use package relay there
08:26 < ariard> also it's more likely a lightning node should use package relay by default, there is no such thing as a global mempool, so you might be under pinning but unable to see it
08:27 < ariard> note, counterparties cooperation to adjust feerate should progressively be dry-out as a behavior with the coming deployment of anchor outputs
08:29 < michaelfolkson> ariard: Right but in those disaster scenarios you only lose money if your counterparty advertently or inadvertently cheats
08:29 < michaelfolkson> You won't lose money as long as your counterparty doesn't do something dishonest
08:30 -!- prayank [~andr0irc@2402:8100:206a:1e47:7f8d:cc7a:9411:8426] has joined #bitcoin-core-pr-reviews     
08:30 < michaelfolkson> Just wait for counterparty to come back up or mempool congestion eases
08:30 < michaelfolkson> Apart from the not receiving preimage to HTLC in time. I'm still hazy on that different scenarios there
08:30 < ariard> michaelfolkson: if you're a routing node and your counterparty came back after HTLC deadline on the incoming HTLC, you should close to avoid the confirmation race
08:31 < michaelfolkson> Right and then package relay is in play / useful
08:31 < ariard> yeah most of attack scenarios are okay in 2-parties setup, but when you have 3-parties setup like routing node it's hard to envision...
08:32 < michaelfolkson> When you say "package relay by default" that is when there are two or more transactions right? If one transaction is enough you wouldn't "package" it up?
08:33 < michaelfolkson> I guess you could...
08:34 < michaelfolkson> Have the same package protocol whether for 1 transaction or 2 or 5
08:34 < ariard> depends which transactions you want to confirm, package relay isn't useful anymore for HTLC ones post-anchor you can aggregate them freely thanks to malleability
08:35 < ariard> to precise, using package relay by default to close channels, i.e broadcasting the commitment
08:35 < glozow> package relay would be used by default, not in reaction to malicious activity. we always wear a helmet, not only when we're planning to fall on our heads
08:36 < ariard> sure I hope we will have the same package protocol for N-txn, what we might do is deploy firsht 2-txn as a package policy then 2 >
08:37 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-lrklepokwofiibml] has quit [Ping timeout: 240 seconds]     
08:37 -!- schmidty [sid297174@gateway/web/irccloud.com/x-bcmslhjuomznedcf] has quit [Ping timeout: 240 seconds]     
08:37 < michaelfolkson> glozow: Depends on the overhead. If it was entirely unnecessary for 1 transaction and had a significant overhead in terms of the message sent to your peers then no.
08:37 -!- hebasto [sid449604@gateway/web/irccloud.com/x-ytveymggjyvonvas] has quit [Ping timeout: 264 seconds]     
08:37 -!- felixweis [sid154231@gateway/web/irccloud.com/x-mdptrwlrtlphtxkd] has quit [Ping timeout: 264 seconds]     
08:37 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-uboeuicxeymktnyo] has quit [Ping timeout: 260 seconds]     
08:37 -!- drbrule [sid395654@gateway/web/irccloud.com/x-giisfptxuqrnwclp] has quit [Ping timeout: 260 seconds]     
08:37 -!- digi_james [sid281632@gateway/web/irccloud.com/x-mcgalubmefqoyzre] has quit [Ping timeout: 265 seconds]     
08:37 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-cbzziiqafmjrlnye] has quit [Ping timeout: 265 seconds]     
08:37 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-xkqcmddsoqhojjwd] has quit [Ping timeout: 272 seconds]     
08:38 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-rqajlfifxlipbvar] has quit [Ping timeout: 258 seconds]     
08:38 < michaelfolkson> The "overhead" isn't significant in this case right?
08:38 -!- dburkett [sid411344@gateway/web/irccloud.com/x-tkxwhnhavbsakwkd] has quit [Read error: Connection reset by peer]     
08:38 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-uzigebtuljkhnqcp] has quit [Read error: Connection reset by peer]     
08:38 -!- fanquake [sid369002@gateway/web/irccloud.com/x-cdfqabdvbagqttfh] has quit [Read error: Connection reset by peer]     
08:38 -!- jamesob [sid180710@gateway/web/irccloud.com/x-kdconuypcvgzahop] has quit [Read error: Connection reset by peer]     
08:38 -!- moneyball [sid299869@gateway/web/irccloud.com/x-rochyfnjwpmypxlr] has quit [Write error: Connection reset by peer]     
08:38 -!- ajonas [sid385278@gateway/web/irccloud.com/x-fzklvcabnnbgevvy] has quit [Read error: Connection reset by peer]     
08:38 -!- SurajUpadhyay [uid421192@gateway/web/irccloud.com/x-lxsueigafytgvkqo] has quit [Read error: Connection reset by peer]     
08:38 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-csphfdkwceqgbych] has quit [Write error: Connection reset by peer]     
08:38 -!- amiti [sid373138@gateway/web/irccloud.com/x-ayunlkaefenrhtuj] has quit [Read error: Connection reset by peer]     
08:38 -!- davterra [uid458765@gateway/web/irccloud.com/x-lhpbswxfklwpxape] has quit [Read error: Connection reset by peer]     
08:38 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-ztegzrteixgwybxf] has quit [Read error: Connection reset by peer]     
08:38 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-xiafkyvtjtuehoop] has quit [Read error: Connection reset by peer]     
08:38 -!- fjahr [sid374480@gateway/web/irccloud.com/x-wkigcsbdradvztsy] has quit [Read error: Connection reset by peer]     
08:38 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-cfpxvfoqzzaxcsfp] has quit [Read error: Connection reset by peer]     
08:38 -!- illest101 [uid109953@gateway/web/irccloud.com/x-sijrojexfmljitno] has quit [Read error: Connection reset by peer]     
08:39 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-iecubrfqgzplxinh] has quit [Ping timeout: 258 seconds]     
08:39 < michaelfolkson> No point sending larger message than necessary if it provides zero benefit in the 1 transaction case
08:39 -!- drbrule [sid395654@gateway/web/irccloud.com/x-nctvgorjcdulbvzr] has joined #bitcoin-core-pr-reviews     
08:39 -!- SurajUpadhyay [uid421192@gateway/web/irccloud.com/x-uefgzwkzruiwmhar] has joined #bitcoin-core-pr-reviews     
08:39 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-fqtcojnbmezqqmsv] has joined #bitcoin-core-pr-reviews     
08:39 -!- schmidty [sid297174@gateway/web/irccloud.com/x-xvvlfkntomjeacbw] has joined #bitcoin-core-pr-reviews     
08:39 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-afvasvujficmfbrp] has joined #bitcoin-core-pr-reviews     
08:40 -!- glozow [uid453516@gateway/web/irccloud.com/x-fxumjocdhrcrnkpo] has quit [Ping timeout: 272 seconds]     
08:40 -!- fanquake [sid369002@gateway/web/irccloud.com/x-rnluuhvzhkzsagov] has joined #bitcoin-core-pr-reviews     
08:40 -!- digi_james [sid281632@gateway/web/irccloud.com/x-mgsawihcfayicthp] has joined #bitcoin-core-pr-reviews     
08:41 -!- brunog [bbb72beb@187.183.43.235] has joined #bitcoin-core-pr-reviews     
08:42 -!- jamesob [sid180710@gateway/web/irccloud.com/x-vtfhagsmwrtlovku] has joined #bitcoin-core-pr-reviews     
08:42 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-jdprefwyhgpusmtg] has joined #bitcoin-core-pr-reviews     
08:42 -!- amiti [sid373138@gateway/web/irccloud.com/x-auoacfajurchojqe] has joined #bitcoin-core-pr-reviews     
08:42 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-vpggjtvyxjofpnen] has joined #bitcoin-core-pr-reviews     
08:42 -!- hebasto [sid449604@gateway/web/irccloud.com/x-mllhoyrmxdikkxgm] has joined #bitcoin-core-pr-reviews     
08:43 < ariard> michaelfolkson: hard to qualify the overhead, likely a real one if you have INV(pkg)
08:43 -!- fjahr [sid374480@gateway/web/irccloud.com/x-rcvxpwznmxtiozvi] has joined #bitcoin-core-pr-reviews     
08:44 < ariard> what do you mean by 1 transaction case here?
08:44 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ukeiamoftqdxfbvz] has joined #bitcoin-core-pr-reviews     
08:44 -!- dburkett [sid411344@gateway/web/irccloud.com/x-fsktttelmhthtmah] has joined #bitcoin-core-pr-reviews     
08:44 -!- ajonas [sid385278@gateway/web/irccloud.com/x-afwpuvrnyrfhxzoe] has joined #bitcoin-core-pr-reviews     
08:44 < michaelfolkson> In the case that onchain fees are what you expected (or lower) when you aim to close the channel
08:45 < michaelfolkson> No need for CPFP
08:45 -!- davterra [uid458765@gateway/web/irccloud.com/x-buyeoafdljnffbjr] has joined #bitcoin-core-pr-reviews     
08:45 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-fdrrqsjkoesabmel] has joined #bitcoin-core-pr-reviews     
08:45 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-wwpwazjwlmnievjx] has joined #bitcoin-core-pr-reviews     
08:45 -!- felixweis [sid154231@gateway/web/irccloud.com/x-smefinmvkaltzcwo] has joined #bitcoin-core-pr-reviews     
08:45 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-hzzvfdtdjawztrby] has joined #bitcoin-core-pr-reviews     
08:45 -!- moneyball [sid299869@gateway/web/irccloud.com/x-dgnnglpoxudmwpsz] has joined #bitcoin-core-pr-reviews     
08:46 -!- lightlike [~lightlike@p200300c7ef1e0e004059a883a2675c63.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
08:47 < ariard> LN-side, deprecating completely the negotiation fee mechanism has some favours, if we go that way, commitment txn will be signed with min relay fee+1
08:48 < michaelfolkson> Gotcha so you will literally be using 2 transactions every time because the fee initially set was rock bottom
08:49 < michaelfolkson> I was thinking you'd estimate the fee based on the current fee environment to reduce the possibility of needing to use 2 transactions
08:49 < ariard> michaelfolkson: another option is attaching a average-fee-on-the-last-2-few-y but it's shotgunish, it will force you a) to pay more when congestion is under the picked up feerate
08:50 < ariard> and thus forcing b) redeploy LN if the feerate become really inacurrate
08:50 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-kklyqnhsxajgkzyb] has joined #bitcoin-core-pr-reviews     
08:50 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-luvhqfgmrsyhdsxj] has joined #bitcoin-core-pr-reviews     
08:50 -!- brunog [bbb72beb@187.183.43.235] has quit [Quit: Connection closed]     
08:51 < michaelfolkson> I'm just thinking if we plan for a high fee environment you'd want to avoid using 2 transactions if you possibly could
08:51 -!- brunog [bbb72beb@187.183.43.235] has joined #bitcoin-core-pr-reviews     
08:51 < michaelfolkson> All those vbytes
08:51 -!- brunog [bbb72beb@187.183.43.235] has quit [Client Quit]     
08:52 < ariard> I think the real issue is we don't have a good mechanism to price correctly network-wise resources consumption for advanced tx-relay (RBF, package-relay)
08:52 < michaelfolkson> Sometimes it would be impossible of course (if fees went wild, no way to avoid two transactions)
08:52 < ariard> the BIP125 ones are fairly arbitrary for not, I agree the vbytes waste on the p2p level is a concern IMO
08:53 < michaelfolkson> It is a market, supply and demand. No way to price correctly
08:53 < michaelfolkson> Just need to give users the tools so they can minimize the fees they pay
08:53 < ariard> you might have already bandwidth spikes with few blocks mined in the row  (though compact blocks should rescure here)
08:54 -!- webster781 [70c492d2@112.196.146.210] has joined #bitcoin-core-pr-reviews     
08:54 < michaelfolkson> If users want to try to avoid using two transactions by estimating the fee that should be facilitated imo
08:54 -!- glozow [sid453516@gateway/web/irccloud.com/x-eecqfvkinqkxwjyj] has joined #bitcoin-core-pr-reviews     
08:54 < michaelfolkson> And then if they caught out they have the tools to respond
08:54 < michaelfolkson> *they get
08:55 -!- wiz [~j@bitcoin.kyoto] has joined #bitcoin-core-pr-reviews     
08:55 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-luvhqfgmrsyhdsxj] has quit [Ping timeout: 260 seconds]     
08:55 -!- sepoyi [~ps@112.196.146.210] has joined #bitcoin-core-pr-reviews     
08:55 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-kklyqnhsxajgkzyb] has quit [Ping timeout: 260 seconds]     
08:56 -!- illest101 [uid109953@gateway/web/irccloud.com/x-vnxsczgbiyrkcutc] has joined #bitcoin-core-pr-reviews     
08:56 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-yybldqqeumoduzjd] has joined #bitcoin-core-pr-reviews     
08:56 -!- that [~that@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
08:57 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
08:57 -!- wiz [~j@bitcoin.kyoto] has quit [Remote host closed the connection]     
08:57 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
08:57 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-mradydukdnmhxyal] has joined #bitcoin-core-pr-reviews     
08:57 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews     
08:57 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
08:57 < michaelfolkson> "it will force you a) to pay more when congestion is under the picked up feerate"
08:58 < michaelfolkson> You could agree to a new comitment transaction with a lower fee when fees drop?
08:58 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-rummhbwcwnyvyqnh] has joined #bitcoin-core-pr-reviews     
08:58 < michaelfolkson> Anyway, this PR review club is gonna start.
08:58 -!- webster781 [70c492d2@112.196.146.210] has quit [Client Quit]     
08:59 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
08:59 < ariard> michaelfolkson: see end of my comment here: https://github.com/lightningnetwork/lightning-rfc/pull/824#pullrequestreview-547730325, if you can come up with an easy economic model to tell you when to switch fee mechanism, and secure why not :)
09:00 < glozow> #startmeeting
09:00 -!- jadi [~jadi@185.21.77.250] has quit [Remote host closed the connection]     
09:00 < emzy> hi     
09:00 < glozow> Welcome to PR Review Club everyone!
09:00 < jnewbery> hi!     
09:00 < Murch> Hello
09:00 < murtyjones> hiya
09:00 < norisgOG> hi!     
09:00 < robot-dreams> hi!     
09:00 < AnthonyRonning> hello
09:00 < svav> Hi     
09:00 < lightlike> hi     
09:00 < glozow> Feel free to say hi so we know you're here :) Any first-timers?
09:00 < sepoyi> hi     
09:00 < that> hi     
09:00 < thomasb06> hi     
09:00 < ccdle12> hi     
09:00 < dhruvm> hi     
09:00 < michaelfolkson> hi     
09:00 -!- wiz [~j@bitcoin.kyoto] has joined #bitcoin-core-pr-reviews     
09:00 < glozow> Today, we’re looking at #20833: enable 📦 through testmempoolaccept (https://github.com/bitcoin/bitcoin/pull/20833)
09:00 < ariard> hi     
09:00 < sepoyi> first time here
09:00 < stacie> hi     
09:00 < prayank> hi     
09:00 < glozow> welcome sepoyi!
09:00 < wiz> hi     
09:01 < glozow> Did anyone get a chance to review the PR? y/n
09:01 < AnthonyRonning> y     
09:01 < emzy> n     
09:01 < robot-dreams> y     
09:01 < murtyjones> notes yes, PR no
09:01 < norisgOG> n     
09:01 < stacie> y     
09:01 < thomasb06> y     
09:01 -!- sishir [c01f69a3@calvisitor-192-31-105-163.calvisitor.berkeley.edu] has joined #bitcoin-core-pr-reviews     
09:01 < svav> y     
09:01 < sepoyi> y     
09:01 < glozow> btw this club is dedicated to learning, so you’re always welcome to ask any questions at any time :)
09:01 < jnewbery> welcome sepoyi!
09:01 < dhruvm> n     
09:01 < jnewbery> y     
09:01 < sishir> hi     
09:01 < ccdle12> n     
09:01 < sunon> y     
09:02 -!- effexzi [uid474242@gateway/web/irccloud.com/x-nbmrmunpuioxjnoe] has joined #bitcoin-core-pr-reviews     
09:02 < glozow> ok let's start with some conceptual questions. What are some use cases for enabling packages through testmempoolaccept? (non-package-relay related please, since that’s very far off from this PR)
09:02 < sepoyi> thanks glozow jnewbery
09:02 < AnthonyRonning> A series of offline transactions that build on each other
09:02 < sishir> This allows you to test validity for second-layer application transaction chains (i.e. with multiple spending paths and where you don't want to broadcast yet).it could be helpful to return more information to the client, but don't know what that would look like concretely
09:02 < murtyjones> maybe testing channel opening on LN?
09:02 < thomasb06> testmempoolaccept will tell whether the transaction would be accepted by the nodes.
09:02 < dhruvm> chained transactions for L2 protocols
09:02 -!- that is now known as bountiful     
09:03 < glozow> yep! yep!
09:03 < robot-dreams> Specifically, double check if the other party cheats in a lightning channel, the subsequent "justice" transaction would get accepted
09:03 < robot-dreams> (check the pair of transactions without adding either to the mempool)
09:03 < ariard> robot-dreams: not an issue, justice tansactions are fully malleable
09:03 < ariard> it's more for counter-signed txn
09:04 < stacie> A non-package-relay answer: With packages you can now validate multiple txs with one testmempoolaccept call (which previously accepted an array but but only expected it to be size one)
09:04 < ariard> *single-party malleable
09:04 < glozow> yeah! we can check transactions that build on each other, although there are some limitations - would anyone like to describe some limitations with what this PR enables?
09:04 < sishir> timelocks, off-chain covenants?
09:04 < murtyjones> from what i read, parent transactions of the tested one must be in the mempool or chain
09:04 < svav> To enable child pays for parent transactions.
09:04 < murtyjones> as opposed to being given in the request
09:04 < AnthonyRonning> does it requires the transactions in a package to be submitted in order of dependency?
09:04 < robot-dreams> ariard: thanks for the clarification
09:05 < thomasb06> it only works if the parent transactions are confirmed or in the mempool.
09:05 < glozow> yep, sishir named some good ones, ariard has a good comment on this: https://github.com/bitcoin/bitcoin/pull/20833#pullrequestreview-570114670
09:05 < lightlike> I think transactions need to be submitted in the right order.
09:05 < glozow> and yes, the PR requires you to have them sorted like AnthonyRonning said
09:05 -!- erijon [~erijon@2a0b:f4c2:2::1] has joined #bitcoin-core-pr-reviews     
09:06 < glozow> (and lightlike said)
09:06 < stacie> Another limitation is the atomic validation - the response is only for the first failure, so if you have multiple, you'll need to go back and correct each one before calling testmempoolaccept again
09:06 < glozow> stacie: correct! this gives you all-or-nothing success or failure
09:07 < ariard> stacie: in practice, that's hard to do because it assumes your txn generation backend to fully consume the errors and be able to correct them while still enforcing application semantic
09:07 < glozow> alright I think we have a good idea of what this PR does/doesn't do, let's dive into the code
09:07 < glozow> The PR starts off with a few refactors. From a code quality standpoint, what is the benefit of moving the validation state, replaced transactions, and fee to `Workspace`? Should we add `coins_to_uncache` to `Workspace `and make `ATMPArgs` a const? Why or why not?
09:07 < ariard> beyond fees bumping, I'm not aware of such backend
09:08 < AnthonyRonning> For code quality, it’s more explicit than relying on `AcceptToMemoryPool` to fill in memory addresses for passed in state, replaced txs, fee.
09:08 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:08 < glozow> AnthonyRonning: I like where that's going, yeah! we have the `MemPoolAccept` class fill in the results instead of ATMP
09:09 < AnthonyRonning> what does ATMP stand for?
09:09 < glozow> what should ATMPArgs be used for, and what should Workspace be used for?
09:09 < sunon> AcceptToMemoryPool
09:09 < glozow> AnthonyRonning: AcceptToMemoryPool, sorry
09:09 < AnthonyRonning> oh yeah duh thanks :)
09:09 < stacie> ariard - agree, and I think the atomic validation is a good thing, but I wonder if people will use this new feature to try validating a set of unrelated transactions. The only use case I can see is to save on the network overhead of multiple RPC calls, but it does seem strange to need to batch/package up a bunch of unrelated transactions ¯\_(ツ)_/¯
09:11 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Client Quit]     
09:11 < AnthonyRonning> I was a bit unsure about the `coins_to_uncache` or const `ATMPArgs` part of the question
09:11 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:11 < glozow> stacie ariard: yeah, this would still work for unrelated transactions, although that's not what it's intended for. we have a question about API later so we could discuss it further :)
09:12 < glozow> cool! So I'll answer the first part, ATMPArgs = arguments for validation, e.g. test_accept. The Workspace gets updated as we go through the steps of validation.
09:12 < svav> The Workspace should contain state that may change
09:12 < svav> throughout validation.
09:12 < glozow> Could someone offer an opinion on which should be const and which should be mutable?
09:12 < lightlike> I can see that it makes it makes the code cleaner and easier to read if we separate input arguments and results for ATMP - not sure if that is the only reason for the refactor though?
09:13 < ariard> if you modify ATMPArgs at a later steps of the validation process you might invalidate previous ones
09:13 < sunon> Args const, workspace mutable?
09:14 < glozow> sunon: ding ding! yep
09:14 < glozow> ariard: yup yup, it'd be really bad if we're using different validation params at different steps in the process
09:15 < glozow> lightlike: yep, the refactor basically makes the code cleaner. no logic change.
09:15 < glozow> ok chugging along...
09:15 < glozow> Why do we run `PreChecks` for ALL of the transactions before script checks? Would it still be correct if we didn’t do this?
09:15 < glozow> Link to the code we're talking about, `AcceptMultipleTransactions`: https://github.com/bitcoin/bitcoin/blob/70f84b22199cd0afffd12ea8e8934d22b0f0c7f4/src/validation.cpp#L1074
09:15 < sishir> What’s the difference between policy checks and pre checks?
09:15 < sunon> I think it's to fail early without doing unnecessary work
09:15 < AnthonyRonning> To fail fast and avoid signature checks if one tx in a package fails something basic like input tx or fee.
09:16 < glozow> sunon: AnthonyRonning: correct!
09:16 -!- Caralie [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews     
09:17 < michaelfolkson> Policy checks are a superset of the pre checks right? The pre checks are policy checks too?
09:17 < jnewbery> sishir: the PolicyScriptChecks function is validating the scripts and signatures. That's the most computationally expensive part of validating a transaction
09:17 < glozow> sishir: policy includes non-consensus rules that Bitcoin Core nodes enforce on unconfirmed transactions, mostly to protect from DoS. Some of the checks are in `PreChecks`, and some are in `PolicyScriptChecks`
09:17 -!- effexzi [uid474242@gateway/web/irccloud.com/x-nbmrmunpuioxjnoe] has quit [Read error: Connection reset by peer]     
09:17 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-rummhbwcwnyvyqnh] has quit [Read error: Connection reset by peer]     
09:17 < sishir> michaelfolkson I thought Policy checks are a superset of consensus checks
09:17 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-mradydukdnmhxyal] has quit [Read error: Connection reset by peer]     
09:17 < sunon> Surface for DoS, right?
09:17 < michaelfolkson> sishir: They are haha
09:17 -!- jackk_ [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
09:18 < michaelfolkson> But pre checks I think are a subset of policy checks
09:18 < glozow> yeah you're all correct. Policy checks rules in addition to consensus. PreChecks is a subset of policy checks because it does some of the policy checks haha
09:18 < michaelfolkson> Phew
09:18 < michaelfolkson> Quite the brain exercise
09:18 < glozow> sunon: yes, script checking is really expensive, we try not to do that as much as possible
09:18 < sishir> i see that makes sense thank you
09:18 < sunon> Ah thanks I see the venns in my head lol
09:18 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-dxlikkepfxrtmvdj] has joined #bitcoin-core-pr-reviews     
09:18 -!- effexzi [uid474242@gateway/web/irccloud.com/x-xdkgijtcdxhnphds] has joined #bitcoin-core-pr-reviews     
09:19 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-tkubptbtgnwrsfgc] has joined #bitcoin-core-pr-reviews     
09:19 < michaelfolkson> I don't think any pre checks are consensus checks if that helps
09:19 < glozow> ok, so quick sanity check: would it still be correct if we did PreChecks + PolicyScriptChecks for each transaction?
09:19 < lightlike> do we need to be concerned about DOS though for a RPC? Or is that in preparation for reusing this code for getting packages from actual peers?
09:19 < ariard> michaelfolkson: but your policy sets might be disjunctive and your consensus sets extended across versions
09:19 < jnewbery> well prechecks also rejects transactions for being consensus-invalid
09:19 < glozow> lightlike: right, we're not too concerned about DoS for an RPC. but this validation code is shared for txns we get through P2P
09:20 < michaelfolkson> ariard, jnewbery: I stand corrected. Correct those venn diagrams
09:20 < sunon> It would still be correct to do both
09:20 < glozow> sunon: yes!
09:20 < glozow> this is purely to fail faster.
09:20 < glozow> Next question: In `AcceptSingleTransaction` (with test_accept=true), both `PolicyScriptChecks` and `ConsensusScriptChecks` are run. However, in `AcceptMultipleTransactions`, we don’t run `ConsensusScriptChecks`. Why is that okay?
09:21 < sishir>  PolicyScriptChecks is stricter so ConsensusScriptChecks is unnecessary.
09:21 < AnthonyRonning> Since `AcceptMultipleTransactions` does not broadcast the transactions, even with `test_accept=false`, there’s no reason to do consensus checks.
09:21 < jnewbery> like this for example: https://github.com/bitcoin/bitcoin/blob/15a9df070615e7e8f29c17a92b889f19218f25ac/src/validation.cpp#L793-L807 a transaction that spends the output of transaction it conflicts with can never be valid. That's a consensus rule since such a transaction could never appear in the block chain
09:21 -!- illest101 [uid109953@gateway/web/irccloud.com/x-vnxsczgbiyrkcutc] has quit [Ping timeout: 272 seconds]     
09:21 -!- hebasto [sid449604@gateway/web/irccloud.com/x-mllhoyrmxdikkxgm] has quit [Ping timeout: 264 seconds]     
09:21 < glozow> sishir: yes! 🧠
09:21 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-fdrrqsjkoesabmel] has quit [Read error: Connection reset by peer]     
09:21 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-wwpwazjwlmnievjx] has quit [Read error: Connection reset by peer]     
09:21 < glozow> like you said before, policy is strictly stricter than consensus :)
09:22 < glozow> Okay but followup question: why do we run `ConsensusScriptChecks` at all in ATMP?
09:22 < sishir> Follow up:At  L2 level we’re aiming for is a txstandardness verifier, a tool encapsulating ATMP checks
09:23 < michaelfolkson> For those who are confused glozow linked to this StackExchange post on policy and consensus in her notes https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c
09:23 < glozow> thanks michaelfolkson
09:23 < glozow> sishir: could you elaborate?
09:24 < sishir> https://github.com/bitcoin/bitcoin/pull/20833#issuecomment-765057102
09:24 < AnthonyRonning> thanks michaelfolkson! I was indeed confused on what consensus checked
09:24 -!- robot-dreams [~textual@172.92.4.53] has joined #bitcoin-core-pr-reviews     
09:25 < jnewbery> There are two reasons to run ConsensusScriptChecks. Anyone want to guess what either of those are?
09:25 -!- mep1911 [5ed843cf@dslb-094-216-067-207.094.216.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews     
09:25 < sepoyi> To ensure backward compatibility?
09:25 < ariard> glozow: I think we don't want to run `ConsensusScriptChecks` because for now those txn aren't added to the mempool and thus there is no matter caching their script results for a potential block validation?
09:26 < michaelfolkson> Run on your transaction or someone else's transaction jnewbery? Or do you mean in the code?
09:26 < michaelfolkson> I think you mean in the code
09:26 < jnewbery> michaelfolkson: I mean in MemPoolAccept
09:26 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-mmjeqtxyfjvoidsr] has joined #bitcoin-core-pr-reviews     
09:27 < robot-dreams> ariard: That was my first thought too, but then wasn't sure, why would we run it for the `AcceptSingleTransaction` case?
09:27 < glozow> ariard: yes, it's a test accept so we're not really waiting for it to be in a block. Not much to gain from script caching here
09:27 < michaelfolkson> You don't want invalid transactions in your mempool. Takes up space, inefficient, could lose you connections if you try to propagate it?
09:27 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Ping timeout: 246 seconds]     
09:28 < michaelfolkson> Ha I think I'm misunderstanding the question
09:28 -!- temp1 [70c492d2@112.196.146.210] has joined #bitcoin-core-pr-reviews     
09:28 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews     
09:28 < glozow> Ok. In a for-realsies transaction validation through MemPoolAccept.AcceptSingleTransaction() (e.g. a tx we receive on P2P), we run ConsensusScriptChecks.
09:29 < glozow> What are the 2 things this accomplishes?
09:29 < glozow> ariard mentioned one of them
09:30 < AnthonyRonning> in case a new block comes in?
09:30 < ariard> have a look in the comment in `ConsensusScriptChecks`
09:30 -!- temp1 [70c492d2@112.196.146.210] has left #bitcoin-core-pr-reviews []     
09:30 < sunon> We want to make sure they're valid txs before adding to our mempool
09:31 < glozow> ariard's hint at this line: https://github.com/bitcoin/bitcoin/blob/15a9df070615e7e8f29c17a92b889f19218f25ac/src/validation.cpp#L961
09:31 -!- hebasto [sid449604@gateway/web/irccloud.com/x-wksdajxeaaviknor] has joined #bitcoin-core-pr-reviews     
09:31 < glozow> sunon: yes, we want to make sure they're valid. that's 1 reason!
09:31 < sunon> Caches script results?
09:31 < glozow> sunon: bingo!!!!!
09:31 < jnewbery> winner!
09:31 < glozow> 💃
09:32 < glozow> even though it's guaranteed to be consensus-valid if it passes all policy checks, we would like to cache the script results!
09:32 -!- lightlike [~lightlike@p200300c7ef1e0e004059a883a2675c63.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
09:32 < sunon> Learning things today!
09:32 < glozow> that means when we see it in a block, we'll have faster validation :)
09:32 -!- lightlike [~lightlike@p200300c7ef1e0e00187df4bbc841b4a3.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:32 < michaelfolkson> "have a few blocks of extra misses on soft-fork activation" I love a good soft fork reference
09:32 < glozow> whew! let's move on.
09:32 < robot-dreams> Sorry, final question about "guaranteed to be consensus-valid", if we can make that guarantee what's the check on line 968 for?
09:32 < sunon> And no expensive scriptsig checks
09:33 < glozow> When we fetch a coin from a `CCoinsViewMemPool` (in this PR), what 4 places do we look and in what order? Why do we check `cache_package_remove` before `cache_package_add`?
09:33 < robot-dreams> s/check/comment* "This is also useful in case of bugs in the standard flags that cause transactions to pass as valid when they're actually invalid."
09:33 < AnthonyRonning> `cache_package_remove`, `cache_package_add`, mempool, and then backend (disk?). We check removed first because a package tx before could have already spent another package tx’s output.
09:34 < glozow> robot-dreams: I think that's a "just in case there is a bug even though we don't think there's a bug" type of thing. policy flags as a superset of consensus flags should guarantee this. (btw we had a whole review club on this topic hehe https://bitcoincore.reviews/19698)
09:34 < glozow> AnthonyRonning: yep! you got all 4!
09:35 < AnthonyRonning> just a general code question, could there be an a single `cache_package_coin` that both adds and removes as needed? Instead of having 2 lists and iterating through both?
09:35 < ariard> yet-another belt-and-suspsender which would be worthy to document better
09:35 < glozow> and yes! we check removed first for precisely that reason, a tx in a package can spend an output created by another tx in the package.
09:35 < jnewbery> robot-dreams: a consensus-invalid transaction getting into the mempool is bad news for the miners. They'd construct a block including that transaction and then later find out that the block is invalid.
09:35 < glozow> Well, they'd see that error in TestBlockValidity before finding the nonce yeah?
09:36 < jnewbery> so this is just an extra check to make sure that doesn't happen. It shouldn't since policy rules should be stricter than consensus rules, but it's good to double check here.
09:36 < michaelfolkson> I guess double checking before setting your whole ASIC farm on it is nice
09:37 < glozow> AnthonyRonning: yes, that could work too. Feel free to leave a review comment :) worth exploring
09:37 < robot-dreams> jnewbery: glozow: Thanks, makes sense that it's a double check
09:37 < ariard> really-worst case scenario it could be leveraged by an attacker to censor block construction by all other miners for few hours and thus txn
09:38 < glozow> yeah true, that'd be bad.
09:38 < glozow> ok next question: If a block arrives while we’re running `PreChecks`, do we have to worry about our CoinsView becoming inconsistent?
09:38 < AnthonyRonning> No because a mempool read lock is applied before running `PreCheck`
09:39 < michaelfolkson> Nice
09:40 < glozow> AnthonyRonning: very close, our mempool shouldn't change. Is there another lock that guards our CoinsView? :)
09:40 < robot-dreams> cs_main, does this mean you can't add a block until the `Accept` is done?
09:41 < AnthonyRonning> looks like an assertion on `cs_main` though I'm not sure what guarantees that has
09:41 < dhruvm> The active chain is also guarded by cs_main
09:41 < glozow> robot-dreams: AnthonyRonning: dhruvm: correct! cs_main guards all our chain state stuff
09:41 < AnthonyRonning> ah, cs = chain state!
09:42 < glozow> and yes, we wouldn't look at the block while we're doing ATMP
09:42 < robot-dreams> Wait I think cs = critical section
09:42 < dhruvm> AnthonyRonning: I think cs is for critical section
09:42 < glozow> yeah cs = critical section
09:42 < AnthonyRonning> oh cool, thx for correction :)
09:42 < jnewbery> glozow: on you question about TestBlockValidity, yes it looks like this is called before getblocktemplate returns a block template. Although I don't know what the advice would be to a miner who saw a "TestBlockValidity() failed" error.
09:43 < glozow> cool, so feel free to grep for `cs_main` in the code everyone :) it's EVERYWHERE
09:43 < glozow> Next question: Why do we set our CoinsView backend to dummy? What bug is this trying to prevent? (We’re looking at this line: https://github.com/bitcoin/bitcoin/blob/15a9df07/src/validation.cpp#L674)
09:43 < AnthonyRonning> everything is critical 😂
09:44 < sishir> if we set backend to dummy, we lose the ability to look up the coins in m_viewmempool
09:44 < jnewbery> cs is critical section, which is a windows name for a mutex. Satoshi wrote the first implementation for windows
09:45 < ariard> jnewbery: warn a human to check the logs, you don't know which transaction is faultive, it might even be the header
09:45 < glozow> sishir: you're right that's why I change it in the PR, but why do we do it in the first place?
09:45 < michaelfolkson> PR to change the name of cs_main? :)
09:45 < sunon> We might never uncache coins that we would have pulled from disk
09:46 < jnewbery> michaelfolkson: no thanks
09:46 < glozow> sunon: yes! why do we want to uncache coins pulled from disk?
09:46 < sishir> 🤔
09:46 < glozow> michaelfolkson: please no
09:46 < michaelfolkson> jnewbery: Sorry just joking
09:46 < prayank> AnthonyRonning: Offtopic but Bitcoin Core is ranked as 4th most critical C++ OSS Project
09:47 < AnthonyRonning> prayank: ahh nice, i am biased but would give it #1 :)
09:47 < michaelfolkson> Let's stay on topic plz
09:47 < sishir> is it to protect against bugs?
09:47 < glozow> prayank: critical referring to important to the world or most amount of critical sections?
09:47 < ariard> yes bitcoin is to protect against money bug
09:47 < glozow> yeah let's stay on topic, what bugs sishir?
09:48 < sunon> We don't want to waste space in utxo cache
09:48 < glozow> sunon: yeah! can someone tell me what kind of attack someone could launch if we forgot to uncache coins we pulled into the utxo cache?
09:49 < robot-dreams> Test a package of 974 transactions where the 973rd fails?
09:49 < murtyjones> some kind of attack exhausting the cache size limit would be my guess
09:49 < dhruvm> glozow: cache thrashing?
09:49 < glozow> robot-dreams: murtyjones: dhruvm: yep!
09:50 < AnthonyRonning> is there any kind of limit to how many txns can be in a package?
09:50 < glozow> we use our cache for performance, but if the attacker got us to pull a bunch of useless coins into our cache, we'd get very little use out of it
09:50 < glozow> they could do this without packages, too
09:50 < dhruvm> murtyjones: i dont think it would exhaust the cache so much as make every cache read be a miss
09:51 < murtyjones> ah got it
09:51 < glozow> they could do it for every coin in the UTXO set (since it can be an invalid transaction) and we'd just be getting cache misses all the time
09:52 < glozow> murtyjones: i suppose it's exhaustive in that we do more disk reads than necessary
09:52 < glozow> last question before we wrap up for today: What are your thoughts on the results array (returning one for each tx if successful or the first one if failed)? Do you have any suggestions for improvement?
09:52 < Murch> glozow: Wouldn't a peer that sends us a flood of invalid txs get banned?
09:52 < lightlike> glozow: would that be an actual attack that would do something worse than slow us down a bit? I'm not so familiar with the topic, but if we have useless full cache, wouldn't we just load more txes from disk until the cache gets better again?
09:53 < AnthonyRonning> It seems like the API now does what it intended to do, so ACK. Not API-breaking because nobody could do more than 1 before anyways, this expands functionality.
09:53 < jnewbery> Murch: not necessarily. It depends why the transaction isn't accepted.
09:53 < robot-dreams> glozow: Another alternative (not necessarily improvement): return an array of the same size, first failure gets input reason, any dependents get `input-missing`?
09:53 < robot-dreams> any subsequent dependents*
09:53 < Murch> Oh right, it could be an orphan transaction or smth
09:54 < jnewbery> We don't ban peers for sending us transactions that are consensus valid but fail our policy checks, or have a fee too low to get into our mempool for example
09:54 < ariard> yeah I don't get what you don't return package size ?
09:54 < murtyjones> if there are multiple failures, it could be useful to send all of them back.
09:54 < Murch> oh right, they could also e.g. just exceed ancestor limits
09:54 < sishir> im still trying to understand this PR, will we be able to do something like this (node.testmempoolaccept([rawtx1, rawtx2, rawtx3, rawtx4])) once it's merged?
09:54 < robot-dreams> murtyjones: agreed though similar to how compiler writers want to avoid spamming users with errors if they missed a semicolon (and caused the next 500 lines to all have errors), maybe we want some way to show only "uncorrelated" errors
09:55 < glozow> lightlike: yeah, it would slow us down, it's not exhausting CPU
09:55 < jnewbery> murtyjones: we abort at the first failure (no point in trying to validate children transactions if the parent is invalid)
09:55 < murtyjones> ah okay. forgot that they have to all be related
09:55 < ariard> Murch: committing to a pairing policy which would ban evict peers for policies divergences would be a violation of the concept itself of policy :)
09:55 < Murch> murtyjones: that would conflict with the goal to "fail fast"
09:55 < glozow> sishir: yes, this PR enables that
09:56 < sishir> i see thats super cool
09:56 < stacie> Was the original intent of having testmempoolacccept take in an array to support packages? (back when the RPC call was first introduced)
09:56 -!- sishir [c01f69a3@calvisitor-192-31-105-163.calvisitor.berkeley.edu] has quit [Quit: Connection closed]     
09:56 < jnewbery> there's not time to get into this in great detail now, but the UTXO cache has a slightly unusual access pattern compared to many caches that people are familiar. The main thing it's saving us is _writes_, not _reads_
09:56 < Murch> ariard, jnewbery: well, strictly speaking I did write _invalid_ txs :p
09:56 < glozow> ariard: I think in the future we could have each result obj have that information
09:57 < michaelfolkson> stacie: I think the use case for testing 1 transaction is sufficient intent
09:57 < glozow> since they won't necessarily 1 package
09:57 < glozow> stacie: yes, that was the intent
09:57 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
09:57 < michaelfolkson> But you could test 1 transaction and that would still be useful right?
09:57 < ariard> stacie: package is a notion from the mempool, it has been a forever talk to expose it as a p2p thing
09:57 < glozow> comment from original PR: https://github.com/bitcoin/bitcoin/pull/11742#issuecomment-352842691
09:57 < jnewbery> if a coin gets spent shortly after it gets created, we never have to write it to disk at all, and many coins get spent in the same block or the next few blocks after they get created (see page 14 of https://eprint.iacr.org/2019/611.pdf)
09:59 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-lbrrqybqucujoaap] has joined #bitcoin-core-pr-reviews     
09:59 < stacie> ah! I see it in that comment, "A future pull can extend this rpc to take lists of more than one raw transaction and feed them into an ephemeral mempool (e.g. based on the current mempool)." thanks!
09:59 < dhruvm> jnewbery: interesting. does the low frequency of flushing UTXOs to disk have implications on chainstate corruption in case of unexpected termination?
10:00 -!- illest101 [uid109953@gateway/web/irccloud.com/x-kgmzcwmtuklpbvqp] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> dhruv: maybe off topic. We can discuss another time!
10:00 < glozow> if anybody comes up with any other ideas on API, please feel free to comment on the PR!
10:00 < glozow> that's all we have time for today, thank you all for coming! 🤗
10:00 -!- fanquake [sid369002@gateway/web/irccloud.com/x-rnluuhvzhkzsagov] has quit [Read error: Connection reset by peer]     
10:00 < glozow> #endmeeting
10:00 < bountiful> thanks glozow
10:00 < michaelfolkson> Thanks glozow!
10:00 < AnthonyRonning> thank you glozow and everyone else!
10:00 < jnewbery> Thanks for hosting glozow. That was great!
10:00 < lightlike> thanks glozow!
10:00 -!- fanquake [sid369002@gateway/web/irccloud.com/x-emqikykffnffnaen] has joined #bitcoin-core-pr-reviews     
10:00 < stacie> thanks glozow! learned a lot ⭐️
10:00 < robot-dreams> Thanks glozow!
10:00 < thomasb06> thanks glozow
10:00 < ariard> thanks glozow!
10:00 < AnthonyRonning> Good work on the PR and +1 for commit structure too, made it easy to read
10:00 < dhruvm> jnewbery: thank you glozow !
10:00 < norisgOG> thank you glozow
10:01 -!- sepoyi [~ps@112.196.146.210] has quit []     
10:01 < n3wBEEEE> thanks
10:01 < michaelfolkson> I don't think Coinjoin is a use case glozow. Did you mean Payjoin? https://brink.dev/blog/2021/01/21/fellowship-project-package-accept/
10:01 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Connection closed]     
10:01 < jnewbery> I'm hosting next week. I'll post notes and questions by Friday
10:01 < sunon> Thanks for hosting, glozow!
10:01 < murtyjones> thanks glozow!
10:01 < Murch> thanks!
10:01 < prayank> Thanks
10:01 < svav> Thanks glozow
10:01 < michaelfolkson> Oh no sorry not Payjoin, CoinSwap. Lol all the words
10:02 < thomasb06> jnewbery: by the way, would it be useful for Bitcoin to have an error correction algorithm at bit level? My guess is no, but I'm trying to plug in something I know
10:02 < michaelfolkson> I don't think Coinjoin and Payjoin have chains of multiple transactions
10:02 < emzy> Thanks glozow!
10:02 < michaelfolkson> And ariard if you are hanging around can we continue the conversation on use cases please? :)
10:02 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has quit [Quit: Connection closed]     
10:03 < glozow> michaelfolkson: they have transactions where you are not in full control of the inputs
10:03 < glozow> and thus fee bumping would either require re-negotiation with possibly untrusted parties or a CPFP
10:03 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 246 seconds]     
10:04 < prayank> glozow: "Critical" in my comment was based on influence and importance of a project and I had read about it here: https://twitter.com/_jonasschnelli_/status/1337351770192961540
10:04 < ariard> michaelfolkson: a coinjoin counterparty might use its output as the starting outpoint of a new chain without other coinjoin counterparies being aware of it ?
10:04 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
10:04 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-afvasvujficmfbrp] has quit [Ping timeout: 260 seconds]     
10:04 < robot-dreams> Following up on something I didn't understand from earlier, how come we do `ConsensusScriptChecks` in the testmempoolaccept -> AcceptSingleTransaction path, but not in the AcceptMultipleTransactions path?
10:04 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has quit [Quit: Connection closed]     
10:04 < ariard> but yeah here if you have use cases questions :)
10:04 < michaelfolkson> glozow: So the use case is you construct a Coinjoin with a certain fee level and then the fee level ramps up straight away?
10:04 < glozow> prayank: ah nice, thanks for linking. I just meant it as a joke since we were talking about the ubiquity of cs_main :P
10:04 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-yybldqqeumoduzjd] has quit [Read error: Connection reset by peer]     
10:04 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-tkubptbtgnwrsfgc] has quit [Read error: Connection reset by peer]     
10:04 < glozow> (and thanks for waiting until after the meeting btw!)
10:05 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-upwrqprakwaswakd] has joined #bitcoin-core-pr-reviews     
10:05 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-ipmzwnpmntbtlecw] has joined #bitcoin-core-pr-reviews     
10:05 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-oklbdmkqnwrafrjp] has joined #bitcoin-core-pr-reviews     
10:05 < glozow> robot-dreams: strictly speaking it's not necessary in the AcceptSingle with test_accept=true path
10:05 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]     
10:05 < ariard> robot-dreams: we don't use AcceptMultipleTransactions for txn potentially included in block, as of today
10:06 < glozow> I originally was going to call ConsensusScriptChecks in AcceptMultiple, but there was a discussion about it not being necessary (see https://github.com/bitcoin/bitcoin/pull/20833#discussion_r552997459)
10:06 < michaelfolkson> My understanding is that the use case for package relay is where you construct a chain of transactions that you will broadcast onchain at some point in the future (days, weeks, months)
10:06 < glozow> (I'd definitely add it back in for-realsies package accept)
10:07 < robot-dreams> Makes sense. So we could technically only call ConsensusScriptChecks in AcceptSingle in the `if (!args.m_test_accept)` case?
10:07 < robot-dreams> Actually is there a strong reason for that (e.g. avoid script result caching for test accepts)
10:07 < glozow> robot-dreams: yes, it would still work :)
10:07 < michaelfolkson> It is pretty unlikely that you'd construct a Coinjoin with a fee and then just before you broadcast it the network fees jump massively. I guess it is possible
10:07 < glozow> robot-dreams: I agree
10:08 < glozow> michaelfolkson: you can think of package relay being useful for fee-bumping transactions where you are not in full control of the inputs
10:08 < michaelfolkson> Anyway ariard... you said earlier " not an issue, justice transactions are fully malleable"
10:09 < ariard> michaelfolkson: in the context of multi-party protocol: it's either a) a conveniency mechanism is the bumped tx isn't time-sensitive or b) a security mechanism if they're
10:09 < ariard> e.g a) is coinjoin, bumping with a package attached might save you from a new round of signatures
10:10 < michaelfolkson> glozow: Right but the increased fee has to come from someone's input. I'd think it was better to just reconstruct a new Coinjoin
10:11 < michaelfolkson> Something has surely gone wrong if there wasn't a large enough fee set in a Coinjoin transaction
10:12 < michaelfolkson> I guess the coordinator of the Coinjoin could take the hit
10:12 < glozow> let's say you constructed a CoinJoin with a medium fee, and you want it to be mined sooner
10:12 < glozow> it hasn't left the mempool yet, so if you tried to construct a new CoinJoin it would be conflicting
10:13 < michaelfolkson> Yeah maybe that happens. I'd have thought Coinjoins would want to confirm immediately given the number of participants and how hard it is to organize
10:13 < glozow> you can imagine participants in multi-party transactions who have different time preference for the transaction
10:13 -!- fanquake [sid369002@gateway/web/irccloud.com/x-emqikykffnffnaen] has quit [Read error: Connection reset by peer]     
10:14 -!- illest101 [uid109953@gateway/web/irccloud.com/x-kgmzcwmtuklpbvqp] has quit [Read error: Connection reset by peer]     
10:14 < michaelfolkson> Yeah maybe... ok!
10:14 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-upwrqprakwaswakd] has quit [Ping timeout: 260 seconds]     
10:14 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-ipmzwnpmntbtlecw] has quit [Ping timeout: 260 seconds]     
10:14 < robot-dreams> One more follow-up from earlier, want to make sure I understand the caching / uncaching correctly.
10:14 < michaelfolkson> ariard: " not an issue, justice transactions are fully malleable" You referring to anchor outputs here?
10:14 < glozow> robot-dreams: hit me!
10:15 < robot-dreams> Here's my current understanding. If we're adding a transaction to the mempool, we bring the inputs into cache, validate, then remove them (because they're spent). If we're TESTING though, we bring the inputs into cache, validate, then manually uncache them?
10:15 < ariard> michaelfolkson: no, justice transactions have always been fully malleable by the cheated victim
10:16 < ariard> though package relay would be useful for delegating such transactions for watchtowers
10:16 < ariard> *to     
10:16 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-oklbdmkqnwrafrjp] has quit [Ping timeout: 272 seconds]     
10:17 -!- illest101 [uid109953@gateway/web/irccloud.com/x-epwnszbhkwcxenmu] has joined #bitcoin-core-pr-reviews     
10:17 -!- amiti [sid373138@gateway/web/irccloud.com/x-auoacfajurchojqe] has quit [Ping timeout: 256 seconds]     
10:17 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-dxlikkepfxrtmvdj] has quit [Read error: Connection reset by peer]     
10:17 < robot-dreams> ariard: Earlier I wasn't referring to fee bumping a justice transaction with CPFP, I was referring to double checking that the chain of 2 transactions would be accepted together even though the commitment transaction hadn't been broadcast yet. Would that use case still make sense in the face of malleable justice transactions?
10:17 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-lbrrqybqucujoaap] has quit [Ping timeout: 272 seconds]     
10:18 -!- fanquake [sid369002@gateway/web/irccloud.com/x-tpngwnepfkvmuutv] has joined #bitcoin-core-pr-reviews     
10:18 < glozow> robot-dreams: if we added it successfully to the mempool, we keep them in cache because we expect to see them again. but if it was invalid, we uncache them.
10:18 -!- amiti [sid373138@gateway/web/irccloud.com/x-qpekpmuzogiobsup] has joined #bitcoin-core-pr-reviews     
10:18 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-qnmugfakmcwqbyqd] has joined #bitcoin-core-pr-reviews     
10:18 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-pzyzmwzujtdwpxws] has joined #bitcoin-core-pr-reviews     
10:18 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-mgbqqtnjwbpvgfih] has joined #bitcoin-core-pr-reviews     
10:19 < michaelfolkson> What exactly is malleable in the justice transaction? It is spending outputs of the expired commitment transaction (pre-ANYPREVOUT)
10:19 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-dmtydqwmmspayklg] has joined #bitcoin-core-pr-reviews     
10:19 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-ckyhturgyjaerhhu] has joined #bitcoin-core-pr-reviews     
10:20 < robot-dreams> glozow: I think I have some confusion over what is "it" and "them" :-P if we add transaction T with inputs vin and outputs vout to the mempool, here's my understanding of what happens:
10:20 < ariard> robot-dreams: I think I understand your question better, you mean being sure you can punish correctly a revoked commitment. Yes it makes sense to use testmempoolaccept when you manually assert correctness of your transaction generation code
10:20 -!- erijon [~erijon@2a0b:f4c2:2::1] has quit [Quit: Leaving]     
10:21 < robot-dreams> ariard: Thanks!
10:21 < robot-dreams> glozow: 1. bring everything in vin into the cache, 2. validate, 3. remove everything from vin from the cache / add everything from vout to the cache, is that right?
10:21 < ariard> but not for production as you don't have to txstandardardness-verify a counterparty conribution, all justice transaction fields are controlled by the punisher
10:21 < glozow> oops 😂 yeah so we care about all the coins that are spent by a tx, and we don't mark them as spent if we're just adding to mempool. but we do want to keep them in the cache for later.
10:22 < ariard> michaelfolkson: in this multi-party context, malleable == single-signed in opposition to counter-signed-and-some-field-selected-by-other
10:22 -!- mep1911 [5ed843cf@dslb-094-216-067-207.094.216.pools.vodafone-ip.de] has quit [Ping timeout: 248 seconds]     
10:22 < robot-dreams> Cool, so in the case of a TEST accept, once we've validated, we want to remove from the cache every vin that wasn't previously in it?
10:22 < glozow> as for the coins created in the tx's vouts, those don't exist yet
10:22 < glozow> it's not a test vs non test accept, it's a valid vs invalid thing
10:23 < glozow> but yes otherwise that is correct
10:24 < michaelfolkson> ariard: Hmmm ok. Different definitions of malleability in single party and multi party contexts apparently :)
10:25 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-ckyhturgyjaerhhu] has quit [Ping timeout: 260 seconds]     
10:25 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-qnmugfakmcwqbyqd] has quit [Ping timeout: 264 seconds]     
10:25 < michaelfolkson> Ok then finally your comment here ariard: https://github.com/bitcoin/bitcoin/pull/20833#pullrequestreview-570114670
10:25 < robot-dreams> In `ProcessNewPackage` it looks like you unconditionally uncache, but in `AcceptToMemoryPoolWithTime` it looks like you only uncache in the `!result.m_accepted` case
10:25 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-pzyzmwzujtdwpxws] has quit [Read error: Connection reset by peer]     
10:25 -!- fanquake [sid369002@gateway/web/irccloud.com/x-tpngwnepfkvmuutv] has quit [Read error: Connection reset by peer]     
10:25 -!- amiti [sid373138@gateway/web/irccloud.com/x-qpekpmuzogiobsup] has quit [Write error: Connection reset by peer]     
10:26 < robot-dreams> Am I missing something here or are you going for different semantics in the single vs. package cases?
10:26 < glozow> OH right, so they're different between single and package yeah
10:26 < glozow> for single, it's valid/invalid
10:26 < glozow> for package, it's basically always
10:26 < glozow> sorry my bad
10:26 < michaelfolkson> ariard: You saying here that Lightning won't use package relay? Or you saying Lightning won't use testmempoolaccept?
10:27 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-zvlnydaarmpqfptf] has joined #bitcoin-core-pr-reviews     
10:27 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-dmtydqwmmspayklg] has quit [Ping timeout: 272 seconds]     
10:27 < robot-dreams> Cool, that makes sense! And what was the motivation for not making the valid/invalid distinction for package?
10:27 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-mgbqqtnjwbpvgfih] has quit [Ping timeout: 264 seconds]     
10:27 < glozow> uh, i was scared of adding a bug
10:28 -!- amiti [sid373138@gateway/web/irccloud.com/x-xxmrneenrqgbcodn] has joined #bitcoin-core-pr-reviews     
10:28 < glozow> 😅 I think i would do it by valid/invalid in for-realsies package
10:28 < michaelfolkson> "In most L2s, chain of transactions validity is more liberal than mempool one. Integrating this new testmempoolaccept might break it..."
10:28 < glozow> also, i need to come up with a better name than for-realsies
10:28 < michaelfolkson> That's interesting
10:28 < robot-dreams> You mean "move fast and break things" is not the motto of bitcoin core? :surprised-pikachu: anyway thanks, that all makes a lot of sense
10:28 < ariard> michaelfolkson: what LN needs is a configurable txstandardness verifier, not exactly what testmempoolaccept is for a first-throw
10:29 < ariard> but it such configurations options can be added later
10:29 < glozow> yeah i don't think you can test LN chains with this
10:29 < glozow> I don't think I claimed that
10:29 < ariard> glozow: public package, p2p-pakcages ?
10:29 < robot-dreams> I like for-realsies, but are you going for something like "atomic" package (all or nothing)?
10:29 < michaelfolkson> Ok I think I'm with you. I think I've caught up
10:30 < robot-dreams> or "batch" package?
10:30 < robot-dreams> or you troll everyone by calling it a "transactional" package cause in DB land transaction = all or nothing
10:30 < michaelfolkson> No you haven't claimed that glozow. In my mind I had claimed that :)
10:30 < glozow> HAHAHA
10:30 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
10:30 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
10:30 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
10:30 < michaelfolkson> Incorrectly it turns out
10:31 < glozow> michaelfolkson: well hopefully we get there, heh
10:31 < michaelfolkson> Ok thanks for hanging around after glozow ariard
10:31 < ariard> glozow Ahah no I don't think you claimed that, it's just "second-layer application chains" cover a bunch of different beasts in practice :)
10:31 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-xrounbsfurrkqzcl] has joined #bitcoin-core-pr-reviews     
10:31 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-xzrxgjpxpxjeibli] has joined #bitcoin-core-pr-reviews     
10:32 < glozow> whew whew
10:32 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-hnlhbsjkoshmmoiw] has joined #bitcoin-core-pr-reviews     
10:32 < michaelfolkson> Yeah I'm of the strong view the focus should be on Lightning until some of the other second layers know what they need
10:32 < michaelfolkson> Fix Lightning problems first
10:33 < michaelfolkson> But Coinjoin isn't second layer if that turns out to be a use case
10:33 -!- lightlike [~lightlike@p200300c7ef1e0e00187df4bbc841b4a3.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
10:33 -!- fanquake [sid369002@gateway/web/irccloud.com/x-yrhdislyvqwfxdcf] has joined #bitcoin-core-pr-reviews     
10:33 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-xhgpbnobqbrbqpvp] has joined #bitcoin-core-pr-reviews     
10:33 < glozow> oh, the CoinJoin thing isn't that relevant for testmempoolaccept i think
10:34 < michaelfolkson> So this is like a stepping stone advancing testmempoolaccept in the hope that a few more stepping stones along we'll start solving real problems
10:34 < michaelfolkson> (with package relay)
10:35 < michaelfolkson> Maybe testmempoolaccept doesn't have any use cases but a few more stepping stones along a use case or multiple use cases start getting solved
10:36 < michaelfolkson> If true sounds like a good approach
10:38 -!- prayank [~andr0irc@2402:8100:206a:1e47:7f8d:cc7a:9411:8426] has quit [Ping timeout: 260 seconds]     
10:38 < glozow> yeah, imo that's a fine way to think about it
10:38 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has joined #bitcoin-core-pr-reviews     
10:43 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
10:47 -!- Caralie [04355c72@4.53.92.114] has quit [Quit: Connection closed]     
10:49 -!- robot-dreams [~textual@172.92.4.53] has quit [Quit: Textual IRC Client: www.textualapp.com]     
10:50 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has quit [Ping timeout: 264 seconds]     
10:54 -!- fanquake [sid369002@gateway/web/irccloud.com/x-yrhdislyvqwfxdcf] has quit [Read error: Connection reset by peer]     
10:54 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-xhgpbnobqbrbqpvp] has quit [Ping timeout: 265 seconds]     
10:54 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-xzrxgjpxpxjeibli] has quit [Read error: Connection reset by peer]     
10:54 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-hnlhbsjkoshmmoiw] has quit [Ping timeout: 272 seconds]     
10:54 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-xrounbsfurrkqzcl] has quit [Read error: Connection reset by peer]     
10:59 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds]     
11:00 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
11:04 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie]     
11:06 -!- Larsson [~l@2804:7f7:a6aa:5213:eb23:68a0:acb6:4e8e] has quit [Quit: Konversation terminated!]     
11:06 -!- aqquadro [02ee6c29@unaffiliated/aqquadro] has quit [Quit: Ping timeout (120 seconds)]     
11:11 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews     
11:14 -!- fanquake [sid369002@gateway/web/irccloud.com/x-vaiqnaaqwdstxqrg] has joined #bitcoin-core-pr-reviews     
11:15 -!- robot-dreams_ [sid463268@gateway/web/irccloud.com/x-twcdzdwbafzsdylv] has joined #bitcoin-core-pr-reviews     
11:15 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-lmppngrkivrboftf] has joined #bitcoin-core-pr-reviews     
11:15 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-dcgzhmutntdsthom] has joined #bitcoin-core-pr-reviews     
11:20 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-dataxrvofypsktyq] has joined #bitcoin-core-pr-reviews     
11:20 -!- jackk_ [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
11:29 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has joined #bitcoin-core-pr-reviews     
11:30 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has quit [Read error: Connection reset by peer]     
11:40 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-dataxrvofypsktyq] has quit [Ping timeout: 260 seconds]     
11:42 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-xrzcgkxzlzktxvvp] has joined #bitcoin-core-pr-reviews     
11:52 -!- jackk_ [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
11:59 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:00 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: ccdle12]     
12:00 -!- bountiful [~that@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]     
12:11 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
12:17 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 272 seconds]     
12:23 -!- jackk_ [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
12:44 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-xrzcgkxzlzktxvvp] has quit [Read error: Connection reset by peer]     
12:44 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-lmppngrkivrboftf] has quit [Read error: Connection reset by peer]     
12:46 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-ovsgclsmhkkkcxht] has joined #bitcoin-core-pr-reviews     
12:47 -!- wallet42___ [sid154231@gateway/web/irccloud.com/x-cyqjwvcpwnemivxk] has joined #bitcoin-core-pr-reviews     
12:57 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie]     
13:11 -!- effexzi [uid474242@gateway/web/irccloud.com/x-xdkgijtcdxhnphds] has quit [Quit: Connection closed for inactivity]     
13:41 -!- rjected [~weechat-h@natp-128-119-202-24.wireless.umass.edu] has quit [Ping timeout: 264 seconds]     
13:42 -!- rjected [~weechat-h@natp-128-119-202-24.wireless.umass.edu] has joined #bitcoin-core-pr-reviews     
13:50 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-tubwgvbdnkssyqah] has quit [Ping timeout: 260 seconds]     
13:51 -!- sunon [duncandean@gateway/shell/matrix.org/x-mcqlsihczpdxmacu] has quit [Ping timeout: 265 seconds]     
14:17 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has joined #bitcoin-core-pr-reviews     
14:20 -!- prayank [~andr0irc@2402:8100:206a:1e47:69be:e777:6031:d6d0] has quit [Read error: Connection reset by peer]     
14:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
14:26 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
14:26 -!- vasild_ is now known as vasild     
15:24 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:217b:6c7a:eac3:3be9] has joined #bitcoin-core-pr-reviews     
15:33 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-jjtbjalneajouwbt] has joined #bitcoin-core-pr-reviews     
15:43 -!- jessepos_ [~jp@2601:645:200:162f:3c9a:cd45:284b:ebea] has joined #bitcoin-core-pr-reviews     
15:44 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Remote host closed the connection]     
15:44 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
15:46 -!- sunon [duncandean@gateway/shell/matrix.org/x-tslthxlcxtpfbkcv] has joined #bitcoin-core-pr-reviews     
15:46 -!- jesseposner [~jp@2601:645:200:162f:edcb:662b:a209:afa] has quit [Ping timeout: 264 seconds]     
16:25 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 260 seconds]     
16:28 -!- prayank [~andr0irc@2402:8100:206a:1e47:f74d:e28e:ac6d:892f] has joined #bitcoin-core-pr-reviews     
16:31 -!- prayank [~andr0irc@2402:8100:206a:1e47:f74d:e28e:ac6d:892f] has quit [Client Quit]     
16:38 -!- mattdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined #bitcoin-core-pr-reviews     
16:38 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Ping timeout: 240 seconds]     
16:48 -!- norisgOG [~norisgOG@91.193.7.40] has quit [Read error: No route to host]     
16:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
16:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
17:16 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]     
17:16 -!- notmandatory [~notmandat@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews     
17:24 -!- jackk_ [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
17:30 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 246 seconds]     
18:21 -!- notmandatory_ [~notmandat@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews     
18:21 -!- notmandatory [~notmandat@shindig.notmandatory.org] has quit [Ping timeout: 256 seconds]     
18:21 -!- mattdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Ping timeout: 256 seconds]     
18:21 -!- fanquake [sid369002@gateway/web/irccloud.com/x-vaiqnaaqwdstxqrg] has quit [Ping timeout: 256 seconds]     
18:21 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-jdprefwyhgpusmtg] has quit [Ping timeout: 256 seconds]     
18:21 -!- fanquake_ [sid369002@gateway/web/irccloud.com/x-hooxevzeyzepxlxz] has joined #bitcoin-core-pr-reviews     
18:21 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined #bitcoin-core-pr-reviews     
18:22 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-sulwoxgyopxoqgnl] has joined #bitcoin-core-pr-reviews     
18:28 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
18:51 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer]     
19:20 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]     
19:21 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
20:03 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
21:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
21:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
21:37 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
21:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]     
22:23 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
22:48 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-bgtpgwlcfpuidlxj] has joined #bitcoin-core-pr-reviews     
22:49 -!- ajonas [sid385278@gateway/web/irccloud.com/x-afwpuvrnyrfhxzoe] has quit [Ping timeout: 256 seconds]     
23:57 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
23:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]