--- Day changed Thu Sep 21 2017 00:05 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds] 00:07 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 00:09 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 00:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:15 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 264 seconds] 00:16 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] 00:19 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 00:21 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 248 seconds] 00:21 -!- LeMiner2 is now known as LeMiner 00:37 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 01:09 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 01:12 -!- privateglacier [~AndChat67@2a02:120b:2c64:e630:d8d6:80f8:c22c:ea71] has joined #bitcoin-core-dev 01:13 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:24 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 01:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:34 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 01:34 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 01:34 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 01:35 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 01:38 < esotericnonsense> my smartphone is multiple years old and is more powerful than many machines i've synced a node from 01:39 < esotericnonsense> much better than a raspberry pi anyway :)\ 01:40 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 01:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 01:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 01:46 -!- privateglacier [~AndChat67@2a02:120b:2c64:e630:d8d6:80f8:c22c:ea71] has quit [Ping timeout: 252 seconds] 01:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:06 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 02:07 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has joined #bitcoin-core-dev 02:15 -!- sdfgsdfg_ [~sdfgsdfg@unaffiliated/sdfgsdfg] has joined #bitcoin-core-dev 02:15 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Quit: This computer has gone to sleep] 02:16 < sdfgsdfg_> ohio, how much until LN is tested on mainnet ? 02:16 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 02:37 < kallewoof> Someone wrote a post about that on reddit. One of the devs said two weeks I think. (LN is actually not bitcoin core, but a separate client entirely.) 02:41 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Quit: This computer has gone to sleep] 02:46 < meshcollider> link: https://www.reddit.com/r/Bitcoin/comments/714x2k/what_is_the_status_of_the_lightning_network/dn8docc/ 02:50 < promag> wumpus: is there a thread pool for RPC handling? 03:01 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 03:19 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 246 seconds] 03:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 03:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 03:30 -!- sdfgsdfg_ [~sdfgsdfg@unaffiliated/sdfgsdfg] has quit [Read error: Connection reset by peer] 03:33 -!- sdfgsdfg [~sdfgsdfg@unaffiliated/sdfgsdfg] has joined #bitcoin-core-dev 03:38 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] 03:43 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 03:47 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 04:07 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 04:29 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 04:30 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 04:30 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has joined #bitcoin-core-dev 04:36 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev 04:41 -!- duringo [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 04:52 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 04:52 -!- duringo [~Mutter@192.3.207.58] has quit [Read error: Connection reset by peer] 05:05 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer] 05:05 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Write error: Connection reset by peer] 05:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Read error: Connection reset by peer] 05:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Write error: Connection reset by peer] 05:05 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Write error: Connection reset by peer] 05:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 05:15 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 05:21 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 05:29 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 05:32 -!- duringo [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 05:37 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 05:37 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 05:37 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 05:37 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 05:38 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 05:49 -!- duringo_ [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 05:49 -!- duringo [~Mutter@192.3.207.58] has quit [Read error: Connection reset by peer] 05:49 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 05:49 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit] 05:58 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [] 05:58 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 06:06 -!- duringo_ [~Mutter@192.3.207.58] has quit [Quit: Mutter: www.mutterirc.com] 06:10 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 06:12 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 06:12 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 246 seconds] 06:14 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 06:17 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:29 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 06:40 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 246 seconds] 06:45 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 06:50 -!- harrymm [~harrymm@85.203.47.66] has quit [] 06:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds] 06:52 -!- harrymm [~harrymm@85.203.47.56] has joined #bitcoin-core-dev 06:53 -!- Giszmo [~leo@ip-238-236-219-201.nextelmovil.cl] has joined #bitcoin-core-dev 06:55 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 06:56 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 06:59 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 07:01 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Ping timeout: 248 seconds] 07:08 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 07:12 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 07:14 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 07:14 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev 07:18 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 07:28 -!- harrymm [~harrymm@85.203.47.56] has quit [] 07:29 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 246 seconds] 07:29 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 07:33 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has quit [Ping timeout: 264 seconds] 07:34 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 07:40 -!- StopAndDecrypt_ [~StopAndDe@142.75.255.199] has quit [Read error: Connection reset by peer] 07:48 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 07:54 -!- StopAndDecrypt_ [~StopAndDe@142.75.255.199] has joined #bitcoin-core-dev 08:00 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 08:07 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-mhptqbdplzujillq] has quit [Quit: Connection closed for inactivity] 08:10 -!- harrymm [~harrymm@85.203.47.40] has joined #bitcoin-core-dev 08:13 < bitcoin-git> [bitcoin] aqibbak opened pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381 08:19 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 08:19 -!- Giszmo [~leo@ip-238-236-219-201.nextelmovil.cl] has quit [Ping timeout: 255 seconds] 08:23 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 08:25 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev 08:29 -!- harrymm [~harrymm@85.203.47.40] has quit [Remote host closed the connection] 08:30 -!- harrymm [~harrymm@85.203.47.40] has joined #bitcoin-core-dev 08:34 < wumpus> promag: yes, the HTTP worker threads 08:39 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 08:41 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit] 08:45 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:46 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev 08:47 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 08:48 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:51 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Client Quit] 09:01 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has joined #bitcoin-core-dev 09:15 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 09:15 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit [] 09:19 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 09:35 -!- sdfgsdfg [~sdfgsdfg@unaffiliated/sdfgsdfg] has quit [Ping timeout: 252 seconds] 09:46 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 09:46 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 248 seconds] 09:47 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit] 09:49 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:03 < ossifrage> The 'reindexing blocks on disk...' progress bar flaps around quite a bit, not exactly a stable progress bar 10:05 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 10:10 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Read error: Connection reset by peer] 10:23 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 10:24 < wumpus> at least better than not showing progress at all 10:25 < ossifrage> wumpus, yeah it just was flapping between "5 year" and "3 years" behind, which is a bit extreme 10:26 < gmaxwell> huh.... 10:26 < gmaxwell> it shouldn't do that 10:26 < ossifrage> I restarted the node with txindex=1 10:26 -!- Deadhand [~deadhand@CPE6038e0be3871-CMf0f249a14e40.cpe.net.cable.rogers.com] has quit [Ping timeout: 248 seconds] 10:26 < ossifrage> I set dbcache to 4096 10:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hnrdqaedovicyimb] has joined #bitcoin-core-dev 10:27 < wumpus> I expect there to be larger variance in the beginning, once it gets to the blocks that are actually filled, it's probably more stable 10:28 < ossifrage> I thought the estimate was just based on block count not transaction count? 10:29 < sipa> no, it's based on transaction count 10:29 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 10:29 < ossifrage> Now it is flapping + 1 year 10:30 -!- Deadhand [~deadhand@CPE6038e0be3871-CMf0f249a14e40.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev 10:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:36 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds] 10:40 < wumpus> I've never seen it flapping here, though I must say I haven't ever paid close attention to it, after all it's hardly something you can wait for to complete :) 10:43 < ossifrage> Maybe it is specific to reindexing with txindex=1... Oddly it doesn't seem to be io bound or cpu bound (none of the threads consume 100% cpu). Lock contention? Or maybe blocking on fsync()? 10:44 < wumpus> that's just in the beginning, it will get cpu bound soon enough 10:45 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381 10:46 < gmaxwell> if its flaping then it doesn't work like I understood... 10:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:48 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:48 < ossifrage> Both the bar and the text are flapping but the "Progress x%" is counting up smoothly (that must be just block height?) 10:48 < wumpus> before it gets to the blocks that require serious validation I expect it's mostly waiting for i/o latency (reading blocks from disk, updating db), interspersed with a bit of cpu use 10:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 10:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:51 < wumpus> I don't think it has used block height as a progress measure in the UI since 0.5.x or so 10:53 < wumpus> block height is pretty useless for that because it starts off really fast and then slows down more and more 10:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:06 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:12 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 11:13 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 240 seconds] 11:25 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:30 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 11:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:41 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 11:56 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-zpyebmccyobsxhbm] has joined #bitcoin-core-dev 11:58 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 12:00 < sipa> meetung? 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Sep 21 19:00:26 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 < 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 12:00 < kanzure> hi. 12:00 < sipa> hi. 12:01 < meshcollider> hello 12:01 < cfields> hi 12:01 < sdaftuar> hey 12:01 < luke-jr> hi 12:01 < jnewbery> hello 12:02 < achow101> hi 12:02 < wumpus> so PSA: we've released 0.15.0.1 with a single patch #11332, compared to 0.15.0, to solve the qt crash issue for some users 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11332 | Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) by jonasschnelli · Pull Request #11332 · bitcoin/bitcoin · GitHub 12:02 < sdaftuar> yay 12:02 < wumpus> #topic high-priority for review 12:03 < achow101> #10871 please? 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/10871 | Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) by achow101 · Pull Request #10871 · bitcoin/bitcoin · GitHub 12:03 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has quit [Ping timeout: 240 seconds] 12:03 < wumpus> I don't think we made much progress on review, this week (me included) 12:03 < BlueMatt> no, we (or at least I) did not :( 12:04 < sipa> regarding that: i've seen several reports of people wondering what happened because getinfo doesn't work... i guess they went from 0.14 to 0.5.99 and never saw the deprecation 12:04 < gmaxwell> Well they shouldn't run 0.5, that would be bad. 12:04 < wumpus> added 10871 12:04 < BlueMatt> heh, so, what, when a new release is announced they just build master? :( 12:05 < luke-jr> Maybe `bitcoin-cli getinfo` should print a message informing the user about the new RPCs, like we did when bitcoind client got deprecated 12:05 < gmaxwell> BlueMatt: some people do that. 12:05 < wumpus> luke-jr: also thought about that 12:05 < BlueMatt> gmaxwell: wat 12:05 < luke-jr> lol 12:05 < wumpus> luke-jr: it should at least print a deprecated message 12:05 < sipa> BlueMatt: gmaxwell is joking about my typo (0.5 instead of 0.15) 12:05 < BlueMatt> gmaxwell: so...what you're saying is we should start using a "develop" branch with master pointing to released versions? 12:05 < BlueMatt> sipa: i figured...... 12:05 < wumpus> luke-jr: instead of just about a missing call, as if it's never existed 12:06 < sipa> i like the approach being used for the estimatefee deprecation 12:06 < luke-jr> BlueMatt: github lets you change the default branch, so we could just make it the latest stable branch 12:06 < goatpig> dont poeple typically pull tags, not just the head of a branch (in this case master) 12:06 < wumpus> BlueMatt: or we can just change the github default branch to something else, you know 12:06 < luke-jr> problem is, it's also the default for PRs… 12:06 < BlueMatt> wumpus: yea, possible 12:06 < sipa> where it disappears, but you have a cmdline switch to re-enable 12:06 < BlueMatt> I mean really not joking there that's a serious issue 12:06 < wumpus> but yes, PRs also go there by default, whichi s kinda annoying 12:06 < BlueMatt> people building master right after release is usually bad cause we merge lots of fun stuff on master right after release :/ 12:06 < achow101> topic suggestion: deprecation stuff a la #11031 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub 12:07 < luke-jr> I suppose we can expect developers to be smarter than users 12:07 < gmaxwell> BlueMatt: I am not saying we should, just pointing out people do that. We have warnings on master... so I don't worry too much. 12:07 < cfields> sipa: i like that too. or even an rpc arg like -force-deprecated. 12:07 < wumpus> PRs to branches are really annoying, so I'd prefer to just keep the status quo there 12:07 < BlueMatt> gmaxwell: yea, maybe we should make the warnings louder? 12:07 < BlueMatt> that may be acceptable similar 12:07 < sipa> i think the reports saw were from pretty much first time users "how do i set this up", and following a guide to build from source 12:07 < luke-jr> cfields: better to force the user to be involved IMO 12:07 < sipa> wumpus: agree 12:08 < wumpus> it can't be the release announcement, as I mention the exact tag to check out there... 12:08 < jonasschnelli> hi 12:08 < cfields> luke-jr: that's what i meant. 12:08 < luke-jr> cfields: a RPC arg wouldn't have the user involved 12:08 < BlueMatt> maybe bitcoind should need a -iknowthisisunreleasedunstableversion option :( 12:08 < luke-jr> software would just set it 12:08 < wumpus> maybe would make sense to add a git clone command in there too for people that can't figure that out themselves 12:08 < BlueMatt> or configure could take it 12:09 < luke-jr> BlueMatt: default to testnet? 12:09 < cfields> luke-jr: oh ok, different definitions of user. i see what you mean. 12:09 < wumpus> configure already has that information, so that'd make sense 12:09 < BlueMatt> ./configure --this-version-is-unreleased-and-possibly-unstable 12:09 < BlueMatt> that would make people think twice and make people fix their guides 12:09 < luke-jr> s/unstable/insecure/ ☺ 12:09 < achow101> luke-jr: we would forget to make it default to mainnet for releases 12:10 < BlueMatt> heh, ok, at the risk of bikeshedding, I vote cfields implement it...I dunno anything 'bout autotools 12:10 < BlueMatt> :p 12:10 < luke-jr> achow101: would we? release-process.md 12:10 < wumpus> I've never forget to set IS_RELEASE to true for releases 12:10 < wumpus> a few times we've forgot to bump the version number but only for *minor* releases 12:10 < luke-jr> or just have -testnet default to !IS_RELEASE 12:10 < cfields> heh 12:10 < wumpus> and for branches the IS_RELEASE is always true anyhow 12:10 < BlueMatt> luke-jr: I kinda like it not modifying the bitcoind at all now that i think about it 12:11 < sipa> wumpus: an alternative would be to have a bitcoin-releases repo (under the same org), to which only release tags get pushed 12:11 < BlueMatt> build the same bitcoind, but make people type something that says "is not release" 12:11 < sipa> wumpus: and direct people to clone from there if they just want stable things 12:11 < sipa> but meh... 12:11 < wumpus> sipa: I don't know... 12:11 < BlueMatt> sipa: heh, if we make it not build from bitcoin/bitcoin, ok 12:11 < wumpus> I really prefer not to mess with the repopsotiry too much 12:11 < jonasschnelli> agree with wumpus 12:11 < morcos> This doesn't seem that large a problem to me... 12:11 < sipa> wumpus: yes, agree - i don't think we should do anything 12:11 < wumpus> agree 12:11 < wumpus> any other topics? 12:11 < BlueMatt> agreed, though I'd vote for a configure flag 12:11 < achow101> we could move the repo to bitcoin-core and break all of those guides :) 12:12 < gmaxwell> yea, I think we don't need to do anything except hunt down and kill people with bad guides. :P 12:12 < sipa> achow101 had a topic 12:12 < BlueMatt> its not a huge issue, but it sounds rather dangerous 12:12 < sipa> (though maybe we've covered it already) 12:12 < gmaxwell> perhaps increase the profile of tarball downloads. 12:12 < BlueMatt> and I dont think hunting down guide-writers is possible 12:12 < wumpus> gmaxwell: now that sounds like a good action item 12:12 < wumpus> $action hunt down and kill people with bad guides 12:12 < gmaxwell> BlueMatt: publishers, not technically authors. 12:12 < jnewbery> any other feedback on the approach in #11031? I think it's a useful pattern for deprecating RPCs (which we'll need to do a few times) 12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub 12:13 < wumpus> #topic deprecation stuff a la #11031 12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub 12:13 < luke-jr> there's only 363 0.15.99 nodes 12:14 < BlueMatt> luke-jr: I'd expect there to be ~0 on mainnet aside from some developer test nodes, fwiw 12:14 < achow101> I think that we might run into a problem where people just have -deprecatedrpc (or whatever it is called) and enable all deprecated behavior until it disappears 12:14 < BlueMatt> achow101: thats fine, at least they were made to type "I know this is going away soon" 12:14 < BlueMatt> so they cant show up and complain that its gone 12:14 < cfields> jnewbery: i like it (better than an rpc arg, on second thought), though the name could use some bikeshedding :( 12:15 < jonasschnelli> luke-jr: my crawler counts 2496 12:15 < jonasschnelli> oh.. no .99,.. sry 12:15 < wumpus> I also prefer command line arg to rpc arg 12:15 < wumpus> it's enough to type it once 12:16 < jnewbery> achow101: it's designed such that the user needs to include `-enablerpcmethod= -enablerpcmethod= ...` to avoid the problem of a user just setting `-enablealldepractedrpcmethods` and forgetting 12:16 < jnewbery> cfields: yes, name could probably be improved 12:16 < gmaxwell> yea, don't have a deprecatedall, it needs to be specific. 12:16 < wumpus> the purpose is just to signal, not to overburden a user with extra work updating their client applications (apart from getting rid of using the RPC call in the first place) 12:16 < meshcollider> hmm yeah "-enablerpcmethod=" should probably have the word "deprecated" in it 12:17 < wumpus> yes 12:17 < achow101> I propose calling it -enableddeprecatedrpc 12:17 < jonasschnelli> ack 12:17 < wumpus> otherwise it sounds more like a silly security feature 12:17 < meshcollider> +! 12:17 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has joined #bitcoin-core-dev 12:17 < meshcollider> s/!/1/ 12:17 < sipa> -yesimnaughtyandneedtoupdatemyclienttonotuserpcmethod=name 12:18 < achow101> although maybe enabled may not necessarily be the best word for that since we have PRCs that themselves are not deprecated but have deprecated output fields and only the deprecated output fields would show if that option is set 12:18 < luke-jr> thought: should rpcuser auth always throw RPC_METHOD_DEPRECATED? if so, how does the user bypass it? 12:18 < morcos> -deprecatedrpc is good enough 12:18 < luke-jr> maybe -enabledeprecated= would be better 12:18 < wumpus> morcos: yes! 12:18 < morcos> in a light pink 12:18 < gmaxwell> -backwardscompatibilitylaunchcode=0xdeadbeef234828429342893429 < that could trigger fields that are going away. :P 12:19 < wumpus> hehehe 12:19 < gmaxwell> (and you need to read the release notes to get the launch code) 12:19 < gmaxwell> (or source) 12:19 < jnewbery> ok, -deprecatedrpc it is 12:19 < wumpus> release notes scavenger hunt 12:19 < cfields> gmaxwell: where the launchcode is the git commit, so it changes every day until release 12:20 < cfields> jnewbery: ack 12:20 < gmaxwell> well the idea there was that each depricated feature would have its own code. So you'd look up the code and specify it. 12:20 < luke-jr> gmaxwell: too strong for mere deprecation IMO 12:20 < gmaxwell> luke-jr: yes, though it solved the how about deprecated fields case. 12:20 < luke-jr> something like that feels more like to allow changing consensus-critical stuff 12:20 < achow101> I suppose we can then put all of the deprecated account RPCs behind that argument 12:21 < cfields> gmaxwell: you're deprecating me? :( 12:21 < wumpus> yes 12:21 < luke-jr> gmaxwell: how about if the "launch code" matches the method name for methods? :p 12:21 < luke-jr> and "accounts" for accounts 12:21 < wumpus> in the case of accounts it'd be a group not one single call 12:21 < luke-jr> "rpcuser" for -rpcuser 12:21 < wumpus> right 12:21 < luke-jr> this code already fits that paradigm I think, except for the param name 12:21 < achow101> luke-jr: doing that for rpcuser is going to annoy a lot of people 12:22 < luke-jr> achow101: yes, that can be discussed separately; it was an example 12:22 < wumpus> I think we should keep the discussion of what things to deprecate separate 12:22 < sipa> agree 12:22 < achow101> ok 12:23 < jonasschnelli> removing the account support via -depracaterpc and positioned arguments seems pretty difficult and/or dangerous. 12:24 < jnewbery> achow101: As long as you're happy with that I'll update 11031 with the new name so you can rebase your various RPC deprecation PRs on it 12:24 < luke-jr> "rpc" probably shouldn't be in the arg name. 12:24 < jonasschnelli> users may be confuse why account are deprecated but still work while -depacaterpc=accounts 12:24 < luke-jr> -enabledeprecated seemed nicer IMO 12:25 < achow101> jnewbery: I guess so. I haven't looked over 11031 in a while so I want to review it before rebasing 12:25 < wumpus> jonasschnelli: it's just the account rpcs that are deprecated, accounts themselves will work as labels 12:25 < meshcollider> jonasschnelli: are you suggesting disable the account system completely? 12:25 < meshcollider> (without deprecation) 12:25 < jonasschnelli> wumpus: yes. That makes sense. 12:25 < wumpus> we'll not rip out the account arguments from any non-account RPC calls 12:25 < wumpus> just that move etc are deprecated 12:26 < achow101> topic suggestion: what to deprecate 12:26 < jonasschnelli> But the transition of having a -enabledepracatedrpc= and not disabling the depracated account features seems not to be ideal.. although I guess it's okay 12:27 < wumpus> I doubt there is any ideal way to deprecate a monster like the accounts feature, tbh 12:27 < luke-jr> wumpus: getbalance should fail too 12:27 < wumpus> luke-jr: yes 12:28 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:28 < luke-jr> jonasschnelli: no "rpc" :/ 12:28 < wumpus> do we have any more upbeat topic than deprecation? 12:28 < gmaxwell> China blocking bitcoin? 12:28 < gmaxwell> (not really) 12:28 < meshcollider> segwit wallet support progress? 12:28 < gmaxwell> That 12:28 < sipa> i'll have a PR soon 12:28 < wumpus> #topic segwit wallet support progress 12:28 < wumpus> thanks 12:29 < sipa> otherwise, review #11167 12:29 < gmaxwell> sipa: Have you heard from thomasv about them blocking v>0 12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub 12:29 < sipa> gmaxwell: yes, we discussed it in here yesterday 12:29 < achow101> sipa: how soon is soon 12:29 < sipa> achow101: this week, i hope 12:29 < jonasschnelli> sipa: are you also tackling the GUI? 12:30 < gmaxwell> did you take my advice and call the new file key-i-key-i-o.cpp 12:30 < sipa> jonasschnelli: no, i'll need help for that 12:30 < sipa> gmaxwell: just key_io 12:30 < meshcollider> haha 12:30 < jonasschnelli> sipa: please point me to your branch after the meeting so I can start to work on that 12:30 < sipa> (for context, gmaxwell is talking about the followup #11372, which is not for 0.15.1) 12:30 < gribble> https://github.com/bitcoin/bitcoin/issues/11372 | Address encoding cleanup by sipa · Pull Request #11372 · bitcoin/bitcoin · GitHub 12:31 < gmaxwell> There should be almost no GUI intersection, other than perhaps offering the default overrides in the gui. 12:31 < sipa> yeah, i expect some expert mode setting to choose the address type - but otherwise it can just use the default 12:31 < gmaxwell> oh right, point of use switching, sure. 12:31 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 12:31 < jonasschnelli> sipa: yes. That is what I though... 12:32 < sipa> not that much to say about the topic otherwise 12:32 < gmaxwell> jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter. We need a monospace text entry field that can be told to underline characters or something like that. 12:32 < gmaxwell> (not necessarily a 0.15.1 feature in any case) 12:32 < jonasschnelli> Yes! I just wanted to write that 12:32 < gmaxwell> well sipa's bip173 patch doesn't have the error finder in it. 12:33 < sipa> i think there is another question, that ThomasV brought up yesterday 12:33 < sipa> what to do with private key import/export for segwit addresses 12:33 < gmaxwell> Though we've written one (a port of it to JS is on that demo page)... it deserves a nice gui handling though (even the js demo is kind of lame, in that it can't highlight inline) 12:33 < wumpus> some importmulti ? 12:33 < achow101> sipa: importmulti 12:33 < sipa> importmulti can handle this natively 12:33 < wumpus> ok, seems good enough for me then 12:33 < gmaxwell> importmulti was my first thought too. 12:33 < achow101> deprecate the other import* rpcs 12:33 < sipa> but perhaps at least a warning for importprivkey / dumpprivkey is needed 12:34 < wumpus> just highlight that the old import* rpcs don't work with segwit 12:34 < jonasschnelli> sipa: yes. Or depracate? 12:34 < gmaxwell> When we do the changes that split the key types later, we'll have more to think about. Right now any key is all keytypes. 12:34 < wumpus> or deprecate them at some point, but not for a minor release 12:34 < sipa> right 12:34 < gmaxwell> we can announce an intent at any time. (I think we just did.) 12:34 < ThomasV> importmulti does not seem as easy to use as a serialized format 12:34 < wumpus> yes, intent+reason could be menitoned in the release notes 12:35 < sipa> ThomasV: i consider that a feature :) 12:35 < gmaxwell> ThomasV: because of versioning issues, we're not going to solve a new serialized format right now. 12:35 < jonasschnelli> importmulti is a bit cumbersome to use,... but should the okay for an RPC layer 12:35 < wumpus> importing keys in bitcoin core is considered advanced functionality anyhow 12:36 < sipa> ThomasV: as said, i don't mind discussing a more convenient import format for some use case, but we're not going to solve that instantly 12:36 < jonasschnelli> importaddress and key with the current rescan-everything approach must go away at some point anyways 12:36 < wumpus> jonasschnelli: yeah... that too 12:36 < ThomasV> gmaxwell: we were also considering an import format along the lines of bip124 12:36 < gmaxwell> raw key handling frequently results in funds loss, even for advanced users too.. but I do think we should ultimately be embedding the required metadata to actually use a key. but it's not something we can really do right now. 12:36 < achow101> the bech32-for-privkeys thing could be something for segwit only and have a the witness version number included in that? 12:37 < wumpus> achow101: yes 12:37 < sipa> achow101: yes, or no - i'm not sure 12:37 < gmaxwell> achow101: witness version number isn't the right data. 12:37 < sipa> i think we need a 'pure private key' format, which is just a key 12:37 < instagibbs> doesn't tell you how it's being used, specifically 12:37 < sipa> to minimize the data needed for backup 12:37 < wumpus> more like a 'key use' 12:37 < gmaxwell> it effectively needs to communicate the scriptpubkey (perhaps be template reference). 12:38 < sipa> the associated addresses/chains/... can be stored separately 12:38 < jonasschnelli> Not sure if we should really support exporting / importing private keys over an RPC layer in the long run 12:38 < luke-jr> sipa: but if you're going for minimal, you'd backup the seed, not the keys? 12:38 < sipa> jonasschnelli: yeah... that's a hard question 12:38 < gmaxwell> sipa: still needs metadata. 12:38 < sipa> gmaxwell: how so? 12:38 < wumpus> right, you could backup the seed, and some metadata, no need to backup the keys themselves 12:38 < achow101> | 12:39 < gmaxwell> I mean you need to know _what_ chains or key types are expected. Otherwise it's a lossy search problem to figure out what you should be actually getting. 12:39 < wumpus> yes 12:39 < sipa> gmaxwell: sure, but i think that can be separate 12:39 < sipa> ideally, your wallet has 1 piece of actually secret data, and then a bunch of chains/addresses/scripts/... that use keys derived from that secret data 12:39 < gmaxwell> it's critical data without which you can't recover the keys... and with which you can. (maybe you could bruteforce it out, under somewhat reasonble assumptions...) 12:40 < jonasschnelli> Conceptual, we should work towards private key separation with a daemon (or agent) and core only deals with public keys. The private-keys agent/tool could still be in the repository (or different one) 12:40 < gmaxwell> it's also potentially a rather small amount of data. 12:40 < sipa> gmaxwell: an example i came up yesterday is CLTV scripts 12:40 < sipa> there is no way you can enumerate all CLTV scripts from a particular seed 12:41 < gmaxwell> no, indeed, but the inability to back up CLTV cleanly was one of the motivations for CSV. 12:41 < sipa> but perhaps there is no need, if you have built-in backups of the chain data (which don't risk monetary loss), and a separate backup of the private key 12:41 < luke-jr> so three levels of data really: the seed itself, the types/chains/etc, and the comments/labels 12:41 < sipa> the private key in that case is just a piece of secret data, referred to by the chains 12:41 < gmaxwell> asking people to handle two critical to maintain pieces of information instead of one would be unfortunate. 12:42 < gmaxwell> (and by unfortunate I mean result in non-negligible funds loss in practice) 12:42 < luke-jr> gmaxwell: maybe concatenate seed + types/chains/etc in practice 12:42 < sipa> sure, for simple situations you can create a convenient format that handles both simultaneously 12:42 < gmaxwell> sure. that would be okay to. 12:42 < wumpus> you could encode it into one identifier somehow... 12:42 < wumpus> sounds easy enough 12:42 < gmaxwell> (re to both luke and sipa) 12:42 < sipa> but i expect there to be cases where you really just want to backup a key, and will handle the metadata (which is too complicated) yourself 12:43 < gmaxwell> the logical seperation sounds fine, but for at least the common case there should be some format for combined data. 12:43 < sipa> sure 12:43 < morcos> +1 for the common case combined format 12:43 < gmaxwell> A possible metadata flag is 'external, good luck'. :) 12:44 < jonasschnelli> X509 12:44 < sipa> JSONx!! 12:44 < ThomasV> lol 12:44 * jonasschnelli *ducks* 12:44 < wumpus> you could always back up the key and metadata separately, then combine them before importing, or have import accept multiple formats, this is just details 12:44 < gmaxwell> Could just have a box where people can just type in x86 machine code and it will decode the result for you ... almost as flexible as x509. 12:44 < gmaxwell> :-) 12:45 < luke-jr> XD 12:45 < sipa> ok, other topics? 12:45 < wumpus> nice, though too easy to use, should be some ancient 8-bit assembly like z80 or 6502 12:46 < sipa> INTERCAL 12:46 < luke-jr> suggested topic: it would be really nice to get #7533 in, since it is a constant rebase hell otherwise; comments on how to improve the code quality (ugh, macros) appreciated 12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub 12:46 < gmaxwell> I've had to use 6502 assembly in the last couple years ... (for a mystery hunt puzzle) 12:46 < wumpus> yeah 12:47 < wumpus> gmaxwell: did you still manage to? :) 12:47 < gmaxwell> other topics: did people see on the mailing list that there is a new Dandelion post? 12:47 < jnewbery> wumpus: you suggested topic high-priority for review earlier. Did you want to discuss individual PRs or were you just asking if people had PRs they want added to the list? 12:47 < meshcollider> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html 12:47 < wumpus> #topic Dandelion post 12:48 < wumpus> jnewbery: both is ok, though there are too many PRs on the list right now, would prefer some to be reviewed first - the point of it focusing review is lost if we just add all PRs in there :) 12:48 < gmaxwell> I don't know that I have much to say, other that I thought it should get some attention (I know not everyone reads the list closely). I think this will be a good thing to implement and the people working on it are pretty eager. 12:48 < gmaxwell> (and responsive) 12:49 < jnewbery> wumpus: ok, tit-for-tat. I'll review a couple of those in the next week. Can you add #10740. I think it's ready for initial review 12:49 < wumpus> thanks for mentioning it, I indeed missed it 12:49 < gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub 12:49 < wumpus> #link https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html 12:50 * BlueMatt is curious how this interacts with the questions about mempool sync 12:50 < BlueMatt> though I havent read the dandelion stuff much 12:50 < wumpus> jnewbery: ok added 12:50 < gmaxwell> BlueMatt: externally to it. Basically it's a quiet forwarding thing that has little to no mempool interaction. 12:50 < jnewbery> wumpus: thanks! 12:50 < gmaxwell> BlueMatt: so that public distribution of transactions happens away from the source. 12:51 < BlueMatt> gmaxwell: well based on the dandelion tl; dr i just got, it seems to me that dandelion is essentially the old mempool-sync proposal of "relay txn to only one, maybe two peers but then do sync of your mempool with your peers every so often to propagate things more fully" 12:51 < BlueMatt> except they replace sync with "broadcast after a while" 12:52 < gmaxwell> BlueMatt: kind of. it's not in your mempool though when it passes through in the one at a time propagation. 12:52 < sipa> BlueMatt: but dandelion has rebroadcast too, which can't be avoided (if you dandelion-forwarded a TX, but don't see it N seconds later on the normal network, you yourself start broadcasting it normally) 12:52 < morcos> sipa: why not dandelion it again? 12:53 < BlueMatt> sipa: yes, I'm asking for comparison between dandelion and the old mempool-sync proposal of gmaxwell 12:53 < sipa> morcos: the dandelion stem isn't expected to reach the entire network 12:53 < BlueMatt> it sounds to me like the gmaxwell proposal is effeciely similar, though maybe dandelion pointed out (correctly, I suppose) that you want to not add it to your mempool until later to preserve privacy 12:53 < sipa> so you still need something outside of dandelion-forward and mempool reconciliation 12:53 < gmaxwell> Peer hands you a txn with a private flag. Assuming the txn is valid wrt your mempool, you set it aside and forward it on to a single other peer (determinstically selected based on the input peer). At random, you drop the private flag when you relay it with some fixed probablity. If the txn is offered by other peers you fetch it. 12:54 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:54 < gmaxwell> If after a timeout you never see it from other peers you broadcast it yourself.. but that only happens if someone in the 'stem' path drops the ball. 12:54 < sipa> BlueMatt: there seems to be some overlap, but i don't think dandelion+sync is a complete solution 12:55 < gmaxwell> so it is similar to my relay improvement proposal, but the privacy requirements mean that it doesn't accomplish syncing itself. 12:55 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:55 < morcos> sipa: hmm, i was just asking if you didn't see it, why you wouldn't repeat the whole process assuming the stem got cut somehwere, and hoping that you can get to the fluff on try 2. why fall back to old method 12:55 < BlueMatt> wait, wait doesnt "(determinstically selected based on the input peer)" imply that you can still group transactions from a single source based on where you first saw them....sure where you first saw them wont be the guy who created it, but it'll still be the same for all txn from the same guy 12:55 < BlueMatt> maybe I should shut up and go read it 12:55 < sipa> morcos: the 'fluff' is just normal tx relay 12:55 < gmaxwell> BlueMatt: so it is like my relay bandwidth improving proposal, without improving relay bandwidth. :P 12:56 < BlueMatt> heh, yea, ok 12:56 < gmaxwell> BlueMatt: only if you are inside the stem yourself. (this was a change their latest work makes) 12:56 < BlueMatt> hmm, alright 12:57 < gmaxwell> the tradeoff is that if you don't do the determinstic routing and the sender sends lots of txn you are certian to be in the stem for some of them. 12:57 < gmaxwell> basically related to the guardnodes problem in tor. 12:57 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 264 seconds] 12:58 < gmaxwell> in any case, it would be good to have more critical eyes on their design. I've only just started thinking about the implications of the change to determinstic paths. 12:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 12:59 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 13:00 < sipa> PLOINK 13:00 < wumpus> yes, extrememly important for privacy to not make any mistakes here 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Sep 21 20:00:18 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.log.html 13:00 < gmaxwell> wumpus: At least the current behavior is weak enough that it would be hard to not make an improvement. :) 13:00 < BlueMatt> hah, yea, that ^ 13:02 < wumpus> sure 13:04 < gmaxwell> unrelated, my gpg encryption subkey expired a bit ago. I just replaced it with a newly generated one... with the rationale that its good to rotate such things, and unlike identity keys, easy to rotate them. I can still decrypt with the old one for now. 13:05 < wumpus> your new key is on the keyserver? 13:05 < achow101> does anyone know when verack was added to the protocol? It's not in the first version but I can't find any documentation about it 13:05 < wumpus> apparently it is, refresh-key worked gpg: new subkeys: 1 13:06 < gmaxwell> wumpus: yes. as of about the beginning of the meeting. 13:06 < sipa> achow101: 0.2.9 13:08 < achow101> sipa: thanks 13:08 < wumpus> sipa: achow101: seems it's missing here https://bitcoin.org/en/developer-reference#protocol-versions 13:09 < achow101> wumpus: yeah, I noticed 13:09 < wumpus> only mentions adding the checksum field there 13:09 < achow101> I assume that's because that's all the commit message mentions too 13:09 < wumpus> please file a PR :) 13:10 < luke-jr> FYI https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668 13:10 < wumpus> luke-jr: :-( 13:10 * luke-jr wonders if it's really only Skylake+ 13:13 < BlueMatt> #11116 could probably use a merge 13:13 < gribble> https://github.com/bitcoin/bitcoin/issues/11116 | [script] Unit tests for script/standard and IsMine functions. by jimpo · Pull Request #11116 · bitcoin/bitcoin · GitHub 13:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 13:15 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 260 seconds] 13:16 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 13:16 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/98212745c8ac...49f3d57eeb66 13:16 < bitcoin-git> bitcoin/master d7afe2d Jim Posen: [script] Unit tests for script/standard functions 13:16 < bitcoin-git> bitcoin/master 7a1e873 Jim Posen: [script] Unit tests for IsMine... 13:16 < bitcoin-git> bitcoin/master 49f3d57 Wladimir J. van der Laan: Merge #11116: [script] Unit tests for script/standard and IsMine functions.... 13:17 < bitcoin-git> [bitcoin] laanwj closed pull request #11116: [script] Unit tests for script/standard and IsMine functions. (master...script-standard-tests) https://github.com/bitcoin/bitcoin/pull/11116 13:21 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Quit: This computer has gone to sleep] 13:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds] 13:31 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 14:20 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] 14:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 14:26 -!- alxlu [~alxlu@138.68.58.104] has quit [Quit: ZNC 1.6.5 - http://znc.in] 14:30 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 14:30 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Client Quit] 14:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 14:36 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 14:36 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 14:40 < promag> wumpus: jnewbery: is there a strong reason to #10740 have high priority review? 14:40 < gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub 14:42 < jnewbery> promag: because it's likely to take quite a bit of review and I'd like it in for 0.16. It will also provide a resolution to the keypool topup corner cases that prevented a full fix for that issue getting into v0.15. 14:44 < luke-jr> #10615 and GUI support should go before 10740.. 14:44 < gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub 14:44 -!- duringo [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 14:44 < luke-jr> far more important to be able to actually use it, than dynamic open/close 14:45 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-tjiwyfzsnftuhazp] has quit [Ping timeout: 252 seconds] 14:45 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-krbiciduxrqbtnnc] has quit [Ping timeout: 252 seconds] 14:46 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-sbdvzrsnnukgcezr] has quit [Ping timeout: 252 seconds] 14:46 < promag> luke-jr: no PR for GUI support right? 14:46 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-ehlsrvmnkhwwjmac] has quit [Ping timeout: 252 seconds] 14:46 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-isdnvleermcqsayi] has quit [Ping timeout: 252 seconds] 14:47 -!- chainhead [~chainhead@2001:19f0:5:e14:5400:ff:fe77:e3d4] has quit [Ping timeout: 252 seconds] 14:47 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 252 seconds] 14:48 -!- spinza [~spin@196.212.164.26] has quit [Ping timeout: 260 seconds] 14:48 -!- Muis [sid26074@gateway/web/irccloud.com/x-kxizsnswjkwddplc] has quit [Ping timeout: 252 seconds] 14:48 -!- xHire [~xHire@kos.paskuli.cz] has quit [Ping timeout: 252 seconds] 14:48 -!- pindarhk_ [sid105966@gateway/web/irccloud.com/x-ulmouitfuooqhasz] has quit [Ping timeout: 252 seconds] 14:48 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-cslgoczemhnytsvs] has joined #bitcoin-core-dev 14:49 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection] 14:49 -!- pindarhk_ [sid105966@gateway/web/irccloud.com/x-taaylkoxllhcdjnk] has joined #bitcoin-core-dev 14:50 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev 14:50 < luke-jr> promag: no, because it's built on top of 10615 14:50 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Read error: Connection reset by peer] 14:50 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 14:50 < luke-jr> promag: the branch is named multiwallet_gui 14:50 < promag> mind I take a look? 14:51 -!- Muis [sid26074@gateway/web/irccloud.com/x-tuinuehcewytlxgw] has joined #bitcoin-core-dev 14:53 -!- chainhead [~chainhead@108.61.159.53] has joined #bitcoin-core-dev 14:54 < promag> so the concept is to have a combobox to choose the wallet in the mainwindow? 14:54 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev 14:54 < luke-jr> promag: yes, it works pretty well 14:55 < luke-jr> been shipping it in Knots since 0.13 ;) 14:56 < luke-jr> maybe I should open a PR so it at least has that 14:56 < promag> does it restores the current wallet when it starts? 14:56 < luke-jr> promag: no 14:57 < luke-jr> maybe it should 14:57 < promag> yeah, like the geometry stuff 14:57 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Quit: This computer has gone to sleep] 14:59 -!- duringo_ [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 14:59 -!- duringo [~Mutter@192.3.207.58] has quit [Read error: Connection reset by peer] 15:00 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-dukpphxnmnlefytb] has joined #bitcoin-core-dev 15:00 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-wzsgdxpmtlpwiywz] has joined #bitcoin-core-dev 15:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 15:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:07 -!- promag_ [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 15:08 < luke-jr> promag_: not sure it makes sense for the wallet, since presumably you'd be using all the wallets (you don't reposition the GUI geometry normally) 15:09 < bitcoin-git> [bitcoin] luke-jr opened pull request #11383: Basic Multiwallet GUI support (master...multiwallet_gui) https://github.com/bitcoin/bitcoin/pull/11383 15:09 -!- promag_ [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 15:09 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:10 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-core-dev 15:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Client Quit] 15:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:12 < promag> nowadays apps usually restore the state 15:12 < promag> "you continue where you left" 15:12 < promag> tks for the PR 15:13 -!- veleiro [~sleeper@fsf/member/veleiro] has left #bitcoin-core-dev [] 15:13 < promag> we can explore that idea later 15:20 -!- duringo__ [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 15:22 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 15:23 -!- duringo_ [~Mutter@192.3.207.58] has quit [Ping timeout: 240 seconds] 15:42 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 240 seconds] 15:44 -!- duringo___ [~Mutter@192.3.207.58] has joined #bitcoin-core-dev 15:44 -!- duringo___ [~Mutter@192.3.207.58] has quit [Client Quit] 15:47 -!- duringo__ [~Mutter@192.3.207.58] has quit [Ping timeout: 248 seconds] 15:50 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer] 16:03 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 16:12 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 16:31 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 16:33 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 16:34 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 16:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:46 -!- sdfgsdfg [~sdfgsdfg@unaffiliated/sdfgsdfg] has joined #bitcoin-core-dev 16:46 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gnxsyqcgwtsyrkpa] has joined #bitcoin-core-dev 16:46 -!- btcdrak [uid239175@gateway/web/irccloud.com/x-zemvsqxzguhwtrwi] has joined #bitcoin-core-dev 16:49 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 16:50 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 16:55 -!- seone [~seone@unaffiliated/seone] has quit [Quit: seone] 17:09 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 17:11 < gmaxwell> Patches to AFL that let you target specific parts of code, e.g. to fuzz test a patch: https://github.com/aflgo/aflgo 17:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 17:12 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gnxsyqcgwtsyrkpa] has quit [Quit: Connection closed for inactivity] 17:21 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev 17:23 -!- Geoffy [~Geo@178-119-187-213.access.telenet.be] has quit [] 17:32 -!- JackH [~laptop@ip-213-127-56-186.ip.prioritytelecom.net] has quit [Ping timeout: 252 seconds] 17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hnrdqaedovicyimb] has quit [Quit: Connection closed for inactivity] 17:45 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev 17:47 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 17:47 -!- fengling_ [~fengling@2400:8901::f03c:91ff:fe61:b65c] has quit [Ping timeout: 264 seconds] 17:50 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 252 seconds] 17:51 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 260 seconds] 18:00 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:07 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev 18:07 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has joined #bitcoin-core-dev 18:08 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Quit: This computer has gone to sleep] 18:13 -!- fengling_ [~fengling@2400:8901::f03c:91ff:fe61:b65c] has joined #bitcoin-core-dev 18:16 -!- Giszmo [~leo@reverso.156.228.153.190.static.operaciones.gtdinternet.com] has quit [Ping timeout: 240 seconds] 18:17 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 18:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 18:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 18:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 18:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:47 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 18:59 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev 19:15 -!- owowo [ovovo@gateway/vpn/mullvad/x-yupmkteumiajvaxn] has quit [Read error: Connection reset by peer] 19:16 -!- tErik_mc [~tErik@unaffiliated/terik] has joined #bitcoin-core-dev 19:18 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 19:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 19:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 19:53 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-zmhxcaxxjeimnrdm] has joined #bitcoin-core-dev 20:20 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has joined #bitcoin-core-dev 20:21 -!- Miezel [~Miezel@64-83-208-26.static.stcd.mn.charter.com] has quit [Client Quit] 20:49 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 20:50 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 20:59 -!- veleiro [~sleeper@fsf/member/veleiro] has left #bitcoin-core-dev [] 21:03 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #bitcoin-core-dev 21:17 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 21:20 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds] 21:24 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 21:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 21:37 < ossifrage> FYI the twitching "Reindexing blocks on disk..." did not damp out as I made progress, now it is at 76% and twitching between 7 and 30 weeks 21:54 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Read error: Connection reset by peer] 21:54 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Read error: Connection reset by peer] 21:54 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Read error: Connection reset by peer] 21:54 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer] 21:54 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer] 21:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 21:55 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 21:58 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 22:06 -!- harrymm [~harrymm@85.203.47.40] has quit [Ping timeout: 246 seconds] 22:19 -!- harrymm [~harrymm@85.203.47.79] has joined #bitcoin-core-dev 22:28 < bitcoin-git> [bitcoin] Gazer022 opened pull request #11384: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11384 22:29 < bitcoin-git> [bitcoin] Gazer022 closed pull request #11384: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11384 22:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 22:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vtzjkywyzxbosxpa] has joined #bitcoin-core-dev 22:43 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/49f3d57eeb66...6c4fecfaf7be 22:43 < bitcoin-git> bitcoin/master 2a07f87 Dan Raviv: Refactor: Modernize disallowed copy constructors/assignment... 22:43 < bitcoin-git> bitcoin/master 6c4fecf Pieter Wuille: Merge #11351: Refactor: Modernize disallowed copy constructors/assignment... 22:44 < bitcoin-git> [bitcoin] sipa closed pull request #11351: Refactor: Modernize disallowed copy constructors/assignment (master...refactor/modernize-no-copy) https://github.com/bitcoin/bitcoin/pull/11351 22:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 23:03 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] 23:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 23:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 23:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 23:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer] 23:07 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 23:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 23:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 240 seconds] 23:34 -!- lvmbdv [~root@188.226.130.89] has quit [Quit: went to lunch, back in 15 mins] 23:45 < bitcoin-git> [bitcoin] sipa opened pull request #11385: Remove some unused functions and methods (master...201709_misc_cleanups) https://github.com/bitcoin/bitcoin/pull/11385 23:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 23:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 23:54 -!- lvmbdv [~root@188.226.130.89] has joined #bitcoin-core-dev 23:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]