--- Log opened Tue Sep 22 00:00:25 2020 00:18 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:18 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:7480:99c2:1df9:1dab] has joined #bitcoin-core-dev 00:21 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 00:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 00:26 -!- marcoagner [~user@bl11-17-219.dsl.telepac.pt] has joined #bitcoin-core-dev 00:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:7480:99c2:1df9:1dab] has quit [Remote host closed the connection] 00:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:7480:99c2:1df9:1dab] has joined #bitcoin-core-dev 00:33 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:7480:99c2:1df9:1dab] has quit [Ping timeout: 240 seconds] 00:56 -!- kljasdfvv [~flack@p57bc9c37.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 00:56 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer] 00:57 -!- sr_gi [~sr_gi@static-80-160-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev 00:57 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:6117:1ae2:5ef1:4f40] has joined #bitcoin-core-dev 00:58 -!- kljasdfvv [~flack@p200300d46f0c7600c5edd51d4a58354d.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 01:03 -!- dermoth_ [~dermoth@unaffiliated/dermoth] has joined #bitcoin-core-dev 01:03 -!- dermoth [~dermoth@unaffiliated/dermoth] has quit [Disconnected by services] 01:03 -!- dermoth_ is now known as dermoth 01:04 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 260 seconds] 01:22 -!- Kiminuo [~mix@141.98.103.148] has joined #bitcoin-core-dev 01:26 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 01:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:6117:1ae2:5ef1:4f40] has quit [Remote host closed the connection] 01:29 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:6117:1ae2:5ef1:4f40] has joined #bitcoin-core-dev 01:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 01:34 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:6117:1ae2:5ef1:4f40] has quit [Ping timeout: 260 seconds] 01:35 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 02:00 -!- leolein1 [~leolein@178.162.209.171] has quit [] 02:04 -!- andreacab [~andreacab@178.197.234.77] has joined #bitcoin-core-dev 02:04 -!- kexkey [~kexkey@89.36.78.166] has quit [Ping timeout: 260 seconds] 02:06 -!- andreaca_ [~andreacab@2a02:120b:2c07:ebc0:30de:ec6:564e:df50] has joined #bitcoin-core-dev 02:07 -!- andreacab [~andreacab@178.197.234.77] has quit [Read error: Connection reset by peer] 02:11 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 02:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 02:21 -!- Cros1 [~Cros@217.146.82.202] has joined #bitcoin-core-dev 02:44 -!- jonatack [~jon@194.187.251.163] has joined #bitcoin-core-dev 02:48 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 02:48 -!- jonatack [~jon@194.187.251.163] has quit [Ping timeout: 240 seconds] 02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:50 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 02:51 -!- jonatack [~jon@37.171.240.64] has joined #bitcoin-core-dev 03:00 -!- andreaca_ [~andreacab@2a02:120b:2c07:ebc0:30de:ec6:564e:df50] has quit [Remote host closed the connection] 03:01 -!- andreacab [~andreacab@2a02:120b:2c07:ebc0:30de:ec6:564e:df50] has joined #bitcoin-core-dev 03:05 -!- andreacab [~andreacab@2a02:120b:2c07:ebc0:30de:ec6:564e:df50] has quit [Ping timeout: 260 seconds] 03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:19 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 246 seconds] 03:20 -!- Terry81Kohler [~Terry81Ko@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev 03:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection] 03:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-dev 03:28 -!- Terry81Kohler [~Terry81Ko@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 272 seconds] 03:29 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 03:31 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 03:34 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 03:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 03:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 04:17 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 04:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:44 < bitcoin-git> [bitcoin] hebasto opened pull request #19991: net: Use alternative port for incoming Tor connections (master...200922-tor) https://github.com/bitcoin/bitcoin/pull/19991 04:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:51 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 05:00 -!- Cros1 [~Cros@217.146.82.202] has quit [] 05:24 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 05:33 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev 05:52 -!- jonatack [~jon@37.171.240.64] has quit [Read error: Connection reset by peer] 05:55 -!- nhandler1 [~nhandler@193.56.252.210] has joined #bitcoin-core-dev 06:12 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 06:21 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 06:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 06:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 06:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 06:38 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 06:57 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 07:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:00 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #19993: refactor: Signet fixups (master...2009-signetFixups) https://github.com/bitcoin/bitcoin/pull/19993 07:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:01 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Remote host closed the connection] 07:01 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev 07:03 < jnewbery> Hi folks. There's a P2P meeting today in an hour. We have one proposed topic: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#22-sept-2020. Feel free to propose more in the next hour. 07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/22 | Update the list of hard-coded node IP addresses · Issue #22 · bitcoin/bitcoin · GitHub 07:04 < jnewbery> bad bot 07:05 < jnewbery> sipa: perhaps a brief overview of #19988 would be of interest to the meeting attendees (motivation/design philosphy rather than technical details that can be found in the PR) 07:05 < gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub 07:08 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 07:23 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 07:30 -!- Kiminuo [~mix@141.98.103.148] has quit [Ping timeout: 260 seconds] 07:41 -!- kexkey [~kexkey@89.36.78.166] has joined #bitcoin-core-dev 07:58 < gleb> jnewbery: I have this PR #19958. I would just make a little announcement during the meeting, not planning to actually discuss it, because I think the trade-off is simple and already known. 07:58 < gribble> https://github.com/bitcoin/bitcoin/issues/19958 | Rename feelers to probes by naumenkogs · Pull Request #19958 · bitcoin/bitcoin · GitHub 07:58 < sipa> jnewbery: happy to do that 07:59 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ojekfqhypyhwkxni] has quit [] 07:59 -!- ajonas [sid385278@gateway/web/irccloud.com/x-mlutywotlnjlafij] has joined #bitcoin-core-dev 08:00 -!- nhandler1 [~nhandler@193.56.252.210] has quit [] 08:00 < sdaftuar> hello 08:00 < jnewbery> #startmeeting 08:00 < lightningbot> Meeting started Tue Sep 22 15:00:35 2020 UTC. The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 08:00 < hebasto> hi 08:00 < gzhao408> hi 08:00 < jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james 08:00 < jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2 08:00 < ajonas> hi 08:01 < ariard> hi 08:01 < aj> holla 08:01 < amiti> hi 08:01 < gleb> hi 08:01 < jnewbery> Hi folks. Two proposed topics today: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#22-sept-2020 08:01 < gribble> https://github.com/bitcoin/bitcoin/issues/22 | Update the list of hard-coded node IP addresses · Issue #22 · bitcoin/bitcoin · GitHub 08:01 < fanquake> hi 08:01 < jnewbery> - Follow-up on "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard) 08:01 < gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub 08:01 < jnewbery> - Overview of https://github.com/bitcoin/bitcoin/pull/19988 (motivation/design philosphy rather than technical details that can be found in the PR) 08:02 < jnewbery> Before we get to those, are there any other proposed topics, or does anyone have any short announcements to make? 08:02 < gleb> Yeah, I have one. 08:02 < vasild> hi 08:02 < gleb> I suggested to rename "feeler" connection to "probe" all along the codebase, because feelers currently capture two distinct features: feelers and test-before-evict. 08:02 < jnewbery> gleb: feelers -> probes ? 08:03 < jnewbery> ok. Let's do that first (and not spend 50 minutes on it :) 08:03 < jnewbery> #topic feelers -> probes (gleb) 08:03 < gleb> There's some support of renaming, but also couple hesitations and wladimir said we would rather not, because of rebase conflicts etc 08:03 < gleb> So I'm planning to drop this idea for now, and just improve the documentation. 08:04 < gleb> If someone is strongly in favor of renaming feelers to probes, please comment in the PR sometime soon :) 08:04 < sipa> fixing documentation is always good 08:04 < gleb> #19958 08:04 < gribble> https://github.com/bitcoin/bitcoin/issues/19958 | Rename feelers to probes by naumenkogs · Pull Request #19958 · bitcoin/bitcoin · GitHub 08:04 < sipa> or at least, making it less confusing 08:05 < gleb> That's it, we now can discuss other topics, unless someone have something to say right now :) 08:05 < amiti> thanks for the doc fix :) 08:05 < jnewbery> I'm generally in favour of making names more meaningful. If we're going to make this name change, I think it's preferable to do it before connection types are exposed in the RPC 08:06 < jnewbery> But I haven't looked at the specifics here, and don't have an opinion on this change 08:06 < jnewbery> ok, next topic? 08:06 < gleb> Good point wrt RPC 08:06 < gleb> yeah, we can move on i guess 08:07 < jnewbery> #topic Follow-up on "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard) 08:07 < gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub 08:07 < ariard> I think we have a problem ecosystem-wise as we have protocols being designed and deployed 08:07 < ariard> which are completely insecure because of implicit assumptions on the tx-relay network and mempools behavior which are false 08:08 < sipa> anything that relies on specific properies of tx relay being guaranteed is broken 08:09 < gleb> how should we approach this problem? :) 08:09 < ariard> yes and I was aiming to synchronize people's model to suggest some kind of join IRC meeting 08:09 < ariard> with the LN devs, rusty, cdecker & all were down 08:09 < sipa> i think it's a good idea to work towards better analysing and documenting the design goals for transactions, but that's not going to result in any guarantees 08:09 < sdaftuar> i think tx relay works pretty well for transactions whose inputs are all confirmed? 08:10 < aj> sdaftuar: not if the transaction is RBF'ing something else that was previously relayed? 08:10 < ariard> sipa: I agree it's more how do we establish a common mental model ecosystem-wise ? 08:10 < sdaftuar> aj: agreed that we can continue to make improvements there! 08:11 < sdaftuar> aj: but i think we have something that is pretty reliable right now 08:11 < ariard> like either modifiyng second-layer protocols or tx-relay but not staying in-between 08:12 < gleb> The problem can be at least split into several 08:12 < vasild> Some LN protocol or implementation relies on a transaction propagating to every node? 08:12 < sipa> ariard: to me, the only solution if you need things that must confirm within a fixed amount of time is loudly yelling at the user if the timeout runs close 08:12 < gleb> For example, "assuming I can pay whatever fee, can I guarantee that my transaction will reach miners"? 08:12 < sdaftuar> guarantee is a very hard word to use 08:13 < ariard> sipa: I think we should dissociate propagation guarantee from confirmation guarantee, ofc you can't promise confirmation 08:13 < sipa> ariard: that's independent of potential improvements to tx relay that can make it more reliable in more varied scenarios - but if your security assumption is that relay (and confirmation!) are guaranteed, nothing can provide that 08:13 < ariard> sipa: yes I think we agree on the confirmation part, it's more the relay one which can be exploited by a malicious counterparty 08:13 < sipa> ariard: and i feel that framing this as "we need better tx relay because higher level protocols rely on some of its assumptions" is kind of missing the point 08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:14 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/77376034d4ab...d692d192cda3 08:14 < bitcoin-git> bitcoin/master fa80c81 MarcoFalke: Assert that RPCArg names are equal to CRPCCommand ones (blockchain) 08:14 < bitcoin-git> bitcoin/master fa6bb0c MarcoFalke: Assert that RPCArg names are equal to CRPCCommand ones (rawtransaction) 08:14 < bitcoin-git> bitcoin/master d692d19 MarcoFalke: Merge #19849: Assert that RPCArg names are equal to CRPCCommand ones (bloc... 08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:14 < gleb> sipa: so you're suggestion it should be users' responsibility? 08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:14 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19849: Assert that RPCArg names are equal to CRPCCommand ones (blockchain,rawtransaction) (master...2008-rpcAssertNames) https://github.com/bitcoin/bitcoin/pull/19849 08:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:14 < gleb> To act when the timeout is too close. Go to a miner, or use other software, or whatelse 08:15 < sipa> i don't see what else you can do 08:15 < ariard> sipa: if I understand your point correctly we can deterministically guarantee propagation it's more a probabilistic issue 08:15 < ariard> *we can't 08:16 < gleb> I'm not even sure about probabilistic, facing an incentivised attacker. 08:16 < instagibbs> of course you can't, otherwise we wouldn't need PoW 08:16 < sipa> indeed 08:17 < sipa> so we should look at what features are useful for common cases in higher-level protocols, and to what extent those can be improved upon 08:17 < gleb> Random idea: a node could probe random nodes in the network to see how many of them knows about a tx. 08:17 < sipa> but if you frame this as "otherwise higher-level protocols are insecure", that's besides the point - if they were before, they'll still be insecure after 08:18 < vasild> if improved from 90% to 95% that is better but still not guaranteed (100%) 08:19 < ariard> I think the changes I'm proposing are more feature-wise than "making better tx relay" 08:20 < aj> sipa: i think it's more "spam prevention should be hard to use as an attack vector to prevent relay" when currently it's fairly easy to use it as an attack vector? (i consider rbf rules as spam prevention, adjust the wording if you disagree i guess) 08:20 < sdaftuar> is there a concrete set of proposed changes to consider? 08:20 < ariard> sipa: what do you understood by "we need better tx relay" ? 08:20 < gleb> I would propose to be more clear that "tx relay is not reliable no matter how much fees you pay"? 08:20 -!- tomatopotato [~tomatopot@s91904426.blix.com] has joined #bitcoin-core-dev 08:21 < ariard> sdaftuar: a) better documentation of policy to avoid someone hitting them for lack of testing b) something like package relay or consorts 08:21 < aj> gleb: there's reliable as in works 99% of the time, and reliable as in it's secure even in the face of a state-level attacker 08:22 < sdaftuar> ariard: i don't know what consorts means, but i don't think "package relay" is sufficiently fleshed out yet, unless there's a proposal i've missed? 08:22 < gleb> aj: "not guaranteed" perhaps. I'm not pushing the exact wording right now :)_ 08:22 < ariard> sdaftuar: but there is a more philosophical question, "what if we tighten a policy rule and someone has built on it being liberal" 08:22 < ariard> lik increasing the mininal transaction size 08:23 < sipa> ariard: basically, my problem is with the word "need" - i don't know that we need anything, but that doesn't mean there can't be improvements 08:23 < sdaftuar> ariard: i agree that is a good question 08:24 < ariard> sipa: right, my wording is bad, it's more how we define clear rules a la BIP 125, and that's it don't make assumptions outside 08:25 < ariard> AFAIK, BIP 125 is the only standard on a mempool policy aiming to offer an interface usable by wallets/applications? 08:25 < sdaftuar> i think it's reasonable to ask whether policy changes to Bitcoin Core should always be documented in a BIP so that wallet authors can take those changes into account 08:26 < ariard> sdaftuar: voila, that's what I've in mind :) 08:26 < ariard> or protocol authors 08:26 < sdaftuar> that was exactly why i had asked for BIP 125 to be drafted in the first place, fwiw 08:26 < sipa> ariard: documenting the relay policy more accurate definitely sounds like a good idea 08:26 < sdaftuar> unfortunately we're starting from a place where none of it (except for bip 125) is documented 08:27 < ariard> sdaftuar: yes like we didn't have a bip for carve-out and some folks are trying to reuse it beyond LN 08:27 < ariard> sadly insecurely 08:28 < jnewbery> I don't think p2p policy belongs in BIPs. https://github.com/bitcoin-core/bitcoin-devwiki/wiki seems like a more appropriate place for it 08:28 < sdaftuar> jnewbery: thanks i was just going to say that it's not clear to me that BIPs are the right place either 08:29 < sdaftuar> on one hand, policy changes may have effects on other software, so a BIP might seem the right place 08:29 < ariard> I agree not necessarily a BIP as far it's documented somewhere 08:29 < luke-jr> strict policy, no, but things that coordinate yes 08:29 < ariard> though we have the example of BIP 125 08:29 < luke-jr> BIP 125 gives meaning to particular sequence values 08:29 < sdaftuar> however there is also a sense that we make implementation-specific changes frequently enough that it woulnd't make sense to always publish things in the BIP repo to reflect them 08:30 < ariard> sdaftuar: I agree that's too heavy to update anytime we change the rejection filter 08:30 < luke-jr> ariard: it's a bug for software to rely on node policies 08:30 < ariard> luke-jr: how do you frame BIP 125, it's a node policy ? 08:31 < luke-jr> ariard: it's not a node policy, it's a definition of sequence values; implementations can honour or ignore the request 08:31 < luke-jr> the latter decision is the policy 08:31 < jnewbery> I feel like we're getting into the semantic weeds here. The important thing is that policy is documented somewhere, not what you call it. 08:32 < luke-jr> (text aside) 08:32 < sdaftuar> jnewbery: i don't think that's exactly true. i think the point luke is making (or at least making me consider harder) is whether there are some aspects of node policy that are different from others 08:32 < jnewbery> and to me, the wiki feels like the obvious place. This is information about Bitcoin Core's policy that is being communicated to external developers 08:33 < luke-jr> stuff external developers should design around, makes sense to have in a BIP; but generally, that should not include most node policy 08:34 < luke-jr> (we can still document policy of course) 08:34 < ariard> luke-jr: okay if I follow your semantic BIP 125 define a request mechanism ; choosing to implement this mechanism is a policy decision 08:34 < luke-jr> ariard: yes, basically 08:34 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 08:34 < ariard> luke-jr: and I agree with you we can't enforce that node operators are effectively deploying this policy 08:35 < sdaftuar> luke-jr: in general, though, external developers are desiging around the policy already 08:35 < luke-jr> sdaftuar: that's a bug in their design IMO 08:35 < ariard> luke-jr: no more we can guarantee that everyone isn't running with blocksonly 08:35 < sdaftuar> and in fact that is the source of this whole discussion 08:35 < luke-jr> and not something we should encourage 08:35 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:36 < ariard> what was the thinking when bloom filters where turn off by default ? 08:37 < ariard> it's this kind of software setting default which encourage/discourage network-wise behaviors? 08:37 < ariard> *were 08:38 < jnewbery> we have one more topic, so I suggest we move on to that soon 08:38 < sipa> ariard: it was turned off because there is an obvious resource usage attack enabled by them (high disk I/O and CPU usage, barely any bandwidth for the attacker), and discussed quite widely before done so 08:38 < sdaftuar> luke-jr: perhaps the right way to think about this is that wallet authors should use their best understanding of what policy rules are deployed on the network to generate transactions that will propagate well, but the bug is in relying on that for security? 08:39 < ariard> security isn't binary, it's more how do you diminish the risk of transactions not propagating well 08:40 < vasild> rely on relay is bad :) 08:40 < sdaftuar> security is also not probabilistic 08:41 < aj> (20min left) 08:41 < jnewbery> thanks aj, let's move on to the next topic 08:41 < ariard> sdaftuar: I think we're going to switch off-topic but it sounds like second layers have somehow to have this probabilistic model 08:41 < jnewbery> #topic Overview of https://github.com/bitcoin/bitcoin/pull/19988 (motivation/design philosphy rather than technical details that can be found in the PR) 08:41 < jnewbery> over to you, sipa 08:41 < sipa> hi! 08:41 < ariard> jnewbery: wait before to switch do people would like to coordinate an IRC meeting with LN devs to talk about those issues ? 08:42 < ariard> or anyone else interested by those propagation issues 08:42 < gleb> ariard: The only common understanding we currently have here seem to be "need more docs". I don't see how talking to LN devs helps here? 08:42 < luke-jr> sdaftuar: wallets should use standards, and node policies ideally will allow standard transactions 08:43 < ariard> gleb: because they have implemented most of the content which could be in those "need more docs" :) 08:44 < jnewbery> ariard: can you co-ordinate your next meeting after this meeting? Let's move on to 19988! 08:44 < gzhao408> woo 19988! 08:44 < ariard> jnewbery: sure let's move on 08:44 < jnewbery> thanks! 08:44 < sipa> hi! 08:45 < sipa> so i recently PR'ed #19988, which is a rebase of 19184 08:45 < gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub 08:45 < sipa> the idea is that our tx fetching logic has really grown over time 08:46 < sipa> with various data structures needed for coordination, and unclear specification of what they actually implement 08:46 < sipa> there are biases in favor/against fetching from certain nodes, but they're all implemented indirectly through random delays and insertions/lookups in maps, that are hard to reason about 08:47 < sipa> so instead, my idea was to create a clear specification of what should be fetched from what, or at least something that can be defined in function of a simple data structure 08:47 < sipa> and then have one class that encapsulates a very efficient implementation of that 08:48 < sipa> 19988 does that 08:49 < sipa> to test that, i wrote a fuzz tester which contains a naive reimplementation with the exact same behavior, and which tries to find sequences of operations that makes them diverge 08:50 < sipa> (which, it turns out, found a lot of them... but all within ~minutes - it has now run for several weeks altogether...) 08:51 < vasild> what does it mean if the naive implementation differs from the real one? 08:51 < instagibbs> sorry naive version of what? 08:51 < jnewbery> vasild: probably that there's a bug in the real one :) 08:51 < instagibbs> like, legacy logic, vs, your encapsulation, vs another implementation? 08:51 < vasild> jnewbery: or in the naive one :) 08:52 < sipa> instagibbs: difference between the efficient boost::multi_index based implementation, and the naive one in the fuzzer 08:52 < instagibbs> ah! 08:52 < sdaftuar> concept ACK from me... feature freeze is oct 15, do people have thoughts on getting this in for 0.21? 08:52 < instagibbs> naive efficiency-wise 08:52 < instagibbs> sdaftuar, don't mean to touch the third rail, but taproot implementation? 08:53 < instagibbs> I guess that doesn't intersect aside from PR author 08:53 < jnewbery> instagibbs: taproot wouldn't be merged before 0.21, so I think this is the priority 08:53 < jnewbery> (in terms of sequencing) 08:53 < sdaftuar> yeah i don't know what one has to do with the other, i'd just like to make our review time be efficient 08:53 < instagibbs> jnewbery, mmmm ok I guess I hadn't heard that decision 08:54 < instagibbs> sdaftuar, same author means limited reaction bandwidth, just noting 08:54 < sipa> i was hoping for both :) 08:54 < jnewbery> This is +2000/-450 LOC, so reviewing and being comfortable to merge in three weeks seems ... ambitious 08:54 < instagibbs> it's not new code. 08:55 < sipa> jnewbery: most is in tests 08:55 < sipa> (but the non-test code is quite hairy, i admit) 08:55 < instagibbs> vast majority of changes were test changes recnetly 08:55 < sipa> i'd encourage reviewers to really look at the fuzz test first - even ignoring the fuzzing aspect, the naive reimplementation probably gives a pretty good idea of what the thing *should* do 08:56 < instagibbs> (sorry, stopping) 08:56 < ajonas> I'd be happy to try some organized nagging if people want to give it a shot to get this in 08:56 < instagibbs> concept ACK the actual topic 08:57 < jnewbery> it might be better to wait until after 0.21 to merge, so that it has more soak time before being in a release? 08:57 < jnewbery> it's not like ADDRv2, where we have some external dependency driving deadlines (torv2 deprecation) 08:58 < ajonas> with two min to go can we check in on those 0.21 priorities? 08:58 < sipa> well, it depends on reviewer time of coursew 08:58 < aj> seems like putting it in early in a cycle would make backporting other p2p things (ie from 0.22pre to 0.21) harder, and there's some reasonable soak time between feature freeze and rc? 08:59 < sipa> aj: yeah 08:59 < sdaftuar> release date is december 3 right now 08:59 < sdaftuar> so that is a fair point 08:59 < sdaftuar> (estimated i guess) 08:59 < jnewbery> one minute left! 08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:59 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #19994: Assert that RPCArg names are equal to CRPCCommand ones (net, rpcwallet) (master...2009-rpcAssertNames) https://github.com/bitcoin/bitcoin/pull/19994 08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:00 -!- proofofkeags [~proofofke@174-29-30-112.hlrn.qwest.net] has joined #bitcoin-core-dev 09:00 < ajonas> The other two priorities mentioned were: 09:00 < ajonas> - ADDRv2 - #19031 (next in sequence is 19845, which is close) 09:00 < ajonas> - outbound & block-relay-only connections in functional tests (#19315) 09:00 < gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub 09:00 < jnewbery> #endmeeting 09:00 < gribble> https://github.com/bitcoin/bitcoin/issues/19315 | [tests] Allow outbound & block-relay-only connections in functional tests. by amitiuttarwar · Pull Request #19315 · bitcoin/bitcoin · GitHub 09:00 < lightningbot> Meeting ended Tue Sep 22 16:00:25 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 09:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-22-15.00.html 09:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-22-15.00.txt 09:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-22-15.00.log.html 09:00 < instagibbs> sdaftuar, which is a good point? there was a flurry of convo there 09:01 < sdaftuar> oh i meant that feature freeze -> release was a good bit more time than i had initially realized at least 09:01 < instagibbs> ah, +1 09:01 < sdaftuar> i guess you'd think i'd remember these things by now, oops 09:02 < aj> sdaftuar: why remember anything you can lookup? bandwidth is cheap 09:02 < sipa> aj: latency hit, though 09:06 < aj> sipa: just do it while configure is running and it's fine 09:08 -!- IGHOR [~quassel@176.121.4.135] has quit [Quit: No Ping reply in 180 seconds.] 09:11 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev 09:25 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds] 09:25 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-dev 09:38 < sipa> bizarre discovery: memcmp in some GCC9 and GCC10 versions are broken, if passed a constant array input that starts with a 0 byte 09:39 < sipa> discovered here https://github.com/bitcoin-core/secp256k1/pull/822, bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 09:39 < sipa> which is fixed in GCC 10.2 09:39 < sipa> i suspect some of bitcoin core's unit tests may be affected too 09:40 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 09:40 < sdaftuar> whoa 09:40 < sipa> i don't immediately see any other uses that would be affected 09:41 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 09:43 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev 09:44 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev 09:44 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 09:48 < roconnor> Not fixed in GCC 10.2. Fixed in master. 09:49 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 09:52 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-dev 09:52 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 09:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 09:53 < sipa> roconnor: oh yes, i misread the report 09:53 < sipa> i confirm the bug exists in the 10.0.1 that's in ubuntu' 09:53 < sipa> i can't reproduce it with gcc 9.3 09:56 < sipa> i also see the problem with std::lexicographical_compare in C++ 09:56 < roconnor> weird, I have trouble with gcc 9.3. 09:57 < roconnor> Are you using -O2? 09:58 < sipa> huh, in C++ i also see it with 9.3 09:58 < sipa> but not in C 09:58 < sipa> yes, using -O2 10:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev 10:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds] 10:30 < jonatack> Sorry for missing the p2p meeting. The implementations of addrv2, taproot, and PR19988 are probably the top 3 priorities to review for me. 10:40 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 10:40 -!- Kiminuo [~mix@141.98.103.148] has joined #bitcoin-core-dev 10:40 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 10:41 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 10:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:47 < bitcoin-git> [bitcoin] practicalswift opened pull request #19995: log: Mitigate disk filling attacks by rate limiting LogPrintf(…) (master...mitigate-log-disk-filling-attacks) https://github.com/bitcoin/bitcoin/pull/19995 10:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:55 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 10:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 11:00 -!- tomatopotato [~tomatopot@s91904426.blix.com] has quit [] 11:00 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds] 11:22 -!- kcomandich1 [~kcomandic@84.39.117.57] has joined #bitcoin-core-dev 11:37 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 11:39 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 11:43 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 11:46 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 11:47 -!- Seaver [49464d4f@c-73-70-77-79.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:14 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:16 -!- Seaver [49464d4f@c-73-70-77-79.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 12:24 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] 12:24 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 12:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev 13:03 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev 13:15 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer] 13:16 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 13:32 -!- MrPaz [~paz@24.14.251.223] has joined #bitcoin-core-dev 13:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:37 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d692d192cda3...c7eb85d00593 13:37 < bitcoin-git> bitcoin/master f07fb5a fanquake: build: patch qt libpng to fix powerpc build 13:37 < bitcoin-git> bitcoin/master c7eb85d MarcoFalke: Merge #19959: build: patch qt libpng to fix powerpc build 13:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:37 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19959: build: patch qt libpng to fix powerpc build (master...powerpc_libpng_qt) https://github.com/bitcoin/bitcoin/pull/19959 13:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:44 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 13:44 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 13:46 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:46 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7eb85d00593...b1291b2e8fc3 13:46 < bitcoin-git> bitcoin/master e153448 t-bast: Clarify blocksonly whitelistforcerelay test 13:46 < bitcoin-git> bitcoin/master b1291b2 MarcoFalke: Merge #19963: Clarify blocksonly whitelistforcerelay test 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:46 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19963: Clarify blocksonly whitelistforcerelay test (master...clarify-whitelist-force-relay-test) https://github.com/bitcoin/bitcoin/pull/19963 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:47 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev 14:00 -!- kcomandich1 [~kcomandic@84.39.117.57] has quit [] 14:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:01 < bitcoin-git> [bitcoin] sipa opened pull request #19997: History for Taproot PR #19953 (master...taproot-history) https://github.com/bitcoin/bitcoin/pull/19997 14:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:08 -!- Kiminuo [~mix@141.98.103.148] has quit [Quit: Leaving] 14:10 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 14:10 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev 14:11 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:17 < bitcoin-git> [bitcoin] hebasto opened pull request #19998: rpc: Add `via_tor` to `getpeerinfo` output (master...200922-istor) https://github.com/bitcoin/bitcoin/pull/19998 14:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:21 -!- gzhao408 is now known as gloriazhao 14:22 -!- Shabbypenguin [~Shabbypen@195.206.169.184] has joined #bitcoin-core-dev 15:04 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-lgebcwdtscmlevxn] has quit [Ping timeout: 240 seconds] 15:04 -!- gloriazhao [uid453516@gateway/web/irccloud.com/x-nlymzppxacrwouot] has quit [Read error: Connection reset by peer] 15:04 -!- gertjaap_ [sid322815@gateway/web/irccloud.com/x-apgijbxtfimtgopk] has quit [Read error: Connection reset by peer] 15:04 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-moqnytbtaisiruva] has quit [Read error: Connection reset by peer] 15:04 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-qcyhrfrvemkspetz] has joined #bitcoin-core-dev 15:04 -!- gloriazhao [uid453516@gateway/web/irccloud.com/x-ffjydwauyyunhkvq] has joined #bitcoin-core-dev 15:04 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-emezvqtpooboqkzz] has quit [Read error: Connection reset by peer] 15:05 -!- gertjaap_ [sid322815@gateway/web/irccloud.com/x-thnklnleujaidjtm] has joined #bitcoin-core-dev 15:05 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ocdalhxrivpycxzh] has joined #bitcoin-core-dev 15:05 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-wnueoswdnvefglqa] has joined #bitcoin-core-dev 15:05 -!- kexkey [~kexkey@89.36.78.166] has quit [Quit: Scaling pentatonically] 15:07 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds] 15:07 -!- kexkey [~kexkey@89.36.78.166] has joined #bitcoin-core-dev 15:09 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 15:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 15:17 -!- marcoagner [~user@bl11-17-219.dsl.telepac.pt] has quit [Ping timeout: 265 seconds] 15:25 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev 15:32 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds] 15:33 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-core-dev 15:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 15:43 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 15:46 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 15:55 -!- kexkey [~kexkey@89.36.78.166] has quit [Quit: Scaling pentatonically] 16:13 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 16:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 16:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:41 < bitcoin-git> [bitcoin] fanquake closed pull request #19751: depends: Split libpng out of Qt (master...depends_libpng) https://github.com/bitcoin/bitcoin/pull/19751 16:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:46 -!- kexkey [~kexkey@89.36.78.166] has joined #bitcoin-core-dev 16:49 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 16:49 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 16:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 16:52 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 16:54 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer] 16:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev 16:54 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 16:57 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 16:57 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 17:00 -!- Shabbypenguin [~Shabbypen@195.206.169.184] has quit [] 17:01 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 258 seconds] 17:03 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 17:05 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 17:06 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Ping timeout: 260 seconds] 17:06 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 17:12 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 17:17 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 17:22 -!- Dantman [~Dantman@178.162.209.171] has joined #bitcoin-core-dev 17:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:30 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 17:30 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev 17:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 17:43 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds] 17:51 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 18:09 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev 18:12 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 18:16 -!- mol_ [~mol@unaffiliated/molly] has left #bitcoin-core-dev ["Leaving"] 18:26 -!- Nebraskka [~Nebraskka@51.83.249.56] has quit [Ping timeout: 260 seconds] 18:27 -!- Nebraskka [~Nebraskka@51.83.249.56] has joined #bitcoin-core-dev 18:45 -!- troygiorshev [~troygiors@172-97-163-5.cpe.distributel.net] has joined #bitcoin-core-dev 19:20 -!- icota[m]1 [icotamatri@gateway/shell/matrix.org/x-sxcivdfavteepvuu] has joined #bitcoin-core-dev 19:21 -!- cncr04s_ [~cncr04s@afxr.net] has joined #bitcoin-core-dev 19:23 -!- cncr04s_ [~cncr04s@afxr.net] has quit [Client Quit] 19:25 -!- cncr04s_ [~cncr04s@afxr.net] has joined #bitcoin-core-dev 19:27 -!- Netsplit *.net <-> *.split quits: paultroon, sethrogers23[m], icota[m], wumpus, cncr04s 19:30 -!- cncr04s_ [~cncr04s@afxr.net] has quit [Quit: See you real soon!] 19:33 -!- Netsplit over, joins: paultroon, wumpus, sethrogers23[m] 19:34 -!- Netsplit over, joins: cncr04s 20:00 -!- Dantman [~Dantman@178.162.209.171] has quit [] 20:10 * troygiorshev lurks waiting for someone to open PR #20000 20:10 < gribble> https://github.com/bitcoin/bitcoin/issues/20000 | HTTP Error 404: Not Found 20:20 -!- larsan [~larsan@84.39.117.57] has joined #bitcoin-core-dev 20:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:13 -!- flag [~flag@net-37-119-159-237.cust.vodafonedsl.it] has quit [Quit: leaving] 21:19 -!- flag [~flag@net-47-53-205-124.cust.vodafonedsl.it] has joined #bitcoin-core-dev 21:27 -!- troygiorshev [~troygiors@172-97-163-5.cpe.distributel.net] has quit [Ping timeout: 272 seconds] 21:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 21:42 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 21:43 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 21:46 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Quit: Leaving] 21:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 22:04 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev 22:17 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 22:17 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 22:34 -!- MrPaz [~paz@24.14.251.223] has quit [Ping timeout: 260 seconds] 22:52 -!- MattMareo [~mattl@131.228.48.68] has joined #bitcoin-core-dev 23:00 -!- larsan [~larsan@84.39.117.57] has quit [] 23:09 -!- MattMareo [~mattl@131.228.48.68] has quit [Quit: WeeChat 2.7.1] 23:21 -!- mrd [~mrd@185.244.214.216] has joined #bitcoin-core-dev 23:30 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 23:42 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has joined #bitcoin-core-dev 23:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:44 < bitcoin-git> [bitcoin] vasild opened pull request #20000: test: fix DecodeBase32 tests (master...fix_base32_tests) https://github.com/bitcoin/bitcoin/pull/20000 23:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:48 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has quit [Ping timeout: 260 seconds] 23:49 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:9966:2e66:e682:ecb1] has joined #bitcoin-core-dev 23:50 -!- jonatack [~jon@37.164.9.222] has joined #bitcoin-core-dev --- Log closed Wed Sep 23 00:00:26 2020