--- Log opened Mon Aug 27 00:00:51 2018
00:06 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
00:21 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has quit [Read error: Connection reset by peer]
00:22 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has joined #bitcoin-core-dev
00:34 -!- vindard [~vindard@96.9.90.105] has joined #bitcoin-core-dev
00:40 -!- vindard [~vindard@96.9.90.105] has left #bitcoin-core-dev ["Leaving"]
01:30 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:45 -!- Zenton [~user@195.235.96.150] has joined #bitcoin-core-dev
01:48 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
01:54 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:56 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection]
02:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nuqnzkarppouhqwa] has joined #bitcoin-core-dev
02:05 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
02:05 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
02:11 -!- Zenton [~user@195.235.96.150] has quit [Changing host]
02:11 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
02:11 -!- Zenton is now known as vicenteH
02:12 -!- vicenteH is now known as Zenton
02:14 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
02:17 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
02:18 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
02:30 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has quit [Read error: Connection reset by peer]
02:30 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
02:31 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has joined #bitcoin-core-dev
02:37 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Remote host closed the connection]
02:37 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
02:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
02:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
02:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
02:47 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
03:08 < sdaftuar> luke-jr: thanks for diving into the mmap leveldb issue. i was also confused about how those limits interact and was doing some measurements of mmap usage.
03:09 < sdaftuar> with txindex off it looked like i'd never get more than 1000 mmaps, but with it on i'd get up to 2000
03:11 < sdaftuar> one thing i was curious about was whether we have a good handle on the maximum number of non-mmap'ed files
03:11 -!- ken2812221_ [~ken281222@118-160-144-34.dynamic-ip.hinet.net] has quit [Ping timeout: 244 seconds]
03:13 < sdaftuar> to make sure there's not some remotely-triggerable leveldb behavior where we end up opening 1000 fd's and breaking select()
03:19 < luke-jr> sdaftuar: looks like we'd be safe doing something like (4096 - 1) / (2 + txindex?1:0) for the file limit
03:19 < luke-jr> (4096 only with the patched mmap limit ofc)
03:19 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:19 < luke-jr> in theory, we could probably burn fds on top of mmaps, but that might hurt performance more than it's worth
03:19 < luke-jr> (since we know 64 * 3 was safe)
03:20 -!- vexbuy_ [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:23 -!- ken2812221_ [~ken281222@118-160-144-34.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
03:24 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Ping timeout: 244 seconds]
03:30 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:33 -!- vexbuy_ [~vexbuy@46.166.142.215] has quit [Ping timeout: 272 seconds]
03:34 -!- vexbuy_ [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:38 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Ping timeout: 276 seconds]
03:39 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:41 -!- vexbuy_ [~vexbuy@46.166.142.215] has quit [Ping timeout: 252 seconds]
03:48 -!- vexbuy_ [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:51 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Ping timeout: 276 seconds]
03:53 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
03:56 -!- vexbuy_ [~vexbuy@46.166.142.215] has quit [Ping timeout: 268 seconds]
04:01 -!- vexbuy_ [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
04:05 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Ping timeout: 264 seconds]
04:06 -!- vexbuy [~vexbuy@46.166.142.215] has joined #bitcoin-core-dev
04:08 -!- vexbuy [~vexbuy@46.166.142.215] has quit [Remote host closed the connection]
04:09 -!- vexbuy_ [~vexbuy@46.166.142.215] has quit [Ping timeout: 272 seconds]
04:13 -!- chainhead [~chainhead@2001:19f0:5:e14:5400:ff:fe77:e3d4] has quit [Ping timeout: 264 seconds]
04:13 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
04:15 -!- ken2812221_ [~ken281222@118-160-144-34.dynamic-ip.hinet.net] has quit [Ping timeout: 252 seconds]
04:23 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev
04:25 -!- zivl [~zivl@2601:19a:837f:e4e1:c9ba:4a07:cd88:b9ae] has quit [Read error: Connection reset by peer]
04:26 -!- zivl [~zivl@2601:19a:837f:e4e1:911f:a12e:c6a1:c0d7] has joined #bitcoin-core-dev
04:36 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has quit [Read error: Connection reset by peer]
04:37 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has joined #bitcoin-core-dev
04:38 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
05:03 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
05:04 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 276 seconds]
05:08 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
05:32 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 276 seconds]
05:38 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev
05:42 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
05:44 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
05:44 -!- itaseski [~itaseski@213.135.176.114] has joined #bitcoin-core-dev
06:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:08 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 268 seconds]
06:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
06:27 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
06:33 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has quit [Read error: Connection reset by peer]
06:33 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has joined #bitcoin-core-dev
06:36 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:36 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:41 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds]
06:42 -!- promag [~promag@119.70.114.89.rev.vodafone.pt] has joined #bitcoin-core-dev
06:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]
06:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds]
06:45 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
06:45 -!- marcinja [~marcin@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:47 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
06:53 -!- Giszmo [~leo@45.232.32.114] has joined #bitcoin-core-dev
06:54 -!- Giszmo [~leo@45.232.32.114] has quit [Client Quit]
06:57 < jnewbery> Review beg for #14023. It's not urgent, but it requires frequent rebase and it should be a very easy, mechanical review.
06:57 < gribble> https://github.com/bitcoin/bitcoin/issues/14023 | Remove accounts rpcs by jnewbery · Pull Request #14023 · bitcoin/bitcoin · GitHub
06:58 < jnewbery> It'd be nice to get a critical number of people review it once than have lots of re-ACKs as it gets rebased
06:58 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:58 < jnewbery> wumpus: not sure if it makes the bar for high priority, but if you think it does, please add it :)
07:01 < wumpus> jnewbery: sure, added!
07:05 -!- phwalkr [~phwalkr@2001:1284:f01c:5d1e:20ea:a833:ca3b:f629] has joined #bitcoin-core-dev
07:10 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev
07:11 -!- atroxes_ [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev
07:12 -!- setpill [~setpill@unaffiliated/setpill] has quit [Ping timeout: 252 seconds]
07:12 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 272 seconds]
07:12 -!- atroxes_ is now known as atroxes
07:13 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]
07:14 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
07:22 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
07:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
07:28 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
07:32 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 268 seconds]
07:32 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
07:40 < jnewbery> thanks!
07:57 -!- a5m0_ [~a5m0@unaffiliated/a5m0] has quit [Ping timeout: 240 seconds]
08:00 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit []
08:01 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
08:04 -!- phwalkr [~phwalkr@2001:1284:f01c:5d1e:20ea:a833:ca3b:f629] has quit [Remote host closed the connection]
08:06 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has joined #bitcoin-core-dev
08:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]
08:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:13 -!- rafalcpp_ is now known as rafalcpp
08:15 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
08:26 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds]
08:36 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev
08:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
08:40 -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-core-dev
08:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
08:45 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev
08:48 < jamesob> gmaxwell sipa: so are we thinking at this point that RSS is kind of a useless metric because clean ldb pages will just be pushed out under memory pressure?
08:50 < sipa> jamesob: possibly
08:50 < gmaxwell> jamesob: That is my view.
08:52 < jamesob> do we want to have bitcoinperf count dirty pages as an additional metric?
08:55  * wumpus waves farewell to account API (finally)
08:55 < jnewbery> \o/
08:55 < gmaxwell> jamesob: I think we should.
08:55 < jnewbery> thanks wumpus!
08:55 < sipa> wumpus: it will be bittersweet goodbye
08:56 < sipa> i think i've developed somewhat of a stockholm syndrome with it
08:56 < instagibbs> sipa, be healed
08:56 < wumpus> yes that's what happens :(
08:56 < instagibbs> I spent hours trying to write a sensible comment about balances with accounts in the code; failed. No love lost there.
08:57 < wumpus> it was the same for me for getinfo
08:58 < wumpus> but it just had to happen, after all that time, and I'm happy this particular knot is finally cut
09:00 < jamesob> gmaxwell: so basically we want to poll `pmap -x $(pidof bitcoind) | tail -n 1 | tr -s ' ' | cut -d' ' -f 4` for a max value throughout ibd/reindex
09:03 < gmaxwell> jamesob: I think that is what we want, yes.
09:08 < jnewbery> The PR that was just merged removed the accounts RPCs. There's a bunch of dead code left behind that's removed in #13825. Feel free to review that if you want to help remove all traces of accounts. (non-urgent and I'm happy to keep rebasing)
09:08 < gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub
09:18 < gmaxwell> :(
09:18 < gmaxwell> 14023 was merged without any actual answer to the locked fund issue.
09:22 < sipa> what locked fund issue?
09:22 < sipa> ah
09:23 < sipa> a reference would be useful
09:23 < rockhouse> gmaxwell: Would you say this definition is correct? "CTs don't use homomorphic encryption. They use "additively homomorphic commitments" which are, essentially, cryptographic proofs."
09:25 < gmaxwell> sipa: I don't know if there is an issue on github anywhere. But as I pointed out, in the past people have attached accounts to addresses, gotten funds assigned to accounts, then found themselves unable to use send to address to send funds until they MOVEed the funds back.
09:26 < gmaxwell> rockhouse: They're additively homorphic commitments, but I wouldn't say that the commitments themselves are "cryptographic proofs", they're just commitments. CT also uses cryptographic proofs.
09:26 < rockhouse> thx
09:28 < gmaxwell> I'm sorry I didn't see that jnewbery responded to me (weird, I thought I had looked yesturday too!)
09:29 < sipa> gmaxwell: that's certainly possible with accounts based RPCs... there were some that did balance checks
09:29 < sipa> gmaxwell: but now the whole concept of balances is gone
09:29 < gmaxwell> What PR removed the balance checks?
09:30 < sipa> accounts are gone.
09:30 < sipa> without accounts, there are no more RPCs that do balance checks
09:30 < sipa> because the concept of balance doesn't exist anymore
09:30 < gmaxwell> Okay, what I'm asking is where were the balance checks removed? I looked at 13825 and I didn't see that.
09:31 < sipa> well the account RPCs are gone, no?
09:32 < gmaxwell> My concern is that people assigned funds to labels in the past, then load up one of their wallets in new code. So they don't need accounts rpcs to get in that state, if the backend code still checks balances.
09:33 < sipa> i think we really need to see a report
09:33 < sipa> because the only things that should be doing balance checks is accounts RPCs
09:33 < sipa> even in the past
09:34 < gmaxwell> There are people in my IRC logs reporting issues sending with sendtoaddress then luke telling them to move and then them saying it worked.
09:38 < sipa> that seems like a very serious bug, if true
09:38 < sipa> first time i hear about it, though
09:41 < gmaxwell> "sendtoaddress only subtracts the amount from the default account,"
09:41 < jnewbery> what are you quoting?
09:42 < gmaxwell> IRC logs.
09:42 < gmaxwell> If that changed (or was never the case) OKAY, but I also thought it was the case, and I don't remember a PR changing it.
09:43 < sipa> sendtoaddress subtracts the default account, but doesn't check its balance
09:43 < sipa> it doesn't do anything with accounts at all
09:43 < sipa> as balances are just defined implicitly
09:49 < gmaxwell> it might be the case that the reporters were actually using sendmany, which did check, but which has since had it removed.
09:49 < gmaxwell> I found the PR disabling it in sendmany.
09:52 < sipa> right
09:54 < gmaxwell> and/or people have been uselessly telling people to use move when their real problem was something else.
09:54 < gmaxwell> (like needing to wait for unconfirmed funds to confirm)
09:56 < jnewbery> yes, sendmany would call getLegacyBalance() and earlier getAccountBalance(). senttoaddress has always used getBalance(), which doesn't check accounts/labels at all
09:56 < jnewbery> sendmany now uses getLegacyBalance() without an account argument
09:57 < jnewbery> if 14023 was done right, then none of the RPCs should now know anything about account balances at all
10:06 -!- promag [~promag@119.70.114.89.rev.vodafone.pt] has quit [Remote host closed the connection]
10:22 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:26 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
10:26 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 272 seconds]
10:27 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev
10:30 -!- karelb [uid316741@gateway/web/irccloud.com/x-dmutzicesyqazbok] has quit [Ping timeout: 264 seconds]
10:30 -!- karelb [uid316741@gateway/web/irccloud.com/x-kbrfiexjxgmfemtc] has joined #bitcoin-core-dev
10:40 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 272 seconds]
10:41 < phantomcircuit> so i notice select has a 50ms timeout, that seems kind of short given all it's only purpose is to consume pnode->vSend when the initial attempt failed
10:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
10:58 < gmaxwell> I assume it was made short so that it wouldn't block sending new messages.
11:00 < phantomcircuit> gmaxwell, send() is called on the full buffer before anything is added to pnode->vSend
11:01 -!- Amuza [~amuza@212.230.156.111] has joined #bitcoin-core-dev
11:03 < phantomcircuit> actually wait this is still doing the thing of calling send() for each message
11:06 < gmaxwell> oh we didn't fix the thing where the header and payload go out in seperate packets? :(
11:07 -!- str4d [~str4d@231.191.6.51.dyn.plus.net] has joined #bitcoin-core-dev
11:08 < phantomcircuit> gmaxwell, i think that's fixed i mean sipa changed this in 2013 from the buffer per connection to a list of messages per connection
11:08 < phantomcircuit> and i cant remember why
11:08 < phantomcircuit> doesn't change the optimistic send logic meaningfully though
11:09 < phantomcircuit> so im still wondering about the 50ms timeout
11:09 -!- str4d_ [~str4d@254.196.6.51.dyn.plus.net] has joined #bitcoin-core-dev
11:10 -!- str4d_ [~str4d@254.196.6.51.dyn.plus.net] has quit [Client Quit]
11:10 -!- hebasto [~hebasto@195.60.70.234] has joined #bitcoin-core-dev
11:11 -!- str4d_ [~str4d@254.196.6.51.dyn.plus.net] has joined #bitcoin-core-dev
11:12 -!- str4d_ [~str4d@254.196.6.51.dyn.plus.net] has quit [Client Quit]
11:12 -!- str4d [~str4d@231.191.6.51.dyn.plus.net] has quit [Ping timeout: 272 seconds]
11:13 -!- str4d [~str4d@254.196.6.51.dyn.plus.net] has joined #bitcoin-core-dev
11:21 -!- str4d [~str4d@254.196.6.51.dyn.plus.net] has quit [Ping timeout: 272 seconds]
11:33 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]
11:33 -!- str4d [~str4d@254.196.6.51.dyn.plus.net] has joined #bitcoin-core-dev
11:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
11:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
11:44 < jonasschnelli> gmaxwell: I can't follow your comment here: https://github.com/bitcoin/bitcoin/pull/14049#discussion_r213027446
11:45 < jonasschnelli> You mean a 32byte pubkey with missing first byte to test for?
11:53 < gmaxwell> BIP151 sends a 32 byte pubkey, not a 33 byte one. Right?  so a test that gives a junk value to the first byte doesn't actually test any case that could be triggered by BIP151. (though it's fine to test that too)  The test I'm going for is an x value not on the curve, since failing to check that is a common implementation bug in ECDH implementations.
11:54 -!- Krellan [~Krellan@2601:640:4000:9258:6518:5acd:4792:2a87] has quit [Ping timeout: 264 seconds]
11:57 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:57 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
11:57 -!- str4d [~str4d@254.196.6.51.dyn.plus.net] has quit [Ping timeout: 268 seconds]
12:02 -!- Rootsudo [~textual@180.190.116.254] has quit [Ping timeout: 272 seconds]
12:13 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
12:14 -!- harrymm_ [~harrymm@69.161.195.103] has quit [Ping timeout: 244 seconds]
12:15 -!- harrymm_ [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
12:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
12:20 < gmaxwell> jonasschnelli: make sense now?
12:20 < jonasschnelli> Ah. I see! Will fix thanks gmaxwell
12:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
12:25 < jonasschnelli> gmaxwell, sipa: what was the conclusion on the inefficiency of the ChaCha20Poly1305@openssh AEAD?
12:25 < jonasschnelli> (currently benchmarking)
12:26 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 268 seconds]
12:29 < jonasschnelli> CHACHA20POLY1305AEAD_BIG, 5, 340, 3.68279, 0.00215035, 0.00219169, 0.00216025
12:29 < jonasschnelli> CHACHA20POLY1305AEAD_SMALL, 5, 250000, 1.08673, 8.51516e-07, 8.93585e-07, 8.61119e-07
12:29 < jonasschnelli> HASH256_BIG, 5, 340, 3.81384, 0.00222589, 0.00226436, 0.00224086
12:29 < jonasschnelli> HASH256_SMALL, 5, 250000, 1.1305, 8.96669e-07, 9.15482e-07, 9.03866e-07
12:30 < jonasschnelli> (BIG = 1MB, SMALL: 256bytes)
12:30 < jonasschnelli> (and this is SHA256 asm vs non-asm ChaCha)
12:31 < jonasschnelli> But I agree that the chacha20 rounds (one for the poly key, one for the length) is not very very efficient...
12:31 < jonasschnelli> But compared to dbl-SHA256 is probably faster
12:31 < jonasschnelli> (once optimized)
12:33 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
12:39 < gmaxwell> jonasschnelli: so there is an obvious optimization to get the length key from bytes 33-36 of the polykey chacha run.  the only apparent argument against doing that is that its less compatible with existing constructs.  it sounds like openssl didn't do it that way so they could just call a function that implemented that TLS style AEAD.
12:39 -!- WhatDaMath [~quassel@114.206.199.196] has joined #bitcoin-core-dev
12:40 < jonasschnelli> gmaxwell: Yes. That would work,... but would reduce the AAD len to 4 (currently flexible, but not required in our case).
12:40 < jonasschnelli> My only worry is that we start cooking our own crypto...
12:45 < jonasschnelli> There is still the option to use AES-CGM *duck*
12:46 < jonasschnelli> Though non NI implementation will bring back cache-time attacks (or non efficient implementations)
12:46 < jonasschnelli> I guess ChaCha20 is preferable if we can't guarantee for AES-NI (which I guess we can't)
12:46 < gmaxwell> jonasschnelli: for AES-GCM there are very fast non-NI that are cache time fine, for machines with SIMD.
12:47 < gmaxwell> It's only CBC mode that really stinks without NI.
12:48 < jonasschnelli> Okay. Yeah. Unsure then if switching "back" (we once discussed AES-CGM vs ChaChaPoly back in 2015) would make sense then.
12:49 < gmaxwell> basically chacha20 is the fastest on ARM by a wide margin.  Basically tied with non-NI on x86 if you use SIMD, and somewhat worse than NI GCM.  Our reasoning, which I assume is the same as others using chacha-- is that it makes sense to optimize for the least powerful computers.
12:49 < gmaxwell> I think thats still true, though the 3x runs of chacha for small messages shifts the equation further in favor of AES simply because most of our messages are pretty small.
12:50 < jonasschnelli> Yes. Indeed. I think optimizing for an AAD-len of 4 and reducing thus to 2x could make sense then
12:50 < gmaxwell> jonasschnelli: I'm not sure why it would reduce the AAD len?  poly1305 uses 32 bytes of key regardless of the auth token size.
12:51 < jonasschnelli> The 2nd rund is currently to derive the 2nd ChaCha20 key for the AAD encryption (the 4 byte length in our case).
12:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
12:52 < gmaxwell> oh I see what you're saying the length of the lenghts.  Well there are 64 bytes available.
12:52 < gmaxwell> 32 get used for poly1305's key, leaving 32 that get throw away right now.
12:52 < jonasschnelli> Yes. We can set the max AAD size to 32
12:53 < jonasschnelli> But I'm not a cryptographer and I'm not sure if this would require some analysis first (isn't it basically a new AEAD)?
12:55 < jonasschnelli> Where I'm unsure: currently, there are two ChaCha20 contexts (two keys), one context is for the actual stream _AND_ the poly1305 key, the 2nd context for the AAD (the payload length)... and now
12:56 < jonasschnelli> We would drop the second context,... and take the AAD key from the main context
12:56 < jonasschnelli> Reducing back to 32bytes of required key material... 
12:57 < gmaxwell> At least the discussion I linked to before said that they designed it that way so they could use an unmodified implementation of the TLS AEAD to implement the openssl one. (this seems dumb to me, but its the rational they gave)
12:57 < jonasschnelli> Which sounds _not_ after a problem... but again, IF we do that, probably good if a cryptograph-expert takes a closer look at this
12:57 < gmaxwell> the defense against the length oracle just depends on you not being able to shift the input.
12:58 < jonasschnelli> I see... 
12:58 < jonasschnelli> Yes. Indeed. Reducing the performance in our system due to legacy stuff from the AEAD-origin system seems indeed inefficient
12:59 < gmaxwell> also, does the openssl usage actually send the full 128 bit poly1305 tag?  I had thought it used a 96 bit tag.
12:59 < jonasschnelli> To bad this is not an optimisation we can do later. :/
12:59 < jonasschnelli> gmaxwell: you mean openssh?
13:00 < gmaxwell> well thats why I'm looking at it now. What got me going down this path was checking to see if anything would get in the way of getting the most out of AVX2/SSE2 in the future.
13:00 < gmaxwell> jonasschnelli: ye.
13:00 < gmaxwell> yes.
13:01 < jonasschnelli> The openssh function produces a 128bit tag,... but not if they wired it over (probably)
13:03 -!- farmerwampum [~farmerwam@104.129.29.18] has quit [Ping timeout: 272 seconds]
13:03 < gmaxwell> There is another change we might want to consider, but I wanted to research if anyone else has proposed it-- that we should chain the unused part of the tag from each message to the AAD (additional authenticated data) in the next message, so we get the full tag's worth of protection, but then noticed we were using the whole tag output. When I thought it was truncated.
13:05 < jonasschnelli> gmaxwell: with the goal of saving 4 bytes per message, right?
13:05 < jonasschnelli> (in case we trunc down to 96bits)
13:06 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:08 < jonasschnelli> gmaxwell: where I'm also unsure – in case we would not reduce the AEAD to use a single 256bit key: the length is pretty much known (known plaintext), right now, in the AEAD@openssh, compromising the second, AAD key, is eventually not too critical
13:08 < jonasschnelli> *in case we would reduce
13:13 < gmaxwell> There is nothing wrong with the lengths being known. 99% of the protocol is known. It's very obvious from traffic analysis when pings are sent, for example. And the sequences of messages we send at the start are the same each time.
13:14 < jonasschnelli> Yes. That true,... 
13:15 < gmaxwell> jonasschnelli: yes, making the tag shorter reduces overhead.  Right now for short messages like a tx inv, almost half the bandwidth is used by overhead (the 4 byte length and the 16 byte tag).  If I was imagining it and no one else is truncating the tags, then I guess we shouldn't just to avoid the security analysis.
13:15 < jonasschnelli> I think its def. worth to see if we can.
13:17 < jonasschnelli> Compared to the v1 protocol (I agree that comparing is not the best metric), the encryption-overhead is not too bad. -4byte magic, -4bytes SHA-chksm,-~8bytes cmd, +16bytes MAC + 4byte length
13:18 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
13:20 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev
13:23 < gmaxwell> still ends up being about twice as much. Which is not unacceptable.  It seems I was dreaming about the 96-bit tag, I don't see anyone using poly1305 with truncated tags.
13:35 < jonasschnelli> twice as much? v1 versus v2? v1 inv: 24(hdr)+36(msg) == 60 bytes    < versus >. v2: 4(outter-len)+4(cmd)+4(inner-len)+36(msg)+16MAC == 64
13:35 < jonasschnelli> So an inv is 4 bytes longer
13:36 < jonasschnelli> Also,... multiple messages can be combined into a single encrypted package
13:36 < jonasschnelli> reducing the "weight" of the AAD (payload length) and the MAC tag
13:38 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:38 < gmaxwell> oh I forgot we could do that, well that basically kills any overhead concerns I had.
13:39 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
13:40 < gmaxwell> on your message above, an INV is 4+12+1+36+4 on the wire today.   
13:41 < gmaxwell> The twice comment was 4+4 vs 4+16 (-command savings) ~= 2x more overhead data. 
13:41 < jonasschnelli> didn't you miss the message size in your calc?
13:42 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Read error: No route to host]
13:42 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:42 < jonasschnelli> gmaxwell: AFAIK a v1 header is 24 bytes (4+12+!4!+4)
13:42 < sipa> yup
13:43 < gmaxwell> magic, command, (something), checksum, whats something?
13:44 < sipa> length
13:44 < jonasschnelli> (something) == 4 bytes 
13:44 < jonasschnelli> (length)
13:44 < jonasschnelli> (non variable)
13:45 < gmaxwell> and in the new protocol we made the lengths implicit to the command type?
13:45 < jonasschnelli> 10x v1 invs result in 600 bytes where a 10x v2 inv (packed) could result in 388 bytes
13:46 < jonasschnelli> gmaxwell: the v2 protocol uses varstr for the command rather then fixed 12 bytes
13:46 < jonasschnelli> but that reduction above comes at the cost of combining 10invs (time lag)
13:46 < gmaxwell> I know that the command is variable in v2. But do we have a second length then now?
13:46 < gmaxwell> jonasschnelli: if you're going to combine 10 invs, you'd combine them in the inv message. :)
13:47 < jonasschnelli> inner length, outer length
13:47 < jonasschnelli> gmaxwell: oh. yes. :/
13:47 < jonasschnelli> outer length is the encrypted payload length that can combine multiple messages
13:47 < jonasschnelli> (where the inner length is the message payload length)
13:48 < gmaxwell> right so it's not like we saved coding that length.
13:49 < jonasschnelli> you mean by using varlen for the inner message size?
13:49 < jonasschnelli> *varint
13:49 < gmaxwell> No.
13:49 < gmaxwell> the 16 byte tag  replaces magic and the checksum but the additional length at the encryption layer is just additional.  
13:49 < jonasschnelli> yes
13:50 < jonasschnelli> Its somehow required since you first need to check the MAC before processing the inner messages
13:51 < gmaxwell> Sure. from the above I thought you were saying that it was the only length we have. generally. But sadly we can't use implicit lengths because we need to be able to handle unknown messages.
13:51 < jonasschnelli> yeah
13:52 < gmaxwell> Whats the maximum size of an encrypted message? the outer length. Just the same as the maximum message size?
13:52 < jonasschnelli> 2^31
13:52 < jonasschnelli> (bit 32 is used for the rekey)
13:52 < gmaxwell> I sure hope not, else it'll be awfully easy to exhaust your ram. :P
13:53 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds]
13:53 < gmaxwell> I know what the length can encode, but there needs to be a smaller limit in the implementation or otherwise there is a trivial memory exhaustion DOS.
13:53 < jonasschnelli> gmaxwell: of course there is the MAX_SIZE check before decrypting the payload
13:54 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/14032/files#diff-35820b8a93cd261189cd3ea9a4e611e1R45
13:54 < gmaxwell> So, if it's the same MAX_SIZE as messages, does this end up effectively reducing MAX_SIZE by a few bytes?
13:55 < jonasschnelli> gmaxwell: Yes. I guess that would require fixing once we combine multiple messages (or expect it will be combined).
13:55 < jonasschnelli> So,... I guess it needs fixing now
13:55 < jonasschnelli> It's indeed missing bytes,... especially if we assume combined messages into a single enc package
13:55 < jonasschnelli> (will fix)
13:56 < gmaxwell> well yes/no, so max_size is much larger than any message we allow today.
13:56 < gmaxwell> so it's not actually a limitation. But I think it actually needs to be set to the largest message plus a few bytes for the overhead.
13:56 < gmaxwell> I think as you have it now thats probably a trivial DOS attack, e.g. I can make your node use 32mb * npeers ram... so 4GB additional usage in the default configuration. 
13:57 < jonasschnelli> hmm...
13:57 < sipa> use 3 byte lengths :)
13:58 < gmaxwell> 3 byte is kinda limiting, I really wanted to suggest that previously. Realistically if we ever had messages that needed to be bigger we'd have to break them up for processing reasons.
13:58 < jonasschnelli> How does the current network code prevents that (there is the same MAX_SIZE check)?
13:58 -!- Amuza [~amuza@212.230.156.111] has quit [Ping timeout: 276 seconds]
13:58 < sipa> the serialization code will only reallocate in blobs of 5 MB as the data is read
13:58 < gmaxwell> jonasschnelli: there are size limits on the particular messages.
13:58 < jonasschnelli> ah... we don't need to auth before process there, right
13:59 < sipa> it never allocates more than 5 MB in addition to what it has already read from the stream
13:59 < gmaxwell> Like if we were to support (say) 40MB blocks pratically we should have messages that split the blocks into chunks, because transfering and allocating 40MB at a time would be kind of absurd.
14:00 < gmaxwell> so 3byte lengths might actually be reasonable.
14:00 < jonasschnelli> ack
14:00 < jonasschnelli> But due to the rekey approach, it would be 2^23
14:02 < jonasschnelli> But I guess we don't want more then that per encryption package that needs auth (doesn't mean we don't want larger messages)
14:03  * jonasschnelli needs to go afk
14:09 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]
14:24 -!- plankers [~plank@200.7.98.14] has joined #bitcoin-core-dev
14:25 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
14:28 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
14:44 -!- rex4539 [~rex4539@2a02:587:3516:600:f89d:efb2:bffb:b0b4] has joined #bitcoin-core-dev
14:46 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has quit [Ping timeout: 264 seconds]
15:00 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev
15:01 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 240 seconds]
15:18 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
15:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
15:36 -!- hebasto [~hebasto@195.60.70.234] has quit [Remote host closed the connection]
15:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
15:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:45 -!- plankers [~plank@200.7.98.14] has quit [Ping timeout: 272 seconds]
15:58 -!- rex4539 [~rex4539@2a02:587:3516:600:f89d:efb2:bffb:b0b4] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:05 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has quit [Ping timeout: 260 seconds]
16:06 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
16:07 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
16:07 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
16:08 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:16 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
16:19 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has joined #bitcoin-core-dev
16:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
16:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
16:24 -!- GoldenBear [~gb@tilde.team] has quit [Ping timeout: 268 seconds]
16:24 -!- comboy [~quassel@tesuji.pl] has quit [Ping timeout: 268 seconds]
16:24 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has quit [Ping timeout: 252 seconds]
16:26 -!- GoldenBear [~gb@tilde.team] has joined #bitcoin-core-dev
16:27 -!- BGL [fifty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds]
16:29 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has joined #bitcoin-core-dev
16:43 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
16:44 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
16:53 -!- itaseski [~itaseski@213.135.176.114] has quit [Ping timeout: 252 seconds]
17:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
17:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:09 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Max SendQ exceeded]
17:09 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev
17:13 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 244 seconds]
17:14 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Remote host closed the connection]
17:15 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
17:22 < achow101> github ded :(
17:22 < sipa> aww
17:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
17:24 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
17:29 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 272 seconds]
17:32 < midnightmagic> achow101: huh?
17:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
17:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
17:41 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]
17:50 -!- BGL [eighty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:55 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev
17:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
18:03 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
18:15 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nuqnzkarppouhqwa] has quit [Quit: Connection closed for inactivity]
18:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
18:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]
18:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
18:53 < achow101> I was getting a bunch of errors earlier
19:18 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
19:33 -!- chainhead [~chainhead@2001:19f0:5:e14:5400:ff:fe77:e3d4] has joined #bitcoin-core-dev
20:39 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20:59 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Disconnected by services]
21:16 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
21:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
21:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
21:30 -!- vexbuy [~vexbuy@46.166.142.220] has joined #bitcoin-core-dev
21:44 -!- unholymachine [~quassel@2601:8c:c003:9f16:a9a2:a65b:627a:51ee] has quit [Read error: Connection reset by peer]
21:46 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:46 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:47 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit]
21:47 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
21:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds]
21:49 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
21:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
21:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]
21:55 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:56 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:56 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit]
21:57 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:57 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit]
21:58 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:58 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit]
21:59 -!- Rootsudo [~textual@180.190.116.254] has joined #bitcoin-core-dev
21:59 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit]
22:08 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Max SendQ exceeded]
22:10 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev
22:12 -!- ken2812221_ [~ken281222@180.217.87.172] has joined #bitcoin-core-dev
22:19 -!- ken2812221_ [~ken281222@180.217.87.172] has quit [Ping timeout: 252 seconds]
22:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
22:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
22:48 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
22:51 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has joined #bitcoin-core-dev
22:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
22:52 -!- vexbuy [~vexbuy@46.166.142.220] has quit [Ping timeout: 268 seconds]
22:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
22:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 272 seconds]
23:01 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
23:14 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
23:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
23:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
23:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 272 seconds]
23:37 -!- pkx1 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev
23:38 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
23:40 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit []
23:43 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 272 seconds]
23:50 -!- Rootsudo [~textual@180.190.112.33] has joined #bitcoin-core-dev
23:52 -!- pkx1 [~pkx@unaffiliated/pkx] has quit [Ping timeout: 268 seconds]
23:57 -!- karelb [uid316741@gateway/web/irccloud.com/x-kbrfiexjxgmfemtc] has quit [Quit: Connection closed for inactivity]
23:59 -!- rex4539 [~rex4539@2a02:587:3516:600:3973:5269:8ea:664] has joined #bitcoin-core-dev
--- Log closed Tue Aug 28 00:00:52 2018