12017-09-21T00:07:07 *** duringo has joined #bitcoin-core-dev
22017-09-21T00:10:35 *** duringo_ has quit IRC
32017-09-21T00:21:39 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (master...2017-09-bitcoin-tx-uncompressed-segwit) https://github.com/bitcoin/bitcoin/pull/11377
42017-09-21T00:30:22 *** goatpig has quit IRC
52017-09-21T00:43:24 <phantomcircuit> gmaxwell, why wouldn't it work?
62017-09-21T00:43:29 <phantomcircuit> it's just slowish
72017-09-21T00:54:37 *** Ylbam has quit IRC
82017-09-21T00:58:57 <bitcoin-git> [bitcoin] btc1-prevention opened pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378
92017-09-21T01:01:09 *** dabura667 has joined #bitcoin-core-dev
102017-09-21T01:02:28 *** JackH has quit IRC
112017-09-21T01:15:47 <bitcoin-git> [bitcoin] fanquake closed pull request #11378: Update COPYING (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11378
122017-09-21T01:17:58 *** promag has joined #bitcoin-core-dev
132017-09-21T01:22:05 *** promag has quit IRC
142017-09-21T01:26:36 *** StopAndDecrypty is now known as StopAndDecrypt
152017-09-21T01:45:36 *** Miezel has joined #bitcoin-core-dev
162017-09-21T01:51:49 *** RubenSomsen has joined #bitcoin-core-dev
172017-09-21T01:56:21 *** thrasher` has quit IRC
182017-09-21T01:58:57 *** thrasher` has joined #bitcoin-core-dev
192017-09-21T01:59:46 *** AaronvanW has quit IRC
202017-09-21T02:05:06 *** AaronvanW has joined #bitcoin-core-dev
212017-09-21T02:20:21 *** justanotheruser has joined #bitcoin-core-dev
222017-09-21T02:25:01 *** rosenfs_ has quit IRC
232017-09-21T02:25:14 *** tknp has quit IRC
242017-09-21T02:45:55 *** JackH has joined #bitcoin-core-dev
252017-09-21T02:48:17 *** Giszmo has quit IRC
262017-09-21T02:48:42 *** harrymm has quit IRC
272017-09-21T02:50:19 *** harrymm has joined #bitcoin-core-dev
282017-09-21T02:51:35 *** harrymm1 has quit IRC
292017-09-21T02:52:13 *** harrymm_ has joined #bitcoin-core-dev
302017-09-21T02:53:26 *** harrymm_ has left #bitcoin-core-dev
312017-09-21T03:16:54 <meshcollider> Is anything in the share/certs/ directory actually relevant anymore? Seems pretty outdated
322017-09-21T03:21:09 <achow101> meshcollider: yes, that's information about the codesigning certs
332017-09-21T03:22:01 *** d9b4bef9 has quit IRC
342017-09-21T03:22:38 <achow101> the threat mitigation part is outdated I think because of the detached sigs thing. the codesigned binaries are now gitian built
352017-09-21T03:23:08 *** d9b4bef9 has joined #bitcoin-core-dev
362017-09-21T03:29:48 <kallewoof> Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with <height> <blockhash> OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match <blockhash>? (It would probably require that <height> was less than <current height> - 100 to avoid nasty double spends at reorgs...)
372017-09-21T03:31:24 <kallewoof> Actually, I don't think that would solve anything, since old UTXOs would still be replayed, just unspendable. Nevermind.
382017-09-21T03:33:53 *** justanotheruser has quit IRC
392017-09-21T03:36:12 <achow101> meshcollider: well I suppose the keys there are outdated as it looks like the codesigned stuff uses a more recent cert
402017-09-21T03:36:29 <achow101> cfields: would you mind updating that? or do you think it should be removed entirely?
412017-09-21T03:37:23 <meshcollider> achow101: yeah that's what I thought, this is stuff from 5 years ago
422017-09-21T03:38:51 <achow101> meshcollider: the keys there are expired too
432017-09-21T03:44:17 <cfields> achow101: yea, i think it can just be removed. The signing process is documented (and scripted)
442017-09-21T03:44:31 <achow101> cfields: where is it documented?
452017-09-21T03:44:53 <cfields> achow101: in the gitian build instructions
462017-09-21T03:45:19 <achow101> oh I see.
472017-09-21T03:45:29 <achow101> where is this script: detached-sig-create.sh?
482017-09-21T03:45:33 <achow101> I only see one for osx
492017-09-21T03:45:35 <bitcoin-git> [bitcoin] MeshCollider opened pull request #11380: Remove outdated share/certs/ directory (master...201709_remove_old_certs) https://github.com/bitcoin/bitcoin/pull/11380
502017-09-21T03:45:44 <achow101> and not one for windows
512017-09-21T03:45:45 <cfields> I've helped a few other projects (litecoin, for ex), build using our process. The last one (i forget who, now) was able to sign without my assistance.
522017-09-21T03:45:57 *** RubenSomsen has quit IRC
532017-09-21T03:46:40 <cfields> hmm, we have one for windows as of 0.15. surely i updated the instructions for it. Checking.
542017-09-21T03:47:26 <cfields> (the script/cert are in contrib/windeploy )
552017-09-21T03:47:40 <achow101> ah, I see it now.
562017-09-21T03:47:50 <achow101> missed that earlier
572017-09-21T03:48:34 <achow101> no certs for osx? (I don't see any in macdeploy)
582017-09-21T03:48:38 <cfields> well, there aren't instructions in that gitian doc like i thought there were. Will add.
592017-09-21T03:49:23 <achow101> the gitian doc has instructions for running the scripts
602017-09-21T03:49:34 <achow101> err the release process doc
612017-09-21T03:49:36 <meshcollider> cfields: might be in the release process doc
622017-09-21T03:50:25 <cfields> no, I got distracted from finishing the osx tool, so committed osx certs can't be used yet
632017-09-21T03:50:32 <cfields> ah, maybe that's it
642017-09-21T03:50:49 *** justanotheruser has joined #bitcoin-core-dev
652017-09-21T03:51:18 <cfields> anyway, gitian spits out "*unsigned.tar.gz", which the signer just untars and runs ./detached-sig-create.sh. Very straigtforward.
662017-09-21T03:51:31 <cfields> but if it's not fully written up, I can do so
672017-09-21T03:52:00 *** ghost43 has quit IRC
682017-09-21T03:52:05 <achow101> it's written up here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#next-steps
692017-09-21T03:52:12 *** RubenSomsen has joined #bitcoin-core-dev
702017-09-21T03:52:29 *** ghost43 has joined #bitcoin-core-dev
712017-09-21T03:52:31 <achow101> why are there 3 certs in win-codesign.cert?
722017-09-21T03:52:46 <achow101> oh, 2 are comodo's and one is ours
732017-09-21T03:52:48 <cfields> yea, there we go
742017-09-21T03:52:58 <cfields> yea, it's the whole chain
752017-09-21T03:53:45 <achow101> Is the osx one the same as the one in share/certs?
762017-09-21T03:53:50 <achow101> it expires in 2018
772017-09-21T03:55:14 <cfields> probably so
782017-09-21T03:55:43 <meshcollider> so they should be moved instead of removed?
792017-09-21T03:56:16 <achow101> meshcollider: the windows one should be removed
802017-09-21T03:56:34 <achow101> don't know about the osx one, but it probably can't be used with the osx script provided in contrib/macdeploy
812017-09-21T03:56:50 <achow101> (I don't have a mac to check if the signature matches that cert)
822017-09-21T03:57:01 <cfields> the stuff in share/certs is informational only, it isn't used atm
832017-09-21T03:57:31 <cfields> the windows certs in contrib/windeploy are actually used by the signing/re-attaching process
842017-09-21T03:58:19 <cfields> the cert chain could be ripped out of an osx binary with some hacking (or maybe there's a tool for it?)
852017-09-21T03:59:34 <achow101> cfields: is there some way to check the detached sigs?
862017-09-21T04:00:06 <cfields> what do you mean by check?
872017-09-21T04:00:29 <achow101> like extract the chain out of them
882017-09-21T04:00:43 <achow101> or see if they verify to that cert
892017-09-21T04:02:35 *** RubenSomsen has quit IRC
902017-09-21T04:03:21 <cfields> checking
912017-09-21T04:10:57 <cfields> the 0.15.0.1 binary contains the same localKeyID as the committed .pem
922017-09-21T04:12:06 <achow101> ok, thanks
932017-09-21T04:12:29 <achow101> I wonder if gavin made bitcoin xt or bitcoin classic releases signed with that key...
942017-09-21T04:14:52 <cfields> not afaik
952017-09-21T04:15:31 <cfields> fwiw: https://pastebin.com/raw/UZKRpdPc
962017-09-21T04:15:31 <achow101> I assume that he isn't stupid enough to do that
972017-09-21T04:15:47 <cfields> anyone on osx can reproduce ^^
982017-09-21T04:16:09 <achow101> is codesign some osx utility?
992017-09-21T04:16:34 <cfields> yea
1002017-09-21T04:17:22 *** tknp has joined #bitcoin-core-dev
1012017-09-21T04:17:23 <cfields> i patched an ios tool to do osx signing a while ago. It's 99% ready, just never finished it/hooked it up
1022017-09-21T04:18:03 <cfields> https://github.com/theuni/osx-codesign
1032017-09-21T04:19:04 <achow101> why?
1042017-09-21T04:19:05 * luke-jr wonders how hard it would be to get iOS and Android builds of the GUI
1052017-09-21T04:19:05 *** RubenSomsen has joined #bitcoin-core-dev
1062017-09-21T04:19:27 <achow101> luke-jr: supposedly qt supports android in some way
1072017-09-21T04:19:41 <cfields> achow101: why what?
1082017-09-21T04:19:52 <luke-jr> achow101: yes, or I wouldn't even consider it a possibility :p
1092017-09-21T04:20:23 <luke-jr> (it also supports iOS)
1102017-09-21T04:20:24 <achow101> cfields: why did you make an osx signing tool if there already is one?
1112017-09-21T04:20:41 <achow101> (the one existing being whatever is used now)
1122017-09-21T04:20:52 <achow101> luke-jr: it does?
1132017-09-21T04:20:57 <luke-jr> achow101: yes
1142017-09-21T04:21:01 <luke-jr> http://doc.qt.io/qt-5/ios-support.html
1152017-09-21T04:21:12 <cfields> achow101: oh, sorry. portable tool. Works from Linux.
1162017-09-21T04:22:04 <achow101> cfields: ah. ok. I figured it was probably also that it is open source
1172017-09-21T04:22:27 <cfields> achow101: well most (all?) of osx userspace is open-source. It's just a tangled web.
1182017-09-21T04:23:17 <luke-jr> cfields: pretty sure the GUI stuff isn't?
1192017-09-21T04:24:06 <cfields> luke-jr: that would make sense
1202017-09-21T04:29:04 <meshcollider> luke-jr: that can't even be considered until SPV mode is added though right, no way android is going to run Qt with even a pruned blockchain and full UTXO set lol
1212017-09-21T04:31:23 <achow101> meshcollider: it can run bitcoind
1222017-09-21T04:31:29 <achow101> look up ABCore
1232017-09-21T04:32:12 <achow101> and android devices (smartphones in general) are getting more powerful and have more ram
1242017-09-21T04:32:23 <cfields> meshcollider: no reason why it should be less performant than gnu/linux on an arm machine
1252017-09-21T04:35:08 <meshcollider> hmm that's true, I've just never even considered trying to run a full node on a smartphone
1262017-09-21T04:35:40 <meshcollider> that's an interesting idea
1272017-09-21T05:00:41 *** tknp has quit IRC
1282017-09-21T05:23:20 *** ghost43 has quit IRC
1292017-09-21T05:23:33 *** ghost43 has joined #bitcoin-core-dev
1302017-09-21T05:58:56 *** PRab has quit IRC
1312017-09-21T06:05:12 *** PRab has joined #bitcoin-core-dev
1322017-09-21T06:22:26 *** dcousens has joined #bitcoin-core-dev
1332017-09-21T06:39:32 *** promag has joined #bitcoin-core-dev
1342017-09-21T06:42:34 *** promag has quit IRC
1352017-09-21T06:48:12 *** BashCo has quit IRC
1362017-09-21T07:05:48 *** afk11 has quit IRC
1372017-09-21T07:07:21 *** afk11 has joined #bitcoin-core-dev
1382017-09-21T07:09:50 *** ThomasV has joined #bitcoin-core-dev
1392017-09-21T07:11:09 *** promag has joined #bitcoin-core-dev
1402017-09-21T07:12:03 *** BashCo has joined #bitcoin-core-dev
1412017-09-21T07:15:58 *** promag has quit IRC
1422017-09-21T07:16:11 *** ThomasV has quit IRC
1432017-09-21T07:19:06 *** LeMiner2 has joined #bitcoin-core-dev
1442017-09-21T07:21:36 *** LeMiner has quit IRC
1452017-09-21T07:21:36 *** LeMiner2 is now known as LeMiner
1462017-09-21T07:37:47 *** ThomasV has joined #bitcoin-core-dev
1472017-09-21T08:09:40 *** SopaXorzTaker has joined #bitcoin-core-dev
1482017-09-21T08:12:08 *** privateglacier has joined #bitcoin-core-dev
1492017-09-21T08:13:20 *** timothy has joined #bitcoin-core-dev
1502017-09-21T08:24:04 *** alreadylate has joined #bitcoin-core-dev
1512017-09-21T08:31:43 *** AaronvanW has quit IRC
1522017-09-21T08:33:55 *** AaronvanW has joined #bitcoin-core-dev
1532017-09-21T08:34:35 *** paveljanik has joined #bitcoin-core-dev
1542017-09-21T08:34:40 *** paveljanik has joined #bitcoin-core-dev
1552017-09-21T08:35:11 *** Aaronvan_ has joined #bitcoin-core-dev
1562017-09-21T08:38:23 *** AaronvanW has quit IRC
1572017-09-21T08:38:43 <esotericnonsense> my smartphone is multiple years old and is more powerful than many machines i've synced a node from
1582017-09-21T08:39:53 <esotericnonsense> much better than a raspberry pi anyway :)\
1592017-09-21T08:40:26 *** promag has joined #bitcoin-core-dev
1602017-09-21T08:41:27 *** Aaronvan_ has quit IRC
1612017-09-21T08:44:36 *** promag has quit IRC
1622017-09-21T08:46:39 *** privateglacier has quit IRC
1632017-09-21T08:56:44 *** promag has joined #bitcoin-core-dev
1642017-09-21T09:06:13 *** ula has quit IRC
1652017-09-21T09:07:43 *** Geoffy has joined #bitcoin-core-dev
1662017-09-21T09:15:23 *** sdfgsdfg_ has joined #bitcoin-core-dev
1672017-09-21T09:15:33 *** Miezel has quit IRC
1682017-09-21T09:16:39 <sdfgsdfg_> ohio, how much until LN is tested on mainnet ?
1692017-09-21T09:16:53 *** Miezel has joined #bitcoin-core-dev
1702017-09-21T09:37:11 <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.)
1712017-09-21T09:41:18 *** Miezel has quit IRC
1722017-09-21T09:46:13 <meshcollider> link: https://www.reddit.com/r/Bitcoin/comments/714x2k/what_is_the_status_of_the_lightning_network/dn8docc/
1732017-09-21T09:50:44 <promag> wumpus: is there a thread pool for RPC handling?
1742017-09-21T10:01:12 *** dabura667 has quit IRC
1752017-09-21T10:19:27 *** RubenSomsen has quit IRC
1762017-09-21T10:25:29 *** promag has quit IRC
1772017-09-21T10:28:25 *** promag has joined #bitcoin-core-dev
1782017-09-21T10:30:28 *** sdfgsdfg_ has quit IRC
1792017-09-21T10:33:23 *** sdfgsdfg has joined #bitcoin-core-dev
1802017-09-21T10:38:24 *** ThomasV has quit IRC
1812017-09-21T10:43:30 *** promag has quit IRC
1822017-09-21T10:47:33 *** RubenSomsen has joined #bitcoin-core-dev
1832017-09-21T11:07:22 *** ThomasV has joined #bitcoin-core-dev
1842017-09-21T11:29:17 *** NielsvG has joined #bitcoin-core-dev
1852017-09-21T11:30:05 *** ThomasV has quit IRC
1862017-09-21T11:30:51 *** m8tion has joined #bitcoin-core-dev
1872017-09-21T11:36:20 *** goatpig has joined #bitcoin-core-dev
1882017-09-21T11:41:41 *** duringo has joined #bitcoin-core-dev
1892017-09-21T11:52:10 *** promag has joined #bitcoin-core-dev
1902017-09-21T11:52:17 *** duringo has quit IRC
1912017-09-21T12:05:33 *** arubi has quit IRC
1922017-09-21T12:05:33 *** dermoth has quit IRC
1932017-09-21T12:05:33 *** intcat has quit IRC
1942017-09-21T12:05:33 *** ghost43 has quit IRC
1952017-09-21T12:05:33 *** afk11 has quit IRC
1962017-09-21T12:13:54 *** SopaXorzTaker has quit IRC
1972017-09-21T12:15:36 *** SopaXorzTaker has joined #bitcoin-core-dev
1982017-09-21T12:21:37 *** laurentmt has joined #bitcoin-core-dev
1992017-09-21T12:29:14 *** ThomasV has joined #bitcoin-core-dev
2002017-09-21T12:32:38 *** duringo has joined #bitcoin-core-dev
2012017-09-21T12:37:18 *** ghost43 has joined #bitcoin-core-dev
2022017-09-21T12:37:20 *** arubi has joined #bitcoin-core-dev
2032017-09-21T12:37:21 *** afk11 has joined #bitcoin-core-dev
2042017-09-21T12:37:23 *** intcat has joined #bitcoin-core-dev
2052017-09-21T12:38:04 *** laurentmt has quit IRC
2062017-09-21T12:49:02 *** duringo_ has joined #bitcoin-core-dev
2072017-09-21T12:49:02 *** duringo has quit IRC
2082017-09-21T12:49:41 *** laurentmt has joined #bitcoin-core-dev
2092017-09-21T12:49:43 *** laurentmt has quit IRC
2102017-09-21T12:58:40 *** promag has quit IRC
2112017-09-21T12:58:57 *** promag has joined #bitcoin-core-dev
2122017-09-21T13:06:34 *** duringo_ has quit IRC
2132017-09-21T13:10:10 *** Giszmo has joined #bitcoin-core-dev
2142017-09-21T13:12:35 *** dermoth has joined #bitcoin-core-dev
2152017-09-21T13:12:42 *** dcousens has quit IRC
2162017-09-21T13:14:50 *** dcousens has joined #bitcoin-core-dev
2172017-09-21T13:17:20 *** Guyver2 has joined #bitcoin-core-dev
2182017-09-21T13:29:52 *** promag has quit IRC
2192017-09-21T13:40:00 *** Giszmo has quit IRC
2202017-09-21T13:45:08 *** promag has joined #bitcoin-core-dev
2212017-09-21T13:50:15 *** harrymm has quit IRC
2222017-09-21T13:51:28 *** justanotheruser has quit IRC
2232017-09-21T13:52:11 *** harrymm has joined #bitcoin-core-dev
2242017-09-21T13:53:19 *** Giszmo has joined #bitcoin-core-dev
2252017-09-21T13:55:21 *** alreadylate has quit IRC
2262017-09-21T13:56:01 *** alreadylate has joined #bitcoin-core-dev
2272017-09-21T13:59:48 *** RubenSomsen has quit IRC
2282017-09-21T14:01:36 *** ossifrage has quit IRC
2292017-09-21T14:08:15 *** alreadylate has quit IRC
2302017-09-21T14:12:36 *** Miezel has joined #bitcoin-core-dev
2312017-09-21T14:14:30 *** promag has quit IRC
2322017-09-21T14:14:40 *** ossifrage has joined #bitcoin-core-dev
2332017-09-21T14:18:11 *** RubenSomsen has joined #bitcoin-core-dev
2342017-09-21T14:28:19 *** harrymm has quit IRC
2352017-09-21T14:29:21 *** dcousens has quit IRC
2362017-09-21T14:29:41 *** RubenSomsen has quit IRC
2372017-09-21T14:33:58 *** Geoffy has quit IRC
2382017-09-21T14:34:58 *** alreadylate has joined #bitcoin-core-dev
2392017-09-21T14:40:53 *** StopAndDecrypt_ has quit IRC
2402017-09-21T14:48:54 *** laurentmt has joined #bitcoin-core-dev
2412017-09-21T14:54:39 *** StopAndDecrypt_ has joined #bitcoin-core-dev
2422017-09-21T15:00:36 *** laurentmt has quit IRC
2432017-09-21T15:07:07 *** meshcollider has quit IRC
2442017-09-21T15:10:50 *** harrymm has joined #bitcoin-core-dev
2452017-09-21T15:13:44 <bitcoin-git> [bitcoin] aqibbak opened pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381
2462017-09-21T15:19:08 *** jtimon has quit IRC
2472017-09-21T15:19:36 *** Giszmo has quit IRC
2482017-09-21T15:23:01 *** alreadylate has quit IRC
2492017-09-21T15:25:51 *** alreadylate has joined #bitcoin-core-dev
2502017-09-21T15:29:07 *** harrymm has quit IRC
2512017-09-21T15:30:45 *** harrymm has joined #bitcoin-core-dev
2522017-09-21T15:34:09 <wumpus> promag: yes, the HTTP worker threads
2532017-09-21T15:39:48 *** laurentmt has joined #bitcoin-core-dev
2542017-09-21T15:41:02 *** laurentmt has quit IRC
2552017-09-21T15:45:08 *** BashCo has quit IRC
2562017-09-21T15:46:44 *** veleiro has joined #bitcoin-core-dev
2572017-09-21T15:47:37 *** Giszmo has joined #bitcoin-core-dev
2582017-09-21T15:48:28 *** Murch has joined #bitcoin-core-dev
2592017-09-21T15:51:18 *** Murch has quit IRC
2602017-09-21T16:01:19 *** Geoffy has joined #bitcoin-core-dev
2612017-09-21T16:15:04 *** promag has joined #bitcoin-core-dev
2622017-09-21T16:15:49 *** alreadylate has quit IRC
2632017-09-21T16:19:05 *** promag has quit IRC
2642017-09-21T16:35:15 *** sdfgsdfg has quit IRC
2652017-09-21T16:46:32 *** laurentmt has joined #bitcoin-core-dev
2662017-09-21T16:46:56 *** Giszmo has quit IRC
2672017-09-21T16:47:49 *** laurentmt has quit IRC
2682017-09-21T16:49:55 *** BashCo has joined #bitcoin-core-dev
2692017-09-21T17:03:37 <ossifrage> The 'reindexing blocks on disk...' progress bar flaps around quite a bit, not exactly a stable progress bar
2702017-09-21T17:05:06 *** Giszmo has joined #bitcoin-core-dev
2712017-09-21T17:10:47 *** m8tion has quit IRC
2722017-09-21T17:23:12 *** RubenSomsen has joined #bitcoin-core-dev
2732017-09-21T17:24:37 <wumpus> at least better than not showing progress at all
2742017-09-21T17:25:05 <ossifrage> wumpus, yeah it just was flapping between "5 year" and "3 years" behind, which is a bit extreme
2752017-09-21T17:26:02 <gmaxwell> huh....
2762017-09-21T17:26:06 <gmaxwell> it shouldn't do that
2772017-09-21T17:26:18 <ossifrage> I restarted the node with txindex=1
2782017-09-21T17:26:24 *** Deadhand has quit IRC
2792017-09-21T17:26:46 <ossifrage> I set dbcache to 4096
2802017-09-21T17:27:27 *** Ylbam has joined #bitcoin-core-dev
2812017-09-21T17:27:53 <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
2822017-09-21T17:28:41 <ossifrage> I thought the estimate was just based on block count not transaction count?
2832017-09-21T17:29:12 <sipa> no, it's based on transaction count
2842017-09-21T17:29:38 *** ThomasV has quit IRC
2852017-09-21T17:29:50 <ossifrage> Now it is flapping + 1 year
2862017-09-21T17:30:23 *** Deadhand has joined #bitcoin-core-dev
2872017-09-21T17:32:16 *** promag has joined #bitcoin-core-dev
2882017-09-21T17:36:51 *** promag has quit IRC
2892017-09-21T17:40:02 <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 :)
2902017-09-21T17:43:33 <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()?
2912017-09-21T17:44:29 <wumpus> that's just in the beginning, it will get cpu bound soon enough
2922017-09-21T17:45:37 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11381: Update .travis.yml (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11381
2932017-09-21T17:46:05 <gmaxwell> if its flaping then it doesn't work like I understood...
2942017-09-21T17:46:35 *** promag has joined #bitcoin-core-dev
2952017-09-21T17:48:12 *** timothy has quit IRC
2962017-09-21T17:48:13 <ossifrage> Both the bar and the text are flapping but the "Progress x%" is counting up smoothly (that must be just block height?)
2972017-09-21T17:48:18 <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
2982017-09-21T17:48:19 *** promag has quit IRC
2992017-09-21T17:48:32 *** promag has joined #bitcoin-core-dev
3002017-09-21T17:51:59 <wumpus> I don't think it has used block height as a progress measure in the UI since 0.5.x or so
3012017-09-21T17:53:23 <wumpus> block height is pretty useless for that because it starts off really fast and then slows down more and more
3022017-09-21T17:53:58 *** promag has quit IRC
3032017-09-21T18:06:16 *** Murch has joined #bitcoin-core-dev
3042017-09-21T18:12:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3052017-09-21T18:13:18 *** Giszmo has quit IRC
3062017-09-21T18:25:32 *** laurentmt has joined #bitcoin-core-dev
3072017-09-21T18:30:52 *** Giszmo has joined #bitcoin-core-dev
3082017-09-21T18:38:45 *** laurentmt has quit IRC
3092017-09-21T18:41:41 *** Chris_Stewart_5 has quit IRC
3102017-09-21T18:56:30 *** meshcollider has joined #bitcoin-core-dev
3112017-09-21T18:58:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3122017-09-21T19:00:11 <sipa> meetung?
3132017-09-21T19:00:26 <wumpus> #startmeeting
3142017-09-21T19:00:26 <lightningbot> Meeting started Thu Sep 21 19:00:26 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3152017-09-21T19:00:26 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3162017-09-21T19:00:49 <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
3172017-09-21T19:00:55 <kanzure> hi.
3182017-09-21T19:00:59 <sipa> hi.
3192017-09-21T19:01:04 <meshcollider> hello
3202017-09-21T19:01:09 <cfields> hi
3212017-09-21T19:01:24 <sdaftuar> hey
3222017-09-21T19:01:26 <luke-jr> hi
3232017-09-21T19:01:42 <jnewbery> hello
3242017-09-21T19:02:06 <achow101> hi
3252017-09-21T19:02:17 <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
3262017-09-21T19:02:18 <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
3272017-09-21T19:02:26 <sdaftuar> yay
3282017-09-21T19:02:49 <wumpus> #topic high-priority for review
3292017-09-21T19:03:10 <achow101> #10871 please?
3302017-09-21T19:03:12 <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
3312017-09-21T19:03:21 *** Geoffy has quit IRC
3322017-09-21T19:03:31 <wumpus> I don't think we made much progress on review, this week (me included)
3332017-09-21T19:03:49 <BlueMatt> no, we (or at least I) did not :(
3342017-09-21T19:04:23 <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
3352017-09-21T19:04:50 <gmaxwell> Well they shouldn't run 0.5, that would be bad.
3362017-09-21T19:04:50 <wumpus> added 10871
3372017-09-21T19:04:51 <BlueMatt> heh, so, what, when a new release is announced they just build master? :(
3382017-09-21T19:05:07 <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
3392017-09-21T19:05:12 <gmaxwell> BlueMatt: some people do that.
3402017-09-21T19:05:15 <wumpus> luke-jr: also thought about that
3412017-09-21T19:05:19 <BlueMatt> gmaxwell: wat
3422017-09-21T19:05:26 <luke-jr> lol
3432017-09-21T19:05:34 <wumpus> luke-jr: it should at least print a deprecated message
3442017-09-21T19:05:44 <sipa> BlueMatt: gmaxwell is joking about my typo (0.5 instead of 0.15)
3452017-09-21T19:05:46 <BlueMatt> gmaxwell: so...what you're saying is we should start using a "develop" branch with master pointing to released versions?
3462017-09-21T19:05:54 <BlueMatt> sipa: i figured......
3472017-09-21T19:05:54 <wumpus> luke-jr: instead of just about a missing call, as if it's never existed
3482017-09-21T19:06:21 <sipa> i like the approach being used for the estimatefee deprecation
3492017-09-21T19:06:23 <luke-jr> BlueMatt: github lets you change the default branch, so we could just make it the latest stable branch
3502017-09-21T19:06:24 <goatpig> dont poeple typically pull tags, not just the head of a branch (in this case master)
3512017-09-21T19:06:26 <wumpus> BlueMatt: or we can just change the github default branch to something else, you know
3522017-09-21T19:06:31 <luke-jr> problem is, it's also the default for PRsâ¦
3532017-09-21T19:06:34 <BlueMatt> wumpus: yea, possible
3542017-09-21T19:06:36 <sipa> where it disappears, but you have a cmdline switch to re-enable
3552017-09-21T19:06:40 <BlueMatt> I mean really not joking there that's a serious issue
3562017-09-21T19:06:49 <wumpus> but yes, PRs also go there by default, whichi s kinda annoying
3572017-09-21T19:06:55 <BlueMatt> people building master right after release is usually bad cause we merge lots of fun stuff on master right after release :/
3582017-09-21T19:06:56 <achow101> topic suggestion: deprecation stuff a la #11031
3592017-09-21T19:06:57 <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
3602017-09-21T19:07:05 <luke-jr> I suppose we can expect developers to be smarter than users
3612017-09-21T19:07:22 <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.
3622017-09-21T19:07:22 <cfields> sipa: i like that too. or even an rpc arg like -force-deprecated.
3632017-09-21T19:07:27 <wumpus> PRs to branches are really annoying, so I'd prefer to just keep the status quo there
3642017-09-21T19:07:33 <BlueMatt> gmaxwell: yea, maybe we should make the warnings louder?
3652017-09-21T19:07:37 <BlueMatt> that may be acceptable similar
3662017-09-21T19:07:38 <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
3672017-09-21T19:07:43 <luke-jr> cfields: better to force the user to be involved IMO
3682017-09-21T19:07:55 <sipa> wumpus: agree
3692017-09-21T19:08:06 <wumpus> it can't be the release announcement, as I mention the exact tag to check out there...
3702017-09-21T19:08:13 <jonasschnelli> hi
3712017-09-21T19:08:15 <cfields> luke-jr: that's what i meant.
3722017-09-21T19:08:31 <luke-jr> cfields: a RPC arg wouldn't have the user involved
3732017-09-21T19:08:44 <BlueMatt> maybe bitcoind should need a -iknowthisisunreleasedunstableversion option :(
3742017-09-21T19:08:46 <luke-jr> software would just set it
3752017-09-21T19:08:48 <wumpus> maybe would make sense to add a git clone command in there too for people that can't figure that out themselves
3762017-09-21T19:08:58 <BlueMatt> or configure could take it
3772017-09-21T19:09:05 <luke-jr> BlueMatt: default to testnet?
3782017-09-21T19:09:17 <cfields> luke-jr: oh ok, different definitions of user. i see what you mean.
3792017-09-21T19:09:19 <wumpus> configure already has that information, so that'd make sense
3802017-09-21T19:09:21 <BlueMatt> ./configure --this-version-is-unreleased-and-possibly-unstable
3812017-09-21T19:09:37 <BlueMatt> that would make people think twice and make people fix their guides
3822017-09-21T19:09:43 <luke-jr> s/unstable/insecure/ âº
3832017-09-21T19:09:50 <achow101> luke-jr: we would forget to make it default to mainnet for releases
3842017-09-21T19:10:01 <BlueMatt> heh, ok, at the risk of bikeshedding, I vote cfields implement it...I dunno anything 'bout autotools
3852017-09-21T19:10:02 <BlueMatt> :p
3862017-09-21T19:10:04 <luke-jr> achow101: would we? release-process.md
3872017-09-21T19:10:04 <wumpus> I've never forget to set IS_RELEASE to true for releases
3882017-09-21T19:10:21 <wumpus> a few times we've forgot to bump the version number but only for *minor* releases
3892017-09-21T19:10:22 <luke-jr> or just have -testnet default to !IS_RELEASE
3902017-09-21T19:10:43 <cfields> heh
3912017-09-21T19:10:46 <wumpus> and for branches the IS_RELEASE is always true anyhow
3922017-09-21T19:10:49 <BlueMatt> luke-jr: I kinda like it not modifying the bitcoind at all now that i think about it
3932017-09-21T19:11:01 <sipa> wumpus: an alternative would be to have a bitcoin-releases repo (under the same org), to which only release tags get pushed
3942017-09-21T19:11:04 <BlueMatt> build the same bitcoind, but make people type something that says "is not release"
3952017-09-21T19:11:13 <sipa> wumpus: and direct people to clone from there if they just want stable things
3962017-09-21T19:11:16 <sipa> but meh...
3972017-09-21T19:11:23 <wumpus> sipa: I don't know...
3982017-09-21T19:11:29 <BlueMatt> sipa: heh, if we make it not build from bitcoin/bitcoin, ok
3992017-09-21T19:11:33 <wumpus> I really prefer not to mess with the repopsotiry too much
4002017-09-21T19:11:44 <jonasschnelli> agree with wumpus
4012017-09-21T19:11:45 <morcos> This doesn't seem that large a problem to me...
4022017-09-21T19:11:48 <sipa> wumpus: yes, agree - i don't think we should do anything
4032017-09-21T19:11:48 <wumpus> agree
4042017-09-21T19:11:54 <wumpus> any other topics?
4052017-09-21T19:11:59 <BlueMatt> agreed, though I'd vote for a configure flag
4062017-09-21T19:11:59 <achow101> we could move the repo to bitcoin-core and break all of those guides :)
4072017-09-21T19:12:03 <gmaxwell> yea, I think we don't need to do anything except hunt down and kill people with bad guides. :P
4082017-09-21T19:12:03 <sipa> achow101 had a topic
4092017-09-21T19:12:06 <BlueMatt> its not a huge issue, but it sounds rather dangerous
4102017-09-21T19:12:11 <sipa> (though maybe we've covered it already)
4112017-09-21T19:12:13 <gmaxwell> perhaps increase the profile of tarball downloads.
4122017-09-21T19:12:18 <BlueMatt> and I dont think hunting down guide-writers is possible
4132017-09-21T19:12:25 <wumpus> gmaxwell: now that sounds like a good action item
4142017-09-21T19:12:33 <wumpus> $action hunt down and kill people with bad guides
4152017-09-21T19:12:44 <gmaxwell> BlueMatt: publishers, not technically authors.
4162017-09-21T19:12:49 <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)
4172017-09-21T19:12:51 <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
4182017-09-21T19:13:27 <wumpus> #topic deprecation stuff a la #11031
4192017-09-21T19:13:29 <gribble> https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
4202017-09-21T19:13:37 <luke-jr> there's only 363 0.15.99 nodes
4212017-09-21T19:14:02 <BlueMatt> luke-jr: I'd expect there to be ~0 on mainnet aside from some developer test nodes, fwiw
4222017-09-21T19:14:18 <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
4232017-09-21T19:14:43 <BlueMatt> achow101: thats fine, at least they were made to type "I know this is going away soon"
4242017-09-21T19:14:47 <BlueMatt> so they cant show up and complain that its gone
4252017-09-21T19:14:48 <cfields> jnewbery: i like it (better than an rpc arg, on second thought), though the name could use some bikeshedding :(
4262017-09-21T19:15:05 <jonasschnelli> luke-jr: my crawler counts 2496
4272017-09-21T19:15:16 <jonasschnelli> oh.. no .99,.. sry
4282017-09-21T19:15:51 <wumpus> I also prefer command line arg to rpc arg
4292017-09-21T19:15:59 <wumpus> it's enough to type it once
4302017-09-21T19:16:04 <jnewbery> achow101: it's designed such that the user needs to include `-enablerpcmethod=<method1> -enablerpcmethod=<method2> ...` to avoid the problem of a user just setting `-enablealldepractedrpcmethods` and forgetting
4312017-09-21T19:16:42 <jnewbery> cfields: yes, name could probably be improved
4322017-09-21T19:16:45 <gmaxwell> yea, don't have a deprecatedall, it needs to be specific.
4332017-09-21T19:16:50 <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)
4342017-09-21T19:16:53 <meshcollider> hmm yeah "-enablerpcmethod=" should probably have the word "deprecated" in it
4352017-09-21T19:17:00 <wumpus> yes
4362017-09-21T19:17:11 <achow101> I propose calling it -enableddeprecatedrpc
4372017-09-21T19:17:17 <jonasschnelli> ack
4382017-09-21T19:17:18 <wumpus> otherwise it sounds more like a silly security feature
4392017-09-21T19:17:20 <meshcollider> +!
4402017-09-21T19:17:32 *** Geoffy has joined #bitcoin-core-dev
4412017-09-21T19:17:33 <meshcollider> s/!/1/
4422017-09-21T19:17:57 <sipa> -yesimnaughtyandneedtoupdatemyclienttonotuserpcmethod=name
4432017-09-21T19:18:15 <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
4442017-09-21T19:18:33 <luke-jr> thought: should rpcuser auth always throw RPC_METHOD_DEPRECATED? if so, how does the user bypass it?
4452017-09-21T19:18:43 <morcos> -deprecatedrpc is good enough
4462017-09-21T19:18:45 <luke-jr> maybe -enabledeprecated= would be better
4472017-09-21T19:18:51 <wumpus> morcos: yes!
4482017-09-21T19:18:51 <morcos> in a light pink
4492017-09-21T19:18:53 <gmaxwell> -backwardscompatibilitylaunchcode=0xdeadbeef234828429342893429 < that could trigger fields that are going away. :P
4502017-09-21T19:19:05 <wumpus> hehehe
4512017-09-21T19:19:16 <gmaxwell> (and you need to read the release notes to get the launch code)
4522017-09-21T19:19:21 <gmaxwell> (or source)
4532017-09-21T19:19:29 <jnewbery> ok, -deprecatedrpc it is
4542017-09-21T19:19:35 <wumpus> release notes scavenger hunt
4552017-09-21T19:19:37 <cfields> gmaxwell: where the launchcode is the git commit, so it changes every day until release
4562017-09-21T19:20:16 <cfields> jnewbery: ack
4572017-09-21T19:20:17 <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.
4582017-09-21T19:20:19 <luke-jr> gmaxwell: too strong for mere deprecation IMO
4592017-09-21T19:20:41 <gmaxwell> luke-jr: yes, though it solved the how about deprecated fields case.
4602017-09-21T19:20:46 <luke-jr> something like that feels more like to allow changing consensus-critical stuff
4612017-09-21T19:20:55 <achow101> I suppose we can then put all of the deprecated account RPCs behind that argument
4622017-09-21T19:21:06 <cfields> gmaxwell: you're deprecating me? :(
4632017-09-21T19:21:11 <wumpus> yes
4642017-09-21T19:21:14 <luke-jr> gmaxwell: how about if the "launch code" matches the method name for methods? :p
4652017-09-21T19:21:22 <luke-jr> and "accounts" for accounts
4662017-09-21T19:21:29 <wumpus> in the case of accounts it'd be a group not one single call
4672017-09-21T19:21:30 <luke-jr> "rpcuser" for -rpcuser
4682017-09-21T19:21:42 <wumpus> right
4692017-09-21T19:21:55 <luke-jr> this code already fits that paradigm I think, except for the param name
4702017-09-21T19:21:57 <achow101> luke-jr: doing that for rpcuser is going to annoy a lot of people
4712017-09-21T19:22:16 <luke-jr> achow101: yes, that can be discussed separately; it was an example
4722017-09-21T19:22:19 <wumpus> I think we should keep the discussion of what things to deprecate separate
4732017-09-21T19:22:26 <sipa> agree
4742017-09-21T19:22:33 <achow101> ok
4752017-09-21T19:23:56 <jonasschnelli> removing the account support via -depracaterpc and positioned arguments seems pretty difficult and/or dangerous.
4762017-09-21T19:24:08 <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
4772017-09-21T19:24:18 <luke-jr> "rpc" probably shouldn't be in the arg name.
4782017-09-21T19:24:43 <jonasschnelli> users may be confuse why account are deprecated but still work while -depacaterpc=accounts
4792017-09-21T19:24:59 <luke-jr> -enabledeprecated seemed nicer IMO
4802017-09-21T19:25:05 <achow101> jnewbery: I guess so. I haven't looked over 11031 in a while so I want to review it before rebasing
4812017-09-21T19:25:12 <wumpus> jonasschnelli: it's just the account rpcs that are deprecated, accounts themselves will work as labels
4822017-09-21T19:25:16 <meshcollider> jonasschnelli: are you suggesting disable the account system completely?
4832017-09-21T19:25:23 <meshcollider> (without deprecation)
4842017-09-21T19:25:48 <jonasschnelli> wumpus: yes. That makes sense.
4852017-09-21T19:25:52 <wumpus> we'll not rip out the account arguments from any non-account RPC calls
4862017-09-21T19:26:00 <wumpus> just that move etc are deprecated
4872017-09-21T19:26:22 <achow101> topic suggestion: what to deprecate
4882017-09-21T19:26:36 <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
4892017-09-21T19:27:02 <wumpus> I doubt there is any ideal way to deprecate a monster like the accounts feature, tbh
4902017-09-21T19:27:06 <luke-jr> wumpus: getbalance <non-*> should fail too
4912017-09-21T19:27:35 <wumpus> luke-jr: yes
4922017-09-21T19:28:05 *** chjj has joined #bitcoin-core-dev
4932017-09-21T19:28:13 <luke-jr> jonasschnelli: no "rpc" :/
4942017-09-21T19:28:17 <wumpus> do we have any more upbeat topic than deprecation?
4952017-09-21T19:28:37 <gmaxwell> China blocking bitcoin?
4962017-09-21T19:28:38 <gmaxwell> (not really)
4972017-09-21T19:28:39 <meshcollider> segwit wallet support progress?
4982017-09-21T19:28:43 <gmaxwell> That
4992017-09-21T19:28:52 <sipa> i'll have a PR soon
5002017-09-21T19:28:52 <wumpus> #topic segwit wallet support progress
5012017-09-21T19:28:55 <wumpus> thanks
5022017-09-21T19:29:06 <sipa> otherwise, review #11167
5032017-09-21T19:29:07 <gmaxwell> sipa: Have you heard from thomasv about them blocking v>0
5042017-09-21T19:29:09 <gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
5052017-09-21T19:29:26 <sipa> gmaxwell: yes, we discussed it in here yesterday
5062017-09-21T19:29:26 <achow101> sipa: how soon is soon
5072017-09-21T19:29:33 <sipa> achow101: this week, i hope
5082017-09-21T19:29:58 <jonasschnelli> sipa: are you also tackling the GUI?
5092017-09-21T19:30:04 <gmaxwell> did you take my advice and call the new file key-i-key-i-o.cpp
5102017-09-21T19:30:11 <sipa> jonasschnelli: no, i'll need help for that
5112017-09-21T19:30:21 <sipa> gmaxwell: just key_io
5122017-09-21T19:30:32 <meshcollider> haha
5132017-09-21T19:30:35 <jonasschnelli> sipa: please point me to your branch after the meeting so I can start to work on that
5142017-09-21T19:30:58 <sipa> (for context, gmaxwell is talking about the followup #11372, which is not for 0.15.1)
5152017-09-21T19:30:59 <gribble> https://github.com/bitcoin/bitcoin/issues/11372 | Address encoding cleanup by sipa · Pull Request #11372 · bitcoin/bitcoin · GitHub
5162017-09-21T19:31:01 <gmaxwell> There should be almost no GUI intersection, other than perhaps offering the default overrides in the gui.
5172017-09-21T19:31:23 <sipa> yeah, i expect some expert mode setting to choose the address type - but otherwise it can just use the default
5182017-09-21T19:31:36 <gmaxwell> oh right, point of use switching, sure.
5192017-09-21T19:31:43 *** ThomasV has joined #bitcoin-core-dev
5202017-09-21T19:31:49 <jonasschnelli> sipa: yes. That is what I though...
5212017-09-21T19:32:07 <sipa> not that much to say about the topic otherwise
5222017-09-21T19:32:14 <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.
5232017-09-21T19:32:25 <gmaxwell> (not necessarily a 0.15.1 feature in any case)
5242017-09-21T19:32:29 <jonasschnelli> Yes! I just wanted to write that
5252017-09-21T19:32:53 <gmaxwell> well sipa's bip173 patch doesn't have the error finder in it.
5262017-09-21T19:33:03 <sipa> i think there is another question, that ThomasV brought up yesterday
5272017-09-21T19:33:14 <sipa> what to do with private key import/export for segwit addresses
5282017-09-21T19:33:24 <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)
5292017-09-21T19:33:33 <wumpus> some importmulti ?
5302017-09-21T19:33:35 <achow101> sipa: importmulti
5312017-09-21T19:33:36 <sipa> importmulti can handle this natively
5322017-09-21T19:33:44 <wumpus> ok, seems good enough for me then
5332017-09-21T19:33:50 <gmaxwell> importmulti was my first thought too.
5342017-09-21T19:33:54 <achow101> deprecate the other import* rpcs
5352017-09-21T19:33:54 <sipa> but perhaps at least a warning for importprivkey / dumpprivkey is needed
5362017-09-21T19:34:01 <wumpus> just highlight that the old import* rpcs don't work with segwit
5372017-09-21T19:34:07 <jonasschnelli> sipa: yes. Or depracate?
5382017-09-21T19:34:11 <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.
5392017-09-21T19:34:18 <wumpus> or deprecate them at some point, but not for a minor release
5402017-09-21T19:34:30 <sipa> right
5412017-09-21T19:34:39 <gmaxwell> we can announce an intent at any time. (I think we just did.)
5422017-09-21T19:34:46 <ThomasV> importmulti does not seem as easy to use as a serialized format
5432017-09-21T19:34:54 <wumpus> yes, intent+reason could be menitoned in the release notes
5442017-09-21T19:35:09 <sipa> ThomasV: i consider that a feature :)
5452017-09-21T19:35:12 <gmaxwell> ThomasV: because of versioning issues, we're not going to solve a new serialized format right now.
5462017-09-21T19:35:23 <jonasschnelli> importmulti is a bit cumbersome to use,... but should the okay for an RPC layer
5472017-09-21T19:35:24 <wumpus> importing keys in bitcoin core is considered advanced functionality anyhow
5482017-09-21T19:36:02 <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
5492017-09-21T19:36:07 <jonasschnelli> importaddress and key with the current rescan-everything approach must go away at some point anyways
5502017-09-21T19:36:18 <wumpus> jonasschnelli: yeah... that too
5512017-09-21T19:36:25 <ThomasV> gmaxwell: we were also considering an import format along the lines of bip124
5522017-09-21T19:36:28 <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.
5532017-09-21T19:36:55 <achow101> the bech32-for-privkeys thing could be something for segwit only and have a the witness version number included in that?
5542017-09-21T19:37:10 <wumpus> achow101: yes
5552017-09-21T19:37:25 <sipa> achow101: yes, or no - i'm not sure
5562017-09-21T19:37:29 <gmaxwell> achow101: witness version number isn't the right data.
5572017-09-21T19:37:40 <sipa> i think we need a 'pure private key' format, which is just a key
5582017-09-21T19:37:43 <instagibbs> doesn't tell you how it's being used, specifically
5592017-09-21T19:37:45 <sipa> to minimize the data needed for backup
5602017-09-21T19:37:58 <wumpus> more like a 'key use'
5612017-09-21T19:37:59 <gmaxwell> it effectively needs to communicate the scriptpubkey (perhaps be template reference).
5622017-09-21T19:38:01 <sipa> the associated addresses/chains/... can be stored separately
5632017-09-21T19:38:02 <jonasschnelli> Not sure if we should really support exporting / importing private keys over an RPC layer in the long run
5642017-09-21T19:38:14 <luke-jr> sipa: but if you're going for minimal, you'd backup the seed, not the keys?
5652017-09-21T19:38:15 <sipa> jonasschnelli: yeah... that's a hard question
5662017-09-21T19:38:23 <gmaxwell> sipa: still needs metadata.
5672017-09-21T19:38:29 <sipa> gmaxwell: how so?
5682017-09-21T19:38:40 <wumpus> right, you could backup the seed, and some metadata, no need to backup the keys themselves
5692017-09-21T19:38:42 <achow101> <scriptpubkey>|<privkey(s)>
5702017-09-21T19:39:01 <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.
5712017-09-21T19:39:10 <wumpus> yes
5722017-09-21T19:39:12 <sipa> gmaxwell: sure, but i think that can be separate
5732017-09-21T19:39:47 <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
5742017-09-21T19:39:51 <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...)
5752017-09-21T19:40:08 <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)
5762017-09-21T19:40:12 <gmaxwell> it's also potentially a rather small amount of data.
5772017-09-21T19:40:30 <sipa> gmaxwell: an example i came up yesterday is CLTV scripts
5782017-09-21T19:40:43 <sipa> there is no way you can enumerate all CLTV scripts from a particular seed
5792017-09-21T19:41:02 <gmaxwell> no, indeed, but the inability to back up CLTV cleanly was one of the motivations for CSV.
5802017-09-21T19:41:16 <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
5812017-09-21T19:41:30 <luke-jr> so three levels of data really: the seed itself, the types/chains/etc, and the comments/labels
5822017-09-21T19:41:36 <sipa> the private key in that case is just a piece of secret data, referred to by the chains
5832017-09-21T19:41:48 <gmaxwell> asking people to handle two critical to maintain pieces of information instead of one would be unfortunate.
5842017-09-21T19:42:10 <gmaxwell> (and by unfortunate I mean result in non-negligible funds loss in practice)
5852017-09-21T19:42:24 <luke-jr> gmaxwell: maybe concatenate seed + types/chains/etc in practice
5862017-09-21T19:42:36 <sipa> sure, for simple situations you can create a convenient format that handles both simultaneously
5872017-09-21T19:42:38 <gmaxwell> sure. that would be okay to.
5882017-09-21T19:42:40 <wumpus> you could encode it into one identifier somehow...
5892017-09-21T19:42:43 <wumpus> sounds easy enough
5902017-09-21T19:42:45 <gmaxwell> (re to both luke and sipa)
5912017-09-21T19:42:59 <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
5922017-09-21T19:43:02 <gmaxwell> the logical seperation sounds fine, but for at least the common case there should be some format for combined data.
5932017-09-21T19:43:21 <sipa> sure
5942017-09-21T19:43:22 <morcos> +1 for the common case combined format
5952017-09-21T19:43:32 <gmaxwell> A possible metadata flag is 'external, good luck'. :)
5962017-09-21T19:44:13 <jonasschnelli> X509
5972017-09-21T19:44:20 <sipa> JSONx!!
5982017-09-21T19:44:21 <ThomasV> lol
5992017-09-21T19:44:26 * jonasschnelli *ducks*
6002017-09-21T19:44:40 <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
6012017-09-21T19:44:49 <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.
6022017-09-21T19:44:57 <gmaxwell> :-)
6032017-09-21T19:45:10 <luke-jr> XD
6042017-09-21T19:45:20 <sipa> ok, other topics?
6052017-09-21T19:45:29 <wumpus> nice, though too easy to use, should be some ancient 8-bit assembly like z80 or 6502
6062017-09-21T19:46:08 <sipa> INTERCAL
6072017-09-21T19:46:13 <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
6082017-09-21T19:46:15 <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
6092017-09-21T19:46:16 <gmaxwell> I've had to use 6502 assembly in the last couple years ... (for a mystery hunt puzzle)
6102017-09-21T19:46:26 <wumpus> yeah
6112017-09-21T19:47:07 <wumpus> gmaxwell: did you still manage to? :)
6122017-09-21T19:47:08 <gmaxwell> other topics: did people see on the mailing list that there is a new Dandelion post?
6132017-09-21T19:47:16 <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?
6142017-09-21T19:47:38 <meshcollider> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
6152017-09-21T19:47:42 <wumpus> #topic Dandelion post
6162017-09-21T19:48:18 <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 :)
6172017-09-21T19:48:38 <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.
6182017-09-21T19:48:48 <gmaxwell> (and responsive)
6192017-09-21T19:49:40 <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
6202017-09-21T19:49:40 <wumpus> thanks for mentioning it, I indeed missed it
6212017-09-21T19:49:42 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
6222017-09-21T19:49:55 <wumpus> #link https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
6232017-09-21T19:50:12 * BlueMatt is curious how this interacts with the questions about mempool sync
6242017-09-21T19:50:20 <BlueMatt> though I havent read the dandelion stuff much
6252017-09-21T19:50:43 <wumpus> jnewbery: ok added
6262017-09-21T19:50:43 <gmaxwell> BlueMatt: externally to it. Basically it's a quiet forwarding thing that has little to no mempool interaction.
6272017-09-21T19:50:53 <jnewbery> wumpus: thanks!
6282017-09-21T19:50:58 <gmaxwell> BlueMatt: so that public distribution of transactions happens away from the source.
6292017-09-21T19:51:36 <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"
6302017-09-21T19:51:48 <BlueMatt> except they replace sync with "broadcast after a while"
6312017-09-21T19:52:07 <gmaxwell> BlueMatt: kind of. it's not in your mempool though when it passes through in the one at a time propagation.
6322017-09-21T19:52:35 <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)
6332017-09-21T19:52:57 <morcos> sipa: why not dandelion it again?
6342017-09-21T19:53:23 <BlueMatt> sipa: yes, I'm asking for comparison between dandelion and the old mempool-sync proposal of gmaxwell
6352017-09-21T19:53:34 <sipa> morcos: the dandelion stem isn't expected to reach the entire network
6362017-09-21T19:53:54 <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
6372017-09-21T19:53:56 <sipa> so you still need something outside of dandelion-forward and mempool reconciliation
6382017-09-21T19:54:00 <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.
6392017-09-21T19:54:33 *** promag has joined #bitcoin-core-dev
6402017-09-21T19:54:36 <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.
6412017-09-21T19:54:56 <sipa> BlueMatt: there seems to be some overlap, but i don't think dandelion+sync is a complete solution
6422017-09-21T19:55:07 <gmaxwell> so it is similar to my relay improvement proposal, but the privacy requirements mean that it doesn't accomplish syncing itself.
6432017-09-21T19:55:09 *** jtimon has joined #bitcoin-core-dev
6442017-09-21T19:55:12 <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
6452017-09-21T19:55:39 <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
6462017-09-21T19:55:44 <BlueMatt> maybe I should shut up and go read it
6472017-09-21T19:55:44 <sipa> morcos: the 'fluff' is just normal tx relay
6482017-09-21T19:55:48 <gmaxwell> BlueMatt: so it is like my relay bandwidth improving proposal, without improving relay bandwidth. :P
6492017-09-21T19:56:20 <BlueMatt> heh, yea, ok
6502017-09-21T19:56:28 <gmaxwell> BlueMatt: only if you are inside the stem yourself. (this was a change their latest work makes)
6512017-09-21T19:56:38 <BlueMatt> hmm, alright
6522017-09-21T19:57:24 <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.
6532017-09-21T19:57:49 <gmaxwell> basically related to the guardnodes problem in tor.
6542017-09-21T19:57:58 *** SopaXorzTaker has quit IRC
6552017-09-21T19:58:38 <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.
6562017-09-21T19:58:48 *** promag has quit IRC
6572017-09-21T19:59:49 *** timothy has joined #bitcoin-core-dev
6582017-09-21T20:00:01 <sipa> PLOINK
6592017-09-21T20:00:11 <wumpus> yes, extrememly important for privacy to not make any mistakes here
6602017-09-21T20:00:18 <wumpus> #endmeeting
6612017-09-21T20:00:18 <lightningbot> Meeting ended Thu Sep 21 20:00:18 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6622017-09-21T20:00:18 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.html
6632017-09-21T20:00:18 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.txt
6642017-09-21T20:00:18 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.log.html
6652017-09-21T20:00:37 <gmaxwell> wumpus: At least the current behavior is weak enough that it would be hard to not make an improvement. :)
6662017-09-21T20:00:50 <BlueMatt> hah, yea, that ^
6672017-09-21T20:02:24 <wumpus> sure
6682017-09-21T20:04:39 <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.
6692017-09-21T20:05:13 <wumpus> your new key is on the keyserver?
6702017-09-21T20:05:37 <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
6712017-09-21T20:05:50 <wumpus> apparently it is, refresh-key worked gpg: new subkeys: 1
6722017-09-21T20:06:02 <gmaxwell> wumpus: yes. as of about the beginning of the meeting.
6732017-09-21T20:06:18 <sipa> achow101: 0.2.9
6742017-09-21T20:08:03 <achow101> sipa: thanks
6752017-09-21T20:08:43 <wumpus> sipa: achow101: seems it's missing here https://bitcoin.org/en/developer-reference#protocol-versions
6762017-09-21T20:09:01 <achow101> wumpus: yeah, I noticed
6772017-09-21T20:09:03 <wumpus> only mentions adding the checksum field there
6782017-09-21T20:09:18 <achow101> I assume that's because that's all the commit message mentions too
6792017-09-21T20:09:19 <wumpus> please file a PR :)
6802017-09-21T20:10:06 <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
6812017-09-21T20:10:44 <wumpus> luke-jr: :-(
6822017-09-21T20:10:56 * luke-jr wonders if it's really only Skylake+
6832017-09-21T20:13:11 <BlueMatt> #11116 could probably use a merge
6842017-09-21T20: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
6852017-09-21T20:13:14 *** SopaXorzTaker has joined #bitcoin-core-dev
6862017-09-21T20:15:17 *** RubenSomsen has quit IRC
6872017-09-21T20:16:10 *** timothy has quit IRC
6882017-09-21T20:16:46 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/98212745c8ac...49f3d57eeb66
6892017-09-21T20:16:47 <bitcoin-git> bitcoin/master d7afe2d Jim Posen: [script] Unit tests for script/standard functions
6902017-09-21T20:16:47 <bitcoin-git> bitcoin/master 7a1e873 Jim Posen: [script] Unit tests for IsMine...
6912017-09-21T20:16:48 <bitcoin-git> bitcoin/master 49f3d57 Wladimir J. van der Laan: Merge #11116: [script] Unit tests for script/standard and IsMine functions....
6922017-09-21T20:17:23 <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
6932017-09-21T20:21:06 *** Miezel has quit IRC
6942017-09-21T20:25:57 *** Chris_Stewart_5 has quit IRC
6952017-09-21T20:31:26 *** Guyver2 has quit IRC
6962017-09-21T20:46:30 *** promag has joined #bitcoin-core-dev
6972017-09-21T20:50:28 *** promag has quit IRC
6982017-09-21T21:20:46 *** ThomasV has quit IRC
6992017-09-21T21:22:16 *** promag has joined #bitcoin-core-dev
7002017-09-21T21:26:53 *** alxlu has quit IRC
7012017-09-21T21:30:05 *** Miezel has joined #bitcoin-core-dev
7022017-09-21T21:32:06 *** promag has quit IRC
7032017-09-21T21:36:01 *** Miezel has joined #bitcoin-core-dev
7042017-09-21T21:36:41 *** promag has joined #bitcoin-core-dev
7052017-09-21T21:40:19 <promag> wumpus: jnewbery: is there a strong reason to #10740 have high priority review?
7062017-09-21T21:40:21 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
7072017-09-21T21:42:31 <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.
7082017-09-21T21:44:15 <luke-jr> #10615 and GUI support should go before 10740..
7092017-09-21T21:44:16 <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
7102017-09-21T21:44:24 *** duringo has joined #bitcoin-core-dev
7112017-09-21T21:44:58 <luke-jr> far more important to be able to actually use it, than dynamic open/close
7122017-09-21T21:45:27 *** NicolasDorier has quit IRC
7132017-09-21T21:45:27 *** rodarmor has quit IRC
7142017-09-21T21:46:00 *** trotski2000 has quit IRC
7152017-09-21T21:46:15 <promag> luke-jr: no PR for GUI support right?
7162017-09-21T21:46:33 *** btcdrak has quit IRC
7172017-09-21T21:46:33 *** jl2012 has quit IRC
7182017-09-21T21:47:06 *** chainhead has quit IRC
7192017-09-21T21:47:39 *** Lightsword has quit IRC
7202017-09-21T21:48:02 *** spinza has quit IRC
7212017-09-21T21:48:12 *** Muis has quit IRC
7222017-09-21T21:48:12 *** xHire has quit IRC
7232017-09-21T21:48:12 *** pindarhk_ has quit IRC
7242017-09-21T21:48:16 *** trotski2000 has joined #bitcoin-core-dev
7252017-09-21T21:49:37 *** intcat has quit IRC
7262017-09-21T21:49:54 *** pindarhk_ has joined #bitcoin-core-dev
7272017-09-21T21:50:05 *** xHire has joined #bitcoin-core-dev
7282017-09-21T21:50:12 <luke-jr> promag: no, because it's built on top of 10615
7292017-09-21T21:50:12 *** LeMiner has quit IRC
7302017-09-21T21:50:33 *** intcat has joined #bitcoin-core-dev
7312017-09-21T21:50:36 <luke-jr> promag: the branch is named multiwallet_gui
7322017-09-21T21:50:57 <promag> mind I take a look?
7332017-09-21T21:51:18 *** Muis has joined #bitcoin-core-dev
7342017-09-21T21:53:30 *** chainhead has joined #bitcoin-core-dev
7352017-09-21T21:54:18 <promag> so the concept is to have a combobox to choose the wallet in the mainwindow?
7362017-09-21T21:54:28 *** Lightsword has joined #bitcoin-core-dev
7372017-09-21T21:54:42 <luke-jr> promag: yes, it works pretty well
7382017-09-21T21:55:40 <luke-jr> been shipping it in Knots since 0.13 ;)
7392017-09-21T21:56:40 <luke-jr> maybe I should open a PR so it at least has that
7402017-09-21T21:56:44 <promag> does it restores the current wallet when it starts?
7412017-09-21T21:56:53 <luke-jr> promag: no
7422017-09-21T21:57:20 <luke-jr> maybe it should
7432017-09-21T21:57:36 <promag> yeah, like the geometry stuff
7442017-09-21T21:57:43 *** Miezel has quit IRC
7452017-09-21T21:59:32 *** duringo_ has joined #bitcoin-core-dev
7462017-09-21T21:59:32 *** duringo has quit IRC
7472017-09-21T22:00:50 *** rodarmor has joined #bitcoin-core-dev
7482017-09-21T22:00:52 *** NicolasDorier has joined #bitcoin-core-dev
7492017-09-21T22:05:52 *** promag has quit IRC
7502017-09-21T22:06:46 *** promag has joined #bitcoin-core-dev
7512017-09-21T22:07:54 *** promag_ has joined #bitcoin-core-dev
7522017-09-21T22:07:54 *** promag has quit IRC
7532017-09-21T22:08:57 <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)
7542017-09-21T22:09:24 <bitcoin-git> [bitcoin] luke-jr opened pull request #11383: Basic Multiwallet GUI support (master...multiwallet_gui) https://github.com/bitcoin/bitcoin/pull/11383
7552017-09-21T22:09:46 *** promag_ has quit IRC
7562017-09-21T22:09:57 *** promag has joined #bitcoin-core-dev
7572017-09-21T22:10:24 *** spinza has joined #bitcoin-core-dev
7582017-09-21T22:11:48 *** promag has quit IRC
7592017-09-21T22:12:02 *** promag has joined #bitcoin-core-dev
7602017-09-21T22:12:05 <promag> nowadays apps usually restore the state
7612017-09-21T22:12:11 <promag> "you continue where you left"
7622017-09-21T22:12:42 <promag> tks for the PR
7632017-09-21T22:13:03 *** veleiro has left #bitcoin-core-dev
7642017-09-21T22:13:09 <promag> we can explore that idea later
7652017-09-21T22:20:09 *** duringo__ has joined #bitcoin-core-dev
7662017-09-21T22:22:02 *** Cheeseo has joined #bitcoin-core-dev
7672017-09-21T22:23:48 *** duringo_ has quit IRC
7682017-09-21T22:42:18 *** Giszmo has quit IRC
7692017-09-21T22:44:21 *** duringo___ has joined #bitcoin-core-dev
7702017-09-21T22:48:00 *** duringo__ has quit IRC
7712017-09-21T22:50:35 *** Cheeseo has quit IRC
7722017-09-21T23:03:22 *** Giszmo has joined #bitcoin-core-dev
7732017-09-21T23:12:58 *** SopaXorzTaker has quit IRC
7742017-09-21T23:31:37 *** Miezel has joined #bitcoin-core-dev
7752017-09-21T23:33:01 *** vicenteH has quit IRC
7762017-09-21T23:34:53 *** RubenSomsen has joined #bitcoin-core-dev
7772017-09-21T23:42:29 *** justanotheruser has joined #bitcoin-core-dev
7782017-09-21T23:46:17 *** sdfgsdfg has joined #bitcoin-core-dev
7792017-09-21T23:46:24 *** jl2012 has joined #bitcoin-core-dev
7802017-09-21T23:46:52 *** btcdrak has joined #bitcoin-core-dev
7812017-09-21T23:49:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
7822017-09-21T23:50:10 *** justanotheruser has quit IRC
7832017-09-21T23:55:39 *** seone has quit IRC