1 2018-01-30 00:35:01	0|bitcoin-git|[13bitcoin] 15promag opened pull request #12299: Improve CWallet::IsFromMe for positive results (06master...062018-01-isfromme) 02https://github.com/bitcoin/bitcoin/pull/12299
  2 2018-01-30 01:51:23	0|bitcoin-git|[13bitcoin] 15jeffrade opened pull request #12300: [Tests] Adding --enable-mainnet configuration option for ChainParams (06master...06mainnet_chain_config) 02https://github.com/bitcoin/bitcoin/pull/12300
  3 2018-01-30 03:37:57	0|jeffrade|fyi, for PR #12300 - will work on requested changes and push commit within 24 - 48 hours
  4 2018-01-30 03:37:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/12300 | [Tests] Adding --enable-mainnet configuration option for ChainParams by jeffrade · Pull Request #12300 · bitcoin/bitcoin · GitHub
  5 2018-01-30 08:58:10	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9d9c4185fada...7cf1aea5cfcc
  6 2018-01-30 08:58:11	0|bitcoin-git|13bitcoin/06master 141944fa3 15Randolf Richardson: [doc] Create build-netbsd.md
  7 2018-01-30 08:58:11	0|bitcoin-git|13bitcoin/06master 14336685e 15Randolf Richardson: [build] Add db4_cxx to bitcoin_find_bdb48.m4...
  8 2018-01-30 08:58:12	0|bitcoin-git|13bitcoin/06master 1411c5827 15fanquake: [build] Add NETBSD leveldb target to configure.ac
  9 2018-01-30 08:59:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12294: [Docs] Create NetBSD build instructions and fix compilation (06master...06netbsd-build-docs) 02https://github.com/bitcoin/bitcoin/pull/12294
 10 2018-01-30 08:59:55	0|bitcoin-git|13bitcoin/06master 14ee11121 15MeshCollider: Add special error for genesis coinbase to gettransaction
 11 2018-01-30 08:59:55	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7cf1aea5cfcc...288deacdbe08
 12 2018-01-30 08:59:56	0|bitcoin-git|13bitcoin/06master 14288deac 15Wladimir J. van der Laan: Merge #12278: Add special error for genesis coinbase to getrawtransaction...
 13 2018-01-30 09:00:50	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12278: Add special error for genesis coinbase to getrawtransaction (06master...06201801_genesis_gettransaction_error) 02https://github.com/bitcoin/bitcoin/pull/12278
 14 2018-01-30 09:17:21	0|bitcoin-git|13bitcoin/06master 14039425c 15João Barbosa: [wallet] Remove duplicate mapWallet lookups
 15 2018-01-30 09:17:21	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/288deacdbe08...7936446268e2
 16 2018-01-30 09:17:22	0|bitcoin-git|13bitcoin/06master 147936446 15Wladimir J. van der Laan: Merge #12276: Remove duplicate mapWallet lookups...
 17 2018-01-30 09:18:11	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12276: Remove duplicate mapWallet lookups (06master...062018-01-mapwallet) 02https://github.com/bitcoin/bitcoin/pull/12276
 18 2018-01-30 09:30:50	0|promag|wumpus: be sure to check #12299
 19 2018-01-30 09:30:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/12299 | Improve CWallet::IsFromMe for positive results by promag · Pull Request #12299 · bitcoin/bitcoin · GitHub
 20 2018-01-30 09:40:37	0|gmaxwell|promag: does that actually make a measurable difference? I would assume very few transactions are fromme, so the early termination would never fire.
 21 2018-01-30 09:40:55	0|gmaxwell|I'd expect a lot bigger gain from things like hoisting the locking cs_wallet out of the inner loop or similar.
 22 2018-01-30 09:43:47	0|promag|GetDebit(tx) is called from a lot of places
 23 2018-01-30 09:43:53	0|promag|it also avoid unnecessary IsMine calls
 24 2018-01-30 09:43:58	0|promag|not saying it's a big performance improvement
 25 2018-01-30 09:44:03	0|promag|regarding locks, IMO only after 0.16 is branched
 26 2018-01-30 09:44:23	0|wumpus|we really need benchmarking for wallet things
 27 2018-01-30 09:44:43	0|wumpus|without that, these kind of changes are really hard to evaluate, whether it's worth complicating the code more
 28 2018-01-30 09:45:30	0|promag|anyway, in that case, I'd say it's a pretty obvious improvement
 29 2018-01-30 09:46:34	0|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?
 30 2018-01-30 09:47:35	0|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.
 31 2018-01-30 09:48:09	0|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.
 32 2018-01-30 09:48:30	0|promag|gmaxwell: I think the semantic of IsFromMe it better explained in that pr
 33 2018-01-30 09:48:57	0|promag|"if from me if at least one input is debit"
 34 2018-01-30 09:49:06	0|promag|s/if/is
 35 2018-01-30 09:49:59	0|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).
 36 2018-01-30 09:50:03	0|promag|also, for big wallets, with thousands of transactions, thousands of keys, avoiding IsMine is important
 37 2018-01-30 09:50:43	0|gmaxwell|I'm only commenting on the IsFromMe early termination.
 38 2018-01-30 09:50:45	0|promag|gmaxwell: sure, for the worst case the performance is the same (although it avoids summing)
 39 2018-01-30 09:50:58	0|promag|also not sure about the average case
 40 2018-01-30 09:51:22	0|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.
 41 2018-01-30 09:52:28	0|promag|gmaxwell: I'll try to measure it
 42 2018-01-30 09:52:40	0|promag|gmaxwell: care to see #12297
 43 2018-01-30 09:52:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/12297 | Improve CWallet::IsAllFromMe for false results by promag · Pull Request #12297 · bitcoin/bitcoin · GitHub
 44 2018-01-30 09:56:23	0|promag|brb
 45 2018-01-30 09:56:59	0|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.)
 46 2018-01-30 09:57:03	0|gmaxwell|ha
 47 2018-01-30 09:57:16	0|gmaxwell|int nDepth = pcoin->GetDepthInMainChain();
 48 2018-01-30 09:57:16	0|gmaxwell|see this is silly, for example:
 49 2018-01-30 09:57:17	0|gmaxwell|continue;
 50 2018-01-30 09:57:17	0|gmaxwell|if (nDepth < (pcoin->IsFromMe(ISMINE_ALL) ? 0 : 1))
 51 2018-01-30 09:59:28	0|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.
 52 2018-01-30 10:00:43	0|gmaxwell|(actually that code looks redundant with the efficient IsTrusted check above)
 53 2018-01-30 10:04:53	0|gmaxwell|but don't listen to me, I should be asleep. :)
 54 2018-01-30 10:55:17	0|wumpus|need review for https://github.com/bitcoin/bitcoin/pull/12266   https://github.com/bitcoin/bitcoin/pull/12274
 55 2018-01-30 10:55:26	0|wumpus|otherhwise I'm going to branch off 0.16 without them
 56 2018-01-30 11:11:08	0|meshcollider|I'd like to review the fd one to help but its beyond my skill level I'm afraid
 57 2018-01-30 11:12:19	0|wumpus|you're not alone in that
 58 2018-01-30 11:12:22	0|wumpus|I'm confused by it too
 59 2018-01-30 11:12:47	0|wumpus|please do review BlueMatt's though
 60 2018-01-30 11:13:03	0|wumpus|that one is not so hard to grasp as I thought initially
 61 2018-01-30 11:13:27	0|wumpus|oh you did!
 62 2018-01-30 11:13:28	0|wumpus|thanks
 63 2018-01-30 11:19:24	0|gmaxwell|ut-sleepy-ACK from me, I'll try to setup some kind of shutdown loop to test it.
 64 2018-01-30 11:20:08	0|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.
 65 2018-01-30 11:21:08	0|wumpus|yes I'd also vote for including #12266, but I think it's quite harmless to hold up on #12274 for now
 66 2018-01-30 11:21:09	0|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
 67 2018-01-30 11:21:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/12274 | http: avoid fd exhaustion by theuni · Pull Request #12274 · bitcoin/bitcoin · GitHub
 68 2018-01-30 11:21:37	0|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
 69 2018-01-30 11:22:07	0|wumpus|also it's regression in 0.15 and it only comes up under rare conditions
 70 2018-01-30 11:22:37	0|gmaxwell|when I looked at the limiter I had questions about concurrency of the limiter function and didn't know where to start looking.
 71 2018-01-30 11:22:38	0|wumpus|sorry I mean it's *not* regression in 0.16
 72 2018-01-30 11:23:18	0|wumpus|it's an issue that has existed since we started using libevent for http, and very hard to trigger
 73 2018-01-30 11:23:56	0|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 :(
 74 2018-01-30 11:23:57	0|gmaxwell|right. we could also cut down our FD usage in some other way to give it more safty margin, I suppose?
 75 2018-01-30 11:25:04	0|gmaxwell|e.g. raise MIN_CORE_FILEDESCRIPTORS
 76 2018-01-30 11:25:11	0|wumpus|right - maybe the accounting of fds (how much is reserved for what) is also incorrect
 77 2018-01-30 11:25:31	0|wumpus|anyhow I think this is a post-0.16 issue
 78 2018-01-30 11:34:40	0|wumpus|milestone 0.16.1 has the fd changes now: https://github.com/bitcoin/bitcoin/milestone/34
 79 2018-01-30 12:04:58	0|bitcoin-git|13bitcoin/06master 14082a61c 15Matt Corallo: Move scheduler/threadGroup into common-init instead of per-app...
 80 2018-01-30 12:04:58	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7936446268e2...3448907a68e0
 81 2018-01-30 12:04:59	0|bitcoin-git|13bitcoin/06master 143448907 15Wladimir J. van der Laan: Merge #12266: Move scheduler/threadGroup into common-init instead of per-app...
 82 2018-01-30 12:05:43	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12266: Move scheduler/threadGroup into common-init instead of per-app (06master...062018-01-common-init) 02https://github.com/bitcoin/bitcoin/pull/12266
 83 2018-01-30 12:13:50	0|meshcollider|wumpus: so branch and tag 0.16 now then?
 84 2018-01-30 12:13:57	0|meshcollider|Is there anything else left to do
 85 2018-01-30 12:15:08	0|meshcollider|Oh, have you done the manpages update thing
 86 2018-01-30 12:21:54	0|wumpus|meshcollider: that needs to be done after the branch, after bumping version, before tagging
 87 2018-01-30 12:23:14	0|wumpus|but yes I intend to branch now
 88 2018-01-30 12:23:37	0|meshcollider|ooh ok yep
 89 2018-01-30 12:23:41	0|meshcollider|\o/
 90 2018-01-30 12:44:34	0|bitcoin-git|13bitcoin/06master 1410847fe 15Wladimir J. van der Laan: qt: Periodic translations update...
 91 2018-01-30 12:44:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/10847fe2d82bd4ffe5be499fd9ad64b6fee78a33
 92 2018-01-30 12:51:21	0|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?
 93 2018-01-30 12:52:38	0|gmaxwell|xabbix: the last thing.
 94 2018-01-30 12:53:49	0|xabbix|gmaxwell: thanks, are there cases that a new node will get an 'old' transaction? what are those cases?
 95 2018-01-30 12:54:01	0|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.
 96 2018-01-30 12:54:05	0|gmaxwell|someone relays it.
 97 2018-01-30 12:54:21	0|gmaxwell|the sender and reciever of the txn will rebroadcast every once in a while, normally...
 98 2018-01-30 12:54:48	0|gmaxwell|and random other people might do so for whatever reasons they feel like.
 99 2018-01-30 12:54:54	0|xabbix|gmaxwell, wumpus: ok, that makes a lot more sense now. thanks.
100 2018-01-30 12:55:07	0|gmaxwell|it won't cross peers that already have it, however.
101 2018-01-30 12:57:33	0|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?
102 2018-01-30 12:58:24	0|gmaxwell|it's not relayed.
103 2018-01-30 12:58:47	0|xabbix|it's = height?
104 2018-01-30 12:58:53	0|wumpus|transactions generated by modern wallets will usually be time-locked to the current (or current-1) block
105 2018-01-30 12:59:49	0|gmaxwell|xabbix: no time value is relayed.
106 2018-01-30 13:00:14	0|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
107 2018-01-30 13:01:00	0|wumpus|(the latter making it impossible to know for sure)
108 2018-01-30 13:03:06	0|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.
109 2018-01-30 13:03:11	0|gmaxwell|The heights (IIRC) are not.
110 2018-01-30 13:04:17	0|bitcoin-git|13bitcoin/06master 14125f4a4 15Anthony Towns: [tests] Require all tests to follow naming convention
111 2018-01-30 13:04:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/10847fe2d82b...8d573198638e
112 2018-01-30 13:04:18	0|bitcoin-git|13bitcoin/06master 148d57319 15MarcoFalke: Merge #12252: Require all tests to follow naming convention...
113 2018-01-30 13:04:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12252: Require all tests to follow naming convention (06master...06rename_tests_no_leeway) 02https://github.com/bitcoin/bitcoin/pull/12252
114 2018-01-30 13:05:25	0|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?
115 2018-01-30 13:05:42	0|xabbix|given my machine clock is set correctly :)
116 2018-01-30 13:07:59	0|bitcoin-git|13bitcoin/060.16 145c242b2 15Wladimir J. van der Laan: build: bump version to 0.16.0...
117 2018-01-30 13:07:59	0|bitcoin-git|[13bitcoin] 15laanwj created 060.16 (+2 new commits): 02https://github.com/bitcoin/bitcoin/compare/5c242b211eda^...66bc647e8c65
118 2018-01-30 13:08:00	0|bitcoin-git|13bitcoin/060.16 1466bc647 15Wladimir J. van der Laan: doc: Update manpages to 0.16.0...
119 2018-01-30 13:08:27	0|gmaxwell|xabbix: why do you think it was two weeks ago?
120 2018-01-30 13:09:10	0|xabbix|I think that I saw a `time` value when I queried getmempoolentry that is before I created the machine I was running on.
121 2018-01-30 13:09:21	0|xabbix|I'm not 100% sure just trying to figure out if that's possible.
122 2018-01-30 13:09:32	0|bitcoin-git|13bitcoin/06master 144602dc7 15Wladimir J. van der Laan: build: Bump version to 0.16.99...
123 2018-01-30 13:09:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/4602dc704ae83bd08d0d6e835b760cc9ab8fea37
124 2018-01-30 13:10:04	0|wumpus|I guess that should not be possible, at least if you didn't install a mempool.dat somehow
125 2018-01-30 13:11:12	0|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.
126 2018-01-30 13:11:28	0|gmaxwell|if you had an older mempool.dat or something then that would do it.
127 2018-01-30 13:12:48	0|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
128 2018-01-30 13:25:39	0|bitcoin-git|13bitcoin/06master 149cb2309 15Wladimir J. van der Laan: doc: Update manpages to 0.16.99...
129 2018-01-30 13:25:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/9cb2309050880c2887b4b5f7a7231e4fc6dc3f47
130 2018-01-30 13:29:03	0|wumpus|going to tag 0.16.0rc1 in a bit on the 0.16 branch
131 2018-01-30 13:34:47	0|wumpus|* [new tag]         v0.16.0rc1 -> v0.16.0rc1
132 2018-01-30 13:45:08	0|jnewbery|\o/
133 2018-01-30 13:55:59	0|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.
134 2018-01-30 13:57:38	0|jnewbery|you'll want to look at the AcceptToMemoryPoolWithTime() function in validation.cpp and the places where it's called
135 2018-01-30 14:05:15	0|promag|\o/
136 2018-01-30 14:05:35	0|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
137 2018-01-30 15:25:23	0|achow101|yay!
138 2018-01-30 15:36:06	0|wumpus|I've added changelog and author information to https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.16.0-Release-notes
139 2018-01-30 15:44:31	0|wumpus|please help check for duplicate authors and such
140 2018-01-30 15:52:03	0|instagibbs|wumpus, Donal OConnor and donaloconnor
141 2018-01-30 15:52:45	0|wumpus|instagibbs: it's a wiki, you can edit it :)
142 2018-01-30 16:20:19	0|luke-jr|sdaftuar: I don't understand this question: https://github.com/bitcoin/bips/pull/639#issuecomment-361642505
143 2018-01-30 16:21:17	0|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?
144 2018-01-30 16:23:04	0|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..
145 2018-01-30 16:23:13	0|sdaftuar|BIP 123 came after BIP 90
146 2018-01-30 16:23:21	0|sdaftuar|it was applied to that doc without my approval!
147 2018-01-30 16:23:50	0|sdaftuar|doesn't the author have the final say on changes?
148 2018-01-30 16:24:26	0|luke-jr|nobody objected before BIP 123 became activate..?
149 2018-01-30 16:25:00	0|sdaftuar|no one tagged me to let me know my document was being changed either
150 2018-01-30 16:25:32	0|luke-jr|the document wasn't really changed, just the headers, which was based on the content
151 2018-01-30 16:26:50	0|wumpus|the author is supposed to be asked in case of changes
152 2018-01-30 16:26:58	0|luke-jr|maybe I don't understand the problem - all it does is describe the BIP
153 2018-01-30 16:27:05	0|luke-jr|wumpus: to the BIP itself, yes
154 2018-01-30 16:27:15	0|wumpus|yes, I don't know the details
155 2018-01-30 16:27:34	0|sdaftuar|the point of the BIP is to explain why merely labeling things as "sfot forks" or "hard forks" is deficient
156 2018-01-30 16:28:09	0|sdaftuar|so applying BIP 123's labels to it doesn't make sense
157 2018-01-30 16:28:22	0|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
158 2018-01-30 16:28:27	0|sdaftuar|no
159 2018-01-30 16:30:03	0|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?
160 2018-01-30 16:30:17	0|luke-jr|the headers aren't part of the document
161 2018-01-30 16:30:26	0|sdaftuar|ah.  we should move them out then
162 2018-01-30 16:30:50	0|luke-jr|having them in separate files would just be needlessly confusing to readers IMO
163 2018-01-30 16:32:14	0|sdaftuar|so i don't have editorial rights to the headers?
164 2018-01-30 16:33:58	0|luke-jr|"The BIP editors monitor BIP changes, and update BIP headers as appropriate."
165 2018-01-30 16:34:25	0|luke-jr|I don't see why you would want to make the headers inaccurate anyway
166 2018-01-30 16:34:43	0|sdaftuar|i think bip 123 is misguided, in its naive labeling of consensus changes as soft forks or hard forks
167 2018-01-30 16:34:59	0|sdaftuar|bip 90 demonstrates this
168 2018-01-30 16:35:11	0|sdaftuar|did you not see the quote i pasted from bip 123's author?
169 2018-01-30 16:35:20	0|sdaftuar|i think that quote reflects a view held by many
170 2018-01-30 16:35:24	0|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
171 2018-01-30 16:35:40	0|luke-jr|bbiab
172 2018-01-30 16:37:13	0|provoostenator|I see it's Gitian o'clock?
173 2018-01-30 16:39:47	0|achow101|hmm, did I screw up my gitian build? The files produced are 0.15.99 not 0.16
174 2018-01-30 16:40:16	0|sdaftuar|luke-jr: it seems to me that BIP123's activation should have required agreement from the BIP-authors that it was applied to
175 2018-01-30 16:43:23	0|BlueMatt|has anyone ever seen a case when compiling qt where flags arent being passed through when compiling the qt stuff properly?
176 2018-01-30 16:44:03	0|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
177 2018-01-30 16:44:18	0|BlueMatt|obviously wiped ccache/git clean'd
178 2018-01-30 16:44:51	0|BlueMatt|maybe cfields has some autotools-debug tips?
179 2018-01-30 16:45:19	0|cfields|BlueMatt: you forget the include, maybe?
180 2018-01-30 16:46:00	0|cfields|(config/bitcoin-config.h)
181 2018-01-30 16:46:07	0|BlueMatt|this is 0.15.1, no modifications
182 2018-01-30 16:47:21	0|cfields|BlueMatt: i'm not sure what you mean. You get "no such slot" at runtime, or build time?
183 2018-01-30 16:47:37	0|BlueMatt|runtime
184 2018-01-30 16:48:03	0|BlueMatt|and like cant click the top tabs to switch views cause of missing slot
185 2018-01-30 16:49:07	0|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/
186 2018-01-30 16:49:14	0|cfields|BlueMatt: sounds like --disable-wallet :)
187 2018-01-30 16:49:28	0|BlueMatt|nope, not --disable-wallet, and configure output lists wallet enabled
188 2018-01-30 16:49:41	0|BlueMatt|i mean also the image on the splash screen somehow didnt get compiled in so the background is blank
189 2018-01-30 16:50:31	0|cfields|BlueMatt: no clue. Sounds like maybe something didn't get regenerated when you switched tags/branches ?
190 2018-01-30 16:50:52	0|cfields|nm, i see you cleaned
191 2018-01-30 16:51:15	0|BlueMatt|full git directory wipe, re-autogen/configure, even wiped ccache
192 2018-01-30 16:51:24	0|BlueMatt|its even in a vm that just got rebooted
193 2018-01-30 16:51:29	0|BlueMatt|sooooo....wat
194 2018-01-30 16:51:43	0|cfields|achow101: bitcoin-0.16.0-osx-unsigned.dmg
195 2018-01-30 16:51:45	0|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.
196 2018-01-30 16:51:59	0|achow101|cfields: I fucked up
197 2018-01-30 16:52:47	0|cfields|BlueMatt: you've verified that the ENABLE_WALLET stuff is actually being built?
198 2018-01-30 16:53:12	0|BlueMatt|it loads the wallet, lists transactions, shows a balance, etc
199 2018-01-30 16:53:15	0|BlueMatt|sooo...yes?
200 2018-01-30 16:53:17	0|cfields|BlueMatt: oh (prepare for possible red herring), kinda sounds like a define is missing when the forms are built
201 2018-01-30 16:54:03	0|BlueMatt|thats what I'm thinking, kinda, but i know almost nothing about qt/autotools
202 2018-01-30 16:54:28	0|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?
203 2018-01-30 16:54:41	0|BlueMatt|only change was upgrading packages....is it possible qt is now mis-parsing the .h?
204 2018-01-30 16:55:52	0|cfields|was qt itself updated?
205 2018-01-30 16:56:13	0|BlueMatt|i believe so, yes
206 2018-01-30 16:56:19	0|cfields|BlueMatt: all qt-generated files are bound to the versions that created them
207 2018-01-30 16:56:19	0|provoostenator|I wasnt' the first ot notice: https://github.com/bitcoin-core/docs/pull/6
208 2018-01-30 16:56:56	0|cfields|so moc 1.2.3 will create headers meant to be linked against qt headers/libs v1.2.3
209 2018-01-30 16:57:00	0|BlueMatt|git clean -f -x -d'd :p
210 2018-01-30 16:57:37	0|cfields|provoostenator: thanks :)
211 2018-01-30 16:57:40	0|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)
212 2018-01-30 16:58:19	0|cfields|BlueMatt: the defines are passed along. Somehow for you they're not...
213 2018-01-30 16:58:20	0|achow101|provoostenator: the OS you build on doesn't really matter since the actual build happens within another vm/container
214 2018-01-30 16:58:39	0|achow101|that vm/container will be the same OS for everyone
215 2018-01-30 16:58:57	0|cfields|BlueMatt: https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.qt.include#L455
216 2018-01-30 16:59:53	0|achow101|cfields: my gitian build has this error: https://0bin.net/paste/S+squMjJftoksqm-#HEzfaPoLdoUUf4qz5ZxzMrrbHtdelDjzCYaVCCDHKQs
217 2018-01-30 17:00:04	0|provoostenator|achow101 someone needs to draw a picture of that inception / VM (Virtual Matroesjka) situation
218 2018-01-30 17:00:19	0|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
219 2018-01-30 17:01:14	0|cfields|BlueMatt: i wonder if you somehow got messed up by the #include "foo.h" -> #include <foo.h>
220 2018-01-30 17:01:43	0|cfields|BlueMatt: out-of-tree ?
221 2018-01-30 17:01:56	0|cfields|ooh, i bet that's it...
222 2018-01-30 17:01:57	0|BlueMatt|in tree
223 2018-01-30 17:02:01	0|BlueMatt|and this is 0.15.1
224 2018-01-30 17:02:04	0|BlueMatt|so pre <foo.h>
225 2018-01-30 17:02:29	0|BlueMatt|i mean clearly qt broke our build, question is if we need to work around it or what
226 2018-01-30 17:02:29	0|cfields|BlueMatt: got a stale bitcoin-config.h around somewhere?
227 2018-01-30 17:02:35	0|BlueMatt|git clean -f -x -d :p
228 2018-01-30 17:03:13	0|cfields|damn, right, i was banking on you saying "out-of-tree"
229 2018-01-30 17:03:42	0|cfields|achow101: I'm betting you just ran out of mem
230 2018-01-30 17:04:05	0|cfields|achow101: I haven't built linux yet though
231 2018-01-30 17:04:06	0|achow101|cfields: probably. I forgot to allocate more memory to kvm when I did this build
232 2018-01-30 17:05:15	0|cfields|BlueMatt: i'm not sure what to tell you. Can you give it a shot with 0.16 so we can start there?
233 2018-01-30 17:06:26	0|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
234 2018-01-30 17:09:05	0|BlueMatt|yes, same bug
235 2018-01-30 17:09:18	0|BlueMatt|gotoOverviewPage (etc) doesn't show up in src/qt/moc_bitcoingui.cpp post-build
236 2018-01-30 17:09:42	0|cfields|ok
237 2018-01-30 17:09:48	0|cfields|got a list of updated packages?
238 2018-01-30 17:10:20	0|BlueMatt|errr....probably, sec
239 2018-01-30 17:13:41	0|BlueMatt|cfields: (roughly, there's a few extras there) http://termbin.com/3zh4
240 2018-01-30 17:13:59	0|BlueMatt|i mean essentially all the things...gcc/boost/qt/etc
241 2018-01-30 17:14:19	0|cfields|BlueMatt: thanks. What distro/version?
242 2018-01-30 17:14:26	0|cfields|I already have a hunch
243 2018-01-30 17:14:34	0|BlueMatt|its an arch vm
244 2018-01-30 17:14:38	0|BlueMatt|so...all rolling release crap
245 2018-01-30 17:15:09	0|cfields|ok
246 2018-01-30 17:15:26	0|cfields|https://github.com/qt/qtbase/commit/abcf558e49d5e8c20eda14badc30e93e2e9cba32#diff-7680dae0477922e25856c03d1058d2b7
247 2018-01-30 17:15:58	0|cfields|so they've recently switched up their option parsing. I'm wondering if they broke -D somehow
248 2018-01-30 17:16:21	0|cfields|(i realize you said it was parsed, but maybe include handling after that is busted)
249 2018-01-30 17:16:56	0|BlueMatt|no, because BITCOIN_CONFIG_H is clearly being used
250 2018-01-30 17:17:05	0|BlueMatt|so it has to be some include option blowing up
251 2018-01-30 17:17:25	0|BlueMatt|yea
252 2018-01-30 17:26:02	0|BlueMatt|cfields: did you find anything in qt git?
253 2018-01-30 17:26:27	0|cfields|BlueMatt: still looking, nothing obvious
254 2018-01-30 17:26:36	0|cfields|BlueMatt: can you try a depends build just for a control?
255 2018-01-30 17:26:41	0|BlueMatt|ugh
256 2018-01-30 17:26:52	0|BlueMatt|I mean I can revert to the older vm image and see what happens
257 2018-01-30 17:27:38	0|cfields|well sure, but it'd be helpful to have good/bad moc side-by-side
258 2018-01-30 17:37:56	0|wumpus|I don't get it, feature_uacomment.py is failing on travis, but I can't reproduce it locally
259 2018-01-30 17:37:58	0|wumpus|https://travis-ci.org/bitcoin/bitcoin/jobs/335143070
260 2018-01-30 17:38:57	0|wumpus|"Error: Total length of network version string (285) exceeds maximum length (256). Reduce the number or size of uacomments."
261 2018-01-30 17:40:45	0|sdaftuar|looks like the test is expecting a slightly different error string (286 instead of 285), and that is why the test is failing
262 2018-01-30 17:40:51	0|cfields|heh, 285 != 286
263 2018-01-30 17:40:56	0|cfields|yep
264 2018-01-30 17:41:02	0|wumpus|but I don't understand where that comes from
265 2018-01-30 17:41:20	0|sdaftuar|yeah me either
266 2018-01-30 17:41:38	0|wumpus|oh maybe 0.16.0 i.s.o 0.16.99
267 2018-01-30 17:41:44	0|wumpus|what a dumb test in that case
268 2018-01-30 17:41:48	0|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
269 2018-01-30 17:42:16	0|sdaftuar|wumpus: ouch
270 2018-01-30 17:42:18	0|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
271 2018-01-30 17:43:13	0|wumpus|sdaftuar: cfields: yep that's it, I'm going to remove the check for a specific number
272 2018-01-30 17:43:15	0|provoostenator|I'll take a snapshot of my VM before doing that...
273 2018-01-30 17:43:35	0|wumpus|can reproduce it locally now, too, I was testing with master
274 2018-01-30 17:44:15	0|cfields|wumpus: makes sense. I vaguely remember a conversation about using exit codes rather than testing strings. Guess that didn't pan out.
275 2018-01-30 17:44:40	0|wumpus|well it makes sense that it checks the error message, it just doesn't have to be so specific
276 2018-01-30 17:49:02	0|cfields|BlueMatt: i'm not seeing anything obvious :\
277 2018-01-30 17:58:53	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #12302: test: Make ua_comment test pass on 0.16.0 (06master...062017_01_uacomment_test_fix) 02https://github.com/bitcoin/bitcoin/pull/12302
278 2018-01-30 18:36:53	0|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
279 2018-01-30 18:37:04	0|arubi|oh this is re. 0.16.0rc1
280 2018-01-30 18:38:55	0|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 :)
281 2018-01-30 18:38:55	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12302: test: Make ua_comment test pass on 0.16.0 (06master...062017_01_uacomment_test_fix) 02https://github.com/bitcoin/bitcoin/pull/12302
282 2018-01-30 18:43:25	0|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
283 2018-01-30 18:43:32	0|jnewbery|whichever you prefer
284 2018-01-30 18:43:48	0|wumpus|I'm just tired of this, wanted to quickly fix the test then everyone wants to push their own solution
285 2018-01-30 18:44:52	0|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
286 2018-01-30 18:45:43	0|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
287 2018-01-30 18:45:48	0|jnewbery|seems over-engineered for fixing a single case. I think here it just makes sense to match on the substring
288 2018-01-30 18:46:09	0|jnewbery|Sorry - I seem to have touched a raw nerve
289 2018-01-30 18:46:40	0|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
290 2018-01-30 18:46:54	0|jnewbery|but if you prefer your way, that obviously also achieves the same
291 2018-01-30 18:46:59	0|wumpus|no, I don't think matching a partial message only is better than ignoring the few characters we don't care about
292 2018-01-30 18:47:42	0|jnewbery|ok, in that case re-open the PR
293 2018-01-30 18:47:51	0|wumpus|I thought about that too but thought this would cover it better
294 2018-01-30 18:48:02	0|sdaftuar|let's merge it and move on... 0.16.0 awais
295 2018-01-30 18:48:04	0|sdaftuar|awaits*
296 2018-01-30 18:48:32	0|jnewbery|many of the test cases match on substring. I agree that regex matching would be better in the general case
297 2018-01-30 18:48:33	0|wumpus|0.16.0 is not blocked on this, we already tagged rc1
298 2018-01-30 18:52:27	0|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
299 2018-01-30 18:54:23	0|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.
300 2018-01-30 18:54:24	0|wumpus|yes, sorry for overreacting
301 2018-01-30 18:59:13	0|wumpus|though I don't think it was unreasonable to try to expand the test framework to do something more than it does
302 2018-01-30 18:59:39	0|wumpus|I understand the consensus code for bitcoin is set in stone, but surely the interface for the test framework isn't
303 2018-01-30 19:06:37	0|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
304 2018-01-30 19:06:56	0|jnewbery|But we don't need to make this a big thing. I can ACK your PR :)
305 2018-01-30 19:17:30	0|provoostenator|"lxc-execute: start.c: lxc_spawn: 1079 Failed to find gateway addresses"
306 2018-01-30 19:18:26	0|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
307 2018-01-30 19:20:37	0|provoostenator|Ah wait, I shouldn't copy paste those example IP addresses probably. Vaguely remember making that mistake last time.
308 2018-01-30 19:21:04	0|wumpus|oh great now that I pushed something else I cannot reopen the PR anymore
309 2018-01-30 19:21:24	0|wumpus|crap github
310 2018-01-30 19:22:16	0|jnewbery|reset to the old commit, push, open PR, reset to the new commit, force push
311 2018-01-30 19:23:01	0|wumpus|some other time
312 2018-01-30 19:34:21	0|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.
313 2018-01-30 19:35:41	0|provoostenator|https://botbot.me/freenode/bitcoin-core-dev/2017-02-21/?msg=81301776&page=1
314 2018-01-30 19:53:46	0|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
315 2018-01-30 19:54:14	0|provoostenator|And of course, Linux being Linux, it just silently fails and let the user shoot themselves in the foot
316 2018-01-30 19:54:56	0|goatpig|does Core use zeromq?
317 2018-01-30 19:55:08	0|achow101|goatpig: yes
318 2018-01-30 19:55:22	0|goatpig|isn't Core under the MIT license?
319 2018-01-30 19:56:54	0|luke-jr|Core *offers* a zeromq service, but "using" it is ill-defined in this case
320 2018-01-30 19:57:01	0|luke-jr|goatpig: yes, and?
321 2018-01-30 19:57:21	0|goatpig|isn't LGPL3 (zmq) incompatible with MIT?
322 2018-01-30 19:57:38	0|gmaxwell|No, not at all.
323 2018-01-30 19:58:00	0|luke-jr|goatpig: LGPL is Lesser GPL. It specifically allows non-GPL stuff to use it.
324 2018-01-30 19:58:01	0|goatpig|with version of GPL is incompatible with MIT then? AGPL?
325 2018-01-30 19:58:13	0|goatpig|ah that's what got me confused I guess
326 2018-01-30 19:58:20	0|luke-jr|GPL and AGPL are incompatible with non-free software, but still compatible with MIT
327 2018-01-30 19:58:23	0|gmaxwell|Nothing is incompatible with MIT, some things are more restrictive and we prefer to not use them.
328 2018-01-30 19:58:30	0|luke-jr|they're NOT compatible with OpenSSL, however, which is another dependency of ours..
329 2018-01-30 19:59:02	0|gmaxwell|(luke's They is GPL and AGPL)
330 2018-01-30 19:59:15	0|goatpig|so a MIT project can make use a LGPL dependency just fine?
331 2018-01-30 19:59:27	0|gmaxwell|Yes.
332 2018-01-30 19:59:33	0|goatpig|ok thanks
333 2018-01-30 19:59:52	0|luke-jr|only thing to keep in mind is, you still need to release source for the dependency per the terms
334 2018-01-30 20:00:49	0|goatpig|due noted
335 2018-01-30 20:02:23	0|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
336 2018-01-30 20:02:38	0|cfields|jonasschnelli: ping
337 2018-01-30 20:03:14	0|luke-jr|cfields: well, I think as long as we depend on OpenSSL, the conflict would prevent distribution
338 2018-01-30 20:03:25	0|provoostenator|Still not seeing the br0 interface though.
339 2018-01-30 20:03:36	0|cfields|hmm?
340 2018-01-30 20:05:47	0|gmaxwell|cfields: openssl has a GPL incompatible license (it's advertising clause bsd)
341 2018-01-30 20:08:53	0|cfields|huh
342 2018-01-30 20:09:27	0|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?
343 2018-01-30 20:10:03	0|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
344 2018-01-30 20:12:48	0|provoostenator|Made some progress: https://github.com/bitcoin-core/docs/issues/15
345 2018-01-30 20:15:52	0|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
346 2018-01-30 20:18:53	0|bitcoin-git|[13bitcoin] 15laanwj reopened pull request #12302: test: Make ua_comment test pass on 0.16.0 (06master...062017_01_uacomment_test_fix) 02https://github.com/bitcoin/bitcoin/pull/12302
347 2018-01-30 20:49:10	0|provoostenator|lxc-execute: conf.c: setup_rootfs: 1279 failed to mount rootfs
348 2018-01-30 20:56:26	0|bitcoin-git|13bitcoin/06master 14aac6bce 15Wladimir J. van der Laan: test: Make ua_comment test pass on 0.16.0...
349 2018-01-30 20:56:26	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9cb230905088...f0295becbf3e
350 2018-01-30 20:56:27	0|bitcoin-git|13bitcoin/06master 14f0295be 15MarcoFalke: Merge #12302: test: Make ua_comment test pass on 0.16.0...
351 2018-01-30 20:57:23	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12302: test: Make ua_comment test pass on 0.16.0 (06master...062017_01_uacomment_test_fix) 02https://github.com/bitcoin/bitcoin/pull/12302
352 2018-01-30 20:58:44	0|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...
353 2018-01-30 20:59:58	0|provoostenator|lxc-execute: conf.c: setup_pts: 1407 No such file or directory - failed to create '/dev/pts'
354 2018-01-30 21:00:17	0|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.
355 2018-01-30 21:04:28	0|wumpus|you definitely shouldn't have to replace target-something with a directory
356 2018-01-30 21:04:47	0|wumpus|that file should be auto-generated
357 2018-01-30 21:05:56	0|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
358 2018-01-30 21:15:59	0|provoostenator|Mmm, so maybe something silently failed when creating the base image?
359 2018-01-30 21:16:23	0|provoostenator|Ah I see, that's why it mounting that file.
360 2018-01-30 21:19:08	0|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".
361 2018-01-30 21:20:47	0|wumpus|the sudo resolve warning is harmless
362 2018-01-30 21:22:19	0|provoostenator|Yeah, I think it's actually building now. Hooray!
363 2018-01-30 21:34:40	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #12304: Backport 12302 (060.16...06backport_12302) 02https://github.com/bitcoin/bitcoin/pull/12304
364 2018-01-30 21:46:22	0|michagogo|Hrm
365 2018-01-30 21:46:27	0|michagogo|http://paste.ubuntu.com/26491672/
366 2018-01-30 21:46:35	0|MarcoFalke|Anyone with block bit want to kick the markov chain generator https://github.com/bitcoin/bitcoin/pull/11771#issuecomment-361742013
367 2018-01-30 21:46:44	0|michagogo|Got a segfault while building
368 2018-01-30 21:46:59	0|MarcoFalke|WalterBoles
369 2018-01-30 21:51:35	0|MarcoFalke|wumpus: ^
370 2018-01-30 21:52:05	0|wumpus|MarcoFalke: looking
371 2018-01-30 21:58:18	0|michagogo|provoostenator: iirc my past experience has been that Ubuntu is much smoother as a host compared to Debian
372 2018-01-30 21:58:46	0|michagogo|I pretty much just followed the gitian readme
373 2018-01-30 22:00:00	0|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)
374 2018-01-30 22:05:26	0|michagogo|WTF? Now it failed somewhere in the Qt build
375 2018-01-30 22:06:06	0|bitcoin-git|13bitcoin/060.16 146c2788c 15Wladimir J. van der Laan: test: Make ua_comment test pass on 0.16.0...
376 2018-01-30 22:06:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.16: 02https://github.com/bitcoin/bitcoin/commit/6c2788c7c8d45ac8f38e998c8a9739efdd0b6d18
377 2018-01-30 22:09:16	0|bitcoin-git|[13bitcoin] 15jamesob opened pull request #12305: Clarify -conf help message to mention datadir path prefix (06master...06jamesob/conf-flag-path-help) 02https://github.com/bitcoin/bitcoin/pull/12305
378 2018-01-30 22:15:30	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12304: [qa] 0.16: Backport 12302 (060.16...06backport_12302) 02https://github.com/bitcoin/bitcoin/pull/12304
379 2018-01-30 22:15:43	0|jamesob|wumpus: worth clarifying other path-accepting configuration option help messages, or should I just close the PR?
380 2018-01-30 22:16:16	0|wumpus|jamesob: I don't know, we might want to document it somewhere in one place instead of for each argument separately
381 2018-01-30 22:16:58	0|wumpus|for things like that it helps to at least try to be consistent
382 2018-01-30 22:17:48	0|wumpus|no arguments to bitcoind are relative to the current directory
383 2018-01-30 22:20:34	0|jamesob|yeah, agree. worth a paragraph between Usage and Options, or maybe there's some other place this is already documented?
384 2018-01-30 22:21:42	0|wumpus|I don't think it's documented anywhere, agree that it should be
385 2018-01-30 22:34:24	0|bitcoin-git|[13bitcoin] 15axvr opened pull request #12306: Docs: Improvements to UNIX documentation (06master...06fix-docs) 02https://github.com/bitcoin/bitcoin/pull/12306
386 2018-01-30 22:49:26	0|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.
387 2018-01-30 22:49:42	0|sdaftuar|is there something you still don't understand about my view?
388 2018-01-30 22:50:13	0|jamesob|paths like "./bitcoin.conf" are interpreted as being relative to datadir as well; is this behavior we want to retain?
389 2018-01-30 22:55:11	0|denis2342|hi
390 2018-01-30 22:55:50	0|denis2342|I just tested bitcoin 0.16.0rc1 on freebsd and it runs fine so far
391 2018-01-30 23:04:37	0|promag|ryanofsky: regarding https://github.com/bitcoin/bitcoin/pull/12287/files#r164570542
392 2018-01-30 23:05:19	0|promag|so if a block is in the active chain, nChainTx is final?
393 2018-01-30 23:06:40	0|ryanofsky|i think so because if it's been in the active chain, then it's been validated, and nChainTx should be set
394 2018-01-30 23:08:15	0|promag|you say "and remove an existing lock"
395 2018-01-30 23:08:18	0|promag|which one?
396 2018-01-30 23:08:55	0|promag|my point is that cs_main is already held in all callers expect ClientModel::getVerificationProgress
397 2018-01-30 23:09:08	0|promag|and that jonas adds
398 2018-01-30 23:10:01	0|ryanofsky|the lock here could be removed: https://github.com/bitcoin/bitcoin/pull/12287/files#diff-b2bb174788c7409b671c46ccc86034bdR1681
399 2018-01-30 23:10:03	0|promag|but I agree that less locks is better
400 2018-01-30 23:10:14	0|gmaxwell|Correct software is better. :)
401 2018-01-30 23:12:21	0|promag|right, in this case only comment per se doesn't prevent problems
402 2018-01-30 23:13:45	0|promag|for instance, in that case ryanofsky, I would lock from https://github.com/bitcoin/bitcoin/pull/12287/files#diff-b2bb174788c7409b671c46ccc86034bdR1678 to L1690
403 2018-01-30 23:14:22	0|promag|ah sorry maybe that's not possible, because of ShowProgress
404 2018-01-30 23:15:35	0|ryanofsky|actually seems like there is another unnecessary lock below that
405 2018-01-30 23:17:32	0|promag|how about avoid duplicate calls to GuessVerificationProgress(chainParams.TxData(), pindex) ?
406 2018-01-30 23:17:51	0|promag|just do it once where the lock exists and use that value?
407 2018-01-30 23:18:22	0|promag|right after pindex = chainActive.Next(pindex); on the loop end
408 2018-01-30 23:18:28	0|promag|and also before the loop starts
409 2018-01-30 23:20:01	0|ryanofsky|probably something like that is fine. the whole function is a mess, there's a bunch of unnecessary nesting and immediate unlocking/relocking
410 2018-01-30 23:21:41	0|Dizzle|sipa
411 2018-01-30 23:22:05	0|Dizzle|Sorry, miss-typed.
412 2018-01-30 23:22:09	0|luke-jr|sdaftuar: deficient or not, it's the language currently used for the Layer header..
413 2018-01-30 23:22:49	0|gmaxwell|Then the layer header should be removed.
414 2018-01-30 23:23:17	0|gmaxwell|It has very little value at best, and clearly is just resulting in needless arguments.
415 2018-01-30 23:23:28	0|luke-jr|I don't agree that it's deficient. It is working fine in this case as well.
416 2018-01-30 23:23:54	0|luke-jr|I don't understand why people are desperate to deny the reality that BIP 90 is a hardfork.
417 2018-01-30 23:24:27	0|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.
418 2018-01-30 23:24:42	0|luke-jr|…
419 2018-01-30 23:25:06	0|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.
420 2018-01-30 23:25:44	0|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
421 2018-01-30 23:25:55	0|gmaxwell|The end result will only be that other people will simply walk away from the mechenism.
422 2018-01-30 23:26:20	0|gmaxwell|It's clearly not completely objective, because the decription doesn't fit the conventional definition of a hardfork.
423 2018-01-30 23:26:21	0|luke-jr|the documents are not edited, only the preamble header
424 2018-01-30 23:26:25	0|luke-jr|it does
425 2018-01-30 23:26:55	0|gmaxwell|You can argue that, but not via special privledges to edit the repository.
426 2018-01-30 23:27:01	0|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
427 2018-01-30 23:27:56	0|gmaxwell|I didn't notice that you stuck a hardfork label on BIP 90 until today.
428 2018-01-30 23:28:38	0|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.
429 2018-01-30 23:28:57	0|luke-jr|the whole reason it was made a BIP at all, was because it was a hardfork..
430 2018-01-30 23:29:29	0|gmaxwell|That is not true.
431 2018-01-30 23:29:35	0|luke-jr|then why would there be a BIP?
432 2018-01-30 23:29:59	0|gmaxwell|because there is a BIP for any protocol change with potential interoperability implications... even just documentary ones.
433 2018-01-30 23:30:19	0|luke-jr|if it is a protocol change, it is a hardfork by definition
434 2018-01-30 23:30:22	0|gmaxwell|And there has never been a hardfork performed via a BIP.
435 2018-01-30 23:30:26	0|luke-jr|the only way to argue it isn't a hardfork, is to argue that it isn't a protocol change
436 2018-01-30 23:30:56	0|gmaxwell|you are now arguing that all changes to the protocol are hardforks?
437 2018-01-30 23:31:00	0|luke-jr|no
438 2018-01-30 23:31:03	0|gmaxwell|so segwit is a hardfork? p2sh is a hardfork?
439 2018-01-30 23:31:11	0|gmaxwell|Fee filter.. hardfork?
440 2018-01-30 23:31:20	0|gmaxwell|compact blocks hardfork
441 2018-01-30 23:31:21	0|luke-jr|Segwit and P2SH constrain the protocol, they don't loosen it
442 2018-01-30 23:31:24	0|gmaxwell|BIP32 ... totally hardfork there.
443 2018-01-30 23:31:28	0|luke-jr|Fee filter and compact blocks aren't protocol changes at all
444 2018-01-30 23:31:41	0|gmaxwell|15:28:57 < luke-jr> the whole reason it was made a BIP at all, was because it  was a hardfork..
445 2018-01-30 23:31:44	0|gmaxwell|15:29:35 < luke-jr> then why would there be a BIP?
446 2018-01-30 23:32:36	0|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
447 2018-01-30 23:33:03	0|luke-jr|there is no reason for standardization of this kind of change, except if we see it as a protocol change
448 2018-01-30 23:33:40	0|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.
449 2018-01-30 23:33:56	0|gmaxwell|it's like arguing that jtimon's changes to not validate the genesis block were a hardfork.
450 2018-01-30 23:34:22	0|luke-jr|if it's an implementation detail, then there's nothing to standardize
451 2018-01-30 23:34:29	0|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.
452 2018-01-30 23:35:14	0|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.
453 2018-01-30 23:35:41	0|luke-jr|where's the grey? I don't see it in this case.
454 2018-01-30 23:35:44	0|gmaxwell|Writing documentation doesn't turn something into a hardfork that had existed for a long time.
455 2018-01-30 23:36:15	0|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.
456 2018-01-30 23:36:57	0|luke-jr|maybe the Layer header should just be deleted for BIP 90 (seeing as it's optional and not always applicable)
457 2018-01-30 23:37:17	0|gmaxwell|That would be an okay way to handle a dispute, I think.
458 2018-01-30 23:37:31	0|gmaxwell|The BIP describes itself, I think accurately and in detail.
459 2018-01-30 23:37:47	0|luke-jr|well, the description in the BIP is clearly a hardfork, IMO
460 2018-01-30 23:38:29	0|gmaxwell|Lets not create bad incentives for people to describe things using anything less than the most conservative language.
461 2018-01-30 23:39:07	0|luke-jr|it's a header. there is no incentive..
462 2018-01-30 23:39:10	0|gmaxwell|esp since bips can pretty much say whatever nonsense they want already.
463 2018-01-30 23:39:47	0|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.
464 2018-01-30 23:39:57	0|BlueMatt|can we just define a new term here
465 2018-01-30 23:39:59	0|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
466 2018-01-30 23:40:01	0|BlueMatt|call it "Buried Fork"
467 2018-01-30 23:40:02	0|BlueMatt|or something
468 2018-01-30 23:40:08	0|BlueMatt|then no one has to be upset
469 2018-01-30 23:40:37	0|gmaxwell|The word fork should probably not be used, because there is no fork.
470 2018-01-30 23:40:48	0|gmaxwell|there is no split in consensus state.
471 2018-01-30 23:41:04	0|gmaxwell|"Silver spoon" :P
472 2018-01-30 23:42:16	0|luke-jr|it's essentially the same thing as adding/removing checkpoints
473 2018-01-30 23:42:34	0|gmaxwell|I think I agree with that, which we also never have BIPed.
474 2018-01-30 23:42:36	0|BlueMatt|"Buried Spoon"
475 2018-01-30 23:42:55	0|BlueMatt|that seems appropriate
476 2018-01-30 23:43:03	0|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.
477 2018-01-30 23:44:42	0|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.
478 2018-01-30 23:44:58	0|contrapumpkin|(a BIP on the need for the layer header in BIPs?)
479 2018-01-30 23:48:10	0|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
480 2018-01-30 23:48:46	0|jtimon|BlueMatt: I like more "Buried deployment", but bikeshedding...
481 2018-01-30 23:48:49	0|contrapumpkin|jtimon: it seems he got disconnected
482 2018-01-30 23:49:02	0|gmaxwell|Buried deployment sounds okay to me.
483 2018-01-30 23:49:03	0|jtimon|ops, yeah
484 2018-01-30 23:49:19	0|promag|ryanofsky https://github.com/promag/bitcoin/commit/74022f56f733cf0ce3c156e9432e275413dff96c
485 2018-01-30 23:49:30	0|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.
486 2018-01-30 23:50:46	0|promag|sorry ryanofsky, force push https://github.com/promag/bitcoin/commit/6e36821823b498c307787543ad59b9e9ccffcc63
487 2018-01-30 23:54:58	0|jtimon|yeah, nobody will ever complain for a typo being corrected
488 2018-01-30 23:55:18	0|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
489 2018-01-30 23:55:24	0|luke-jr|(I read the IRC log to catch up)
490 2018-01-30 23:55:32	0|luke-jr|having a Core-specific place for implementation detail documentation would encourage more documentation of Core-specific stuff too
491 2018-01-30 23:55:49	0|luke-jr|?
492 2018-01-30 23:56:11	0|jtimon|luke-jr: it's not core specific, everybody is welcomed to do bip90 too
493 2018-01-30 23:57:19	0|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.
494 2018-01-30 23:58:55	0|jtimon|was bip39 whatever-wallet-implemented-it-first-specific?