12018-01-30T00:03:27 *** RubenSomsen has quit IRC
22018-01-30T00:05:40 *** Randolf has joined #bitcoin-core-dev
32018-01-30T00:06:42 *** Randolf has quit IRC
42018-01-30T00:12:05 *** capa66 has quit IRC
52018-01-30T00:35:01 <bitcoin-git> [bitcoin] promag opened pull request #12299: Improve CWallet::IsFromMe for positive results (master...2018-01-isfromme) https://github.com/bitcoin/bitcoin/pull/12299
62018-01-30T00:38:51 *** Emcy has joined #bitcoin-core-dev
72018-01-30T00:41:05 *** Emcy_ has quit IRC
82018-01-30T00:51:03 *** Giszmo has quit IRC
92018-01-30T00:56:52 *** Giszmo has joined #bitcoin-core-dev
102018-01-30T01:00:59 *** promag has quit IRC
112018-01-30T01:07:54 *** belcher has quit IRC
122018-01-30T01:09:01 *** Scrat has joined #bitcoin-core-dev
132018-01-30T01:15:18 *** Giszmo has quit IRC
142018-01-30T01:21:07 *** tryphe_ has joined #bitcoin-core-dev
152018-01-30T01:24:21 *** tryphe has quit IRC
162018-01-30T01:26:33 *** Randolf has joined #bitcoin-core-dev
172018-01-30T01:27:23 *** tryphe_ is now known as tryphe
182018-01-30T01:31:33 *** promag has joined #bitcoin-core-dev
192018-01-30T01:33:39 *** Scrat has quit IRC
202018-01-30T01:36:33 *** promag has quit IRC
212018-01-30T01:38:04 *** esotericnonsense has joined #bitcoin-core-dev
222018-01-30T01:51:23 <bitcoin-git> [bitcoin] jeffrade opened pull request #12300: [Tests] Adding --enable-mainnet configuration option for ChainParams (master...mainnet_chain_config) https://github.com/bitcoin/bitcoin/pull/12300
232018-01-30T01:53:53 *** Giszmo has joined #bitcoin-core-dev
242018-01-30T02:20:40 *** Lynet has quit IRC
252018-01-30T02:37:10 *** Murch has quit IRC
262018-01-30T02:41:17 *** RubenSomsen has joined #bitcoin-core-dev
272018-01-30T02:42:56 *** bear_ has joined #bitcoin-core-dev
282018-01-30T02:50:10 *** RubenSomsen has quit IRC
292018-01-30T03:11:14 *** dx25 has quit IRC
302018-01-30T03:16:15 *** dx25 has joined #bitcoin-core-dev
312018-01-30T03:16:44 *** achow101 has quit IRC
322018-01-30T03:20:11 *** jeffrade has joined #bitcoin-core-dev
332018-01-30T03:22:46 *** flokie has quit IRC
342018-01-30T03:23:34 *** flokie has joined #bitcoin-core-dev
352018-01-30T03:30:53 *** jamesob has joined #bitcoin-core-dev
362018-01-30T03:31:28 *** achow101 has joined #bitcoin-core-dev
372018-01-30T03:35:40 *** james has joined #bitcoin-core-dev
382018-01-30T03:36:03 *** james is now known as Guest16656
392018-01-30T03:37:56 <jeffrade> fyi, for PR #12300 - will work on requested changes and push commit within 24 - 48 hours
402018-01-30T03:37:58 <gribble> https://github.com/bitcoin/bitcoin/issues/12300 | [Tests] Adding --enable-mainnet configuration option for ChainParams by jeffrade · Pull Request #12300 · bitcoin/bitcoin · GitHub
412018-01-30T03:38:28 *** jeffrade has quit IRC
422018-01-30T03:41:07 *** tryphe has quit IRC
432018-01-30T03:41:50 *** tryphe has joined #bitcoin-core-dev
442018-01-30T03:42:20 *** achow101 has quit IRC
452018-01-30T03:44:49 *** tryphe_ has joined #bitcoin-core-dev
462018-01-30T03:45:23 *** booyah has quit IRC
472018-01-30T03:46:13 *** booyah has joined #bitcoin-core-dev
482018-01-30T03:47:27 *** tryphe has quit IRC
492018-01-30T03:54:56 *** achow101 has joined #bitcoin-core-dev
502018-01-30T04:08:58 *** tryphe_ is now known as tryphe
512018-01-30T04:50:52 *** Krellan has quit IRC
522018-01-30T04:51:23 *** Krellan has joined #bitcoin-core-dev
532018-01-30T04:55:48 *** Krellan has quit IRC
542018-01-30T04:57:49 *** bajohns has joined #bitcoin-core-dev
552018-01-30T05:09:54 *** jtimon has quit IRC
562018-01-30T05:10:19 *** arbitrary_guy has quit IRC
572018-01-30T05:15:50 *** Guest16656 has quit IRC
582018-01-30T05:15:55 *** Murch has joined #bitcoin-core-dev
592018-01-30T05:16:15 *** jamesob has quit IRC
602018-01-30T05:37:26 *** Giszmo has quit IRC
612018-01-30T05:39:38 *** mrannanay has joined #bitcoin-core-dev
622018-01-30T05:44:51 *** To7 has quit IRC
632018-01-30T05:46:23 *** Emcy_ has joined #bitcoin-core-dev
642018-01-30T05:47:45 *** indistylo has joined #bitcoin-core-dev
652018-01-30T05:49:21 *** Emcy has quit IRC
662018-01-30T05:52:01 *** Emcy has joined #bitcoin-core-dev
672018-01-30T05:54:38 *** Emcy_ has quit IRC
682018-01-30T06:12:17 *** jogi has joined #bitcoin-core-dev
692018-01-30T06:13:20 *** jogi has quit IRC
702018-01-30T06:25:56 *** jb55 has quit IRC
712018-01-30T06:29:22 *** promag has joined #bitcoin-core-dev
722018-01-30T06:33:15 *** checksauce has joined #bitcoin-core-dev
732018-01-30T06:34:35 *** promag has quit IRC
742018-01-30T06:35:57 *** Sentineo has quit IRC
752018-01-30T06:48:48 *** flokie has quit IRC
762018-01-30T06:49:30 *** Krellan_ has joined #bitcoin-core-dev
772018-01-30T06:53:48 *** Krellan_ has quit IRC
782018-01-30T07:16:29 *** Murch has joined #bitcoin-core-dev
792018-01-30T07:42:17 *** d_t has joined #bitcoin-core-dev
802018-01-30T07:51:47 *** d_t has quit IRC
812018-01-30T07:54:15 *** Krellan has joined #bitcoin-core-dev
822018-01-30T07:54:46 *** Krellan has joined #bitcoin-core-dev
832018-01-30T07:55:12 *** promag has joined #bitcoin-core-dev
842018-01-30T07:57:38 *** Krellan has quit IRC
852018-01-30T07:59:51 *** promag has quit IRC
862018-01-30T08:00:47 *** Krellan has joined #bitcoin-core-dev
872018-01-30T08:02:10 *** booyah has quit IRC
882018-01-30T08:03:20 *** booyah has joined #bitcoin-core-dev
892018-01-30T08:06:25 *** indistylo has quit IRC
902018-01-30T08:08:54 *** Murch has quit IRC
912018-01-30T08:13:04 *** Sinclai__ has quit IRC
922018-01-30T08:14:53 *** Sinclair6 has joined #bitcoin-core-dev
932018-01-30T08:23:40 *** atroxes has quit IRC
942018-01-30T08:25:09 *** atroxes has joined #bitcoin-core-dev
952018-01-30T08:33:58 *** Pavle has joined #bitcoin-core-dev
962018-01-30T08:38:19 *** dermoth has joined #bitcoin-core-dev
972018-01-30T08:57:25 *** dabura667 has joined #bitcoin-core-dev
982018-01-30T08:58:10 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d9c4185fada...7cf1aea5cfcc
992018-01-30T08:58:11 <bitcoin-git> bitcoin/master 336685e Randolf Richardson: [build] Add db4_cxx to bitcoin_find_bdb48.m4...
1002018-01-30T08:58:11 <bitcoin-git> bitcoin/master 1944fa3 Randolf Richardson: [doc] Create build-netbsd.md
1012018-01-30T08:58:12 <bitcoin-git> bitcoin/master 11c5827 fanquake: [build] Add NETBSD leveldb target to configure.ac
1022018-01-30T08:59:10 <bitcoin-git> [bitcoin] laanwj closed pull request #12294: [Docs] Create NetBSD build instructions and fix compilation (master...netbsd-build-docs) https://github.com/bitcoin/bitcoin/pull/12294
1032018-01-30T08:59:54 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7cf1aea5cfcc...288deacdbe08
1042018-01-30T08:59:54 <bitcoin-git> bitcoin/master ee11121 MeshCollider: Add special error for genesis coinbase to gettransaction
1052018-01-30T08:59:55 <bitcoin-git> bitcoin/master 288deac Wladimir J. van der Laan: Merge #12278: Add special error for genesis coinbase to getrawtransaction...
1062018-01-30T09:00:49 <bitcoin-git> [bitcoin] laanwj closed pull request #12278: Add special error for genesis coinbase to getrawtransaction (master...201801_genesis_gettransaction_error) https://github.com/bitcoin/bitcoin/pull/12278
1072018-01-30T09:14:30 *** jtimon has joined #bitcoin-core-dev
1082018-01-30T09:17:20 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/288deacdbe08...7936446268e2
1092018-01-30T09:17:20 <bitcoin-git> bitcoin/master 039425c João Barbosa: [wallet] Remove duplicate mapWallet lookups
1102018-01-30T09:17:21 <bitcoin-git> bitcoin/master 7936446 Wladimir J. van der Laan: Merge #12276: Remove duplicate mapWallet lookups...
1112018-01-30T09:18:10 <bitcoin-git> [bitcoin] laanwj closed pull request #12276: Remove duplicate mapWallet lookups (master...2018-01-mapwallet) https://github.com/bitcoin/bitcoin/pull/12276
1122018-01-30T09:25:25 *** promag has joined #bitcoin-core-dev
1132018-01-30T09:25:58 *** indistylo has joined #bitcoin-core-dev
1142018-01-30T09:30:38 *** aruns has joined #bitcoin-core-dev
1152018-01-30T09:30:50 <promag> wumpus: be sure to check #12299
1162018-01-30T09:30:52 <gribble> https://github.com/bitcoin/bitcoin/issues/12299 | Improve CWallet::IsFromMe for positive results by promag · Pull Request #12299 · bitcoin/bitcoin · GitHub
1172018-01-30T09:31:38 *** Aaronvan_ has joined #bitcoin-core-dev
1182018-01-30T09:31:45 *** indistylo has quit IRC
1192018-01-30T09:34:47 *** checksau_ has joined #bitcoin-core-dev
1202018-01-30T09:37:37 *** checksauce has quit IRC
1212018-01-30T09:40:36 <gmaxwell> promag: does that actually make a measurable difference? I would assume very few transactions are fromme, so the early termination would never fire.
1222018-01-30T09:40:55 <gmaxwell> I'd expect a lot bigger gain from things like hoisting the locking cs_wallet out of the inner loop or similar.
1232018-01-30T09:43:47 <promag> GetDebit(tx) is called from a lot of places
1242018-01-30T09:43:53 <promag> it also avoid unnecessary IsMine calls
1252018-01-30T09:43:58 <promag> not saying it's a big performance improvement
1262018-01-30T09:44:02 <promag> regarding locks, IMO only after 0.16 is branched
1272018-01-30T09:44:23 <wumpus> we really need benchmarking for wallet things
1282018-01-30T09:44:43 <wumpus> without that, these kind of changes are really hard to evaluate, whether it's worth complicating the code more
1292018-01-30T09:45:30 <promag> anyway, in that case, I'd say it's a pretty obvious improvement
1302018-01-30T09:46:34 <gmaxwell> I don't agree. It turns one line of simple code into five lines of less clear code. I don't think it's bad, but if its not actually faster for any realistic case, why would we want it?
1312018-01-30T09:47:35 <gmaxwell> maybe it is-- e.g. perhaps we call IsFromMe on masses of wallet txn all the time, where its true on the first input... but I'm not aware of that.
1322018-01-30T09:48:08 <gmaxwell> Certantly to the extent that the function is run on transactions in the chain the early termination won't make it faster-- I doubt it would make it slower either, but not faster.
1332018-01-30T09:48:30 <promag> gmaxwell: I think the semantic of IsFromMe it better explained in that pr
1342018-01-30T09:48:57 <promag> "if from me if at least one input is debit"
1352018-01-30T09:49:05 <promag> s/if/is
1362018-01-30T09:49:59 <gmaxwell> I know what the semantics of the functions are. But early termination is not a win for a function where 99.999% of the time it will never fire, it can even be a performance loss (though I am not saying I expect that here).
1372018-01-30T09:50:02 <promag> also, for big wallets, with thousands of transactions, thousands of keys, avoiding IsMine is important
1382018-01-30T09:50:43 <gmaxwell> I'm only commenting on the IsFromMe early termination.
1392018-01-30T09:50:44 <promag> gmaxwell: sure, for the worst case the performance is the same (although it avoids summing)
1402018-01-30T09:50:58 <promag> also not sure about the average case
1412018-01-30T09:51:22 <gmaxwell> And, as far as I know, for the average case. If not, we're probably calling it where we shouldn't be at all.
1422018-01-30T09:52:26 *** Pavle has quit IRC
1432018-01-30T09:52:27 <promag> gmaxwell: I'll try to measure it
1442018-01-30T09:52:40 <promag> gmaxwell: care to see #12297
1452018-01-30T09:52:41 <gribble> https://github.com/bitcoin/bitcoin/issues/12297 | Improve CWallet::IsAllFromMe for false results by promag · Pull Request #12297 · bitcoin/bitcoin · GitHub
1462018-01-30T09:56:22 <promag> brb
1472018-01-30T09:56:59 <gmaxwell> (at least off the top of my head I only know that function being called on all blockchain/relay txn, where it'll return false almost all the time for even the largest users. I think we also call it on some unconfirmed stuff.)
1482018-01-30T09:57:03 <gmaxwell> ha
1492018-01-30T09:57:15 <gmaxwell> see this is silly, for example:
1502018-01-30T09:57:16 <gmaxwell> int nDepth = pcoin->GetDepthInMainChain();
1512018-01-30T09:57:16 <gmaxwell> if (nDepth < (pcoin->IsFromMe(ISMINE_ALL) ? 0 : 1))
1522018-01-30T09:57:16 <gmaxwell> continue;
1532018-01-30T09:58:43 *** promag has quit IRC
1542018-01-30T09:59:28 <gmaxwell> so it looks like there are a couple other places it's called, but none strike me as that interesting at a glance, though some could be optimized.
1552018-01-30T10:00:42 <gmaxwell> (actually that code looks redundant with the efficient IsTrusted check above)
1562018-01-30T10:04:53 <gmaxwell> but don't listen to me, I should be asleep. :)
1572018-01-30T10:15:41 *** Krellan has quit IRC
1582018-01-30T10:18:15 *** aruns has quit IRC
1592018-01-30T10:18:40 *** aruns has joined #bitcoin-core-dev
1602018-01-30T10:20:41 *** Krellan has joined #bitcoin-core-dev
1612018-01-30T10:24:48 *** Krellan has quit IRC
1622018-01-30T10:25:42 *** Krellan has joined #bitcoin-core-dev
1632018-01-30T10:30:08 *** Krellan has quit IRC
1642018-01-30T10:30:43 *** Krellan has joined #bitcoin-core-dev
1652018-01-30T10:32:48 *** ghost43 has quit IRC
1662018-01-30T10:33:23 *** dabura667 has quit IRC
1672018-01-30T10:33:48 *** Sentineo has joined #bitcoin-core-dev
1682018-01-30T10:34:48 *** Krellan has quit IRC
1692018-01-30T10:35:44 *** Krellan has joined #bitcoin-core-dev
1702018-01-30T10:38:59 *** ghost43 has joined #bitcoin-core-dev
1712018-01-30T10:39:57 *** Krellan has quit IRC
1722018-01-30T10:40:45 *** Krellan has joined #bitcoin-core-dev
1732018-01-30T10:44:48 *** Krellan has quit IRC
1742018-01-30T10:45:45 *** dabura667 has joined #bitcoin-core-dev
1752018-01-30T10:45:46 *** Krellan has joined #bitcoin-core-dev
1762018-01-30T10:54:55 *** jtimon has quit IRC
1772018-01-30T10:55:16 <wumpus> need review for https://github.com/bitcoin/bitcoin/pull/12266 https://github.com/bitcoin/bitcoin/pull/12274
1782018-01-30T10:55:25 <wumpus> otherhwise I'm going to branch off 0.16 without them
1792018-01-30T10:58:03 *** dx25 has quit IRC
1802018-01-30T11:00:23 *** Aaronvan_ has quit IRC
1812018-01-30T11:00:59 *** AaronvanW has joined #bitcoin-core-dev
1822018-01-30T11:02:41 *** dx25 has joined #bitcoin-core-dev
1832018-01-30T11:05:15 *** AaronvanW has quit IRC
1842018-01-30T11:08:54 *** larafale has joined #bitcoin-core-dev
1852018-01-30T11:11:08 <meshcollider> I'd like to review the fd one to help but its beyond my skill level I'm afraid
1862018-01-30T11:12:18 <wumpus> you're not alone in that
1872018-01-30T11:12:21 <wumpus> I'm confused by it too
1882018-01-30T11:12:46 <wumpus> please do review BlueMatt's though
1892018-01-30T11:13:02 <wumpus> that one is not so hard to grasp as I thought initially
1902018-01-30T11:13:27 <wumpus> oh you did!
1912018-01-30T11:13:28 <wumpus> thanks
1922018-01-30T11:19:23 <gmaxwell> ut-sleepy-ACK from me, I'll try to setup some kind of shutdown loop to test it.
1932018-01-30T11:20:08 <gmaxwell> I'd bias toward including since we have known easily triggered shutdown deadlock, if users report that on rc1 without this we learn nothing, if they report it or a shutdown crash on an rc1 with this we learn something.
1942018-01-30T11:21:07 <wumpus> yes I'd also vote for including #12266, but I think it's quite harmless to hold up on #12274 for now
1952018-01-30T11:21:09 <gribble> https://github.com/bitcoin/bitcoin/issues/12266 | Move scheduler/threadGroup into common-init instead of per-app by TheBlueMatt · Pull Request #12266 · bitcoin/bitcoin · GitHub
1962018-01-30T11:21:11 <gribble> https://github.com/bitcoin/bitcoin/issues/12274 | http: avoid fd exhaustion by theuni · Pull Request #12274 · bitcoin/bitcoin · GitHub
1972018-01-30T11:21:37 <wumpus> it's a lot of logic to work around an upstream issue, and according to test reports there it doesn't even fully solve the issue yet
1982018-01-30T11:21:51 *** ghost43 has quit IRC
1992018-01-30T11:22:06 <wumpus> also it's regression in 0.15 and it only comes up under rare conditions
2002018-01-30T11:22:36 <gmaxwell> when I looked at the limiter I had questions about concurrency of the limiter function and didn't know where to start looking.
2012018-01-30T11:22:38 *** ghost43 has joined #bitcoin-core-dev
2022018-01-30T11:22:38 <wumpus> sorry I mean it's *not* regression in 0.16
2032018-01-30T11:23:18 <wumpus> it's an issue that has existed since we started using libevent for http, and very hard to trigger
2042018-01-30T11:23:56 <wumpus> I don't mean it should not be solved, but I wonder if we shouldn't take a higher level approach and try to fix upstream, instead of hack on hack on hack :(
2052018-01-30T11:23:57 <gmaxwell> right. we could also cut down our FD usage in some other way to give it more safty margin, I suppose?
2062018-01-30T11:25:04 <gmaxwell> e.g. raise MIN_CORE_FILEDESCRIPTORS
2072018-01-30T11:25:11 <wumpus> right - maybe the accounting of fds (how much is reserved for what) is also incorrect
2082018-01-30T11:25:30 <wumpus> anyhow I think this is a post-0.16 issue
2092018-01-30T11:28:58 *** wxss has joined #bitcoin-core-dev
2102018-01-30T11:31:14 *** promag has joined #bitcoin-core-dev
2112018-01-30T11:34:40 <wumpus> milestone 0.16.1 has the fd changes now: https://github.com/bitcoin/bitcoin/milestone/34
2122018-01-30T11:45:39 *** dabura667 has quit IRC
2132018-01-30T12:03:42 *** ghost43 has quit IRC
2142018-01-30T12:04:57 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7936446268e2...3448907a68e0
2152018-01-30T12:04:58 <bitcoin-git> bitcoin/master 082a61c Matt Corallo: Move scheduler/threadGroup into common-init instead of per-app...
2162018-01-30T12:04:58 <bitcoin-git> bitcoin/master 3448907 Wladimir J. van der Laan: Merge #12266: Move scheduler/threadGroup into common-init instead of per-app...
2172018-01-30T12:05:42 <bitcoin-git> [bitcoin] laanwj closed pull request #12266: Move scheduler/threadGroup into common-init instead of per-app (master...2018-01-common-init) https://github.com/bitcoin/bitcoin/pull/12266
2182018-01-30T12:06:10 *** ghost43 has joined #bitcoin-core-dev
2192018-01-30T12:12:39 *** checksau_ has quit IRC
2202018-01-30T12:13:50 <meshcollider> wumpus: so branch and tag 0.16 now then?
2212018-01-30T12:13:56 <meshcollider> Is there anything else left to do
2222018-01-30T12:15:08 <meshcollider> Oh, have you done the manpages update thing
2232018-01-30T12:15:34 *** capa66 has joined #bitcoin-core-dev
2242018-01-30T12:21:54 <wumpus> meshcollider: that needs to be done after the branch, after bumping version, before tagging
2252018-01-30T12:23:13 <wumpus> but yes I intend to branch now
2262018-01-30T12:23:37 <meshcollider> ooh ok yep
2272018-01-30T12:23:40 <meshcollider> \o/
2282018-01-30T12:25:37 *** aruns__ has joined #bitcoin-core-dev
2292018-01-30T12:27:33 *** Guyver2 has joined #bitcoin-core-dev
2302018-01-30T12:28:28 *** aruns has quit IRC
2312018-01-30T12:44:34 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/10847fe2d82bd4ffe5be499fd9ad64b6fee78a33
2322018-01-30T12:44:34 <bitcoin-git> bitcoin/master 10847fe Wladimir J. van der Laan: qt: Periodic translations update...
2332018-01-30T12:49:37 *** xabbix has joined #bitcoin-core-dev
2342018-01-30T12:51:20 <xabbix> Can someone please explain how the mempool is filled for a new node and relayed? If I just finished syncing up my node, is it possible that I'll get a tx into my mempool that was sent a week ago (and still haven't confirmed)? Does my node request the mempool from the 8 peers it is connected to? Or does it just start collecting what is relayed to it from the point it was launched?
2352018-01-30T12:52:37 <gmaxwell> xabbix: the last thing.
2362018-01-30T12:53:49 <xabbix> gmaxwell: thanks, are there cases that a new node will get an 'old' transaction? what are those cases?
2372018-01-30T12:54:01 <wumpus> it will start collecting transactuins once it leaves initial sync. Normally these are new transactions, though there's nothing preventing people from re-relaying old transactions.
2382018-01-30T12:54:05 <gmaxwell> someone relays it.
2392018-01-30T12:54:21 <gmaxwell> the sender and reciever of the txn will rebroadcast every once in a while, normally...
2402018-01-30T12:54:47 <gmaxwell> and random other people might do so for whatever reasons they feel like.
2412018-01-30T12:54:53 <xabbix> gmaxwell, wumpus: ok, that makes a lot more sense now. thanks.
2422018-01-30T12:55:07 <gmaxwell> it won't cross peers that already have it, however.
2432018-01-30T12:56:19 *** promag has quit IRC
2442018-01-30T12:57:32 <xabbix> As I understand from an answer that jnewbery wrote to me a few days ago, the `time` value in the mempool is saved and relayed by other nodes, so even though my node is 'new' I can get txs with `time` values of before I ever started my node, but the `height` value is not stored and therefore not very reliable. Is there an easy way of calculating what the block height was at a certain time?
2452018-01-30T12:58:24 <gmaxwell> it's not relayed.
2462018-01-30T12:58:47 <xabbix> it's = height?
2472018-01-30T12:58:52 <wumpus> transactions generated by modern wallets will usually be time-locked to the current (or current-1) block
2482018-01-30T12:59:49 <gmaxwell> xabbix: no time value is relayed.
2492018-01-30T13:00:13 <wumpus> if you really want to compute the height at a certain time there's no efficient way to do that because block times are not strictly increasing and also not accurate
2502018-01-30T13:01:00 <wumpus> (the latter making it impossible to know for sure)
2512018-01-30T13:03:05 <gmaxwell> xabbix: if you were asking about why you had times before your startup time, that would be because the mempool and its timestamps are saved across restarts.
2522018-01-30T13:03:11 <gmaxwell> The heights (IIRC) are not.
2532018-01-30T13:04:00 *** intcat has quit IRC
2542018-01-30T13:04:17 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/10847fe2d82b...8d573198638e
2552018-01-30T13:04:17 <bitcoin-git> bitcoin/master 125f4a4 Anthony Towns: [tests] Require all tests to follow naming convention
2562018-01-30T13:04:18 <bitcoin-git> bitcoin/master 8d57319 MarcoFalke: Merge #12252: Require all tests to follow naming convention...
2572018-01-30T13:04:59 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12252: Require all tests to follow naming convention (master...rename_tests_no_leeway) https://github.com/bitcoin/bitcoin/pull/12252
2582018-01-30T13:05:24 <xabbix> gmaxwell: that means that I should not at any circumstances have a `time` value of two weeks ago if I installed bitcoin-core today?
2592018-01-30T13:05:42 <xabbix> given my machine clock is set correctly :)
2602018-01-30T13:06:57 *** goatpig has joined #bitcoin-core-dev
2612018-01-30T13:07:04 *** intcat has joined #bitcoin-core-dev
2622018-01-30T13:07:59 <bitcoin-git> [bitcoin] laanwj created 0.16 (+2 new commits): https://github.com/bitcoin/bitcoin/compare/5c242b211eda^...66bc647e8c65
2632018-01-30T13:07:59 <bitcoin-git> bitcoin/0.16 5c242b2 Wladimir J. van der Laan: build: bump version to 0.16.0...
2642018-01-30T13:08:00 <bitcoin-git> bitcoin/0.16 66bc647 Wladimir J. van der Laan: doc: Update manpages to 0.16.0...
2652018-01-30T13:08:27 <gmaxwell> xabbix: why do you think it was two weeks ago?
2662018-01-30T13:09:10 <xabbix> I think that I saw a `time` value when I queried getmempoolentry that is before I created the machine I was running on.
2672018-01-30T13:09:21 <xabbix> I'm not 100% sure just trying to figure out if that's possible.
2682018-01-30T13:09:31 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/4602dc704ae83bd08d0d6e835b760cc9ab8fea37
2692018-01-30T13:09:32 <bitcoin-git> bitcoin/master 4602dc7 Wladimir J. van der Laan: build: Bump version to 0.16.99...
2702018-01-30T13:10:03 <wumpus> I guess that should not be possible, at least if you didn't install a mempool.dat somehow
2712018-01-30T13:11:11 <gmaxwell> I don't think it's possible, the only places in the code that is set is with the output of GetTime() (gets the current time) and when reading it from the mempool.dat file.
2722018-01-30T13:11:27 <gmaxwell> if you had an older mempool.dat or something then that would do it.
2732018-01-30T13:12:48 <wumpus> is it perhaps an ARM board without realtime clock? I've seen times all over the place with those, if they fail the ntpdate at startup
2742018-01-30T13:13:32 *** Krellan has quit IRC
2752018-01-30T13:14:00 *** xabbix has quit IRC
2762018-01-30T13:16:20 *** Krellan has joined #bitcoin-core-dev
2772018-01-30T13:20:38 *** Krellan has quit IRC
2782018-01-30T13:21:21 *** Krellan has joined #bitcoin-core-dev
2792018-01-30T13:23:55 *** To7 has joined #bitcoin-core-dev
2802018-01-30T13:25:38 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/9cb2309050880c2887b4b5f7a7231e4fc6dc3f47
2812018-01-30T13:25:39 <bitcoin-git> bitcoin/master 9cb2309 Wladimir J. van der Laan: doc: Update manpages to 0.16.99...
2822018-01-30T13:25:48 *** Krellan has quit IRC
2832018-01-30T13:29:03 <wumpus> going to tag 0.16.0rc1 in a bit on the 0.16 branch
2842018-01-30T13:29:29 *** indistylo has joined #bitcoin-core-dev
2852018-01-30T13:30:37 *** indistylo has quit IRC
2862018-01-30T13:30:41 *** aruns__ has quit IRC
2872018-01-30T13:31:06 *** aruns__ has joined #bitcoin-core-dev
2882018-01-30T13:31:23 *** Krellan has joined #bitcoin-core-dev
2892018-01-30T13:34:47 <wumpus> * [new tag] v0.16.0rc1 -> v0.16.0rc1
2902018-01-30T13:35:48 *** Krellan has quit IRC
2912018-01-30T13:36:25 *** Krellan has joined #bitcoin-core-dev
2922018-01-30T13:37:20 *** indistylo has joined #bitcoin-core-dev
2932018-01-30T13:40:48 *** Krellan has quit IRC
2942018-01-30T13:41:26 *** Krellan has joined #bitcoin-core-dev
2952018-01-30T13:45:07 <jnewbery> \o/
2962018-01-30T13:45:48 *** Krellan has quit IRC
2972018-01-30T13:46:26 *** Krellan has joined #bitcoin-core-dev
2982018-01-30T13:50:42 *** Krellan has quit IRC
2992018-01-30T13:51:28 *** Krellan has joined #bitcoin-core-dev
3002018-01-30T13:51:45 *** jamesob has joined #bitcoin-core-dev
3012018-01-30T13:52:37 *** bajohns has quit IRC
3022018-01-30T13:54:21 *** Emcy_ has joined #bitcoin-core-dev
3032018-01-30T13:55:43 *** Emcy has quit IRC
3042018-01-30T13:55:59 <jnewbery> xabbix: not sure how you interpreted "Both are set by your own node" as time is relayed by peers! Time is set by your own node when it receives the tx, and is saved in mempool.dat on shutdown/loaded on startup.
3052018-01-30T13:57:37 <jnewbery> you'll want to look at the AcceptToMemoryPoolWithTime() function in validation.cpp and the places where it's called
3062018-01-30T13:58:36 *** james has joined #bitcoin-core-dev
3072018-01-30T13:59:00 *** james is now known as Guest66433
3082018-01-30T14:04:04 *** jtimon has joined #bitcoin-core-dev
3092018-01-30T14:04:18 *** promag has joined #bitcoin-core-dev
3102018-01-30T14:05:14 <promag> \o/
3112018-01-30T14:05:35 <wumpus> the release notes still need work, if anyone feels like improving them please do so on the wiki, https://github.com/bitcoin/bitcoin/issues/11054 https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.16.0-Release-notes
3122018-01-30T14:10:38 *** Giszmo has joined #bitcoin-core-dev
3132018-01-30T14:18:00 *** jojeyh has quit IRC
3142018-01-30T14:20:27 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3152018-01-30T14:31:47 *** SopaXorzTaker has joined #bitcoin-core-dev
3162018-01-30T14:40:27 *** meshcollider has quit IRC
3172018-01-30T15:06:45 *** mandric has quit IRC
3182018-01-30T15:09:14 *** mandric has joined #bitcoin-core-dev
3192018-01-30T15:17:31 *** flokie has joined #bitcoin-core-dev
3202018-01-30T15:18:57 *** Carolina35Keeble has quit IRC
3212018-01-30T15:25:23 <achow101> yay!
3222018-01-30T15:34:42 *** Giszmo has quit IRC
3232018-01-30T15:35:32 *** Giszmo has joined #bitcoin-core-dev
3242018-01-30T15:36:06 <wumpus> I've added changelog and author information to https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.16.0-Release-notes
3252018-01-30T15:37:44 *** indistylo has quit IRC
3262018-01-30T15:38:09 *** aruns__ has quit IRC
3272018-01-30T15:38:54 *** wraithm has joined #bitcoin-core-dev
3282018-01-30T15:44:31 <wumpus> please help check for duplicate authors and such
3292018-01-30T15:52:03 <instagibbs> wumpus, Donal OConnor and donaloconnor
3302018-01-30T15:52:45 <wumpus> instagibbs: it's a wiki, you can edit it :)
3312018-01-30T15:59:23 *** Trevor18Ritchie has joined #bitcoin-core-dev
3322018-01-30T16:01:05 *** Krellan has quit IRC
3332018-01-30T16:02:30 *** Krellan has joined #bitcoin-core-dev
3342018-01-30T16:06:48 *** Krellan has quit IRC
3352018-01-30T16:07:32 *** Krellan has joined #bitcoin-core-dev
3362018-01-30T16:12:10 *** Emcy has joined #bitcoin-core-dev
3372018-01-30T16:14:25 *** Emcy_ has quit IRC
3382018-01-30T16:17:44 *** intcat has quit IRC
3392018-01-30T16:18:30 *** intcat has joined #bitcoin-core-dev
3402018-01-30T16:20:19 <luke-jr> sdaftuar: I don't understand this question: https://github.com/bitcoin/bips/pull/639#issuecomment-361642505
3412018-01-30T16:21:17 <sdaftuar> luke-jr: I'm trying to restore a document I authored to its original text. I don't know why this needs a discussion on bitcoin-dev?
3422018-01-30T16:22:15 *** Randolf has quit IRC
3432018-01-30T16:23:04 <luke-jr> sdaftuar: the Layer field was added by BIP 123; the only reason BIP 90 was a BIP at all, is because it was a hardfork..
3442018-01-30T16:23:13 <sdaftuar> BIP 123 came after BIP 90
3452018-01-30T16:23:21 <sdaftuar> it was applied to that doc without my approval!
3462018-01-30T16:23:49 <sdaftuar> doesn't the author have the final say on changes?
3472018-01-30T16:24:25 <luke-jr> nobody objected before BIP 123 became activate..?
3482018-01-30T16:25:00 <sdaftuar> no one tagged me to let me know my document was being changed either
3492018-01-30T16:25:31 <luke-jr> the document wasn't really changed, just the headers, which was based on the content
3502018-01-30T16:26:49 <wumpus> the author is supposed to be asked in case of changes
3512018-01-30T16:26:57 <luke-jr> maybe I don't understand the problem - all it does is describe the BIP
3522018-01-30T16:27:04 <luke-jr> wumpus: to the BIP itself, yes
3532018-01-30T16:27:15 <wumpus> yes, I don't know the details
3542018-01-30T16:27:34 <sdaftuar> the point of the BIP is to explain why merely labeling things as "sfot forks" or "hard forks" is deficient
3552018-01-30T16:28:09 <sdaftuar> so applying BIP 123's labels to it doesn't make sense
3562018-01-30T16:28:22 <luke-jr> the point of the BIP was that changes were being made in Core that were objectively a hardfork, and as such should be documented as a hardfork
3572018-01-30T16:28:27 <sdaftuar> no
3582018-01-30T16:30:03 <sdaftuar> i'm at a loss as to what the process here is. i wrote a document, you changed it, and you seem to think i can't change it back without... what exactly?
3592018-01-30T16:30:16 <luke-jr> the headers aren't part of the document
3602018-01-30T16:30:25 <sdaftuar> ah. we should move them out then
3612018-01-30T16:30:49 <luke-jr> having them in separate files would just be needlessly confusing to readers IMO
3622018-01-30T16:32:14 <sdaftuar> so i don't have editorial rights to the headers?
3632018-01-30T16:33:58 <luke-jr> "The BIP editors monitor BIP changes, and update BIP headers as appropriate."
3642018-01-30T16:34:25 <luke-jr> I don't see why you would want to make the headers inaccurate anyway
3652018-01-30T16:34:35 *** Murch has joined #bitcoin-core-dev
3662018-01-30T16:34:43 <sdaftuar> i think bip 123 is misguided, in its naive labeling of consensus changes as soft forks or hard forks
3672018-01-30T16:34:58 <sdaftuar> bip 90 demonstrates this
3682018-01-30T16:35:11 <sdaftuar> did you not see the quote i pasted from bip 123's author?
3692018-01-30T16:35:19 <sdaftuar> i think that quote reflects a view held by many
3702018-01-30T16:35:23 *** ProfMac has quit IRC
3712018-01-30T16:35:24 <luke-jr> this is a complaint that should have been brought up before BIP 123 was activated, or a new Process BIP to revise/change it
3722018-01-30T16:35:40 <luke-jr> bbiab
3732018-01-30T16:37:12 <provoostenator> I see it's Gitian o'clock?
3742018-01-30T16:39:47 <achow101> hmm, did I screw up my gitian build? The files produced are 0.15.99 not 0.16
3752018-01-30T16:40:16 <sdaftuar> luke-jr: it seems to me that BIP123's activation should have required agreement from the BIP-authors that it was applied to
3762018-01-30T16:40:33 *** Chris_Stewart_5 has quit IRC
3772018-01-30T16:41:35 *** promag has quit IRC
3782018-01-30T16:43:23 <BlueMatt> has anyone ever seen a case when compiling qt where flags arent being passed through when compiling the qt stuff properly?
3792018-01-30T16:44:02 <BlueMatt> eg I get "No such slot" on all the slots that are inside #ifdef ENABLE_WALLET in bitcoingui.h, and some icons/images arent being compiled in (eg QImage::scaled: Image is a null image) properly
3802018-01-30T16:44:18 <BlueMatt> obviously wiped ccache/git clean'd
3812018-01-30T16:44:51 <BlueMatt> maybe cfields has some autotools-debug tips?
3822018-01-30T16:45:18 <cfields> BlueMatt: you forget the include, maybe?
3832018-01-30T16:46:00 <cfields> (config/bitcoin-config.h)
3842018-01-30T16:46:07 <BlueMatt> this is 0.15.1, no modifications
3852018-01-30T16:47:20 <cfields> BlueMatt: i'm not sure what you mean. You get "no such slot" at runtime, or build time?
3862018-01-30T16:47:37 <BlueMatt> runtime
3872018-01-30T16:48:02 <BlueMatt> and like cant click the top tabs to switch views cause of missing slot
3882018-01-30T16:49:06 <provoostenator> The Debian installer link in the instructions is broken, beacuse there's no more iso-cd path. Which one should I use? http://cdimage.debian.org/mirror/cdimage/archive/8.9.0/amd64/
3892018-01-30T16:49:13 <cfields> BlueMatt: sounds like --disable-wallet :)
3902018-01-30T16:49:28 <BlueMatt> nope, not --disable-wallet, and configure output lists wallet enabled
3912018-01-30T16:49:41 <BlueMatt> i mean also the image on the splash screen somehow didnt get compiled in so the background is blank
3922018-01-30T16:50:31 <cfields> BlueMatt: no clue. Sounds like maybe something didn't get regenerated when you switched tags/branches ?
3932018-01-30T16:50:51 <cfields> nm, i see you cleaned
3942018-01-30T16:51:15 <BlueMatt> full git directory wipe, re-autogen/configure, even wiped ccache
3952018-01-30T16:51:24 <BlueMatt> its even in a vm that just got rebooted
3962018-01-30T16:51:28 <BlueMatt> sooooo....wat
3972018-01-30T16:51:43 <cfields> achow101: bitcoin-0.16.0-osx-unsigned.dmg
3982018-01-30T16:51:44 <provoostenator> Looks like they got rid of iso images for the 8.9.0 release. 9.2.1 still has them. I'll try if that produces the same build and make a PR.
3992018-01-30T16:51:59 <achow101> cfields: I fucked up
4002018-01-30T16:52:47 <cfields> BlueMatt: you've verified that the ENABLE_WALLET stuff is actually being built?
4012018-01-30T16:53:12 <BlueMatt> it loads the wallet, lists transactions, shows a balance, etc
4022018-01-30T16:53:14 <BlueMatt> sooo...yes?
4032018-01-30T16:53:16 <cfields> BlueMatt: oh (prepare for possible red herring), kinda sounds like a define is missing when the forms are built
4042018-01-30T16:54:02 <BlueMatt> thats what I'm thinking, kinda, but i know almost nothing about qt/autotools
4052018-01-30T16:54:27 <BlueMatt> so I have a #ifndef ENABLE_WALLET #error in bitcoingui.h, but I dont know if its being compiled or if qt is doing some C++ parsing?
4062018-01-30T16:54:41 <BlueMatt> only change was upgrading packages....is it possible qt is now mis-parsing the .h?
4072018-01-30T16:55:51 <cfields> was qt itself updated?
4082018-01-30T16:56:13 <BlueMatt> i believe so, yes
4092018-01-30T16:56:18 <provoostenator> I wasnt' the first ot notice: https://github.com/bitcoin-core/docs/pull/6
4102018-01-30T16:56:19 <cfields> BlueMatt: all qt-generated files are bound to the versions that created them
4112018-01-30T16:56:56 <cfields> so moc 1.2.3 will create headers meant to be linked against qt headers/libs v1.2.3
4122018-01-30T16:57:00 <BlueMatt> git clean -f -x -d'd :p
4132018-01-30T16:57:36 <cfields> provoostenator: thanks :)
4142018-01-30T16:57:39 <BlueMatt> uh huh, yes, so moc-qt5 is now broken for us - in normal compile the #ifdef ENABLE_WALLETs are being ignored, if I remove the ifdefs things work (eg gotoOverviewPage will or wont show up in moc_bitcoingui.cpp)
4152018-01-30T16:58:18 <cfields> BlueMatt: the defines are passed along. Somehow for you they're not...
4162018-01-30T16:58:20 <achow101> provoostenator: the OS you build on doesn't really matter since the actual build happens within another vm/container
4172018-01-30T16:58:39 <achow101> that vm/container will be the same OS for everyone
4182018-01-30T16:58:48 *** Trevor18Ritchie has quit IRC
4192018-01-30T16:58:57 <cfields> BlueMatt: https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.qt.include#L455
4202018-01-30T16:59:53 <achow101> cfields: my gitian build has this error: https://0bin.net/paste/S+squMjJftoksqm-#HEzfaPoLdoUUf4qz5ZxzMrrbHtdelDjzCYaVCCDHKQs
4212018-01-30T17:00:04 <provoostenator> achow101 someone needs to draw a picture of that inception / VM (Virtual Matroesjka) situation
4222018-01-30T17:00:18 <BlueMatt> cfields: -DHAVE_CONFIG_H is passed to moc-qt5 (make claims it is, at least), and if I put an ENABLE_WALLET inside the if defined(HAVE_CONFIG_H) it works fine, but somehow bitcoin-config.h isnt getting included
4232018-01-30T17:01:14 <cfields> BlueMatt: i wonder if you somehow got messed up by the #include "foo.h" -> #include <foo.h>
4242018-01-30T17:01:30 *** Randolf has joined #bitcoin-core-dev
4252018-01-30T17:01:43 <cfields> BlueMatt: out-of-tree ?
4262018-01-30T17:01:55 <cfields> ooh, i bet that's it...
4272018-01-30T17:01:57 <BlueMatt> in tree
4282018-01-30T17:02:01 <BlueMatt> and this is 0.15.1
4292018-01-30T17:02:04 <BlueMatt> so pre <foo.h>
4302018-01-30T17:02:28 <cfields> BlueMatt: got a stale bitcoin-config.h around somewhere?
4312018-01-30T17:02:29 <BlueMatt> i mean clearly qt broke our build, question is if we need to work around it or what
4322018-01-30T17:02:31 *** jb55 has joined #bitcoin-core-dev
4332018-01-30T17:02:34 <BlueMatt> git clean -f -x -d :p
4342018-01-30T17:03:12 <cfields> damn, right, i was banking on you saying "out-of-tree"
4352018-01-30T17:03:42 <cfields> achow101: I'm betting you just ran out of mem
4362018-01-30T17:03:57 *** mandric has quit IRC
4372018-01-30T17:04:05 <cfields> achow101: I haven't built linux yet though
4382018-01-30T17:04:06 <achow101> cfields: probably. I forgot to allocate more memory to kvm when I did this build
4392018-01-30T17:04:56 *** Krellan has quit IRC
4402018-01-30T17:05:15 <cfields> BlueMatt: i'm not sure what to tell you. Can you give it a shot with 0.16 so we can start there?
4412018-01-30T17:05:32 *** Krellan has joined #bitcoin-core-dev
4422018-01-30T17:06:25 <BlueMatt> yea, I still had the test_bitcoin-qt failure on 16 so i figured bug was the same but didnt actually try to run it
4432018-01-30T17:06:26 *** mandric has joined #bitcoin-core-dev
4442018-01-30T17:09:05 <BlueMatt> yes, same bug
4452018-01-30T17:09:18 <BlueMatt> gotoOverviewPage (etc) doesn't show up in src/qt/moc_bitcoingui.cpp post-build
4462018-01-30T17:09:42 <cfields> ok
4472018-01-30T17:09:48 <cfields> got a list of updated packages?
4482018-01-30T17:09:48 *** Krellan has quit IRC
4492018-01-30T17:10:20 <BlueMatt> errr....probably, sec
4502018-01-30T17:10:33 *** Krellan has joined #bitcoin-core-dev
4512018-01-30T17:11:55 *** twistedline_ has joined #bitcoin-core-dev
4522018-01-30T17:12:05 *** twistedline has quit IRC
4532018-01-30T17:13:41 <BlueMatt> cfields: (roughly, there's a few extras there) http://termbin.com/3zh4
4542018-01-30T17:13:58 <BlueMatt> i mean essentially all the things...gcc/boost/qt/etc
4552018-01-30T17:14:19 <cfields> BlueMatt: thanks. What distro/version?
4562018-01-30T17:14:26 <cfields> I already have a hunch
4572018-01-30T17:14:34 <BlueMatt> its an arch vm
4582018-01-30T17:14:38 <BlueMatt> so...all rolling release crap
4592018-01-30T17:15:08 <cfields> ok
4602018-01-30T17:15:26 <cfields> https://github.com/qt/qtbase/commit/abcf558e49d5e8c20eda14badc30e93e2e9cba32#diff-7680dae0477922e25856c03d1058d2b7
4612018-01-30T17:15:58 <cfields> so they've recently switched up their option parsing. I'm wondering if they broke -D somehow
4622018-01-30T17:16:20 <cfields> (i realize you said it was parsed, but maybe include handling after that is busted)
4632018-01-30T17:16:56 <BlueMatt> no, because BITCOIN_CONFIG_H is clearly being used
4642018-01-30T17:17:05 <BlueMatt> so it has to be some include option blowing up
4652018-01-30T17:17:24 <BlueMatt> yea
4662018-01-30T17:20:13 *** promag has joined #bitcoin-core-dev
4672018-01-30T17:24:54 *** Krellan has quit IRC
4682018-01-30T17:25:31 *** Krellan has joined #bitcoin-core-dev
4692018-01-30T17:26:01 <BlueMatt> cfields: did you find anything in qt git?
4702018-01-30T17:26:27 <cfields> BlueMatt: still looking, nothing obvious
4712018-01-30T17:26:35 <cfields> BlueMatt: can you try a depends build just for a control?
4722018-01-30T17:26:41 <BlueMatt> ugh
4732018-01-30T17:26:52 <BlueMatt> I mean I can revert to the older vm image and see what happens
4742018-01-30T17:27:37 <cfields> well sure, but it'd be helpful to have good/bad moc side-by-side
4752018-01-30T17:29:58 *** Krellan has quit IRC
4762018-01-30T17:30:33 *** Krellan has joined #bitcoin-core-dev
4772018-01-30T17:33:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4782018-01-30T17:35:45 *** dgenr8 has quit IRC
4792018-01-30T17:35:54 *** dgenr8 has joined #bitcoin-core-dev
4802018-01-30T17:37:56 <wumpus> I don't get it, feature_uacomment.py is failing on travis, but I can't reproduce it locally
4812018-01-30T17:37:58 <wumpus> https://travis-ci.org/bitcoin/bitcoin/jobs/335143070
4822018-01-30T17:38:57 <wumpus> "Error: Total length of network version string (285) exceeds maximum length (256). Reduce the number or size of uacomments."
4832018-01-30T17:40:44 <sdaftuar> looks like the test is expecting a slightly different error string (286 instead of 285), and that is why the test is failing
4842018-01-30T17:40:51 <cfields> heh, 285 != 286
4852018-01-30T17:40:56 <cfields> yep
4862018-01-30T17:41:02 <wumpus> but I don't understand where that comes from
4872018-01-30T17:41:20 <sdaftuar> yeah me either
4882018-01-30T17:41:38 <wumpus> oh maybe 0.16.0 i.s.o 0.16.99
4892018-01-30T17:41:43 <wumpus> what a dumb test in that case
4902018-01-30T17:41:47 <provoostenator> The guide is very clear until after the Setup Gitian section. After that there's too many options. https://github.com/bitcoin-core/docs/blob/master/gitian-building.md#getting-and-building-the-inputs
4912018-01-30T17:42:16 <sdaftuar> wumpus: ouch
4922018-01-30T17:42:17 <provoostenator> " run it with the --setup command" should have a specific example, e.g. assuming Debian. I remember that confused me for hours half a year ago
4932018-01-30T17:43:13 <wumpus> sdaftuar: cfields: yep that's it, I'm going to remove the check for a specific number
4942018-01-30T17:43:15 <provoostenator> I'll take a snapshot of my VM before doing that...
4952018-01-30T17:43:35 <wumpus> can reproduce it locally now, too, I was testing with master
4962018-01-30T17:44:00 *** Chris_Stewart_5 has quit IRC
4972018-01-30T17:44:15 <cfields> wumpus: makes sense. I vaguely remember a conversation about using exit codes rather than testing strings. Guess that didn't pan out.
4982018-01-30T17:44:39 <wumpus> well it makes sense that it checks the error message, it just doesn't have to be so specific
4992018-01-30T17:49:02 <cfields> BlueMatt: i'm not seeing anything obvious :\
5002018-01-30T17:50:36 *** xabbix has joined #bitcoin-core-dev
5012018-01-30T17:58:52 <bitcoin-git> [bitcoin] laanwj opened pull request #12302: test: Make ua_comment test pass on 0.16.0 (master...2017_01_uacomment_test_fix) https://github.com/bitcoin/bitcoin/pull/12302
5022018-01-30T17:59:23 *** Cecelia13Shanaha has joined #bitcoin-core-dev
5032018-01-30T18:00:51 *** Randolf has quit IRC
5042018-01-30T18:01:57 *** Randolf has joined #bitcoin-core-dev
5052018-01-30T18:14:08 *** promag has quit IRC
5062018-01-30T18:18:10 *** neha has quit IRC
5072018-01-30T18:18:48 *** Lynet has joined #bitcoin-core-dev
5082018-01-30T18:18:54 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5092018-01-30T18:19:58 *** neha has joined #bitcoin-core-dev
5102018-01-30T18:20:11 *** Krellan has quit IRC
5112018-01-30T18:20:45 *** Krellan has joined #bitcoin-core-dev
5122018-01-30T18:25:57 *** DrFeelGood has quit IRC
5132018-01-30T18:27:21 *** Krellan has quit IRC
5142018-01-30T18:27:49 *** Krellan has joined #bitcoin-core-dev
5152018-01-30T18:32:18 *** Krellan has quit IRC
5162018-01-30T18:33:29 *** laurentmt has joined #bitcoin-core-dev
5172018-01-30T18:36:49 *** neha has quit IRC
5182018-01-30T18:36:53 <arubi> daemon stopped, I mkdir 'wallet/' in datadir, moved all my wallet .dats in there, added a new 'wallet=30_01_28_btc_segwit.dat' line in bitcoin.conf, started the daemon, and the new wallet file with this name was created in the datadir root. somewhat surprising, I'm able to getwalletinfo for both this new wallet and old wallets that are now in wallet/ using the -rpcwallet= set
5192018-01-30T18:37:03 <arubi> oh this is re. 0.16.0rc1
5202018-01-30T18:38:55 <arubi> ohh it says 'wallets' in th release notes, but 'wallet/' in the rpc call help. my bad. it just created a bunch of new wallets :)
5212018-01-30T18:38:55 <bitcoin-git> [bitcoin] laanwj closed pull request #12302: test: Make ua_comment test pass on 0.16.0 (master...2017_01_uacomment_test_fix) https://github.com/bitcoin/bitcoin/pull/12302
5222018-01-30T18:39:52 *** Krellan has joined #bitcoin-core-dev
5232018-01-30T18:43:00 *** neha has joined #bitcoin-core-dev
5242018-01-30T18:43:25 <jnewbery> wumpus: I'm happy to open a new PR if you think that's better, but I'm also happy for you to just force push the one-line fix in your PR
5252018-01-30T18:43:32 <jnewbery> whichever you prefer
5262018-01-30T18:43:47 <wumpus> I'm just tired of this, wanted to quickly fix the test then everyone wants to push their own solution
5272018-01-30T18:44:12 *** jb55 has quit IRC
5282018-01-30T18:44:18 *** Krellan_ has joined #bitcoin-core-dev
5292018-01-30T18:44:24 *** Krellan has quit IRC
5302018-01-30T18:44:52 <wumpus> I think a regexp is a good idea for message matching, and could be useful in other cases too in the future where there's data embedded in the message we want to ignore
5312018-01-30T18:45:43 <wumpus> but I really don't feel like eternally arguing even about things like this, of course you can solve it in 20 different ways too
5322018-01-30T18:45:48 <jnewbery> seems over-engineered for fixing a single case. I think here it just makes sense to match on the substring
5332018-01-30T18:45:53 *** SopaXorzTaker is now known as ^s
5342018-01-30T18:46:09 <jnewbery> Sorry - I seem to have touched a raw nerve
5352018-01-30T18:46:40 <jnewbery> It wasn't a NACK, I just think it's neater to update the individual case than change the util function for this one case
5362018-01-30T18:46:54 <jnewbery> but if you prefer your way, that obviously also achieves the same
5372018-01-30T18:46:58 <wumpus> no, I don't think matching a partial message only is better than ignoring the few characters we don't care about
5382018-01-30T18:47:42 <jnewbery> ok, in that case re-open the PR
5392018-01-30T18:47:51 <wumpus> I thought about that too but thought this would cover it better
5402018-01-30T18:48:02 <sdaftuar> let's merge it and move on... 0.16.0 awais
5412018-01-30T18:48:04 <sdaftuar> awaits*
5422018-01-30T18:48:32 <jnewbery> many of the test cases match on substring. I agree that regex matching would be better in the general case
5432018-01-30T18:48:33 <wumpus> 0.16.0 is not blocked on this, we already tagged rc1
5442018-01-30T18:49:36 *** Krellan_ has quit IRC
5452018-01-30T18:50:56 *** flokie has quit IRC
5462018-01-30T18:52:27 <sdaftuar> fair, but even if we're not immediately blocked on it, i think we make our lives easier by quickly closing out these kinds of minor issues when we can
5472018-01-30T18:54:23 <jnewbery> I agree. I'd argue that implementing a minimal fix that only fixes the broken test case is more appropriate than trying to expand the functionality of the test framework, but really either fix is fine.
5482018-01-30T18:54:24 <wumpus> yes, sorry for overreacting
5492018-01-30T18:59:13 <wumpus> though I don't think it was unreasonable to try to expand the test framework to do something more than it does
5502018-01-30T18:59:39 <wumpus> I understand the consensus code for bitcoin is set in stone, but surely the interface for the test framework isn't
5512018-01-30T19:04:10 *** Randolf has quit IRC
5522018-01-30T19:06:09 *** Cecelia13Shanaha has quit IRC
5532018-01-30T19:06:36 <jnewbery> I agree that the framework can be improved, but I think that can be done in a separate PR from a quick fix to get the tests running again
5542018-01-30T19:06:56 <jnewbery> But we don't need to make this a big thing. I can ACK your PR :)
5552018-01-30T19:08:12 *** Tennis has joined #bitcoin-core-dev
5562018-01-30T19:10:15 *** jb55 has joined #bitcoin-core-dev
5572018-01-30T19:17:30 <provoostenator> "lxc-execute: start.c: lxc_spawn: 1079 Failed to find gateway addresses"
5582018-01-30T19:18:25 <provoostenator> Pretty sure I followed this to the T: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md
5592018-01-30T19:20:36 <provoostenator> Ah wait, I shouldn't copy paste those example IP addresses probably. Vaguely remember making that mistake last time.
5602018-01-30T19:21:04 <wumpus> oh great now that I pushed something else I cannot reopen the PR anymore
5612018-01-30T19:21:24 <wumpus> crap github
5622018-01-30T19:22:03 *** owowo has quit IRC
5632018-01-30T19:22:16 <jnewbery> reset to the old commit, push, open PR, reset to the new commit, force push
5642018-01-30T19:23:01 <wumpus> some other time
5652018-01-30T19:23:04 *** flokie has joined #bitcoin-core-dev
5662018-01-30T19:25:39 *** arbitrary_guy has joined #bitcoin-core-dev
5672018-01-30T19:27:39 *** owowo has joined #bitcoin-core-dev
5682018-01-30T19:29:37 *** Tennis has quit IRC
5692018-01-30T19:34:20 <provoostenator> I can't remember where to get the correct values for GITIAN_HOST_IP (the IP of the Debian virtual box?) and LXC_GUEST_IP.
5702018-01-30T19:35:10 *** d_t has joined #bitcoin-core-dev
5712018-01-30T19:35:23 *** schmidty has joined #bitcoin-core-dev
5722018-01-30T19:35:41 <provoostenator> https://botbot.me/freenode/bitcoin-core-dev/2017-02-21/?msg=81301776&page=1
5732018-01-30T19:37:41 *** dcousens has quit IRC
5742018-01-30T19:37:47 *** wraithm_ has joined #bitcoin-core-dev
5752018-01-30T19:38:03 *** dcousens has joined #bitcoin-core-dev
5762018-01-30T19:38:35 *** wraithm_ has quit IRC
5772018-01-30T19:38:49 *** owowo has quit IRC
5782018-01-30T19:39:08 *** wraithm_ has joined #bitcoin-core-dev
5792018-01-30T19:39:24 *** wraithm has quit IRC
5802018-01-30T19:39:25 *** wraithm_ has quit IRC
5812018-01-30T19:39:40 *** PaulCapestany has quit IRC
5822018-01-30T19:40:12 *** wraithm has joined #bitcoin-core-dev
5832018-01-30T19:40:44 *** Krellan has joined #bitcoin-core-dev
5842018-01-30T19:41:03 *** wraithm has quit IRC
5852018-01-30T19:41:26 *** mandric has quit IRC
5862018-01-30T19:41:48 *** wraithm has joined #bitcoin-core-dev
5872018-01-30T19:42:40 *** wraithm has joined #bitcoin-core-dev
5882018-01-30T19:44:20 *** mandric has joined #bitcoin-core-dev
5892018-01-30T19:45:05 *** Krellan has quit IRC
5902018-01-30T19:45:08 *** owowo has joined #bitcoin-core-dev
5912018-01-30T19:45:53 *** wraithm_ has joined #bitcoin-core-dev
5922018-01-30T19:46:05 *** Krellan has joined #bitcoin-core-dev
5932018-01-30T19:46:38 *** wraithm_ has quit IRC
5942018-01-30T19:46:38 *** Krellan has quit IRC
5952018-01-30T19:46:48 *** wraithm has quit IRC
5962018-01-30T19:47:07 *** Krellan has joined #bitcoin-core-dev
5972018-01-30T19:47:35 *** PaulCape_ has joined #bitcoin-core-dev
5982018-01-30T19:53:45 <provoostenator> Ah wait, it's more subtle. These instructions use "ifconfig" which isn't installed on Debian by default: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md#setting-up-debian-for-gitian-building
5992018-01-30T19:54:14 <provoostenator> And of course, Linux being Linux, it just silently fails and let the user shoot themselves in the foot
6002018-01-30T19:54:54 *** wraithm has joined #bitcoin-core-dev
6012018-01-30T19:54:56 <goatpig> does Core use zeromq?
6022018-01-30T19:55:08 <achow101> goatpig: yes
6032018-01-30T19:55:22 <goatpig> isn't Core under the MIT license?
6042018-01-30T19:56:54 <luke-jr> Core *offers* a zeromq service, but "using" it is ill-defined in this case
6052018-01-30T19:57:01 <luke-jr> goatpig: yes, and?
6062018-01-30T19:57:20 <goatpig> isn't LGPL3 (zmq) incompatible with MIT?
6072018-01-30T19:57:35 *** dcousens has quit IRC
6082018-01-30T19:57:37 <gmaxwell> No, not at all.
6092018-01-30T19:57:59 <luke-jr> goatpig: LGPL is Lesser GPL. It specifically allows non-GPL stuff to use it.
6102018-01-30T19:58:01 <goatpig> with version of GPL is incompatible with MIT then? AGPL?
6112018-01-30T19:58:10 *** arbitrary_guy has quit IRC
6122018-01-30T19:58:12 <goatpig> ah that's what got me confused I guess
6132018-01-30T19:58:14 *** dcousens has joined #bitcoin-core-dev
6142018-01-30T19:58:20 <luke-jr> GPL and AGPL are incompatible with non-free software, but still compatible with MIT
6152018-01-30T19:58:23 <gmaxwell> Nothing is incompatible with MIT, some things are more restrictive and we prefer to not use them.
6162018-01-30T19:58:30 <luke-jr> they're NOT compatible with OpenSSL, however, which is another dependency of ours..
6172018-01-30T19:59:01 <gmaxwell> (luke's They is GPL and AGPL)
6182018-01-30T19:59:15 <goatpig> so a MIT project can make use a LGPL dependency just fine?
6192018-01-30T19:59:24 *** Ron62Deckow has joined #bitcoin-core-dev
6202018-01-30T19:59:27 <gmaxwell> Yes.
6212018-01-30T19:59:33 <goatpig> ok thanks
6222018-01-30T19:59:52 <luke-jr> only thing to keep in mind is, you still need to release source for the dependency per the terms
6232018-01-30T20:00:08 *** schmidty has quit IRC
6242018-01-30T20:00:48 <goatpig> due noted
6252018-01-30T20:02:23 <cfields> yes. We could pull in a gplv3 lib and we'd be fine to distribute it as usual. Problem is that some companies would want to modify that code without publishing it, so it's unlikely that we'd add any dependencies like that
6262018-01-30T20:02:38 <cfields> jonasschnelli: ping
6272018-01-30T20:03:13 <luke-jr> cfields: well, I think as long as we depend on OpenSSL, the conflict would prevent distribution
6282018-01-30T20:03:25 <provoostenator> Still not seeing the br0 interface though.
6292018-01-30T20:03:36 <cfields> hmm?
6302018-01-30T20:05:46 <gmaxwell> cfields: openssl has a GPL incompatible license (it's advertising clause bsd)
6312018-01-30T20:06:18 *** dcousens has quit IRC
6322018-01-30T20:07:22 *** dcousens has joined #bitcoin-core-dev
6332018-01-30T20:08:52 <cfields> huh
6342018-01-30T20:09:26 <achow101> in the test framework, how can I make it so that all of the nodes in a test are connected to each other and stay synced together without having to use sync_all?
6352018-01-30T20:10:02 <achow101> sync_all is very slow and it would be better if they were properly connected over the p2p network and sending data between themselves
6362018-01-30T20:12:47 <provoostenator> Made some progress: https://github.com/bitcoin-core/docs/issues/15
6372018-01-30T20:13:33 *** Chris_Stewart_5 has quit IRC
6382018-01-30T20:15:52 <instagibbs> achow101, they should be connected, sync_all just makes sure that you can order evens from the frame of reference of all the nodes
6392018-01-30T20:17:06 *** d_t has quit IRC
6402018-01-30T20:18:36 *** laurentmt has quit IRC
6412018-01-30T20:18:53 <bitcoin-git> [bitcoin] laanwj reopened pull request #12302: test: Make ua_comment test pass on 0.16.0 (master...2017_01_uacomment_test_fix) https://github.com/bitcoin/bitcoin/pull/12302
6422018-01-30T20:21:36 *** ^s is now known as SopaXorzTaker
6432018-01-30T20:31:46 *** SopaXorzTaker has quit IRC
6442018-01-30T20:34:21 *** blueOcean has joined #bitcoin-core-dev
6452018-01-30T20:41:30 *** laurentmt has joined #bitcoin-core-dev
6462018-01-30T20:42:01 *** laurentmt has quit IRC
6472018-01-30T20:45:07 *** blueOcean has quit IRC
6482018-01-30T20:47:50 *** laurentmt has joined #bitcoin-core-dev
6492018-01-30T20:49:10 <provoostenator> lxc-execute: conf.c: setup_rootfs: 1279 failed to mount rootfs
6502018-01-30T20:55:38 *** Randolf has joined #bitcoin-core-dev
6512018-01-30T20:56:26 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9cb230905088...f0295becbf3e
6522018-01-30T20:56:26 <bitcoin-git> bitcoin/master aac6bce Wladimir J. van der Laan: test: Make ua_comment test pass on 0.16.0...
6532018-01-30T20:56:27 <bitcoin-git> bitcoin/master f0295be MarcoFalke: Merge #12302: test: Make ua_comment test pass on 0.16.0...
6542018-01-30T20:57:18 *** LumberCartel has joined #bitcoin-core-dev
6552018-01-30T20:57:23 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12302: test: Make ua_comment test pass on 0.16.0 (master...2017_01_uacomment_test_fix) https://github.com/bitcoin/bitcoin/pull/12302
6562018-01-30T20:58:44 <provoostenator> I ended up deleting the file /home/debian/gitian-builder/target-trusty-amd64 and replacing it with a directory, including /proc and /sys subdirs. That at least got me to the next error...
6572018-01-30T20:59:55 *** promag has joined #bitcoin-core-dev
6582018-01-30T20:59:57 <provoostenator> lxc-execute: conf.c: setup_pts: 1407 No such file or directory - failed to create '/dev/pts'
6592018-01-30T21:00:15 *** Randolf has quit IRC
6602018-01-30T21:00:17 <provoostenator> These are different issues than I ran into half a year ago. I opened some issues on the docs repo. Will try again later.
6612018-01-30T21:00:24 *** jb55 has quit IRC
6622018-01-30T21:01:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6632018-01-30T21:01:54 *** LumberCartel has quit IRC
6642018-01-30T21:04:27 <wumpus> you definitely shouldn't have to replace target-something with a directory
6652018-01-30T21:04:47 <wumpus> that file should be auto-generated
6662018-01-30T21:05:55 <wumpus> as I understand base-trusty-amd64 is the file that will be created by installing gitian / building the initial image, target-trusty-amd64 should be re-generated on every run of gitian when building something, it's a working copy of the base image
6672018-01-30T21:10:31 *** _203458034582340 has joined #bitcoin-core-dev
6682018-01-30T21:11:05 *** _203458034582340 has quit IRC
6692018-01-30T21:11:49 *** Randolf has joined #bitcoin-core-dev
6702018-01-30T21:12:27 *** Randolf has quit IRC
6712018-01-30T21:12:32 *** cloaks has quit IRC
6722018-01-30T21:15:23 *** laurentmt has quit IRC
6732018-01-30T21:15:44 *** jb55 has joined #bitcoin-core-dev
6742018-01-30T21:15:58 <provoostenator> Mmm, so maybe something silently failed when creating the base image?
6752018-01-30T21:16:23 <provoostenator> Ah I see, that's why it mounting that file.
6762018-01-30T21:18:50 *** cloaks has joined #bitcoin-core-dev
6772018-01-30T21:19:08 <provoostenator> I deleted that directory again. Now it seems to be doing a bit more. But I get frequent "init.lxc: failed to mount /dev/shm" error, as well as "sudo: unable to resolve host gitian".
6782018-01-30T21:20:46 <wumpus> the sudo resolve warning is harmless
6792018-01-30T21:22:19 <provoostenator> Yeah, I think it's actually building now. Hooray!
6802018-01-30T21:28:50 *** Giszmo has quit IRC
6812018-01-30T21:34:40 <bitcoin-git> [bitcoin] jnewbery opened pull request #12304: Backport 12302 (0.16...backport_12302) https://github.com/bitcoin/bitcoin/pull/12304
6822018-01-30T21:40:40 *** arbitrary_guy has joined #bitcoin-core-dev
6832018-01-30T21:46:22 <michagogo> Hrm
6842018-01-30T21:46:27 <michagogo> http://paste.ubuntu.com/26491672/
6852018-01-30T21:46:34 <MarcoFalke> Anyone with block bit want to kick the markov chain generator https://github.com/bitcoin/bitcoin/pull/11771#issuecomment-361742013
6862018-01-30T21:46:39 *** Ron62Deckow has quit IRC
6872018-01-30T21:46:43 <michagogo> Got a segfault while building
6882018-01-30T21:46:48 *** cloaks has quit IRC
6892018-01-30T21:46:58 <MarcoFalke> WalterBoles
6902018-01-30T21:47:09 *** cloaks has joined #bitcoin-core-dev
6912018-01-30T21:48:23 *** meshcollider has joined #bitcoin-core-dev
6922018-01-30T21:51:34 <MarcoFalke> wumpus: ^
6932018-01-30T21:52:05 <wumpus> MarcoFalke: looking
6942018-01-30T21:53:48 *** jb55 has quit IRC
6952018-01-30T21:55:43 *** cloaks has quit IRC
6962018-01-30T21:58:17 <michagogo> provoostenator: iirc my past experience has been that Ubuntu is much smoother as a host compared to Debian
6972018-01-30T21:58:46 <michagogo> I pretty much just followed the gitian readme
6982018-01-30T22:00:00 <michagogo> I think at some point I set up a working gitian environment from scratch in a clean VM and put out a video (and ova)
6992018-01-30T22:01:24 *** Neil13Bradtke has joined #bitcoin-core-dev
7002018-01-30T22:02:28 *** jb55 has joined #bitcoin-core-dev
7012018-01-30T22:05:19 *** larafale has quit IRC
7022018-01-30T22:05:26 <michagogo> WTF? Now it failed somewhere in the Qt build
7032018-01-30T22:06:06 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/6c2788c7c8d45ac8f38e998c8a9739efdd0b6d18
7042018-01-30T22:06:06 <bitcoin-git> bitcoin/0.16 6c2788c Wladimir J. van der Laan: test: Make ua_comment test pass on 0.16.0...
7052018-01-30T22:08:02 *** belcher has joined #bitcoin-core-dev
7062018-01-30T22:08:44 *** jb55 has quit IRC
7072018-01-30T22:09:16 <bitcoin-git> [bitcoin] jamesob opened pull request #12305: Clarify -conf help message to mention datadir path prefix (master...jamesob/conf-flag-path-help) https://github.com/bitcoin/bitcoin/pull/12305
7082018-01-30T22:13:18 *** neha has quit IRC
7092018-01-30T22:15:16 *** neha has joined #bitcoin-core-dev
7102018-01-30T22:15:30 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12304: [qa] 0.16: Backport 12302 (0.16...backport_12302) https://github.com/bitcoin/bitcoin/pull/12304
7112018-01-30T22:15:42 <jamesob> wumpus: worth clarifying other path-accepting configuration option help messages, or should I just close the PR?
7122018-01-30T22:16:15 <wumpus> jamesob: I don't know, we might want to document it somewhere in one place instead of for each argument separately
7132018-01-30T22:16:58 <wumpus> for things like that it helps to at least try to be consistent
7142018-01-30T22:17:48 <wumpus> no arguments to bitcoind are relative to the current directory
7152018-01-30T22:20:33 <jamesob> yeah, agree. worth a paragraph between Usage and Options, or maybe there's some other place this is already documented?
7162018-01-30T22:21:42 <wumpus> I don't think it's documented anywhere, agree that it should be
7172018-01-30T22:22:13 *** jb55 has joined #bitcoin-core-dev
7182018-01-30T22:24:33 *** Neil13Bradtke has quit IRC
7192018-01-30T22:34:23 <bitcoin-git> [bitcoin] axvr opened pull request #12306: Docs: Improvements to UNIX documentation (master...fix-docs) https://github.com/bitcoin/bitcoin/pull/12306
7202018-01-30T22:40:20 *** cloaks has joined #bitcoin-core-dev
7212018-01-30T22:41:18 *** jb55 has quit IRC
7222018-01-30T22:44:26 *** d_t has joined #bitcoin-core-dev
7232018-01-30T22:47:28 *** Dizzle has joined #bitcoin-core-dev
7242018-01-30T22:49:26 <sdaftuar> luke-jr: could you explain your "+1" on evoskuil's last comment? i think i've spent quite a bit of time now on that PR explaining why i find the "soft fork"/"hard fork" language deficient.
7252018-01-30T22:49:42 <sdaftuar> is there something you still don't understand about my view?
7262018-01-30T22:50:13 <jamesob> paths like "./bitcoin.conf" are interpreted as being relative to datadir as well; is this behavior we want to retain?
7272018-01-30T22:54:48 *** denis2342 has joined #bitcoin-core-dev
7282018-01-30T22:55:11 <denis2342> hi
7292018-01-30T22:55:50 <denis2342> I just tested bitcoin 0.16.0rc1 on freebsd and it runs fine so far
7302018-01-30T22:59:10 *** ula has joined #bitcoin-core-dev
7312018-01-30T22:59:24 *** Eleanora26Kemmer has joined #bitcoin-core-dev
7322018-01-30T23:04:01 *** Eleanora26Kemmer has quit IRC
7332018-01-30T23:04:36 <promag> ryanofsky: regarding https://github.com/bitcoin/bitcoin/pull/12287/files#r164570542
7342018-01-30T23:04:56 *** Chris_Stewart_5 has quit IRC
7352018-01-30T23:05:19 <promag> so if a block is in the active chain, nChainTx is final?
7362018-01-30T23:06:40 <ryanofsky> i think so because if it's been in the active chain, then it's been validated, and nChainTx should be set
7372018-01-30T23:06:57 *** d_t has quit IRC
7382018-01-30T23:08:15 <promag> you say "and remove an existing lock"
7392018-01-30T23:08:18 <promag> which one?
7402018-01-30T23:08:55 <promag> my point is that cs_main is already held in all callers expect ClientModel::getVerificationProgress
7412018-01-30T23:09:07 <promag> and that jonas adds
7422018-01-30T23:10:01 <ryanofsky> the lock here could be removed: https://github.com/bitcoin/bitcoin/pull/12287/files#diff-b2bb174788c7409b671c46ccc86034bdR1681
7432018-01-30T23:10:03 <promag> but I agree that less locks is better
7442018-01-30T23:10:14 <gmaxwell> Correct software is better. :)
7452018-01-30T23:11:39 *** Lynet_ has joined #bitcoin-core-dev
7462018-01-30T23:12:18 *** Lynet has quit IRC
7472018-01-30T23:12:21 <promag> right, in this case only comment per se doesn't prevent problems
7482018-01-30T23:13:05 *** Guest66433 has quit IRC
7492018-01-30T23:13:37 *** jamesob has quit IRC
7502018-01-30T23:13:38 *** Guyver2 has quit IRC
7512018-01-30T23:13:45 <promag> for instance, in that case ryanofsky, I would lock from https://github.com/bitcoin/bitcoin/pull/12287/files#diff-b2bb174788c7409b671c46ccc86034bdR1678 to L1690
7522018-01-30T23:14:21 <promag> ah sorry maybe that's not possible, because of ShowProgress
7532018-01-30T23:14:38 *** lnostdal has quit IRC
7542018-01-30T23:15:35 <ryanofsky> actually seems like there is another unnecessary lock below that
7552018-01-30T23:17:32 <promag> how about avoid duplicate calls to GuessVerificationProgress(chainParams.TxData(), pindex) ?
7562018-01-30T23:17:51 <promag> just do it once where the lock exists and use that value?
7572018-01-30T23:18:22 <promag> right after pindex = chainActive.Next(pindex); on the loop end
7582018-01-30T23:18:28 <promag> and also before the loop starts
7592018-01-30T23:20:00 <ryanofsky> probably something like that is fine. the whole function is a mess, there's a bunch of unnecessary nesting and immediate unlocking/relocking
7602018-01-30T23:20:40 *** lnostdal has joined #bitcoin-core-dev
7612018-01-30T23:21:40 <Dizzle> sipa
7622018-01-30T23:22:05 <Dizzle> Sorry, miss-typed.
7632018-01-30T23:22:08 <luke-jr> sdaftuar: deficient or not, it's the language currently used for the Layer header..
7642018-01-30T23:22:48 <gmaxwell> Then the layer header should be removed.
7652018-01-30T23:23:17 <gmaxwell> It has very little value at best, and clearly is just resulting in needless arguments.
7662018-01-30T23:23:27 <luke-jr> I don't agree that it's deficient. It is working fine in this case as well.
7672018-01-30T23:23:54 <luke-jr> I don't understand why people are desperate to deny the reality that BIP 90 is a hardfork.
7682018-01-30T23:24:27 <gmaxwell> luke-jr: you're acting inappropriately, your ability to update documents shouldn't be used as a lever to advance arguments you want to make.
7692018-01-30T23:24:42 <luke-jr> â¦
7702018-01-30T23:25:06 <gmaxwell> So you disagree about some description stuff, fine. But editing the documents to fit your world view when other people, particularly the authors of the document disagree isn't kosher.
7712018-01-30T23:25:19 *** Emcy has quit IRC
7722018-01-30T23:25:44 <luke-jr> it's a change proposed nearly 2 years ago and implemented at least many months ago, without any dispute until this week, not used to advance any arguments at all, and in any case completely objective
7732018-01-30T23:25:55 <gmaxwell> The end result will only be that other people will simply walk away from the mechenism.
7742018-01-30T23:26:19 <gmaxwell> It's clearly not completely objective, because the decription doesn't fit the conventional definition of a hardfork.
7752018-01-30T23:26:21 <luke-jr> the documents are not edited, only the preamble header
7762018-01-30T23:26:25 <luke-jr> it does
7772018-01-30T23:26:55 <gmaxwell> You can argue that, but not via special privledges to edit the repository.
7782018-01-30T23:27:01 <luke-jr> unless you're trying to push a redefinition of hardfork, which is not the fault of a change made a long time ago
7792018-01-30T23:27:55 <gmaxwell> I didn't notice that you stuck a hardfork label on BIP 90 until today.
7802018-01-30T23:28:38 <gmaxwell> Had I noticed it I would have disagreed at any point, and you should have known that because voskuil tried arguing that on the mailing list previously and almost everyone disagreed with him.
7812018-01-30T23:28:57 <luke-jr> the whole reason it was made a BIP at all, was because it was a hardfork..
7822018-01-30T23:29:29 <gmaxwell> That is not true.
7832018-01-30T23:29:35 <luke-jr> then why would there be a BIP?
7842018-01-30T23:29:59 <gmaxwell> because there is a BIP for any protocol change with potential interoperability implications... even just documentary ones.
7852018-01-30T23:30:18 <luke-jr> if it is a protocol change, it is a hardfork by definition
7862018-01-30T23:30:22 <gmaxwell> And there has never been a hardfork performed via a BIP.
7872018-01-30T23:30:26 <luke-jr> the only way to argue it isn't a hardfork, is to argue that it isn't a protocol change
7882018-01-30T23:30:55 <gmaxwell> you are now arguing that all changes to the protocol are hardforks?
7892018-01-30T23:31:00 <luke-jr> no
7902018-01-30T23:31:02 <gmaxwell> so segwit is a hardfork? p2sh is a hardfork?
7912018-01-30T23:31:10 <gmaxwell> Fee filter.. hardfork?
7922018-01-30T23:31:19 <gmaxwell> compact blocks hardfork
7932018-01-30T23:31:20 <luke-jr> Segwit and P2SH constrain the protocol, they don't loosen it
7942018-01-30T23:31:24 <gmaxwell> BIP32 ... totally hardfork there.
7952018-01-30T23:31:28 <luke-jr> Fee filter and compact blocks aren't protocol changes at all
7962018-01-30T23:31:41 <gmaxwell> 15:28:57 < luke-jr> the whole reason it was made a BIP at all, was because it was a hardfork..
7972018-01-30T23:31:44 <gmaxwell> 15:29:35 < luke-jr> then why would there be a BIP?
7982018-01-30T23:32:36 <luke-jr> as a protocol change, BIP 90 loosens the rules, and is therefore a hardfork. if it is not a protocol change, then it is an implementation detail that doesn't need standardization
7992018-01-30T23:33:03 <luke-jr> there is no reason for standardization of this kind of change, except if we see it as a protocol change
8002018-01-30T23:33:39 <gmaxwell> BIP 90 doesn't losen the rules. It changes implementation details about things burried in the past, what in the past is in the past. If there were some other chain they would possibly accept that something else would reject then there would be a distinction there. But there isn't.
8012018-01-30T23:33:55 <gmaxwell> it's like arguing that jtimon's changes to not validate the genesis block were a hardfork.
8022018-01-30T23:34:21 <luke-jr> if it's an implementation detail, then there's nothing to standardize
8032018-01-30T23:34:29 <gmaxwell> it turns "hardfork" into some jibberish technical defintion that doesn't map usefully to system behavior, which serves no productive goal other than making it so that only you can decide what is and isn't one.
8042018-01-30T23:35:14 <gmaxwell> luke-jr: Things aren't so black and white, most of BIP90 had been done for something like a year before the BIP was written. But it's better to communicate more instead of less.
8052018-01-30T23:35:41 <luke-jr> where's the grey? I don't see it in this case.
8062018-01-30T23:35:44 <gmaxwell> Writing documentation doesn't turn something into a hardfork that had existed for a long time.
8072018-01-30T23:35:57 *** denis2342 has quit IRC
8082018-01-30T23:36:15 <gmaxwell> luke-jr: BIP90 can't fork off nodes in any plausable situation; thats not even grey: it's not a hardfork in any meaningful sense.
8092018-01-30T23:36:57 <luke-jr> maybe the Layer header should just be deleted for BIP 90 (seeing as it's optional and not always applicable)
8102018-01-30T23:37:17 <gmaxwell> That would be an okay way to handle a dispute, I think.
8112018-01-30T23:37:31 <gmaxwell> The BIP describes itself, I think accurately and in detail.
8122018-01-30T23:37:47 <luke-jr> well, the description in the BIP is clearly a hardfork, IMO
8132018-01-30T23:38:29 <gmaxwell> Lets not create bad incentives for people to describe things using anything less than the most conservative language.
8142018-01-30T23:39:06 <luke-jr> it's a header. there is no incentive..
8152018-01-30T23:39:09 <gmaxwell> esp since bips can pretty much say whatever nonsense they want already.
8162018-01-30T23:39:33 *** Tennis has joined #bitcoin-core-dev
8172018-01-30T23:39:47 <gmaxwell> Sure there is, it's an incentive to not be as conservative (e.g. spelling out any possible way anyone could call it a hardfork, and als possible risks) if its going to result in a misleading header.
8182018-01-30T23:39:57 <BlueMatt> can we just define a new term here
8192018-01-30T23:39:59 <luke-jr> is there some context I'm missing? to me, it looks like someone just up and randomly decided to whine about the layer header
8202018-01-30T23:40:00 <BlueMatt> call it "Buried Fork"
8212018-01-30T23:40:02 <BlueMatt> or something
8222018-01-30T23:40:07 <BlueMatt> then no one has to be upset
8232018-01-30T23:40:11 *** denis2342 has joined #bitcoin-core-dev
8242018-01-30T23:40:36 <gmaxwell> The word fork should probably not be used, because there is no fork.
8252018-01-30T23:40:47 <gmaxwell> there is no split in consensus state.
8262018-01-30T23:41:04 <gmaxwell> "Silver spoon" :P
8272018-01-30T23:42:15 <luke-jr> it's essentially the same thing as adding/removing checkpoints
8282018-01-30T23:42:34 <gmaxwell> I think I agree with that, which we also never have BIPed.
8292018-01-30T23:42:36 <BlueMatt> "Buried Spoon"
8302018-01-30T23:42:55 <BlueMatt> that seems appropriate
8312018-01-30T23:43:03 <gmaxwell> we talked about this when the bip was written and thought there was technically no need to BIP it, but more documentation is better than less.
8322018-01-30T23:44:42 <gmaxwell> I think thats a good practice, but this showing up as some "hardfork enforce by core devs" crap would be a profound disincentive to ever do that again.
8332018-01-30T23:44:57 <contrapumpkin> (a BIP on the need for the layer header in BIPs?)
8342018-01-30T23:45:33 *** luke-jr has quit IRC
8352018-01-30T23:48:10 <jtimon> luke-jr: of course it's good to make bip90 or sdaftuar's pr whether they're hfs, sfs or none of that. I honestly don't care if bip90 is a hf or not, it's still a good thing and should be documented in a bip. I don't think it's good to edit bips without the author's permission unless it's for typos or tiny things
8362018-01-30T23:48:45 <jtimon> BlueMatt: I like more "Buried deployment", but bikeshedding...
8372018-01-30T23:48:48 <contrapumpkin> jtimon: it seems he got disconnected
8382018-01-30T23:49:02 <gmaxwell> Buried deployment sounds okay to me.
8392018-01-30T23:49:02 <jtimon> ops, yeah
8402018-01-30T23:49:04 *** mrannanay has quit IRC
8412018-01-30T23:49:18 <promag> ryanofsky https://github.com/promag/bitcoin/commit/74022f56f733cf0ce3c156e9432e275413dff96c
8422018-01-30T23:49:30 <gmaxwell> well I think a general editoral principle is that you can be liberal with changes that no one complaints about, and conservative with things that cause a fuss.
8432018-01-30T23:50:24 *** luke-jr has joined #bitcoin-core-dev
8442018-01-30T23:50:45 <promag> sorry ryanofsky, force push https://github.com/promag/bitcoin/commit/6e36821823b498c307787543ad59b9e9ccffcc63
8452018-01-30T23:51:26 *** wraithm has quit IRC
8462018-01-30T23:54:58 <jtimon> yeah, nobody will ever complain for a typo being corrected
8472018-01-30T23:55:18 <luke-jr> if we're looking at BIP90-like changes as implementation details, then it should probably go in a Core-specific doc repo rather than BIPs since it isn't a coordinated thing
8482018-01-30T23:55:24 <luke-jr> (I read the IRC log to catch up)
8492018-01-30T23:55:32 <luke-jr> having a Core-specific place for implementation detail documentation would encourage more documentation of Core-specific stuff too
8502018-01-30T23:55:48 <luke-jr> ?
8512018-01-30T23:56:11 <jtimon> luke-jr: it's not core specific, everybody is welcomed to do bip90 too
8522018-01-30T23:57:18 <gmaxwell> you can look at as as we did the analysis to determine that this was an okay thing to do and are publishing the details.
8532018-01-30T23:58:54 <jtimon> was bip39 whatever-wallet-implemented-it-first-specific?
8542018-01-30T23:59:32 *** Allison19Schinne has joined #bitcoin-core-dev