--- Log opened Wed Jun 01 00:00:40 2022
00:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bdd7:5f7c:80d:1470] has quit [Ping timeout: 252 seconds]
00:55 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
01:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bdd7:5f7c:80d:1470] has joined #bitcoin-core-pr-reviews
01:52 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
01:54 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds]
01:56 -!- hashfunc173 [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has joined #bitcoin-core-pr-reviews
02:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bdd7:5f7c:80d:1470] has quit [Ping timeout: 260 seconds]
02:18 -!- hashfunc173 [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has quit [Remote host closed the connection]
02:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bdd7:5f7c:80d:1470] has joined #bitcoin-core-pr-reviews
02:57 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
03:09 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
03:46 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
03:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bdd7:5f7c:80d:1470] has quit [Ping timeout: 258 seconds]
04:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has joined #bitcoin-core-pr-reviews
04:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has quit [Ping timeout: 272 seconds]
04:31 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
04:37 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 260 seconds]
04:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has joined #bitcoin-core-pr-reviews
04:46 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
05:10 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 258 seconds]
05:35 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
05:53 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Read error: Connection reset by peer]
05:53 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
06:00 -!- __gotcha1 [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
06:00 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Read error: Connection reset by peer]
06:00 -!- __gotcha1 is now known as __gotcha
06:09 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 246 seconds]
06:11 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
06:14 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds]
06:29 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
06:44 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
07:05 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 240 seconds]
07:22 -!- ubba [uid552050@user/ubba] has joined #bitcoin-core-pr-reviews
07:29 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
07:36 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 258 seconds]
07:37 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
07:48 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2607:fb90:22d4:cb66:59f3:8fc5:3b7d:4d63] has joined #bitcoin-core-pr-reviews
07:53 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2607:fb90:22d4:cb66:59f3:8fc5:3b7d:4d63] has quit [Remote host closed the connection]
07:57 -!- __gotcha1 [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
07:57 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Read error: Connection reset by peer]
07:57 -!- __gotcha1 is now known as __gotcha
08:05 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Read error: Connection reset by peer]
08:05 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
08:12 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 246 seconds]
08:20 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
08:21 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
08:22 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
08:34 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 246 seconds]
08:34 -!- __gotcha [~Thunderbi@213.181.59.198] has joined #bitcoin-core-pr-reviews
08:38 -!- __gotcha [~Thunderbi@213.181.59.198] has quit [Ping timeout: 246 seconds]
09:21 -!- adiabat_ [~adiabat@63.209.32.102] has quit [Remote host closed the connection]
09:24 -!- adiabat_ [~adiabat@63.209.32.102] has joined #bitcoin-core-pr-reviews
09:53 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:53 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
09:55 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:56 -!- rage-proof [~rage-proo@ip5f5bf3ad.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews
09:56 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:58 -!- yashraj [~yashraj@cpe08a7c09f284f-cm08a7c09f284d.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
09:59 -!- furszy [~furszy@user/furszy] has joined #bitcoin-core-pr-reviews
09:59 -!- d [~d@208.127.242.71] has joined #bitcoin-core-pr-reviews
09:59 -!- d [~d@208.127.242.71] has quit [Client Quit]
10:00 < glozow> hi!
10:00 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
10:00 < glozow> Hopefully y'all can see my messages
10:00 < glozow> #startmeeting
10:00 < michaelfolkson> hi
10:00 < BlueMoon> Hello!!
10:01 -!- danielabrozzoni [~danielabr@2001:bc8:1828:379::1] has joined #bitcoin-core-pr-reviews
10:01 < danielabrozzoni> hi
10:01 < glozow> Welcome to PR Review Club! This meeting is intended for beginners to learn about the Bitcoin Core codebase and how to review PRs.
10:01 < glozow> Today we're looking at PR #25228, "Add BIP-125 rule 5 testcase with default mempool"
10:01 < glozow> Notes are here: https://bitcoincore.reviews/25228
10:02 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:02 < effexzi> Hi every1 
10:02 < paul_c> Hey
10:02 < glozow> Please feel free to ask questions whenever you want, and don't worry about interrupting - this meeting is for learning!
10:03 -!- soy_yo [~soy_yo@h-155-4-132-94.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews
10:03 < BlueMoon> Thanks!!
10:03 -!- soy_yo [~soy_yo@h-155-4-132-94.NA.cust.bahnhof.se] has quit [Client Quit]
10:03 < glozow> Did anyone get a chance to review the PR and/or look at the notes? How about a y/n from people who are here
10:03 < paul_c> y
10:03 < danielabrozzoni> y 
10:03 < michaelfolkson> y
10:03 < larryruane> hi
10:04 < glozow> Great to see people reviewed it! Could you tell us a little bit about your review process?
10:04 < BlueMoon> I couldn't check it, sorry.
10:04 < larryruane> I'm trying to run the modified test (feature_rbf.py) in the debugger ... but having unexpected trouble for some reason
10:05 < paul_c> read through it, search google/youtube for terms I'm not familiar with
10:05 < danielabrozzoni> I read the code, I tried to understand the difference between the new `test_too_many_replacements_with_default_mempool_params` and the old `test_too_many_replacements` to understand why the old one wasn't testing the rule 5 use case
10:05 -!- Kalixto [~Kalixto@200.109.50.144] has joined #bitcoin-core-pr-reviews
10:05 -!- dulcedu [~dulcedu@h-155-4-132-94.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews
10:06 < glozow> Great! could somebody summarize what this PR is doing?
10:06 -!- dulcedu [~dulcedu@h-155-4-132-94.NA.cust.bahnhof.se] has quit [Client Quit]
10:07 -!- OliverOff [~OliverOff@187.85.172.39] has joined #bitcoin-core-pr-reviews
10:07 < larryruane> adding test coverage, testing the code-under-test in a more realistic way (how it runs in real life)
10:07 -!- dulce [~dulce@h-155-4-132-94.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews
10:07 -!- randomsats [~randomsat@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
10:07 < danielabrozzoni> Adding a test with the default mempool parameters to check that the nodes are enforcing RBF rule 5
10:07 -!- Hardcode [~Hardcode@190.62.9.208] has joined #bitcoin-core-pr-reviews
10:08 -!- Hardcode [~Hardcode@190.62.9.208] has quit [Client Quit]
10:08 < glozow> larryruane: danielabrozzoni: Great summaries, thank you! Let's move onto the questions. What does it mean for a transaction to “conflict with” transactions in the mempool? What is the difference between a “directly” and “indirectly conflicting” transaction?
10:08 -!- dulce [~dulce@h-155-4-132-94.NA.cust.bahnhof.se] has quit [Client Quit]
10:09 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:09 -!- dulce [~dulce@h-155-4-132-94.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews
10:09 < michaelfolkson> Conflict = they both can't get into the blockchain
10:10 < glozow> michaelfolkson: but *why* can't they both get into the blockchain?
10:10 < OliverOff> A conflicting transaction is one that spends the same prevout as other transactions already in the mempool
10:10 -!- yashraj [~yashraj@cpe08a7c09f284f-cm08a7c09f284d.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]
10:12 < larryruane> i think indirect would be if the existing transaction has decendants ... those would have to be dropped from the mempool too, if this new tx is accepted
10:12 < danielabrozzoni> TxA is directly conflicting with TxB if A double spends B's inputs. TxA is indirectly conflicting with TxB if A is directly conflicting with one of B's ancestors (so if B's ancestor is replaced with A, B has to be evicted as well).
10:12 < glozow> OliverOff: right, two transactions "conflict" if they spend the same UTXO. You can tell because they each have an input which refers to the same prevout: https://github.com/bitcoin/bitcoin/blob/b752dade048ced8227a9d205a708f50d58f99312/src/txmempool.cpp#L961
10:13 < larryruane> danielabrozzoni: yes, I think you said it more clearly than I did (I think we said the same thing)
10:13 -!- Hardcode [~Hardcode@190.62.9.208] has joined #bitcoin-core-pr-reviews
10:13 < glozow> danielabrozzoni: larryruane: yes! if you evict a transaction, you must also evict its descendants. so we also care if there are "indirect" conflicts, i.e. the transaction conflicts with the ancestor of a mempool tx
10:13 -!- Hardcode [~Hardcode@190.62.9.208] has quit [Client Quit]
10:13 -!- Kalixto [~Kalixto@200.109.50.144] has quit [Quit: Connection closed]
10:14 -!- Hardcode [~Hardcode@190.62.9.208] has joined #bitcoin-core-pr-reviews
10:14 < danielabrozzoni> larryruane (IRC): yup, same thing 🙂 
10:14 < glozow> Based on the default RBF policy, how many direct and indirect conflicts can a transaction have?
10:14 < glozow> i.e. what is Rule 5? :P
10:15 < OliverOff> 100?
10:15 < glozow> OliverOff: yup!
10:15 < glozow> Why should the node limit the number of transactions that can be replaced at a time? Can you think of any potential attacks if we don't have a limit?
10:15 < larryruane> and just to elaborate slightly, the reason we MUST drop the decendants is because their input references an output by txid (and index), and that txid no longer exists
10:16 -!- Hardcode [~Hardcode@190.62.9.208] has quit [Client Quit]
10:16 < larryruane> a useful link https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
10:17 < larryruane> I think you could in effect flush other nodes' mempools almost to empty!
10:18 < glozow> larryruane: yes, how would an attacker do that and how much would it cost them?
10:19 -!- Hardcode [~Hardcode@190.62.9.208] has joined #bitcoin-core-pr-reviews
10:19 < larryruane> they could submit (let's just say) 500 independent transactions all with low fee (but enough to make it into the mempool), and then attacker could submit a single transaction that conflicts with all 500 
10:20 < danielabrozzoni> Why would an attacker do that? Waste cpu time of the nodes? 
10:20 < larryruane> (they wouldn't have to be independent but the dependent ones can form a set of size more than 25, i believe)
10:21 < michaelfolkson> It could crash the node depending on the hardware right?
10:22 < larryruane> danielabrozzoni: maybe? but also just flushing other nodes' mempools is a kind of DoS because the flushed tx won't get included in a block (unless they're resubmitted)
10:22 -!- Hardcode [~Hardcode@190.62.9.208] has quit [Client Quit]
10:22 < glozow> I don't think there would be any crashes, just inconvenient for everybody
10:23 < danielabrozzoni> But the txs you're replacing, they're all yours, so I'm not sure why that would be a DoS... does someone have something to read on this?
10:24 < michaelfolkson> Requesting and validating a whole new mempool of transactions sounds resource intensive for a very lightweight node
10:24 < michaelfolkson> But maybe it can deal with it
10:25 < glozow> this might be useful: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017020.html
10:25 < danielabrozzoni> Ah right, that makes sense, it's DoS as everyone has to validate a whole new mempool 
10:25 < danielabrozzoni> glozow (IRC): Thanks!
10:27 < glozow> I'm don't have perfect knowledge on RBF history, but it seems to be the case that Rule 5 predates the ancestry limits
10:27 < glozow> let's continue with the questions
10:27 < glozow> How is it possible for a transaction to conflict with 100 transactions if the descendant limit is 25? Can you come up with an example that isn’t the one tested in this PR?
10:27 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
10:29 -!- Azor [~Azor@200.109.50.144] has joined #bitcoin-core-pr-reviews
10:30 < larryruane> let's say there are 100 independent tx in the mempool ... the new tx may try to spend an input from all 100 of those tx
10:30 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds]
10:30 < glozow> larryruane: yep exactly, it's as simple as that!
10:30 < larryruane> (is there a limit on the number of inputs a tx can have? or a standardness limit at least?)
10:31 < OliverOff> Alternatively, by having a tx that conflicts with 4+ txs, each tx having 25 descendants of its own (as mentioned before)
10:31 < sipa> larryruane: No limit beyond the normal standard 400000 weight limit per tx.
10:31 < larryruane> OliverOff: sipa: +1
10:32 < glozow> larryruane: good question. with just 1 output, I think you can get at least 600something inputs before you reach the 400KWu limit
10:33 < sipa> larryruane: Which does imply a strict (standardness) limit of ~2400 inputs, as every input is at least 41 vbytes.
10:33 < sipa> Of course, if we're talking about standardness, inputs can also only spend standard outputs, and those have a higher minimum per-input weight.
10:33 < glozow> woops i think I used a p2sh input size when i calculated
10:34 < sipa> p2tr key path spending inputs are probably the cheapest standard inputs you can construct now
10:35 < sipa> With those I think you could get to 1738 inputs in a tx.
10:35 < sipa> Paging Murch.
10:35 < glozow> is it 58vb for a taproot pubkey spend?
10:36 < sipa> 36 vbytes prevout, 4 vbytes nsquence, 1 vbyte scriptsig length, 1 WU for number of witness stack items, 1 WU for the length of the witness stack item, 64 WU for the signature
10:36 < larryruane> glozow: i think that's right https://twitter.com/murchandamus/status/1262062602298916865?s=20&t=eFK23X7Xy1y5_32Rxx2aQw
10:37 < sipa> so 36 + 4 + 1 + (1 + 1 + 64)/4 = 57.5 vbytes?
10:37 < michaelfolkson> https://bitcoinops.org/en/tools/calc-size/
10:37 < glozow> say we subtract 100vB for the rest of the transaction, 99900/58 gives us ~1700 inputs
10:38 < glozow> Fun! I have a bonus question that's pretty relevant here. Rule 5 only restricts the number of transactions that can be replaced, not the size. However, an effective maximum exists; what is the effective maximum virtual size of transactions that can be replaced in a default mempool?
10:40 < larryruane> 1700 * 101k or something like that?
10:41 < danielabrozzoni> At a guess, the biggest case is replacing 100 independent txs? So, 100*MAX_STANDARD_TX_WEIGHT? 
10:41 < glozow> ah no, it won't have anything to do with this 1700 number.
10:41 < glozow> danielabrozzoni: yes exactly :)
10:42 < glozow> so that's 40,000,000Wu
10:43 < glozow> next question. What’s wrong with configuring -acceptnonstdtxn=1, -limitancestorcount, -limitancestorsize, -limitdescendantcount, and -limitdescendantsize, to test mempool policy?
10:43 < larryruane> so roughly compare that with the default mempool size, 300mb, that's over 10%?
10:44 < larryruane> 13% actually... so a single tx could replace 13% of the mempool?
10:45 < glozow> larryruane: not really, because we're comparing virtual bytes of the transaction with memory allocated for the mempool data structure.
10:45 -!- OliverOff [~OliverOff@187.85.172.39] has quit [Quit: Connection closed]
10:45 < larryruane> oh i see, so the 300mb is memory (including metadata overhead like for the map and stuff)
10:45 < glozow> the mempool is about 75% metadata, so 300MB really stores about 75MvB worth of transactions
10:45 -!- Azor [~Azor@200.109.50.144] has quit [Quit: Connection closed]
10:46 < michaelfolkson> glozow: Not testing the default mempool policy? 
10:46 < glozow> larryruane: but yes, your math is correct. 10MvB/75MvB is about 13%
10:47 < Murch> sup
10:47 < michaelfolkson> Wot. Mempool is 75 percent metadata? Like what metadata?
10:47 < larryruane> michaelfolkson: +1 but also it's probably good to test that those args are not ignored
10:47 < sipa> michaelfolkson: Not metadata - overhead.
10:47 < glozow> here's the declaration for mempool entries: https://github.com/bitcoin/bitcoin/blob/b752dade048ced8227a9d205a708f50d58f99312/src/txmempool.h#L85
10:48 < sipa> There is some metadata there too, but most if it is just memory allocation overhead, pointers, indexing, ...
10:48 < larryruane> michaelfolkson: if you have a std::map of bool, and it contains 1000 entries, the mem usage will be much more than 1000 bytes
10:48 < sipa> And way more than 125 bytes, which ought to be enough to store 1000 bools.
10:48 < _aj_> glozow: "vB" deweights witness data, if you've got a 1000vB tx, that might be 2000B of serialised data, even without metadata
10:49 < michaelfolkson> sipa: Still sounds a lot. Overhead is only 1/6 of input size for P2TR
10:49 < glozow> yes there are a lot of approximations here. my point was we can't really just do simple arithmetic to see how many transactions fit in a 300MB mempool
10:50 < sipa> michaelfolkson: It helps to realize that transactions are abstract data structures with a lot of complex structure in them (inputs, outputs, witnesses, stack items, ...). The traditional "network protocol raw serialized" view of a transaction is just one way of representing it, and isn't actually used internally except for storing on disk and transmitting over the network.
10:51 < michaelfolkson> Ok, interesting thanks
10:51 < glozow> there are other data structures in the mempool as well, like mapNextTx and mapDeltas: https://github.com/bitcoin/bitcoin/blob/b752dade048ced8227a9d205a708f50d58f99312/src/txmempool.h#L560-L561
10:52 < glozow> ok let's move on
10:52 < BlueMoon> Thank you all, just from reading you I am learning a lot.
10:52 < glozow> Why is it necessary to pass a different sequence to create_self_transfer_multi?
10:52 < sipa> std::move(topic)
10:52 -!- furszy [~furszy@user/furszy] has quit [Remote host closed the connection]
10:52 < glozow> BlueMoon: great to hear!
10:52 < Murch> The 300 MB are usually reached at around 80-95 blocks depth
10:52 < Murch> Says past-Murch: https://bitcoin.stackexchange.com/a/96070/5406
10:52 < BlueMoon> :)
10:53 < larryruane> yes that indirectmap (for the mapNextTx) is one of the most mindbending things i've encountered! very cool though
10:54 < _aj_> Murch: that's the ballpark that i was thinking/remembering
10:54 < danielabrozzoni> The transactions that need to be replaced, or that replace, need to signal for RBF, and the way this is done is by setting the sequence to less than 0xffffffff - 1
10:54 < glozow> danielabrozzoni: yes exactly
10:55 < glozow> I guess another approach would have been to make miniwallet transactions signal rbf by default, but maybe that'd break a test somewhere
10:55 < glozow> What does annotating `get_utxo` with the `-> dict` return type annotation do?
10:55 < larryruane> danielabrozzoni: and it's not "the" sequence number; each input has its own, so *any* sequence number
10:56 < danielabrozzoni> Do I recall correctly that even a transaction that replaces others in mempool needs to signal for RBF?
10:57 < danielabrozzoni> larryruane (IRC): yep right! 🙂 
10:57 < larryruane> danielabrozzoni: i don't think so
10:57 < michaelfolkson> glozow: More metadata describing the return value
10:57 < glozow> afaik no the replacement doesn't need to signal anything. just the original
10:58 < sipa> yeah, the signal represents replaceability, not replacingness (which is implied by the fact it's spending an unconfirmed output).
10:58 < Murch> No, only the replaced needs to signal
10:58 < danielabrozzoni> Ah ok, I'm getting confused with something else then, thanks everyone 🙂 
11:00 < glozow> michaelfolkson: ye. see #18410 if anyone's interested
11:00 < glozow> thanks for coming y'all, that's all the time we have  today
11:00 < glozow> #endmeeting
11:00 < paul_c> Thanks, picked up a lot
11:01 < larryruane> thanks glozow this was very helpful
11:01 < danielabrozzoni> Thanks everyone, I learned so much 🙂 
11:01 < effexzi> Thanks every1 
11:02 < michaelfolkson> Thanks glozow
11:02 < svav> Thanks all
11:02 < dulce> Gracias :)
11:02 -!- dulce [~dulce@h-155-4-132-94.NA.cust.bahnhof.se] has quit [Quit: Connection closed]
11:03 < BlueMoon> Thanks!! It was incredible!!
11:03 < BlueMoon> :)
11:03 -!- randomsats [~randomsat@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has quit [Quit: Connection closed]
11:04 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:06 -!- evbo [~bosats@2601:47:4285:c7f0:a7df:3981:7a04:d870] has joined #bitcoin-core-pr-reviews
11:21 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
11:32 -!- rage-proof [~rage-proo@ip5f5bf3ad.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed]
11:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has quit [Remote host closed the connection]
12:02 -!- yashraj [~yashraj@2607:fea8:8600:8100:40a5:7370:bc5d:f09f] has joined #bitcoin-core-pr-reviews
12:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has joined #bitcoin-core-pr-reviews
12:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has quit [Ping timeout: 250 seconds]
12:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has joined #bitcoin-core-pr-reviews
12:16 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:16 -!- yashraj [~yashraj@2607:fea8:8600:8100:40a5:7370:bc5d:f09f] has quit []
12:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has quit [Ping timeout: 260 seconds]
12:19 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
12:20 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
12:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has joined #bitcoin-core-pr-reviews
12:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2913:d1c7:489a:a148] has quit [Client Quit]
12:23 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
12:25 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
12:42 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:45 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds]
12:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Remote host closed the connection]
12:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
12:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 250 seconds]
13:02 -!- ubba [uid552050@user/ubba] has quit [Quit: Connection closed for inactivity]
13:11 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:14 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:15 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
13:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
13:30 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:33 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:33 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
13:35 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
13:40 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:43 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
13:43 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has quit [Quit: Client closed]
14:02 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
14:06 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 276 seconds]
14:11 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
14:28 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 255 seconds]
14:35 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
14:39 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
14:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
14:45 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
14:48 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 246 seconds]
15:14 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 244 seconds]
17:48 -!- hashfunc41a [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has joined #bitcoin-core-pr-reviews
17:54 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
17:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 260 seconds]
17:58 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
17:58 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
18:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
18:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
18:11 -!- greypw25460 [~greypw254@grey.pw] has quit [Quit: I'll be back!]
18:11 -!- greypw25460 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
18:11 -!- greypw25460 [~greypw254@grey.pw] has quit [Remote host closed the connection]
18:12 -!- greypw25460 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
18:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
18:44 -!- hashfunc41a [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has quit [Remote host closed the connection]
19:03 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
19:05 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
19:07 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 246 seconds]
19:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 244 seconds]
19:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
19:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 258 seconds]
19:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
19:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
19:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
19:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
19:37 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
19:51 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
20:00 -!- greypw25460 [~greypw254@grey.pw] has quit [Remote host closed the connection]
20:00 -!- greypw25460 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
20:03 -!- greypw25460 [~greypw254@grey.pw] has quit [Remote host closed the connection]
20:03 -!- greypw25460 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
20:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
20:23 -!- hashfunc1df8 [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has joined #bitcoin-core-pr-reviews
21:28 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
21:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 248 seconds]
21:34 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
22:01 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
22:14 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
22:36 -!- hashfunc1df8 [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has quit [Remote host closed the connection]
22:39 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds]
22:41 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
22:41 -!- hashfunc1bb [~user@2601:5c0:c280:7090:30da:f74b:fc0a:7f05] has joined #bitcoin-core-pr-reviews
23:18 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
23:22 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
23:25 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 246 seconds]
23:31 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
23:42 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
23:46 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 258 seconds]
23:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has joined #bitcoin-core-pr-reviews
23:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9de3:c88:85ba:eb2b] has quit [Ping timeout: 244 seconds]
23:54 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Jun 02 00:00:41 2022