--- Day changed Thu Dec 21 2017
00:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:07 < ryanofsky> jonasschnelli, i think if you're using pcoinsdbview you don't need cs_main, but if you using pcoinsTip you do
00:08 < jonasschnelli> thanks ryanofsky 
00:08 < ryanofsky> i was also wondering if #9306 might be useful for what you are doing
00:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9306 | Make CCoinsViewCache::Cursor() return latest data by ryanofsky · Pull Request #9306 · bitcoin/bitcoin · GitHub
00:09 -!- JackH_ [~laptop@host-80-43-140-59.as13285.net] has quit [Ping timeout: 264 seconds]     
00:09 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:12 < jonasschnelli> ryanofsky: I'm implementing UTXO scans (provide pubkeys, xpubs, get unspents, total, etc.)
00:15 < jonasschnelli> ryanofsky: Can you explain the benefits of 9306?
00:17 < ryanofsky> 9306 just lets you scan pcoinsTip instead of pcoinsdbview. pcoinsTip has current utxo data, pcoinsdbview has older utxo data from the time of the last flush
00:18 < jonasschnelli> If you FlushStateToDisk(); and then loop with the curser will give you the same results?
00:19 < ryanofsky> yeah, that should basically be the same
00:19 < jonasschnelli> Are there any performance implications/benefits?
00:20 < ryanofsky> meshcollider, for command line option registration, can't you require the type of the option when registering it? this would let you enforce the type during parsing
00:20 < jonasschnelli> Scanning the whole set takes a couplf of mins here
00:20 < jonasschnelli> *couple
00:20 < ryanofsky> jonasschnelli, i don't know the performance tradeoffs. if calling FlushStateToDisk() is an option though, I would go with that because it seems simpler
00:22 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
00:22 < jonasschnelli> ryanofsky: I'll open a PR soon (next week maybe) and happy if you have a look for possible optimisations...
00:22 < jonasschnelli> thanks
00:23 < ryanofsky> sounds good
00:28 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Read error: Connection reset by peer]     
00:28 < sipa> flushing just to perform a wallet operation sounds like sething we should avoid
00:30 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #bitcoin-core-dev     
00:30 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/604e08c83cf5...7a11ba7e01f3
00:30 < bitcoin-git> bitcoin/master b798f9b Wladimir J. van der Laan: contrib: New clang patch for install_db4...
00:30 < bitcoin-git> bitcoin/master c0298b0 Wladimir J. van der Laan: contrib: Make X=Y arguments work in install_db4...
00:30 < bitcoin-git> bitcoin/master d95c83d Wladimir J. van der Laan: contrib: FreeBSD compatibility in install_db4.sh...
00:31 < bitcoin-git> [bitcoin] laanwj closed pull request #11945: Improve BSD compatibility of contrib/install_db4.sh (master...2017_12_contrib_bsd) https://github.com/bitcoin/bitcoin/pull/11945
00:31 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
00:33 -!- jodli [bce6864b@gateway/web/freenode/ip.188.230.134.75] has joined #bitcoin-core-dev     
00:38 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:49 -!- Uiser [~usuario@168.0.4.67] has joined #bitcoin-core-dev     
00:55 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
00:59 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
01:05 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
01:13 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
01:15 -!- Uiser [~usuario@168.0.4.67] has quit [Quit: Leaving]     
01:19 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
01:20 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:22 -!- puff [~stevenjow@static-108-32-33-25.pitbpa.fios.verizon.net] has quit [Read error: Connection reset by peer]     
01:27 -!- puff [~stevenjow@static-108-32-33-25.pitbpa.fios.verizon.net] has joined #bitcoin-core-dev     
01:33 -!- epic [sid37137@gateway/web/irccloud.com/x-popvyvbxolbewxlz] has joined #bitcoin-core-dev     
01:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:45 -!- wxss [~user@194.88.105.17] has joined #bitcoin-core-dev     
01:47 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:49 < meshcollider> ryanofsky yeah that's what I thought, but I can't think of how to pass a type as a parameter in the registration
01:50 < meshcollider> Without using a variant or univalue or whatever
01:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
01:51 < ryanofsky> is registration just declaring a global variable? if so the type should just be part of the variable type, maybe a template argument
01:55 -!- mmortal03 [d0579a29@gateway/web/freenode/ip.208.87.154.41] has joined #bitcoin-core-dev     
01:56 -!- alcipir [~user@189-48-57-145.user.veloxzone.com.br] has joined #bitcoin-core-dev     
02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:03 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
02:08 -!- JackH [~laptop@host-80-43-140-59.as13285.net] has joined #bitcoin-core-dev     
02:09 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
02:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:13 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:14 -!- alcipir [~user@189-48-57-145.user.veloxzone.com.br] has quit [Ping timeout: 265 seconds]     
02:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]     
02:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
02:17 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]     
02:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
02:21 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
02:23 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:24 < meshcollider> But you have to pass a pointer to the global variable to the arg manager right, so I'm just confused as to the best way of accepting a pointer to a variable of unknown type
02:24 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:25 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
02:25 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
02:26 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
02:27 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 252 seconds]     
02:38 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-cnwtyqcsuuhkwgjf] has joined #bitcoin-core-dev     
02:41 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
02:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
02:46 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
02:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
02:48 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Client Quit]     
02:49 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
02:59 -!- mmortal03 [d0579a29@gateway/web/freenode/ip.208.87.154.41] has quit [Quit: Page closed]     
03:05 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:06 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:06 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
03:06 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:06 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:06 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:07 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:07 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:08 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:08 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:09 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:09 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:09 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:10 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:10 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:10 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:11 -!- _swift [~swift@ip5b40eed4.dynamic.kabel-deutschland.de] has quit []     
03:11 -!- rubensayshi [sid201751@gateway/web/irccloud.com/x-xnepgoqteejldgua] has quit [Quit: Connection closed for inactivity]     
03:11 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:11 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:12 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:12 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:13 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:13 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
03:15 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has joined #bitcoin-core-dev     
03:19 -!- jtimon_ [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]     
03:20 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:22 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:22 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:23 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Quit: Leaving]     
03:23 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:23 -!- jodli [bce6864b@gateway/web/freenode/ip.188.230.134.75] has quit [Ping timeout: 260 seconds]     
03:31 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
03:33 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
03:33 -!- harrymm [~harrymm@104.207.83.52] has quit [Ping timeout: 240 seconds]     
03:44 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev     
03:44 < ryanofsky> meshcollider, probably through subclassing. you could have list<unique_ptr<Option>>, with IntOption, BoolOption, StringOption subclasses, for example
03:44 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
03:46 -!- booyah_ [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
03:47 -!- harrymm [~harrymm@104.207.83.16] has joined #bitcoin-core-dev     
03:47 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev     
03:48 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
03:51 -!- booyah_ [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
03:51 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev     
04:03 < bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/7a11ba7e01f3...711d16ca4a91
04:03 < bitcoin-git> bitcoin/master cdc260a MeshCollider: Add GetCScripts to CBasicKeyStore
04:03 < bitcoin-git> bitcoin/master b702ae8 MeshCollider: Add CScripts to dumpwallet RPC
04:03 < bitcoin-git> bitcoin/master ef0c730 MeshCollider: Add scripts to importwallet RPC
04:04 < bitcoin-git> [bitcoin] laanwj closed pull request #11667: Add scripts to dumpwallet RPC (master...201710_dumpwallet_scripts) https://github.com/bitcoin/bitcoin/pull/11667
04:05 < bitcoin-git> [bitcoin] ryanofsky opened pull request #11970: Add test coverage for bitcoin-cli multiwallet calls (master...pr/mcli) https://github.com/bitcoin/bitcoin/pull/11970
04:11 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:12 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:14 < bitcoin-git> [bitcoin] laanwj closed pull request #10051: adhere to `-whitelist` for outbound connection (master...whitelist-outbound) https://github.com/bitcoin/bitcoin/pull/10051
04:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
04:20 -!- jouke__ is now known as jouke     
04:21 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has quit [Changing host]     
04:21 -!- jouke [~jouke@unaffiliated/komkommer] has joined #bitcoin-core-dev     
04:24 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Remote host closed the connection]     
04:28 -!- larafale [~larafale@174.130-14-84.ripe.coltfrance.com] has quit [Remote host closed the connection]     
04:32 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
04:40 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:41 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:49 -!- DSidH [b7521029@gateway/web/freenode/ip.183.82.16.41] has joined #bitcoin-core-dev     
04:49 < DSidH> When creating a transaction by hand, how do I decide the scriptPubKey contents? Do I just look at the first byte of the pubKeyHash and decide that its either P2PKH or P2SH ?
04:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
04:59 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
05:09 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:10 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
05:10 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:11 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:12 < DSidH> nvm: got the answer. (yes)
05:12 -!- DSidH [b7521029@gateway/web/freenode/ip.183.82.16.41] has left #bitcoin-core-dev []     
05:14 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-rufmykjnsswvdmkm] has quit [Quit: Connection closed for inactivity]     
05:16 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
05:17 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Client Quit]     
05:17 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
05:18 -!- player1 [50478e5e@gateway/web/freenode/ip.80.71.142.94] has joined #bitcoin-core-dev     
05:22 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:27 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:28 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
05:29 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
05:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
05:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
05:47 < Varunram> If I may ask, what's the reason in some of the license banners being old? (e.g. bitcoinconsensus.h has a 2009-2016 banner)
05:49 < wumpus> Varunram: usually we do one "update copyright years" PR at the end of the yera
05:49 < wumpus> if the file is touched that year
05:49 < Varunram> was just curious, thanks!
05:51 < wumpus> it's certainly allowed to update the copyright year of a file together with your change, but almost no one bothers to do that, and it might even result in merge conflicts/rebases as it's a single hotspot per file. There's just no urgency in updating them.
05:54 < Varunram> yep, got the "don't update copyright until the file is changed" part, but just wanted to know the rationale behind it :)
06:01 < bitcoin-git> [bitcoin] Varunram opened pull request #11971: [docs]: include README with binary releases (master...bindoc) https://github.com/bitcoin/bitcoin/pull/11971
06:10 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Ping timeout: 256 seconds]     
06:10 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
06:12 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
06:14 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
06:18 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 248 seconds]     
06:18 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev     
06:18 -!- quantbot [~quantbot@38.101.106.141] has quit [Remote host closed the connection]     
06:19 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev     
06:27 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:38 -!- audriusra [bc45d689@gateway/web/freenode/ip.188.69.214.137] has joined #bitcoin-core-dev     
06:41 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
06:46 -!- promag [~promag@2.83.247.244] has joined #bitcoin-core-dev     
06:49 -!- larafale [~larafale@80.12.34.67] has joined #bitcoin-core-dev     
07:03 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 256 seconds]     
07:03 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has joined #bitcoin-core-dev     
07:04 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
07:05 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
07:05 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
07:06 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:07 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:09 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
07:10 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #bitcoin-core-dev     
07:12 -!- Pasha is now known as Cory     
07:15 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:17 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:17 -!- pierre_rochard [~pierre_ro@unaffiliated/pierre-rochard/x-3593157] has joined #bitcoin-core-dev     
07:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:22 -!- schnerchi [~schnerchi@static.120.187.99.88.clients.your-server.de] has quit [Ping timeout: 248 seconds]     
07:23 -!- AndyS2 [~noname@static.74.88.9.5.clients.your-server.de] has quit [Ping timeout: 248 seconds]     
07:23 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
07:24 -!- AndyS2 [~noname@static.74.88.9.5.clients.your-server.de] has joined #bitcoin-core-dev     
07:25 -!- larafale [~larafale@80.12.34.67] has quit [Ping timeout: 240 seconds]     
07:25 -!- schnerchi [~schnerchi@static.120.187.99.88.clients.your-server.de] has joined #bitcoin-core-dev     
07:42 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha]     
07:56 -!- pkx2 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev     
08:01 -!- promag [~promag@2.83.247.244] has quit [Remote host closed the connection]     
08:01 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:02 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:07 -!- larafale [~larafale@80.12.33.9] has joined #bitcoin-core-dev     
08:13 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:14 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:15 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
08:16 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Quit: lnostdal]     
08:18 -!- Glance_ [63939c81@gateway/web/freenode/ip.99.147.156.129] has joined #bitcoin-core-dev     
08:20 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:21 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds]     
08:22 -!- Glance_ [63939c81@gateway/web/freenode/ip.99.147.156.129] has quit [Client Quit]     
08:26 -!- larafale [~larafale@80.12.33.9] has quit [Remote host closed the connection]     
08:29 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:29 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-cnwtyqcsuuhkwgjf] has quit [Quit: Connection closed for inactivity]     
08:30 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:32 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
08:34 -!- ilanosortap [25d2f8ee@gateway/web/freenode/ip.37.210.248.238] has joined #bitcoin-core-dev     
08:36 < ilanosortap> Hey guys, i would like to contribute to this project. I understand that the first step should be to build it on my system, how can i do so?
08:36 -!- zshlyk is now known as intcat     
08:36 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 264 seconds]     
08:37 < ilanosortap> Also, since i am beginner how can i choose bugs to work on
08:39 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
08:39 -!- mikestovlensky [d92a1d1e@gateway/web/freenode/ip.217.42.29.30] has joined #bitcoin-core-dev     
08:40 < mikestovlensky> Anyone here?
08:40 < mikestovlensky> I've got a quick question
08:43 < ryanofsky> ilanosortap, list of good first issues is https://github.com/bitcoin/bitcoin/issues?q=label%3A%22good+first+issue%22, build instructions https://github.com/bitcoin/bitcoin/blob/master/doc/README.md
08:44 < mikestovlensky> Hi Ryan
08:45 < mikestovlensky> Have you had any contact with the people at Coinbase about when they plan to support Segwit?
08:46 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 256 seconds]     
08:49 < BlueMatt> mikestovlensky: dont think this is the place, #bitcoin
08:49 < ryanofsky> sorry, i don't know anything and i don't think coinbase developers are active here
08:49 < BlueMatt> also, answer is probably no
08:50 < mikestovlensky> I asked Coinbase, they just ignore me
08:50 < mikestovlensky> Just checking in case they have a line in with you folks
08:51 < wumpus> no, not at all
08:51 < mikestovlensky> thanks folks. Keep coding ahead. We'll win this battle. Roger Ver and his cronies got nothing on the hard work you lot are doing
08:52 < mikestovlensky> The community believes in you guys. Your vision is the way forward. I'll leave you lot to plug back in. Merry Xmas in advance
08:52 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Ping timeout: 252 seconds]     
08:52 < wumpus> thank you, same to you
08:53 -!- mikestovlensky [d92a1d1e@gateway/web/freenode/ip.217.42.29.30] has left #bitcoin-core-dev []     
08:56 -!- JackH [~laptop@host-80-43-140-59.as13285.net] has quit [Ping timeout: 248 seconds]     
08:58 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev     
08:59 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 248 seconds]     
09:01 < ilanosortap> Thanks a lot @ryanofsky
09:02 -!- ilanosortap [25d2f8ee@gateway/web/freenode/ip.37.210.248.238] has quit [Quit: Page closed]     
09:08 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has quit [Ping timeout: 268 seconds]     
09:12 -!- larafale [~larafale@80.12.34.150] has joined #bitcoin-core-dev     
09:15 -!- JackH [~laptop@host-80-43-141-44.as13285.net] has joined #bitcoin-core-dev     
09:15 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
09:16 < goatpig> Is there a version of SPV that keeps track a record of the last 1000 blocks or so?
09:16 -!- larafale_ [~larafale@109.190.253.13] has joined #bitcoin-core-dev     
09:18 < wumpus> no, there is no SPV mode in bitcoin core at all at the moment
09:18 -!- larafale [~larafale@80.12.34.150] has quit [Ping timeout: 240 seconds]     
09:18 -!- larafale [~larafale@80.12.34.115] has joined #bitcoin-core-dev     
09:18 < goatpig> oh, what about pruned mode?
09:19 < wumpus> there's https://github.com/bitcoin/bitcoin/pull/9483 which could use review and testing
09:19 < wumpus> yes, there is a pruned mode
09:19 < goatpig> thanks
09:20 -!- larafale_ [~larafale@109.190.253.13] has quit [Ping timeout: 240 seconds]     
09:20 -!- larafale [~larafale@80.12.34.115] has quit [Read error: Connection reset by peer]     
09:23 -!- player1 [50478e5e@gateway/web/freenode/ip.80.71.142.94] has quit [Quit: Page closed]     
09:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
09:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
09:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
09:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
09:34 -!- abaptist [411dad1d@gateway/web/freenode/ip.65.29.173.29] has joined #bitcoin-core-dev     
09:35 -!- abaptist [411dad1d@gateway/web/freenode/ip.65.29.173.29] has quit [Client Quit]     
09:44 -!- Gloata [77095c81@gateway/web/freenode/ip.119.9.92.129] has joined #bitcoin-core-dev     
09:48 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
09:49 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]     
09:49 -!- btcdrak [uid234579@gateway/web/irccloud.com/x-jmwwewqyjhfomugg] has joined #bitcoin-core-dev     
09:53 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:00 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:02 -!- audriusra [bc45d689@gateway/web/freenode/ip.188.69.214.137] has quit [Quit: Page closed]     
10:13 -!- nelruk [~dax_the_c@181.121.118.210] has joined #bitcoin-core-dev     
10:13 < luke-jr> goatpig: pruned mode isn't SPV
10:14 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 272 seconds]     
10:14 < goatpig> i know, im just looking into alternate node modes and thinking forward
10:14 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has joined #bitcoin-core-dev     
10:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:22 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
10:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:23 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
10:29 < jonasschnelli> goatpig: what are you building?
10:29 < jonasschnelli> IMO the most straight forward way if you want to run multiple wallets away from a Core node would be an RPC proxy.
10:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:30 < eck> can i get any book recommendations for practical/applied cryptography for an engineer who has an undergraduate or so level of background in mathematics
10:30 < jonasschnelli> The (new) wallet app could hold keys, and therefore do the signing. That app would create new wallets via RPC (proxy) (which would create a watch-only-wallet on your node).
10:30 < jonasschnelli> Which would also work with pruned peers.
10:31 < jonasschnelli> So a single pruned peer node could server (maybe) hundreds of wallets.. no index required
10:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:31 < jonasschnelli> Backup recovery is only possible via UTXO-set sweep
10:32 < goatpig> not building anything yet
10:32 < goatpig> working on my supernode
10:33 < goatpig> thinking of a hybrid mode where clients bootstrap on a public supernode then run off of a lite bitcoin node
10:33 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
10:36 < jonasschnelli> goatpig: what is a supernode?
10:36 < jonasschnelli> what is a lite bitcoin node?
10:37 < goatpig> db that tracks all blockchain history undiscrimnately
10:37 < goatpig> can handle any arbitrary history request quickly
10:37 < arubi> I can just feed it any blockchain and it would index it?
10:37 < luke-jr> archive node?
10:37 < goatpig> basically yes
10:37 < jonasschnelli> goatpig: fully indexed? Like an electrum server?
10:37 < luke-jr> oh     
10:37 < goatpig> yes     
10:38 < arubi> well, sounds like free for all dos
10:38 < jonasschnelli> Okay. Yes. Pretty inefficient if you just want to run a handful of wallets
10:38 < luke-jr> goatpig: so that assumes the blockchains in question are minimally compatible with Bitcoin in some way?
10:38 < jonasschnelli> But ideally for a large backend
10:38 -!- webuser8434 [529acf7d@gateway/web/freenode/ip.82.154.207.125] has joined #bitcoin-core-dev     
10:38 < luke-jr> jonasschnelli: IMO it should be a goal that Core does something similar long-term
10:38 < goatpig> luke-jr: this is targetted at Bitcoin, i dont do alts
10:38 < arubi> oh ^
10:38 < webuser8434> Hey I just wanted to say that I think maybe at some point in the future you guys might want to consider dissolution of the "Core" brand thing. As much I support everything you do and how you do it the whole "Core" idea is Bad and you'll never stop paying price for it and by extension the entire Bitcoin community. It's divisive in its nature and it gives opponents a tangible target. Unless of course it goes away. It was
10:38 < jonasschnelli> luke-jr: Yeah.. I started to change my mind about indexing... it may should be in Core
10:38 < webuser8434> The only label there is is Bitcoin. Maybe use a section of bitcoin.org to communicate development .. whatever, details are not import. Core needs to die for Bitcoin to live!
10:39 < luke-jr> goatpig: that contradicts the "undiscrimnately" part.. invalid blocks aren't Bitcoin
10:39 < goatpig> arubi: any public facing service has to, but this can also be used internally by businesses
10:39 < webuser8434> Ah, and please please release this bloody Segwit yesterday.
10:39 < webuser8434> Good holidays chaps!
10:39 -!- webuser8434 [529acf7d@gateway/web/freenode/ip.82.154.207.125] has quit [Client Quit]     
10:39 < luke-jr> jonasschnelli: for example, by tracking BCH's chain, we can use "total known hashrate" as a security metric
10:39 < wumpus> eck: 'cryptography' is kind of general
10:39 < arubi> goatpig, I'll have to see what you mean by "any blockchain"
10:40 < luke-jr> jonasschnelli: this is useful because if we know hashrate is mining BCH, we know it isn't being used to make an attack reorg chain
10:40 < jonasschnelli> luke-jr: hmm... thats interesting... though "known" hashrate is probably not enough for a security metric... there could be hashrate sitting around in non BCH/BTC chains
10:40 < goatpig> arubi: im not saying that, this is based on Bitcoin, i dont care about other networks/chains
10:40 < luke-jr> jonasschnelli: yes, but it's an improvement
10:40 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
10:41 < jonasschnelli> luke-jr: if you attack BTC, then you would just have to "hide" the hashrate until it drops out of BTC hash security algo, then attack with that hidden hashrate
10:41 < eck> wumpus: well eventually i'd like to understand things like pederson commitments, ring signatures etc. at a deeper level, my current understanding is superficial. doesn't necessarily have to be a book that covers those things specifically, but i'd like to build a more solid theory foundation.
10:41 < luke-jr> jonasschnelli: it's harder to hide 50%
10:41 < arubi> goatpig, alright, but I don't think I understand the usefulness if it's targeted at bitcoin specifically
10:41 < goatpig> my users run against fullnodes
10:41 < goatpig> this lets you do
10:42 < goatpig> 1 fullnode -> 1 db -> any amount of clients
10:42 < luke-jr> jonasschnelli: but for example, if 50% of miners switch to BCH, we wouldn't want to false flag this as a security problem in Bitcoin
10:42 < jonasschnelli> goatpig: I'm currently in favor of a direct backend. Means, you pass in new just created pubkeys in oder to track them (like a wallet), means you don't need block history, means you can run on pruned peers
10:42 -!- sis [807f69a3@gateway/web/freenode/ip.128.127.105.163] has joined #bitcoin-core-dev     
10:42 < provoostenator> In theory you could feed the client any sha256 hash from any source and it couuld figure out how much went into it. So you can feed it headers from anything that's completely different from Bitcoin, as long as it has a trustworthy timestamp, and it only cares aobut estimating total work in the world.
10:42 < arubi> goatpig, so the clients aren't fully validating?
10:42 < jonasschnelli> goatpig: if you don't care about the backup recovery, you can run endless wallets on a 4GB pruned peer
10:43 < provoostenator> (known work, and the trustworthy timestamp bit doesn't seem trivial)
10:43 < wumpus> eck: in that case it might be useful to focus on the math underpinning it, group theory etc first
10:43 < goatpig> arubi: maybe some context is lost, the supernode is for armory, i was asking about litghter nodes for users to interface with while they bootstrap off a remote supernode
10:43 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:44 < goatpig> arubi: the armory stack is full node, db, client. im looking into possible ways around that
10:44 < arubi> ah, you're right.  yea I understand now.  I missed context
10:44 < wumpus> eck: one of my fav books in that regard is Victor Shoup's A Computational Introduction to Number Theory and Algebra, it's free for download too at http://shoup.net/ntb/
10:44 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:45 < eck> great, thank you for the recommendation!
10:45 -!- Gloata [77095c81@gateway/web/freenode/ip.119.9.92.129] has quit [Ping timeout: 260 seconds]     
10:45 < goatpig> jonasschnelli: as long as i can deliver a good service with armory, Core wouldn't need to work towards that
10:45 < wumpus> eck: besides I really enjoyed "applied cryptoanalsys
10:45 < wumpus> eck: but that's as off topic to cryptocurrencies as it's possible :)
10:45 < eck> i might enjoy it anyway, i'll take a look
10:46 < jonasschnelli> "applied cryptoanalysys"... is that the new word for hacking?
10:46 < jonasschnelli> :-)     
10:46 -!- nelruk [~dax_the_c@181.121.118.210] has quit [Quit: Leaving]     
10:46 < wumpus> jonasschnelli: it's about breaking rsa in some edge cases, timing attacks, and breaking various historical ciphers, so yea sort of
10:47 < wumpus> but not the expoitation kind
10:50 < provoostenator> I doubt this is reproducable, but I just managed to crash QT while it was doing a reindex (in order to get -txindex=1 to work). At the next launch it decided to just redownload the whole blockchain...
10:50 < wumpus> eck: http://cryptopals.com/ has some fairly interesting challenges re: applied cryptography things
10:50 < wumpus> provoostenator: uh oh
10:51 < wumpus> provoostenator: are you able to get a traceback?
10:51 < provoostenator> I'm not entirely sure how I managed to crash it. I was running the eclair lightning test suite, so it's possible that that interfered.
10:51 < provoostenator> wumpus: where would I find that?
10:52 < wumpus> well if you ran it in gdb it would be easy, otherwise, did it dump a core file?
10:53 < wumpus> linux also prints the crash eip to dmesg in case of a segmentation fault but I've found that fairly useless usually with ASLR
10:53 -!- sis [807f69a3@gateway/web/freenode/ip.128.127.105.163] has quit [Quit: Page closed]     
10:55 < jonasschnelli> provoostenator: I guess you ran in the OOM issue? It's still in master AFAIK
10:55 < provoostenator> OSX applications sometimes create crash reports. Maybe that's something we can / need to enable? At least in debug mode.
10:55 < jonasschnelli> The crash report should be stored somewhere
10:55 < provoostenator> I'm on sipa's SegWit branch and I set a pretty high dbcache
10:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
10:56 < jonasschnelli> provoostenator: reindexes on current master causes OOM (on my 32GB machine it did): You need https://github.com/bitcoin/bitcoin/pull/11824
10:56 < jonasschnelli> 11824 should probably by hi-prio
10:56 < jonasschnelli> I did a reindex 4-5 days ago and had the OOM crash on debian with 32GB ram
10:57 < provoostenator> Why would an OOM cause a new IDB?
10:57 < provoostenator> IBD     
10:57 < provoostenator> IBD     
10:57 < promag> does it cause ibd?
10:57 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:57 < jonasschnelli> provoostenator: I think you may end up with a corrupted db.. even if you souldn't (in theory)
10:58 < provoostenator> Oh I was monitoring memory usage, and that was about 30 GB during the reindex (I have 16 GB physical)
10:58 < jonasschnelli> provoostenator: yes. Its fixed in 11824
10:58 < jonasschnelli> reindex in master is currently not usable
10:58 < provoostenator> promag: I don't know if it caused IBD, but it certain started an IBD after this happened
10:58 < wumpus> apparently the validation queue fills memory
10:58 -!- LIndvidu_ [~LIndividu@modemcable028.7-81-70.mc.videotron.ca] has joined #bitcoin-core-dev     
10:59 < provoostenator> So only a re-index should cause this crash, right? Not the new IBD? I might just let this IBD finish and then do another re-index to see if it crashes, before cherry-picking that fix.
11:00 < promag> guess I'll check 11824 too
11:00 < gmaxwell> it would effect IBD too
11:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-micghrinihggzvij] has joined #bitcoin-core-dev     
11:01 < luke-jr> depending on bandwidth?
11:01 < jonasschnelli> I haven't looked at the code of 11824 to be honest...
11:01 < cfields> meeting?
11:01 < wumpus> #startmeeting
11:01 < lightningbot> Meeting started Thu Dec 21 19:01:13 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01 < provoostenator> gmaxwell: ok, that's "great"; saves me time to reproduce. So far it's only using 1.1 GB of RAM in ~2013...
11:01 < 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 achow101 meshcollider jnewbery maaku fanquake promag
11:01 < jonasschnelli> hi     
11:01 < Chris_Stewart_5> hello
11:01 < provoostenator> hi     
11:01  * BlueMatt is betting on low attendance
11:01 < promag> hi o/
11:01 < kanzure> hi.     
11:01 < luke-jr> why?
11:02 < gmaxwell> people travling for holidays
11:02 < luke-jr> oh     
11:02 < sipa> oh, look, a meeting
11:02 < provoostenator> Without taking their laptop? Lame.
11:02 < promag> or buying gifts
11:02 < wumpus> seems there are enough people to warrant a meeting
11:02 < cfields> hi     
11:02 -!- LIndividu [~LIndividu@modemcable028.7-81-70.mc.videotron.ca] has quit [Ping timeout: 268 seconds]     
11:03 < wumpus> but yes holidays is a good topic, I won't be there for next week and the week after that meeting
11:03 < promag> on my side just want to let know that I've made some progress on the activity feature, hope to submit PR next week
11:04 < jonasschnelli> topics?
11:04 < jtimon> hi     
11:04 < wumpus> segwit wallet merge? please? :)
11:04  * sipa is in favor
11:04 < jonasschnelli> Yes. Please
11:05 < gmaxwell> plz     
11:05 < jonasschnelli> xmas present
11:05 < sipa> but also please review first
11:05 < wumpus> #topic segwit wallet
11:05 < wumpus> what is left to do?
11:05 < BlueMatt> I think it needs more review still? I havent checked since my last round but there were a number of papercuts that needed fixing
11:05 < sipa> ryanofsky made a nice list of todos in a comment (all for other PRs ino)
11:05 < wumpus> yes, I mean for this PR
11:05 < sipa> BlueMatt: i've responded, please review
11:05 -!- bitinvestor [2d144301@gateway/web/freenode/ip.45.20.67.1] has joined #bitcoin-core-dev     
11:06 < BlueMatt> yes, will try to get back to it this week
11:06 < wumpus> there's plenty of things that can be done after merging it
11:06 < sipa> cool
11:06 < gmaxwell> sipa: did you look into that multisig still using p2sh thing we discussed?
11:06 < sipa> gmaxwell: yes, fixed, and added tests
11:06 < BlueMatt> oh, yes, it def needed more tests
11:06 < aj> ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917
11:06 < sipa> BlueMatt: also addressed, i think
11:07 < BlueMatt> kool
11:07 < wumpus> #link ryanofsky's todo's: https://github.com/bitcoin/bitcoin/pull/11403#pullrequestreview-83563917
11:07 < sipa> ah yes, there are no address_type parsing tests yet
11:07 < sipa> i'll add those
11:08 < wumpus> great
11:09 < wumpus> any other topics?
11:09 < jonasschnelli> gitian build are broken
11:09 < jonasschnelli> https://github.com/bitcoin/bitcoin/issues/11935
11:09 < jonasschnelli> *builds
11:09 < BlueMatt> review 0.16 stuff!
11:09 < jonasschnelli> (I think its not a local issue)
11:09 < BlueMatt> (not just segwit wallet)
11:09 < wumpus> oh no not again
11:09 < cfields> mm, will have a look
11:09 < jonasschnelli> I think its one for cfields 
11:09 < cfields> jonasschnelli: thanks for reporting
11:10 < cfields> jonasschnelli: oh, i see
11:10 < cfields> it's missing -static-libstdc++ for some reason
11:10 < Chris_Stewart_5> is there still a memory leak on master?
11:10 < wumpus> oh the symbols check fails
11:10 < jonasschnelli> Chris_Stewart_5: yes see 11824
11:10 < gmaxwell> Chris_Stewart_5: it's not a memory leak, but yes its still there.
11:10 < sipa> Chris_Stewart_5: not a leak, but memory is growing unboundedly
11:10 < wumpus> yes, it shouldn't dynamically import libstdc++
11:11 < cfields> yea, the stdlib is just linked shared. Will get to the bottom of it.
11:11 < wumpus> cfields: thanks
11:11 < cfields> nice to see that got caught!
11:12 < jonasschnelli> it's broken since dec. 1st if that helps track down the relevant commit
11:13 < wumpus> two PRs were merged that day, #11804 and #11337
11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/11804 | [docs] Fixed outdated link with archive.is by TimothyShimmin · Pull Request #11804 · bitcoin/bitcoin · GitHub
11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/11337 | Fix code constness in CBlockIndex::GetAncestor() overloads by danra · Pull Request #11337 · bitcoin/bitcoin · GitHub
11:14 < cfields> thanks
11:14 < jonasschnelli> Build 2017-12-01 00:00:10 UTC failed... but build 2017-11-30 00:00:10 UTC succeeded
11:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:14 < wumpus> ok many more things were merged the day before that
11:15 < sipa> dec 1st in what tz?
11:15 < jonasschnelli> 2017-12-01 00:00:10 UTC
11:16 < jonasschnelli> Commit must be between 2017-11-30 00:00:10 UTC and 2017-12-01 00:00:10 UTC
11:16 < jonasschnelli> But maybe other topics first?
11:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:16 < jonasschnelli> anything to change at / mention from the HP list https://github.com/bitcoin/bitcoin/projects/8?
11:17 < wumpus> there's 10 things on there already, I don't think it will help to add more
11:17 < jtimon> BlueMatt: what is "0.16 stuff"?
11:17 < BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/milestone/30
11:17 < wumpus> only so much that can be 'high priority' at once
11:17 -!- c40d9b0743a91f40 [~2c232c25c@unaffiliated/c40d9b0743a91f40] has quit [Ping timeout: 264 seconds]     
11:17 < wumpus> and what we really want is segwit wallet anyway
11:18 < sipa> prioritize ALL THE THINGS!
11:18 < wumpus> hehe
11:18 < jtimon> does everything in there need to be merged before forking 0.16 ?
11:18 < wumpus> jtimon: no
11:18 < wumpus> just segwit wallet + the bugfixes
11:18 < wumpus> all features are optional
11:19 < wumpus> I think we get this question every week
11:19 < jonasschnelli> Maybe a short discussion about fallbackfee / RBF defaults?
11:19 < wumpus> #topic fallbackfee / RBF defaults
11:19 < jtimon> I guess the 0.16 tag confuses me
11:20 < jonasschnelli> There is a PR to split walletrbf between RPC and GUI #11605 (I don't think we should do that)
11:20 < gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
11:20 < wumpus> RBF should probably become default, I don't think there's any way around that
11:20 < jonasschnelli> Also,.. there are two PRs do disable the fallback fee (one on mainnet, one entierly)
11:20 < gmaxwell> RBF should probably be default now, electrum does it, without any great consequence.
11:20 < instagibbs> wumpus, ACK
11:20 < jonasschnelli> Okay. I agree. So lets enable it by default.
11:20 < promag> +1     
11:20 < gmaxwell> jonasschnelli: if fallback fee is disabled what happens if it would otherwise use it?
11:21 < jonasschnelli> provoostenator: can you transform your PR toward that: 11605?
11:21 < wumpus> not sure what the rationale is to enable it only by default for qt?
11:21 < provoostenator> Well, I'm not so sure if that's a good idea for the RPC, which is used by different applicaitons than e.g. electrum.
11:21 < jonasschnelli> gmaxwell: reject
11:21 < jonasschnelli> Disabled fallback fee = JSON throw or QT reject
11:21 < gmaxwell> jonasschnelli: I mean, does the user get prompted to enter a fee?
11:21 < jonasschnelli> No     
11:21 < wumpus> but let's merge enabling it for the gui first at least that's a step forward
11:21 < jonasschnelli> No manual fee entering is provoked
11:21 < provoostenator> Electrum is used afaik person to person, not for broadcasting lots of stuff through an automated process.
11:21 < gmaxwell> so the software just becomes unusable?
11:21 < luke-jr> ^     
11:21 -!- pierre_rochard [~pierre_ro@unaffiliated/pierre-rochard/x-3593157] has quit [Quit: pierre_rochard]     
11:21 < wumpus> jonasschnelli: but it's possible to select a custom fee right?
11:22 < wumpus> jonasschnelli: the GUI has a checkbox for that
11:22 < jonasschnelli> wumpus: Yes. Always...
11:22 < luke-jr> hmm     
11:22 < wumpus> so no, the software doesn't become unusable
11:22 < gmaxwell> What about in the rpc/cli?
11:22 < jonasschnelli> wumpus: but if you don't and fee estimations are not ready,.. rject!
11:22 < jonasschnelli> gmaxwell: reject if you haven't set fallbackfee or paytxfee and feeest is not ready
11:22 < jonasschnelli> fallback fees are the worst!
11:22 < jonasschnelli> (UX)
11:23 < gmaxwell> Is there are rpc way to see a fallback fee?
11:23 < jonasschnelli> Especially if its default enabled and the user don't get informed it was used!
11:23 < sipa> feeest!
11:23 < jonasschnelli> gmaxwell: I don't think so
11:23 < gmaxwell> jonasschnelli: in the gui does the failure message tell you that you can set a fee? 
11:23 < provoostenator> See this comment and the IRC discussion it points back to: https://github.com/bitcoin/bitcoin/pull/11605#issuecomment-352056518 (also cc bluematt)
11:23 < jonasschnelli> If we disable it by default, you wonldn't
11:23 < jonasschnelli> gmaxwell: no.. but I guess I should add that
11:23 < jonasschnelli> gmaxwell: it says you should wait for the feeest to be ready (a couple of blocks)
11:24 < gmaxwell> We should probably do this but we need to make the matching fixes so that the software isn't unusuable for the first day of running it or whatever. e.g. by telling you that you can manually set a fee and providing facilities to do that.
11:24 < gmaxwell> probably need to add a trivial rpc to set the fallback fee.
11:24 < jtimon> ack on RBF by default. I would also remove -mempoolreplacement and always do replacements but that's likely to be more controversial
11:25 < instagibbs> jtimon, luke-jr says miners actually use this option
11:25 < jonasschnelli> gmaxwell: I agree.
11:25 < wumpus> it's still settable on the command line at least
11:25 < gmaxwell> since paytxfee doesn't really do the right thing there.
11:25 < sipa> it's probably best to look at the actual UI, which i haven't :)
11:25 < jonasschnelli> We could even fetch estimations from bitcoincore.org (*hide* *duck* *runaway")
11:25 < wumpus> not sure it'd make sense as a RPC, as there's already paytxfee
11:25 < zelest> sorry for asking, but can anyone just grab whatever bug in the repo and fix it.. and submit a pull request? :o
11:25 < instagibbs> jonasschnelli, or from one of my two suspended twitter bots :P
11:25 < jtimon> instagibbs: yeah, I remember that, just repeating my opinion about it
11:25 < jonasschnelli> heh     
11:26 < gmaxwell> wumpus: IIRC paytxfee overrides the estimator, rather than being overridden by the estimator.
11:26 < sipa> indeed
11:26 < wumpus> zelest: no, you need triple-signed off documents from the central committee first 
11:26 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-sfnvavgsyunotymb] has joined #bitcoin-core-dev     
11:26 < wumpus> zelest: (yes, everyone can just do that :-)
11:26 < gmaxwell> wumpus: so if you achieve your fallback by setting paytxfee then you'll end up underpaying even when your estimator knows better.
11:26 < zelest> Ah ;-)
11:26 < jonasschnelli> The sendto commands have really no clever way to set the txfee
11:26 < zelest> Mayhaps this is what I should spend/waste my free time on...
11:26 < gmaxwell> in any case, I can write the rpc to set the fallback fee, it would be trivial.
11:27 < jtimon> what is the fallback fee?
11:27 < meshcollider> hi, sorry I'm late
11:27 < gmaxwell> and then the errors when you hit that case should just tell you to set the fee.
11:27 < wumpus> gmaxwell: I think it'd be slightly confusing to add yet another fee setting RPC, but okay
11:27 < jonasschnelli> jtimon: its the feerate used when no estimations are available
11:27 < wumpus> another global used in fee determination
11:27 < jtimon> jonasschnelli: thanks
11:27 < wumpus> zelest: that'd be awesome
11:27 < jonasschnelli> I agree with gmaxwell that we need a good UX for the first "day" when fee estimations are not available
11:28 < gmaxwell> wumpus: Agreed, but I don't see around it, telling lots of people to use paytxfee is probably a bad situation.
11:28 < promag> so if fee estimation is not available, rpc funding should fail?
11:28 < gmaxwell> jonasschnelli: not just first day, every day, because of resource usage lots of people don't leave their nodes running.
11:28 < jonasschnelli> promag: Yes
11:28 < wumpus> gmaxwell: agree...
11:28 < jonasschnelli> gmaxwell: indeed.
11:28 < gmaxwell> promag: unless you've set a fallback feerate.
11:28 < wumpus> gmaxwell: would almost wish that there'd be something like 'paytxfeepriority' but not that that would be any easier to understand :-)
11:28 < promag> jonasschnelli: and in the UI too? or prompt for custom?
11:28 < jtimon> gmaxwell: yeah, or people just shut down their computers when they go to sleep
11:28 < jonasschnelli> So either the user enters the current feerates into RPC/GUI or we load it from somewhere
11:29 < wumpus> gmaxwell: (e.g. whether it'd override the fee estimator or not)
11:29 < promag> gmaxwell: but we want to remove that?
11:29 < gmaxwell> promag: no we want to eliminate there being a default one.
11:29 < gmaxwell> The estimator is always going to take time to start working.  And it's not reasonable to force people to not transact until they have estimates.
11:30 < gmaxwell> But a static compiled in fallback is dumb.
11:30 < wumpus> promag: the problem is that fees are too variable now to hardcode any sensible default in the software
11:30 < promag> gmaxwell: ok, but once defined it can be outdated very fast
11:30 < luke-jr> ideally we could pre-sign multiple fee rates and send the higher ones once we have an estimate
11:30 < promag> luke-jr: only with rbf signaled
11:30 < gmaxwell> RBFing has complications, unfortunately.
11:30 < promag> ?     
11:31 < jonasschnelli> luke-jr: long term.... yes. Maybe. But complicated to implement
11:31 < luke-jr> well, require RBF when there's no estimates?
11:31 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
11:31 < jonasschnelli> luke-jr: I had this in a PR
11:31 < gmaxwell> You can't just assume that RBF will work unfortunately.
11:31 < gmaxwell> Because of the pinning problem.
11:31 < jonasschnelli> But then morocs asked for just disabling fallback.. which makes sense
11:31 < wumpus> RBF is orthogonal imo
11:31 < luke-jr> even without RBF, it would probably work if the problem is fee rate too low
11:31 < instagibbs> gmaxwell, "pinning" meaning someone spending on top?
11:31 < instagibbs> I like the name if so
11:31 < luke-jr> if nobody has the conflicting tx in their mempool, it's not even considered a replacement
11:31 < wumpus> yes, we also want RBF by default, but that doesn't change the fallback fee situation
11:31 < gmaxwell> instagibbs: with a large txn, yes.
11:32 < wumpus> certainly not for RPC
11:32  * luke-jr wonders how pinning affects mempool eviction of low feerate
11:32 < jonasschnelli> I think the fallback fee problem is solveble in the GUI,... but not sure about RPC layer,... we would have to add feerate parameters to the send commands
11:32 < gmaxwell> in any case, ACK removing fallback fee but we must be mindful that for a lot of users the no-estimate case will be very frequent so the workflow has to be good: which means clear messages and a straight forward way to set a fee.  
11:33 < gmaxwell> jonasschnelli: RPC I think is fine, setfallbackfee ...  and the error returned on send tells you that you have to use that.
11:33 < wumpus> yeah...
11:33 < jonasschnelli> I think gmaxwell idea with the setfallbackfee RPC makes most sense.. 
11:33 < jtimon> yeah I think RBF is orthogonal too. let's just make it default independently of the estimation issue
11:33 < wumpus> jtimon: agree
11:33 < gmaxwell> then for cli users the workflow is basically like the GUI one, and for businesses they might pull the fallback off another node, or an estimation site.
11:33 < wumpus> right
11:33 < gmaxwell> (automatically)
11:33 < jtimon> don't we have an estimator purely based on past blocks with no knowledge of the mempool?
11:34 < instagibbs> jtimon, that's the only way we do it
11:34 < jtimon> mhm, then why do you need to be up for some time to have estimates?
11:34 < gmaxwell> instagibbs: not quite we watch the dwell time of transactions that confirm.
11:34 < gmaxwell> it needs both
11:35 < promag> how about something to help/speedup fee estimation?
11:35 < instagibbs> mistook the question
11:35 < wumpus> using only blocks would be easy to manipulate
11:35 < promag> like feeding fee estimation with something.. don't know the internals
11:35 < gmaxwell> using blocks exclusively is exploitable, unfortunately. Though there are limited ways which it could help.
11:35 < gmaxwell> e.g. you could look at the minimum fee confirmed over many blocks, but sadly it would be misleadingly low because of OOB payments and such.
11:36 < jtimon> perhaps we could have a non-mempool estimator that is used by default until there's data for the mempool based one
11:36 < wumpus> adding a new estimator is not going to go for 0.16 at least
11:36 < wumpus> in the future, who knows
11:36 < gmaxwell> also it's not likely to be invented by folks who don't know the current one and history. :)
11:36 < jtimon> say, something stupid like max (the minimum feerate in each block for the last 144 blocks)
11:37 < gmaxwell> jtimon: yes, maybe... under the bet that there is at least one block with no OOB fees. You'd have to exclude blocks that weren't full.
11:37 < sipa> or bounding estimates by the feerate at 1 MB vbyte from the top of the mempool
11:38 < aj> jtimon: aggregate all the fee rates over a bunch of blocks and choose a fee that's higher than ~10% or 20% of them
11:38 < gmaxwell> sipa: without mempool sync that isn't fast.
11:38 < jtimon> gmaxwell: right, 100 empty blocks would screw you
11:38 < sipa> ah yes
11:38 < gmaxwell> but indeed, once we have some kind of mempool sync we could do things like that.
11:38 < wumpus> 100 empty blocks would screw everyone
11:39 < jtimon> is there a way to persist the mempool while running instead of only when shutting down?
11:39 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:39 < instagibbs> jtimon, i think there is an rpc for that
11:39 < gmaxwell> jtimon: just go back one day of blocks, counting only blocks at least 0.95*MAX_WEIGHT in size, and check the maximum of their minimum feerates. Would be interesting to see what that yields right now. It _might_ be useful.
11:40 < wumpus> savemempool RPC
11:40 < instagibbs> https://github.com/bitcoin/bitcoin/pull/11099
11:40 < jtimon> gmaxwell: yeah, that sounds less stupid than what I proposed, and still isn't hard
11:40 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 248 seconds]     
11:41 -!- bitinvestor [2d144301@gateway/web/freenode/ip.45.20.67.1] has quit [Quit: Page closed]     
11:41 < gmaxwell> or instead of their minimum feerate, their Nth percentile feerate.
11:41 < jtimon> I mean, still probably not for 0.16, but not hard to code I think
11:41 < gmaxwell> right
11:41 < wumpus> any other topics?
11:42 < gmaxwell> e.g. what feerate is less than 95% of the txn in the block... gives it room to ignore 5% priority txn.
11:42 < jtimon> wumpus: instagibbs thank you! and sorry, the question is kind of unrelated anyway
11:42 < wumpus> yes that'd make sense
11:42 < provoostenator> I'm still reluctant about enabling RBF for RPC. Without having a long disucssion here, is there a list of known large services that use Bitcoin Core RPC to broadcast transactions? I'd like to know their take on this.
11:42 < gmaxwell> provoostenator: an RPC using service can at least read the release note and simply turn it off again.
11:42 < aj> i did sextile graphs of fee rates aggregated over 24 hours the other day, http://azure.erisian.com.au/~aj/tmp/graphs/fpvb-trends.png and http://azure.erisian.com.au/~aj/tmp/graphs/segwit-comparison.png i think they track pretty well
11:42 < wumpus> promag: let's first enable it for the gui, at least that's uncontroversial
11:42 < wumpus> provoostenator*
11:43 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
11:44 < instagibbs> 15 minutes left
11:44 < provoostenator> It's equally trivial for an RPC user to just set walletrbf=1 if they want to use this. The only problem seems to be code complexity.
11:44 < wumpus> I think having a too long defaults discussion is not productive, if anyone is opposed to enabling it for RPC with good reason then we shouldn't do that
11:44 < gmaxwell> rpc can wait, we can release note a reminder that you can turn it on for cli/rpc use.
11:44 < promag> wumpus: ok
11:45 < wumpus> people using RPC will usually have a better idea of available options anyhow
11:45 < provoostenator> gmaxwell: I already put that in the release note in my PR
11:45 < instagibbs> perhaps with a warning that future versions may change this
11:45 < provoostenator> (sort of)
11:45 -!- valentinewallace [32017b03@gateway/web/freenode/ip.50.1.123.3] has joined #bitcoin-core-dev     
11:45 < jonasschnelli> I don't think splitting walletrbf between GUI and RPC makes sense in the long run
11:45 < wumpus> yes, defaults are subject to change
11:45 < gmaxwell> sipa: so what do you think long term trying to use that block percentile as a maximum fee for a fast estimate, and then use a synced mempool to potentially reduce the number. I think that escapes the primary manipulation concerns we have.
11:45 < wumpus> jonasschnelli: on the long run it makes no sense
11:45 < provoostenator> I think it does make sense to treat GUI and RPC different
11:45 < wumpus> jonasschnelli: it'd be a temporary artifact
11:45 < provoostenator> Very different use cases.
11:45 < gmaxwell> just get rid of the setting for the GUI.
11:46 < provoostenator> It's just a code maintenance thing why we shouldn't make them too different.
11:46 < sipa> gmaxwell: if you're worried about OOB paymemts, shouldn't you also be concerned about OOB refunds?
11:46 < jonasschnelli> What speak again just enabling -walletrbf GUI/RPC by default?
11:46 < jonasschnelli> *against
11:46 < wumpus> gmaxwell: I think that's a good point too - why would the GUI need a setting for the default?
11:46 < jtimon> i think rbf active is the most sensible default for both rpc and gui
11:46 < gmaxwell> sipa: OOB refunds don't currently appear to be a real thing.
11:46 < wumpus> it has a checkbox if you really want to disable it
11:46 < provoostenator> gmaxwell: yes, I can kill the setting for the GUI, especially because I renamed the RPC setting to -rpcwalletrbf
11:47 < gmaxwell> wumpus: yep thats just what I was typing, that it has a checkbox.
11:47 < jonasschnelli> wumpus: people are lazy to read checkboxes? :)
11:47 < gmaxwell> then they'll certantly not read a setting. :)
11:47 < wumpus> jonasschnelli: well the default is sensible, lazy people won't want to override it!
11:47 < wumpus> gmaxwell: indeed
11:47 < sipa> gmaxwell: for now.
11:47 < wumpus> +1 on not having the GUI default setting
11:48 < jonasschnelli> Set walletrbf=1 by default,.. switch the checkbox in the GUI  (to disable RBF instead of enable)
11:49 < jtimon> why not leave the checkbox as meaning enabled but simply have it checked by default?
11:49 < provoostenator> Rather than renaming -walletrbf to -rpcwalletrbf, I can also make it clear that -walletrbf won't impact the GUI.
11:49 < wumpus> provoostenator: yes, I'd prefer that
11:49 < gmaxwell> +1     
11:49 < wumpus> provoostenator: I'd really prefer not to have a rename/deprecate cycle there
11:50 < wumpus> provoostenator: (as I've expressed before)
11:50 < gmaxwell> better to not break things for people who are already walletrbf=1 if we can avoid it.
11:50 < wumpus> yeah... 
11:50  * jonasschnelli unsure
11:50 < wumpus> just document the option instead of renaming it
11:50 < jonasschnelli> Wait...yes. This makes sense
11:50 < provoostenator> Yeah, the deprecation stuff was a bit overkill.
11:50 < gmaxwell> just adjust the description, make the gui not read that setting for the checkbox default.
11:50 < wumpus> ok, cool!
11:50 < wumpus> seems we agree
11:50 < jonasschnelli> ack     
11:51 < meshcollider> yep sounds good
11:51 < gmaxwell> if users complain that they can't set a different default we'll deal with that then, but I don't expect it.
11:51 < luke-jr> why not just let -walletrbf continue to work, but have the new defaults only affect when it's unset?
11:51 < wumpus> luke-jr: it will continue to work
11:51 < wumpus> for the RPC
11:51 < luke-jr> wumpus: I mean for both
11:51 < wumpus> any other topics?
11:51 < wumpus> luke-jr: using the same setting with different default in different places was *ugly*
11:52 < provoostenator> ^     
11:52 < provoostenator> That was actually what I did in the first version, but it's confusing.
11:52 < gmaxwell> the 'implementation defined behavior when not set' should be used very sparingly.
11:52 < provoostenator> Making it clear that -walletrbf has no bearing on the GUI (including it's default) seems better.
11:52 < luke-jr> IMO the ugliness only comes from having two defaults, not from having a common setting
11:52 < wumpus> yes, that used to be the case, but it's no way to handle options imo, and won't be ocmpatible when we introduce an actual options registration/parsing system
11:52 < provoostenator> I'll push that after the meeting.
11:52 < jonasschnelli> Thanks provoostenator!
11:52 < gmaxwell> In general we should probably not have config file setting for GUI checkboxes that stare the user in the face.
11:53 < provoostenator> Remind me not to make changes to defaults too often :-)
11:53 < gmaxwell> if the GUI wants a persistant default it should be changable from the GUI.
11:53 < meshcollider> Which I am trying to work on at the moment :)
11:53 < luke-jr> gmaxwell: via rwconf ;)
11:53 < jonasschnelli> provoostenator: hah... these are the worst. :)
11:53 < gmaxwell> But hopefully we won't need a changable persistant default for this.
11:53 < wumpus> right
11:53 < jtimon> the rbf checkbox doesn't appear with every tx?
11:54 < provoostenator> luke-jr: rwconf?
11:54 < wumpus> jtimon: isn't it always there?
11:54 < meshcollider> jtimon: what?
11:54 < gmaxwell> provoostenator: code to allow the conf file to be rewritten by setting changes at runtime.
11:54 < luke-jr> provoostenator: lets the GUI change config file settings
11:54 < wumpus> please, no scope creep
11:54 < gmaxwell> that was just a tangent.
11:54 < gmaxwell> not scope creep. :)
11:54 < provoostenator> Ah, so we don't have this "here's a setting, but if you use -blah it's overridden, unless you also have bitcoin.conf, unless you have another one" stuff?
11:55 < gmaxwell> I was just expressing the principle that controlling GUI defaults via non-gui accessable settings is just not very good.
11:55 < jtimon> sorry, I should look at the gui. my assumption was that for every tx a checkbox would say "allow rbf" and that is unchecked by default and we're moving to checked by default
11:55 < wumpus> it would add another bitcoin.conf, bitcoin_rw.conf, which can be written by the software itself
11:55 < provoostenator> gmaxwell: indeed, also not very easy to launch QT with flags on OSX.
11:55 < gmaxwell> I know, we could save the users settings ON THE BLOCKCHAIN
11:56 < meshcollider> jtimon: yep that's basically what this is doing
11:56 < wumpus> hehehe, settings delta chain
11:56 < sipa> gmaxwell: woah!
11:56 < meshcollider> lol     
11:56  * cfields founds chainsettingsalytics
11:56 < wumpus> gmaxwell: I"m surprised that no *coin project commits git diffs to the blockchain yet
11:56 < jtimon> meshcollider: then I don't understand the -walletrbf discussion, but it's fine
11:57 < gmaxwell> plus the related costs will make them never get changed, and since they're never changed we could remove the implementation of the choices... less UI to maintain!
11:57 < provoostenator> Some people use opentimestamps for that
11:57 < provoostenator> The git integration thing.
11:57 < achow101> wumpus: there's definitely a Core commit diff somewhere on the blockchain
11:57 < meshcollider> jtimon: the walletrbf discussion is about whether that parameter should affect the GUI default or only the RPC I believe
11:57 < wumpus> or even better, just commit javascript code for the GUI to the block chain
11:57 < wumpus> :')     
11:57 < achow101> I found it once, but don't know where it is
11:58 < wumpus> achow101: oh! which one?
11:58 < wumpus> it'd certainly create incentive to make patches small
11:58 < achow101> wumpus: I don't quite remember
11:58 < jtimon> meshcollider: right, we're moving to not affecting it seems, which is what makes most sense to me, just what I described with no relation to -walletrbf. so it's fine.
11:58 < meshcollider> wumpus: heh why just the GUI, entire new versions of core could be downloaded directly from the blockchain too!
11:59 < wumpus> no one would submit a diff-all-over-the-place PR if it costs >300 sat/byte
11:59 -!- btcdrak [uid234579@gateway/web/irccloud.com/x-jmwwewqyjhfomugg] has quit [Quit: Connection closed for inactivity]     
11:59 < wumpus> meshcollider: yes of course, updates to the consensus algo too :')
11:59 < sipa> wumpus: do you get a refund for deleted lines?
11:59 < wumpus> sipa: yes!
11:59 < provoostenator> Unless they want to show off their wealth as an offering...
11:59 < meshcollider> jtimon: yep exactly 
11:59 < jtimon> meshcollider: that would be great to make sure everyone upgrades before a hf :p
11:59 < sipa> wumpus: brb, deleting all the tests
11:59 < wumpus> sipa: but only if accepted :-)
11:59 < luke-jr> wumpus: you're going to give my children nightmares
11:59 < sipa> oh.     
12:00 < sipa> DONG
12:00 < wumpus> #endmeeting
12:00 < lightningbot> Meeting ended Thu Dec 21 20:00:08 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-21-19.01.log.html
12:00 < wumpus> luke-jr: uh oh
12:00 < jonasschnelli> cfields: chainsettingsalytics?
12:00 < achow101> I forgot there was a meeting today..
12:00 < meshcollider> achow101: at least you made it for the end ;)
12:00 < cfields> jonasschnelli: for tracking and selling on-chain user settings, of course
12:01 < jtimon> -forceautoupgradeonversionsolderthanthisoption
12:01 < cfields> jonasschnelli: you happen to have git revisions for good/broken gitian builds?
12:01 < sipa> achow101: you should make the blockchain remind you
12:01 < achow101> sipa: lol
12:01 < jonasschnelli> cfields: let me check
12:01 < cfields> thanks
12:01 < jonasschnelli> Good: 38d31f95
12:01 < jtimon> sipa: can you even program a smart contract alarm without turing completeness? :p
12:01 < jonasschnelli> Broken: 13e31dd6
12:01 < jonasschnelli> Happy bisect
12:02 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has quit [Ping timeout: 240 seconds]     
12:02 < achow101> in other unrelated news, I finally got around to simulating the branch and bound coin selection stuff
12:02 < cfields> perfect! thanks :)
12:04 < jtimon> alright, I'm going to go try that savemempool rpc...
12:07 < jonasschnelli> jtimon: why?
12:07 -!- jb55 [~jb55@2605:8d80:4c3:766c:a2af:bdff:fef0:c102] has joined #bitcoin-core-dev     
12:08 < gmaxwell> achow101: and?
12:08 < wumpus> FYI you can only save to the default file, it doesn't take a filename argument
12:08 < achow101> gmaxwell: it's taking a long time
12:08 -!- spence [18650bcc@gateway/web/freenode/ip.24.101.11.204] has joined #bitcoin-core-dev     
12:08 < achow101> I'm looking at some results right now and I'll add a comment to the PR with them
12:11 < achow101> gmaxwell: AFAICT, it performs on par with the current coin selection behavior but I think that might be because BnB was only used <3% of the time with the dataset and parameters I just tried
12:13 < spence> Is there a roadmap for integrating segwit better into Core?  Gui, etc...
12:13 < gmaxwell> it'll be in the next release.
12:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:15 -!- amj_ [554ca2e5@gateway/web/freenode/ip.85.76.162.229] has joined #bitcoin-core-dev     
12:16 < wumpus> #11403
12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
12:17 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
12:20 < contrapumpkin> is there a way I can feed bitcoin core an HD wallet xpub key and get it to monitor the balance without holding the private keys?
12:20 < contrapumpkin> oh sorry, wrong channel
12:21 < provoostenator> On a meta note. Looks like I can keep helping out for a while without running out food :-)  https://blog.blockchain.com/2017/12/21/first-open-source-developer/
12:21 < achow101> provoostenator: congrats!
12:23 < jtimon> jonasschnelli: I'm working on an explorer, and every time I deploy ir restarts the daemon's container, but it doesn't wait for the mempool dump, so I lose the whole mempool every time. I'll fix it with process that  periodically calls savemempool
12:23 < jonasschnelli> ah     
12:24 < sipa> provoostenator: congratulations
12:24 < sipa> very happy to see that
12:25 < jonasschnelli> provoostenator: Oh. Nice! Well done.
12:25 < wumpus> provoostenator: great!
12:26 < jimpo> Just out of curiousity, why is much of the secp256k1 code in _impl.h header files instead of .c files?
12:27 < wumpus> jimpo: optimization, scope for inlining, as well as making it easy to add secp256k1 to a project by just adding one .c file
12:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:28 < jtimon> provoostenator: cool, great news
12:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:30 -!- spence [18650bcc@gateway/web/freenode/ip.24.101.11.204] has quit [Quit: Page closed]     
12:31 -!- amj_ [554ca2e5@gateway/web/freenode/ip.85.76.162.229] has quit [Ping timeout: 260 seconds]     
12:32 < meshcollider> 🎉
12:32 < cfields> provoostenator: congrats!
12:33 < zelest> how much of self-torture will I have to live through to get bitcoin running on OpenBSD? :)
12:33 < provoostenator> Thanks! Also, updated #11605 (but do check carefully, it's a bit late here...) 
12:33 < gribble> https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
12:36 -!- cireful_ [0269c514@gateway/web/freenode/ip.2.105.197.20] has joined #bitcoin-core-dev     
12:38 -!- cireful [0269c514@gateway/web/freenode/ip.2.105.197.20] has quit [Ping timeout: 260 seconds]     
12:39 < cfields> zelest: there are freshly updated docs for that
12:39 < cfields> wumpus self-tortured himself so you wouldn't have to
12:41 < wumpus> cfields: well we didn't update the docs yet for openbsd 6.2, just the bdb building tool
12:41 < wumpus> although the current instructions should work
12:41 < cfields> oh, i thought that was all that was needed
12:41 < wumpus> the docs could be really simplified because openbsd 6.2 includes clang, it currently tells to install either clang or a newer gcc
12:42 < wumpus> openbsd 6.2's built-in compiler can build bitcoin core :)
12:42 < cfields> ah right
12:42 < cfields> nice
12:43 < cfields> wonder what obsd would've done without clang.
12:44 < wumpus> dunno either, could hardly have sticked with gcc 4.2 forever
12:46 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
12:46 < wumpus> zelest: so basically: append CC=cc CXX=c++ to the contrib/install_db4.sh and configure commands
12:47 < wumpus> so that it will use clang and not the gcc 4.2, which for some reason is still installed
12:47 -!- jrayhawk_ is now known as jrayhawk     
12:48 < wumpus> (or maybe that's because my openbsd box was upgraded from $OLD_VERSION)
12:48 < cfields> it switched your default cc/c++ after an upgrade?
12:49 < wumpus> it didn't use to have cc/c++, just gcc/g++
12:49 < cfields> ah     
12:49 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
12:50 < wumpus> and by default, most build systems will pick gcc over cc
12:50 < cfields> yikes, though. buildsystems do all kinds of combinations of checks for cc/gcc
12:50 < cfields> stupid cmake, for example, uses cc/c++
12:51 < wumpus> I should try installing an openbsd 6.2 from scratch and see if it has only clang, that'd make more sense
12:52 < wumpus> g++ and c++ have an incompatible abi so ou're right that it cause all kind of pain
12:52 < cfields> or gcc -> cc
12:52 < cfields> that's what macos does
12:52 < wumpus> yes the same command line interface anyway
12:53 < cfields> 10% unrelated: gcc is able to build in a chroot with only binutils/gmake/previous gcc/libc/kernel headers.
12:54 < cfields> cmake, however, is the first to require a whole mess of libs :(
12:54 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds]     
12:54 < wumpus> what do we need cmake for?
12:54 < wumpus> it's mostly used for graphical stuff right?
12:54 < cfields> clang
12:54 < wumpus> oh     
12:54 < cfields> so no avoiding it as part of the early build process, i'm afraid
12:55 < wumpus> clang is cmake only now?
12:55 < wumpus> Ithought it had an autoconf based build as well
12:56 < cfields> not sure if it is for 5.0, but if not, the autotools is heavily deprecated
12:56 < wumpus> ah yes you're right
12:56 < wumpus> I see I also switched my clang configuration script to cmake at some point, apparently without remembering
12:56 < cfields> heh     
12:57 < cfields> well it's probably not all that different if you're using all system paths
12:58 < wumpus> cmake -DLLVM_TOOL_COMPILER_RT_BUILD:BOOL=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/opt/clang${VER} -DLLVM_BINUTILS_INCDIR=/usr/include -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm
12:58 < wumpus> well it's not as bad as some cross-compiles...
13:02 < zelest> wumpus, Ah, awesome! thanks :)
13:07 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has joined #bitcoin-core-dev     
13:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:13 -!- jb55 [~jb55@2605:8d80:4c3:766c:a2af:bdff:fef0:c102] has quit [Ping timeout: 252 seconds]     
13:15 -!- promag [~promag@2.83.247.244] has joined #bitcoin-core-dev     
13:20 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Quit: No Ping reply in 180 seconds.]     
13:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:23 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
13:30 -!- Megumiin [~Megumiin@unaffiliated/megumiin] has joined #bitcoin-core-dev     
13:31 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
13:39 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
13:40 -!- promag [~promag@2.83.247.244] has quit [Remote host closed the connection]     
13:49 < zelest> wumpus, boo! the compile blew up P
13:49 < zelest> :P     
13:50 < wumpus> with what?
13:50 < zelest> https://pastebin.com/0WLsNR7j
13:51 < wumpus> zelest: what version are you building?
13:51 < wumpus> and you did do contrib/install_db4.sh CC=cc CXX=c++ ?
13:52 < wumpus> this happens when dbc++ was built with a different compiler than bitcoind
13:53 < zelest> wumpus, 0.15.1 and yeah.. and no, I used CC=egcc CXX=eg++ CPP=ecpp :o
13:53 < sipa> what version of gcc is that?
13:54 < zelest> 4.2.1
13:54 < zelest> i did however run ./configure with CC=cc and CXX=c++
13:54 < sipa> that won't work
13:54 < sipa> you need gcc 4.7
13:55  * zelest tries what wumpus suggested and runs llvm for both dbc++ and bitcoind
13:56 < wumpus> zelest: 0.15.1 doesn't have the necessary patch, unfortunately that install_db4.sh  ignores arguments
13:56 < zelest> oh     
13:56 < wumpus> this was fixed on master yesterday with #11945
13:56 < gribble> https://github.com/bitcoin/bitcoin/issues/11945 | Improve BSD compatibility of contrib/install_db4.sh by laanwj · Pull Request #11945 · bitcoin/bitcoin · GitHub
13:56 < wumpus> you could probably just copy the file from there
13:57 < zelest> wumpus, can I compile master? (i saw build:failed on there, hence me picking 0.15.1)
13:57 < wumpus> https://raw.githubusercontent.com/laanwj/bitcoin/2712742ef2947feef4a142f7d1360d1e821597dc/contrib/install_db4.sh
13:57 < zelest> ah     
13:57 < wumpus> sure, you can build master
13:57 < zelest> oh yeah, the link in build-openbsd.md is wrong btw
13:57 < zelest> it 404s
13:57 < wumpus> but thanks for reminding me it needs a backport label
13:58 < wumpus> which link?
13:59 < wumpus> anyhow that's likely fixed on master too
13:59 < zelest> https://github.com/bitcoin/bitcoin/blob/master/doc/build-openbsd.md the "the installation script included in contrib/" under Building Berkley DB
14:00 < zelest> BerkeleyDB*
14:03 < bitcoin-git> [bitcoin] laudaa opened pull request #11976: [Doc] Fix link to installation script (master...master) https://github.com/bitcoin/bitcoin/pull/11976
14:03 < Lauda> Sorry, we missed that one
14:03 < wumpus> apparently Lauda in #11960 fixed that in all files except build-openbsd.md in 
14:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11960 | [Doc] Fix link to installation script by laudaa · Pull Request #11960 · bitcoin/bitcoin · GitHub
14:06 < zelest> no love for OpenBSD :(
14:09 < Emcy> !topic
14:09 < gribble> Bitcoin Core development discussion and commit log | This is the channel for developing Bitcoin Core. Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: https://botbot.me/freenode/bitcoin-core-dev, http://www.erisian.com.au/bitcoin-core-dev/
14:09 < Emcy> when are the meetings? weekly?
14:09 < Lauda> Yes     
14:09 < wumpus> 19:00-20:00 UTC Thursdays, you just missed one
14:10 < Emcy> ok     
14:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
14:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
14:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
14:22 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
14:24 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 265 seconds]     
14:27 < zelest> wumpus, yeah, failed even with those CC flags
14:27 < zelest> oh well
14:29 < Emcy> 0.16 i branching soon. nice.
14:29 < wumpus> zelest: so you used the new version of install_db4.sh?
14:29 < zelest> yeah
14:29 < Emcy> and segwit gui is getting merged
14:29 < wumpus> zelest: ok, no clue in that case, it worked for me
14:30 < zelest> wumpus, i'm using -current though, might affecting it.. *shrugs*
14:30 < zelest> also had it running back in 6.1
14:31 < zelest> wumpus, thanks for all the help though :)
14:31 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has quit [Quit: Computer has gone to sleep.]     
14:32 < wumpus> zelest: I don't think that should matter - what matters is that both dbc++ and bitcoind are compiled with the same c and c++ compiler
14:32 < wumpus> zelest: if not, you get linker errors, due to ABI mismatch
14:33 -!- Joshua [4c627782@gateway/web/freenode/ip.76.98.119.130] has joined #bitcoin-core-dev     
14:33 -!- Joshua is now known as Guest99499     
14:34 < zelest> hmms..
14:34 < Guest99499> How can 4 btc come out of my wallet and I did not send anything 
14:35 < Guest99499>  It was  several different transactions with the same address going out is it rerouting
14:35 < zelest> wumpus, i will give it another go tomorrow and start out with a fresh copy of both source trees.. need to hit the shower before i hit the sack. :)
14:36 < Guest99499> Will it come back to my Wallet
14:36 < sipa> Guest99499: #bitcoin
14:36 < wumpus> zelest: yes it might be that something left behind from earlier builds; also it's a good idea to pipe the build output to a file to see if the right compiler gets used
14:36 < sipa> Guest99499: or https://bitcoin.stackexchange.com
14:36 < zelest> wumpus, ah, true
14:37 < Guest99499> So there's nothing to worry about it will come back to my wallet
14:37 < sipa> Guest99499: not here.
14:39 < Guest99499> How can I get my missing btc back in my wallet  Who authorized to take it out 
14:40 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:41 < Guest99499> Has anybody else had the same problem
14:41 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has joined #bitcoin-core-dev     
14:44 < wumpus> Guest99499: #bitcoin please
14:44 < sipa> Guest99499: last warning, not here. this channel is for development, not support
14:51 -!- Guest99499 [4c627782@gateway/web/freenode/ip.76.98.119.130] has quit [Ping timeout: 260 seconds]     
14:59 -!- talha_ [27353fdd@gateway/web/freenode/ip.39.53.63.221] has joined #bitcoin-core-dev     
14:59 < talha_> hi     
15:02 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:04 < bitcoin-git> [bitcoin] theuni opened pull request #11981: Fix gitian build after libzmq bump (master...fix-gitian-build) https://github.com/bitcoin/bitcoin/pull/11981
15:05 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has quit [Quit: Leaving]     
15:06 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has joined #bitcoin-core-dev     
15:07 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:09 -!- mrfrasha [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha]     
15:13 < talha_> any fork expert here?
15:14 < wumpus> that's off topic here
15:16 -!- lurker342457 [3aad4b1d@gateway/web/freenode/ip.58.173.75.29] has joined #bitcoin-core-dev     
15:17 -!- lurker342457 [3aad4b1d@gateway/web/freenode/ip.58.173.75.29] has quit [Client Quit]     
15:20 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has quit [Ping timeout: 272 seconds]     
15:28 -!- pkx2 [~pkx@unaffiliated/pkx] has quit [Remote host closed the connection]     
15:31 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
15:32 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has quit [Quit: Leaving]     
15:32 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]     
15:34 < talha_> whats the topic here?
15:35 -!- molz is now known as mlz     
15:36 < zelest> wumpus, heh, who needs sleep.. :D removed both trees and started over. seems to be compiling now.. \o/
15:41 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
15:45 < meshcollider> talha_: topic here is development of bitcoin core, not any other software or forks
15:48 -!- kkk [51100ac4@gateway/web/freenode/ip.81.16.10.196] has joined #bitcoin-core-dev     
15:48 -!- kkk is now known as Guest51641     
15:48 -!- Guest51641 [51100ac4@gateway/web/freenode/ip.81.16.10.196] has quit [Client Quit]     
15:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
16:04 -!- talha_ [27353fdd@gateway/web/freenode/ip.39.53.63.221] has quit [Ping timeout: 260 seconds]     
16:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
16:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:27 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
16:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
16:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:41 -!- cornben [~cornben@50-39-110-98.bvtn.or.frontiernet.net] has joined #bitcoin-core-dev     
16:43 -!- jb55 [~jb55@2605:8d80:4c0:a32f:a2af:bdff:fef0:c102] has joined #bitcoin-core-dev     
16:54 -!- jb55 [~jb55@2605:8d80:4c0:a32f:a2af:bdff:fef0:c102] has quit [Ping timeout: 252 seconds]     
17:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
17:02 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:08 -!- hytf [1f9774bd@gateway/web/freenode/ip.31.151.116.189] has joined #bitcoin-core-dev     
17:12 -!- hytf [1f9774bd@gateway/web/freenode/ip.31.151.116.189] has quit [Client Quit]     
17:13 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:35 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
17:35 -!- Moe [4db4d7a4@gateway/web/freenode/ip.77.180.215.164] has joined #bitcoin-core-dev     
17:35 < fanquake> Can someone add zeromq 4.2.2 & 4.2.3 to /depends-sources on bitcoincore.org
17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-micghrinihggzvij] has quit [Quit: Connection closed for inactivity]     
17:45 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
17:46 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:48 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 240 seconds]     
17:49 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:50 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
17:55 -!- Moe [4db4d7a4@gateway/web/freenode/ip.77.180.215.164] has quit []     
18:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
18:04 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 248 seconds]     
18:09 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds]     
18:15 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
18:19 -!- adafdgfdvdsfew [55cc859d@gateway/web/freenode/ip.85.204.133.157] has joined #bitcoin-core-dev     
18:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:25 -!- np [4b3a0961@gateway/web/freenode/ip.75.58.9.97] has joined #bitcoin-core-dev     
18:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:28 -!- np [4b3a0961@gateway/web/freenode/ip.75.58.9.97] has quit [Client Quit]     
18:38 -!- cornben1 [~cornben@66-87-113-239.pools.spcsdns.net] has joined #bitcoin-core-dev     
18:38 -!- cornben1 [~cornben@66-87-113-239.pools.spcsdns.net] has quit [Max SendQ exceeded]     
18:40 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:40 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
18:41 -!- cornben [~cornben@50-39-110-98.bvtn.or.frontiernet.net] has quit [Ping timeout: 248 seconds]     
18:41 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:43 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]     
18:47 -!- adafdgfdvdsfew [55cc859d@gateway/web/freenode/ip.85.204.133.157] has quit [Quit: Page closed]     
18:50 -!- cornben [~cornben@66-87-113-239.pools.spcsdns.net] has joined #bitcoin-core-dev     
18:50 -!- valentinewallace [32017b03@gateway/web/freenode/ip.50.1.123.3] has quit [Quit: Page closed]     
18:58 -!- cornben1 [~cornben@172.56.42.54] has joined #bitcoin-core-dev     
18:58 -!- cornben1 [~cornben@172.56.42.54] has quit [Max SendQ exceeded]     
19:00 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev     
19:00 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 252 seconds]     
19:01 -!- cornben [~cornben@66-87-113-239.pools.spcsdns.net] has quit [Ping timeout: 240 seconds]     
19:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:05 -!- billbrofaggins [792cf03b@gateway/web/freenode/ip.121.44.240.59] has joined #bitcoin-core-dev     
19:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:09 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:10 -!- cornben [~cornben@172.102.12.221] has joined #bitcoin-core-dev     
19:10 -!- cornben [~cornben@172.102.12.221] has quit [Max SendQ exceeded]     
19:11 -!- billbrofaggins [792cf03b@gateway/web/freenode/ip.121.44.240.59] has left #bitcoin-core-dev []     
19:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:18 -!- cornben [~cornben@2605:ef80:ab:ccd::] has joined #bitcoin-core-dev     
19:18 -!- cornben [~cornben@2605:ef80:ab:ccd::] has quit [Max SendQ exceeded]     
19:26 -!- cornben [~cornben@2605:ef80:b6:292d::] has joined #bitcoin-core-dev     
19:26 -!- cornben [~cornben@2605:ef80:b6:292d::] has quit [Max SendQ exceeded]     
19:27 -!- cornben [~cornben@2605:ef80:b6:292d::] has joined #bitcoin-core-dev     
19:27 -!- cornben [~cornben@2605:ef80:b6:292d::] has quit [Max SendQ exceeded]     
19:29 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
19:31 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
19:31 -!- gauravgoyal [~gauravgoy@103.227.53.88] has joined #bitcoin-core-dev     
19:33 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]     
19:33 -!- booyah is now known as booyah_     
19:37 -!- booyah_ is now known as booyah     
19:37 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev     
19:39 -!- cornben [~cornben@192.104.160.174] has joined #bitcoin-core-dev     
19:53 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
19:54 -!- gauravgoyal [~gauravgoy@103.227.53.88] has quit [Remote host closed the connection]     
20:03 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has quit [Quit: Computer has gone to sleep.]     
20:05 -!- kmkmkmkm [464a9e27@gateway/web/freenode/ip.70.74.158.39] has joined #bitcoin-core-dev     
20:07 -!- kmkmkmkm [464a9e27@gateway/web/freenode/ip.70.74.158.39] has quit [Client Quit]     
20:18 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds]     
20:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:19 -!- Syde [~root@64.140.119.122] has joined #bitcoin-core-dev     
20:20 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:22 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
20:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:33 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:44 -!- intx [intx@unaffiliated/intx] has joined #bitcoin-core-dev     
20:46 -!- spence [18650bcc@gateway/web/freenode/ip.24.101.11.204] has joined #bitcoin-core-dev     
20:49 < spence> I have a noob-ish question.  How does the code determine the buffer size when reading the blocks, like in reindexing?  I'm playing around with adding my own custom data structure to blocks, and I'm getting an ioerror "read attempted past buffer limit".
20:59 < sipa> ?     
21:05 < spence> sipa is that in response to me?
21:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:12 -!- phantomcircuit [~phantomci@192.241.205.97] has left #bitcoin-core-dev ["Leaving"]     
21:12 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev     
21:15 -!- cornben1 [~cornben@172.56.42.206] has joined #bitcoin-core-dev     
21:18 -!- cornben [~cornben@192.104.160.174] has quit [Ping timeout: 264 seconds]     
21:23 -!- spence [18650bcc@gateway/web/freenode/ip.24.101.11.204] has quit [Quit: Page closed]     
21:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:25 < meshcollider> spence: I would imagine so :) adding custom data structure to blocks sounds like ##altcoin-dev rather than this channel I think?
21:27 < Varunram> meshcollider: he quit :/
21:27 < meshcollider> Heh oh well
21:43 -!- murr4y [ali@100.94.211.130.bc.googleusercontent.com] has quit [Ping timeout: 265 seconds]     
21:46 -!- gauravgoyal [~gauravgoy@103.227.53.88] has joined #bitcoin-core-dev     
21:47 -!- gauravgoyal [~gauravgoy@103.227.53.88] has quit [Remote host closed the connection]     
21:49 -!- gauravgoyal [~gauravgoy@103.227.53.88] has joined #bitcoin-core-dev     
21:52 -!- Syde [~root@64.140.119.122] has quit [Ping timeout: 248 seconds]     
22:07 -!- Bosma [sid103570@gateway/web/irccloud.com/x-yqiftmilteomxipn] has joined #bitcoin-core-dev     
22:25 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:25 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
22:26 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-mabtjwplozfjegbs] has joined #bitcoin-core-dev     
22:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:34 -!- cornben [~cornben@50-39-110-98.bvtn.or.frontiernet.net] has joined #bitcoin-core-dev     
22:35 -!- cornben1 [~cornben@172.56.42.206] has quit [Ping timeout: 248 seconds]     
22:37 -!- youngentrepreneu [835b0426@gateway/web/freenode/ip.131.91.4.38] has joined #bitcoin-core-dev     
22:38 -!- youngentrepreneu [835b0426@gateway/web/freenode/ip.131.91.4.38] has quit [Client Quit]     
22:53 -!- gauravgoyal [~gauravgoy@103.227.53.88] has quit [Read error: Connection reset by peer]     
23:00 -!- viru [79f145e8@gateway/web/freenode/ip.121.241.69.232] has joined #bitcoin-core-dev     
23:00 < viru> hi     
23:01 -!- viru [79f145e8@gateway/web/freenode/ip.121.241.69.232] has quit [Client Quit]     
23:01 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has joined #bitcoin-core-dev     
23:01 -!- Cogito_Ergo_Sum [~Myself@80.107.151.135] has quit [Changing host]     
23:01 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
23:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dkwxllfvluoobnpp] has joined #bitcoin-core-dev     
23:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:07 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:12 -!- wvr- [~wvr@47.red-88-20-84.staticip.rima-tde.net] has joined #bitcoin-core-dev     
23:13 -!- wvr [~wvr@140.red-88-17-152.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds]     
23:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:15 < meshcollider> viru: hi
23:19 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
23:21 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
23:27 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
23:28 -!- dabura667 [~dabura667@153.142.228.110] has joined #bitcoin-core-dev     
23:56 < echeveria> wish list: getmempoolinfo should show the size of the extra transactions pool.