--- Log opened Tue Aug 28 00:00:52 2018 00:11 -!- Amuza [~amuza@85.159.207.5] has joined #bitcoin-core-dev 00:13 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds] 00:24 -!- pkx1 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev 00:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:28 -!- pkx1 [~pkx@unaffiliated/pkx] has quit [Remote host closed the connection] 00:29 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds] 00:31 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 00:37 -!- Rootsudo [~textual@180.190.112.33] has quit [Ping timeout: 268 seconds] 00:49 -!- wxss [~user@158.58.172.183] has joined #bitcoin-core-dev 00:59 -!- wxss [~user@158.58.172.183] has quit [Ping timeout: 264 seconds] 01:12 -!- wxss [~user@109.236.91.108] has joined #bitcoin-core-dev 01:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 01:29 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:38 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 01:39 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 01:53 -!- WhatDaMath [~quassel@114.206.199.196] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 02:07 < jonasschnelli> sipa, gmaxwell: I think we should keep 2^31 for the maximal message size, reducing to 3bytes (23bits + rekey bit) seems too small and not worth saving a byte 02:08 < jonasschnelli> BTW: -maxreceivebuffer is also respected with the new message types... (this is a level deeper more on the socket) 02:09 < jonasschnelli> Ah... nm. I was wrong. The buffer check only happens when a complete message has been loaded 02:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:09 < wumpus> why would you ever need such a big message? in my experience it's usually better to split something up into smaller messages in that case 02:10 < wumpus> (for one, example to be able to continue an interrupted transfer, if it's all-or-nothing that won't work) 02:11 < jonasschnelli> 3 bytes - one rekey bit results in max size of 8’388’608 bytes (hardcoded in the protocol). I agree that we want smaller junks enforced on the application layer... but unsure about the protocol layer 02:12 < wumpus> so if you really need >24MB network messages, that is to me a suggestion something is wrong with the design at a higher level 02:12 < wumpus> right 02:13 < wumpus> if you also want to cram other data into the length word, it changes, though you could reserve the bits instead 02:14 < jonasschnelli> Yes. Thats also an idea. 02:14 < jonasschnelli> I also fail to see why someone should not be able to mem DOS a current peer with a incomplete message up to MAX_SIZE (33'554'432)... 02:14 < jonasschnelli> The -maxreceivebuffer hits only when the message is complete 02:15 < wumpus> so still leave 24 bits for the message length, a bit for rekey, and leave the rest for future use--it seems a bit wasteful but if your protocol is byte-based you don't get around such things 02:15 < wumpus> right 02:16 < wumpus> though as attacker you have to actually send the data, so if so it's a very slow DoS, but yes DoS potential is another good reason to not allow very large messages 02:17 < jonasschnelli> [22:56:32] 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 02:17 < jonasschnelli> wumpus: I think that attack is possible today 02:17 < jonasschnelli> npeers * MAX_SIZE 02:17 < wumpus> yes 02:18 < jonasschnelli> The question is, why is MAX_SIZE 0x2000000 02:18 < jonasschnelli> Ah. That constant is also used at http level 02:19 < jonasschnelli> and other places 02:20 < wumpus> for http is pretty arbitrary 02:20 < wumpus> but less important, as the http interface is meant for internal use, there are probably tons of ways to DoS it 02:20 < jonasschnelli> I mean as an attacker, you can create a IPv6 peer and create 128 connections to a peer (assume remote peer has no used ports) and send the same incomplete 32MB message to the peer and consume 4GB 02:22 < wumpus> as buffers are per connection, the only way around that would be to account, on a process level, of the total size of those buffers and go into some kind of DoS mode if too much is consumed in total 02:23 < wumpus> you *need* a fairly large receive buffer (though maybe not that large) to handle all the current messages, multiplied with 120+ that's always going to be a lot ! 02:26 < jonasschnelli> I think there should be a combined view on those buffers and as you said some sort of DoS prevention mode or a max total buffer size that makes per-connection-queues pause 02:26 < wumpus> indeed 02:27 < wumpus> one way to handle going over the total buffer cap would be to simply stop reading until it's processed, another way would be to drop connections with low priority and large buffers 02:28 < jonasschnelli> Yes. 02:28 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 02:29 < wumpus> might be out of scope for what you're doing, *not making it worse* would be nice 02:30 < wumpus> (re: bitcoin P2P specifically: do we ever get *unexpected* big messages?) 02:30 < wumpus> my intuition would be that the larger messages are always replies to requests such as getblock, getaddr, etc 02:31 < jonasschnelli> The buffer attack problem is orthogonal to the v2 protocol I'm implementing 02:31 < wumpus> if so, someone connecting to you and instantly offering a large message should probably be blasted 02:31 < wumpus> yes, agree 02:32 < jonasschnelli> I guess the attack would be, a) connect with a bunch of fake peers, do proper version handshake, send incomplete 32MB message (only header will be parsed) via all connections. 02:32 < jonasschnelli> The attacked peer could reject messages based on per command max sizes 02:33 < jonasschnelli> But then, unknown messages.. (unknown commands) 02:33 < wumpus> well if someone wants to send you an unknown message, out of the blue, larger than N -> bye 02:33 < wumpus> there's some scope for behavior modeling here, though I think keeping track of total buffer sizes is more predictable and easier to implement 02:33 < jonasschnelli> Yes. That is implemented, though N is 0x2000000 02:33 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has quit [Read error: Connection reset by peer] 02:34 < jonasschnelli> wumpus: yes. agree 02:35 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has joined #bitcoin-core-dev 02:37 < wumpus> it's even possible that libevent already has this funcionality, as it's not protocol specific 02:39 -!- math_ is now known as math 02:39 -!- math is now known as mthiel 02:39 < jonasschnelli> good point... 02:45 < jonasschnelli> Anyone know how I can solve this gcc -fPIC error while compiling test_bitcoin or bench_bitcoin: 02:45 < jonasschnelli> CXXLD test/test_bitcoin 02:45 < jonasschnelli> /usr/bin/ld: crypto/libbitcoin_crypto_base.a(crypto_libbitcoin_crypto_base_a-chacha.o): relocation R_X86_64_32 against `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC 02:45 < jonasschnelli> https://api.travis-ci.org/v3/job/421481343/log.txt 02:45 < jonasschnelli> Is it because I added extern C code? 02:46 < jonasschnelli> I think its clang not gcc, sry 02:50 < wumpus> "You can assign bufferevents to a rate limiting group if you want to limit their total bandwidth usage." seems like a different thing though 02:50 < wumpus> rate limiting versus total buffer limiting 02:50 < wumpus> jonasschnelli: you're probably linking to a static library that wasn't compiled with -fPIC 02:51 < wumpus> either link to a dynamic library instead or re-compile it with -fPIC 02:52 < jonasschnelli> wumpus: could it be because test_bitcoin has LDFLAGS -static? It works on master, but when I add my chacha20/poly1305 code to LIBBITCOIN_CRYPTO, it failes 02:54 < wumpus> on a general level it happens when some objects are built without -fPIC while requesting a position independent library/executable at link time-- '-static' will, on most platforms, generate a position dependent executable so no I don't think that's the reason 02:55 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-fbzunkgthhaiacle] has joined #bitcoin-core-dev 02:58 < wumpus> in this specific case, it looks like crypto_libbitcoin_crypto_base_a-chacha.o is built without -fPIC so the linker cannot include it 03:01 < jonasschnelli> wumpus: thanks... I'll take a closer look 03:08 < jonasschnelli> wumpus: I guess i found it, the added code (chacha/poly1305) are .c files and compiled with CC (CFLAGS) and not with CXX 03:16 < wumpus> ahh the ancient problem 03:20 < luke-jr> can probably just rename to .cpp? 03:23 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 03:24 < jonasschnelli> luke-jr: trying right now... 03:25 < wumpus> yes, 'porting' it to C++ might be the most straightforward solution, unless you need to do it repeatedly (such as when there's an upstream) 03:27 < jonasschnelli> I guess porting is fine... but the compile cache is killing me 03:28 < wumpus> both the name of the file and the compile flags will have changed, why would the cache pick that up? 03:46 < wumpus> please, don't do this: #14087 we have PRs enough to cope with 03:46 < gribble> https://github.com/bitcoin/bitcoin/issues/14087 | Remove unnecessary G_TRANSLATION_FUN nullptr assignment by promag · Pull Request #14087 · bitcoin/bitcoin · GitHub 03:47 < wumpus> the code is correct and clear, no need to fiddle with it 03:59 -!- wxss [~user@109.236.91.108] has quit [Ping timeout: 244 seconds] 03:59 -!- wxss [~user@158.58.172.183] has joined #bitcoin-core-dev 04:33 -!- farmerwampum [~farmerwam@104.129.29.18] has joined #bitcoin-core-dev 04:52 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 04:53 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 04:56 -!- wxss [~user@158.58.172.183] has quit [Ping timeout: 252 seconds] 04:57 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 252 seconds] 05:22 -!- Sinclair6 [~sinclair6@108-75-18-87.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-dev 05:45 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 05:48 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 05:48 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Client Quit] 05:48 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:23 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 06:27 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Remote host closed the connection] 06:27 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 06:32 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 272 seconds] 06:34 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 06:35 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 06:39 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Read error: Connection reset by peer] 06:58 -!- itaseski [~itaseski@213.135.176.221] has joined #bitcoin-core-dev 06:58 < wumpus> ok, apparently the code was not correct and clear, it was assigning nullptr to a std::function, sorry 07:26 < wumpus> btw: I intend to change my git mail to laanwj@protonmail.com (from laanwj@gmail.com), is this going to give any problems or set off alarms? (I'll keep using the same gpg key FWIW) 07:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:32 -!- cdecker [~cdecker@mail.snyke.net] has left #bitcoin-core-dev [] 07:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds] 07:38 < gmaxwell> 02:07:36 < jonasschnelli> sipa, gmaxwell: I think we should keep 2^31 for the maximal message size, reducing to 3bytes (23bits + rekey bit) seems too small and not worth saving a byte 07:38 < gmaxwell> jonasschnelli: I agree that the byte is unimportant, but we will never have such big messages. 07:39 < wumpus> indeed 07:39 -!- Amuza [~amuza@85.159.207.5] has quit [Remote host closed the connection] 07:39 < gmaxwell> Even sending around 2MB messages is pretty terrible. Anything where a message would be that big should be split into smaller messages. 07:39 -!- promag [~promag@83.223.251.34] has joined #bitcoin-core-dev 07:40 < gmaxwell> I would say that we should introduce new messages to do this for blocks already, except that other than in IBD/catchup blocks are almost never sent whole anymore. 07:40 < wumpus> yep, said the same thing 07:44 < gmaxwell> E.g. a N-way split block message could send the merkle branches for the remaining parts, so you can verify the merkle root for each chunk as you get it, and not bother buffering something that is never going to be useful. 07:45 < wumpus> similar to how bittorrent uses merkle trees IIRC 07:45 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 07:46 < wumpus> but yes, good idea 07:50 < jonasschnelli> yes. agree. 07:53 < gmaxwell> Really the message sizes should be driven by being large enough to make overheads low, and large enough to usefully process something incrementally (it's not so useful to send a message where we can do nothing at all with it except wait for more), and otherwise as small as possible to avoid creating large buffering and head of line blocking problems. 08:06 < sipa> wumpus: add a new uid to your gpg key and upload it somewhere 08:08 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 08:09 < wumpus> sipa: I already did that part :) 08:13 < waxwing> sipa, what's going on here? why would someone be adding both witness and non-witness utxo fields in the same input (bip174)? https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L256-L259 08:18 < achow101> waxwing: it's just a safety check 08:19 < achow101> waxwing: that could happen in the case that someone adds a non-witness utxo to a witness one because it is p2sh wrapped. Then someone else could, seeing that there was no witness utxo, add a witness one without removing the non-witness one 08:19 < achow101> that would of course be an implementation error, but it should still be a case that needs to be handled 08:21 < sipa> waxwing: both are added, and the irrelevant one is later deleted (because it's the signing code that determines which one was needed) 08:22 < sipa> it will never make it out to the serialization 08:22 < waxwing> it's technically more lax than what was specc'ed right, which was to reject anything with both. but the example you give is a plausible case for allowing it. 08:22 < sipa> waxwing: this is just internals 08:22 < sipa> it's not observable behavior 08:23 < waxwing> ah ok, thanks 08:23 < sipa> (scroll down a bit, see line 280-287 08:26 -!- promag [~promag@83.223.251.34] has quit [Ping timeout: 264 seconds] 08:26 -!- rex4539 [~rex4539@2a02:587:3516:600:3973:5269:8ea:664] has quit [Quit: Textual IRC Client: www.textualapp.com] 08:30 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev 08:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 08:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 08:52 < gmaxwell> jonasschnelli: re memory usage, see MAX_PROTOCOL_MESSAGE_LENGTH. -- you can't cause 32MB usage today. 08:53 < gmaxwell> I think if we were to redo things from scratch, we'd end up with a 256KB maximum message size or something like that. The only reason I don't suggest making the encrypted transport limited to that sort of size is because we'd have to introduced split block messages first. 08:54 < gmaxwell> and as I mentioned before, due to compact blocks I think it isn't particularly important to add split blocks. 08:56 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has quit [Read error: Connection reset by peer] 08:57 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has joined #bitcoin-core-dev 09:01 -!- Rootsudo [~textual@180.191.157.73] has joined #bitcoin-core-dev 09:02 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 09:10 -!- Rootsudo [~textual@180.191.157.73] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:14 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 09:17 -!- Rootsudo [~textual@180.191.157.73] has joined #bitcoin-core-dev 09:42 -!- blackbaba [~blackbaba@223.225.141.88] has joined #bitcoin-core-dev 09:42 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 09:55 -!- blackbaba [~blackbaba@223.225.141.88] has quit [Remote host closed the connection] 09:57 -!- blackbaba [~blackbaba@223.225.141.88] has joined #bitcoin-core-dev 10:00 -!- blackbaba [~blackbaba@223.225.141.88] has quit [Client Quit] 10:04 < ryanofsky> MarcoFalke, any suggestion on how handle "AppVeyor was unable to build non-mergeable pull request" in 9381? there are no conflicts. maybe close and reopen? 10:05 -!- Rootsudo [~textual@180.191.157.73] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:06 < gmaxwell> I recommend a goat sacrifice. 10:14 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev 10:18 < wumpus> yes, a goat should do in this case 10:22 < luke-jr> who has one? someone is more rural than me? 10:26 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Ping timeout: 272 seconds] 10:30 < Chris_Stewart_5> any idea what is going on testnet ? 10:31 < Chris_Stewart_5> or ¯\_(ツ)_/¯ 10:39 -!- Giszmo [~leo@ip-100-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 10:41 -!- ken2812221 [~ken281222@180.217.87.172] has quit [Ping timeout: 268 seconds] 10:48 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 10:56 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 264 seconds] 10:58 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 11:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:04 -!- profmac [~ProfMac@2001:470:1f0f:226:ed71:2a87:1aaa:73e9] has joined #bitcoin-core-dev 11:05 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has quit [Read error: Connection reset by peer] 11:07 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has joined #bitcoin-core-dev 11:17 -!- ExtraCrispy [~ExtraCris@67.215.11.12] has joined #bitcoin-core-dev 11:25 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 11:32 -!- Krellan [~Krellan@2601:640:4000:9258:390e:963f:4db3:d60] has quit [Remote host closed the connection] 11:33 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 268 seconds] 11:38 < jonasschnelli> gmaxwell: oh. Right. I missed MAX_PROTOCOL_MESSAGE_LENGTH. 11:38 < jonasschnelli> That check is also there for the v2 protocol (in my PR) 11:39 < jonasschnelli> But its in-precise in v2 because one package can contain multiple messages (and this checks a "package") 11:39 < gmaxwell> We might want to log the command, length, number for each message we send, and see if the ability to batch multiple messages even potentially pays for the extra 3/4 bytes of length. 11:40 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 11:41 -!- willyko_ [cf66d662@gateway/web/freenode/ip.207.102.214.98] has joined #bitcoin-core-dev 11:42 < gmaxwell> jonasschnelli: what do you mean that its imprecise? 11:42 < gmaxwell> The package payload should be limited to MAX_PROTOCOL_MESSAGE_LENGTH. 11:42 < jonasschnelli> gmaxwell: if you combine 10 blocks into a single encryption package it gets rejected 11:42 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 11:42 < jonasschnelli> gmaxwell: Yes. I agree. 11:43 < jonasschnelli> I guess its a wording thing,... 11:43 < jonasschnelli> message is IMO the v2 inner message (the actual command&size&payload) 11:43 < willyko_> hi all, i'm wondering what's the current gitian build tech stack people are using right now? i haven't been able to gitian build since the bionic upgrade 11:43 < gmaxwell> Right good. I understand, you're just saying that by applying it as max package length you can't always use a message of that size. 11:43 < jonasschnelli> Where the outer message is the "package" 11:43 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:43 < jonasschnelli> If combining messages gets a thing, people would expect that MAX_PROTOCOL_MESSAGE_LENGTH is per inner message 11:44 < gmaxwell> jonasschnelli: if you would otherwise buffer more than MAX_PROTOCOL_MESSAGE_LENGTH then that just goes into another package. 11:44 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer] 11:45 < jonasschnelli> gmaxwell: but you need to read-process the whole package to check the MAC before you can look at the inner messages 11:45 < gmaxwell> Yes. I am referring to the sender. 11:46 < jonasschnelli> oh. yes. 11:46 < jonasschnelli> Yeah. The question is if we want to drop the multi-message thing and save 4 bytes (and some complication is size checkes) 11:46 < jonasschnelli> I guess originally cfields came up with that idea 11:47 < jonasschnelli> (the idea to use multi-message envelopes 11:47 < jonasschnelli> +) 11:47 < gmaxwell> But I'm wondering if the ability to put multiple messages in a package even makes sense. It adds 4 bytes (maybe we change to 3) overhead to every message, ... but only saves 16 bytes when we bundle. And except for ping no common message is especially small. 11:47 < gmaxwell> A headers message, we want to minimize latency, so it will almost never be bundled. 11:47 < gmaxwell> INVs get batched internally. 11:48 < cfields> jonasschnelli: I believe I argued against :) 11:48 < cfields> jonasschnelli: iirc my request was that IF we bundle, to throw an index up-front so that we could do optimistic preallocation 11:48 < gmaxwell> It seemed like sipa was for some reason thinking that we could incrementally process inner messages before buffering the whole thing. But we can't or otherwise that moots the MAC. 11:49 < jonasschnelli> Yeah... 11:49 < jonasschnelli> I say drop it (the envelope/inner-message wrapping) 11:49 < jonasschnelli> And reduce the length to 3 bytes (- rekey bit) resulting in 2^23 (8’388’608) max message size 11:51 < gmaxwell> Does the inner length as done now include the variable length command? 11:51 -!- profmac [~ProfMac@2001:470:1f0f:226:ed71:2a87:1aaa:73e9] has quit [Ping timeout: 276 seconds] 11:51 < jonasschnelli> no 11:51 < gmaxwell> It should. So you don't have to read the command in order to process the mac. 11:52 < gmaxwell> by read I mean decode. 11:52 < gmaxwell> [3 byte - 1 bit lenth][varlen command][16 byte mac]. 11:52 < jonasschnelli> wouldn't it be -> ( 3bytes_cipher_length_plus_flag || cipher_command || payload || 128bit-MAC ) 11:53 < gmaxwell> yes, well I mean, if you want to actually send payloads... :P 11:53 < jonasschnelli> You decrypt the length, then read and MAC-check the rest, then decrypt 11:53 < jonasschnelli> if there is no payload you would figure out during command varint processing and after the MAC 11:55 < jonasschnelli> AEAD( AAD( K1_ENC( 3bytes_cipher_length_plus_flag ) ) || K2_ENC( cipher_command || payload ) ) 11:56 < gmaxwell> in the above the crypto layer just becomes completely oblivious to commands. it's all just payload to it. 11:57 < gmaxwell> how is the variable length command implemented? the bip just says varlen which is not very clear. 11:58 < jonasschnelli> varstr (a varint plus a string),... I think probably always one byte & the string 11:58 < jonasschnelli> 0x03 'i' 'n' 'v' 11:58 < gmaxwell> yes, it should be at most one byte. Allowing more to be encoded is just begging for bugs. 11:59 < jonasschnelli> Yes. We could enforce one bytes length by the specs 12:01 < gmaxwell> We could also change to command byte where 0-12 mean 0-12 byte explicit comands, and other values are mapped to some existing commands (like ping/inv/header) and the rest are undefined. 12:01 < gmaxwell> but at least the size should just be made a byte. 12:02 < gmaxwell> in general we should watch for cases where a parser would need to impose limits to protect itself from bad values, and just make those bad values impossible to encode. 12:02 < jonasschnelli> Yeah.. would save another byte. :) 12:04 < gmaxwell> well for ping the packed commands would save 4 bytes. For inv 3 bytes. for headers it would save 7 bytes... 12:04 -!- Orion3k [~Orion3k@24-176-200-142.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev 12:04 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #bitcoin-core-dev 12:05 < jonasschnelli> gmaxwell: Aha. I see now. Dropping the str-based command for a number-to-command mapping... 12:06 < jonasschnelli> But smells a bit after central planing (I guess developers will tend then to address new values to new commands) 12:06 < gmaxwell> jonasschnelli: str based exists for some messages, its needed for extensibility. 12:06 < jonasschnelli> Yes. Sure. We can set 0xFF for str or something 12:06 < jonasschnelli> or as you said, just use 0-12 for the very known ones 12:06 < gmaxwell> Well I was suggesting that we have values 1-12 be for strings of length 1-12. 12:06 < gmaxwell> right. 12:07 < jonasschnelli> Or that. Yes. 12:07 < gmaxwell> then use values for the few very common small protocol messages (ping, inv, header probably) and the rest just stay strings. 12:07 < jonasschnelli> Jup. I like that. 12:08 < gmaxwell> as far as centeral planning goes there isn't a reason that nodes couldn't use different numbers on dinfferent links. 12:08 < gmaxwell> we wouldn't implement support for that unless needed, but it wouldn't be a problem. 12:09 < gmaxwell> they 1-byte commands would really only be needed for commands which are frequent and small... So, for example if we introduced a new kind of headers message, we might want to use one for that. 12:09 < gmaxwell> But I don't see any reason to use a 1-byte command for a block. 12:11 < jonasschnelli> Your argument is then more for latency then for bandwidth, right? 12:13 < jonasschnelli> I guess if your peer gets heavy used for IBDing, saving a couple of bytes on the block command has the same effect then on the inv command (in terms of total bandwidth 12:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:14 < gmaxwell> But say, for example, we decide we want to have a HEADERS2 message coded as value 27 in bitcoin core. We're going to negoiate its activation with something like SENDHEADERS. Say another implementation BitcoinConnectUnlimitedClassic (BCUX) wants to use 27 for XHEADERS. An implementation could support talking to both kinds of peers just by assigning the meaning of 27 based on the negoation. 12:14 < gmaxwell> jonasschnelli: not in terms of percentage, however. 12:15 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 12:17 < gmaxwell> Over the life of a node, even one that serves IBDing peers, it should service a lot more INV messages than block messages. 12:19 < jonasschnelli> agree 12:20 < gmaxwell> we can even specify that any usage of short types other than the ones initially set should be negoigated. So then there is basically no collision problem. 12:22 -!- profmac [~ProfMac@2001:470:1f0f:226:ed71:2a87:1aaa:73e9] has joined #bitcoin-core-dev 12:22 < jonasschnelli> With negotiating you mean some "proprietary" message? 12:23 < gmaxwell> I mean just that you don't use them unless you know the other side can handle them, based on something else they've sent. 12:24 < jonasschnelli> Yes. We should mention that... 12:24 < gmaxwell> So for example, we'll likely introduce a new ADDR message in the future. So your peer can send you a SENDADDR2 command, and then after they get that they know they can send you value=22 messages, per the ADDR2 BIP. 12:25 < jonasschnelli> Got it. Yes. 12:25 < jonasschnelli> gmaxwell: since the length is now caped at 2^23, how would decomposing a message distributed over two packages look like? 12:26 < gmaxwell> Thats specific to the message. It should be decomposed in a way that allows incremental processing. 12:26 < jonasschnelli> Aha.. PARTIALBLOCK or something 12:27 < jonasschnelli> Good. Then there is no extra handling on the transport layer. 12:27 < gmaxwell> So for example, say we wanted to support breaking blocks up, you'd split a block into N messages, the first message might be the header, tx count, and N hashes, where the N hashes are the merkelroots for the N chunks of the block. Then additional messages for each chunk. But the transport layer doesn't care. 12:27 < gmaxwell> The rationale is that the right splitting is message type dependant. 12:28 < gmaxwell> For an INV, for example, there is _just no reason_ to ever make a single INV that big, just make another INV. 12:28 < gmaxwell> so the splitting for INVs is more invs. 12:32 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev 12:32 -!- booyah_ is now known as THE_JUDGE 12:33 -!- THE_JUDGE [~bb@193.25.1.157] has quit [Client Quit] 12:35 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-dev 12:37 -!- Giszmo [~leo@ip-100-233.219.201.nextelmovil.cl] has quit [Ping timeout: 268 seconds] 12:39 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:53 -!- Giszmo [~leo@ip-100-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 12:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 13:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:42 -!- adiabat [~adiabat@63.209.32.102] has quit [Quit: WeeChat 1.4] 13:42 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-fbzunkgthhaiacle] has quit [Quit: Connection closed for inactivity] 13:54 < promag> #13825 in HP? 13:54 < gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub 13:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 14:05 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds] 14:15 -!- Giszmo [~leo@ip-100-233.219.201.nextelmovil.cl] has quit [Ping timeout: 245 seconds] 14:18 < gmaxwell> jonasschnelli: interesting to note: 4(magic) + 12(command) + 4(length) + 4(sha2) = 24 which is more than 3 (length) + 1(type) + 16(mac) = 20 for messages that can use the 1-byte type. 14:19 -!- profmac [~ProfMac@2001:470:1f0f:226:ed71:2a87:1aaa:73e9] has quit [Ping timeout: 264 seconds] 14:31 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev 14:38 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...] 14:38 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 14:47 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-dev 15:06 -!- profmac [~ProfMac@72-48-98-98.dyn.grandenetworks.net] has joined #bitcoin-core-dev 15:09 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 15:19 < Chris_Stewart_5> luke-jr: I could get my hands on a goat -- don't think i could sacrifice it though. 15:19 < Chris_Stewart_5> ;) 15:29 -!- grubles_ [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 15:30 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 15:36 -!- grubles_ [~grubles@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 15:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 15:46 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 15:47 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 15:49 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 15:50 -!- Krellan_ [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 15:51 -!- Krellan_ [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 15:51 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 15:52 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 15:59 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 15:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 16:02 -!- unholymachine [~quassel@2601:8c:c003:9f16:a106:666b:62dd:7c27] has joined #bitcoin-core-dev 16:04 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 246 seconds] 16:11 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/] 16:13 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 16:16 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl] 16:20 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Quit: Leaving] 16:22 -!- profmac [~ProfMac@72-48-98-98.dyn.grandenetworks.net] has quit [Ping timeout: 246 seconds] 16:29 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 16:43 -!- rhavar_ [uid237883@gateway/web/irccloud.com/x-uubwsobagzoywltz] has joined #bitcoin-core-dev 16:47 -!- willyko_ [cf66d662@gateway/web/freenode/ip.207.102.214.98] has quit [Ping timeout: 252 seconds] 17:02 -!- alexneudatchin [~alexn___r@31.148.139.118] has joined #bitcoin-core-dev 17:03 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds] 17:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 17:09 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 272 seconds] 17:24 < phantomcircuit> anybody know why we sleep in ThreadSocketHandler when select() fails ? 17:25 < phantomcircuit> (it's all the way back to satoshi so cant exactly ask the author) 17:28 < gmaxwell> presumably to avoid slamming it when it fails under the assumption that if it fails its not going to stop failing for a bit. 17:30 < phantomcircuit> gmaxwell, it seems like basically every way it can fail except EINTR is a catastrophic failure and should just exit 17:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection] 17:31 < phantomcircuit> other things are like you gave it an invalid fd which should never happen 17:32 < sipa> phantomcircuit: well, is it triggering for you? 17:32 -!- alexneudatchin [~alexn___r@31.148.139.118] has quit [Quit: Leaving] 17:33 < phantomcircuit> sipa, no and i cant remember ever seeing "socket select error" in logs 17:33 < phantomcircuit> quick split up and search debug.log's far and wide 17:36 -!- itaseski [~itaseski@213.135.176.221] has quit [Ping timeout: 272 seconds] 17:37 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 18:03 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 18:19 -!- Netsplit *.net <-> *.split quits: earlz, _flow_, michagogo, rockhouse, harrigan 18:19 -!- Netsplit over, joins: earlz 18:21 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has joined #bitcoin-core-dev 18:21 -!- harrigan [~harrigan@skynet.skynet.ie] has joined #bitcoin-core-dev 18:22 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev 18:36 -!- profmac [~ProfMac@2001:470:1f0f:226:ed71:2a87:1aaa:73e9] has joined #bitcoin-core-dev 18:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 18:49 -!- Netsplit *.net <-> *.split quits: lesderid, felco, trotski2000 18:50 -!- Netsplit *.net <-> *.split quits: lightningbot, paracyst 18:51 -!- Netsplit over, joins: felco 18:52 -!- Netsplit over, joins: lesderid 18:54 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 18:55 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev 19:02 -!- echeveria [~echeveria@unaffiliated/echeveria] has joined #bitcoin-core-dev 19:20 -!- ken2812221 [~ken281222@180.217.161.139] has joined #bitcoin-core-dev 19:34 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 244 seconds] 19:42 -!- Netsplit *.net <-> *.split quits: twistedline, achow101, jonasschnelli, lifeofguenter, [b__b] 19:43 -!- Netsplit *.net <-> *.split quits: gmaxwell, barq, Apocalyptic, infernix, sugarpuff, hsmiths, midnightmagic, aj, TD-Linux, z323, (+9 more, use /NETSPLIT to show all of them) 19:43 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 19:52 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ 19:52 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ 19:53 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev 19:56 -!- Fuzzbawls [~Fuzz@fuzzbawls.pw] has joined #bitcoin-core-dev 19:57 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev 19:57 < gmaxwell> can we try removing +r again, I just couldn't join for a while because freenode bumped me and nickserv was down 19:57 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 19:58 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 19:58 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 19:58 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev 19:58 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 20:01 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 20:02 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev 20:04 -!- infernix [nix@unaffiliated/infernix] has joined #bitcoin-core-dev 20:05 -!- dc1 [~dc@unaffiliated/dc/x-2221435] has joined #bitcoin-core-dev 20:06 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ 20:06 -!- z323 [~z323@ec2-54-234-151-68.compute-1.amazonaws.com] has joined #bitcoin-core-dev 20:06 -!- mode/#bitcoin-core-dev [-r] by sipa 20:06 <@sipa> let's see 20:06 -!- mode/#bitcoin-core-dev [-o sipa] by sipa 20:12 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 21:00 -!- gleb [sid306870@gateway/web/irccloud.com/x-pnsagnamqzasnfkz] has joined #bitcoin-core-dev 21:35 -!- phwalkr [~phwalkr@2001:1284:f016:19d7:956b:a881:aa86:ccf7] has joined #bitcoin-core-dev 21:37 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:4455:5da2:fcdb:e685] has joined #bitcoin-core-dev 21:38 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:4455:5da2:fcdb:e685] has quit [Remote host closed the connection] 21:39 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:4455:5da2:fcdb:e685] has joined #bitcoin-core-dev 21:39 -!- phwalkr [~phwalkr@2001:1284:f016:19d7:956b:a881:aa86:ccf7] has quit [Ping timeout: 240 seconds] 21:43 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:4455:5da2:fcdb:e685] has quit [Ping timeout: 240 seconds] 21:51 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 21:56 -!- jonasschnelli_ [~jonasschn@2a01:4f8:172:10da::2] has joined #bitcoin-core-dev 22:13 -!- Rootsudo [~textual@180.191.157.73] has joined #bitcoin-core-dev 22:14 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has joined #bitcoin-core-dev 22:16 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 22:18 < leishman> I had a node running 0.16.2 with a txindex. I updated the binary to 0.17rc2 and when starting up bitcoind it seems to hang on "Upgrading txindex database... [0%]" 22:19 < leishman> I'm not sure how long this is expected to take, but I've seen no progress displayed after 5-10 minutes 22:21 < leishman> I'm assuming this has to do with the changes to the txindex in 0.17 22:24 < leishman> ok got 10% progress after 10 minutes 22:26 < leishman> perhaps we should warn users that an upgrade for a node with a txindex could end up taking a while 22:27 -!- leishman_ [~leishman@136.24.189.159] has joined #bitcoin-core-dev 22:27 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has quit [Read error: Connection reset by peer] 22:28 < sipa> leishman_: do the release notes not say anything about that? if so, indeed 22:29 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 22:29 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 22:29 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 22:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Write error: Broken pipe] 22:30 < leishman_> sipa: I don't see any mention of it here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes#transaction-index-changes 22:30 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 22:31 -!- Rootsudo [~textual@180.191.157.73] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:32 < leishman_> I see in jimpos PR here (https://github.com/bitcoin/bitcoin/pull/13033) that it was tested. What kind of migration times did others see? 22:32 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Quit: Leaving.] 22:36 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:454f:112b:9095:f0ea] has quit [Ping timeout: 260 seconds] 22:49 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 22:49 < warren> leishman_: what kind of hardware? 22:50 -!- qrestlove [~qrestlove@2605:6000:eb61:c500:34a3:1124:bc17:69fb] has joined #bitcoin-core-dev 22:50 < leishman_> warren: Intel J1900 Quad Core. 4GB ram, HDD 22:52 < leishman_> i'm at 22% through the migration after about 30 minutes. 23:05 -!- Rootsudo [~textual@180.191.157.73] has joined #bitcoin-core-dev 23:05 -!- Krellan [~Krellan@c-73-223-240-37.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 23:09 -!- Krellan [~Krellan@c-73-223-240-37.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 23:11 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-swwpqwixkxdrpbfx] has joined #bitcoin-core-dev 23:11 < bitcoin-git> [bitcoin] osbc opened pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098 23:11 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-swwpqwixkxdrpbfx] has left #bitcoin-core-dev [] 23:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-smctxzrqbdwmhrdx] has joined #bitcoin-core-dev 23:12 < bitcoin-git> [bitcoin] osbc closed pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098 23:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-smctxzrqbdwmhrdx] has left #bitcoin-core-dev [] 23:19 -!- leishman_ [~leishman@136.24.189.159] has quit [Remote host closed the connection] 23:19 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has joined #bitcoin-core-dev 23:24 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has quit [Remote host closed the connection] 23:24 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has joined #bitcoin-core-dev 23:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 23:49 -!- Krellan [~Krellan@2601:640:4000:9258:78f6:6b13:2750:b1c3] has joined #bitcoin-core-dev 23:53 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has quit [Remote host closed the connection] 23:53 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has joined #bitcoin-core-dev 23:54 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 23:56 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 23:57 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 23:58 -!- leishman [~leishman@2604:5500:c225:c500:d415:9401:5761:5d12] has quit [Ping timeout: 250 seconds] 23:59 -!- rhavar_ [uid237883@gateway/web/irccloud.com/x-uubwsobagzoywltz] has quit [Quit: Connection closed for inactivity] --- Log closed Wed Aug 29 00:00:53 2018