--- Log opened Wed Jan 12 00:00:28 2022 00:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 00:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Ping timeout: 240 seconds] 00:27 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 00:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Ping timeout: 245 seconds] 01:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 01:12 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews 01:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Ping timeout: 240 seconds] 01:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 01:32 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds] 01:53 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 02:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 02:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Ping timeout: 240 seconds] 02:32 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 02:33 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 02:34 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit] 02:35 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 02:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 02:49 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:14 -!- anandn [~anandn@2601:600:a27f:d92d:151d:1f53:302f:b5fe] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Remote host closed the connection] 03:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 03:54 -!- stickies-v_ [~stickies-@host-92-8-99-192.as13285.net] has joined #bitcoin-core-pr-reviews 03:55 -!- stickies-v [~stickies-@81.178.227.161] has quit [Ping timeout: 240 seconds] 03:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 240 seconds] 04:12 -!- stickies-v_ [~stickies-@host-92-8-99-192.as13285.net] has quit [Ping timeout: 256 seconds] 04:14 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has joined #bitcoin-core-pr-reviews 04:27 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 04:31 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 240 seconds] 05:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 05:13 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has quit [Ping timeout: 256 seconds] 05:14 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has joined #bitcoin-core-pr-reviews 05:51 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 05:54 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds] 06:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Remote host closed the connection] 07:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has joined #bitcoin-core-pr-reviews 07:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9817:71a7:f6e9:e856] has quit [Ping timeout: 268 seconds] 07:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 07:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 245 seconds] 08:13 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 08:32 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 08:37 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 245 seconds] 08:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 08:44 -!- tim1 [~tim@c-73-217-34-231.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews 08:45 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 08:51 -!- greypw254 [~greypw2@grey.pw] has quit [Quit: I'll be back!] 08:52 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews 08:53 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 256 seconds] 08:58 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has joined #bitcoin-core-pr-reviews 08:58 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has quit [Client Quit] 08:58 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews 08:59 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has joined #bitcoin-core-pr-reviews 09:00 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 09:00 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:00 < lightlike> #startmeeting 09:00 < lightlike> Hi! 09:00 < emzy> hi 09:00 < stickies-v> hi 09:00 < tarun> hi 09:00 < svav> Hi 09:01 < tim1> hi 09:01 -!- kouloumos [~kouloumos@62-10-208.netrun.cytanet.com.cy] has joined #bitcoin-core-pr-reviews 09:01 < effexzi> Hi 09:01 < kouloumos> hi 09:01 < larryruane> hi 09:01 < sipa> hi 09:01 < b10c> hi 09:01 < lightlike> Welcome to PR Review Club - today's session is about PR 20726 - Add DISABLETX message for negotiating block-relay-only connections 09:01 < lightlike> https://github.com/bitcoin/bitcoin/pull/20726 09:01 < lightlike> Before we start, is anybody here for the first time? 09:01 < michaelfolkson> hi 09:02 < glozow> hi 09:02 -!- Azor [~Azor@201.211.83.147] has joined #bitcoin-core-pr-reviews 09:03 < lightlike> Seems to be not the case - who had the chance to review this week's PR (y/n)? 09:03 < stickies-v> 0.5y 09:03 < tarun> y 09:03 < emzy> n 09:03 < larryruane> 0.5 09:03 < sipa> y, a long time ago 09:04 < michaelfolkson> 0.5y 09:04 < jnewbery> hi 09:04 < lightlike> cool - and what was your initial impression? 09:04 -!- greypw254 [~greypw2@grey.pw] has quit [Quit: I'll be back!] 09:05 < stickies-v> seems very sensible, but also that I think it maybe would've been nice to have fRelay be more expressive as an integer so we could capture more states, including the one expressed by disabletx 09:05 -!- oreid52 [~oreid52@host109-155-151-97.range109-155.btcentralplus.com] has joined #bitcoin-core-pr-reviews 09:05 < stickies-v> (but that's always easy in hindsight) 09:06 < tarun> I have perhaps a background question--is block only an all or nothing approach--that a node is block only for all its outbound connections? 09:07 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews 09:07 < glozow> it always seemed like a bit of a hack to be using fRelay to control tx relay, since it's a bloom filter-related field 09:07 < sipa> A node can run in blockonly mode, where it just doesn't ask for individual transactions from peers at all. 09:07 < sipa> That's different from block-relay-only connections, which are on a per-connection basis. 09:08 < lightlike> yes, it sounds very similar, but is a different thing 09:08 < tarun> ok-that distinction is helpful-thanks 09:08 < lightlike> ok - let's move to the first question: 09:08 < michaelfolkson> tarun: If I understand your question the answer is no. A node may be block only for some of its peers and a normal peer for other of its peers 09:08 < lightlike> What are the benefits of introducing the disabletx message? What are the downsides, if any? 09:08 < glozow> that's perhaps the most-asked question in pr review club 09:08 < sipa> michaelfolkson: Then it's not blockonly. Blockonly means it has no mempool at all. 09:09 < larryruane> from the review club notes, "... and don’t have any logic attached to it" -- can someone elaborate on what that means? 09:09 < stickies-v> I think the benefit is mostly altruistic, in that your peer can optimize their local state to not have to prepare for sending you transactions in the future (e.g. keeping sketches with erlay) 09:09 < sipa> The purpose of blockonly mode is different from the purpose of block-relay-only peers. 09:09 < glozow> sipa: has mempool, but ignores incoming transactions that aren't from whitelisted peers, no? 09:09 < stickies-v> But there's also a small selfish benefit, in that you'd not have to receive other messages (e.g. ADDR) anymore after sending DISABLETX, so less bandwidth usage 09:10 < lightlike> stickies-v: yes to both! 09:10 -!- jb55 [~jb55@user/jb55] has joined #bitcoin-core-pr-reviews 09:10 < sipa> glozow: Fair, with whitelisted peers that forcibly give you transactions you could still have a mempool (though that's kind of weird)... the point of blockonly mode is just reducing bandwidth because you don't care about having a mempool. 09:10 < michaelfolkson> Blockonly versus block-relay-only oof. Ok that is a distinction I wasn't making 09:11 -!- justthefirsttime [~justthefi@ipb21a7e59.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews 09:12 < sipa> stickies-v: Is erlay that related? If erlay isn't negotiated with a peer, no sketches have to be kept for it, whether it's disabletx or not. 09:12 < lightlike> yes, every default-configured node today has 2 block-relay-only connections, so it's probably much more common than "-blocksonly" mode. 09:12 -!- baffler [~baffler@69-153-6-185.lightspeed.lsvlky.sbcglobal.net] has joined #bitcoin-core-pr-reviews 09:12 < larryruane> Is it counterintuitive naming for DISABLETX to control addr messages? 09:13 < stickies-v> sipa ah yes, good point. Then I'm not sure what other local optimizations could currently be made by knowing that you won't have to send transactions in the future? Are there any? 09:13 < sipa> Yes, all other tx related data structures (e.g. the set of recently announced transactions for deduplication etc). 09:14 < sipa> (if that's still the case; I saw something about doing that lazily) 09:14 < sipa> My understanding may be a bit outdated. 09:14 < stickies-v> That's compact block related, right? Anticipating which tx's your peer would already have in mempool as to know what to include in blocks you send along? 09:14 < michaelfolkson> To go from a block-relay-only peer to a normal peer requires a disconnection and new handshake? 09:14 -!- dumeril[m] [~dumerilma@2001:470:69fc:105::1:6806] has joined #bitcoin-core-pr-reviews 09:15 < glozow> not compact block related, but not announcing something that your peer already announced 09:15 < jnewbery> stickies-v: anything in the TxRelay struct in https://github.com/bitcoin/bitcoin/pull/22778/files can be omitted if transactions don't need to be relayed over the connection 09:15 < lightlike> yes, there is the TxRelay struct in net.h with different objects (notable a bloom filter) that is not needed on a block-relay-only connection 09:16 < sipa> I think the rationale is mostly knowing that a connection will never need these datastructures, which could help with e.g. deciding how many connections can be supported given local resource constraints. 09:16 < lightlike> michaelfolkson: yes, that is not something that can be changed during a connection 09:17 < lightlike> Any downsides to the new message? 09:17 < jnewbery> the biggest saving is the rolling bloom filter m_tx_inventory_known_filter which is >500k per connection 09:17 < michaelfolkson> I just wonder if you have a reliable block-relay-only peer and you're struggling for peers maybe you'd want to transition them to be a normal peer 09:17 < stickies-v> thx, I hadn't looked at TxRelay yet, will look into it a bit more. I'd assumed the bloom filter related stuff could already be optimized just based on fRelay, though 09:17 < jnewbery> stickies-v: you're right, and that's what #22778 does, although it needs rebase and comments addressed 09:17 < glozow> bloom filter m_tx_inventory_known_filter is distinct from BIP37 bloom filters fyi 09:18 < glozow> oh, facepalm, i misread the message, ignore me 09:18 < jnewbery> glozow: right, it's a rolling bloom filter, which is the same data structure we use for various purposes in p2p 09:19 < michaelfolkson> Maybe clutching at straws but is it a downside telling your peers what you want from them explicitly a bit of a privacy leak. I'm thinking that is a bit of a push 09:19 < sipa> You're already telling them you don't want transactions from them. 09:19 < sipa> DISABLETX is telling them you'll never want transactions from them. 09:21 < lightlike> I wonder if having a separate protocol message for each boolean of information you want to exchange during feature negotiation is ideal design in the long run - it could lead to a zoo of messages over time that might be hard to keep track with 09:21 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has joined #bitcoin-core-pr-reviews 09:21 < sipa> There aren't that many pieces of information to be negotiated really... transactions, blocks, and ip addresses. 09:22 < sipa> I guess headers is another one. 09:22 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has quit [Client Quit] 09:23 < lightlike> yes, currently the boolen-like messages are WTXIDRELAY, SENDADDRV2 and SENDHEADERS afaik, but there is probably potential for growth 09:23 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has joined #bitcoin-core-pr-reviews 09:23 < sipa> lightlike: If we had perfect foresight about what we'd ever want the protocol to be, I'm sure something cleaner/more efficient could be chosen, but the "new protocol version number to add support for X; new message to negotiate the feature" has proven pretty flexible so far. 09:23 < sipa> Don't forget that most P2P connections are pretty long-lived (hours to days/weeks or more even), so a few messages back and forth once at the start isn't a huge cost. 09:23 < sipa> https://www.dsn.kastel.kit.edu/bitcoin/ for numbers. 09:24 < lightlike> next question: 09:24 < lightlike> When a node makes an outgoing block-relay-only connection, it will send a disabletx message after this PR. Will there be other changes in behavior for the sender beyond this (if yes, which ones)? 09:24 < jnewbery> lightlike: I share that concern. I think it's tractable now, but it gets more complex as the number of features increases and there are features that can only be negotiated if other features have already been enabled (eg erlay requires wtxidrelay). 09:25 -!- RandyMcMillan [~RandyMcMi@47.205.11.3] has joined #bitcoin-core-pr-reviews 09:25 < lightlike> sipa: yes, true. I'm not sure if the protocol would be more simple if these weren't separate messages but bits in one message containing a bitfield or something like this. 09:28 < stickies-v> lightlike I don't think it's implemented in this PR yet, but my understanding is that in follow up PRs the sender of DISABLETX would also have to stop sending other messages like ADDR in order not to be disconnected? 09:29 < stickies-v> or is that logic implemented already? 09:29 < lightlike> stickies-v: actually, that won't be necessary, we'll get to that in a later question. addr relay works well together with this PR and BIP338 "out of the box" 09:30 < sipa> The BIP only states that it is recommended not to send ADDR/... messages to DISABLETX peers, but without any hard rule. 09:30 < lightlike> but yes, there are no other changes in behavior for the *sender*. 09:31 < lightlike> moving to the receiver: 09:31 -!- Azor [~Azor@201.211.83.147] has quit [Quit: Ping timeout (120 seconds)] 09:31 < lightlike> When a node receives both fRelay=false and a disabletx message from an incoming peer, will it behave differently after this PR? If yes, how? 09:31 < Kaizen_K_> it wont send any transactions to that incoming peer? 09:32 < stickies-v> It will disconnect such peers that send now invalid messages like GETDATA 09:33 < lightlike> Kaizen_K_: not sending transaction is something it would already be done before, just using the old "fRelay=false" information, so it's not changed with this PR. 09:33 < Kaizen_K_> ty 09:33 -!- Azor [~Azor@201.211.83.147] has joined #bitcoin-core-pr-reviews 09:33 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has quit [Quit: Connection closed] 09:34 < lightlike> stickies-v: correct! If you first send a disabletx message and then don't follow the BIP by following up with tx-related messages, you'll get disconnected. 09:35 < lightlike> note that the part where the receiver doesn't initialize the TxRelay objects is not part of this PR, it would probably make sense as a follow-up PR. 09:36 < michaelfolkson> So a possible downside to this DISABLETX approach is it formalizes the relationship as a block relay only and to get out of it you need to redo the handshake. Current behavior is a peer can later request to receive transactions again using filterload without redoing the handshake? 09:37 < sipa> Filterload is all but dead. 09:37 < sipa> It requires actively opting in to BIP37 support. 09:38 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has joined #bitcoin-core-pr-reviews 09:38 < michaelfolkson> Ok gotcha, thanks 09:38 < lightlike> I think the old behavior is not disallowed: If you intend to use BIP37, just don't send a disabletx message, and everything works as good (or bad) as before 09:38 < sipa> Indeed. 09:38 -!- daftuar [~daftuar@ool-6c3afc52.static.optonline.net] has quit [Client Quit] 09:38 < lightlike> Next question: 09:39 < lightlike> Earlier discussions in the PR revolved around the interaction of disabletx and address relay. Why is it, after PR #21528, no longer necessary to change any address-relay related code in this PR? 09:40 < Kaizen_K_> I think that peer #21528 filters peers that have no other peers? Is that correct? 09:41 < michaelfolkson> lightlike: Is this the deferring initialization of m_addr_known? 09:41 < lightlike> michaelfolkson: yes, correct! 09:44 < lightlike> It basically changed the way address relay is setup: if you make an outgoing block-relay-connection, you know that you don't want addr related messages, and just don't send any such messages. 09:44 < lightlike> On getting an inbound connection, you'd only start sending addr related address after having received at least one. 09:45 < michaelfolkson> That is a neat side effect of #21528. Presumably it was deliberate with this advantage in mind? 09:45 < lightlike> So, everything plays nice already on a block-relay-only connection, without a need to disable something. 09:45 < Kaizen_K_> Can anyone explain what addr messages are please? Can't find anything on google. 09:45 < stickies-v> https://en.bitcoin.it/wiki/Protocol_documentation#addr 09:45 < lightlike> That's what https://github.com/bitcoin/bitcoin/pull/20726#issuecomment-1006005523 refers to. 09:45 < sipa> Kaizen_K_: They relay IP addresses of other nodes. 09:45 < Kaizen_K_> ty 09:46 -!- sdaftuar1 [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-pr-reviews 09:46 -!- sdaftuar1 is now known as sdaftuar 09:47 < svav> I googled Bitcoin addr message and found this https://en.bitcoin.it/wiki/Protocol_documentation#addr 09:47 < sipa> Also see BIP155, for its successor, ADDRV2. 09:48 < lightlike> there was also a review club meeting on PR 21528 that I forgot to link: https://bitcoincore.reviews/21528 09:48 < lightlike> Next question is more C++-technical: 09:48 < lightlike> The new m_disable_tx field of the Peer struct is of type std::atomic. Why is an std::atomic used here instead of a simple bool, or a bool guarded by a lock? 09:50 < glozow> for thread safety 09:50 < sipa> A bool guarded by a lock would also be thread safe, but much slower on most platforms. 09:50 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 09:51 < glozow> and more code 09:51 < michaelfolkson> When would you use a bool guarded by a lock if it is much slower? :) 09:52 < lightlike> yes, I guess the basic thing is that the "Peer" struct is not guarded by cs_main as a whole, so something needs to be done for each of the members separately 09:52 < sipa> You wouldn't. 09:52 < sipa> But perhaps you need a lock that guards more than just a bool. 09:52 < sipa> An atomic is only usable if you want a guarded data structure that only contains a bool, and nothing more. 09:52 < lightlike> michaelfolkson, sipa: could there be situation where this makes sense because you care about enforcing a lock order? 09:53 < sipa> If lock order is relevant, it means you're not guarding just a bool. 09:53 < larryruane> it seems this boolean is set (to true) from only one thread (message processing), but read from other threads, and locking is needed even in this case 09:54 < sipa> An atomic is equivalent to a bool with a lock that's only held at the innermost level. 09:54 < stickies-v> sipa https://en.cppreference.com/w/cpp/atomic/atomic seems to also be defined on other types than bool? 09:54 < glozow> for every read/write to an atomic_bool, the lock will be taken right before and released right before that operation is over, so you wouldn't be taking multiple locks at a time in different orders? 09:54 -!- oreid52 [~oreid52@host109-155-151-97.range109-155.btcentralplus.com] has quit [Quit: Connection closed] 09:54 < larryruane> can there be `atomic`? we seem to see it only for simple types 09:55 < sipa> stickies-v: Oh, sorry, I didn't mean to imply it just worked for bools. 09:55 < sipa> larryruane: If there was, it'd almost certainly be implemented using a lock :D 09:55 < larryruane> yes, just wondering if it's even allowed by the compilter 09:55 < lightlike> could it be that operations such as setting a bool aren't atomic anyway? Or is this implemenation-specific and we jsut want to be on the safe side? 09:56 < sipa> larryruane: Pet peeve of mine: the compiler is irrelevant. The question you should ask if is if it's permitted by the *language* (and so far, I think the answer is no, but it could be expanded in future language versions of course). 09:56 < willcl_ark> Does a mutex also not get locked and unlocked each with an atomic operation, i.e. 2 atomic operations minimum? 09:57 < sipa> willcl_ark: In practice, yes. 09:57 -!- baffler [~baffler@69-153-6-185.lightspeed.lsvlky.sbcglobal.net] has quit [Quit: Connection closed] 09:58 < lightlike> larryruane: I think that std::atomic is currently limited to just few small, "integer-like" types. I don't think it exists for double, for example. 09:58 < sipa> lightlike: Unguarded concurrent access is undefined behavior. 09:58 < sipa> It might work, it might also send all your BTC in your wallet to me. 09:59 < stickies-v> Now that's an innovative source of dev funding 10:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 10:00 < lightlike> ok, time's up - thanks a lot everyone! 10:00 < sipa> In practice, x86 has a fairly strong consistency model, so it's not unreasonable that the resulting compiled code actually works there (but it certainly might not). On other hardware (non-Mac ARM, in particular) non-atomic operations are pretty likely to kill you. 10:00 < lightlike> #endmeeting 10:00 < Kaizen_Kintsugi_> Thanks everyone! 10:00 < glozow> thanks lightlike! 10:00 < larryruane> thanks lightlike !! 10:00 < tarun> thank you. 10:00 < Kaizen_Kintsugi_> learned a lot today 10:00 < justthefirsttime> thx - for 1st participation 10:00 < stickies-v> Thanks lightlike for hosting! 10:00 < sipa> Thanks! 10:00 < michaelfolkson> Thanks lightlike et al 10:00 < willcl_ark> thanks, sorry I missed the bulk of the meeting! 10:00 < George[m]1> thank you! 10:01 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has quit [Quit: Konversation terminated!] 10:01 -!- Azor [~Azor@201.211.83.147] has quit [Quit: Connection closed] 10:01 < emzy> Thank you! 10:02 < jnewbery> thank you lightlike! 10:02 < svav> Thanks all 10:04 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 10:04 < michaelfolkson> This sounds fun w/ glozow tomorrow on reviewing Bitcoin Core PRs https://twitter.com/ConorOkus/status/1480950589777453058?s=20 10:05 -!- justthefirsttime [~justthefi@ipb21a7e59.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed] 10:05 < glozow> michaelfolkson: that one is going to be very very beginner friendly 10:06 < Kaizen_Kintsugi_> yea I'm headed to that for sure 10:07 < michaelfolkson> Cool 10:15 -!- kouloumos [~kouloumos@62-10-208.netrun.cytanet.com.cy] has quit [Quit: Connection closed] 10:20 -!- Ting_Jun [~Ting_Jun@2603-7000-a701-2362-ff60-c48f-046f-f2e6.res6.spectrum.com] has quit [Quit: Client closed] 10:30 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has quit [Remote host closed the connection] 10:35 -!- Netsplit *.net <-> *.split quits: dumeril[m], hebasto, jnewbery, duderonomy, George[m]1, johnzwen-, jarolrod, jeremyrubin, jonasschnelli_, lightlike, (+82 more, use /NETSPLIT to show all of them) 10:39 -!- Netsplit over, joins: Henry151 10:39 -!- djinni`_ [~djinni@static.38.6.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 10:39 -!- Netsplit over, joins: pink_sarco 10:39 -!- orionwl [~laanwj@user/laanwj] has joined #bitcoin-core-pr-reviews 10:39 -!- takinbo_ [~takinbo@user/takinbo] has joined #bitcoin-core-pr-reviews 10:39 -!- provoostenator_ [~quassel@user/provoostenator] has joined #bitcoin-core-pr-reviews 10:39 -!- Netsplit over, joins: glozow, fanquake 10:39 -!- sandipndev [sandipndev@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews 10:39 -!- sanket_cell [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 10:39 -!- yakshaver123 [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews 10:39 -!- Netsplit over, joins: RubenSomsen, _aj_, michaelfolkson, kanzure, _0x0ff, jeremyrubin, ajonas, ghost43, fjahr, jarolrod (+71 more) 10:41 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection] 10:43 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #bitcoin-core-pr-reviews 10:46 -!- Ting_Jun [~Ting_Jun@2603-7000-a701-2362-9b58-f688-93f3-b954.res6.spectrum.com] has joined #bitcoin-core-pr-reviews 10:53 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 10:57 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 240 seconds] 11:03 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has quit [Remote host closed the connection] 11:07 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 11:26 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 11:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Remote host closed the connection] 12:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 12:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 268 seconds] 12:23 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:25 -!- anandn [~anandn@2601:600:a27f:d92d:6c3b:dc86:41f9:d3cb] has joined #bitcoin-core-pr-reviews 12:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 12:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 250 seconds] 12:38 -!- gwilin [~gwilin@191.91.194.60] has joined #bitcoin-core-pr-reviews 13:02 -!- gwilin [~gwilin@191.91.194.60] has quit [Ping timeout: 256 seconds] 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 240 seconds] 13:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 13:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 268 seconds] 13:20 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 13:32 -!- RandyMcMillan [~RandyMcMi@47.205.11.3] has quit [Quit: Connection closed] 13:41 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection] 13:41 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 13:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 13:54 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 13:58 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 14:02 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 14:15 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 14:19 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 14:20 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds] 14:20 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 14:21 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 14:23 -!- jb55 [~jb55@user/jb55] has joined #bitcoin-core-pr-reviews 14:26 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds] 14:28 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 14:40 -!- gwilin [~gwilin@191.91.194.60] has joined #bitcoin-core-pr-reviews 14:43 -!- gwilin [~gwilin@191.91.194.60] has quit [Client Quit] 15:04 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection] 15:05 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 15:10 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 15:21 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 15:28 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 15:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 250 seconds] 15:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 16:06 -!- anandn [~anandn@2601:600:a27f:d92d:6c3b:dc86:41f9:d3cb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 16:28 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 16:29 -!- anandn [~anandn@98.232.3.180] has joined #bitcoin-core-pr-reviews 16:37 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 16:43 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 16:54 -!- Common [~Common@user/common] has quit [Quit: Leaving] 16:55 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 16:59 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 17:12 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 17:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Remote host closed the connection] 17:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 17:31 -!- anandn [~anandn@98.232.3.180] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Remote host closed the connection] 17:33 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has quit [Ping timeout: 256 seconds] 17:33 -!- stickies-v [~stickies-@81.178.231.129] has joined #bitcoin-core-pr-reviews 17:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 17:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 252 seconds] 17:43 -!- anandn [~anandn@2601:600:a27f:d92d:e83d:324a:8daa:9f9f] has joined #bitcoin-core-pr-reviews 17:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 17:57 -!- anandn [~anandn@2601:600:a27f:d92d:e83d:324a:8daa:9f9f] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:00 -!- evanlinjin [evanlinjin@gateway/vpn/protonvpn/evanlinjin] has quit [Quit: WeeChat 3.3] 18:16 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 18:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 18:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 18:45 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 18:45 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection] 18:45 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 18:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 240 seconds] 18:53 -!- anandn [~anandn@98.232.3.180] has joined #bitcoin-core-pr-reviews 18:55 -!- anandn [~anandn@98.232.3.180] has quit [Client Quit] 18:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 18:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 252 seconds] 19:10 -!- anandn [~anandn@2601:600:a27f:d92d:e83d:324a:8daa:9f9f] has joined #bitcoin-core-pr-reviews 19:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 19:34 -!- anandn [~anandn@2601:600:a27f:d92d:e83d:324a:8daa:9f9f] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:36 -!- Ting_Jun [~Ting_Jun@2603-7000-a701-2362-9b58-f688-93f3-b954.res6.spectrum.com] has quit [Quit: Client closed] 20:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 240 seconds] 20:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 20:33 -!- anandn [~anandn@98.232.3.180] has joined #bitcoin-core-pr-reviews 20:34 -!- anandn [~anandn@98.232.3.180] has quit [Client Quit] 20:36 -!- anandn [~anandn@2601:600:a27f:d92d:a176:1395:81f9:b649] has joined #bitcoin-core-pr-reviews 20:38 -!- anandn [~anandn@2601:600:a27f:d92d:a176:1395:81f9:b649] has quit [Client Quit] 20:50 -!- anandn [~anandn@2601:600:a27f:d92d:a908:fe4a:67d7:11cf] has joined #bitcoin-core-pr-reviews 21:17 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection] 21:18 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 21:23 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 21:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 252 seconds] 21:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 21:57 -!- meshcollider [meshcollid@user/meshcollider] has quit [Ping timeout: 256 seconds] 21:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has joined #bitcoin-core-pr-reviews 22:00 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #bitcoin-core-pr-reviews 22:04 -!- Yihen [~textual@114.113.238.18] has quit [Ping timeout: 256 seconds] 22:13 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 256 seconds] 22:34 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:38 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 22:51 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 22:55 -!- Ting_Jun [~Ting_Jun@2603-7000-a701-2362-9b58-f688-93f3-b954.res6.spectrum.com] has joined #bitcoin-core-pr-reviews 22:55 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 23:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64d3:5ec4:6df9:8177] has quit [Ping timeout: 252 seconds] 23:03 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 23:08 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 23:12 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 23:25 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 23:32 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 23:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 23:46 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 23:49 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds] 23:49 -!- lukedashjr is now known as luke-jr --- Log closed Thu Jan 13 00:00:17 2022