--- Day changed Sun Feb 12 2017 00:00 -!- goksinen [~goksinen@2604:2000:c591:8400:4d4f:f515:1114:c55a] has joined #bitcoin-core-dev 00:01 -!- goksinen_ [~goksinen@2604:2000:c591:8400:5aa:8d98:8d29:1e07] has joined #bitcoin-core-dev 00:03 -!- goksine__ [~goksinen@2604:2000:c591:8400:a823:1217:e092:9681] has joined #bitcoin-core-dev 00:04 -!- dodomojo [~goksinen@2604:2000:c591:8400:89a4:98c9:c071:b242] has quit [Ping timeout: 255 seconds] 00:05 -!- goksinen [~goksinen@2604:2000:c591:8400:4d4f:f515:1114:c55a] has quit [Ping timeout: 255 seconds] 00:06 -!- goksinen_ [~goksinen@2604:2000:c591:8400:5aa:8d98:8d29:1e07] has quit [Ping timeout: 255 seconds] 00:07 -!- goksinen [~goksinen@2604:2000:c591:8400:6851:a81b:bc78:7bfb] has joined #bitcoin-core-dev 00:09 -!- harrymm [~wayne@191.96.49.84] has quit [Ping timeout: 260 seconds] 00:10 -!- goksine__ [~goksinen@2604:2000:c591:8400:a823:1217:e092:9681] has quit [Ping timeout: 255 seconds] 00:16 -!- goksinen [~goksinen@2604:2000:c591:8400:6851:a81b:bc78:7bfb] has quit [Remote host closed the connection] 00:31 -!- goksinen [~goksinen@2604:2000:c591:8400:e006:a3c3:d713:deaa] has joined #bitcoin-core-dev 00:35 -!- goksinen [~goksinen@2604:2000:c591:8400:e006:a3c3:d713:deaa] has quit [Ping timeout: 255 seconds] 00:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:51 -!- Victor_sueca is now known as VIctorsueca 00:51 -!- VIctorsueca is now known as Victorsueca 00:52 -!- harrymm [~wayne@191.96.49.108] has joined #bitcoin-core-dev 01:38 < bitcoin-git> [bitcoin] 34ro opened pull request #9745: [RPC] Getting confirmations command (master...add-getconfirmations-to-rpc) https://github.com/bitcoin/bitcoin/pull/9745 01:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 02:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:49 -!- zzaj12 [~jazzybee@host-92-5-245-243.as43234.net] has joined #bitcoin-core-dev 02:49 -!- zzaj12 [~jazzybee@host-92-5-245-243.as43234.net] has left #bitcoin-core-dev ["Leaving"] 03:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 04:09 -!- FiveBroDeepBook [~gk.1wm.su@46.148.182.82] has joined #bitcoin-core-dev 04:09 -!- FiveBroDeepBook [~gk.1wm.su@46.148.182.82] has left #bitcoin-core-dev [] 04:20 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 05:18 -!- goksinen [~goksinen@2604:2000:c591:8400:e006:a3c3:d713:deaa] has joined #bitcoin-core-dev 05:23 -!- goksinen [~goksinen@2604:2000:c591:8400:e006:a3c3:d713:deaa] has quit [Ping timeout: 255 seconds] 06:21 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 06:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:48 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 06:49 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 06:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:51 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has joined #bitcoin-core-dev 07:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 07:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 08:14 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Remote host closed the connection] 08:16 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 08:29 -!- FiveBroDeepBook [~gk.1wm.su@2606:f180:1:df:df:121e:9695:caa6] has joined #bitcoin-core-dev 08:29 -!- FiveBroDeepBook [~gk.1wm.su@2606:f180:1:df:df:121e:9695:caa6] has left #bitcoin-core-dev [] 08:37 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 08:48 < bitcoin-git> [bitcoin] kobake opened pull request #9747: Vs2015 (master...vs2015) https://github.com/bitcoin/bitcoin/pull/9747 08:50 < bitcoin-git> [bitcoin] kobake closed pull request #9747: Vs2015 (master...vs2015) https://github.com/bitcoin/bitcoin/pull/9747 09:02 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 09:04 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 09:24 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 09:34 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-qzgqvvgfdgdhknix] has quit [Ping timeout: 255 seconds] 09:36 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has quit [Ping timeout: 245 seconds] 09:36 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] 09:48 -!- str4d [~str4d@host-78-145-19-22.as13285.net] has joined #bitcoin-core-dev 09:57 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 10:04 < arubi> I think I'm building the crediting transaction from script_tests.json wrong. I can pass tests that don't have a checksig in them, but (e.g.) a p2pk test fails with a bad signature. here's an example of both cases: https://paste.fedoraproject.org/555262/92264814/raw/ . the tests describe the crediting tx structure right at the beginning of the script_tests.json file. would appreciate your input. 10:20 < bitcoin-git> [bitcoin] vosa88 opened pull request #9748: config.txt (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9748 10:21 < bitcoin-git> [bitcoin] fanquake closed pull request #9748: config.txt (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9748 10:44 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has joined #bitcoin-core-dev 10:54 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has joined #bitcoin-core-dev 10:55 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has left #bitcoin-core-dev [] 10:56 -!- RealM9 [~androirc@5.254.97.103] has joined #bitcoin-core-dev 10:57 -!- RealM9 [~androirc@5.254.97.103] has quit [Client Quit] 11:09 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-hewqhluqvjqqmjna] has joined #bitcoin-core-dev 11:18 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 11:19 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has joined #bitcoin-core-dev 12:08 < jonasschnelli> sipa: re https://github.com/bitcoin/bitcoin/pull/9743/files ... 12:08 < jonasschnelli> is std::unique_ptr ecc; not equivalent to ecc.reset(new Secp256k1Init()); 12:09 < sipa> jonasschnelli: no 12:09 < jonasschnelli> I know I miss something... but I wonder what 12:09 < sipa> jonasschnelli: a unique_ptr is initialized to nullptr by default 12:09 < jonasschnelli> I stepped it in lldb and got a non nullptr after std::unique_ptr ecc; 12:09 < jonasschnelli> But maybe a -O0 issue? 12:10 < sipa> jonasschnelli: you must be doing something wrong :) 12:10 < jonasschnelli> heh.. okay. I see the point now. 12:12 < jonasschnelli> Ah. Yes. __first_ = 0x0000000000000000 12:12 < jonasschnelli> The question then remains, how could this have worked before your PR. :) 12:43 < sipa> because the secp library does right now not actually need a check the ctx pointer ther 12:43 < sipa> but it declares that argument is required to be nonnull 12:44 < sipa> so with sanitizers on, that's enforced at runtime 12:45 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 12:48 -!- handlex [~handlex@2804:14c:658f:4dc7:e09d:cf2d:98af:9f2d] has joined #bitcoin-core-dev 12:48 -!- handlex [~handlex@2804:14c:658f:4dc7:e09d:cf2d:98af:9f2d] has quit [Client Quit] 12:48 -!- handlex [~handlex@2804:14c:658f:4dc7:e09d:cf2d:98af:9f2d] has joined #bitcoin-core-dev 12:50 -!- handlex [~handlex@2804:14c:658f:4dc7:e09d:cf2d:98af:9f2d] has quit [Client Quit] 12:52 -!- handlex [~handlex@179.214.98.122] has joined #bitcoin-core-dev 13:00 -!- handlex [~handlex@179.214.98.122] has quit [Quit: handlex] 13:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 13:02 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] 13:42 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Ping timeout: 255 seconds] 13:45 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 13:53 -!- str4d [~str4d@host-78-145-19-22.as13285.net] has quit [Ping timeout: 240 seconds] 13:57 -!- str4d [~str4d@host-78-145-19-22.as13285.net] has joined #bitcoin-core-dev 14:10 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 14:10 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 14:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 14:28 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 15:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:37 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 15:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:09 < bitcoin-git> [bitcoin] luke-jr opened pull request #9749: If -spkreuse=0, ensure transactions in mempool always have unique scriptPubKeys (master...unique_spk_mempool) https://github.com/bitcoin/bitcoin/pull/9749 16:09 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 16:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 16:35 -!- str4d [~str4d@host-78-145-19-22.as13285.net] has quit [Quit: Leaving] 16:37 -!- AaronvanW [~AaronvanW@105.red-81-33-161.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 16:37 -!- AaronvanW [~AaronvanW@105.red-81-33-161.dynamicip.rima-tde.net] has quit [Changing host] 16:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:46 < gmaxwell> luke-jr: it would be interesting if there were a 1 bit flag in scriptpubkeys that indicated if you wanted to allow reuse or not. 16:50 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 16:50 -!- Giszmo [~leo@ip-253-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 17:29 < luke-jr> gmaxwell: enforcing it consistently would require an ever-growing set, so this is more useful to simply discourage it in general 17:29 < gmaxwell> it would just be "best effort" 17:30 < gmaxwell> e.g. I promise no two in the last N blocks, beyond that, "probablistic" 17:30 < luke-jr> I can't think of any reason to ever intentionally accomidate reuse. 17:30 < gmaxwell> widespread practice. 17:31 < gmaxwell> an improvement no one uses is not an improvement. 17:31 < luke-jr> widespread practice needs to change; people enabling this puts pressure on others to stop doing it 17:31 < luke-jr> especially people doing more transaction volume 17:31 < BlueMatt> how? only realistically if its off-by-default, which we cant do, or if miners use it, which they wont 17:32 < sdaftuar> i haven't read this patch carefully, but is there anything to prevent an attacker from interfering with relay by sending a low-fee, low-value transaction to an output that he sees, and relaying that ahead of the original tx? 17:32 < gmaxwell> and what if the net effect is just someone standarziding that wallets should notice their scriptpubkey with a dummy push also strapped to it? 17:32 < gmaxwell> oh slick point. 17:32 < luke-jr> sdaftuar: there isn't. perhaps it should use RBF semantics in that case 17:33 < sdaftuar> this seems like a solution looking for a problem imo 17:33 < gmaxwell> well there are problems it would help with. 17:34 < gmaxwell> for example,, if you take some old addresses and spend all the connected coins, people have frequently then sent near dust amounts to them, seemingly with the hope that you'll spend the dust in another transaction and link the outputs. 17:34 < morcos> luke-jr: also to clarify (sorry for not just reading the code), if there are already multiple outputs encumbered by the same scriptpubkey, does this patch prevent spending more than one of them at a time? 17:35 < gmaxwell> no, it's just a creation restriction AFAICT. 17:35 < luke-jr> morcos: it doesn't prevent that. 17:35 < luke-jr> it restricts spending as well, but allows multiple of them in the same tx 17:35 < morcos> ok, the exception in your PR text confused me.. that's good at least! 17:35 < luke-jr> brb 17:35 < morcos> wait... so it does prevent that unless you put them in the same TX???? 17:37 < jcorgan> is there a particular reason bitcoin.conf only allows IP parameters by address and not hostname/dns name, other than "it hasn't been written yet"? 17:37 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection] 17:37 < morcos> for the record, i agree with the basic gist of discouraging address reuse, but i think its crazy to make it an absolute. i've reused (And continue to reuse) addresess many times... its a choice of convenience over.. eh.. maybe some loss of privacy 17:38 < morcos> for instance if your change output is readily discernible already.. 17:38 < gmaxwell> luke-jr: probably more important is that more outputs shouldn't be made to an address once it's been spent from (and ideally wallets would spend from that address all at once) 17:40 < midnightmagic> morcos: Also, loss of privacy for other people who deal with you. 17:40 -!- Giszmo [~leo@ip-253-233.219.201.nextelmovil.cl] has quit [Quit: Leaving.] 17:40 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 17:43 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jlfdsyrfkbmtbmgw] has quit [Quit: Connection closed for inactivity] 17:50 -!- Giszmo [~leo@pc-165-227-45-190.cm.vtr.net] has quit [Remote host closed the connection] 18:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:26 < luke-jr> morcos: it's not absolute; you can wait until the transaction is mined 18:27 < luke-jr> it occurs to me the current PR already breaks RBF, so I need to fix that :/ 18:31 < luke-jr> I suppose it should just treat SPK overlaps as if they shared a conflicting input 18:31 < luke-jr> solve both issues at once 18:32 < morcos> i think it makes no sense at all to have an option that makes it difficult for people to spend previously created outputs 18:32 < morcos> i'd be opposed to that 18:33 < morcos> i mean i'm basically opposed to the option in general.. but if its just an option and it defaults off.. well you have to pick your battles 18:33 < morcos> but if it prevents spending existing outputs.. that seems crazy 18:33 < luke-jr> you can spend them in separate blocks or in the same tx 18:34 < luke-jr> there is no reason anyone should ever have multiple tx in the same block anyway 18:35 < sipa> right, but why would miners enable that setting? 18:35 < sipa> and if miners don't, why would anyone else? 18:36 < sipa> i like the reasons... but it's noneconomical 18:36 < luke-jr> because some miners actually care about Bitcoin 18:36 < morcos> honestly i think this is the kind of change that should go into something like Knots 18:38 < luke-jr> I don't like the direction Core is changing to where everything must be exclusively economic incentives. Bitcoin can't work with mere economic incentives as things are today. The way things are heading, Core is no longer a reference implementation, but a specific political agenda to the exclusion of others. 18:39 < sipa> luke-jr: the only criteria for non-miner mempools is the expectancy of what will confirm 18:39 < sipa> for miners, i would argue that any non-economical property is a push for a certain policy 18:39 < sipa> the economical one is that i expect everyone to take eventually 18:40 < luke-jr> sipa: I see it more of that non-miner mempools constrain miners, by creating slower propagation of blocks that don't match the wider network policies. 18:40 < luke-jr> sipa: economical is also a certain policy. options are options. 18:40 < sipa> luke-jr: divergence between non-miners and miners just encourages people to submit directly to miners, and miners to be reachable (and thus non-anonymous) 18:41 < sipa> i think that's a far worse outcome than just rational policies 18:41 < luke-jr> lack of divergence creates centralisation pressures forcing miners to all run the same policy dictated by developers 18:41 < morcos> i would argue that a minimum bar for an option is that at least the majority of Core developers think its a good idea OR a good fraction of the user community think its a good idea 18:41 < morcos> we can't support every fringe option 18:42 < sipa> luke-jr: my assumption is that if we'd introduce non-economical policies, and they're configurable they'd be turned off, and if they're not configurable someone will create a patch to change them 18:43 < sipa> by the vast majority of miners 18:43 < morcos> i also dislike the use of policy as something that tries to constrain users to use bitcoin in a certain way.. if its not necessary for DoS prevention or resource allocation, then good usage policies/options should be at the wallet level 18:44 < morcos> relay and mining should be essentially blind to any attribute of txs other than resource usage (which is unfortunately a multi-dimensional beast) 18:44 < luke-jr> I don't see many miners turning on acceptnonstdtxn. Or enabling full RBF (although some do exist). Miners do care to an extent, and that will hopefully improve as difficulty kills profits. 18:45 < luke-jr> morcos: that is not a sustainable view, at least as things are today. but more importantly, I concede your right to take that position, but you need to understand not everyone agrees with it. 18:46 < sipa> luke-jr: ok, i'll reformulate: my expectation is that over time we'll converge to more rational relay policies... not because developers force it, but because it's the most economical thing to do 18:46 < luke-jr> economical != rational 18:46 < sipa> short-term vs long-term? 18:46 < luke-jr> perhaps 18:47 < luke-jr> it's rational to filter SPK reuse in hopes of improving Bitcoin privacy, for example 18:47 < sipa> the only thing that actually improves privacy IMHO is consensus rules that incentivize it 18:48 < morcos> luke-jr: i'd be much more amenable to that argument if the Core wallet stopped SPK reuse.. having relay be difficult in the even of SPK reuse seems like it risks causing more harm than good 18:48 < luke-jr> neither developers nor miners control consensus rules. but miners do control policy. 18:49 < morcos> luke-jr: right! that's why we need to work towards a bitcoin where there is no policy!! all txs look the same 18:49 < luke-jr> no, policy is important. 18:49 < sipa> yes, let's switch to MimbleWimble. all txs look the same! 18:49 < sipa> luke-jr: in my ideal world, there can't be any policy beyond fees/size, because there is nothing else that distinguishes two transactions 18:50 < luke-jr> sipa: that's not everyone's ideal world. 18:50 < sipa> the fact that you can even say whether two outputs use the same address is a fungibility flaw on itself 18:50 < sipa> the fact that miners have censorship rights at all is a weakness 18:50 < luke-jr> I suppose 18:50 < luke-jr> no, miners are supposed to "censor" spam 18:50 < luke-jr> that's part of how the system works 18:51 < sipa> i agree with you, but only in its "development phase"... which may last a long time 18:51 < luke-jr> ? 18:51 -!- ChatSharp [~ChatSharp@stc.66.70.188.95.dsl.krasnet.ru] has joined #bitcoin-core-dev 18:51 < sipa> everyone should cooperate to make the system as usable as possible while it is not perfect 18:52 < luke-jr> morcos: btw, Core wallet never reuses SPKs 18:52 < sipa> but eventually, it will need to work in a very-close-to-perfectly-rational environment 18:52 < luke-jr> sipa: okay, I think I agree on that. 18:52 < sipa> that doesn't mean that has to happen today 18:53 < luke-jr> IMO Lightning will help take a big step toward that 18:54 < sipa> maybe 18:54 < luke-jr> well, in theory since legit txs will probably drop in blockchain data usage vs spam 18:54 -!- ChatSharp [~ChatSharp@stc.66.70.188.95.dsl.krasnet.ru] has left #bitcoin-core-dev [] 18:54 < luke-jr> hopefully that will increase the feerate of legit use beyond the point where spam is more economic 19:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:06 * luke-jr ponders if a town will ever be named std:: XD 19:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 19:46 -!- wdfwefewvfgew [~gk.1wm.su@2001:590:1405:2e4:2e4:762d:9e59:405b] has joined #bitcoin-core-dev 19:46 -!- wdfwefewvfgew [~gk.1wm.su@2001:590:1405:2e4:2e4:762d:9e59:405b] has left #bitcoin-core-dev [] 20:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 20:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 21:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 21:42 < bitcoin-git> [bitcoin] rohundhar opened pull request #9750: Bloomfilter: parameter variables made constant (master...bloomVar) https://github.com/bitcoin/bitcoin/pull/9750 22:50 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 22:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:12 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ccsrwyotvqjjnqtj] has joined #bitcoin-core-dev 23:29 -!- harrymm [~wayne@191.96.49.108] has quit [Ping timeout: 255 seconds] 23:37 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 23:39 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:43 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 23:44 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 23:52 -!- harrymm [~wayne@191.96.49.7] has joined #bitcoin-core-dev 23:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]