--- Day changed Thu Nov 10 2016
00:28 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
00:28 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev     
00:55 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
00:55 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host]     
00:55 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
01:02 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbwvyireegjfjkav] has joined #bitcoin-core-dev     
01:08 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
01:09 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
01:11 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
01:25 < bitcoin-git> [bitcoin] visvirial opened pull request #9122: fix getnettotals RPC description about timemillis. (master...fix-getnettotals-rpc-desc) https://github.com/bitcoin/bitcoin/pull/9122
01:31 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/faec09bc7f03...537e0cb252a3
01:31 < bitcoin-git> bitcoin/master 45d372f UdjinM6: Missed one "return false" in recent refactoring in #9067
01:31 < bitcoin-git> bitcoin/master 537e0cb Wladimir J. van der Laan: Merge #9120: bug: Missed one "return false" in recent refactoring in #9067...
01:31 < bitcoin-git> [bitcoin] laanwj closed pull request #9120: bug: Missed one "return false" in recent refactoring in #9067 (master...fixExitCodesBitcoinTx) https://github.com/bitcoin/bitcoin/pull/9120
01:32 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
01:33 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
01:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:35 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/537e0cb252a3...aab102cbae6b
01:35 < bitcoin-git> bitcoin/master bdcba6d Pavel Janík: Initialize variable to prevent compiler warning
01:35 < bitcoin-git> bitcoin/master aab102c Wladimir J. van der Laan: Merge #9121: Initialize variable to prevent compiler warning...
01:35 < bitcoin-git> [bitcoin] laanwj closed pull request #9121: Initialize variable to prevent compiler warning (master...20161110_rpcdump_uninitialized) https://github.com/bitcoin/bitcoin/pull/9121
01:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:41 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 260 seconds]     
01:43 -!- DigiByteDev [~JT2@209.160.126.163] has quit [Quit: DigiByteDev]     
01:47 -!- owowo [ovovo@gateway/vpn/mullvad/x-eesgnexftnadgctu] has quit [Ping timeout: 244 seconds]     
01:48 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds]     
01:48 -!- testnet [~testnet@gateway/tor-sasl/testnet] has quit [Ping timeout: 245 seconds]     
01:55 -!- afk11 [~afk11@79.97.105.226] has joined #bitcoin-core-dev     
01:55 -!- afk11 [~afk11@79.97.105.226] has quit [Changing host]     
01:55 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev     
01:57 -!- DigiByteDev [~JT2@124.217.188.196] has joined #bitcoin-core-dev     
02:01 -!- DigiByteDev [~JT2@124.217.188.196] has quit [Client Quit]     
02:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
02:06 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
02:06 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aab102cbae6b...4a2b170c075c
02:06 < bitcoin-git> bitcoin/master a79f864 Masahiko Hyuga: fix getnettotals RPC description about timemillis.
02:06 < bitcoin-git> bitcoin/master 4a2b170 MarcoFalke: Merge #9122: fix getnettotals RPC description about timemillis....
02:07 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9122: fix getnettotals RPC description about timemillis. (master...fix-getnettotals-rpc-desc) https://github.com/bitcoin/bitcoin/pull/9122
02:08 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection]     
02:17 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
02:17 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Read error: Connection reset by peer]     
02:24 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a2b170c075c...e5364991daec
02:24 < bitcoin-git> bitcoin/master fac1141 MarcoFalke: [qa] preciousblock: Use assert_equal and BitcoinTestFramework.__init__
02:24 < bitcoin-git> bitcoin/master fa97ccb MarcoFalke: [qa] util: Rework sync_*()...
02:24 < bitcoin-git> bitcoin/master e536499 MarcoFalke: Merge #9097: [qa] Rework sync_* and preciousblock.py...
02:24 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9097: [qa] Rework sync_* and preciousblock.py (master...Mf1611-qaSyncAndPrecious) https://github.com/bitcoin/bitcoin/pull/9097
02:25 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
02:29 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 248 seconds]     
02:33 -!- laurentmt [~Thunderbi@80.215.178.71] has joined #bitcoin-core-dev     
02:35 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
02:38 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
02:38 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
02:38 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
02:43 -!- laurentmt [~Thunderbi@80.215.178.71] has quit [Quit: laurentmt]     
02:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
02:50 -!- laurentmt [~Thunderbi@80.215.178.71] has joined #bitcoin-core-dev     
02:52 -!- laurentmt [~Thunderbi@80.215.178.71] has quit [Client Quit]     
02:57 -!- whphhg [whphhg@gateway/vpn/mullvad/x-nlfnuubopulaydfr] has quit [Quit: Leaving]     
03:13 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
03:36 -!- cdecker [~quassel@2a02:aa16:1105:4a80:bcd4:7d3b:d57e:787f] has joined #bitcoin-core-dev     
03:54 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
03:58 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
04:11 < jonasschnelli> would it make sense to use a 1byte command code instead of the 12byte char in the new bip151 message structure?
04:12 < jonasschnelli> Or would that lead to problems defining new commands and possible overlaps?
04:12 < jonasschnelli> 0x01 = inv, 0x02 = getaddr, etc.
04:13 < jonasschnelli> It would just save another 3-11 bytes per message.
04:15 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]     
04:15 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
04:15 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 265 seconds]     
04:16 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
04:16 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
04:17 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
04:21 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:44 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
05:08 <@wumpus> jonasschnelli: I disagree with doing that: using 12-byte identifiers gives an enormouse scope for different parties to define commands that don't overlap
05:09 <@wumpus> jonasschnelli: using a 1 or 4 byte command code implies a central authority dealing out command codes, and we've had many collisions already
05:09 <@wumpus> (with other things like inv enums)
05:10 <@wumpus> let's not throw away the baby with the bath water while (over) optimizing
05:24 < jonasschnelli> Okay.
05:33 <@wumpus> you could bring it down from 12 to, say, 8 I guess, 64-bit identifiers can be pretty unique
05:34 -!- harrymm [~wayne@104.222.140.86] has quit [Remote host closed the connection]     
05:34 <@wumpus> heck even 4 bytes probably won't cause a lot of fighting, this is not about about bits but enums
05:35 <@wumpus> but 256 options is just too few and will guarantee fighting, that will end in fire :)
05:39 < jonasschnelli> It looks like that 256 options should be sufficient from the current perspective... but right,.. maybe we better keep it
05:40 < jonasschnelli> An INV would go down from 60bytes to 58bytes. :(
05:40 < jonasschnelli> I guess it's not worth it.
05:40 <@wumpus> INVs can already combine right?
05:41 <@wumpus> ideally send a whole bunch of them at once, not one per message
05:41 < jonasschnelli> A right. INV is a vector.
05:41 <@wumpus> and yes, 256 bytes is 'sufficient from the current perspective' but that's not my point, my point is to make it feature proof and allow permissionless innovation
05:41 <@wumpus> future proof*
05:42 < jonasschnelli> Yes. I think this is wise.
05:43 < jonasschnelli> I wonder if reducing the poly1305 mac tag (currently 16 bytes) would be something that could be considered.
05:43 <@wumpus> is there ever a use case where lots of small messages are sent?
05:43 < jonasschnelli> Probably not.
05:43 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:43 < jonasschnelli> wumpus: spv?
05:44 <@wumpus> any that are not vector-able?
05:44 <@wumpus> if so it may make sense to have a 'group' message which just concatenates a bunch of messages (of the same type, say, or at least with types RLE'd), under one mac tag and outer header and such
05:45 < jonasschnelli> Probably not.
05:45 <@wumpus> that would make all messages vector-able. Although it's a design choice at which level to do that...
05:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:46 < jonasschnelli> Bip151 encrypted message packaging (https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#encrypted-messages-structure) allows that. Because from the protocol perspective, combining them seems to have no downside
05:46 < jonasschnelli> Which is different when we look at the implementation
05:46 <@wumpus> oh that's already possible
05:46 <@wumpus> I don't see the problem then, or motivation for looking at few-byte wins in the header
05:47 <@wumpus> the implementation could be smart about it: queue up messages until a certain threshold is reached or timeout
05:47 <@wumpus> like TCP nagle algorithm
05:47 < jonasschnelli> I think switching to encrypted traffic gives us kind of a one-time chance to improve the message structure. I just try to consider every possible optimization.
05:47 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
05:47 < jonasschnelli> Yes. I have discussed that yesterday with cfields. A timeout until messaged gets combined..
05:47 <@wumpus> do beware scope creep
05:48 < jonasschnelli> Good point.
05:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
05:51 <@wumpus> in any case: those implementations are possible, they have been done many times before. I wouldn't worry too much about optimizing current implementtions when desiging a protocol
05:51 <@wumpus> optimizing for
05:51 <@wumpus> this needs to be future proof because we don't want to be in the same situation again in say, 5 years
05:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:52 <@wumpus> also means security should be adequate: don't reduce the MAC tags to near current security bounds
05:54 < jonasschnelli> ack     
05:55 -!- harrymm [~wayne@104.222.140.94] has joined #bitcoin-core-dev     
05:56 -!- striker227 [44e49d64@gateway/web/freenode/ip.68.228.157.100] has joined #bitcoin-core-dev     
05:56 -!- striker227 [44e49d64@gateway/web/freenode/ip.68.228.157.100] has quit [Client Quit]     
06:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
06:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has joined #bitcoin-core-dev     
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has quit [Changing host]     
06:21 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
06:21 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host]     
06:21 -!- owowo [ovovo@gateway/vpn/mullvad/x-furilvcnmnzeullu] has joined #bitcoin-core-dev     
06:24 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]     
06:27 -!- Guyver2__ is now known as Guyver2     
06:58 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
07:00 -!- aalex_ [~aalex@64.187.177.58] has quit [Remote host closed the connection]     
07:03 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/e5364991daec...71bc39eb7483
07:03 < bitcoin-git> bitcoin/master b2e178a Matt Corallo: Add deserialize + CheckBlock benchmarks, and a full block hex
07:03 < bitcoin-git> bitcoin/master eecffe5 Matt Corallo: Remove redundant duplicate-input check from CheckTransaction
07:03 < bitcoin-git> bitcoin/master e2b3fb3 Matt Corallo: Optimize vInOutPoints insertion a bit
07:03 < bitcoin-git> [bitcoin] laanwj closed pull request #9049: Remove duplicatable duplicate-input check from CheckTransaction (master...2016-10-bench-checkblock) https://github.com/bitcoin/bitcoin/pull/9049
07:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:17 -!- abpa [~abpa@2604:5500:16:6:2c68:e018:be3d:5d83] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
07:22 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
08:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-inicnahqycfyiwex] has quit [Quit: Connection closed for inactivity]     
08:13 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has quit [Quit: .]     
08:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xamadexnyqydpwan] has joined #bitcoin-core-dev     
08:18 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:91f9:27c7:8aeb:50cf] has joined #bitcoin-core-dev     
08:34 -!- testnet [~testnet@gateway/tor-sasl/testnet] has joined #bitcoin-core-dev     
08:39 < sipa> jonasschnelli: openssl just reported a dos attack bug in their chacha20-poly1305, we may want to verify if we'd be susceptible
08:40 < sipa> jonasschnelli: if you want to shave off some bytes, make the command codes variable length
08:42 < sipa> or they could be made lowercase only, and use bitpacking to map 12-character strings to 64-bit values ;)
09:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
09:14 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection]     
09:18 -!- laurentmt [~Thunderbi@80.215.178.71] has joined #bitcoin-core-dev     
09:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
09:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
09:22 -!- laurentmt [~Thunderbi@80.215.178.71] has quit [Client Quit]     
09:26 < cfields> BlueMatt: ping. I still need help understanding the race comment in #9075.
09:27 < gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
09:30 < gmaxwell> The TCP/IP overhead is already pretty large, so reducing the command size is less relative improvement than you might think.
09:32 < gmaxwell> I think in gneral we'd be better off defining batch operations, like how an inv contains many items.
09:32 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
09:34 < gmaxwell> sipa: lol base-32, 5*12 = 60. 
09:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
09:36 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-ctgdweobnuquhglt] has quit [Ping timeout: 260 seconds]     
09:39 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-yffvmqugbxgpzcnf] has joined #bitcoin-core-dev     
09:40 < sipa> gmaxwell: base 26 * 12 = 57 bits
09:45 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:50 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:52 -!- laurentmt [~Thunderbi@80.215.178.71] has joined #bitcoin-core-dev     
09:52 -!- laurentmt [~Thunderbi@80.215.178.71] has quit [Client Quit]     
09:55 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
09:55 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
09:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
10:00 < gmaxwell> sipa: you think people complain about endianness, make them pack a non-power of two range... :P
10:01 -!- whphhg [whphhg@gateway/vpn/mullvad/x-auuhcnhldzjvcrfx] has joined #bitcoin-core-dev     
10:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
10:36 < BlueMatt> cfields: I think its dependant on multithreaded-peer-logic
10:37 < cfields> BlueMatt: ok, so the issue is that it drops the lock and then re-takes it, and in the meantime, the nodeid could've changed (if multi-threaded) ?
10:38 < BlueMatt> cfields: if you have two block sources at once
10:38 < cfields> right
10:38 < BlueMatt> or, eg, you have a node which gives you a block and then you submitblock the same block
10:39 < jtimon> ping https://github.com/bitcoin/bitcoin/pull/8855
10:39 < cfields> BlueMatt: in that case though, if it's a full block that's submitted, the ban bool could be switched as well, so it'd be possible to skip punishing a peer who's sent a bad full block?
10:39 < cfields> or am i misreading?
10:40 < cfields> (i'm just wondering if it makes sense to switch to a multimap, so that every node gets the correct response)
10:41 < BlueMatt> cfields: huh? no, I'm saying in thread a) a peer adds itself to mapBlockSource as the person to punish, then in thread b) another peer adds itself, then the block is processed from peer a...peer b doesnt get processed as "already rejected" but doesnt get the punishment for invalid block, either
10:41 < BlueMatt> i highly dont think it matters
10:44 < sipa> turn mapBlockSource into a multimap?
10:45 < cfields> sipa: heh, see 3 lines up :)
10:46 < cfields> i just don't see why we'd complicate possible future logic if we could easily guarantee that everyone gets the correct response
10:48 < BlueMatt> huh? I mean if they're on an invalid chain we'll ban them on the next block anyway
10:49 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
10:53 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
10:53 < cfields> BlueMatt: Is there some advantage to leaving it this way? "we'll get it eventually" seems like a strange argument here.
10:54 < BlueMatt> code diff? ease of change?
10:54 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.]     
10:55 < jonasschnelli> sipa: BIP151 has varlen command codes
10:55 < sipa> jonasschnelli: oh!
10:55 < sipa> jonasschnelli: then who cares
10:55 < jonasschnelli> Yes. I think this should be sufficient.
10:55 < BlueMatt> cfields: also, DoS needs to die
10:55 < BlueMatt> cfields: so we can fix it then
10:57 < jonasschnelli> sipa: I have started extracting ChaCha20 and Poly1305 from openssh (IEFT ChaCha20Poly1305 as well as ChaCha20Poly1305@openssh) https://github.com/jonasschnelli/chacha20poly1305
10:57 < jonasschnelli> I will pass it over to you soon.. :)
10:57 < jonasschnelli> I just wanted to make some benachmarks
10:57 < sipa> jonasschnelli: i'm not going to even look at it until the network refactors are done
10:57 < sipa> jonasschnelli: i expect it to be very easy
10:57 < cfields> BlueMatt: i suppose it's not getting worked up about if it requires multithreading anyway
10:58 < BlueMatt> cfields: my target for multithreading is 0.14, though I highly doubt I'll make that
10:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:02 < sipa> meetingh?
11:02 < jonasschnelli> yes     
11:03 <@wumpus> #startmeeting
11:03 < lightningbot> Meeting started Thu Nov 10 19:03:00 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:03 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:03 <@wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012
11:03 < kanzure> hi.     
11:03 <@wumpus> proposed topics?
11:03 < paveljanik> Hi     
11:03 < btcdrak> holidays
11:03 -!- MarcoF____ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev     
11:03 < BlueMatt> reasons why there is no way in hell we could multithread ProcessMessages in 0.14
11:04 < BlueMatt> :)     
11:04 < achow101> oh, meeting already?
11:04 < jonasschnelli> Not sure if it's OT or not, but if possible, it like to propose a short topic "concept of hybrid SPV"
11:04 < BlueMatt> anyone else just want a bloom filter commitment soft fork for that?
11:04 < cfields> jonasschnelli: yes please
11:04 <@wumpus> #topic hybrid SPV
11:04 < jonasschnelli> I wanted to ask if we'd like to see some form of "SPV" (wrong term, i agree) mode in Bitcoin-Core, if it's worth to continue the work
11:05 < jonasschnelli> IMO it could affect the userbase
11:05 < kanzure> was this about initial block download?
11:05 < jonasschnelli> (from expertish to novicish)
11:05 <@wumpus> I think the idea has always been to have some kind of SPV mode in bitcoin core, yes
11:05 < sipa> why would it be a wrong term?
11:05 < kanzure> "SPV" was the one about fraud proofs etc
11:06 < sipa> ok, "client mode" as bitcoin's creator called it then
11:06 < jonasschnelli> I like SPV, ... but some people told me SPV implies bloom filters. I somehow disagree with that though
11:06 <@wumpus> even if full block SPV without bloom filters
11:06 < jonasschnelli> I think full block hybrid SPV sounds ideal IMO
11:06 < BlueMatt> ^ that
11:06 <@wumpus> no, it doesn't need bloom filters. Say you want to do SPV against a local node which stores the block chain anyway, there's no need for bloom filters
11:07 < jonasschnelli> Once we have 150/151, we could add bloomfiltering options against bip150 authed peers.
11:07 < BlueMatt> preferably not
11:07 < sdaftuar> jonasschnelli: hybrid spv means it starts out as spv, but eventually becomes fully validating?
11:07 < jonasschnelli> sdaftuar: right.
11:07 <@wumpus> and yes could always be added later, if there is a sane way of filtering that doesn't throw all your privacy out of thew indow
11:07 < BlueMatt> better designs are possible, but for full blocks agreed
11:07 < sdaftuar> jonasschnelli: sounds awesome!
11:07 < NicolasDorier> I'm bit lost here, why is it called SPV if the node store the blockchain oO
11:07 < BlueMatt> NicolasDorier: SPV here is referring to the trust model of trusting miners
11:07 < NicolasDorier> is there some past discussion somewhere about it I can read ?
11:08 <@wumpus> NicolasDorier: no, it doesn't need to store it
11:08 < jonasschnelli> For those who haven seen it, there a full working PR for the hybrid SPV: https://github.com/bitcoin/bitcoin/pull/9076
11:08 < kanzure> the level of confusion around naming and name-implications is really high. it's sort of amusing.
11:08 <@wumpus> NicolasDorier: it just receives the blocks, filters them locally intead of setting a bloom filter
11:08 < jonasschnelli> Haven't got conceptual ACKs and wasen't sure if its worth to continue, ... make it clean and stable, etc.
11:08 < NicolasDorier> how is it different from a pruned node?
11:08 < kanzure> if it's not immediately obvious to most of us that feature x is included (like block downloading or something) then we need better names :P
11:08 < jonasschnelli> NicolasDorier: it does no validation
11:09 <@wumpus> NicolasDorier: it would allow receiving transactions while validation is not complete yet, for example
11:09 < jonasschnelli> NicolasDorier: just header chainwork check and pass the transaction to the wallet
11:09 <@wumpus> a pruned node is a full node
11:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 268 seconds]     
11:09 < NicolasDorier> ah ok, so basically a node without UTXO ?
11:09 < jonasschnelli> The main difference is, that we load blocks during IBD first from the wallet brthday.
11:09 < jonasschnelli> NicolasDorier: yes. No UTXO set
11:09 < jonasschnelli> No mempool, same fee problem that all SPV wallets have to deal with
11:09 < NicolasDorier> ah ok got it
11:10 <@wumpus> pruning has nothing to do with SPV, full node has nothing to do with 'storing the block chain' or not
11:10 < jonasschnelli> But with the option of slowing becomming a full node
11:10 < btcdrak> jonasschnelli: I dont think anyone concept ack because it's so obviously a good feature.
11:10 <@wumpus> right, it is about the UTXO set
11:10 <@wumpus> jonasschnelli: I've been very busy, sorry
11:10 < jtimon> oh, I undesrtand the details now, headers first, then you are an spv node that fetches the full block instead of using bloom filter but you keep syncing on the background to become a full node, sounds all fine
11:10 <@wumpus> jonasschnelli: it's obviously a good idea
11:10 < BlueMatt> jonasschnelli: but still fill-blocks-in-background?
11:10 < BlueMatt> or are we moving away from that?
11:10 < BlueMatt> but, yes, obviously good
11:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:10 < jonasschnelli> BlueMatt: there are two modes, purespv and hybridspv
11:10 <@wumpus> BlueMatt: that should certainly be an option
11:10 < jonasschnelli> purespv will just throw away blocks...
11:11 < BlueMatt> oh, only optional? hum, not a fan of it only being optional
11:11 < jonasschnelli> hybrid spv will keep the blocks and does IBD in the background (maybe throttled)
11:11 <@wumpus> hybrid stores them for later
11:11 <@wumpus> BlueMatt: why not?
11:11 < morcos> jonasschnelli: +1 on the ability to throttle, think that would make it very useful
11:11 < BlueMatt> i mean you dont have to keep blocks, but you still want to ibd and build the utxo set
11:11 < BlueMatt>  /validate
11:11 < BlueMatt> wumpus: because if you're not gonna be upgrading to full trust model why are you running bitcoin core as a wallet?
11:11 <@wumpus> being able to use bitcoin core as a full SPV node would be useful, especially with a local node that does validate
11:12 <@wumpus> BlueMatt: why not?
11:12 < jonasschnelli> BlueMatt: if you throw away blocks with the long term goal of getting a full node your wasting bandwith
11:12 < BlueMatt> jonasschnelli: no, you're not!
11:12 < BlueMatt> jonasschnelli: you're upgrading your security model
11:12 < jonasschnelli> BlueMatt:: you have to download the block again!
11:12 < BlueMatt> jonasschnelli: huh? oh, you mean keeping the blocks at the tip that you're using to fill wallet...ahh, misunderstanding
11:12 < jonasschnelli> purespv is interesting when connecting to a trusted node.
11:13 <@wumpus> right
11:13 < BlueMatt> I'm not sure if its worth the effort to make bitcoin core a competitive spv wallet - they mostly all already support connecting to a trusted node (though need auth)
11:13 < jonasschnelli> fullblock SPV gets uninteresting if you import keys or watchonlys.. because we set the timestamp to 0 = download the whole blockchain
11:13 < achow101> so hybrid keeps blocks for later and purespv doesn't? Is that the only diference?
11:13 < BlueMatt> if someone wants to work on it I wont complain, but...
11:13 < jonasschnelli> achow101: right.
11:14 < BlueMatt> jonasschnelli: argh, I'm lost in your terms here
11:14 < btcdrak> Yeah I also think purespv seems wrong for Bitcoin Core.
11:14 < btcdrak> but w/e
11:14 < sipa> i don't see why
11:14 < jonasschnelli> achow101: hybrid means, your doing IBD with all its downsides...
11:14 < NicolasDorier> well bitcoin core has a wallet part
11:14 < sipa> bitcoin core has a perfectly good wallet
11:14 < BlueMatt> purespv? fullblock spv? define?
11:14 < sipa> seems stupid to restrict it to full node use only
11:14 < CodeShark> We really should drop the term spv
11:14 < jtimon> achow101: it seems also hybridspv does background ibd while pure doesn't
11:14 < achow101> ok     
11:14 < jonasschnelli> purespv = no IBD, hybridspv = SPV during IDB
11:15 < BlueMatt> jonasschnelli: wait, so what is fullblockspv?
11:15 <@wumpus> both
11:15 < btcdrak> I thought the point of the hybride SPV is just to make the wallet usable immediately during IDB, and put an end to the poor user experience for new users.
11:15 < BlueMatt> huh     
11:15 < jonasschnelli> Both. Yes.
11:15 < BlueMatt> what does both mean?
11:15 < jtimon> isn't hybridspv the same as "both"?
11:15 < sipa> BlueMatt: both hybrid and pure download full blocks
11:15 <@wumpus> no bloom filters are used in either case, it is all retrieving full blocks
11:15 < jonasschnelli> Both modes (pure and hybrid) are full block SPV modes.
11:15 < achow101> fullblock spv is where the full block is downloaded and the transaction is pulled. watever happens to the block is depended on hybrid or pure
11:15 <@wumpus> what is so hard to understand about that?
11:15 <@wumpus> achow101: right
11:15 < jonasschnelli> let me write a short post on bitcoincore ML
11:15 < BlueMatt> wumpus/sipa: ahh, just referring to the way we download in either case
11:16 < BlueMatt> wumpus: the way it was referenced it sounded like a different mode
11:16 < jonasschnelli> From the enduser perspective, the modes are very different
11:16 <@wumpus> the only difference is that in pure SPV mode, the blocks are thrown away and there is no IBD, in hybrid mode the blocks are backfilled and IBD happens
11:16 < BlueMatt> wumpus: yes, i was confused and thought there was a third mode
11:17 < jtimon> I see no problem with allowing purespv optionally, the default is going to be hybridspv, right?
11:17 <@wumpus> ok     
11:17 <@wumpus> jtimon: yes
11:17 < ryanofsky> in the pr, i suggested calling hybrid spv "prioritized download"
11:17 < jonasschnelli> purespv can solve an interesting usecase where one likes to decouple the wallet from the node
11:17 <@wumpus> jonasschnelli: exactly
11:17 < BlueMatt> jtimon: agreed, just saying that it seems a strange thing to focus work on...there are already good options for consumers on the purespv front
11:17 < BlueMatt> like, lots of good options
11:17 <@wumpus> jonasschnelli: it's basically a stand-alone wallet
11:18 < jonasschnelli> BlueMatt: purespv would be the only fullblock SPV wallet in the wild
11:18 < jtimon> BlueMatt: I suspect the reasoning is that it will be relatively cheap to add that extra mode
11:18 <@wumpus> BlueMatt: it is not *focusing* work on, it's just a by-effect of allowing it
11:18 < BlueMatt> wumpus: yup, I'm fine with it being a free feature, just making a note
11:18 < jtimon> maybe a pr with the hybrid default one and a later one adding the purespv mode would make sense
11:18 < achow101> purespv would be great for privacy
11:18 < jonasschnelli> not for bandwidth thought 
11:19 < sipa> BlueMatt: fair enough, but if we want hybrid spv because of the terrible syncing experience, we have all the pieces in place for purespv as well
11:19 < CodeShark> I still don't quite get purespv - sorry, scrolling back and keeping up is hard
11:19 <@wumpus> sigh.\
11:19 < jonasschnelli> purespv = plain full block SPV
11:19 <@wumpus> any other topics?
11:19 <@wumpus> we're starting to repeat ourselves and that is annoying
11:19 < gmaxwell> hah     
11:19 < jonasschnelli> download block, no validation, extract relevavnt txs
11:19 < CodeShark> ok     
11:19 < jonasschnelli> Okay. I'll continue and try to make small PRs (could be hard though). Thanks
11:20 <@wumpus> please just read back if you want to know things that have been discussed before, we can't repeat every single thing specifically for everyone
11:20 < BlueMatt> topics?
11:20 < MarcoF____> topic suggestion: 0.14
11:20 < CodeShark> I'd rather discuss bloom filter commitments or clientside bloom filtering from trusted nodes
11:20 <@wumpus> #topic  multithread ProcessMessages
11:20 < MarcoF____> Personally I mostly care about multiwallet refactoring for 0.14
11:21 < MarcoF____> but there are plenty of other pulls open, so we might want to prioritize?
11:21 <@wumpus> BlueMatt ^^
11:21 < BlueMatt> i mean i think we all want multiple message-processing threads
11:21 < jonasschnelli> +1     
11:21 < gmaxwell> Sorry, I delayed matt by asking him about it offline.  My only comment was "don't reorder messages from a single peer!" :P but apparently I'm behind the times.
11:21 < BlueMatt> and while it probably wont be so useful with cs_main at the head of like every message, I'd like to see plumbing for it sooner rather than later
11:21 <@wumpus> well if cs_main usage is brought down enough, that will start to make sense
11:22 < BlueMatt> then people can remove cs_main one message at a time and it will be useful
11:22 < BlueMatt> I'd be happy to see, but dont know if we'll make, cs_main split-outs too much for 0.14 (thats next after main.cpp split)
11:22 < BlueMatt> but I'd like to see a few free wins like being able to respond to getblocktxn requests while a block is processing
11:23 < gmaxwell> okay, thanks for the concrete example of something pretty useful.
11:23 < BlueMatt> anyone have any thoughts on blockers for this? things likely to break? etc?
11:23 < cfields> BlueMatt: seems unlikely to have any real-world benefit without breaking out CNodeState? Maybe we should try to knock that out first?
11:23 < gmaxwell> I was struggling to come up with one, but that one is good.
11:23 <@wumpus> being able to service multiple nodes at once would be very useful
11:24 < BlueMatt> cfields: why do you have to break out CNodeState? you'll never call ProcessMessages in two threads for a single peer at the same time
11:24 < BlueMatt> cfields: that would violate our serialization stuff
11:24 < gmaxwell> Yes, in particular being able to reply to getblocktxn multiple times in parallel should reduce block relaying delays.
11:25 < BlueMatt> gmaxwell: yes, i really want it for FIBRE-based relay network - respond to getblocktxn from a shared_ptr<const CBlock> block_currently_processing
11:25 <@wumpus> I mean looking at it from the other side, there's no good reason for keeping doing message processing only in one thread
11:25 < morcos> BlueMatt: I think its going to be important to do a thorough review of synchronization issues first.  Sometimes I feel like things just happen to not be a problem b/c they are only accessed from the single thread.
11:25 < BlueMatt> morcos: yea, thats my concern :(
11:25 < cfields> BlueMatt: well when each one is grabbing for cs_main, it only takes one long lock to drop us back to single-threaded
11:25 < morcos> We do an ok job of fixing these missing locks when we find them, but if we're goign to make multiple message processing threads, we need to make sure we've really got them all
11:25 < BlueMatt> morcos: any concrete things i should be looking for
11:25 < morcos> I think we should make a list of what needs to be protected by cs_main
11:26 < BlueMatt> cfields: yea, I mean I'm ok with switching to a multi-threaded model that does ~nothing and then slowly reducing the locks
11:26 < gmaxwell> So I think making process message concurrent may create greater exposure for data races around the nodestats.  Right now the locking around stats is _widely_ incorrect, leading to undefined behavior. (I haven't been watching closely and cfields likely improved a lot of it recently, but I expect there are still problems)
11:26 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
11:26 < gmaxwell> (this is responsive to matt's question about likely sources of problems)
11:27 < sipa> gmaxwell: for stats we can just change them all to atomics
11:27 < gmaxwell> I recommend that we run testing harnesses with valgrind DRD and try to get this change to be data race free at least according to DRD.
11:27 < BlueMatt> gmaxwell: good suggestion, indeed
11:27 < gmaxwell> sipa: I made that suggestion previously. I think we access them infrequently enough that it's not an awful idea.
11:28 < sipa> gmaxwell: you can also cache per peer, and flush to a locked global occasionally if it's a concern.
11:28 < sipa> stats are easy, no consistency requirements
11:28 < gmaxwell> last time I ran DRD I saw some races around stats but there wasn't a wall of errors.
11:28 <@wumpus> and the per-node stats should not be an issue as we likely don't want to be processing two messages from the same peer at the same time?
11:28 < cfields> sipa: that sounds like a good model
11:29 < sipa> wumpus: indeed
11:29 < BlueMatt> wumpus: yes, that would reduce lots of issues
11:29 < gmaxwell> wumpus: I suspect we can get a message from peer A that causes use to iterate over all the other peers stats.
11:29 < sdaftuar> BlueMatt: have you given much thought to how the threading logic would work?
11:29 < sdaftuar> i mean, how you'd decide how to split work across threads
11:29 < gmaxwell> (just an example why single peer at a time doesn't automatically mean thread safty of per node stats)
11:29 <@wumpus> gmaxwell: that sounds scary
11:30 < gmaxwell> (maybe we don't actually do that anywhere, at least in response to a message... a connection, for example, causes that--)
11:30 < BlueMatt> sdaftuar: hum? do we need anything more complicated than just a thread pool each looking for peers that have available work and arent being worked on that just wait on a cv when there is nothing to do
11:30 -!- MarcoF____ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
11:30 <@wumpus> gmaxwell: no, but keeping to rules like that will make it easier manageable
11:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:31 < gmaxwell> Another point to keep in mind is thread prolifervation and address space usage on 32-bit hosts. Not a reason to not do this, but just a cost.
11:31 < sdaftuar> well, my thought was that since most messages are tx's, we might find ourselves tying up all our threads but unable to continue, as they're all contending on cs_main
11:31 < sdaftuar> so you wouldn't necessarily be able to respond to a getblocktxn while processing a block
11:31 < sdaftuar> you could do somethign smarter though...
11:31 <@wumpus> gmaxwell: it would still be possible to run with only one thread I suppose
11:31 <@wumpus> gmaxwell: I'm not terribly worried
11:32 < BlueMatt> sdaftuar: yes, i was thinking for v1 we ignore that issue
11:32 < sdaftuar> ok :)
11:32 < gmaxwell> wumpus: I'm not either.
11:32 < BlueMatt> sdaftuar: indeed, eventually we could have some "oh, these messages take cs_main" list to make it smart
11:32 < gmaxwell> Besides, this is a better use of threads (actual concurrency) than some others we have had.
11:32 < BlueMatt> gmaxwell: very true :(
11:32 <@wumpus> gmaxwell: we certainly shouldn't be restricting work towards better performance because there happen to be a few nodes on small systems, those can be handled specifically
11:33 < gmaxwell> (e.g. connect has a thread, wallet flush thread, etc.) 
11:33 < BlueMatt> we can make up the difference by moving wallet flush into cscheduler thread :)
11:33 < gmaxwell> wumpus: agreed, I am just exposing areas of consideration. I support the work.
11:33 <@wumpus> (and I run most of my nodes on 32-bit ARM so it's not like I don't care)
11:33 < BlueMatt> well, and like three net threads to cscheduler
11:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
11:33 <@wumpus> yes, we can do thread-stack accounting like that, but let's not get lost in details
11:34 < morcos> and while we're at it we can increase script checking threads :)
11:34 < petertodd> wumpus: oh, on rpi's and the like?
11:34 <@wumpus> petertodd: cubox-i's are my favourite
11:34 < petertodd> wumpus: interesting, thanks!
11:35 <@wumpus> next topic, I suppose
11:35 < gmaxwell> (there are other possibilties like decresing the stack size on some threads that don't do much, firefox uses 128k or 256k (I forget) stacks for media processing threads.  So I really don't at all think it's a blocker, just something to keep in mind.)
11:36 <@wumpus> gmaxwell: indeed you can do that through an environment variable IIRC, I think I even list it in my "reducing bitcoind memory usage" document ,if not I should
11:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:36 <@wumpus> #topic 0.14
11:36 <@wumpus> @MarcoFalke
11:37 < jonasschnelli> multiwallet support would be nice
11:37 <@wumpus> oh he left?
11:37 < gmaxwell> wumpus: yes, well you can control it for all threads in an env variable --- though that can result in security problems. :(  But there are some threads where their stack usage is precisely decidable easily. (e.g. the connect thread).
11:37 < jtimon> yep, it seems so
11:37 -!- MarcoFalk_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev     
11:37 < jonasschnelli> [20:36:29]  <@wumpus>	#topic 0.14
11:37 < jonasschnelli> [20:36:49]  <@wumpus>	@MarcoFalke
11:38 < BlueMatt> MarcoFalk_: 
11:38 < bitcoin-git> [bitcoin] morcos opened pull request #9123: Remove extraneous LogPrint from fee estimation (master...eliminateFeeWarning) https://github.com/bitcoin/bitcoin/pull/9123
11:38 < MarcoFalk_> Jup, I'd like to hear what is a priority to get in to 0.14
11:38 < jtimon> multiwallet refactoring for 0.14
11:38 < MarcoFalk_> ^     
11:38 <@wumpus> gmaxwell: I'm not sure about security problems, though yes it can cause crashes if you set it that low that the stack underflows
11:38  * jonasschnelli gives MarcoFalk a IRC bouncer for birthday
11:38 < BlueMatt> main.cpp split, but thats guaranteed at this point, pretty much
11:38 < sdaftuar> i think the validation speedups from jeremyrubin would be great for 0.14
11:38 < MarcoFalk_> Ok, what is the progess on the net refactor. Is it almost done?
11:39 <@wumpus> gmaxwell: then again the thread stacks are extremely small on some platforms
11:39 <@wumpus> gmaxwell: linux assigns quite a lot by default
11:39 < BlueMatt> sdaftuar: yea, at least the cucku cache thing
11:39 < jonasschnelli> I think there is not much left for the multi-wallet support. Though, not sure if we can make this happen for 0.14
11:39 < jonasschnelli> Also.. we should add a private-key free mode.
11:39 < jonasschnelli> A safe-mode
11:39 < gmaxwell> sdaftuar: I agree, all of them. 
11:39 <@wumpus> if we all agree to start reviewing wallet changes, I'm sure we can get multi wallet support in 0.14
11:39 < jtimon> I would like to move on libconsensus, but so far nothing seems to be happening on that front
11:40 < MarcoFalk_> Some of the wallet changes need rebase
11:40 < jonasschnelli> wumpus: Nice! I can review some stuff next week.
11:40 < gmaxwell> In terms of wallet features I think some kind of multiwallet support would have the greatest ratio of benefit to cost+risk.
11:40 < gmaxwell> It's just software eng.
11:40 < jonasschnelli> gmaxwell: ack!
11:41 < jonasschnelli> Also, with the current fundrawtransaction options, you can perfectly run watch-only wallets
11:41 < cfields> I'm aiming to get net.h/cpp split in half in the next ~week also.
11:41 < jonasschnelli> So.. theres a project: https://github.com/bitcoin/bitcoin/projects/2
11:42 < jonasschnelli> for MW support
11:42 < cfields> (for the 0.14 list)
11:42 < gmaxwell> So I think multiwallet should be a greater priority.  Also while 0.14 has a lot of really great infrastructural changes, I think it has relatively few ordinary user visible improvements.
11:42 < paveljanik> Network on/off in GUI please :-)
11:42 < jonasschnelli> paveljanik: Yes. I'll make that happen soon.
11:42 <@wumpus> because most of the focus has been on 0.13.1, 0.14 will be somewhat of a smaller release, I don't think that's a problem
11:43 < gmaxwell> There are a number of other things I'd like to work on, like more bandwidth usage controls. Improvement to header fetching logic... but I think it's not useful to speak to work that hasn't even started.
11:43 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome]     
11:43 < jonasschnelli> I was hoping the mempool stats can be in 0.14... but not sure if there are enough reviews
11:43 < BlueMatt> bumpfee
11:43 < MarcoFalk_> I was pinging luke-jr on #8776, but haven't heard anything about luke-jr recently
11:43 < gribble> https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
11:43 < MarcoFalk_> Hope hes doing fine
11:43 < paveljanik> jonasschnelli, mempool stats: count with me for review!
11:44 < jonasschnelli> BlueMatt: yeah! Bumpfee should get some review. Guys! https://github.com/bitcoin/bitcoin/pull/8456
11:44 < paveljanik> it would be nice to have a estimatefee 2, 3, 4 graph also...
11:44 <@wumpus> cfields: weren't you working on bandwidth throttling w/ the P2P libevent switch?
11:44 < MarcoFalk_> paveljanik: I think the review-intense part is #8501
11:44 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
11:44 < gmaxwell> We'll see what shows up, in any case.
11:44 <@wumpus> yeah there's not much point in listing all major open pulls here now
11:44 < MarcoFalk_> paveljanik: The gui change is rel. simple
11:45 < jonasschnelli> Yes. #8501 is groundwork for mempool stats. Has no review so far
11:45 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
11:45 <@wumpus> we know about them, what they need is more review and testing :)
11:45 < MarcoFalk_> (and rebase) *ducks*
11:45 < morcos> I'm going to do at least some minor (and needed) improvements to fee estimation.  Is  there any interest on estimates for longer than 25 blocks?  Or should I continue to punt on that?
11:45 < cfields> wumpus: yes, i don't think that's likely for 0.14 though. The libevent changes are going to be quite different from what I originally intended, I think
11:45 < gmaxwell> WRT review, I believe that multiwallet review is fundimentally easier than bumpfee for example, because in bumpfee I need to reason about a complex state machine, the effect on the network, corner cases with double spends, etc.  And multiwallet is 98% "does this crash or not". :)
11:45 <@wumpus> cfields: it's taking quite longer than we expected :)
11:46 <@wumpus> gmaxwell: so start reviewing multiwallet pulls then :D
11:46 < BlueMatt> wumpus: lol, doesnt everything
11:46 <@wumpus> (or did you already?)
11:46 < gmaxwell> morcos: mempool backlog levels are not great enough where estimates >25 blocks matter that much I think, currently.
11:46 < jtimon> btw maybe we can talk about the "custom mode" (separately from the blocksigning mode which I think it's unlikely to get to master with the union and the global, but we can just rebase every release)
11:46 < cfields> wumpus: yes, sorry for that. I vastly underestimated the refactor impact.
11:46 <@wumpus> BlueMatt: yes, I'm kind of overwhelmed already, so I don't care that much some things are going slower
11:47 < morcos> gmaxwell: But its often possible to pay a much lower fee if you are willing to wait 100 blocks or whatever...  So in the interest of keeping fees down.., but I just don't know if thats much of a use case.
11:47 < gmaxwell> morcos: fun graph, fee availble at the time of a block (red) vs immediately after (green): https://people.xiph.org/~greg/temp/fee_avail.png  thats a week of data,  also a different reason during the high fee floods a couple weeks ago: https://people.xiph.org/~greg/temp/fee_avail2.png
11:48 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
11:48 < gmaxwell> morcos: interesting, if it would make a big difference I think it would be interesting. I wasn't thinking it would make much of a difference.
11:48 <@wumpus> cfields: my worry is that some things are blocked on it, e.g. gmaxwell talks about wanting to do things with bandwidth management, those things would all be easier if we had switched to libevent, instead of trying to cram it into the current networking backend
11:48 < gmaxwell> morcos: I still wouldn't priortize it over general improvements.
11:48 -!- gabridome [~gabridome@87.18.61.184] has quit [Client Quit]     
11:49 < morcos> gmaxwell: tremendous difference. i'm pretty sure you could always pay about 2 sat/byte if you are wiling to wait a couple days..  limiting factor might be the 3 day eviction.
11:49 < gmaxwell> Yes, I've held off on doing too much more with bandwidth management due to that.  There are somethings we can do, for example delaying inv relays when bandwidth starved.
11:49 < cfields> wumpus: ACK. I'll pick up the pace.
11:49 < gmaxwell> morcos: my publically reachable nodes don't really expirence 3 day eviction, -- some clown or another inevitably connects and restores the evicted stuff. :P
11:50 < sipa> gmaxwell, cfields: it sounds to me like the bandwidth management you're talking about is very different and probably won't have much code conflicts
11:50 < sipa> as gmaxwell is talking about application level decisions that afaik don't even affect anything at the network layer
11:50 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
11:50 < gmaxwell> Well I specifically just mentioned the part of the management scope that wouldn't have conflicts. (and I think should probably be done first:  to quickly offer something but then relay it out slowly is somewhat peer abusive. :P )
11:51 < cfields> sipa: indeed
11:53 <@wumpus> other topics?
11:54 < gmaxwell> we should say hello to all the americans that missed the timezone change.
11:54 < gmaxwell> and are just arriving now. :P
11:54 < jcorgan> heh     
11:54 < petertodd> gmaxwell: canadians too :)
11:54 < gmaxwell> Hi guys.
11:55 < achow101> hi     
11:55 < gmaxwell> Welcome to the end of the meeting.
11:55 <@wumpus> yes, welcome
11:55 < sipa> kthxbye
11:55 <@wumpus> #endmeeting
11:55 < lightningbot> Meeting ended Thu Nov 10 19:55:51 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:55 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-10-19.03.html
11:55 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-10-19.03.txt
11:55 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-10-19.03.log.html
11:56 < sipa> lunch?
11:56 < btcdrak> petertodd: you mean snow mexicans right?
11:56 < petertodd> btcdrak: nah, we're the ones building a wall
11:56 < jcorgan> no, they are 51st state-ians
11:56 < petertodd> sipa: sure, there's a nice diner near me
11:57 < paveljanik> MarcoFalk_, 8501 is part of 8550...
11:57 < petertodd> jcorgan: in a few years you're going to be saying canadafornia's
11:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
11:58 < jonasschnelli> petertodd: yes. 8501 can work without 8550 and has the most bitcoin-core wide impact.
11:58 < jcorgan> true dat
11:58 < jonasschnelli> Ahm,.. meant paveljanik 
11:58 < jcorgan> actually, i like how that sounds
11:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
11:59 < instagibbs> lol timechange :)
11:59 < BlueMatt> #8501, #8550
11:59 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
11:59 < gribble> https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
12:00 < instagibbs> " we should say hello to all the americans that missed the timezone change." hmmm 
12:01 < paveljanik> HELLo ;-)
12:01 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
12:02 < instagibbs> I usually miss it anyways since it's not on my calendar and thursdays are my most productive day :P
12:02 < instagibbs> will add to cal
12:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:02  * jcorgan starts putting all his calendar events in UTC
12:02 < BlueMatt> jcorgan: you want iceland time
12:03 < MarcoFalk_> Maybe trump drops DST
12:03 < instagibbs> at blockstream we have this issue a lot so everything is on iceland time
12:03 < achow101> why iceland?
12:03 < jonasschnelli> MarcoFalk_: lol
12:03 < paveljanik> there will be TST soon...
12:04 < Chris_Stewart_5> oh damn, meeting moved up by an hour now for Americans? 
12:04 < achow101> Chris_Stewart_5: daylight savings...
12:04 < sipa> achow101: iceland is 100% of the year in UTC
12:04 < BlueMatt> achow101: iceland == utc
12:04 < BlueMatt> no dst
12:04 < achow101> oh. til
12:04 < sipa> (which makes no sense, geographically they should be at +1 all the time)
12:04 < jcorgan> wish they'd just drop time zones altogether
12:04 < sipa> jcorgan: one per continent may make sense
12:05 < jcorgan> hmm, maybe we can change our time zone when we become New Canadafornia
12:05 -!- harrymm [~wayne@104.222.140.94] has quit [Ping timeout: 260 seconds]     
12:06 < instagibbs> ok, set to 7pm iceland time, should be good now
12:06 < jtimon> instagibbs: not everything is on iceland time :(
12:06 < gmaxwell> achow101: google software doesn't have a 'UTC' option (because braindamage, I guess), fortuately iceland is equivilent.
12:07 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer]     
12:08 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
12:08 < jcorgan> thanks for the iceland tip
12:08 < achow101> ohh.
12:08 < sdaftuar> BlueMatt: let's get #9058 merged, these spurious test failures are annoying...
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9058 | Fixes for p2p-compactblocks.py test timeouts on travis (#8842) by ryanofsky · Pull Request #9058 · bitcoin/bitcoin · GitHub
12:19 -!- Cory [~Cory@unaffiliated/cory] has quit []     
12:25 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
12:28 -!- harrymm [~wayne@104.222.140.101] has joined #bitcoin-core-dev     
12:38 <@wumpus> what's holding #9058 back?
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/9058 | Fixes for p2p-compactblocks.py test timeouts on travis (#8842) by ryanofsky · Pull Request #9058 · bitcoin/bitcoin · GitHub
12:39 < bitcoin-git> [bitcoin] paveljanik opened pull request #9124: Use better name for local variable to prevent -Wshadow compiler warning (master...20161110_Wshadow_benchcheckblock) https://github.com/bitcoin/bitcoin/pull/9124
12:40 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome]     
12:42 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
12:42 < sdaftuar> wumpus: i think it's good to go, but thought bluematt might want to review since it is a (very small) change to BIP 152
12:46 -!- gabridome [~gabridome@87.18.61.184] has quit [Ping timeout: 248 seconds]     
12:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xamadexnyqydpwan] has quit [Quit: Connection closed for inactivity]     
12:54 -!- MarcoFalk_ [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
12:59 -!- go1111111 [~go1111111@104.200.154.47] has quit [Ping timeout: 268 seconds]     
13:01 < bsm1175321> What is the plan for the MSG_FILTERED_WITNESS_BLOCK message?  (spv + segwit...)
13:01 < bsm1175321> or block type rather in inv/getdata
13:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
13:06 < gmaxwell> bsm1175321: for most SPV wallets the witness is useless and not desirable.
13:06 < gmaxwell> Without the pubkey they can't verify it.
13:06 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
13:07 < gmaxwell> bsm1175321: I think many people would be glad to work on a spec for that with clear applications.
13:07 < gmaxwell> But I expect most (though not all) SPV segwit wallets to not use it.
13:07 < bsm1175321> Which pubkey?  The witness contains the pubkeys no?
13:08 < gmaxwell> The scritpubkey.
13:08 < bsm1175321> I was surprised to find the bcoin library setting this flag on testnet...spent a day tracking down why 0.13.1 wasn't responding to my getdata...
13:08 < gmaxwell> Setting what flag?
13:09 < bsm1175321> MSG_FILTERED_WITNESS_BLOCK
13:09 < bsm1175321> on getdata queries
13:09 < bsm1175321> Clearly a bug for bcoin...anyhoo
13:10 < bsm1175321> What do you have in mind for "a spec with clear applications"?
13:15 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
13:15 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome]     
13:16 -!- tulip [uid192128@gateway/web/irccloud.com/x-wmoyuwyrrjekxwlr] has joined #bitcoin-core-dev     
13:18 < tulip> bsm1175321: similarly BIP37 hashes items in the scriptpubkey individually and adds them to the filter. 
13:23 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
13:23 < tulip> MSG_FILTERED_WITNESS_BLOCK would regrettably have to do the thing where the witness of a matching transaction is serialised and inserted back into the filter as well. 
13:24 < bsm1175321> Woah I had no idea the BIP37 filters are applied to *any* data element in your script.
13:27 < tulip> the transaction, the TXID, the serialised inputs, every data element in any script. 
13:31 < Chris_Stewart_5> tulip: I don't think the entire txs is checked, and I think it is only the outpoints in the inputs? 
13:32 < Chris_Stewart_5> + date elements in the script like you said
13:33 < tulip> Chris_Stewart_5: you're right that it doesn't match the entire transaction, just the hash. I think the other parts of my comment are correct looking at the specification. 
13:33 -!- juscamarena [~jus@2607:f380:a61:650:bcfe:aea5:c6f5:f3e6] has joined #bitcoin-core-dev     
13:43 < gmaxwell> yea, that 'feature' really contributes to the lack of privacy and utiliy of BIP37.
13:43 -!- FreeUser [~yaaic@191-99-179-94.pool.ukrtel.net] has joined #bitcoin-core-dev     
13:43 < FreeUser> Hello.
13:43 < FreeUser> The alert system will be removed, yes?
13:44 < FreeUser> But how users will receive info about critical bugs?
13:45 < gmaxwell> it was removed a long time ago, it is only now being deactivated for older software.
13:45 < gmaxwell> FreeUser: same way they recieve news about anything.
13:47 < FreeUser> How to disable alerts in old Bitcoin Core versions?
13:48 < gmaxwell> FreeUser: there is a final alert which will be sent which causes a final alert to be displayed which cannot be overridden by any other alert.
13:49 < FreeUser> Are alerts stored in blockchain?
13:49 < gmaxwell> No.     
13:50 < FreeUser> But how users received these alerts?
13:50 < gmaxwell> bsm1175321: there is only one application that I'm currently aware of for a SPV wallet to see witness data: so a multisignature wallet can track which of the signers signed their own coins.
13:51 < gmaxwell> FreeUser: they were sent peer to peer between indivigual nodes.
13:53 < FreeUser> What will happens with Litecoin/other altcoin?
13:53 < FreeUser> *altcoins
13:53 < gmaxwell> nothing, they're totally seperate systems
13:54 < FreeUser> Why Litecoin not updating Litecoin Core?
13:55 < bsm1175321> gmaxwell I'm interested in SPV clients getting witness data because I'm using the spent pubkeys for out-of-band auth and communication.
13:55 < FreeUser> Is it hard to fork newer version and change it like old?
13:55 < sipa> FreeUser: ask them
13:55 < sipa> litecoin is offtopic here
13:56 < gmaxwell> bsm1175321: the public keys are in the paying transactions txouts. 
13:56 < FreeUser> What is difference between 0.13.1 and 0.13.99?
13:56 < FreeUser> And why 99?
13:57 < sipa> FreeUser: 0.13.99 is the version number used in the 0.14 branch before 0.14 is released
13:57 < sipa> FreeUser: at this point we have 0.14 branch with more significant changes, and a stable 0.13 branch that only receives bug fixes
13:57 < FreeUser> Is Bitcoin Knots an official wallet?
13:58 < sipa> there is no 'official'
13:58 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
13:58 < sipa> Knots is a fork of Bitcoin Core, maintained by different people
13:58 < FreeUser> Official means from Bitcoin Core devs
13:58 < sipa> i'm not involved in Knots
13:58 < gmaxwell> whats a Bitcoin Core devs? there is no such thing as membership.
13:58 < sipa> and i develop for Core.
13:58 < bsm1175321> gmaxwell: correct, I'm interested in obtaining that paying transaction, with witness data, by SPV clients.
13:58 < gmaxwell> Perhaps you're a Bitcoin Core dev, have you submitted a patch? :)
13:58 < Chris_Stewart_5> Damn! I paid that guy all my doge coin for a bitcoin core dev sticker..
13:59 < FreeUser> I can see "Bitcoin Core Developers" while loading Bitcoin Core.
13:59 < sipa> FreeUser: you too can contribute to either, none, or both
13:59 < gmaxwell> FreeUser: yes, that just means all the people who have contributed.
13:59 < MarcoFalke> FreeUser: The "Bitcoin Core Developers" is  just the short version of all the credits (which you can find in the release notes)
14:00 < MarcoFalke> E.g. https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.1.md#credits
14:01 < FreeUser> Can I find Satoshi Nakamoto in release notes?
14:02 < sipa> he has not contributed to any release since 0.3.19
14:02 < sipa> (at least not under that name)
14:04 < Lauda> I'm somewhat inclinded to believe that sipa is satoshi
14:04 < Lauda> they both start with an 's'.
14:04 < FreeUser> Can Satoshi Nakamoto be killed?
14:04 < FreeUser> So     
14:04 < sipa> wth are you talking about?
14:04 < Lauda> Oops wrong chat, thought this was #bitcoin. Sorry.
14:04 < sipa> please take this elsewhere
14:05 < FreeUser> Some cracker cracked his P2P Foundation account.
14:05 < sipa> off topic
14:05 < sipa> you're free to ask questions about Bitcoin and Bitcoin Core's development model here
14:05 -!- FreeUser [~yaaic@191-99-179-94.pool.ukrtel.net] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]     
14:05  * gmaxwell waits for the rbtc headline
14:06 -!- juscamarena [~jus@2607:f380:a61:650:bcfe:aea5:c6f5:f3e6] has quit [Read error: Connection reset by peer]     
14:07 -!- Satoshin [~Bitcoin@191-99-179-94.pool.ukrtel.net] has joined #bitcoin-core-dev     
14:07 < Satoshin> Hello.
14:08 -!- sipa [~pw@2a02:348:86:3011::1] has quit [Changing host]     
14:08 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev     
14:08 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
14:09 < Satoshin> .help
14:09 -!- Satoshin [~Bitcoin@191-99-179-94.pool.ukrtel.net] has left #bitcoin-core-dev []     
14:09 < gmaxwell> I recommend setting a wildcard on that.
14:11 < BlueMatt> sdaftuar: sounds good, will put it on the review-stack :)
14:19 < BlueMatt> sdaftuar: up next after cuckoo
14:27 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
14:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
14:52 < cfields> hmm, is it intended that feeler connections are allowed to send more than just version messages out?
14:56 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome]     
14:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbwvyireegjfjkav] has quit [Quit: Connection closed for inactivity]     
15:03 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
15:15 < gmaxwell> cfields: not really, though I noticed that to and concluded that we'll probably like to expand their behavior over time.
15:16 < cfields> gmaxwell: ok. I suppose at worst, it just makes it look more like a normal node
15:16 < gmaxwell> E.g.e treat them more like like regular connections, and potentially disconnect another connection that hasn't been so useful.
15:18 < cfields> gmaxwell: right. I kinda assumed they did some of that already. For ex, noting nodes with unexpected services in addrman.
15:19 < cfields> Seems a shame to learn that, then mark it as up/fresh anyway
15:19 < gmaxwell> they do update the services before disconnecting. (though we avoid trying to feeler to things without relevant services right now, which diminishes the usefulness somewhat. :) )
15:20 < cfields> ok, roger. As long as it's not unintentional behavior :)
15:23 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome]     
15:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:37 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
15:42 -!- cdecker [~quassel@2a02:aa16:1105:4a80:bcd4:7d3b:d57e:787f] has quit [Ping timeout: 246 seconds]     
15:44 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev     
15:45 -!- gabridome [~gabridome@87.18.61.184] has quit [Client Quit]     
15:49 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vxmbrylvhmntjqyp] has joined #bitcoin-core-dev     
15:55 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: Lost terminal]     
16:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
17:22 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has quit [Remote host closed the connection]     
17:22 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has joined #bitcoin-core-dev     
17:25 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has quit [Client Quit]     
17:25 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has joined #bitcoin-core-dev     
17:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
17:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:58 < bitcoin-git> [bitcoin] sipa opened pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (master...sharedblock) https://github.com/bitcoin/bitcoin/pull/9125
18:08 -!- fengling [~fengling@123.117.40.78] has joined #bitcoin-core-dev     
18:08 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
18:10 -!- tulip [uid192128@gateway/web/irccloud.com/x-wmoyuwyrrjekxwlr] has quit [Quit: Connection closed for inactivity]     
18:19 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]     
18:20 < cfields> sipa: interesting
18:20 <@sipa> cfields: the PR above?
18:20 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
18:20 < cfields> sipa: yes
18:21 < sipa> i was surprised that i didn't need to touch any of the block or transaction serialization logic
18:21 < cfields> yes, it's simpler than I would've expected too
18:21 < cfields> trying to decide how much foot-gun the serialize.h changes allow
18:22 < sipa> the shared_ptr serializer only applies when the element type is const
18:27 < cfields> sipa: yep, actually seems innocuous
18:28 < cfields> sipa: and my knee-jerk when I see shared_ptr is to grumble about ownership models, but I can't imagine this being any worse than duplicating all over the place
18:29 < sipa> cfields: right, but that doesn't apply when the element type is const
18:30 < sipa> you can just see the different shared_ptr's as deduplicated copies of the same data
18:30 < cfields> yes. I like it :)
18:32 < gmaxwell> keep up the grumbling at shared_ptr, I agree.. but it sure seems to make sense for mempool transactions which otherwise we'd have copies of, since the different uses have different lifetimes.
18:36 < cfields> yes, this seems like a really good use-case.
18:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vxmbrylvhmntjqyp] has quit [Quit: Connection closed for inactivity]     
18:40 < cfields> probably requires new approaches in lots of places. For ex where copying a block becomes very cheap for the purposes of caching around locks. 
18:40 < cfields> s/requires/allows/
18:42 < sipa> cfields: well that would better be served by using shared_ptr's to CBlock itself
18:43 < cfields> sipa: i was wondering if that's the next logical step. I don't think they'd be mutually exclusive?
18:45 < sipa> cfields: sure
18:47 < sipa> there are probably a few more optimizations that i haven't addressed
18:47 < sipa> i think ATMP should take a shared_ptr
18:47 < sipa> so a reorg wouldn't require a copy back from the block to the mempool
19:23 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qqhtwqgxpbnzlhow] has joined #bitcoin-core-dev     
19:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
19:48 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
19:55 -!- abpa [~abpa@2602:306:b837:dbf0:b530:d6ac:5237:29f6] has joined #bitcoin-core-dev     
20:56 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
21:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:31 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ygljnoaihgmpvuvp] has quit [Ping timeout: 260 seconds]     
21:33 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rsujyipaxbfkmseh] has joined #bitcoin-core-dev     
21:40 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
22:10 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rsujyipaxbfkmseh] has quit [Ping timeout: 260 seconds]     
22:10 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rqsoysmozdgsnrmy] has joined #bitcoin-core-dev     
22:27 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qqhtwqgxpbnzlhow] has quit [Quit: Connection closed for inactivity]     
22:28 < bitcoin-git> [bitcoin] theuni opened pull request #9128: net: Decouple CConnman and message serialization (master...connman-send) https://github.com/bitcoin/bitcoin/pull/9128
22:33 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
22:38 < bitcoin-git> [bitcoin] rebroad opened pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
22:54 -!- thokon00 [~thokon00@unaffiliated/thokon00] has quit [Ping timeout: 265 seconds]     
22:58 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
23:03 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jivforlhhjsbmsbt] has joined #bitcoin-core-dev     
23:03 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 256 seconds]     
23:05 -!- thokon00 [~thokon00@unaffiliated/thokon00] has joined #bitcoin-core-dev     
23:06 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
23:08 < luke-jr> should we be using std::random_device?
23:10 < sipa> luke-jr: afaik it has 0 guarantees
23:10 < luke-jr> can't hurt though, right?
23:11 < luke-jr> (and what's the point of the exception if there's no guarantees at all? O.o)
23:12 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:13 < sipa> the exception is for when no random number can be generated at all
23:14 < sipa> even if it generates one, it doesn't guarantee cryptographic quality (or any quality at all)
23:14 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
23:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 248 seconds]     
23:25 -!- cfields [~quassel@unaffiliated/cfields] has quit [Quit: cfields]     
23:25 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev     
23:39 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
23:55 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rqsoysmozdgsnrmy] has quit [Ping timeout: 256 seconds]     
23:57 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gftgfwwtiqbvxgcq] has joined #bitcoin-core-dev