--- Log opened Thu Sep 27 00:00:20 2018
00:02 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
00:34 < jonasschnelli> Bitcoin Qt looks a bit strange in OSX 10.14 (Mojaves) dark mode. :)
00:35 -!- t0adst00l [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has joined #bitcoin-core-dev
00:35 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds]
00:36 -!- prometheus_falli [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has quit [Ping timeout: 256 seconds]
00:45 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
01:12 -!- Krellan [~Krellan@2601:640:4000:9258:1c1:5844:3ef1:ae96] has quit [Remote host closed the connection]
01:12 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has joined #bitcoin-core-dev
01:13 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
01:16 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:25 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
01:37 < wumpus> kallewoof: the lists are generated automatically but always need human editing
01:37 < wumpus> kallewoof: the list of PRs is generated from github API data, the authors list from git commit authors—this might be what causes the divergence in this case
01:38 < wumpus> jonasschnelli: that's curious, I always run it with dark gtk themes and that seems to go well
01:38 < jonasschnelli> wumpus: Could be because of the different platformstyles... investigating now 
01:39 < jonasschnelli> black icons on black background are not ideal.. but at least you can see them
01:39 < jonasschnelli> correction: black icons on dark-gray background
01:40 < wumpus> jonasschnelli: yes that's it, I think on UNIX it does an attempt to grab the icon color from the theme, on MacOS is defaults to black
01:41 < jonasschnelli> jup... 
01:42 < wumpus> kallewoof: that's it; the commits in 9991 are by JeremyRubin and apparently my script lists authors only, not committers
01:43 < wumpus> kallewoof: I'll try to fix the script, otherwise I'll just edit him in manually
01:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Quit: bye]
01:59 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
02:01 < wumpus> kallewoof: added in committers to my list-authors script; looks like Dorier was the only one missed to this
02:04 < wumpus> phantomcircuit: travis does have IPv4, but no IPv6 IIRC
02:04 < wumpus> (*not even localhost*)
02:10 < echeveria> I fixed testnet, for what it's worth. the most work is now in a valid chain.
02:24 -!- hebasto [~hebasto@195.60.70.234] has joined #bitcoin-core-dev
02:28 < jonasschnelli> wumpus: using the dark arc theme in Ubuntu Bionic, the background of Bitcoin Qt is still light gray/whiteish? Is that expected?
02:30 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 240 seconds]
02:32 < wumpus> jonasschnelli: I don't think so; the bitcoin-qt background should be the same as other gtk applications, say "charmap"
02:33 < wumpus> jonasschnelli: though that might only work if you build from source, theme integration is not available with the shipped binaries
02:33 < jonasschnelli> aha... I see.
02:34 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
02:34 < wumpus> (the latter because it's based on plugins, which are not available when building qt statically)
02:35 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:36 < jonasschnelli> wumpus: I would have expected that the OS provides some sort of color scheme for background, etc. (macOS Mojave) handles it that way). Qt could use OsBackgroundColor(), etc. for certain things.
02:36 < wumpus> huh—looks broken on ubuntu 18.04, I get a light grey background now too w/ Adwaita-dark theme
02:36 < wumpus> built against system qt
02:36 < wumpus> AHH when did this happen
02:36 < jonasschnelli> hmm...
02:36 < jonasschnelli> Must be a Qt upstream issue
02:36 < jonasschnelli> (or a flag)
02:37 < wumpus> yes, indeed
02:37 < jonasschnelli> https://askubuntu.com/questions/910012/how-can-i-get-qt5-applications-to-use-the-gtk-theme-in-ubuntu-17-04
02:37 < wumpus> I see the same in Quasselclient
02:37 < wumpus> which is also a qt (5 AFAIK) app
02:37 < jonasschnelli> «The problem has occurred since Qt5.7. In this release, the GTK2 platform theme and style was removed and replaced with the GTK3 platform theme»
02:38 < wumpus> but how! I'm sure my theme also covers gtk3
02:38 < wumpus> 'charmap' is gtk3 and has a dark grey background
02:39  * jonasschnelli loving QT
02:42 -!- t0adst00l [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has quit [Ping timeout: 256 seconds]
02:44 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
02:52 < wumpus> I guess... it is the least of evils, with regard to cross-platform GUIs. Though losing theme integration on by far most linux distributions (except KDE-based ones?) is a pity.
02:56 < wumpus> installing qt5-style-plugins and then doing 'export QT_QPA_PLATFORMTHEME=gtk2' works here, but that's helluva awkward
02:57 < hebasto> wumpus: what is the way to build bitcoin-qt against system qt?
03:06 < wumpus> hebasto: it does that by default if you don't do a depends build
03:06 < wumpus> just follow the steps in build-unix.md
03:09 < wumpus> that way, bitcoin won't magically install its own qt; so it will build against system qt if available, and not build against qt at all if not available
03:12 < wumpus> this is the preferred way, we even used to ship that way for qt4, but unfortunately the range of portability of the executables is much smaller then so it's not an option anymore (then again, nothing of this matters anymore, if qt upstream broke desktop integration...)
03:17 -!- t0adst00l [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has joined #bitcoin-core-dev
03:23 < hebasto> wumpus: thank you
03:28 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has quit [Read error: Connection reset by peer]
03:30 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has joined #bitcoin-core-dev
03:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
03:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
03:57 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
03:57 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:00 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:01 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
04:10 < provoostenator> wumpus: "great" to hear macOS isn't the only platform having QT headaches now.
04:17 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
04:20 -!- Kvaciral [~Kvaciral@5ED6B9A2.cm-7-7c.dynamic.ziggo.nl] has quit [Remote host closed the connection]
04:25 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has quit [Ping timeout: 264 seconds]
04:26 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has joined #bitcoin-core-dev
04:56 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
05:25 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 245 seconds]
05:26 < wumpus> GUIs were a mistake
05:30 < Sentineo> an audio interface would have been betterperhaps :)
05:33 -!- schnerchi [~schnerchi@p54A0EDE7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:41 < wumpus> direct brain interface ftw :)
05:42 < Sentineo> yeah :)
05:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:10 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-jylyzqyvintyjhku] has joined #bitcoin-core-dev
06:22 -!- scroll2 [sid313090@gateway/web/irccloud.com/x-eriuyigddvipdmjj] has joined #bitcoin-core-dev
06:24 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
06:30 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
06:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
06:48 -!- irc_viewer_test1 [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
06:50 < promag> hebasto: hi
06:51 < hebasto> promag: hi
06:51 < promag> hebasto: I don't have space to install fedora :/ but I hope to get around that today/tomorrow
06:51 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Ping timeout: 264 seconds]
06:51 < hebasto> promag: I see
06:51 < promag> hebasto: can only test by then
06:53 < hebasto> promag: don't be hurry, I'm working on your suggestions right now
06:53 < promag> so in fact it's necessary to not map?
06:54 < hebasto> yes, it is. I've tested on fedora.
07:00 < hebasto> promag: would you mind to look into #14222?
07:00 < gribble> https://github.com/bitcoin/bitcoin/issues/14222 | Qt: Fix restoration of minimized to tray window by hebasto · Pull Request #14222 · bitcoin/bitcoin · GitHub
07:01 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
07:04 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
07:16 < promag> hebasto: will fo
07:16 < promag> *do
07:28 -!- profmac [~ProfMac@2001:470:1f0f:226:653f:f07b:7c00:cc3] has joined #bitcoin-core-dev
07:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
07:37 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
07:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
07:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:50 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
07:55 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 252 seconds]
08:01 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
08:02 -!- irc_viewer_test1 [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test1]
08:16 -!- jarthur [~jarthur@rrcs-98-101-134-18.midsouth.biz.rr.com] has joined #bitcoin-core-dev
08:24 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
08:28 -!- TheCharlatan [~TheCharla@109.236.87.57] has joined #bitcoin-core-dev
08:34 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
08:39 -!- Victor_sueca is now known as Victorsueca
08:40 -!- emilengler [~Emil@ip4d145229.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
08:43 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
09:09 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has quit [Read error: Connection reset by peer]
09:10 -!- emilengler [~Emil@ip4d145229.dynamic.kabel-deutschland.de] has quit [Quit: Leaving]
09:10 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has joined #bitcoin-core-dev
09:12 -!- emilengler [~Emil@ip4d145229.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
09:13 -!- emilengler [~Emil@ip4d145229.dynamic.kabel-deutschland.de] has quit [Client Quit]
09:19 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-dev
09:28 < luke-jr> 57b59260952742aa51dca79a37849429a456496292d3e4f28cdf7de3eef516f3
09:29 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has quit [Ping timeout: 252 seconds]
09:32 -!- jarthur [~jarthur@rrcs-98-101-134-18.midsouth.biz.rr.com] has quit [Remote host closed the connection]
09:32 -!- promag [~promag@83.223.234.29] has joined #bitcoin-core-dev
09:34 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has joined #bitcoin-core-dev
09:36 -!- jarthur [~jarthur@rrcs-98-101-134-18.midsouth.biz.rr.com] has joined #bitcoin-core-dev
09:40 < promag> luke-jr: heh
09:54 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection]
09:55 -!- rex4539 [~rex4539@ppp-2-84-165-183.home.otenet.gr] has quit [Quit: rex4539]
09:58 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
10:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 245 seconds]
10:14 -!- promag [~promag@83.223.234.29] has quit [Remote host closed the connection]
10:42 -!- t0adst00l [~sluggo@gateway/tor-sasl/prometheusfalli/x-99064168] has quit [Ping timeout: 256 seconds]
10:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
10:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
10:54 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has left #bitcoin-core-dev ["ERC (IRC client for Emacs 26.1)"]
11:15 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
11:19 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
11:24 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
11:28 -!- Krellan [~Krellan@2601:640:4000:9258:1913:ff55:eee3:fdcd] has quit [Remote host closed the connection]
11:48 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
11:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
11:55 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev
12:00 < wumpus> meeting time?
12:00 < jonasschnelli> hiyes
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Sep 27 19:00:52 2018 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:01 < promag> hi
12:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircu
12:01 < provoostenator> hi
12:01 < wumpus> it codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
12:01 < cfields> hi
12:01 < achow101> hi
12:02 < meshcollider> Hi
12:02 < jonasschnelli> Status of 0.15.2 and 0.14.3?
12:02 < phantomcircuit> hi
12:03 < wumpus> jonasschnelli: good question; are there enough gitian sigs to upload binaries?
12:03 < jonasschnelli> I think so... 5 or 6
12:03 < luke-jr> yeah
12:04 < jamesob> hi
12:04 < achow101> 0.14.3 has 6, 0.15.2 has 5
12:04 < jonasschnelli> 6 for 0.14.3 and 5 for 0.15.2 AFAIK
12:04 < wumpus> ok, will do that then, I'm back from Riga so I'm able to sign/upload binaries again
12:04 < jonasschnelli> due to my shitty setup, I can't compile trusty stuff on Gitian anymore
12:04 < jonasschnelli> thanks wumpus 
12:05 < wumpus> 0.14/0.15 build still seems to work here
12:05 < provoostenator> It took some pain for me as well, but I still keep an old Gitian VM for backports.
12:05 < wumpus> #topic 0.17.0 release
12:06 < jonasschnelli> Not sure if #14339 is something we want to address for 0.17... probably not
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/14339 | Qt 0.17.0rc4 (and master) not running on Ubuntu 14.04.5 LTS · Issue #14339 · bitcoin/bitcoin · GitHub
12:06 < provoostenator> So macOS GUI compilation seems completely broken: #14327, but that wouldn't stop cross compling a release I suppose.
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/14327 | macOS Mojave QT 5.11 compilation fails · Issue #14327 · bitcoin/bitcoin · GitHub
12:06 < wumpus> so the blocker for 0.17 is #14289
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
12:07 < wumpus> the GUI problems are annoying and need to be fixed but are not blocking the release at this stage, IMO
12:07 < instagibbs> hi
12:07 < jonasschnelli> provoostenator: hmm.. compiled master yesterday on a fresh Mojave installation
12:07 < jonasschnelli> (no problems)
12:07 < jonasschnelli> wumpus: agree
12:08 < provoostenator> jonasschnelli: ok, maybe it's machine specific? Can you and others comment on that issue?
12:08 < jonasschnelli> (will do later)
12:09 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has joined #bitcoin-core-dev
12:09 < provoostenator> (I'm trying now on my Macbook as well, maybe it's just my iMac being a pain)
12:09 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:09 < jonasschnelli> What about #14289 and #14104?
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14104 | 0.17.2rc issue (standardness change for bare multisig) · Issue #14104 · bitcoin/bitcoin · GitHub
12:09 < wumpus> although, it's likely that #14289 is not a regression for 0.17 it's still something that needs to be addressed in some way
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
12:10 < wumpus> jonasschnelli: I don't think #14104 is a blocker, but the other one is nasty
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/14104 | 0.17.2rc issue (standardness change for bare multisig) · Issue #14104 · bitcoin/bitcoin · GitHub
12:10 < provoostenator> 14289: one "solution" could be to recommend people to resync if they're still on v0.13, since it's impractically slow anyway even without the memory problem.
12:10 < jonasschnelli> We just need to make sure to communicate the standardness change in 0.17.0
12:10 < provoostenator> Or they can install 0.15 first, wait for that process to finish and then install 0.17
12:11 < jonasschnelli> meh
12:11 < sipa> hi, i'm sortof here - ping me if needed
12:11 < wumpus> provoostenator: agree; though putting a message in the code itself if people are upgrading from 0.13.0 would make sense, for those not carefully reading the release notes, but anyhow
12:11 < gmaxwell> I think even though 0.16 appears to have added the replay bloat, 0.17 makes bloat worse because it adds an additional place where they're queued.  (this doesn't change that I think notices are probably the best move for now)
12:12 < wumpus> but yes for the most common case (0.13.0 upgrade rollback), adding a message to the release notes would be acceptable solution
12:12 < luke-jr> couldn't we detect the reorg needed, and just prompt for user action instead of trying to upgrade it?
12:12 < provoostenator> If it can be done safely, having the upgrade simply refuse and throw an error message seems safer than just a release note.
12:12 < sipa> gmaxwell: i'm not sure anything was added in 0.17
12:12 < sipa> i blamed the txindex change, but the asynchronous processing was added earlier
12:12 < wumpus> so I guess there isn't really a hurry to release 0.17.0 at this point
12:12 < gmaxwell> sipa: txindex also schedulers queues block connections and disconnection, no?
12:13 < gmaxwell> regardless... We don't yet have a proper fix for the issue, and I don't think we're still learning much about 0.17rc.
12:13 < sipa> gmaxwell: i think (sorry no time to look now) is that 0.17 just added the txindex as a listener for those blockconnected events; the issue is not that, but the events in the first place
12:14 < gmaxwell> ah.
12:14 < sipa> my suggestion is to just point out in release notes that upgrading from 0.13.0 or before is a known memory bloat issue, which can be worked around with -reindex
12:14 < gmaxwell> I didn't walk through the patches so it wasn't clear to me that the events existed before. Got it.
12:14 < luke-jr> (ActivateBestChain actually checks for the queue length and blocks on it getting caught up)
12:14 < sipa> luke-jr: it does; but RewindBlock and InvalidateBlock don't
12:15 < luke-jr> sipa: would it be so bad if they did?
12:15 < sipa> luke-jr: they need to release cs_main for that, which would be a major refactor for those functions
12:15 < gmaxwell> luke-jr: that can be tricky to do safely as car has to be taken to make sure they don't wait while holding any locks.
12:15 < gmaxwell> care*
12:15 < luke-jr> hmm
12:15 < sipa> but we can probably remove the upgrading logic from pre-segwit blocks anyway - as provoostenator says, it's already pretty unwieldy even without the memory bloat issue
12:16 < gmaxwell> yea, reindex might already actually be faster.
12:16 < sipa> i'm pretty sure it is
12:16 < gmaxwell> but I assumed we'd want to use the rewind for future softforks.
12:16 < provoostenator> Does reindex just toss out block files it doesn't need?
12:16 < sipa> i don't care so much that invalidateblock takes a lot of memory - it would be a nice to have if we could actually make it revert to genesis, but it's not a priority
12:16 < sipa> provoostenator: yes
12:16 < gmaxwell> sipa: uh it's a little worse than that.
12:17 < gmaxwell> I mean it hits 64+GB usage rewinding only a couple months of blocks.
12:17 < sipa> yeah, ok
12:17 < provoostenator> And it doesn't stop once it's going.
12:18 < gmaxwell> indeed, and it doesn't return the memory, ever. 
12:18 < sipa> we'll need to refactor InvalidateBlock to deal with that; doesn't sound impossible, but probably for 0.17.1?
12:18 < gmaxwell> Not a reason to hold 0.17, but it's not an irrelevant inefficiency.
12:18 < sipa> fair
12:18 < gmaxwell> sipa: sounds fine to me.
12:18 < luke-jr> <2% of the network (<2000 nodes) run non-segwit software at this point; throwing an error that we can't upgrade them anymore seems reasonable
12:19 < wumpus> yes
12:19 < sipa> luke-jr: that's a useful statistics
12:19 < gmaxwell> I still think we shouldn't just can the rewinding code though.
12:19 < provoostenator> Maybe also throw an error if the user tries to invalidate more than 10K blocks? They can always do it in increments.
12:20 < gmaxwell> ugh.
12:20 < gmaxwell> just release note it, then we'll fix it later, please don't add additional falure cases to the function.
12:20 < wumpus> agree with gmaxwell 
12:20 < wumpus> please don't overdesign temporary code
12:20 < sipa> the refactor will effectively just do that - split it up in batches of X blocks to disconnect at once
12:21 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
12:21 < wumpus> this needs to be fixed properly, in master, and in the future we should be careful to review anything that adds a queue or global data structure for this possiblity
12:21 < sipa> agree
12:21 < wumpus> but don't spend too much time on the workaround
12:21 < provoostenator> I guess anyone upgrading all the way from 0.13  will probably pay more than average attention to the Upgrade Notice section in bold at the top...
12:22 < wumpus> I think most people still running 0.13.x do so intentionally, and won't be upgrading to 0.17.x any time soon
12:22 < wumpus> (not those nodes, at least!)
12:22 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
12:22 < luke-jr> most 0.13 nodes are 0.13.2 anyway
12:23 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-jylyzqyvintyjhku] has quit [Quit: Connection closed for inactivity]
12:23 < sipa> yes; 0.13 is not the issue; 0.13.0 is
12:23 < luke-jr> sipa: https://luke.dashjr.org/programs/bitcoin/files/charts/services.html fwiw
12:23 < wumpus> e.g. some users want to run old node software to cross-validate
12:25 < wumpus> so: for 0.17.0, we should add a mention to the release notes for users upgrading from 0.13.0. This would require no new rc, so the way to final can continue as normal.
12:25 < achow101> there's a pr for backports, will that be fore 0.17.1, or are those going in for .0?
12:26 < wumpus> I haven't seen it, but unless they solve critical problems, they are not going in .0
12:26 < achow101> #14328
12:26 < gribble> https://github.com/bitcoin/bitcoin/issues/14328 | [0.17] Backports by MarcoFalke · Pull Request #14328 · bitcoin/bitcoin · GitHub
12:27 < wumpus> I don't think any of those are very serious
12:27 < wumpus> potential unititialized value sounds dangerous, but looking at the PR, it's impossible to trigger in practice
12:28 < wumpus> I hate that kind of PR naming
12:28 < provoostenator> PR bait? :-)
12:28 < gmaxwell> I've complained about that a number of times in the past.
12:28 < wumpus> me too, so many times, the guy doesn't listen to me
12:29 < achow101> so does that mean 0.17.0 final after the meeting?
12:29 < wumpus> (or gal, I don't really know)
12:29 < provoostenator> Works for me.
12:29 < wumpus> I guess so? would be nice to have the release notes change in
12:29 < wumpus> before tagging
12:31 < gmaxwell> just needs a one liner, no?  "If upgrading from 0.13 or prior, you must start with -reindex"
12:31 < sipa> yah
12:31 < wumpus> I've noted it here https://github.com/bitcoin/bitcoin/issues/12391#issuecomment-425211080
12:32 < gmaxwell> k
12:32 < achow101> we also need to add a known issues section
12:33 < wumpus> yepp
12:33 < wumpus> any other topics?
12:33 < phantomcircuit> can anybody reproduce the travis error on #14336
12:33 < gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
12:34 < phantomcircuit> i cannot reproduce it locally
12:34 < wumpus> #topic Travis error on poll() PR
12:34 -!- jarthur [~jarthur@rrcs-98-101-134-18.midsouth.biz.rr.com] has quit []
12:34 < jonasschnelli> IMO after the meeting
12:34 < wumpus> I guess this is a action item, that people shoudl try the PR locally?
12:34 < gmaxwell> instagibbs had a related question, where are the bitcoind exit codes coming from.  phantomcircuit's travis failure bitcoind has a return value of -6
12:35 < wumpus> after the meeting, yes, doesn't make sense to do a real-time debugging session I think :)
12:35 < instagibbs> I shall wait
12:35 < jonasschnelli> would be fun... but yes. Better later.
12:35 < promag> wumpus: topic suggestion: multiwallet
12:35 < wumpus> #action try to run tests on #14336 on different environments to see if it reproduces travis error
12:35 < jonasschnelli> High-Prio list?
12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/14336 | net: implement poll by pstratem · Pull Request #14336 · bitcoin/bitcoin · GitHub
12:36 < wumpus> #topic multiwallet (promag)
12:36 < promag> cc jnewbery
12:36 < promag> just want some feedback regarding https://github.com/bitcoin/bitcoin/pull/13100#issuecomment-424342813
12:36 < promag> also, regarding listwalletdir
12:36 < wumpus> jonasschnelli: I haven't paid attention to the high-prio list at all this week, with the CVE issue and Riga travel so I'm not sure there's much to do there, but sure we can discuss it
12:37 < jonasschnelli> I think Concept ack on both (promag)! Will test more soon.
12:37 < promag> and I'm going to submit a refactor PR introducing WalletsModel
12:37 < promag> that combines loaded wallets and existing wallets
12:37 < jonasschnelli> wumpus: Yeah. I only wanted to ask for a review on #14046 from gmaxwell and sipa since they both commented already on it (fixed stuff)
12:37 < gribble> https://github.com/bitcoin/bitcoin/issues/14046 | net: Refactor message parsing (CNetMessage), adds flexibility by jonasschnelli · Pull Request #14046 · bitcoin/bitcoin · GitHub
12:38 < promag> otherwise #13100 looks like junk code..
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
12:39 < promag> any objections to WalletsModel? IIRC it was previously suggested
12:40 < gmaxwell> I'll look at 14046 again, thanks for the ping.
12:42 < jonasschnelli> topic proposal: factor out berkeley-db
12:43 < wumpus> #topic factor out berekey-db
12:43 < wumpus> (jonasschnelli)
12:43 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
12:43 < jonasschnelli> I tried this serval times but seems more complex then initially though..
12:43 < jonasschnelli> But I think we should slowly consider alternative database systems (internal) for wallet files
12:43 < jonasschnelli> And factroing out BDB should be done sooner then later
12:43 < jamesob> where did the complexity come from?
12:44 < provoostenator> Could be combined with  jnewbery's standalone wallet tool, which can hold  on to the direct dependnecy a bit longer.
12:44 < jonasschnelli> jamesob: I think mostly due to the complex code layering...
12:44 < jonasschnelli> I think switching the database backend on runtime should be possible....
12:45 < promag> switching the database backend on runtime should be possible <- why?
12:45 < jonasschnelli> I hope someone working on the wallet can initiate that refactor: jamesob, jnewbery, ryanofsky 
12:45 < provoostenator> I assume it makes most sense to move it to leveldb since we're using that for most other things?
12:45 < sipa> leveldb is very annoying
12:45 < gmaxwell> what gah no
12:45 < jamesob> I don't think so; leveldb can't use a single .dat-ish file
12:45 < jonasschnelli> promag: we must assume there will be a pretty long "transition" phase from the old to the new database layer
12:45 < jonasschnelli> Not leveldb...
12:45 < sipa> it needs whole directories, and provides way too many features
12:45 < gmaxwell> and not a particularly good fit for what its used for here.
12:45 < jonasschnelli> sipa one wrote a simple append only database... 
12:46 < jamesob> sqlite IMO seems like a good bet
12:46 < gmaxwell> jonasschnelli: do we need to assume there is a long transistion instead of a standalone conversion util?
12:46 < wumpus> yeah, though FWIW for the berkekeydb we also suggest a whole directory per wallet at the moment
12:46 < jonasschnelli> (logdb),... there is a 2-4 year old PR somewhere (search after logdb)
12:46 < sipa> sqlite is fine, though we also don't need any of its features, apart from safe updating
12:46 < gmaxwell> wumpus: yes, but we know we don't like to do that. :)
12:46 < jamesob> or honestly just a raw format of our own creation
12:46 < wumpus> but the dangerous thing here is that anything you choose for the wallet will need to be supported more or less forever, so it's not an easy choice
12:46 < jonasschnelli> gmaxwell: could also be a conversion utility,.. but at least the utility must be capable to run both database systems,... so won't change that much for the refactroing)
12:46 < provoostenator> If we add another dependency, maybe pick one that's potentially useful for block and index storage?
12:46 < gmaxwell> esp since we just end up loading the whole thing into memory, a fancy database is kinda overkill.
12:47 < jonasschnelli> gmaxwell: agree
12:47 < sipa> provoostenator: those things actually need efficient querying, atomic batch updates, ...
12:47 < wumpus> we don't *need* to load the whole thing in memroy, that's a current design choice
12:47 < sipa> provoostenator: for the wallet we just need a key-value store with some append only records :)
12:47 < gmaxwell> (and also makes the files much more fragile and harder to work with than they would be otherwise)
12:47 < cfields> sqlite is also nice in that they provide a monolithic source file and encourage direct integration.
12:47 < wumpus> if there's proper indexing, loading every single transaction into memory could be avoided
12:47 < sipa> yeah, i'm not opposed to sqlite
12:47 < jonasschnelli> logdb (#5686) would be a simple append only hard to corrupt "database"... everything is hold in memory
12:47 < gribble> https://github.com/bitcoin/bitcoin/issues/5686 | [Wallet] replace BDB with internal append only (logdb) backend by jonasschnelli · Pull Request #5686 · bitcoin/bitcoin · GitHub
12:47 < sipa> it has very thorough tests
12:48 < luke-jr> cfields: that's not a good thing. -.-
12:48 < provoostenator> Someone once complained that the wallet didn't have atomicity guarantees.
12:48 < gmaxwell> wumpus: indeed. but that decision should be made jointly.
12:48 < jonasschnelli> Or sqlite... yeah
12:48 < wumpus> I like sqlite, especially with deterministic wallets it wouldn't need to store all the keys
12:48 < jamesob> sqlite seems like a pretty safe bet
12:48 < cfields> luke-jr: the alternative is the reason we're switching away...
12:48 < wumpus> so it's pretty much a metadata database, and sqlite is great for metadata and querying metadata
12:48 < sipa> wumpus: with descriptor based wallets we don't need that anyway :)
12:48 < luke-jr> cfields: what?
12:48 < wumpus> sipa: even beter
12:48 < gmaxwell> I don't think sqlite makes much sense unless the intent is also to move away from pulling everything into memory.
12:48 < jonasschnelli> Is it guaranteed that sqlite databases are interoperatable between platforms and versions of sqlite?
12:48 < jamesob> gmaxwell: what would you propose in lieu?
12:49 < wumpus> please move away from loading everyting into memory in the long run
12:49 < gmaxwell> And if we're going to do that, the scheme in the database matters a lot, so that change should probably be made at the same time.
12:49 < wumpus> on the short term it's not a priority
12:49 < wumpus> but don't make it impossible
12:49 < wumpus> (in a new format)
12:49 < gmaxwell> jamesob: if we're loading the whole thing into memory, a simple serialized format like logdb is I think vastly superior.
12:49 < jonasschnelli> I agree with gmaxwell: sqlite makes most sense if we want to one active handling of merchant size wallets
12:49 < jonasschnelli> and not sure if we want that
12:49 < promag> does it have to be an embedded database?
12:49 < wumpus> some large users of the wallet run into memory issues, and have to remake a new wallet perioidically because of this limitation
12:50 < sipa> promag: no
12:50 < gmaxwell> if we just use sqllite but then just treat it like a blob holder, then the whole schema will need to change to avoid memory loading it in any case. 
12:50 < phantomcircuit> jonasschnelli, think it makes most sense to have a tool which is a separate binary to convert from bdb to "new" wallet format
12:50 < jonasschnelli> I don't think it has to be a "database" at all
12:50 < wumpus> (due to storing all the transactions in memory, and also the time overhead of loading the whopping thing at startup)
12:50 < instagibbs> wumpus, or abusing rpc calls to whiddle it down
12:50 < phantomcircuit> and for the new wallet format to simply be a flat file
12:50 < wumpus> instagibbs: oh :-)
12:50 < jonasschnelli> phantomcircuit: I agree. But that tools would require the refactoring also
12:50 < cfields> luke-jr: eh, not worth getting into it and muddying the conversation
12:50 < wumpus> instagibbs: I mean, :-(
12:50 < gmaxwell> wumpus: More than memory issues, they run into problems that many of our rpc operations iterate over all txn in the wallet and then become super slow.
12:50 < instagibbs> gmaxwell, yeah that one
12:51 < phantomcircuit> jonasschnelli, yes but has the advantage that you can write the conversion tool and then just rip out a ton of the walletdb logic entirely
12:51 < wumpus> gmaxwell: right - another lmitation of not having indexing, either in memory or on disk
12:51 < instagibbs> i know people who delete completely spent tx(plus 100 confs or something) to speed it wallets
12:51 < phantomcircuit> which makes refactoring much easier, cause you dont have to support both simultaneously
12:51 < jonasschnelli> phantomcircuit: the logic must still be available somewhere,... could be in a tool source only. yeah
12:51 < phantomcircuit> cfields, sqlite doesn't actually provide a monolithic file in the same way bdb doesn't
12:51 < wumpus> instagibbs: ah yes, the "wallet only needs a view of current utxos, not all of history" view
12:52 < gmaxwell> "pruned wallet"
12:52 < instagibbs> wumpus, either that or listunspent takes forever :(
12:52 < cfields> phantomcircuit: eh? They for sure used to.
12:52 < phantomcircuit> to operate in the fast safe mode it needs a separate write ahead log file
12:52 < wumpus> gmaxwell: right
12:52 < luke-jr> well, at least we don't need to keep the history in memory
12:52 < wumpus> luke-jr: indeed
12:52 < cfields> phantomcircuit: oh, I was talking about source file, not the database format.
12:52 < phantomcircuit> cfields, you cant have a single file but it's amazingly slow
12:52 < phantomcircuit> oh
12:52 < phantomcircuit> yes it does have that but like
12:52 < phantomcircuit> meh
12:52 < wumpus> that's where something like sqlite would be, more or less, useful, I like how clightning uses it
12:52 < gmaxwell> going back to the prior point. ... if the history isn't in memory, then the database storing the wallet needs to be structured in a way that suports that
12:53 < cfields> phantomcircuit: that makes integration into our build a no-brainer. That's a signifacant feature imo.
12:53 < phantomcircuit> gmaxwell, and needs to be quite fast actually
12:54 < wumpus> integrating sqlite into a project is trivial, indeed can be done as a single .cpp file if that's desirable
12:54 < jamesob> if we're thinking longterm (esp. about not loading everything into memory simultaneously), I think it makes sense to come up with a normalized, relational schema for the wallet and use sqlite. shouldn't be hard to come up with something non-controversial (famous last words)
12:54 < promag> any reason to not consider postgres for instance?
12:54 < wumpus> AHHHH
12:54 < sipa> gmaxwell: i don't think the choice of container format and the choice of database layout need to be made at the same time
12:54 < sipa> promag: god why
12:54 < jamesob> wat
12:54 < luke-jr> promag: uh, lots?
12:55 < jonasschnelli> Oracle?
12:55 < cfields> haha
12:55 < wumpus> jonasschnelli: :-) <3
12:55 < sipa> Oracle BDB?
12:55 < promag> luke-jr: name one
12:55 < jonasschnelli> I think however we proceed (sqlite, logdb, etc.), factoring out BDB in a nice layered way will be require (even helps if we keep BDB forever)
12:55 < luke-jr> I mean, if we're using sqlite, the queries could be compatible with multiple backends, but expecting regular users to set up Postgres is crazy..
12:55 < jonasschnelli> I hope someone picks that up
12:55 < sipa> promag: let's do that outside this meeting
12:55 < cfields> this might work better in terms of concrete proposals rather than rounds of "how about xyz?"
12:55 < jonasschnelli> Also BDB is a compile pitfall
12:55 < promag> sure
12:56 < wumpus> cfields: good point
12:56 < wumpus> 'what about mongodb?' :')
12:56 < wumpus> any other topics? 4 minutes left
12:56 < cfields> haha
12:57 < provoostenator> We should just store it on a blockchain.
12:57 < luke-jr> provoostenator: it would be nice if it was possible to commit to it in such a way
12:57 < luke-jr> eg, if you could get a historical hash of the wallet state for commitments
12:57 < wumpus> luke-jr: right, optional support for a large-scale DBM like postgres would be useful for really big users, but that's really a long term goal I suppose, if at all
12:57 < gmaxwell> I'd prefer it if just ban anyone that ever directly uses the name of any database system from the channel.
12:58 < jonasschnelli> but leveldb!
12:58 < wumpus> except oracle, of course *ducks*
12:58 < gmaxwell> sipa: "container" is basically my point, if we're just using it as a "container" a simple log would be a lot better.
12:58 < jonasschnelli> heh
12:58 < wumpus> #endmeering
12:58 < wumpus> #endmeeting
12:58 < lightningbot> Meeting ended Thu Sep 27 19:58:55 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:58 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-27-19.00.html
12:58 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-27-19.00.txt
12:58 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-27-19.00.log.html
12:58 < sipa> gmaxwell: yes, but sqlite is essentially two layers; a well-tested safe updatable blob storing mechanism, and then a database layer on top
12:58 < gmaxwell> sipa: if you just dump transactions/keys into a container and then have to load them into memory and index them thats fine.. if you want to avoid having to do that, you can't just use the storage as a container, it needs to be used as a database.
12:59 < jonasschnelli> The append-only easyness got a bit lost since we added abandontransaction
12:59 < wumpus> jonasschnelli: yes
12:59 < jonasschnelli> Its still possible but comes at high disk-mem cost
12:59 < gmaxwell> jonasschnelli: why?
12:59 < promag> gmaxwell: how about aws s3? o/
12:59 < gmaxwell> jonasschnelli: abandon transaction just logs the txn as abandoned.
12:59 < luke-jr> ^
12:59 < sipa> gmaxwell: by switching to sqlite as a container and only using the low level format, you get pretty much what we need (apart from the extra code for the database stuff), but you also get the ability to later switch the db schema
12:59 < gmaxwell> So we could start using sqllite as a container, but then later actually have a schema, thats a thing that could be done, but really its just two incompatible wallet formats.
13:00 < jamesob> ripping out bdb in favor of sqlite sounds fun... I might take a crack if no one gets around to it in the next few months. sounds like a good christmas break project :)
13:00 < promag> gmaxwell: and support log compaction?
13:00 < jonasschnelli> gmaxwell: yeah.. but if you abandon a 10k bytes transaction you have 10k unused bytes (where only 32bytes change)
13:00 < gmaxwell> promag: why would that be needed?
13:00 < jonasschnelli> log compactation is of course possible
13:00 < wumpus> jamesob: it's not too hard to replace the database, I replaced berkeleydb with leveldb once in a day or so
13:00 < gmaxwell> jonasschnelli: yes so? no one cares about 10k extra data in their wallet, if they did any of these database based solutions would be unacceptable from the getgo as they're all fairly space inefficent.
13:00 < phantomcircuit> jonasschnelli, nobody is using abandon transaction because of 10kb of disk space being used lol
13:00 < wumpus> jamesob: (that's in a very naive way, though, proper schemas will be more work)
13:00 < sipa> i don't see how abandomtransaction changed anything more than a transaction confirming does
13:01 < jamesob> wumpus: what's the tricky part? providing a migration path?
13:01 < sipa> it's just an update "this tx is now abandoned"
13:01 < instagibbs> so, what does exit status "1" mean in the functional test suite, when shutting down a node?
13:01 < jonasschnelli> wumpus, jamesob: I think the hard part of the refactoring is to make two database work (which is ultimatively required for a conversion tool)
13:01 < promag> why not? for systems that use bitcoin wallet in a couple of months it can be pretty large
13:01 < sipa> jonasschnelli: i think that's the easiest part
13:01 < phantomcircuit> what does -6 mean?
13:01 < wumpus> jamesob: the "don't load everything into memory and use proper indexes" part, and yes ,migration is also an issue
13:01 < sipa> jonasschnelli: agreeing on a new database schema will be impossible, however :)
13:01 < achow101> instagibbs: 1 is EXIT_FAILURE
13:01 < achow101> phantomcircuit: where do you get -6?
13:01 < luke-jr> append a "drop the tx" command, and punch a hole where the original data was
13:01 < jonasschnelli> gmaxwell: Yes. I just meant the easyness (or the effectiviness) got a bit lost with state changes on transactions like abandontx
13:01 < phantomcircuit> jonasschnelli, that is for sure the principle issue, supporting two formats at the same time is difficult
13:02 < sipa> jonasschnelli: i really don't see where that comes from
13:02 < luke-jr> then it can be saved append-only in backups, and also frees the disk space (potentially)
13:02 < sipa> jonasschnelli: a tx confirming is equally a state change
13:02 < instagibbs> achow101, ah ok, i shall hunt for this error
13:02 < gmaxwell> sipa: in any case, my point is that just swapping the backing store doesn't seem to produce any real benefit, but it creates incompatiblity. I might be missing it, but it sounds like replacing a black box with a more trendy black box.  Actually making use of it to to keep stuff out of memory would potentially be a big gain, but that isn't the discussion, and if it were done would create 
13:02 < gmaxwell> effectively another new wallet format.
13:02 < phantomcircuit> achow101, https://travis-ci.org/bitcoin/bitcoin/jobs/433891452
13:02 < phantomcircuit> test_framework.test_node.FailedToStartError: [node 0] bitcoind exited with status -6 during initialization
13:02 < jamesob> wumpus: as you say earlier, though, we can gradually build in better use of the database; I think it'd be nice just to shed the bdb dependency asap
13:02 < wumpus> luke-jr: fallocate(FALLOC_FL_PUNCH_HOLE, ...)?
13:02 < phantomcircuit> have literally no idea what would cause that
13:03 < sipa> gmaxwell: well the low-level part of sqlite looks like a well-tested implementation of what we'd want actually
13:03 < gmaxwell> jonasschnelli: I'm still not seeing it, we always made changes to tx.. adding labels, or as sipa notes, confirming them.. spending their outputs, etc.
13:03 < sipa> gmaxwell: of course, needs investigation
13:03 < luke-jr> wumpus: I don't have the exact APIs memorised, but probably something like that
13:03 < luke-jr> wumpus: so long as the loader ignores null bytes, it should be fairly trivial
13:04 < wumpus> luke-jr: I remembered because it sounds so senselessly aggressive, it replaces a page in a file with a hole (all-zeros) page
13:04 < luke-jr> and frees the space used by it
13:04 < jonasschnelli> gmaxwell: I think confirmation is stateless from the wallet perspective (only in conjunction with the blockchain/header state)... but yes. Its non crucial.
13:04 < luke-jr> aggressive in what sense?
13:05 < gmaxwell> does windows do sparse files?
13:05 < wumpus> luke-jr: I mean, as in violent
13:05 < luke-jr> gmaxwell: yes, but not sure if it has an easy punch-hole
13:05 < sipa> jonasschnelli: ... no, we add the block hash that contains the tx to the CWalletTx record
13:06 < wumpus> gmaxwell: modern versions of windows do
13:06 < achow101> phantomcircuit: I think maybe that's a SIGABRT
13:06 < jonasschnelli> uh. yes. Right. There is then at least one update from mempool to in-block,... right (and eventually some reorg writes)
13:06 < luke-jr> we don't support versions that don't I think :p
13:08 < wumpus> so does MacOS support sparse files?
13:08 < gmaxwell> achow101: how would sigabrt show up that way? signals are normally very high exit codes
13:08 -!- ott0disk [~smuxi@cb.85.7a9f.ip4.static.sl-reverse.com] has joined #bitcoin-core-dev
13:08 < sipa> promag: short answer to why not postgres; we don't need a multi-user networked database, and we don't need sql
13:08 < sipa> we need a file on disk
13:08 < sipa> that's safe to interact with and move around
13:09 < wumpus> requireing postgres would be really evil, though not as evil as requiring oracledb
13:10 < wumpus> besides being unnecessary it has lots of extra setup steps to get started in the first place
13:10 < achow101> gmaxwell: exit codes are signed, so anything above 128 would be negative, right?
13:10 < gmaxwell> exit codes are a char?
13:10 < sipa> i think so yes
13:10 < wumpus> on most UNIX, yes
13:10 < gmaxwell> ha, if I knew that it was long since lost!
13:11 < provoostenator> There are of course some other cryptocurrency projects dealing with lots of I/O. Anything useful we can use e.g. from libbitcoin, or LMDB that Monero uses?
13:11 < gmaxwell> okay well SIGABRT would mean he was hitting an assertion most likely.
13:11 < wumpus> and negative values are generally only used when the process was killed with a signal
13:11 < provoostenator> (not that the wallet is I/O heavy, so maybe that's not the thing to worry about)
13:11 < gmaxwell> provoostenator: I have detected you mentioned a database. You are a bad person
13:11 < jamesob> would it be an acceptable user experience for us to completely strip bdb out in some major release, provide an upgrade tool, and throw an error if users try to start bitcoin with bdb-format wallets?
13:11 < gmaxwell> jamesob: I had assumed that we would eventually do exactly that.
13:12 < wumpus> provoostenator: monero doesn't use LMDB for the wallet ,as far as I know, only for the block chain
13:12 < sipa> provoostenator: we are not talking about a database. we're talking about the wallet
13:12 < achow101> gmaxwell: according to http://tldp.org/LDP/abs/html/exitcodes.html, the exit codes are 128 + n where n is the signal number
13:12 < wumpus> monero has some really simple format for the "simplewallet" IIRC
13:12 < achow101> so I think that means -6 becomes just signal number 6, which is sigabrt
13:12 < wumpus> achow101: yes
13:12 < sipa> provoostenator: there are very different trade-offs relevant if we're talking about the UTXO set etc, but that's not the topic now
13:12 < jamesob> gmaxwell: makes sense - didn't know if anyone was intent on having some kind of runtime migration
13:13 < promag> sipa: I understand, just playing devil's advocate
13:13 < provoostenator> I just think it's suboptimal to pull in a whole new dependency _only_ for the wallet.
13:14 < provoostenator> So might as well think ahead a bit, unless we're sure we never want to move away from leveldb for everything else.
13:14 < gmaxwell> have you all considered rewritting the software in javascript? it has webscale. it's very popular now, I hear nodecoin uses it.
13:14 < gmaxwell> provoostenator: the wallets needs are almost but not entirely unlike the needs of the system state.
13:15 < gmaxwell> It's basically an entirely different task, with very different requirements.
13:15 < wumpus> yes
13:15 < wumpus> and sqlite would be a trivial dependency at least
13:16 < gmaxwell> (as an aside, people have also tested lmdb and sqllite for what we use leveldb fore. lmdb seemed to be about the same or slightly worse, depending on hardware in use... and the report was on sqllite that no one had enough patience to let it finish syncing after the Nth day.. :) )
13:17 < jamesob> leveldb strikes me as totally fine for the utxo set and uprooting it seems very dangerous (not sure if I'm attacking a strawman here)
13:17 < gmaxwell> s/fore/for/
13:17 < provoostenator> "SQLite does not use Git" that's a great start...
13:17 < provoostenator> (but nothing a checksum can't handle)
13:17 < sipa> heh
13:17 < sipa> what does that have to do with anything
13:17 < luke-jr> SQLite isn't consensus-critical.
13:18 < luke-jr> just pkgconfig sqlite3, done
13:18 < wumpus> yes
13:18 < gmaxwell> phantomcircuit was saying above that the safe mode of sqllite requires a seperate log file. :(
13:18 < gmaxwell> if so, thats a bummer.
13:18 < BlueMatt> wait, huh, what happened to append-only wallet?
13:18 < wumpus> anyhow I don't think we're ever going to agree on this
13:18 < luke-jr> gmaxwell: do we need the safe mode?
13:19 < BlueMatt> seems like a really, really bad idea to move from a design like that to some standard db env
13:19 < sipa> BlueMatt: great idea, just discussing alternaives :)
13:19 < BlueMatt> heh, we havent had enough fun with bdb?
13:19 < sipa> sqlite is nothing like bdb :)
13:19 < wumpus> at least sqlite supports proper indexing and queries...
13:19 < sipa> (but if what gmaxwell says is true, that makes it mch less attractive)
13:19 < BlueMatt> true, but still
13:19 < wumpus> which is great for finding transactions matching a certain criterion, for example
13:20 < jamesob> wumpus: isn't the sqlite logfile just some optional performance tweak?
13:20 < gmaxwell> wumpus: unless our way of using it is just throwing in a lot of binary blobs like we pretty much use bdb. :P
13:20 < wumpus> with keyvalue databses all that indexing has to be implemented manually
13:20 < wumpus> gmaxwell: as I said, I like how clightning uses it
13:21 < wumpus> it's really sensible and well-designed
13:21 < provoostenator> Problem solved then, a SQL lite binary blob inside bdb.
13:21 < wumpus> somehow I really dislike how we ended up with a wallet embeded in our project and being unable to move away from it
13:22 < gmaxwell> wumpus: to be clear, I'm +1 on using it with a schema, -1 on using it in a blobby way,  neutral on blobby in general, but if we were going to stay blobby a simple thing that just writes out a change log for in memory state would probably be better (more reliable, simpler, etc.).
13:22 < wumpus> I wish it was just some external thing, but that's too much to wish for at this point
13:22 < jamesob> wumpus: huge agree
13:22 < wumpus> everyone is always going to disagree how to move on from here, it's like a really bad local maximum in evolution
13:23 < gmaxwell> if it were, I think bitcoin would be nearly dead... there would be very little reason for people to bother even trying to start a node.
13:23 < gmaxwell> Altcoins where node operations are totally distinct from using a wallet basically just don't haver users using nodes.
13:23 < wumpus> the node could still be shipped with some wallet
13:24 < luke-jr> on that point, we do need to make it easier to pair nodes with other wallets
13:24 < luke-jr> the hard part is the port forwarding stuff :/
13:24 < jamesob> luke-jr: in your opinion is that an issue of making the rpc interface more granular/complete or something else?
13:24 < wumpus> or like monero simply ship with the most simple wallet possible, with no ambitions of anything more
13:24 < gmaxwell> luke-jr: because there is so much development surplus that it would be good to spend it on facilitating duplication of efforts that aren't even being duplicated yet. :P
13:25 < luke-jr> jamesob: RPC interface isn't really used much for other wallets
13:25 < jamesob> anecdotally, if someone just wants to transact in bitcoin they often just go to electrum/trezor/bread/etc.
13:25 < luke-jr> gmaxwell: people are using other wallets whether we facilitate it or not
13:25 < jamesob> I think few people who _just_ want a wallet go to the bother of syncing bitcoind
13:26 < gmaxwell> luke-jr: I don't see how that connects to your comment.
13:26 < jamesob> though I am sympathetic to that reasoning... wish there was a way of quantifying it
13:26 < provoostenator> jamesob: that's probably because they don't understand the privacy tradeoff
13:26 < gmaxwell> luke-jr: how someing using a hosted web wallet doesn't really have anything to do with bitcoind.
13:26 < luke-jr> gmaxwell: I mean electrum/trezor/bread/etc
13:26 < wumpus> in any case, this comes back every time
13:27 < jamesob> of course - but even a user like me doesn't actually use the core wallet because it doesn't, e.g., support hardware devices
13:27 < wumpus> the same discussions since 2012
13:27 < luke-jr> ideally, they could just scan a QR code from Core, and have it use their own node
13:27 < luke-jr> the trouble is getting past firewalls
13:27 < gmaxwell> luke-jr: and what does that hae to do with bitcoind?
13:27 < jamesob> provoostenator: oops ^
13:27 < gmaxwell> It's a lot more than that.
13:27 < wumpus> even the "let's use a SQL database, oh why not postgres" I'm fairly sure we alrady had back in 2012
13:27 < gmaxwell> Trezor, for example, is effectively a hosted web wallet, though with signing using your hardware fob.
13:28 < jamesob> gmaxwell: right - which I hate but nonetheless use
13:28 < gmaxwell> I am really frustrated by the fact that any time anyone mentions storing anything on disk there is a tiresome discussion of the trendy database things. Someone above joked mongo, but in the 2013 (IIRC) flavor of these rehashings, it would actually get suggested seriously.
13:29 < provoostenator> And because people are physically holding it, they're less aware of that problem.
13:29 < provoostenator> Everyone always saying "don't use web wallets, use a hardware wallet"..
13:29 < wumpus> the other wallets aren't better in every regard, that's for sure, the core wallet is pretty good, I'm just tired of some kinds of discussions
13:29 < gmaxwell> jamesob: my point in responding to luke there, that no amount of changed to bitcoind is going to make the 'trezor wallet' work with it.
13:29 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
13:29 < booyah> hashtag nosql
13:30 < wumpus> gmaxwell: exactly... 
13:30 < provoostenator> jamesob: at least there's hope: https://gist.github.com/achow101/a9cf757d45df56753fae9d65db4d6e1d
13:30 < gmaxwell> (getting support for hardware wallets, OTOH, would enable people to not use the trezor wallet, and thats another matter)
13:30 < booyah> gmaxwell: as for trezor, well with electrum it's a signing engine, not webwallet at all
13:30 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:30 < luke-jr> gmaxwell: Electrum already supports Trezors (altohugh to support Electrum, we need a lot more than just port forwarding)
13:31 < gmaxwell> booyah: right, and PSBT was a first step in getting thins so we could use devices like that.
13:31 < wumpus> I'm happy that we managed to depreacte accounts at least, to simplify things, that was also an issue running almost since satoshi left
13:31 < booyah> gmaxwell: freaking finally ;)
13:31 < wumpus> yes hardware wallet support is something worth working on!
13:31 < jamesob> gmaxwell provoostenator: I think even now you can do some bitcoind -> electrum personal server -> electrum -> trezor thing, but I haven't tried it because it sounds like a ton of work
13:31 < wumpus> that would be actually nice
13:31 < wumpus> in contrast to the eternal database discussion
13:31 < gmaxwell> booyah: unfortunately its hard going because the vendors of these things have not been helping, instead mostly just making their own custom stuff for time to market reasons.
13:31 < jonasschnelli> jamesob: its working and setup is easy
13:31 < booyah> gmaxwell: satoshi labs was not helpful?
13:31 < provoostenator> I've tried the electrum personal server approach. Works reasonably well. I've also tried the achow101 approach, which works great once you're used to it, but too manual for now.
13:32 < jamesob> jonasschnelli: oh cool, I'll try that then.
13:32 < wumpus> https://github.com/romanz/electrs looks really neat
13:32 < jonasschnelli> jamesob: Bitbox has a native desktop app that can connect to EPS <-> Core
13:32 < wumpus> (haven't tried it yet though)
13:32 < gmaxwell> jamesob: and it involves using electrum... which has plenty of its own downsides.
13:32 < jamesob> right
13:33 < gmaxwell> I'm certantly not faulting the HW wallet vendors for focusing on time to market, it's just what it is.
13:33 < provoostenator> I have some WIP stuff where I try to turn achow101's HWI scripts into an RPC server, which could eventually be a universal "sign something" service, not necessarily restricted to hardware wallets.
13:33 < wumpus> me neither, though they have been kind of shooting themselves in the foot by not thinking about a common standard, but maybe that's something taht can only arise after experimentation... happy about PSBT
13:34 < provoostenator> In that case all Core needs to do is make a bunch of RPC calls to a user configured URI (or a file socket maybe).
13:34 < gmaxwell> provoostenator: I'd suggested previously that we exeute a configured command and shove crap at it over stdin.
13:34 < provoostenator> And then it's up to hardware wallet makers to listen for those calls.
13:35 < gmaxwell> (I'm less of a fan of URIs because of the security problems, e.g. when some local JS starts connecting to it...)
13:35 < sipa> provoostenator: or PSBT and invoke a binary to sign it
13:35 < provoostenator> Executing commands sounds scary too
13:35 < gmaxwell> provoostenator: hows it scary? it's configured explicitly.
13:35 < provoostenator> True, malware gonna malware, no matter how you do it.
13:36 < gmaxwell> provoostenator: the URI thing in general has a challenge that browsers can make connections to things that listen to the network. There have been a LOT of thefts in eth land, due to 'wallets' that take commands from local sockets.
13:36 < clarkmoody> Apply UNIX philosophy to wallet: text is the universal interface
13:36 < gmaxwell> provoostenator: I'm not talking about malware running unconstrained on your host, I'm talking about just stuff in your webbrowser.
13:36 < wumpus> in any case I think it makes sense to, in meetings, discuss the things each participant plans on working on, not wild far future plans
13:36 < provoostenator> gmaxwell: c-lightning uses file sockets which at least prevent hat.
13:36 < luke-jr> provoostenator: on Windows? O.o
13:36 < wumpus> otherwise we end up discussing the same things from 2012 every time
13:37 < provoostenator> luke-jr: there's that...
13:37 < gmaxwell> provoostenator: okay, thats essentially the same security model as what I was talking about. didn't know you could do that on windows.
13:37 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
13:38 < provoostenator> I wish browsers didn't let websites talk to any URL in the universe, but it seems they do.
13:38 < gmaxwell> wumpus: The way it seems to go though is.. "I plan on working on something something something database" "Excuse me sir, but have you considered Monodb? It has webscale"  then goto 2012;
13:38 -!- rex4539 [~rex4539@ppp-2-84-165-183.home.otenet.gr] has joined #bitcoin-core-dev
13:38 < gmaxwell> maybe I just need to write a webpage to link to, with links to every other time we've gone through this loop.
13:38 < wumpus> windows also has various local RPC methods
13:39 < wumpus> gmaxwell: agree, there seems to be a lack of memory in these kind of things, although it seems to slightly improve, back then we had the literal same discussion within weeks of each other with new people
13:39 < provoostenator> gmaxwell: a nice use case for RPC calls would be a web based multisig service.
13:40 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
13:40 < gmaxwell> provoostenator: in any case the model of "you tell your wallet to talk to some other local program that has the task of signing things" sounds great to me. It also could be used "talk to some other local program that has the task of collecting other signatures for multisig" easily.
13:40 < wumpus> (I think recent windows 10 even has UNIX sockets)
13:40 < gmaxwell> provoostenator: I'd say jinx except this was all pointed out last time I was lobbying in that direction. ;)
13:40 < provoostenator> Yes, it just means those services have to ship an executable, but that trade-off might be worth it. 
13:41 < wumpus> but in any case, if you want a *secure* RPC method, you will have to determine for every OS what is the best choice
13:41 < gmaxwell> provoostenator: "Driver", it might well be the case that eventually we ship drivers for common cases ourselves.
13:41 < jamesob> gmaxwell: you know we're trending upwards because no one *seriously* recommended mongodb this time around
13:41 < wumpus> just deciding for 'UNIX sockets' is very UNIX-centric by default
13:41 < gmaxwell> jamesob: I think thats just because the world at large no longer thinks mongodb is the new hotness. :)
13:42 < jamesob> heh, true
13:42 < provoostenator> gmaxwell: especially if someone comes up with a proper USB protocol standard for talking with devices, so we wouldn't have to merge device specific stuff?
13:42 < gmaxwell> wumpus: well thats why I liked stdio, as it does exist everwhere. :P 
13:42 < wumpus> mongodb suggestion was a reductio ad absurdum by me this time
13:42 -!- ott0disk [~smuxi@cb.85.7a9f.ip4.static.sl-reverse.com] has quit [Ping timeout: 264 seconds]
13:42 < gmaxwell> provoostenator: right, but it's not just the usb, there are UI considerations. e.g. many hardware wallets have some pin entry on the host computer or similar.
13:43 < gmaxwell> Basically the need to control enough of the host probably contributes to making your hardware wallet supported by creating a whole web wallet for it.
13:43 < wumpus> gmaxwell: yes, communicating through a pipe over stdin/stdout seems to be something every OS has
13:44 < provoostenator> At least Ledger and Trezor these days do pin entry on device. So in that case it's just a matter of waiting.
13:44 < wumpus> (though on windows it's different; stdio only exists for console applications, not for winmain ones)
13:45 < jamesob> the Trezor One requires on-host software for pin entry
13:45 < wumpus> it's such a crazy labyrinth people have created, nothing is straightforward
13:45 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 260 seconds]
13:46 < gmaxwell> jamesob: okay that one was the one that I was thinking about.
13:46 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
13:48 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit []
13:49 < provoostenator> There's a bunch of ports that some browsers ban, but it's quite narrow, and those are already used by the system (that's why they're blocked). I also don't think there's a standard.
13:53 < provoostenator> You can add authentication, maybe some tofu mechanism. But browers are extremely powerful these days.
13:53 -!- hebasto [~hebasto@195.60.70.234] has quit [Remote host closed the connection]
13:53 < provoostenator> Even USB is no longer off limits: https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
13:53 < phantomcircuit> gmaxwell, sqlite has a safe *but slow* single file mode
13:54 < phantomcircuit> like really slow
13:54 < phantomcircuit> cause it's using fsync() multiple times per write
13:54 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xbcuhzcyamfocbun] has joined #bitcoin-core-dev
13:55 < achow101> provoostenator: the whole HWI thing is intended for the "execute a command and shove crap at it over stdin"
13:59 < wumpus> phantomcircuit: writes to the wallet are more or less rare, though, so it might still be ok
13:59 < gmaxwell> phantomcircuit: that sounds like it would probably be fine
14:01 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Read error: Connection reset by peer]
14:07 < wumpus> by far and far, most queries will be reads
14:08 < wumpus> this is not like the utxo set where every read tends to imply a write/update
14:09 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
14:12 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
14:12 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
14:28 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Ping timeout: 252 seconds]
14:38 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
14:38 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
14:39 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
14:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
14:48 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
14:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
15:02 -!- jarthur [~jarthur@172.58.153.57] has joined #bitcoin-core-dev
15:04 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has joined #bitcoin-core-dev
15:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
15:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
15:31 -!- jarthur [~jarthur@172.58.153.57] has quit []
15:41 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 272 seconds]
15:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:57 < phantomcircuit> wumpus, reads are fast... for a sql database
15:57 < phantomcircuit> but are significantly slower than the in memory stuff is now
15:58 < phantomcircuit> gmaxwell, seems the issue is in the commit just before the poll() implementation actually
15:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
16:04 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
16:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:14 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
16:22 -!- paracyst_ [paracyst@unaffiliated/paracyst] has quit [Ping timeout: 272 seconds]
16:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
16:26 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]
16:31 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev
16:32 -!- dqx [~dqx@unaffiliated/dqx] has quit [Quit: .]
16:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:36 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
16:49 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
16:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
16:58 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Quit: Leaving.]
17:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
17:13 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds]
17:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:21 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:24 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
17:40 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 246 seconds]
17:43 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xbcuhzcyamfocbun] has quit [Quit: Connection closed for inactivity]
17:46 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
17:46 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.1]
17:50 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Client Quit]
17:54 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
17:59 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
18:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
18:33 -!- unholymachine [~quassel@38.132.115.211] has joined #bitcoin-core-dev
19:17 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
19:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
20:24 -!- schnerchi [~schnerchi@p54A0EDE7.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
20:36 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-dev
20:50 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
20:50 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
20:51 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
20:52 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
21:37 -!- hebasto [~hebasto@195.60.70.234] has joined #bitcoin-core-dev
21:50 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
22:01 -!- unholymachine [~quassel@38.132.115.211] has quit [Remote host closed the connection]
22:02 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
22:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
22:06 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has quit [Ping timeout: 245 seconds]
22:06 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Client Quit]
23:09 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-dev
23:14 -!- escrivner [~user@cpe-76-175-74-114.socal.res.rr.com] has quit [Ping timeout: 272 seconds]
23:17 -!- keymone [~keymone@ip1f109c7a.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
23:39 -!- keymone [~keymone@ip1f109c7a.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
23:55 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
--- Log closed Fri Sep 28 00:00:21 2018