1 2016-06-09 00:13:06	0|dgenr8|adiabat: bloom filter digests would be great, but won't kill off connection bloom filters. people want to see unconfirmed activity
  2 2016-06-09 00:16:39	0|gmaxwell|dgenr8: the addition of filtering the current transactions was a 12th hour addition to BIP37, and for many users saving an average of 13kbit/sec for a total loss of privacy is not all that interesting just to see unconfirmed transactions that their wallets can't even tell are at all remotely possily correct.
  3 2016-06-09 00:23:28	0|dgenr8|gmaxwell: so you think wallet should be watching all live tx, or none, or "either of those, just not filtered"?
  4 2016-06-09 00:24:41	0|gmaxwell|Or filtered, it's the wallets call. The exact behavior depends on the specific use case, and I think the specific use case for filtered is fairly narrow.
  5 2016-06-09 00:25:09	0|gmaxwell|If the digests idea had come up at the time of BIP37, I think it would have been implemented and filtering of relayed transactions wouldn't have been.
  6 2016-06-09 00:32:52	0|dgenr8|one use case is "i'm told a tx was broadcast that pays me. i wonder if that's true"
  7 2016-06-09 01:25:48	0|gmaxwell|P2Pool is updated for CSV.
  8 2016-06-09 01:35:32	0|luke-jr|it needed updating?
  9 2016-06-09 01:35:48	0|luke-jr|oh, because peers need to police each other
 10 2016-06-09 01:48:50	0|gmaxwell|also because it compensates for lack of softfork flags on gbt by not signaling higher versions than p2p knows about.
 11 2016-06-09 01:52:51	0|GitHub140|[13bitcoin] 15gmaxwell opened pull request #8179: Evict orphans which are included or precluded by accepted blocks. (06master...06reap_orphans) 02https://github.com/bitcoin/bitcoin/pull/8179
 12 2016-06-09 02:56:05	0|luke-jr|gmaxwell: ah, right
 13 2016-06-09 04:47:40	0|iniana|Will miners who don't upgrade get their blocks orphaned immediately once the grace period is over (by not signalling the activated bit) or only when they mine an invalid block?
 14 2016-06-09 05:13:38	0|GitHub77|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4286f4302514...19ea17302e8f
 15 2016-06-09 05:13:39	0|GitHub77|13bitcoin/06master 14ad38204 15Cory Fields: gitian: use CONFIG_SITE rather than hijacking the prefix
 16 2016-06-09 05:13:39	0|GitHub77|13bitcoin/06master 14b676f38 15Cory Fields: depends: allow for CONFIG_SITE to be used rather than stealing prefix...
 17 2016-06-09 05:13:40	0|GitHub77|13bitcoin/06master 147e7eb27 15Cory Fields: gitian: create debug packages for linux/windows...
 18 2016-06-09 05:13:47	0|GitHub1|[13bitcoin] 15laanwj closed pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (06master...06split-debug) 02https://github.com/bitcoin/bitcoin/pull/8167
 19 2016-06-09 05:23:25	0|GitHub156|13bitcoin/06master 1474c1347 15Wladimir J. van der Laan: gitian: Add --disable-bench to config flags for windows...
 20 2016-06-09 05:23:25	0|GitHub156|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/19ea17302e8f...f0299d80fd42
 21 2016-06-09 05:23:26	0|GitHub156|13bitcoin/06master 14f0299d8 15Wladimir J. van der Laan: Merge #8175: gitian: Add --disable-bench to config flags for windows...
 22 2016-06-09 05:23:30	0|GitHub5|[13bitcoin] 15laanwj closed pull request #8175: gitian: Add --disable-bench to config flags for windows (06master...062016_06_disable_bench_windows) 02https://github.com/bitcoin/bitcoin/pull/8175
 23 2016-06-09 05:26:10	0|gmaxwell|iniana: the latter
 24 2016-06-09 05:27:43	0|GitHub35|[13bitcoin] 15luke-jr opened pull request #8180: Update luke-jr's PGP key (06master...062016_pgp_update) 02https://github.com/bitcoin/bitcoin/pull/8180
 25 2016-06-09 05:28:30	0|gmaxwell|or even "if" not when, these txn are non-standard, so they won't likely mine them
 26 2016-06-09 05:29:30	0|GitHub0|13bitcoin/06master 1477f63a4 15Pieter Wuille: Fix two warnings for comparison between signed and unsigned
 27 2016-06-09 05:29:30	0|GitHub0|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f0299d80fd42...7e6dd7bee479
 28 2016-06-09 05:29:31	0|GitHub0|13bitcoin/06master 147e6dd7b 15Wladimir J. van der Laan: Merge #8172: Fix two warnings for comparison between signed and unsigned...
 29 2016-06-09 05:29:40	0|GitHub101|[13bitcoin] 15laanwj closed pull request #8172: Fix two warnings for comparison between signed and unsigned (06master...06fixunsigned) 02https://github.com/bitcoin/bitcoin/pull/8172
 30 2016-06-09 05:32:19	0|gmaxwell|Thanks. those have been bothering me.
 31 2016-06-09 05:33:15	0|luke-jr|☺
 32 2016-06-09 05:37:24	0|GitHub102|13bitcoin/06master 14e012f3c 15Wladimir J. van der Laan: util: Add ParseUInt32 and ParseUInt64...
 33 2016-06-09 05:37:24	0|GitHub102|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7e6dd7bee479...d36618585de6
 34 2016-06-09 05:37:25	0|GitHub102|13bitcoin/06master 14d366185 15Wladimir J. van der Laan: Merge #8168: util: Add ParseUInt32 and ParseUInt64...
 35 2016-06-09 05:37:34	0|GitHub92|[13bitcoin] 15laanwj closed pull request #8168: util: Add ParseUInt32 and ParseUInt64 (06master...062016_06_parseuint) 02https://github.com/bitcoin/bitcoin/pull/8168
 36 2016-06-09 06:13:34	0|GitHub168|13bitcoin/06master 14d3d02d5 15Kaz Wesley: drop vAddrToSend after sending big addr message...
 37 2016-06-09 06:13:34	0|GitHub168|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d36618585de6...1445835bd3c4
 38 2016-06-09 06:13:35	0|GitHub168|13bitcoin/06master 141445835 15Wladimir J. van der Laan: Merge #8154: drop vAddrToSend after sending big addr message...
 39 2016-06-09 06:13:44	0|GitHub102|[13bitcoin] 15laanwj closed pull request #8154: drop vAddrToSend after sending big addr message (06master...06drop-vAddrToSend) 02https://github.com/bitcoin/bitcoin/pull/8154
 40 2016-06-09 06:25:45	0|GitHub197|13bitcoin/06master 14c2715d3 15Pavel Janík: Do not shadow local variables
 41 2016-06-09 06:25:45	0|GitHub197|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1445835bd3c4...0b5279f89c9a
 42 2016-06-09 06:25:46	0|GitHub197|13bitcoin/06master 140b5279f 15Wladimir J. van der Laan: Merge #8166: src/test: Do not shadow local variables...
 43 2016-06-09 06:25:53	0|GitHub194|[13bitcoin] 15laanwj closed pull request #8166: src/test: Do not shadow local variables (06master...0620160607_shadowing_tests) 02https://github.com/bitcoin/bitcoin/pull/8166
 44 2016-06-09 06:36:15	0|GitHub92|[13bitcoin] 15laanwj closed pull request #7398: Improve seed generation script for clarity (06master...06contrib-seeds) 02https://github.com/bitcoin/bitcoin/pull/7398
 45 2016-06-09 07:04:48	0|gmaxwell|Hm. I think with the 0.13 sorted inv behavior can actually wipe out the orphan map when we have no outstanding unresponded getdata for transactions from any peers.  (this wouldn't be a good idea with the pre 0.13 behavior in the network, so we probably shouldn't do that now)
 46 2016-06-09 07:08:24	0|jonasschnelli|sipa: Willing to test https://github.com/bitcoin/bitcoin/pull/8035? Would be great to make progress before 0.13 here.
 47 2016-06-09 07:08:49	0|jonasschnelli|You also mentioned here (https://github.com/bitcoin/bitcoin/pull/8035#issuecomment-223058733) that " There are a few nits left to address.". Can you point me to them?
 48 2016-06-09 07:27:10	0|paveljanik|github Unircorn 8)
 49 2016-06-09 07:28:45	0|jonasschnelli|argh... again...
 50 2016-06-09 07:28:55	0|jonasschnelli|We need a decentralized github web. :)
 51 2016-06-09 07:29:21	0|sipa|You mean git?
 52 2016-06-09 07:29:27	0|jonasschnelli|hehe...
 53 2016-06-09 07:29:49	0|jonasschnelli|Yes. With the option of creating issues, public announcements of pull requests, etc.
 54 2016-06-09 07:47:55	0|wumpus|there have been ideas to create a git.bitcoincore.org which mirrors the repository and where one can clone from if the github repository is offline, the thing is, no one really has time to set up and babysit such things
 55 2016-06-09 07:49:24	0|warren|Does the git repo use signed merge commits?
 56 2016-06-09 07:49:55	0|btcdrak|wumpus: maintenance is a bitch.
 57 2016-06-09 07:50:04	0|sipa|warren: we always gpg sign merge commits
 58 2016-06-09 07:50:05	0|btcdrak|warren: yes.
 59 2016-06-09 07:50:17	0|sipa|warren: and there is a script to verify that
 60 2016-06-09 07:52:30	0|jonasschnelli|wumpus: you mean mirroring the github data?
 61 2016-06-09 07:52:42	0|jonasschnelli|Or just the git?
 62 2016-06-09 07:52:51	0|wumpus|just the git
 63 2016-06-09 07:53:01	0|jonasschnelli|Okay. That would be trivial.
 64 2016-06-09 07:53:12	0|wumpus|we do mirror the github data in a github repository, could also push that there
 65 2016-06-09 07:53:16	0|jonasschnelli|btcdrak: where is bitcoincore.org hosted?
 66 2016-06-09 07:53:17	0|btcdrak|I'm sure the odd Github Unicorn doesnt cause us _that_ much trouble.
 67 2016-06-09 07:53:32	0|btcdrak|jonasschnelli: the website is at github :)
 68 2016-06-09 07:53:33	0|sipa|wumpus: wgat
 69 2016-06-09 07:53:41	0|jonasschnelli|Yes. But we can't work on a decentralized system on a centralized github. :)
 70 2016-06-09 07:53:43	0|btcdrak|but can set a DNS entry to any server...
 71 2016-06-09 07:53:51	0|btcdrak|(a subdomain I mean)
 72 2016-06-09 07:54:29	0|btcdrak|jonasschnelli: decentralisation is a myth in this case.
 73 2016-06-09 07:54:43	0|wumpus|we've been signing merge commits consistently from ~2013 or so, and were one of the first projects to do this
 74 2016-06-09 07:55:03	0|sipa|unfortunately git commit ids are only sha1 :(
 75 2016-06-09 07:55:55	0|wumpus|well it's not perfect security but certainly puts of a barrier, which is the point of any security feature
 76 2016-06-09 07:55:58	0|btcdrak|i love how this entire conversation comes up almost verbatim again every now and again :)
 77 2016-06-09 07:56:23	0|wumpus|we're like broken records
 78 2016-06-09 07:56:33	0|btcdrak|mayeb I should write a FAQ :-p
 79 2016-06-09 07:58:42	0|btcdrak|but seriously, my point is: someone sees a Unicorn, and rather than press F5, it ignites a sledge hammer to crack peanut response :-D
 80 2016-06-09 07:58:55	0|wumpus|please include a "database corrupted" entry
 81 2016-06-09 07:59:09	0|wumpus|really doesn't help that everyone creates a new issue every time they get that
 82 2016-06-09 07:59:35	0|wumpus|where 99 out of 100 times it's simply a hardware problem
 83 2016-06-09 08:00:05	0|btcdrak|agreed, I think there are a bunch of common issue we could cover.
 84 2016-06-09 08:00:07	0|wumpus|we really should discourage people from creating new issues about that, unless there's new information to report
 85 2016-06-09 08:00:25	0|wumpus|maybe they could post to an existing issue for statistics or something
 86 2016-06-09 08:01:46	0|gmaxwell|change the message to "Apparent hardware error" :)
 87 2016-06-09 08:02:47	0|wumpus|gcc has the same thing, where people keep reporting SEGV crashes caused by overclocked or otherwise flakey CPUs, while compiling run-of-the-mill software
 88 2016-06-09 08:03:41	0|wumpus|gmaxwell: yes, that would be a good idea
 89 2016-06-09 08:04:18	0|paveljanik|maybe even a link to the FAQ entry about this?
 90 2016-06-09 08:06:17	0|sipa|nobody believes you when you tell them their hardware is broken
 91 2016-06-09 08:06:27	0|gmaxwell|a few do.
 92 2016-06-09 08:06:29	0|wumpus|still, it helps to have it written down somewhere
 93 2016-06-09 08:06:35	0|wumpus|in a clear way
 94 2016-06-09 08:06:45	0|wumpus|instead of repeating it all the time, increasingly annoyed :)
 95 2016-06-09 08:06:47	0|gmaxwell|I actually think they believe it from the sofware more than names on IRC.
 96 2016-06-09 08:07:12	0|gmaxwell|well whats worse is that they search the log entry, and find other people explaining that it's totally not hardware and the software is buggy and what not'
 97 2016-06-09 08:07:20	0|gmaxwell|and they show up "hey you morons still haven't fixed this!"
 98 2016-06-09 08:07:45	0|gmaxwell|they also run -rescan ten times and it won't go away and why should they have to run it an eleventh!?
 99 2016-06-09 08:08:19	0|gmaxwell|Is there a german word for where you both feel apologetic towards someone and want to strangle them?
100 2016-06-09 08:10:36	0|wumpus|the thing is, even if there are software bugs involved, opening more issues about it isn't going to help a thing
101 2016-06-09 08:11:21	0|gmaxwell|A lot of people just don't have a good mental model of how this whole thing works. Like, if it's still buggy and reported, then why haven't we fixed it? obviously we don't care or are lazy.
102 2016-06-09 08:11:23	0|wumpus|I think I'm going to create one 'data corruption' issue and close the others as duplicates
103 2016-06-09 08:11:51	0|gmaxwell|Same reason why reports seldom have the information required to reproduce the issue.
104 2016-06-09 08:12:27	0|wumpus|well most issues are fairly good in that regard
105 2016-06-09 08:12:28	0|gmaxwell|if we had simply forgotten, reporting again would help-- and we do, from time to time, forget actual issues.
106 2016-06-09 08:12:43	0|wumpus|generally not issues that are reported on github
107 2016-06-09 08:12:49	0|gmaxwell|Right.
108 2016-06-09 08:12:53	0|wumpus|sure, if something is said on IRC or the mailing list it gets lost
109 2016-06-09 08:12:57	0|gmaxwell|at least not while they're still open.
110 2016-06-09 08:13:00	0|wumpus|the point of an issue tracker is to have a persistent URL for an issue
111 2016-06-09 08:13:31	0|gmaxwell|But clearly we've fogotten the data corruption because it keeps hapenning. :P QED.
112 2016-06-09 08:13:33	0|wumpus|if it gets too crowded it loses its value
113 2016-06-09 08:14:01	0|wumpus|then it's just like mentioning it once on reddit, no one will ever look back to it
114 2016-06-09 08:14:10	0|wumpus|heh
115 2016-06-09 08:14:28	0|wumpus|well every time I had actual data corruption I investigated in depth
116 2016-06-09 08:16:53	0|jonasschnelli|What about providing a script/cli-tool (C++) that would perform some heave leveldb tests with block like data? Something like a bitcoin-hardware-test?
117 2016-06-09 08:17:07	0|gmaxwell|it's called bitcoind.
118 2016-06-09 08:17:19	0|wumpus|it will take long to detect errors, so no one will run that
119 2016-06-09 08:17:25	0|wumpus|heh exactly
120 2016-06-09 08:17:28	0|gmaxwell|it's not just leveldb though, the cpu load from signature validation triggers memory errors on some systems.
121 2016-06-09 08:17:30	0|jonasschnelli|Okay.. :)
122 2016-06-09 08:17:59	0|gmaxwell|when we have wumpus' snapshot stuff perhaps we could also do other things to retry/recover in the face of error.
123 2016-06-09 08:18:33	0|wumpus|there are just so many types of hardware problems that can result in corruptions
124 2016-06-09 08:18:39	0|gmaxwell|I have mixed feelings, users really shouldn't count on faulty computers... esp for handling irreversable money...
125 2016-06-09 08:19:05	0|wumpus|and there is software to detect hardware problems, that's a completely orthogonal thing :)
126 2016-06-09 08:19:29	0|jonasschnelli|Right. Agree.
127 2016-06-09 08:19:32	0|gmaxwell|many are resolved just by being able to go back to earlier state... obviously flying writes that corrupt data at rest.. well not much then can be done there... (well, we do have forward error correction code...)
128 2016-06-09 08:20:20	0|jonasschnelli|I just had serval crashes on my Pine64 (due to false configuration and maybe USB issues). I always had to reindex/IBD from the scratch.
129 2016-06-09 08:20:33	0|jonasschnelli|Wumpuses snapshot idea would be a live-safer for such situations
130 2016-06-09 08:23:15	0|GitHub178|[13bitcoin] 15laanwj closed pull request #7938: [0.12.2] Backports (060.12...06Mf1604-012backp) 02https://github.com/bitcoin/bitcoin/pull/7938
131 2016-06-09 08:23:18	0|GitHub74|[13bitcoin] 15laanwj pushed 15 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/e7ec24e336dc...20d00a180ee6
132 2016-06-09 08:23:19	0|GitHub74|13bitcoin/060.12 149095594 15ptschip: Do not download transactions during inital sync...
133 2016-06-09 08:23:19	0|GitHub74|13bitcoin/060.12 14a9e73f7 15instagibbs: Fix and cleanup listreceivedbyX documentation...
134 2016-06-09 08:23:20	0|GitHub74|13bitcoin/060.12 1464fd0ce 15jloughry: fix spelling of advertise in src and doc...
135 2016-06-09 08:29:55	0|paveljanik|Can you kick travis on #8109 please?
136 2016-06-09 08:30:55	0|paveljanik|ah, I can do that myself by simply rebasing it.
137 2016-06-09 08:51:16	0|GitHub89|13bitcoin/06master 14cdf7dff 15Jonas Schnelli: OSX diskimages need 0775 folder permissions...
138 2016-06-09 08:51:16	0|GitHub89|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0b5279f89c9a...172cd7f10c7e
139 2016-06-09 08:51:17	0|GitHub89|13bitcoin/06master 14172cd7f 15Wladimir J. van der Laan: Merge #8169: OSX diskimages need 0775 folder permissions...
140 2016-06-09 08:51:29	0|GitHub110|[13bitcoin] 15laanwj closed pull request #8169: OSX diskimages need 0775 folder permissions (06master...062016/06/fix_gitian_osx) 02https://github.com/bitcoin/bitcoin/pull/8169
141 2016-06-09 08:53:10	0|GitHub177|13bitcoin/060.12 140f8d574 15Jonas Schnelli: OSX diskimages need 0775 folder permissions...
142 2016-06-09 08:53:10	0|GitHub177|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/0f8d574e8f6521c07ae204b4f8b61d1534f03c21
143 2016-06-09 09:12:51	0|GitHub37|[13bitcoin] 15laanwj opened pull request #8181: build: Get rid of `CLIENT_DATE` (06master...062016_06_bye_client_date) 02https://github.com/bitcoin/bitcoin/pull/8181
144 2016-06-09 09:14:37	0|GitHub131|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/172cd7f10c7e...fd9881ae6782
145 2016-06-09 09:14:38	0|GitHub131|13bitcoin/06master 14fa42a67 15MarcoFalke: [gitian] hardcode datetime for depends
146 2016-06-09 09:14:38	0|GitHub131|13bitcoin/06master 14fa58c76 15MarcoFalke: [gitian] Default reference_datetime to commit author date
147 2016-06-09 09:14:39	0|GitHub131|13bitcoin/06master 14fd9881a 15Wladimir J. van der Laan: Merge #7283: [gitian] Default reference_datetime to commit author date...
148 2016-06-09 09:14:42	0|GitHub186|[13bitcoin] 15laanwj closed pull request #7283: [gitian] Default reference_datetime to commit author date (06master...06MarcoFalke-2016-gitianTimeDefault) 02https://github.com/bitcoin/bitcoin/pull/7283
149 2016-06-09 09:17:51	0|GitHub19|[13bitcoin] 15jonasschnelli opened pull request #8182: [Qt] Add simple opt-in-RBF support (06master...062016/04/qt_rbf_set_new) 02https://github.com/bitcoin/bitcoin/pull/8182
150 2016-06-09 09:22:14	0|GitHub148|[13bitcoin] 15jonasschnelli closed pull request #7819: [Qt] Simple opt-in-RBF checkbox (06master...062016/04/qt_rbf_set) 02https://github.com/bitcoin/bitcoin/pull/7819
151 2016-06-09 10:43:46	0|MarcoFalke|wumpus: Can you explain why you left BUILD_DATE in share/genbuild.sh ?
152 2016-06-09 10:43:51	0|MarcoFalke|Is it used elsewhere?
153 2016-06-09 11:32:34	0|wumpus|MarcoFalke: probably an oversight, or I wasn't sure, let me see
154 2016-06-09 11:33:16	0|wumpus|yes that can definitely go
155 2016-06-09 13:27:48	0|instagibbs|is there a list of known issues with getbalance? I'm getting inconsistencies, and the comments in the code give me instructions which causes a json parsing error(??)
156 2016-06-09 13:27:52	0|instagibbs|"// getbalance and "getbalance * 1 true" should return the same number"
157 2016-06-09 13:28:16	0|instagibbs|oh the latter is probably me being dumb, but I still am getting weird balances
158 2016-06-09 13:30:05	0|sipa|instagibbs: https://github.com/bitcoin/bitcoin/pull/7715 ?
159 2016-06-09 13:32:08	0|instagibbs|thanks, is that comment supposed to be correct? I'm getting different balances
160 2016-06-09 13:36:01	0|sipa|are you typing "getbalance * 1 true" on the command line? that will expand * to the list of files in your current directory
161 2016-06-09 13:36:22	0|instagibbs|i was, but i escaped it yes
162 2016-06-09 13:37:01	0|instagibbs|If I send funds to myself in regtest, it immediately shows up in getbalance, but not getbalance * 1 true
163 2016-06-09 13:37:01	0|sipa|then how do you get a parsing error?
164 2016-06-09 13:37:18	0|instagibbs|no that was my 2nd issue, now fixed
165 2016-06-09 13:37:24	0|sipa|ah, getbalance will show unconfirmed sends from yourself
166 2016-06-09 13:37:36	0|instagibbs|well... I will change that comment then
167 2016-06-09 13:37:42	0|instagibbs|thanks
168 2016-06-09 13:38:14	0|sipa|that comment is very very old
169 2016-06-09 13:38:21	0|sipa|2010, i expect
170 2016-06-09 13:39:26	0|instagibbs|2015?
171 2016-06-09 13:39:33	0|instagibbs|according to git blame
172 2016-06-09 13:39:54	0|sipa|oh
173 2016-06-09 13:39:56	0|instagibbs|dgenr8 one-line addition
174 2016-06-09 13:40:18	0|instagibbs|Anyways, I'll PR if that's expected behavior
175 2016-06-09 13:41:22	0|sipa|if you disable -spendzeroconfchange, it may work
176 2016-06-09 13:41:27	0|sipa|s/work/hold true/
177 2016-06-09 13:41:53	0|instagibbs|ok
178 2016-06-09 13:52:13	0|instagibbs|still a slight difference with spendzeroconfchange disabled, hmm
179 2016-06-09 14:32:59	0|GitHub84|[13bitcoin] 15sipa pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fd9881ae6782...7ce9ac5c83b1
180 2016-06-09 14:33:00	0|GitHub84|13bitcoin/06master 145ec0cde 15Suhas Daftuar: Refactor logic for converting mempool entries to JSON
181 2016-06-09 14:33:00	0|GitHub84|13bitcoin/06master 148f7b5dc 15Suhas Daftuar: Add getmempoolancestors RPC call
182 2016-06-09 14:33:01	0|GitHub84|13bitcoin/06master 140dfd869 15Suhas Daftuar: Add getmempooldescendants RPC call
183 2016-06-09 14:33:04	0|GitHub151|[13bitcoin] 15sipa closed pull request #7292: [RPC] Expose ancestor/descendant information over RPC (06master...06add-chain-info) 02https://github.com/bitcoin/bitcoin/pull/7292
184 2016-06-09 14:42:49	0|GitHub198|13bitcoin/06master 143144449 15Pieter Wuille: Add git and github tips and tricks to developer notes
185 2016-06-09 14:42:49	0|GitHub198|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7ce9ac5c83b1...f7b1bfc9a347
186 2016-06-09 14:42:50	0|GitHub198|13bitcoin/06master 14f7b1bfc 15Wladimir J. van der Laan: Merge #8178: Add git and github tips and tricks to developer notes...
187 2016-06-09 14:42:59	0|GitHub125|[13bitcoin] 15laanwj closed pull request #8178: Add git and github tips and tricks to developer notes (06master...06docgit) 02https://github.com/bitcoin/bitcoin/pull/8178
188 2016-06-09 14:44:36	0|GitHub172|13bitcoin/06master 140d53a9e 15Luke Dashjr: Update luke-jr's PGP key...
189 2016-06-09 14:44:36	0|GitHub172|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f7b1bfc9a347...32b7294177e5
190 2016-06-09 14:44:37	0|GitHub172|13bitcoin/06master 1432b7294 15Wladimir J. van der Laan: Merge #8180: Update luke-jr's PGP key...
191 2016-06-09 14:44:46	0|GitHub194|[13bitcoin] 15laanwj closed pull request #8180: Update luke-jr's PGP key (06master...062016_pgp_update) 02https://github.com/bitcoin/bitcoin/pull/8180
192 2016-06-09 15:20:39	0|dgenr8|instagibbs: getbalance and getbalance "" appear to differ in their treatment of 0-conf utxos from self.  getbalance "" 1 seems to always includes them.  getbalance "*" follows from getbalance "" (since "" is just a specific account)
193 2016-06-09 15:21:42	0|dgenr8|instagibbs: also sendfrom "A" seems to not work in a test I just just (it selected a utxo not belonging to "A")
194 2016-06-09 15:21:49	0|dgenr8|justdid
195 2016-06-09 15:22:03	0|instagibbs|yeah i opened an issue
196 2016-06-09 15:22:12	0|instagibbs|since im not sure what the comment should be changed to
197 2016-06-09 15:22:25	0|instagibbs|there are nooks and crannies depending on settings you are running
198 2016-06-09 15:25:51	0|dgenr8|agreed that since -spendzeroconfchange affects the result of getbalance, the comment is too general.  prolly just remove it
199 2016-06-09 15:26:08	0|sipa|dgenr8: sendfrom just subtracts the balance from A; it always uses all utxos
200 2016-06-09 15:26:26	0|sipa|dgenr8: as accounts don't own utxos in any way
201 2016-06-09 15:26:41	0|instagibbs|dgenr8, yes I think removal is best
202 2016-06-09 15:34:34	0|sipa|dgenr8: also, do you feel like addresses the comments on your partition check improvement?
203 2016-06-09 15:34:43	0|sipa|*addressing
204 2016-06-09 16:32:18	0|gmaxwell|2016-06-09 08:46:38.763465 [0%]...[50%]...[99%]...[DONE].
205 2016-06-09 16:32:39	0|gmaxwell|Is it really okay to dribble out a log entry over a long time?  Not going to break external log handling?
206 2016-06-09 17:45:10	0|GitHub16|[13bitcoin] 15theuni opened pull request #8184: WIP: OSX toolchain bump (06master...06osx-sdk-bump) 02https://github.com/bitcoin/bitcoin/pull/8184
207 2016-06-09 18:20:44	0|wumpus|gmaxwell: sure, an external log handler would just wait for the line to complete
208 2016-06-09 18:21:20	0|gmaxwell|K. I've never considered that case before and thought it potentially useful to raise the question.
209 2016-06-09 18:21:21	0|wumpus|there's no rule that log messages need to be written within a certain time
210 2016-06-09 18:21:58	0|gmaxwell|well generally we should write them a line at a time or otherwise we'll get log entries split by threads.
211 2016-06-09 18:22:43	0|wumpus|yes, that came up during review too, it can be done here because there is nothing else running at that time
212 2016-06-09 18:22:50	0|wumpus|and this is less spammy than printing a line for every N%
213 2016-06-09 18:23:14	0|gmaxwell|Right. I agree that it can be done here.
214 2016-06-09 18:33:14	0|BakSAj|hi
215 2016-06-09 18:36:00	0|BakSAj|http://bitcoin.sipa.be/ver9-2k.png
216 2016-06-09 18:36:06	0|BakSAj|i like the picture :-)
217 2016-06-09 18:36:22	0|BakSAj|not sure if we make it to 95% in this diff period
218 2016-06-09 18:36:46	0|gmaxwell|mostly depends on KNC going offline again or not.
219 2016-06-09 18:37:12	0|adam3us|they maybe selling the equipment
220 2016-06-09 18:42:34	0|BakSAj|lets hope...
221 2016-06-09 18:43:39	0|BakSAj|on the other hand its a bit sad that hash will get little more centralized when this EU miner ends
222 2016-06-09 19:00:17	0|jonasschnelli|meeting?
223 2016-06-09 19:00:25	0|gmaxwell|Meeting time.
224 2016-06-09 19:00:29	0|wumpus|yes
225 2016-06-09 19:00:35	0|wumpus|#meetingstart
226 2016-06-09 19:00:38	0|lightningbot|Meeting started Thu Jun  9 19:00:38 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
227 2016-06-09 19:00:38	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
228 2016-06-09 19:00:38	0|wumpus|#startmeeting
229 2016-06-09 19:01:01	0|gmaxwell|phantomcircuit: sipa: morcos: sdaftuar: btcdrak: jonasschnelli: luke-jr:
230 2016-06-09 19:01:22	0|wumpus|first at PSA: the feature freeze for 0.13 is next week. Make sure that whatever features need to be merged are merged before that time. If there are any pulls that require special attention, or are ready, let me know.
231 2016-06-09 19:01:26	0|gmaxwell|petertodd: MarcoFalke:
232 2016-06-09 19:01:40	0|wumpus|#link 0.13 release schedule: https://github.com/bitcoin/bitcoin/issues/7679
233 2016-06-09 19:01:52	0|MarcoFalke|any topic suggestions today?
234 2016-06-09 19:02:23	0|gmaxwell|We can talk some about ongoing compact block testings, I have a few things to report.
235 2016-06-09 19:02:42	0|wumpus|last meeting there was talk of release lifecycles documentation, btcdrak and David Harding have been working on that page here: https://github.com/bitcoin-core/bitcoincore.org/pull/179 https://github.com/btcdrak/bitcoincore.org/pull/2  this needs review
236 2016-06-09 19:02:54	0|cfields_|wumpus: I have 2 p2p refactor PRs that i'd _very_ much like to have in 0.13. I'm not sure how you're considering those in terms of freezing
237 2016-06-09 19:02:55	0|gmaxwell|instagibbs: nickler: NicolasDorier: CodeShark:
238 2016-06-09 19:03:15	0|CodeShark|yo
239 2016-06-09 19:03:24	0|MarcoFalke|cfields_: I think p2p refactor can go in after the feature freeze?
240 2016-06-09 19:03:29	0|gmaxwell|We apparently can no longer compile on hosts with only 2GB ram with defaults.
241 2016-06-09 19:03:40	0|wumpus|other TODOs from last week: review and merge #8126 (std::shared_ptr based CTransaction storage in mempool) - that was done, #7935 (Versionbits: GBT support) - also done
242 2016-06-09 19:03:47	0|MarcoFalke|I mean it is not a new feature ;)
243 2016-06-09 19:04:04	0|gmaxwell|well it was more like 1.5GB ram before.
244 2016-06-09 19:04:35	0|wumpus|others have not yet finished: #7598 (Refactor CreateNewBlock to be a method of the BlockAssembler class)
245 2016-06-09 19:04:38	0|jonasschnelli|gmaxwell: I compiled on a 2GG AARCH this week successfully.
246 2016-06-09 19:04:42	0|jonasschnelli|*GB
247 2016-06-09 19:04:46	0|gmaxwell|We have docs that say 1.5GB, they're gonna be like the blocksize on bitcoin.org :)
248 2016-06-09 19:04:49	0|wumpus|#7600  Mining: Select transactions using feerate-with-ancestors
249 2016-06-09 19:04:56	0|wumpus|depends on what else is running on the machine
250 2016-06-09 19:05:34	0|gmaxwell|I've been going through #7598/#7600.
251 2016-06-09 19:05:38	0|wumpus|#topic compile-time memory usage
252 2016-06-09 19:05:46	0|wumpus|what can *concretely* be done here?
253 2016-06-09 19:05:58	0|jonasschnelli|would kick out boost help?
254 2016-06-09 19:06:00	0|luke-jr|-O0
255 2016-06-09 19:06:01	0|wumpus|is it something worrying?
256 2016-06-09 19:06:08	0|cfields_|has anyone measured to see if there are particular objects that are especially guilty?
257 2016-06-09 19:06:12	0|CodeShark|what's eating up all the RAM?
258 2016-06-09 19:06:14	0|wumpus|yes, we have cfields_
259 2016-06-09 19:06:20	0|cfields_|ie. main.cpp/net.cpp ?
260 2016-06-09 19:06:21	0|luke-jr|CodeShark: ld/GCC doesn't free memory
261 2016-06-09 19:06:23	0|wumpus|especialy some autogenerated c++ files
262 2016-06-09 19:06:33	0|wumpus|I made some tables back in the issue about this
263 2016-06-09 19:06:37	0|gmaxwell|main.cpp, matt has a patch that moves all the mempool stuff out of it taht apparently gets it back to 1.5GB.
264 2016-06-09 19:06:50	0|luke-jr|CFLAGS="-O0 -g0 --param ggc-min-expand=0 --param ggc-min-heapsize=32768"
265 2016-06-09 19:06:54	0|gmaxwell|I dunno why he hasn't PRed it, I asked him to.
266 2016-06-09 19:06:54	0|wumpus|#link https://github.com/bitcoin/bitcoin/issues/7471
267 2016-06-09 19:07:00	0|cfields_|wumpus: thanks
268 2016-06-09 19:07:10	0|wumpus|eeh that's the wrong one
269 2016-06-09 19:07:22	0|gmaxwell|wumpus: unthanks
270 2016-06-09 19:07:31	0|wumpus|well it is about the same subject
271 2016-06-09 19:07:34	0|wumpus|#link https://github.com/bitcoin/bitcoin/issues/6658
272 2016-06-09 19:07:53	0|wumpus|lots of people have posted about it, but there doesn't seem to be a clear solution
273 2016-06-09 19:08:00	0|jonasschnelli|main.cpp -> 1248524bytes ... ^^
274 2016-06-09 19:08:37	0|wumpus|reducing the number of included headers works, I think
275 2016-06-09 19:08:41	0|sipa|present
276 2016-06-09 19:08:46	0|cfields_|I have PRs which break up net.h/netbase.h, i'd be curious to see if those make a significant difference
277 2016-06-09 19:09:00	0|gmaxwell|in any case, something to be aware of and nudge a bit at... some refactorings to move code around would help.
278 2016-06-09 19:09:13	0|wumpus|also building with clang helps
279 2016-06-09 19:09:21	0|wumpus|it uses a lot less memory at the same compile settings, usually
280 2016-06-09 19:09:26	0|gmaxwell|and be independantly good for reasons unrelated to peak memory usage.
281 2016-06-09 19:10:05	0|cfields_|i'd assume that mem usage correlates solidly with compile time
282 2016-06-09 19:10:55	0|CodeShark|not so sure - lots of small files might mean the bottleneck is disk access
283 2016-06-09 19:11:29	0|sipa|CodeShark: come on
284 2016-06-09 19:11:32	0|CodeShark|in any case, it would be good to bring down the peak mem usage
285 2016-06-09 19:11:32	0|wumpus|the bottleneck in compilation is hardly ever disk access, at least *reading* disk access
286 2016-06-09 19:11:37	0|sipa|reading in 100 files?
287 2016-06-09 19:11:43	0|sipa|sequentially
288 2016-06-09 19:12:09	0|BakSAj|would be cool, if btc full nodes could continue to be runnable on Rasberry Pi ... with 1GB RAM
289 2016-06-09 19:12:38	0|jeremyrubin|BakSAj: runnable is not compileable on?
290 2016-06-09 19:12:41	0|gmaxwell|not sure there is much else to say here.  I only brought it up for general awareness issues, since I think it's likely a death by 1000 cuts that can be improved in a multitude of ways.
291 2016-06-09 19:12:55	0|wumpus|seek/read access for source files is only a problem for really huge projects, and then especially when the source is hosted on some horrible network file system (like clearcase), in any case bitcoin doesn't even come close
292 2016-06-09 19:13:03	0|cfields_|heh, disk is negligible. It's easy to see where time is spent with -ftime-report.
293 2016-06-09 19:13:17	0|wumpus|but like always: measure before you start talking about bottlenecks
294 2016-06-09 19:13:36	0|jonasschnelli|I think adding cross compile depends options for ARM and AARCH64 would also reduce the "memory problem" (at least the amount of complains): https://github.com/bitcoin/bitcoin/issues/8162
295 2016-06-09 19:13:58	0|BakSAj|jeremyrubin: preferably both compileable and operatable
296 2016-06-09 19:13:59	0|wumpus|BakSAj: for small embedded systems you should use cross-compilation
297 2016-06-09 19:14:04	0|cfields_|jonasschnelli: i'm halfway through the changes needed there.
298 2016-06-09 19:14:13	0|jeremyrubin|i have had machines take a bit of time on autogen.sh fyi
299 2016-06-09 19:14:18	0|jonasschnelli|cfields_: nice. Focus on Qt5.6 first. :)
300 2016-06-09 19:14:34	0|wumpus|you can cross compile on ARM using depends, we just don't distribute ARM binaries
301 2016-06-09 19:14:37	0|cfields_|jonasschnelli: actually, arm/aarch64 already work fine with depends. Just have to use NO_QT=1 manually.
302 2016-06-09 19:14:41	0|wumpus|s/on/to
303 2016-06-09 19:14:42	0|gmaxwell|I'm skeptical that the intersection of rpi users that complain about compile issues and people who will cross compile is the emptyset. But cross compiling is good.
304 2016-06-09 19:14:45	0|wumpus|cfields_: yes, it works fine
305 2016-06-09 19:14:51	0|luke-jr|for comparison, webkit-based stuff typically uses up to 12 GB RAM with debug symbols, and much much less without..
306 2016-06-09 19:14:56	0|gmaxwell|er isn't the empty set, you get what I mean.
307 2016-06-09 19:15:08	0|cfields_|luke-jr: oh, good point...
308 2016-06-09 19:15:13	0|wumpus|it's *very easy* tocross compile for ARM
309 2016-06-09 19:15:14	0|jonasschnelli|I think NO_QT=1 for ARM/AARCH64 could be a start (even for "official binaries").
310 2016-06-09 19:15:20	0|wumpus|with the depends system
311 2016-06-09 19:15:24	0|wumpus|jonasschnelli: yes
312 2016-06-09 19:15:28	0|cfields_|the gitian-debug PR turns on debug symbols, so gitian mem requirement is bumped after that.
313 2016-06-09 19:15:37	0|gmaxwell|wumpus: a lot of people using rpi2 like systems do not have another linux host.
314 2016-06-09 19:15:43	0|luke-jr|wumpus: that builds static binaries, which is wasteful on RAM
315 2016-06-09 19:15:44	0|jonasschnelli|Also ARM is used more and more for GUI systems.
316 2016-06-09 19:15:50	0|jeremyrubin|can autogen.sh be made faster?
317 2016-06-09 19:16:02	0|wumpus|jeremyrubin: no
318 2016-06-09 19:16:15	0|wumpus|not by us, at least
319 2016-06-09 19:16:16	0|BakSAj|ok, thanks for explaining.. personally i had no trouble compiling 0.12.1 on rpi 3, was afraid that minimum requirements will raise with future releases
320 2016-06-09 19:16:32	0|BakSAj|since suprisingly many nodes run on rpi
321 2016-06-09 19:16:32	0|jonasschnelli|luke-jr: if you want to run bitcoind on a RiP (or similar) static builds are fine. Mostly you don't have tons of other tools that could share libraries installed.
322 2016-06-09 19:16:45	0|jeremyrubin|wumpus: maybe the one thing that is fixed by a faster disk
323 2016-06-09 19:16:50	0|luke-jr|jonasschnelli: I'm thinking more of Bitcoin-Qt
324 2016-06-09 19:17:00	0|cfields_|jonasschnelli: as qt's gui plugin situation improves, we may be able to move back to the shared-qt builds
325 2016-06-09 19:17:06	0|wumpus|I'm sure minimum requirements will raise with future releases, that's just the way things are, we'll try to raise them not too much though
326 2016-06-09 19:17:12	0|MarcoFalke|jonasschnelli: I think we already have notes on how to corss compile to arm?
327 2016-06-09 19:17:13	0|jonasschnelli|Agree. Static linking qt is not ideal. But lets don't roll this up again.
328 2016-06-09 19:17:14	0|MarcoFalke|https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#arm-cross-compilation
329 2016-06-09 19:17:23	0|btcdrak|oh meeting
330 2016-06-09 19:17:35	0|jonasschnelli|MarcoFalke: notes, yes. But it should be included in our release builds (gitian)
331 2016-06-09 19:17:42	0|MarcoFalke|jup, agree
332 2016-06-09 19:17:46	0|cfields_|jonasschnelli: sorry, i meant that directly in the context of shipping arm+gui binaries
333 2016-06-09 19:17:56	0|luke-jr|jonasschnelli: for now, people just compile natively to avoid static, so suggesting cross-compile isn't a real option
334 2016-06-09 19:18:07	0|wumpus|jeremyrubin: I'm not sure. I have no idea what autogen.sh would be spending time on. But it seems more a GNU problem thatn a bitcoin core problem :)
335 2016-06-09 19:18:23	0|wumpus|jeremyrubin: I'm surprised it's autogen.sh taking a lot of time not configure, which has this huge list of scripts to execute for probing
336 2016-06-09 19:18:50	0|cfields_|jeremyrubin: you can use a quicker shell for autogen. IIRC dash vs. bash shaves a few seconds off
337 2016-06-09 19:19:15	0|luke-jr|autogen.sh isn't even part of building; it's a developer tool
338 2016-06-09 19:19:15	0|wumpus|well arm non-GUI binaries would already be a great step forward, one step at a tme
339 2016-06-09 19:19:17	0|cfields_|wumpus: ah, as a feature-freeze request: ok to plan on arm bins (without gui) for 0.13 ?
340 2016-06-09 19:19:27	0|luke-jr|if you're running autogen.sh, that means you're running from git, and you shouldn't do that
341 2016-06-09 19:19:30	0|cfields_|i can try to have that done today
342 2016-06-09 19:19:31	0|jonasschnelli|cfields_: ack, +1
343 2016-06-09 19:19:33	0|wumpus|I think arm gui would be prett much a per-distro afair
344 2016-06-09 19:19:37	0|wumpus|cfields_: sure!
345 2016-06-09 19:19:38	0|luke-jr|cfields_: +1
346 2016-06-09 19:19:39	0|jeremyrubin|luke-jr: are we making build faster for developers or for users?
347 2016-06-09 19:19:45	0|gmaxwell|+1
348 2016-06-09 19:19:47	0|cfields_|ok
349 2016-06-09 19:20:06	0|luke-jr|jeremyrubin: I think the concern is "ability to build" rather than "speed to build"
350 2016-06-09 19:20:12	0|gmaxwell|jeremyrubin: users shouldn't need to run autogen-- if they get the source tarballs we have, it should already be autogenned.
351 2016-06-09 19:20:26	0|cfields_|^^
352 2016-06-09 19:20:36	0|BakSAj|cool, rpi fans will love you :-)
353 2016-06-09 19:20:44	0|wumpus|but the people actually doing a lot of builds are developers, only they would care about a few more/less seconds in the build scripting
354 2016-06-09 19:20:57	0|BakSAj|next step - run full node on cell phone :-)
355 2016-06-09 19:21:02	0|jeremyrubin|wumpus: ++
356 2016-06-09 19:21:12	0|luke-jr|BakSAj: I believe a number of people have done this.
357 2016-06-09 19:21:19	0|wumpus|BakSAj: people are doing that actually, that's one of the motivations for the ARM binaries
358 2016-06-09 19:21:28	0|BakSAj|lol ok
359 2016-06-09 19:21:28	0|luke-jr|next step is therefore to support SPV mode when bandwidth is expensive ;)
360 2016-06-09 19:21:30	0|gmaxwell|BakSAj: abcore, it works fine.
361 2016-06-09 19:21:39	0|jonasschnelli|luke-jr: +1
362 2016-06-09 19:21:41	0|luke-jr|but that's post-0.13 IMO
363 2016-06-09 19:21:46	0|wumpus|absolutely
364 2016-06-09 19:22:22	0|wumpus|in any case it's too late to start on anything new for 0.13, for that we have to consider which of the current pulls can go in
365 2016-06-09 19:22:47	0|luke-jr|can we get in [8-bit] key generation type?
366 2016-06-09 19:23:33	0|jonasschnelli|32bit!
367 2016-06-09 19:23:42	0|jonasschnelli|You can provide a migration patch for Knots
368 2016-06-09 19:23:52	0|jonasschnelli|Isn't that trivial?
369 2016-06-09 19:23:53	0|BakSAj|will 0.13 contain just segwit code or actual softfork also? tnx
370 2016-06-09 19:24:03	0|jonasschnelli|SW SF can be 0.13.1
371 2016-06-09 19:24:17	0|jonasschnelli|SW are mostly not coupled with major releases
372 2016-06-09 19:24:22	0|jeremyrubin|I think that 0.13.1 will be worse for upgrade times
373 2016-06-09 19:24:25	0|wumpus|SW should be released in a minor release
374 2016-06-09 19:24:26	0|jeremyrubin|does anyone have data on that
375 2016-06-09 19:24:30	0|gmaxwell|BakSAj: major releases do not contain network consensus changes.
376 2016-06-09 19:24:32	0|sdaftuar|do we think segwit is going in to 0.13?
377 2016-06-09 19:24:43	0|sdaftuar|(without activation scheduled)
378 2016-06-09 19:24:52	0|jeremyrubin|wumpus: isn't it a major change?
379 2016-06-09 19:24:53	0|luke-jr|jonasschnelli: migration is not very practical if 32-bit uses the same version number in Core as 8-bit in Knots already is
380 2016-06-09 19:24:53	0|petertodd|sdaftuar: you mean, 0.13.0, or 0.13.x>0?
381 2016-06-09 19:24:57	0|sdaftuar|0.13.0
382 2016-06-09 19:24:59	0|btcdrak|sdaftuar: yes, sipa wanted to merge it soon to master
383 2016-06-09 19:25:01	0|CodeShark|what happened to doing it in 0.12.x?
384 2016-06-09 19:25:02	0|luke-jr|jonasschnelli: maybe this needs more off-meeting discussion then
385 2016-06-09 19:25:08	0|btcdrak|(without mainnet defs)
386 2016-06-09 19:25:08	0|jonasschnelli|luke-jr: agree
387 2016-06-09 19:25:16	0|sdaftuar|seems like there are still open issues, and no ACKs
388 2016-06-09 19:25:17	0|wumpus|jeremyrubin: well from what I've heard minor releases are usually more popular, especialy .1, as some people don't trust .0  :)
389 2016-06-09 19:25:27	0|gmaxwell|CodeShark: nothing, there are confused questions.
390 2016-06-09 19:25:27	0|sdaftuar|so i don't see how it's going to be merged in the next week
391 2016-06-09 19:25:48	0|btcdrak|sdaftuar: why?
392 2016-06-09 19:25:49	0|luke-jr|jeremyrubin: segwit is a major change to Bitcoin - not Bitcoin Core.
393 2016-06-09 19:25:52	0|gmaxwell|jeremyrubin: we have a long thought out published spec on this, please don't divert the meeting to debating it. I can direct you to the information after the meeting.
394 2016-06-09 19:26:07	0|jeremyrubin|wumpus: interesting... I do tend to not upgrade any of my software major versions for 6 months. diversion over
395 2016-06-09 19:26:27	0|sipa|well merging segwit without fork enabled is not in contradiction with "not doing a consensus change in a major release"
396 2016-06-09 19:26:36	0|jonasschnelli|agree
397 2016-06-09 19:26:42	0|CodeShark|right
398 2016-06-09 19:26:48	0|wumpus|sure
399 2016-06-09 19:26:49	0|luke-jr|no objections to merging segwit code without activation
400 2016-06-09 19:26:51	0|gmaxwell|sure, there are code motion logistics that favor merging it.
401 2016-06-09 19:26:51	0|jonasschnelli|Also, getting ACK for SW is extremly hard. Nobody wants to take the risk.
402 2016-06-09 19:26:51	0|sdaftuar|to be clear i'm not talking about any kind of release policy, just code-readiness / review
403 2016-06-09 19:26:54	0|btcdrak|jeremyrubin: see out lifecycle docs https://github.com/bitcoin-core/bitcoincore.org/pull/179
404 2016-06-09 19:27:07	0|btcdrak|s/out/our/
405 2016-06-09 19:27:58	0|wumpus|so is SW ready for merge (into master/0.13)?
406 2016-06-09 19:28:06	0|sdaftuar|it has no ACKs, and some open issues to be resolved
407 2016-06-09 19:28:31	0|wumpus|ok
408 2016-06-09 19:28:33	0|jonasschnelli|major open issue? Or more nitish stuff?
409 2016-06-09 19:28:35	0|sdaftuar|minor
410 2016-06-09 19:28:50	0|wumpus|if it is not critical it can also be fixed in a later pull
411 2016-06-09 19:28:51	0|sdaftuar|but bugs, not style nits
412 2016-06-09 19:29:09	0|wumpus|oh known bugs should be addressed in the pull itself
413 2016-06-09 19:29:21	0|sipa|i think everything will be addressed in my next batch of patches
414 2016-06-09 19:29:29	0|btcdrak|sipa: great!
415 2016-06-09 19:29:42	0|gmaxwell|should people be acking the reviwew PR or the rebase/reorg?
416 2016-06-09 19:29:42	0|luke-jr|sipa: does that include expanding 2nd push to 75 bytes max? or is that still an open thing?
417 2016-06-09 19:30:20	0|sipa|luke-jr: this is the place to ask, and i would say no, there is no point
418 2016-06-09 19:30:28	0|sipa|but perhaps others have another opinion
419 2016-06-09 19:30:33	0|btcdrak|luke-jr: I didnt understand where 75 came from.
420 2016-06-09 19:30:42	0|sipa|btcdrak: up to 75 is easy
421 2016-06-09 19:30:43	0|luke-jr|btcdrak: largest size that wouldn't require additional testing
422 2016-06-09 19:31:19	0|gmaxwell|has to do with the opcode types changing for different sizes of push.
423 2016-06-09 19:31:47	0|sipa|so, opinions?
424 2016-06-09 19:31:52	0|btcdrak|32->40->75 seems like a big jump
425 2016-06-09 19:32:06	0|gmaxwell|btcdrak: from the code perspective they're all the same.
426 2016-06-09 19:32:19	0|luke-jr|my opinion is there is no point limiting it (beyond the impl/test cost of >75), and such limits could very well prevent future softforks
427 2016-06-09 19:32:49	0|luke-jr|more tolerant enables softforks, so should be preferred over useless limits
428 2016-06-09 19:33:08	0|gmaxwell|Luke-jr's argument has merit in my opinion-- it can be reduced later, but I don't have a strongly held view. I'm not aware of a DOS attack risk created by not having the stricter limit earlier.
429 2016-06-09 19:33:44	0|gmaxwell|(of course, IsStandardness should be strictly limited)
430 2016-06-09 19:33:45	0|luke-jr|to expand the limit later requires a hardfork
431 2016-06-09 19:34:01	0|luke-jr|yes, node policy should reject any unknown witnesses period
432 2016-06-09 19:34:23	0|CodeShark|ok, I think luke-jr has a strong argument
433 2016-06-09 19:34:27	0|btcdrak|that makes sense
434 2016-06-09 19:34:47	0|sipa|there should be no need for more than 256-bit hash + some versioning metadata
435 2016-06-09 19:35:14	0|sipa|and setting it to more gives it the impression that there is
436 2016-06-09 19:35:16	0|petertodd|sipa: or, to be precise if there is that means Bitcoin is more broken than that
437 2016-06-09 19:35:25	0|sipa|petertodd: exactly
438 2016-06-09 19:35:33	0|jeremyrubin|luke-jr: in general I agree with keeping flexible, but do you have an example for sipa of why you'd want it?
439 2016-06-09 19:35:37	0|gmaxwell|The biggest harm I see is that allowing a larger size here does limit the ability to make utxo entries limited in size in the future, potentially. But it could be done later.  It also enabled policy bypass to abuse the utxo set for data storage, though it's not much of an issue there.
440 2016-06-09 19:35:42	0|luke-jr|sipa: it doesn't need to give that impression. I don't think we need to predict the future too much here.
441 2016-06-09 19:36:23	0|gmaxwell|luke-jr: for example, if you were to argue that we might someday need 512 bit hashes, I'd agree-- but then I'd point out that in that case there would need to be a hardfork to change all the other things.
442 2016-06-09 19:36:26	0|sipa|i'd rather not rely on isstandardness when reasoning about longer term future
443 2016-06-09 19:37:01	0|petertodd|in a MR implementation I did, it turned out to be very advantageous if the things in the MMR were fixed side forperformance
444 2016-06-09 19:37:14	0|luke-jr|jeremyrubin: any case where we would need indicators in the UTXO set itself; but I don't have a concrete example at this time
445 2016-06-09 19:37:19	0|gmaxwell|Also, not allowing it in SW doesn't preclude it in the future, you'd just need to use a different version type signaling in that case.
446 2016-06-09 19:37:36	0|luke-jr|for example, we could have added the maturity stuff in the 2nd push if we didn't have nSequence
447 2016-06-09 19:37:44	0|gmaxwell|Yes, I really wish UTXO entries were fixed size.
448 2016-06-09 19:37:53	0|sdaftuar|sipa: isn't there a strong deterrent against abuse, because your funds are anyone-can-spend to older nodes?
449 2016-06-09 19:38:00	0|luke-jr|gmaxwell: you'd need a new commitment entirely
450 2016-06-09 19:38:14	0|luke-jr|gmaxwell: in addition to the current one
451 2016-06-09 19:38:25	0|sipa|sdaftuar: there is no rule preventing 0-value outputs
452 2016-06-09 19:38:34	0|_anthony_|just use the private key of a payment address to store the 256 bits
453 2016-06-09 19:38:37	0|sdaftuar|ah, good point
454 2016-06-09 19:38:41	0|sipa|(if you ignore relay polify)
455 2016-06-09 19:39:10	0|luke-jr|abuse is already possible. this doesn't make it worse. if in the future we make it better, we can limit this at the same time
456 2016-06-09 19:39:28	0|gmaxwell|if one assumes a fixed size utxo entry, luke's suggestion basically doubles the utxo set size.
457 2016-06-09 19:39:32	0|petertodd|sipa: though, for that specific case I find it ahrd to think of a abuse use-case that'd care about that, given you could screw up the usse-case by spending those outputs
458 2016-06-09 19:39:52	0|luke-jr|gmaxwell: we can't assume that today, and if we softfork an assumption tomorrow, we can limit this then also
459 2016-06-09 19:40:44	0|gmaxwell|We've probably spent more time discussing it now than the decision is worth.
460 2016-06-09 19:41:14	0|wumpus|ok, next topic?
461 2016-06-09 19:41:24	0|wumpus|#topic compact block testing
462 2016-06-09 19:41:28	0|luke-jr|so we use 75 for now, and discuss reducing it later?
463 2016-06-09 19:41:34	0|gmaxwell|(and that time could be better spent reviewing/testing more corner cases... lets continue discussion elsewhere I guess)
464 2016-06-09 19:42:35	0|btcdrak|so compact blocks...
465 2016-06-09 19:42:42	0|gmaxwell|OK. So there are some number of nodes running compactblocks on the public network.. I have 12 peers at the moment, matt has another half dozen in the new relay network that I'm not connected to.
466 2016-06-09 19:42:52	0|gmaxwell|Things seem to be working well there, instagibbs has posted some charts.
467 2016-06-09 19:42:56	0|wumpus|I've been running a compact blocks node for a few days, no crashes to report :)
468 2016-06-09 19:43:17	0|instagibbs|yes i love charts http://imgur.com/iq2lRGl
469 2016-06-09 19:43:27	0|gmaxwell|I've been conducting some new tests with a network of nodes with a modified version of compact blocks that reduces the hash size to 16 bits in order to test corner cases around collisions.
470 2016-06-09 19:43:28	0|instagibbs|blue stuff is in kB fwiw
471 2016-06-09 19:43:30	0|wumpus|lots of succesfully reconstructed blocks
472 2016-06-09 19:43:32	0|luke-jr|(ugh, Travis is apparently "detecting abuse" on the Bitcoin code itself, so every clone will be affected?)
473 2016-06-09 19:43:36	0|btcdrak|Two large mining pools have also been running them, connected to their pool nodes for block source, one is behind the GFW
474 2016-06-09 19:43:40	0|instagibbs|blue dot == 0 fetched txns
475 2016-06-09 19:44:21	0|gmaxwell|I found a few bugs, which matt has fixed but not pushed to the PR yet.  Bugs were things like if the cmptblk message was rubbish, it would wait for the peer to timeout before requesting the block normally.
476 2016-06-09 19:44:49	0|instagibbs|I intended to review the PR then got ill. Still planning to review.
477 2016-06-09 19:44:57	0|gmaxwell|I think this particular testing technique of modifying the code to make rare cases common is pretty effective and will result in good testing of most of those corner cases.
478 2016-06-09 19:45:05	0|wumpus|luke-jr: (offtopic) that started happening with the parallel testing I think
479 2016-06-09 19:45:08	0|sipa|gmaxwell: agree
480 2016-06-09 19:45:19	0|MarcoFalke|luke-jr: Shoot them an email
481 2016-06-09 19:45:39	0|gmaxwell|The compact block code is now rebased on top of the sharedptr work, so it's now a fair bit simpler.
482 2016-06-09 19:45:54	0|luke-jr|MarcoFalke: I have. My concern is more than just whitelisting individual repos though. (Let's continue discussion after the meeting)
483 2016-06-09 19:45:55	0|instagibbs|gmaxwell, matt's rebase is on that now?
484 2016-06-09 19:45:59	0|instagibbs|err pr is rebased*
485 2016-06-09 19:46:01	0|gmaxwell|instagibbs: yes.
486 2016-06-09 19:46:12	0|gmaxwell|matt's PR is on master as of last night.
487 2016-06-09 19:46:21	0|sipa|yes, forget my branch
488 2016-06-09 19:46:35	0|CodeShark|what PR#?
489 2016-06-09 19:46:49	0|instagibbs|#8086
490 2016-06-09 19:47:08	0|wumpus|#link https://github.com/bitcoin/bitcoin/pull/8068
491 2016-06-09 19:47:15	0|cfields_|has there been discussion of a servicebit for compact blocks? Now that we have the dns seed prefixes, that would allow for very quick discovery
492 2016-06-09 19:47:23	0|gmaxwell|Based on the issues I found, probably the interaction with block fetching logic needs more review.
493 2016-06-09 19:47:37	0|btcdrak|cfields_: if it deploys in 0.13 it wont be necessary
494 2016-06-09 19:47:44	0|gmaxwell|cfields_: IMO I don't see a need to preferrentially peer. I expect support to become sufficiently ubiquitious fast enough.
495 2016-06-09 19:47:46	0|wumpus|#action forget sipa's compact blocks branch and use thebluematt's PR
496 2016-06-09 19:48:11	0|gmaxwell|it's not something that anyone has a reason to not support, except for just not having implemented it.
497 2016-06-09 19:48:14	0|btcdrak|hrm, action point is to forget :)
498 2016-06-09 19:48:16	0|sipa|cfields_: the argument brought up before was tgat service bits should be used for critical
499 2016-06-09 19:48:29	0|sipa|for critically required services
500 2016-06-09 19:48:42	0|gmaxwell|like your node won't work right if you don't have peers with the right services.
501 2016-06-09 19:48:46	0|wumpus|btcdrak: yeah for people testing the code to use the other branch
502 2016-06-09 19:48:49	0|luke-jr|makes sense
503 2016-06-09 19:48:55	0|sipa|and the only time when yoi critically need a compact block peer is as a miner, who should be curating their connections anyway
504 2016-06-09 19:49:00	0|jeremyrubin|in #8086 where is the salt generated btw?
505 2016-06-09 19:49:09	0|cfields_|hmm, fair enough
506 2016-06-09 19:49:35	0|wumpus|and miners can look at the protocol version to see if their peer supports compact blocks?
507 2016-06-09 19:49:49	0|gmaxwell|+CBlockHeaderAndShortTxIDs::CBlockHeaderAndShortTxIDs(const CBlock& block) :
508 2016-06-09 19:49:49	0|gmaxwell|jeremyrubin:
509 2016-06-09 19:49:53	0|gmaxwell|+        nonce(GetRand(std::numeric_limits<uint64_t>::max())),
510 2016-06-09 19:50:12	0|luke-jr|wumpus: I don't think we can assume a specific protocol version supports it
511 2016-06-09 19:50:27	0|luke-jr|if we have a future version with better compact blocks, we may want to drop support for the current one
512 2016-06-09 19:50:28	0|jeremyrubin|thanks
513 2016-06-09 19:50:30	0|Lightsword|I think using service bits is a good idea, mainually curtailing connections is very time consuming and raisies the barrier to entry for mining
514 2016-06-09 19:50:33	0|gmaxwell|wumpus: you can do the handshake.
515 2016-06-09 19:50:36	0|sipa|wumpus: no, miners should connect to a known peer that supports it
516 2016-06-09 19:50:42	0|luke-jr|Lightsword: neither are likely to be necessary
517 2016-06-09 19:51:09	0|wumpus|gmaxwell: right
518 2016-06-09 19:51:22	0|gmaxwell|Please, service bits are basically forever and we only have 32 of them, I expect the window between some and nearly all use of this to only be a few months to a year long.
519 2016-06-09 19:51:24	0|sipa|wumpus: because just supporting compact blocks is not enough, they also need to have good uptime and reliability  latency, bandwodth, ...
520 2016-06-09 19:51:29	0|sipa|gmaxwell: we have 64
521 2016-06-09 19:51:41	0|gmaxwell|Same difference. (really? hmph!)
522 2016-06-09 19:51:46	0|jeremyrubin|I would suggest either writing the entropy to a file once or having it settable in a config file
523 2016-06-09 19:51:49	0|wumpus|we should have a concept of temporary service bits, like for the versionbits
524 2016-06-09 19:52:06	0|sipa|jeremyrubin: that's a good idea but orthogonal
525 2016-06-09 19:52:11	0|luke-jr|as long as nobody relies on service bits, they can be temporary
526 2016-06-09 19:52:16	0|btcdrak|we dont need preferential peering for compact blocks. It wont take long for wide network support.
527 2016-06-09 19:52:17	0|luke-jr|ie, use them as hints
528 2016-06-09 19:52:24	0|cfields_|don't we have a range designated for playground?
529 2016-06-09 19:52:27	0|luke-jr|yes
530 2016-06-09 19:52:31	0|jeremyrubin|sipa: (yes, sorry, just reviewing it now)
531 2016-06-09 19:52:34	0|Lightsword|a service bit to indicate a secondary service bit field needs to be used?
532 2016-06-09 19:52:47	0|luke-jr|one of which is currently getting full-RBF temporary usage
533 2016-06-09 19:52:50	0|wumpus|Lightsword: that would completely make it unuseful for preferential peering
534 2016-06-09 19:52:51	0|gmaxwell|jeremyrubin: uh. I'm not sure what you're talking about there... the nonces are per block and should not be predictable.
535 2016-06-09 19:53:12	0|wumpus|Lightsword: (as neither addr messages nor the DNS seeds would be aware of the secondary mechanism)
536 2016-06-09 19:53:14	0|gmaxwell|statically configuring it would be broken.
537 2016-06-09 19:53:29	0|wumpus|why would you want to fix the entropy statically?
538 2016-06-09 19:53:34	0|instagibbs|gmaxwell, perhaps setting cmpctblock as a tie-breaker for keeping connection?
539 2016-06-09 19:53:41	0|gmaxwell|Okay, in any case, I think thats all I've got there.
540 2016-06-09 19:53:51	0|btcdrak|ding ding, we have 7 mins remaining
541 2016-06-09 19:53:52	0|instagibbs|well, I guess "he sent me blocks fast" is/will be one, same thing
542 2016-06-09 19:53:54	0|cfields_|static entropy is much easier to test :p
543 2016-06-09 19:53:54	0|gmaxwell|instagibbs: sounds like a fine additional ranker in the connection management stuff.
544 2016-06-09 19:54:06	0|sipa|indeed
545 2016-06-09 19:54:06	0|wumpus|instagibbs: +1
546 2016-06-09 19:54:13	0|jeremyrubin|cfields_: yep
547 2016-06-09 19:54:16	0|gmaxwell|instagibbs: though yea, the 'most recent blocks' probably mostly covers it.
548 2016-06-09 19:54:35	0|BakSAj|which version are compact blocks planned for?
549 2016-06-09 19:54:40	0|sipa|related to that: please review gmaxwell's patch for adding fast blkck and tx relayers for not evicted
550 2016-06-09 19:54:41	0|jeremyrubin|gmaxwell: it doesn't harm security so long as it's kept secret from peers
551 2016-06-09 19:54:50	0|btcdrak|BakSAj: 0.13.0
552 2016-06-09 19:54:52	0|instagibbs|sipa, which number
553 2016-06-09 19:55:00	0|sipa|instagibbs: sec
554 2016-06-09 19:55:05	0|jeremyrubin|gmaxwell: nvm -- forgot you have to send it?
555 2016-06-09 19:55:07	0|gmaxwell|jeremyrubin: the nonce used for compact blocks must be sent to peers or they can't recover the block.
556 2016-06-09 19:55:12	0|petertodd|wumpus: we do have temporary service bits
557 2016-06-09 19:55:19	0|BakSAj|btcdrak: thanks!
558 2016-06-09 19:55:33	0|sdaftuar|gmaxwell: thoughts on #7598/#7600? you said above that you'd started review
559 2016-06-09 19:55:40	0|Lightsword|isn’t it likely we’re going to overhaul the p2p protocol by the time we run out of service bits?
560 2016-06-09 19:55:45	0|sdaftuar|i still think it should be a priority to get those PRs merged for 0.13.0...
561 2016-06-09 19:55:47	0|instagibbs|I don't think connecting to cmpctblock peers will be hard unless we get sybil'd by AWS forks
562 2016-06-09 19:55:57	0|gmaxwell|sdaftuar: I like them and will ACK soon, once I come up with a useful way to test.
563 2016-06-09 19:56:08	0|sipa|sdaftuar: me too, i started revieweing but got caught up on other things
564 2016-06-09 19:56:10	0|gmaxwell|sdaftuar: I agree.
565 2016-06-09 19:56:25	0|sipa|Lightsword: maybe
566 2016-06-09 19:56:42	0|sipa|Lightsword: it's often hard to predict how long protocols live
567 2016-06-09 19:56:48	0|gmaxwell|I think important big PRs I'd really like to have in 0.13 are SW, Compact blocks, CFPF related, and BIP32.
568 2016-06-09 19:56:52	0|sdaftuar|gmaxwell: ok, let me know if you want help with the sim environment i shared with you, i think that makes it easy
569 2016-06-09 19:56:54	0|instagibbs|sipa, https://github.com/bitcoin/bitcoin/pull/8084
570 2016-06-09 19:56:59	0|gmaxwell|There are a bunch of small things (including all of mine)
571 2016-06-09 19:57:16	0|sipa|instagibbs: that one, thanks
572 2016-06-09 19:57:45	0|cfields_|off-topic: quickly, before I forget. I'll be headed out of town on Friday and only reachable for emergencies for ~10 days. If anyone needs anything from me before I go, speak up now :)
573 2016-06-09 19:57:58	0|sipa|cfields_: for how long?
574 2016-06-09 19:58:04	0|Lightsword|maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
575 2016-06-09 19:58:04	0|sipa|a month?
576 2016-06-09 19:58:17	0|wumpus|only features have to be in before the feature freeze, anything that can be interpreted as bug fixes or anti-DoS measures doesn't have the deadline of next week
577 2016-06-09 19:58:20	0|wumpus|also SW is special
578 2016-06-09 19:58:31	0|sipa|Lightsword: we should also have an evil bit that abusive nodes should set
579 2016-06-09 19:58:45	0|gmaxwell|Lightsword: "the I am a DOS attack master node, please connect to me" flag?
580 2016-06-09 19:58:48	0|Chris_St1|brilliant
581 2016-06-09 19:58:52	0|btcdrak|sipa: ^.^
582 2016-06-09 19:58:56	0|wumpus|as we discussed above it's a consensus change so it can't be enabled in a major release first
583 2016-06-09 19:59:04	0|cfields_|sipa: for ~10 days. I'll be gone for a month total, but working for the last few weeks.
584 2016-06-09 19:59:10	0|sipa|i see
585 2016-06-09 19:59:23	0|wumpus|he announced that well in advance
586 2016-06-09 19:59:30	0|gmaxwell|lynch him!
587 2016-06-09 19:59:33	0|luke-jr|cfields_: review of https://github.com/bitcoin/bitcoin/pull/5872 ? :D
588 2016-06-09 19:59:36	0|gmaxwell|oh in advance, okay.
589 2016-06-09 19:59:39	0|gmaxwell|:P
590 2016-06-09 19:59:48	0|BakSAj|:-)
591 2016-06-09 19:59:54	0|cfields_|luke-jr: added to the list, thanks
592 2016-06-09 20:00:02	0|sipa|*ding dong*
593 2016-06-09 20:00:03	0|instagibbs|wumpus, all-but-SF SW would be nice
594 2016-06-09 20:00:06	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.log.html
595 2016-06-09 20:00:06	0|lightningbot|Meeting ended Thu Jun  9 20:00:05 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
596 2016-06-09 20:00:06	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.html
597 2016-06-09 20:00:06	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-09-19.00.txt
598 2016-06-09 20:00:06	0|wumpus|#endmeeting
599 2016-06-09 20:00:18	0|luke-jr|FWIW, I will also be travelling June 20th-early July (but probably semi-available and working)
600 2016-06-09 20:00:25	0|sipa|thanks all, this was an interesting meeting
601 2016-06-09 20:00:29	0|cfields_|along the same lines, review plea for #8128
602 2016-06-09 20:00:57	0|wumpus|instagibbs: I know, just wanted the situation around SW to be clear for people reading the logs
603 2016-06-09 20:01:05	0|instagibbs|+1
604 2016-06-09 20:01:35	0|BakSAj|btw, is there a rough estimate when 0.13.1 may come?
605 2016-06-09 20:01:47	0|BakSAj|or version with segwit sf
606 2016-06-09 20:01:49	0|instagibbs|Probably when a certain Softfork is ready....
607 2016-06-09 20:01:50	0|gmaxwell|yea, my comments were assuming that it would be released in 0.12.x first, but parallel included in master.
608 2016-06-09 20:01:54	0|luke-jr|BakSAj: "when it's ready"
609 2016-06-09 20:01:56	0|btcdrak|BakSAj: SW will be released in 0.12.x
610 2016-06-09 20:01:57	0|gmaxwell|BakSAj: 0.12.x
611 2016-06-09 20:02:06	0|cfields_|luke-jr: btw, i believe I found your issue wrt out-of-tree build and chowning
612 2016-06-09 20:02:23	0|gmaxwell|BakSAj: development operats long ahead of public release, we're often working up to a year ahead of whats released.
613 2016-06-09 20:02:32	0|cfields_|luke-jr: we rely on "git diff" to update the index, but it can't if .git is read-only.
614 2016-06-09 20:02:48	0|luke-jr|aha
615 2016-06-09 20:02:52	0|BakSAj|uf little confused
616 2016-06-09 20:03:07	0|BakSAj|now you release 0.13.0 with segwit code
617 2016-06-09 20:03:11	0|gmaxwell|the interest in merging SW in master mostly comes from the fact that it isn't merged is holding people back from some changes because they don't want to make the SW rebases more complex.
618 2016-06-09 20:03:15	0|btcdrak|gmaxwell: BlueMatt just pushed the fixes to #8068 compact blocks
619 2016-06-09 20:03:18	0|BakSAj|but then 0.12.2 with code and activation comes
620 2016-06-09 20:03:22	0|instagibbs|BakSAj, ok, so 0.13 isn't out. That means if SW is released, it goes into 0.12.2
621 2016-06-09 20:03:29	0|instagibbs|then will still show up in 0.13
622 2016-06-09 20:03:56	0|gmaxwell|For example, I wrote a patch to remove three loops over all transactions in accetblock... then shelved it, because its just a tiny speedup, and would conflict with the SW patches.
623 2016-06-09 20:04:07	0|BakSAj|wont this bring confusion whether to run 0.12.2 or 0.13 ?
624 2016-06-09 20:04:38	0|cfields_|luke-jr: could you verify that your process works if you add a "chown -R user:user" after the "chown -R root:root ." ?
625 2016-06-09 20:04:38	0|instagibbs|btcdrak, sigh, my block hit rate is going to poop :(
626 2016-06-09 20:04:47	0|sipa|BakSAj: what os are you running?
627 2016-06-09 20:04:51	0|luke-jr|BakSAj: there is no one version everyone must run
628 2016-06-09 20:05:01	0|gmaxwell|instagibbs: start up the relay node client for a bit to prefill your mempool.
629 2016-06-09 20:05:07	0|BakSAj|sipa ?
630 2016-06-09 20:05:08	0|luke-jr|cfields_: eh, that sounds like a noop?
631 2016-06-09 20:05:16	0|instagibbs|gmaxwell, hmm ok pretty sure I have that installed
632 2016-06-09 20:05:18	0|btcdrak|instagibbs: well you could spin up a new node instead...
633 2016-06-09 20:05:20	0|sipa|BakSAj: what version of your os are you running.
634 2016-06-09 20:05:24	0|cfields_|luke-jr: er, sorry...
635 2016-06-09 20:05:34	0|cfields_|luke-jr: "chown -R user:user .git"
636 2016-06-09 20:05:41	0|BakSAj|sipa: for full node?
637 2016-06-09 20:05:52	0|btcdrak|instagibbs: rsync your chainstate etc.
638 2016-06-09 20:05:56	0|sipa|BakSAj: whatever, i'm trying to make an analogu
639 2016-06-09 20:06:07	0|BakSAj|lol, win10
640 2016-06-09 20:06:11	0|sipa|BakSAj: you run 0.12.x to get more stable/tested code
641 2016-06-09 20:06:24	0|sipa|BakSAj: you run 0.13.0 to get the latest and greates
642 2016-06-09 20:06:39	0|sipa|and segwit is independent of that
643 2016-06-09 20:06:50	0|sipa|it will be released in a point update to both
644 2016-06-09 20:07:10	0|gmaxwell|SW is not a client feature, it's part of the network protocol.
645 2016-06-09 20:07:21	0|BakSAj|i understand how sw livecycle usually works, but im confused about thing that 0.13.0 wont have SF active
646 2016-06-09 20:07:43	0|luke-jr|BakSAj: if 0.13.0 is released before SW, it won't have SW; if it is released after SW, it won't remove SW
647 2016-06-09 20:07:59	0|gmaxwell|BakSAj: it may or may not, but it won't be the first release with it. 0.12.x (likely 0.12.2) will.
648 2016-06-09 20:08:00	0|luke-jr|SW introduction is independent from Core's release cycle
649 2016-06-09 20:08:04	0|sipa|BakSAj: because in order to enable SW, we need many code changes
650 2016-06-09 20:08:29	0|sipa|BakSAj: it's a pita to keep maintaining those in parallel when we know the code worms
651 2016-06-09 20:08:32	0|sipa|*works
652 2016-06-09 20:08:46	0|BakSAj|ah
653 2016-06-09 20:08:51	0|luke-jr|BakSAj: if 0.12.1 and 0.13.0 are released before SW, then SW will be added in 0.13.1 and 0.12.2; if only 0.12.1 is released before SW, then it will be added to 0.12.2, and the later 0.13.0 will also have it still
654 2016-06-09 20:09:01	0|BakSAj|i had bad assumption about 0.13.0
655 2016-06-09 20:09:08	0|BakSAj|guys, thanks for explanation
656 2016-06-09 20:09:19	0|gmaxwell|btcdrak: in the future, please wait for travis to finish before nagging people to update. :)
657 2016-06-09 20:09:34	0|BakSAj|got it now
658 2016-06-09 20:10:33	0|BakSAj|https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
659 2016-06-09 20:10:39	0|BakSAj|mayb needs little refurbish
660 2016-06-09 20:10:44	0|BakSAj|dates and staff
661 2016-06-09 20:11:25	0|instagibbs|BakSAj, the section on the site about life cycle needs a refurb
662 2016-06-09 20:11:35	0|BakSAj|if i can speak for little educated public :-) i would prefer complex btc roadmap
663 2016-06-09 20:11:50	0|BakSAj|not just capacity increase roadmap
664 2016-06-09 20:12:53	0|btcdrak|gmaxwell: noted
665 2016-06-09 20:50:03	0|dgenr8|sipa: on .11.0 and .12.0 (I didn't try newer), after sendfrom "A", no subtraction from A is reflected in listaccounts or getbalance "A"
666 2016-06-09 20:50:25	0|dgenr8|sipa: it looks like there is no way query ledger entries like this (or those created by move) :/
667 2016-06-09 20:51:31	0|dgenr8|sipa: listunspent shows account A as an attribute of a utxo with address created by getnewaddress A.  sendfrom A should probably wipe that out ...  but that strays into trying to fix it
668 2016-06-09 20:52:23	0|sipa|dgenr8: receive accounts are a property of incoming payments, not utxos
669 2016-06-09 20:52:50	0|sipa|dgenr8: the fact that a send is not reflected in getbalance is a bug
670 2016-06-09 20:53:19	0|dgenr8|I guess was speaking loosely ... i mean it has a txid and a vout, and it is unspent :)
671 2016-06-09 22:14:00	0|GitHub89|[13bitcoin] 15MarcoFalke opened pull request #8185: [0.12.2] Various qa and test backports (060.12...06Mf1606-qaBackports) 02https://github.com/bitcoin/bitcoin/pull/8185
672 2016-06-09 22:50:43	0|GitHub176|[13bitcoin] 15MarcoFalke opened pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (060.12...06Mf1606-rpcBip9Backport) 02https://github.com/bitcoin/bitcoin/pull/8186
673 2016-06-09 23:08:02	0|GitHub153|[13bitcoin] 15MarcoFalke opened pull request #8187: [WIP] [0.12.2] backport: [qa] Switch to py3 (060.12...06Mf1606-qaPy3Backport) 02https://github.com/bitcoin/bitcoin/pull/8187