--- Day changed Wed Apr 29 2020 00:31 -!- jonatack_ [~jon@37.165.16.42] has joined #bitcoin-core-pr-reviews 00:34 -!- jonatack [~jon@37.165.71.66] has quit [Ping timeout: 264 seconds] 00:51 -!- as_pnn [~pierreirc@119.192.247.147] has joined #bitcoin-core-pr-reviews 00:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 01:00 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 01:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 01:01 -!- shesek` [~shesek@5.22.128.43] has quit [Ping timeout: 246 seconds] 01:02 -!- shesek` [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews 01:05 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 01:06 -!- shesek` [~shesek@5.22.128.43] has quit [Ping timeout: 256 seconds] 01:06 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 252 seconds] 01:08 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 01:08 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 01:09 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 01:12 -!- shesek [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews 01:12 -!- shesek [~shesek@5.22.128.43] has quit [Changing host] 01:12 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 01:14 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews 02:51 -!- sonofhan [~sonofhan@104.238.46.201] has quit [Ping timeout: 256 seconds] 03:00 -!- sonofhan [~sonofhan@104.238.46.201] has joined #bitcoin-core-pr-reviews 03:01 -!- brakmic [brakmic@gateway/vpn/nordvpn/brakmic] has joined #bitcoin-core-pr-reviews 03:05 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 03:07 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 03:10 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 03:19 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 03:24 -!- ccdle12_ [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 03:25 -!- ccdle12_ [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 03:41 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 03:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:44 -!- vasild_ is now known as vasild 03:46 -!- as_pnn [~pierreirc@119.192.247.147] has quit [Quit: killed] 03:47 -!- as_pnn [~pierreirc@119.192.247.147] has joined #bitcoin-core-pr-reviews 04:38 -!- sonofhan [~sonofhan@104.238.46.201] has quit [Ping timeout: 240 seconds] 04:45 -!- as_pnn [~pierreirc@119.192.247.147] has quit [Quit: killed] 04:45 -!- jonatack_ [~jon@37.165.16.42] has quit [Read error: Connection reset by peer] 04:46 -!- jonatack [~jon@213.152.161.25] has joined #bitcoin-core-pr-reviews 04:47 -!- jonatack [~jon@213.152.161.25] has quit [Read error: Connection reset by peer] 04:53 -!- jonatack [~jon@37.165.16.42] has joined #bitcoin-core-pr-reviews 04:55 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 04:58 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 04:58 -!- jonatack [~jon@37.165.16.42] has quit [Ping timeout: 256 seconds] 04:59 -!- jonatack [~jon@109.232.227.149] has joined #bitcoin-core-pr-reviews 05:06 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 05:11 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] 05:16 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 05:41 -!- whythat [whythatmat@gateway/shell/matrix.org/x-ucouhznhwoghjuwk] has left #bitcoin-core-pr-reviews ["Kicked by @appservice-irc:matrix.org : issued !quit command"] 05:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Quit: WeeChat 1.9.1] 06:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 06:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 06:35 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 06:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 07:07 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 07:11 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:12 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] 07:16 -!- mrwhythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 07:17 -!- mrwhythat is now known as whythat 07:19 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Client Quit] 07:19 -!- whythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 07:46 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:58 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:05 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 08:27 -!- sonofhan [~sonofhan@104.238.46.201] has joined #bitcoin-core-pr-reviews 08:29 -!- sonofhan [~sonofhan@104.238.46.201] has quit [Client Quit] 08:55 < jnewbery> We'll get started in just over an hour 08:56 -!- Prayank [8ba79fc1@139.167.159.193] has joined #bitcoin-core-pr-reviews 08:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 09:01 -!- Prayank [8ba79fc1@139.167.159.193] has quit [Ping timeout: 240 seconds] 09:08 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:12 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:20 -!- Anonymous93 [60f858e5@pool-96-248-88-229.cmdnnj.fios.verizon.net] has joined #bitcoin-core-pr-reviews 09:23 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 09:26 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:37 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:2576:934:d62b:3df0] has joined #bitcoin-core-pr-reviews 09:38 -!- Smeier [cfacdb18@207.172.219.24] has joined #bitcoin-core-pr-reviews 09:53 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 09:58 -!- b10c [~b10c@2001:16b8:2e48:6500:f802:c214:4679:e07f] has joined #bitcoin-core-pr-reviews 09:58 -!- robot-visions [ac5c0435@172.92.4.53] has joined #bitcoin-core-pr-reviews 09:58 -!- spaghetti [18bf0f97@ool-18bf0f97.dyn.optonline.net] has joined #bitcoin-core-pr-reviews 10:00 < amiti> #startmeeting 10:00 < amiti> hi everyone! welcome to another bitcoin core review club 10:00 < Anonymous93> hey there! 10:00 < vasild> \o/ 10:00 < amiti> feel free to say hi and let everyone know you are here :) 10:00 < willcl_ark> hi amiti 10:00 < robot-visions> hi 10:00 < fjahr> hi 10:00 < _andrewtoth_> hi 10:00 < vasild> hi 10:00 < jnewbery> hi! 10:00 < ccdle12> hi 10:01 < b10c> hi! 10:01 < felixweis> Hi 10:01 < amiti> notes are in the usual place: https://bitcoincore.reviews/18038.html 10:01 < jkczyz> hi 10:01 < jonatack> hi 10:01 < elichai2> hi 10:01 < amiti> the PR just got merged this morning, but that doesn't mean we should stop reviewing and thinking critically about it :) 10:02 -!- julessss [60ead5a4@pool-96-234-213-164.bltmmd.fios.verizon.net] has joined #bitcoin-core-pr-reviews 10:02 < amiti> who has gotten a chance to review the PR? (y/n) 10:02 < robot-visions> y 10:02 < jnewbery> y 10:02 -!- gloria43 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:02 < jonatack> y 10:02 < fjahr> y 10:02 < b10c> n 10:02 < jkczyz> n :( 10:02 < Anonymous93> n 10:02 < ccdle12> y 10:02 < vasild> n 10:02 < willcl_ark> n 10:02 -!- detoxify [~detoxify@185.242.5.35] has joined #bitcoin-core-pr-reviews 10:02 < _andrewtoth_> n 10:03 < amiti> cool! 10:03 < jnewbery> reviewing merged PRs is as important as reviewing unmerged PRs (and you get a lot more Bitcoin wizard points for finding a bug in a merged PR) 10:03 < amiti> thanks to those of you that reviewed, and thanks to those of you that haven't but have joined today :) 10:04 < amiti> lets get started by talking about what is the unbroadcast set? 10:04 < amiti> what is the point of it? 10:04 -!- lightlike [~lightlike@p200300C7EF169600F5C62F9B2F452BEB.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 10:05 < _andrewtoth_> the point of it is to track transactions submitted locally that have not yet been broadcast to the public network 10:05 < amiti> yup! 10:05 < amiti> why? 10:06 < Smeier> to reduce the necessity of rebroadcasting all txs? 10:06 < willcl_ark> to improve privacy 10:06 < MarcoFalke> hi 10:06 < robot-visions> you might want to try rebroadcasting the "unbroadcast" ones more eagerly (compared to transactions that HAVE been broadcast to the public network, but not yet mined) 10:06 < amiti> yup! all correct 10:06 -!- julessss [60ead5a4@pool-96-234-213-164.bltmmd.fios.verizon.net] has quit [Remote host closed the connection] 10:06 -!- lightlike [~lightlike@p200300C7EF169600F5C62F9B2F452BEB.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:06 < vasild> "to improve privacy" - how? 10:06 < Smeier> ^ 10:07 < amiti> by tracking the ones that we dont think have been successfully propagated yet, we can reattempt broadcasting those separately from rebroadcasting transactions that we think have been seen by other nodes 10:07 < raj_> hi 10:07 < Smeier> Reading some of the conversations, I was confused on whether this is a privacy positive or not 10:07 -!- lightlike [~lightlike@p200300C7EF169600F5C62F9B2F452BEB.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 10:07 < amiti> great! lets get into it 10:08 < amiti> whats the claim for why this PR helps privacy 10:08 -!- lola_dam [56c00d0d@lfbn-ami-1-546-13.w86-192.abo.wanadoo.fr] has joined #bitcoin-core-pr-reviews 10:08 < amiti> and how does the unbroadcast set factor in? 10:08 < instagibbs> currently nodes only re-broadcast the same tx to same peer if it's committed to in their wallet 10:08 < detoxify> vasild: the privacy improvement is because a network observer can ascertain which node a transaction originated from because it's highly likely a node that's rebroadcsting a txn is the originating node because current default behavior for core is to rebroadcast one's own txn 10:09 < gloria43> ^ so if you ever see a node telling you about the same tx twice, it must originate from them? 10:09 < detoxify> PR is to reduce the amount of data a network observer has to make conclusions about txn origin 10:09 < lightlike> because we broadcast walltet transactions less often (ideally, in the case that we receive GETDATA for the tx the first broadcast, plus the tx gets mined within a day, only once) 10:09 < robot-visions> It makes sense intuitively that "rebroadcast less frequently" helps, but I'm having trouble coming up with a specific attack that gets thwarted. 10:09 < amiti> everyone is correct :D 10:10 < sipa> robot-visions: gloria43 just described it 10:10 < raj_> How the nodes decide "this one hasn't been propagated successfully, should try rebroadcasting"? 10:10 < jnewbery> robot-visions: I connect to your node and wait. If you INV me the same transaction over and over again, I can be pretty certain that it's in your wallet 10:10 < sipa> also, hi 10:10 < instagibbs> robot-visions, snoop can sit and not relay, just wait for you to say it again 10:11 < vasild> Do we ever re-broadcast transactions that did not originate at us in a sole attempt to fool an observer? I guess no. 10:11 < instagibbs> vasild, no 10:11 < Smeier> raj_, if your node receives a getdata request, you consider it broadcast 10:11 < _andrewtoth_> the unbroadcast set factors into this by removing a local tx after it is successfully broadcast, so it doesn't get broadcast to the same peer again 10:11 < detoxify> this is an anti-Eve measure 10:11 < robot-visions> jnewbery: sipa: so reducing to 24 hours makes this attack more expensive (you have to wait 1 day instead of 30 minutes?) 10:11 < amiti> ok. so the point of the unbroadcast set is so the _mempool_ can track transactions and do a best-effort of getting them to the network 10:11 < detoxify> robot-visions more expensive or obviates its possibility entirely 10:12 < sipa> also note that you need multiple connections 10:12 < amiti> this allows the _wallet_ to attempt rebroadcasting _wallet_ transactions less frequently 10:12 < sipa> within one connection there is a bloom filter that keeps track of that the other side already knows 10:12 < sipa> which filters out duplicate announcements 10:12 < jnewbery> vasild: not currently. See https://github.com/bitcoin/bitcoin/pull/16698 for the longer-term plan 10:12 < jnewbery> sipa: how long does that filter take to refresh? 10:12 < Smeier> so, does a given node never rebroadcast foreign txs? 10:13 < Smeier> and why not? 10:13 < MarcoFalke> robot-visions: Yes. And the tx could have been mined in those 24 hours 10:13 < amiti> if I remember correctly, I did some rough calculations that bloom filter can take ~6-12 hours to refresh. but low confidence on that. 10:13 < MarcoFalke> Smeier: See the link jnewbery shared 10:13 < robot-visions> thanks all! that makes sense. I expect the planned follow up PRs will help even more but I now understand more clearly how this one helps privacy immediately 10:14 < lightlike> i agree. if the tx has a reasonable miner fee, the attack should be impossible, not just more expensive. 10:14 < amiti> 16698 pulls out the *rebroadcast* functionality from wallet to mempool, so *all* nodes will start rebroadcasting some transactions 10:14 < elichai2> Do I understand correctly that the big privacy improvements aren't in this PR but will come later? 10:15 < MarcoFalke> elichai2: Yes, most of it 10:15 < MarcoFalke> Though, this one is also an improvement, I'd say 10:15 < amiti> elichai2: I think its subjective 10:15 < detoxify> lightlike +1 10:15 < amiti> I think this one is a significant improvement, esp in current mempool conditions 10:15 -!- pinheadmz_ [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 10:15 < amiti> but also that the next step will be even stronger privacy guarantees 10:15 < elichai2> But it sounds like this one actually increases the number of times it rebroadcasts it's txs 10:16 < MarcoFalke> elichai2: no, why? 10:16 < gloria43> in this PR, is the originating node still the only one rebroadcasting? 10:16 < amiti> not quite, to clarify this can somebody explain the difference between "unbroadcast" and "rebroadcast" ? 10:16 < elichai2> Oh I'm sorry, I misread 10:16 < sipa> gloria43: yes 10:16 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Ping timeout: 240 seconds] 10:16 < elichai2> I thought the old is 1/day and now it's 1/15min but it's the opposite :) 10:16 < gloria43> thanks for clarification! 10:16 < robot-visions> sure! "unbroadcast": it's not even in the network yet, so you retry every 10-15 minutes; "rebroadcast": it's already in the network but not yet mined, so you try again every 12-36 hours 10:17 < amiti> robot-visions: very nice! 10:17 < lightlike> MarcoFalke: really? Isn't the most usual case (you get a GETDATA for a tx, plus the tx is mined within a day) covered by this, so that future improvements might only improve privacy in fringe cases (no GETDATA; tx doesnt get mined)?) 10:17 < Smeier> but only your own txs can be unbroadcast right? 10:17 < elichai2> so this is definitely already a privacy improvement 10:18 < Smeier> this PR would never label foreign Txs as unbroadcast, because they had to come from outside? 10:18 < vasild> "in the network" is a bit fuzzy, what does it mean? "at least one other node has the tx"? 10:18 < robot-visions> "in the network" means you received a getdata for that transaction 10:18 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 10:18 -!- pinheadmz_ is now known as pinheadmz 10:18 < willcl_ark> so this PR -> "less chance of being identified" vs "quite likely to be identified" 10:18 < gleb> hi 10:18 < amiti> smeier: yes 10:18 < amiti> willcl_ark: I don't follow 10:18 < MarcoFalke> lightlike: Yeah, as amiti said it is subjective. It depends at what feerate the wallet creates txs. if they are with a target of 14 days, then the current change doesn't improve that much 10:18 < Smeier> amiti: thanks 10:19 < _andrewtoth_> is only 1 GETDATA enough? Should it wait for more than 1 to prevent it being blackholed? 10:19 < Smeier> does the "should've been mined" heuristic consider fee rate? 10:19 < amiti> _andrewtoth_: great question! one that I've asked myself a lot. 10:19 < amiti> lets go through step by step of how transactions interact with the unbroadcast set 10:20 < amiti> 1. how do transactions get added to the set? 10:20 < vasild> so, "in the network" indeed means "at least one other node has the tx" 10:20 < Smeier> they are locally submitted 10:20 < amiti> smeier: correct. what does that mean? 10:20 < _andrewtoth_> either from rpc sendrawtransaction or sent by the wallet 10:20 -!- lola_dam [56c00d0d@lfbn-ami-1-546-13.w86-192.abo.wanadoo.fr] has quit [Remote host closed the connection] 10:21 < amiti> vasild: its actually a bit more specific than that. the heuristic is that one other node has sent us a GETDATA for this transaction, leading us to believe its probably "in the network" 10:21 < amiti> so, very much a heuristic 10:21 < amiti> and the question _andrewtoth_ was asking is ... is this heuristic sufficient ? 10:21 < gleb> we still do best effort to send to every peer, right? 10:22 < gleb> heuristic just helps to not do it *again* 10:22 < amiti> which is a *really important* question to be asking. because if its insufficient, transactions might not make it out to the network 10:22 < Smeier> the best effort is changed to 12-36 hrs I believe 10:22 < _andrewtoth_> gleb that's my understanding 10:22 < detoxify> gleb same 10:22 < _andrewtoth_> it's removed on first GETDATA, but it was announced to all peers and their GETDATA's could come in after 10:22 < amiti> gleb: yes, but there can be some edge use cases that cause failures 10:23 < jnewbery> A more sophisticated way to determine if a transaction has propagated would be to announce it to some of your peers and wait for it to be INVed by the others 10:23 < amiti> jnewbery: agreed. that seems very robust 10:24 < Smeier> is that planned in future PRs? 10:24 < amiti> ok, so "locally submitted" transactions get added to the set, which means they were submitted via the wallet or via the rpcs 10:24 < _andrewtoth_> jnewbery: could that have privacy improvements as well? Not all your peers will know you've originated it 10:25 < gleb> If your node is reachable, someone can still easily connect to you issue you that INV etc... Then you probably want several invs from *outbounds*. 10:25 < amiti> not currently planned. would probably have privacy improvements. would have to be implemented very carefully, but probably possible 10:25 < amiti> I considered it when designing this PR, but decided to make incremental improvements 10:25 < robot-visions> jnewbery: if you send a transaction to a peer in response to `getdata`, will they send an `inv` back for that transaction, or would the per-connection bloom filter prevent it? 10:26 < amiti> what is another way transactions can be removed from the unbroadcast set? 10:26 < sipa> robot-visions: that certainly gets filtered 10:26 < amiti> (other than on the first GETDATA) 10:26 < Smeier> it seems like it could allow eclipse attacks to be easier, because a full eclipse isn't necessary. 2-3 nodes could convince yours to stop broadcasting 10:26 < jnewbery> _andrewtoth_: maybe? Would that now mean that if you _don't_ announce a tx that everyone else announced, then you're probably the originator? 10:26 < sipa> amiti: i assume... by the transaction leaving the mempool? 10:26 < robot-visions> amiti: I think transactions could also be removed if they get mined, expired, etc. 10:26 < b10c> amiti: transaction is confirmed? 10:27 < raj_> when its removed from mempool. 10:27 < gleb> Smeier: I won't call it eclipse. Probably censorship (and only of rebroadcast tx). But yeah. 10:27 < amiti> sipa: I like how you say you "assume" when you reviewed the pr 😂 10:27 < robot-visions> sipa: thanks, makes sense 10:27 < sipa> amiti: i just woke up :) 10:27 < sipa> but i'm actually going to check now that it does that 10:27 < _andrewtoth_> this won't be removed if it is mined, because if it is in unbroadcast set it was never sent to miners 10:27 < Smeier> Gleb why wouldn't this affect unbroadcast? 10:27 < amiti> yup correct. I just wanted to highlight that because when this was in the initial stages & part of the bigger 16698 PR I overlooked removing for other reasons 10:28 < _andrewtoth_> jnewbery: they would have to have a lot of knowledge of peer topography to determine that no? 10:28 < gleb> Smeier: oh, I'm confusing the two still, joined the meeting too late I guess :) Eclipse is just too much of a strong word for this, you still receive everything from the network and can send other transactions... 10:28 < jnewbery> possibly. I'm just throwing stuff out there :) 10:29 < b10c> _andrewtoth_: it could have reached the miner not from our node 10:29 < robot-visions> _andrewtoth_: good point, I suppose that can't usually happen unless YOU are the miner or some other edge case 10:29 < _andrewtoth_> b10c: how if it's a locally submitted transaction? 10:29 < b10c> _andrewtoth_: if I submit it on e.g. two nodes 10:29 < robot-visions> _andrewtoth_: maybe someone submitted it in multiple places? 10:29 < _andrewtoth_> hmm but yes now that I think about it, that could happen. but in that case it is removed from mempool when it's mined, so this PR covers that case 10:29 < Smeier> gleb, you're right, censorship is the better term. But currently, to censor a tx, you'd have be all of a node's peers, with jnewbery suggestion, you could do it with just a fe 10:29 < Smeier> few 10:30 < jnewbery> _andrewtoth_: One example: you co-signed a transaction with someone. They submit it and you submit it 10:30 < sipa> in general both the sender and receiver will rebroadcast 10:30 -!- whythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 10:30 -!- gloria43 is now known as gzhao408 10:31 < amiti> ok cool, moving forward.. 10:31 < gleb> Smeier: I don't think john's idea degrades as compared to the discussed PR approach. One INVs instead of GETDATAs. Invs are a bit easier I guess: they can be send unsolicited. 10:31 < _andrewtoth_> right, lots of cases where it could be mined but still in the unbroadcast set 10:31 < amiti> the next two questions we have danced around, but maybe we can dig into it further 10:31 < lightlike> can someone who knows the lightning network well, tell me how time critical a rebroadcast can be there? Can we lose money if a tx does not get broadcast the first time and we have to wait ~12 hours? If we don't succeed the second time? 10:31 < gleb> lightlike: as low as 2 hours in some cases. 10:31 < amiti> ok nevermind i'll pause till we dig into these :) 10:32 < amiti> one topic being discussed is different heuristics for determining if the unbroadcast txns have been seen by the network 10:32 < gleb> lightlike: generally they widely use 144 blocks, but there are some corner cases where they do like 6-12 blocks iirc. 10:33 < _andrewtoth_> doesn't it depend on how many hops the payment is sent? 10:33 < gleb> lightlike: I would say that's probably a responsibility of lightning impl, not Bitcoin Core. Because they may also want to do fee bumping in that case, and our p2p code can absolutely not do that. 10:34 < sipa> amiti: actually, i wonder if perhaps your PR does not do this... the wallet rebroadcasting logic applies to all wallet transactions; but only sent transactions (and not received ones) get added to the mempool-based rebroadcasting 10:34 < gleb> sipa: very cool consideration. I'm actually curious now. 10:35 < amiti> sipa: when you say mempool-based rebroadcast, are you talking about implementation in 16698? 10:35 < sipa> amiti: i'm talking about the PR that was just merged, 18038 10:35 < amiti> or do you mean mempool-based unbroadcast retries in 18038 10:35 < _andrewtoth_> if the wallet receives a tx but it doesn't get confirmed in 24 hours, it won't be rebroadcast. Only sent txs 10:35 < amiti> oh yes, only the sender will reattempt 10:36 < sipa> addition to the unbroadcast set happens in BroadcastTransaction, which only the sender calls 10:36 < sipa> i think the receiver should also call it 10:36 < jonatack> gleb: afaik ultimately the LN implementations still need a fuller version of package relay (e.g. changed bitcoin core p2p protocol) to deal with fee management issues when fees rise again 10:36 < detoxify> sipa is your point that if you receive a transaction from a peer that the receiver's node will rebroadcast the transaction which will affect unbroadcast/rebroadcast logic? 10:36 < amiti> sipa: I agree only sender reattempts. can you help me understand a use case why receiver should also call? 10:36 < jnewbery> sipa: I don't think so. If you've received it then it's already propagated 10:37 < jnewbery> this seems like an improvement to me. The receiver won't needlessly rebroadcast 10:37 < _andrewtoth_> a use case is if the tx doesn't get confirmed in 24 hours, and the sender is offline 10:37 < sipa> amiti: for starters, conceptually, the receiver is the only one who actually cares the transaction confirms 10:37 < jnewbery> the receiver would still rebroadcast after 12-36 hours I believe 10:37 < Anonymous93> amiti sidetrack, but how did u go about debugging this PR and knowing which files to modify? 10:37 < sipa> and the receiver may have learned about the tx out of band 10:38 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Ping timeout: 240 seconds] 10:38 < amiti> jnewbery: yes they'd rebroadcast after 12-36 hours 10:38 < amiti> sipa: if the receiver learned about the txn out of band and wants it to confirm, couldn't they just submit it through the RPC? 10:38 < MarcoFalke> sipa: Out of band == sendrawtransaction? 10:38 < Smeier> sorry, beginner question, but that means all txs are broadcast again regardless of origin every 12-36 hrs? 10:39 < MarcoFalke> Smeier: It is a wallet function to do this every couple of hours 10:39 < sipa> right, i'm saying this PR changed the receiver rebroadcast from frequent to infrequent, without adding a corresponding unbroadcast logic to compensate 10:39 < amiti> smeier: right now only wallet txns will be broadcast again every 12-36 hours 10:39 < jnewbery> Smeier: correct. The wallet will rebroadcast all of its unconfirmed transactions (sent or received) every 12-36 hours 10:39 < sipa> amiti: or you run local software that used the p2p interface to submit transactions to the receiver's node 10:39 < Smeier> including other unrelated ones? or only sent and received ? 10:39 < sipa> i agree it's not the most common scenario 10:39 < robot-visions> I think I'm having trouble keeping up with the "sender" vs. "receiver" discussion because I'm not clear on what's meant by "a wallet transaction". 10:39 < sipa> Smeier: only wallet-affecting transactions 10:39 < robot-visions> Excluding `rawtransaction`, which transactions are eligible for rebroadcast? 10:40 < sipa> robot-visions: all wallet transactions 10:40 < instagibbs> robot-visions, wallets will rebroadcast *any* transaction stored in the wallet 10:40 < sipa> i don't know what rawtransaction has to do with it? 10:40 < amiti> sipa: I think in the case where the recipient resubmits via RPC, then they will add to unbroadcast set as well 10:40 < instagibbs> robot-visions, this can include a transaction you sent, a transaction you received, a transaction you *watched* 10:40 < instagibbs> aka watchonly 10:40 < amiti> if they are doing something that uses the p2p interface to submit, then you're right, the functionality has been changed 10:41 < jnewbery> sipa: if you receive it from local software using the p2p interface, then it'll get relayed on after it's accepted to the mempool 10:41 < Smeier> what should I read to understand the difference between wallet and p2p interface? do they submit txs differently? 10:42 < amiti> robot-visions: if you wanna better understand, check out the ResendWalletTransactions method https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1986 10:42 < MarcoFalke> Smeier: They call the same function "BroadcastTransaction" 10:42 < amiti> in the section where it wants to relay transactions, it iterates through `mapWallet` 10:42 < _andrewtoth_> ahh so received txs still get rebroadcast after 24 hours, that's not affected by unbroadcast set 10:42 < sipa> MarcoFalke: wallet and RPC both use BroadcastTransaction 10:42 < MarcoFalke> jup, I believe so 10:42 < sipa> "p2p interface" to submit transactions... that's just the network 10:42 < amiti> you can search the code for what transactions get tracked in `mapWallet` :) 10:43 < sipa> jnewbery: i don't understand your last sentence 10:43 < robot-visions> sipa: instagibbs: amiti: thanks, that helps a lot! 10:43 < _andrewtoth_> Smeier: wallet submits locally, rpcs are sendtoaddress and sendmany. p2p uses INV and GETDATA to broadcast txs 10:43 < MarcoFalke> sipa: A transaction added to the mempool will get the txid passed to connman for the inv logic 10:44 < MarcoFalke> `RelayTransaction` or so 10:44 < sipa> sure, for the initial broadcast 10:44 < amiti> Anonymous93: "sidetrack" questions are welcome! not sure what you meant though 10:44 < MarcoFalke> sipa: But yeah. There is no unbroadcast for wallet txs received on the p2p interface 10:45 < Smeier> _andrewtoth_ wallet submits locally but then it calls BroadcastTransaction, correct? and RPC calls the same? 10:45 -!- whythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 10:45 < sipa> i'm not sure it matters a lot, but i feel it's a behavior change this PR introduced that i missed before 10:45 < amiti> sipa: what I'm understanding- if a user is submitting a transaction via a p2p interface, the reattempts at broadcast changes with this PR 10:46 < sipa> right 10:46 < _andrewtoth_> Smeier: wallet is controlled by RPC 10:46 < jnewbery> sipa: I'm trying to understand your scenario. I have a Bitcoin node and wallet. I have some other software that connects to the Core node and sends a TX over P2P that spends to my wallet. 10:46 < jonatack> Anonymous93: by participating in the review club! (and reviewing PRs and looking at the codebase, over time it starts to make more sense) 10:46 < instagibbs> worth a release note probably that wallets are in charge of rebroadcast, even if external 10:46 < amiti> thats true whether they are sender / receiver / whatever 10:46 < sipa> jnewbery: and say the sender goes offline 10:46 < jnewbery> I'm saying that when we receive the TX and it gets accepted to our mempool, we'll relay it on to other peers. 10:46 < sipa> sure 10:46 < Anonymous93> amiti how do u go about debugging ur code to make sure the PR works? 10:46 < MarcoFalke> Anonymous93: there are tests included 10:47 < amiti> anonymous93: ahahhaha I see. well I like functional tests a lot. and usually when I'm iterating I do manual tests as well 10:47 < Anonymous93> do u use GDB, just observing and looking? 10:47 < amiti> I also like to log things so I can trace through the C++ code and check my expectations 10:47 < Anonymous93> understood, thanks MarcoFalke and amiti 10:47 < jnewbery> if you want to force something back into the unbroadcast set, you can call sendrawtranscation, right? 10:47 < instagibbs> Anonymous93, also depends on the size of change you're making how much you test and how you test 10:48 < Anonymous93> cool 10:48 < Smeier> on the topic of checking, I checked out this pr branch, and ran make check (as with normal bitcoin core) 10:48 < amiti> when I'm tracing with logging, I'll add "abcd" to the start of log prints that I care about, then I'll have a functional test, save the logs, and grep "abcd", to check the code flow 10:48 < sipa> jnewbery: my point is that that's an unreasonable behavior change, if anything relies on it 10:48 < amiti> its a mixture of techniques :) 10:48 < Smeier> How can I look at the tests just for this PR? 10:48 < sipa> jnewbery: so far, the wallet has done frequent rebroadcasting of every relevant transaction, not just sent ones 10:48 < MarcoFalke> sipa: Agree that that should be mentioned somewhere outside this IRC log 10:48 < amiti> smeier: check out the diff of this PR & trace down where tests have been introduced, either unit or functional 10:49 < robot-visions> sipa: just to make sure I understand, your concern is that if a wallet *receives* a transaction, it will still only use the rebroadcast (not the unbroadcast) mechanism? 10:49 < Anonymous93> fjahr can u move this onto GitHub so that we can maintain it: https://gist.github.com/fjahr/2cd23ad743a2ddfd4eed957274beca0f 10:49 < jnewbery> sipa: but I don't see much difference from if we're the sender. We'll relay it once in both cases 10:49 < sipa> this has changed to only frequent rebroadcasting of unbroadcast sent transactions, and infrequent rebroadcasting of everything else 10:49 < amiti> sipa, marcofalke: any ideas of where I can document? 10:49 < amiti> if this was a use case that people relied on, then we could figure out a way to support it 10:49 < sipa> it seems trivial to fix 10:50 < amiti> oh yeah? 10:50 < robot-visions> Smeier: one way is to look at individual commits in the PR: https://github.com/bitcoin/bitcoin/pull/18038/commits 10:50 < _andrewtoth_> Smeier: In the commit https://github.com/bitcoin/bitcoin/pull/18038/commits/297a1785360c4db662a7f3d3ade7b6b503258d39 10:50 < jnewbery> the only difference is if you're offline when you submit your receiving transaction over your local p2p network 10:50 < sipa> call AddUnbroadcastTx in AddToWallet 10:50 < fjahr> Anonymous93: sure, i was planning to rework it but collaborating is better for sure. Thanks! 10:51 < Anonymous93> fjahr I looked at it and definitely want to help out! 10:51 < robot-visions> sipa: could that result in the unbroadcast set getting very large? for example, by the time a sender receives a transaction, maybe most of its peers have it, so no one will ever send a getdata 10:51 < jnewbery> sipa: then you'll always echo back transactions sent to you. Seems like a step backwards 10:51 < robot-visions> s/sender/receiver 10:51 < gleb> sipa: not sure the wording Unbroadcast now really applies that well but yeah, i think the idea makes perfect sense. 10:52 < sipa> jnewbery: hmm, i see 10:52 < amiti> I'll have to think about it more. I agree with jnewbery that in most cases it seems bad for privacy 10:52 < Anonymous93> can we propose fixes that we want to see being reviewed? I'm having trouble fixing one of the unit tests. 10:52 < gleb> i wish there was a way to distinguish receiving from regular p2p network and semi-out-of-band whatever. 10:52 < gleb> Maybe we could remove it once we get a second inv or something... 10:52 < Anonymous93> https://github.com/bitcoin/bitcoin/issues/18776 10:53 < b10c> question 5 is "Should mempool.dat be versioned?" 10:53 < sipa> but you may first get 147 INVs very rapidly, request a GETDATA from one of them, which arrives after all INVs have already arrived 10:53 < b10c> I think it is versioned, isn't it? 10:53 < MarcoFalke> jnewbery: Why? there is a bloom filter to prevent that 10:53 < amiti> were talking about this use case of "submitting via p2p", what would that hook up into? 10:53 < amiti> ahahhahah b10c thank you :) 10:53 < sipa> in which case you'll never get an INV again, so it will remain in the unbroadcast set 10:53 < sipa> which would be bad 10:54 < amiti> it does have a version on it, but it seems like its actually a bit tricky to update the version 10:54 < b10c> it is: https://github.com/bitcoin/bitcoin/blob/0ef0d33f7562c3b7f9c021549e70b3b4dbcc504c/src/validation.cpp#L5006-L5009 10:54 < jnewbery> MarcoFalke: yeah, pfilter will catch it 10:54 < _andrewtoth_> what about the use case where you have a node in your local network that connects to only 1 node that has outside connections. It will never get a GETDATA for a received tx from that one node 10:54 < b10c> amiti: oh why? 10:54 < robot-visions> b10c: amiti: If everyone is going to upgrade at the same time, then I'd say yes. But this seems unlikely, so I don't think it's worth the extra complexity to ensure that you can upgrade while keeping your previously persisted mempool. 10:55 < MarcoFalke> sipa: AddUnbroadcast should not add the tx to the set. This is a bug right now and will make your node DOS other peers and be uniquely identifiable if it does that. I plan on fixing that. 10:55 < sipa> perhaps the solution to all these questions is just the successor... where all nodes start rebroadcasting everything they know that they expect to see confirmed 10:55 < sipa> MarcoFalke: hmm? 10:55 < MarcoFalke> *if it the tx is not in the mempool 10:55 < sipa> (i was talking about a hypothetical AddToWallet calling AddUnbroadcast - which I agree now would be a bad idea) 10:55 < robot-visions> amiti: do you know what happens if you start the updated version with an old `mempool.dat`? 10:55 < amiti> b10c: check out this comment thread here. https://github.com/bitcoin/bitcoin/pull/18038#discussion_r397982629. marcofalke gave some descriptions and I learned a bunch 10:56 < MarcoFalke> sipa: Even absent that, it is still a bug and exploitable through mempool.dat 10:56 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Ping timeout: 240 seconds] 10:56 < sipa> MarcoFalke: then i don't know what you're talking about; care to elaborate? 10:56 < gleb> I try to think of Bitcoin Core wallet as any other wallet. Would we have the same questions about receiving transactions if it is "external"? 10:57 < sipa> gleb: this is all solved once all nodes start rebroadcasting everything 10:57 < sipa> so maybe we should just defer the solutions to that 10:57 < MarcoFalke> sipa: Will submit a fix instead ;) 10:57 < jonatack> This PR changes a wallet tx resend timer that hasn't been changed since at least 2011... if ever at all? I would be surprised to not run across a few unexpected effects from this first change to it. 10:57 < b10c> amiti: thanks! didn't even mean move on, was just curious about that question 10:57 < amiti> ok! so looks like we have 3 minutes left 10:57 < amiti> does anybody have any questions 10:58 < sipa> 2 10:58 < amiti> =P 10:58 < jnewbery> MarcoFalke: sipa: I believe we just need to do this: https://github.com/bitcoin/bitcoin/pull/18038#discussion_r416861609 to prevent the unbroadcast set potentially getting out of sync with the mempool 10:58 < fjahr> Anonymous93: Done :) https://github.com/fjahr/debugging_bitcoin 10:59 < vasild> Why the current code does not treat own txs like foreign txs and rebroadcast everything? To reduce traffic? 10:59 < sipa> vasild: that's the next step; one thing at a time 10:59 < MarcoFalke> jnewbery: Probably good to add checks to both AddUnbroadcast and ReattemptInitialBroadcast 10:59 < jnewbery> vasild: see the next PR in the sequence 10:59 < MarcoFalke> jnewbery: "belt-and-suspenders" 10:59 < amiti> yes rebrodacasting *everything* would be a significant hit to the bandwidth, so we have to do it carefully 10:59 < amiti> thus the next PR 10:59 < vasild> sipa: yes, but I mean why it was not done like that in the first place? 10:59 < sipa> vasild: ask satoshi? 10:59 < sipa> :p 11:00 < jonatack> I'm certainly looking forward to reviewing the next steps. 11:00 < vasild> probably he had a slow internet connection :) 11:00 < amiti> ok! that is time 11:00 < amiti> thanks all for playing! 11:00 < instagibbs> amiti, have you thought much about rusty's point here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017797.html 11:00 < jnewbery> thanks amiti! 11:01 < robot-visions> thanks! 11:01 < instagibbs> would the next PR fit the bill to start thinking about reforming transaction replacement policy? 11:01 < vasild> Cheerz! 11:01 < amiti> if anybody has outstanding questions, feel free to DM me and I'll try my best to get to them 11:01 < _andrewtoth_> thanks amiti! 11:01 < b10c> thanks amiti! 11:01 < lightlike> thanks! 11:01 < gzhao408> thanks amiti! 11:01 < sipa> so perhaps it's worth just adding to the release notes that transactions submitted locally to the wallet via P2P will not be rebroadcast frequently anymore, which can be circumvented by using sendrawtransaction 11:02 < willcl_ark> thanks amiti, that was an interesting discussion to watch 11:02 < Smeier> thank you! 11:02 < amiti> instagibbs: not entirely sure the relationship you're talking about, but I'll take a closer look at the email 11:02 < jonatack> sipa: agree, good idea 11:02 < amiti> sipa: will do 11:02 < instagibbs> amiti, yeah just read it, you'll likely know the answer more than me 11:02 -!- spaghetti [18bf0f97@ool-18bf0f97.dyn.optonline.net] has quit [Remote host closed the connection] 11:02 < amiti> 👌 11:03 < sipa> i think it's mostly unrelated to this work 11:03 < jonatack> thanks amiti et al, excellent session 11:03 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 265 seconds] 11:03 < sipa> thanks! 11:03 < sipa> the discussion made me review your changes in more depth :) 11:04 < amiti> thats awesome! 11:05 < amiti> I learned stuff today (and want to continue..) 11:05 -!- whythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 11:07 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 11:07 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 11:07 -!- Smeier [cfacdb18@207.172.219.24] has quit [Remote host closed the connection] 11:08 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 11:08 < emzy> btw. I have the data dir on a bttrfs with zstd as compression running. Runs find and saved 20% disk space. 11:11 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 11:13 -!- shaunsun [~shaunsun@c-76-26-29-34.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews 11:17 -!- shaunsun_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 11:17 -!- b10c [~b10c@2001:16b8:2e48:6500:f802:c214:4679:e07f] has quit [Quit: Leaving] 11:20 -!- shaunsun [~shaunsun@c-76-26-29-34.hsd1.fl.comcast.net] has quit [Ping timeout: 256 seconds] 11:29 -!- robot-visions [ac5c0435@172.92.4.53] has quit [Remote host closed the connection] 11:29 -!- lightlike [~lightlike@p200300C7EF169600F5C62F9B2F452BEB.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 11:38 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds] 11:40 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 12:33 -!- jonatack [~jon@109.232.227.149] has quit [Ping timeout: 244 seconds] 12:34 -!- sonofhan [~sonofhan@104.238.46.201] has joined #bitcoin-core-pr-reviews 12:35 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:35 -!- jonatack [~jon@37.170.24.56] has joined #bitcoin-core-pr-reviews 12:35 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 12:36 -!- sonofhan [~sonofhan@104.238.46.201] has quit [Read error: Connection reset by peer] 12:56 -!- Anonymous93 [60f858e5@pool-96-248-88-229.cmdnnj.fios.verizon.net] has quit [Remote host closed the connection] 13:01 -!- kristapsk_ is now known as kristapsk 13:02 -!- sonofhan [~sonofhan@104.238.46.201] has joined #bitcoin-core-pr-reviews 13:04 -!- sonofhan [~sonofhan@104.238.46.201] has quit [Client Quit] 13:34 -!- brakmic_ [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews 13:34 -!- jonatack [~jon@37.170.24.56] has quit [Quit: jonatack] 13:36 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Remote host closed the connection] 13:36 -!- mrwhythat [~whythat@gateway/tor-sasl/whythat] has joined #bitcoin-core-pr-reviews 13:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55] 13:38 -!- brakmic [brakmic@gateway/vpn/nordvpn/brakmic] has quit [Ping timeout: 260 seconds] 13:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 14:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 14:39 -!- shesek [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews 14:39 -!- shesek [~shesek@5.22.128.43] has quit [Changing host] 14:39 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 14:41 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:2576:934:d62b:3df0] has quit [Quit: Sleep mode] 14:43 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:2576:934:d62b:3df0] has joined #bitcoin-core-pr-reviews 14:44 -!- detoxify [~detoxify@185.242.5.35] has quit [Quit: detoxify] 14:53 -!- mrwhythat is now known as whythat 14:56 -!- shaunsun_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 256 seconds] 14:59 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 14:59 -!- whythat [~whythat@gateway/tor-sasl/whythat] has quit [Quit: whythat] 15:00 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 15:00 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 15:15 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 256 seconds] 15:21 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:2576:934:d62b:3df0] has quit [Ping timeout: 272 seconds] 15:37 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Quit: WeeChat 1.9.1] 15:39 -!- soju [uid403160@gateway/web/irccloud.com/x-wzjtboigpqexgdoh] has joined #bitcoin-core-pr-reviews 15:41 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 15:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:45 -!- vasild_ is now known as vasild 16:03 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 16:24 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 16:27 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 16:43 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 16:56 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 17:34 -!- brakmic_ [~brakmic@185.183.85.108] has quit [] 17:48 -!- soju [uid403160@gateway/web/irccloud.com/x-wzjtboigpqexgdoh] has quit [Quit: Connection closed for inactivity] 18:17 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 246 seconds] 18:17 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 18:17 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 18:17 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 19:58 -!- midnight is now known as midnightmagic 19:59 -!- midnightmagic is now known as midnight 20:48 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 20:51 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 21:12 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 22:06 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 22:17 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 22:25 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 22:53 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 22:58 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 23:28 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 23:33 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]