1 2016-05-05 03:00:02	0|BlueMatt|lol, did a chainsync with infinite dbcache and, on shutdown, bitcoind did a 1.5G malloc
  2 2016-05-05 03:00:53	0|luke-jr|>_<
  3 2016-05-05 03:03:51	0|BlueMatt|wait...wtf
  4 2016-05-05 03:04:04	0|BlueMatt|and on startup, with a tiny dbcache...leveldb did a 2.1G alloc
  5 2016-05-05 03:04:06	0|BlueMatt|that cant be right
  6 2016-05-05 03:04:47	0|BlueMatt|yea, it is
  7 2016-05-05 03:04:54	0|BlueMatt|heh, the first time you restart after that it does insane things
  8 2016-05-05 04:48:12	0|GitHub82|[13bitcoin] 15catilac opened pull request #8004: signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t (06master...06fix_signal_handler) 02https://github.com/bitcoin/bitcoin/pull/8004
  9 2016-05-05 06:20:28	0|GitHub154|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8206835cc173...42a67533828f
 10 2016-05-05 06:20:29	0|GitHub154|13bitcoin/06master 1408d7b56 15Wladimir J. van der Laan: util: switch LogPrint and error to variadic templates
 11 2016-05-05 06:20:29	0|GitHub154|13bitcoin/06master 149eaa0af 15Wladimir J. van der Laan: tinyformat: force USE_VARIADIC_TEMPLATES...
 12 2016-05-05 06:20:30	0|GitHub154|13bitcoin/06master 1442a6753 15Wladimir J. van der Laan: Merge #8000: tinyformat: force USE_VARIADIC_TEMPLATES...
 13 2016-05-05 06:20:38	0|GitHub192|[13bitcoin] 15laanwj closed pull request #8000: tinyformat: force USE_VARIADIC_TEMPLATES (06master...062016_05_tinyformat_variadic) 02https://github.com/bitcoin/bitcoin/pull/8000
 14 2016-05-05 07:15:17	0|cjcj|What is the git process for including a specific PR (#6853) into the v0.11.2 branch?
 15 2016-05-05 07:18:22	0|Guest7895|cjcj: it gets backporter if it's considered critical
 16 2016-05-05 07:18:40	0|Guest7895|v0.11.2 is a release, not a branch, by the way
 17 2016-05-05 07:20:13	0|Guest7895|6853 is not a bugfix, and certainly not a critical one
 18 2016-05-05 07:24:44	0|btcdrak|cjcj: all changes should be made to master, and then they can be backported as required. You backport to the specific branch 0.12, and 0.11
 19 2016-05-05 07:26:13	0|btcdrak|cjcj: normally you just mark it as "requires backport", and the maintainers will cherry-pick backport it after merge, but if it has lots of merge conflicts with the backport branch then you may need to open a PR for it (but wait until master merge first).
 20 2016-05-05 07:30:18	0|cjcj|btcdrak: I never intended to PR this. It would be for my own use only. The 0.12 branch doesn't work for some reason for my case, and #6853 is the only PR from 0.12 I really need. Was just wondering of a painless way to include it, but I think I will just build from CodeSharks fNoRetarget branch.
 21 2016-05-05 07:31:30	0|Guest7895|cjcj: well you can git cherry-pick
 22 2016-05-05 07:31:50	0|Guest7895|though i'm interested why 0.12 does not work for you... perhaps that's an indication of a bigger problem
 23 2016-05-05 07:33:42	0|btcdrak|what does "does not work for me" mean specifically?
 24 2016-05-05 07:34:54	0|cjcj|Guest7895: Will check out that command. Am not very familiar with git yet. I don't know yet why 0.12, but I bet the problem is on my end. For now 0.11.2 just works so I will continue from there for now.
 25 2016-05-05 07:39:31	0|cjcj|btcdrak: The program crashes when I make an RPC request in 0.12 after running for a while, but it works fine in 0.11.
 26 2016-05-05 07:40:52	0|sipa|perhaps you should open an issue for that?
 27 2016-05-05 07:40:58	0|sipa|or is this with heavy local modifications?
 28 2016-05-05 07:42:43	0|cjcj|sipa: I think the problem is on my end, but I will debug the issue further when I got time and open an issue if it doesn't resolve.
 29 2016-05-05 07:43:13	0|cjcj|I'm using python-bitcoinlib as well, so maybe the issue could lie there.
 30 2016-05-05 07:43:44	0|cjcj|Are there heavy differences in the RPC code between 0.11 and 0.12?
 31 2016-05-05 07:44:15	0|sipa|you'll need to give a bit more information about what you're doing
 32 2016-05-05 07:44:26	0|sipa|some things changed a lot, others not at all
 33 2016-05-05 07:45:11	0|wumpus|yes, you need to be more specific about what is not working, 'it doesn't work' is  not a good bug report
 34 2016-05-05 07:45:47	0|wumpus|what are you doing, what error do you get back
 35 2016-05-05 07:46:10	0|wumpus|does bitcoind crash ,if so can you provide a traceback
 36 2016-05-05 07:46:16	0|wumpus|etc
 37 2016-05-05 07:47:14	0|wumpus|if you just want to cherry-pick one commit, use the git cherry-pick command, it may be easy, it may also be very hard if the surrounding code changed a lot between 0.11 and 0.12 (large chance)
 38 2016-05-05 07:49:21	0|cjcj|bitcoind doesn't crash, only the python script I'm running. Will provide a traceback once I have removed some personal info from it.
 39 2016-05-05 07:49:47	0|sipa|ah, ok :)
 40 2016-05-05 08:59:17	0|GitHub26|[13bitcoin] 15avar closed pull request #8003: Get rid of a compiler warning due to #if 0'd test (06master...06fix-unused-function-compiler-warning) 02https://github.com/bitcoin/bitcoin/pull/8003
 41 2016-05-05 08:59:52	0|GitHub154|[13bitcoin] 15avar opened pull request #8005: Add a comment indicating that the btc devs don't want a warning fixed (06master...06note-that-unused-function-compiler-warning-should-not-be-fixed) 02https://github.com/bitcoin/bitcoin/pull/8005
 42 2016-05-05 10:44:01	0|GitHub73|13bitcoin/06master 1447eda2d 15fanquake: [depends] Add -stdlib=libc++ to darwin CXX flags
 43 2016-05-05 10:44:01	0|GitHub73|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/42a67533828f...f9b4582292e8
 44 2016-05-05 10:44:02	0|GitHub73|13bitcoin/06master 14f9b4582 15Wladimir J. van der Laan: Merge #8002: [depends] Add -stdlib=libc++ to darwin CXX flags...
 45 2016-05-05 10:44:16	0|GitHub176|[13bitcoin] 15laanwj closed pull request #8002: [depends] Add -stdlib=libc++ to darwin CXX flags (06master...06depends-darwin-stdlib) 02https://github.com/bitcoin/bitcoin/pull/8002
 46 2016-05-05 10:52:24	0|GitHub88|13bitcoin/06master 140281678 15Warren Togami: doc: Fedora build requirements
 47 2016-05-05 10:52:24	0|GitHub88|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f9b4582292e8...ff69aafe52f9
 48 2016-05-05 10:52:25	0|GitHub88|13bitcoin/06master 14ff69aaf 15Wladimir J. van der Laan: Merge #7968: doc: Fedora build requirements...
 49 2016-05-05 10:52:35	0|GitHub75|[13bitcoin] 15laanwj closed pull request #7968: doc: Fedora build requirements (06master...06fedora_build_readme) 02https://github.com/bitcoin/bitcoin/pull/7968
 50 2016-05-05 10:52:53	0|GitHub74|13bitcoin/06master 14f7c4f79 15Daniel Kraft: [trivial] Add missing const qualifiers....
 51 2016-05-05 10:52:53	0|GitHub74|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ff69aafe52f9...e8d917591f28
 52 2016-05-05 10:52:54	0|GitHub74|13bitcoin/06master 14e8d9175 15Wladimir J. van der Laan: Merge #7977: [trivial] Add missing const qualifiers....
 53 2016-05-05 10:53:05	0|GitHub193|[13bitcoin] 15laanwj closed pull request #7977: [trivial] Add missing const qualifiers. (06master...06consts) 02https://github.com/bitcoin/bitcoin/pull/7977
 54 2016-05-05 10:54:33	0|GitHub20|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e8d917591f28...06303533230f
 55 2016-05-05 10:54:34	0|GitHub20|13bitcoin/06master 147db0ecb 15Andrew Chow: Test for signing messages...
 56 2016-05-05 10:54:34	0|GitHub20|13bitcoin/06master 14f90efbf 15Andrew: Create signmessagewithprivkey rpc...
 57 2016-05-05 10:54:35	0|GitHub20|13bitcoin/06master 140630353 15Wladimir J. van der Laan: Merge #7953: Create signmessagewithprivkey rpc...
 58 2016-05-05 10:54:42	0|GitHub14|[13bitcoin] 15laanwj closed pull request #7953: Create signmessagewithprivkey rpc (06master...06signmessagewithprivkey) 02https://github.com/bitcoin/bitcoin/pull/7953
 59 2016-05-05 10:57:52	0|GitHub54|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/06303533230f...d51618e481ab
 60 2016-05-05 10:57:53	0|GitHub54|13bitcoin/06master 14091d6e0 15Wladimir J. van der Laan: http: Do a pending c++11 simplification...
 61 2016-05-05 10:57:53	0|GitHub54|13bitcoin/06master 14f97b410 15Wladimir J. van der Laan: http: Add log message when work queue is full...
 62 2016-05-05 10:57:54	0|GitHub54|13bitcoin/06master 1437b2137 15Wladimir J. van der Laan: http: Change boost::scoped_ptr to std::unique_ptr in HTTPRequest...
 63 2016-05-05 10:58:01	0|GitHub179|[13bitcoin] 15laanwj closed pull request #7966: http: Do a pending c++11 simplification handling work items (06master...062016_04_httpserver_c++11) 02https://github.com/bitcoin/bitcoin/pull/7966
 64 2016-05-05 11:01:15	0|wumpus|anything else that is ready for merge?
 65 2016-05-05 11:02:41	0|gmaxwell|I wish I knew where #7840 was.
 66 2016-05-05 11:09:01	0|wumpus|well seems to have plenty of tested as well as untested acks
 67 2016-05-05 11:09:20	0|wumpus|there are some nits by sdaftuar: do they need to be handled in that pull?
 68 2016-05-05 11:10:00	0|gmaxwell|sipa wanted to stop making refactors further, otherwise it would never go in, so I dont ~think~ so.
 69 2016-05-05 11:10:11	0|gmaxwell|I have further changes on top of that that I'm siting on waiting for that to go in.
 70 2016-05-05 11:10:24	0|wumpus|if there is nothing *critical* and it's only about refactors, I'd suggest the same
 71 2016-05-05 11:14:33	0|wumpus|so that means #7840 is ready...
 72 2016-05-05 11:14:59	0|GitHub130|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d51618e481ab...3b9a0bf41f23
 73 2016-05-05 11:15:00	0|GitHub130|13bitcoin/06master 14dc13dcd 15Pieter Wuille: Split up and optimize transaction and block inv queues
 74 2016-05-05 11:15:00	0|GitHub130|13bitcoin/06master 14f2d3ba7 15Gregory Maxwell: Eliminate TX trickle bypass, sort TX invs for privacy and priority....
 75 2016-05-05 11:15:01	0|GitHub130|13bitcoin/06master 14ed70683 15Pieter Wuille: Handle mempool requests in send loop, subject to trickle...
 76 2016-05-05 11:15:07	0|GitHub56|[13bitcoin] 15laanwj closed pull request #7840: Several performance and privacy improvements to inv/mempool handling (06master...06splitinvtxblock) 02https://github.com/bitcoin/bitcoin/pull/7840
 77 2016-05-05 11:15:19	0|wumpus|anything else?
 78 2016-05-05 11:16:33	0|wumpus|doing final testing on https://github.com/bitcoin/bitcoin/pull/7814 at the moment
 79 2016-05-05 11:16:46	0|gmaxwell|wumpus: whats the goal in the rounds of merging right now? just cleaning out backlog?
 80 2016-05-05 11:16:54	0|wumpus|just moving forward
 81 2016-05-05 11:17:05	0|gmaxwell|Good.
 82 2016-05-05 11:18:31	0|gmaxwell|#7934 seems good to me I've had it running since my utACK without issue.
 83 2016-05-05 11:25:29	0|fanquake|wumpus issues that could be reviewed/closed by inactivity 6835 6355
 84 2016-05-05 11:28:03	0|wumpus|yes #6835 won't be merged anyway - it at least used to be kept up to date by people that cared about it, but it can just as well be a separate branch on someone's repository without being a pull request
 85 2016-05-05 11:29:31	0|fanquake|Also #7149
 86 2016-05-05 11:30:24	0|wumpus|not sure about #6355, seems it just received very little review and testing
 87 2016-05-05 11:31:38	0|wumpus|generally I don't close pulls for inactivty, only issues, if the OP doesn't respond to requests for more data. In this case the author can't help that his PR received so little attention
 88 2016-05-05 11:32:51	0|wumpus|bah #7149 has a lot of changes for a 'bugfix'
 89 2016-05-05 11:47:04	0|fanquake|Seems that #7814 fails on osx when you run the extended test suite
 90 2016-05-05 11:52:32	0|MarcoFalk_|fanquake, which test / exception?
 91 2016-05-05 11:55:20	0|fanquake|MarcoFalk_ will post to GH
 92 2016-05-05 11:57:09	0|fanquake|Looks like you've just missed signmessages.py
 93 2016-05-05 11:59:23	0|MarcoFalk_|When was this merged?
 94 2016-05-05 11:59:29	0|MarcoFalk_|Is probably a merge conflict
 95 2016-05-05 12:00:07	0|MarcoFalk_|You are running merge(master, pull) ?
 96 2016-05-05 12:00:13	0|fanquake|When did I merge it? 10 minutes ago
 97 2016-05-05 12:00:35	0|fanquake|Looking at the PR, you haven't touched signmessages.py at all
 98 2016-05-05 12:02:52	0|MarcoFalk_|Oh, actually you need to compile if you also want to run the signmessage.py test
 99 2016-05-05 12:10:18	0|GitHub118|[13bitcoin] 15Tyler-Hardin opened pull request #8006: Qt: Add option to disable the system tray icon (06master...06disable-tray) 02https://github.com/bitcoin/bitcoin/pull/8006
100 2016-05-05 12:14:43	0|jonasschnelli|Whoha! PR/Issue# >8000!
101 2016-05-05 12:15:56	0|wumpus|it will take some getting used to 5-digit PRs/issues
102 2016-05-05 12:17:29	0|jonasschnelli|hah.. yes. Soon.
103 2016-05-05 15:04:48	0|GitHub126|[13bitcoin] 15kazcw opened pull request #8007: Minor locking improvements (06master...06locknits) 02https://github.com/bitcoin/bitcoin/pull/8007
104 2016-05-05 17:02:00	0|GitHub84|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3b9a0bf41f23...006cdf64dc93
105 2016-05-05 17:02:01	0|GitHub84|13bitcoin/06master 14c0f660c 15Patrick Strateman: Replace c-style cast with c++ style static_cast.
106 2016-05-05 17:02:01	0|GitHub84|13bitcoin/06master 14ec9ad5f 15Patrick Strateman: Replace memcmp with std::equal in CScript::FindAndDelete...
107 2016-05-05 17:02:02	0|GitHub84|13bitcoin/06master 14e2a30bc 15Gavin Andresen: Unit test for CScript::FindAndDelete
108 2016-05-05 17:02:05	0|GitHub194|[13bitcoin] 15laanwj closed pull request #7907:  Optimize and Cleanup CScript::FindAndDelete (06master...062016-04-17-findanddelete) 02https://github.com/bitcoin/bitcoin/pull/7907
109 2016-05-05 17:05:03	0|GitHub197|[13bitcoin] 15JeremyRand opened pull request #8009: Docs: Fixed invalid example paths in gitian-building.md (06master...06doc-gitian-building-offline-paths-fix) 02https://github.com/bitcoin/bitcoin/pull/8009
110 2016-05-05 19:00:10	0|wumpus|meeting time?
111 2016-05-05 19:00:29	0|anchow101|yes?
112 2016-05-05 19:00:55	0|btcdrak|yes
113 2016-05-05 19:01:09	0|jonasschnelli|yes
114 2016-05-05 19:01:24	0|gmaxwell|I guess so.
115 2016-05-05 19:01:25	0|lightningbot|Meeting started Thu May  5 19:01:24 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
116 2016-05-05 19:01:25	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
117 2016-05-05 19:01:25	0|wumpus|#startmeeting
118 2016-05-05 19:01:51	0|BlueMatt|hi all
119 2016-05-05 19:02:03	0|btcdrak|topics?
120 2016-05-05 19:02:17	0|wumpus|last week's action items were
121 2016-05-05 19:02:18	0|wumpus|ACTION: (sipa) list a few areas where i think mildly tricky things are done that warrant review (wumpus, 19:08:50)
122 2016-05-05 19:02:26	0|sipa|in a plane, i can only stay online for 15 minutes
123 2016-05-05 19:02:32	0|wumpus|ACTION: bip 144 needs to include the service bit stuff
124 2016-05-05 19:02:33	0|sipa|oops, forgot about that; will do
125 2016-05-05 19:02:40	0|sipa|that's done
126 2016-05-05 19:02:42	0|instagibbs|wumpus, merged
127 2016-05-05 19:02:45	0|gmaxwell|petertodd: morcos: sdaftuar: phantomcircuit: MarcoFalk_: jonasschnelli: luke-jr: jtimon: instagibbs:
128 2016-05-05 19:02:46	0|wumpus|ACTION: (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
129 2016-05-05 19:03:01	0|phantomcircuit|im here
130 2016-05-05 19:03:05	0|sdaftuar|hi
131 2016-05-05 19:03:18	0|cfields|here
132 2016-05-05 19:03:27	0|gmaxwell|wumpus: I've failed to do that so far, sorry.
133 2016-05-05 19:03:39	0|wumpus|no rush I suppose
134 2016-05-05 19:03:43	0|wumpus|any other topics?
135 2016-05-05 19:03:59	0|anchow101|segwit versionbit
136 2016-05-05 19:04:03	0|nickler|I've had a look at the btcd segwit PR, it includes around 5 tests
137 2016-05-05 19:04:21	0|wumpus|#topic segwit versionbit
138 2016-05-05 19:04:59	0|anchow101|The bip still says tbd for bit and date.
139 2016-05-05 19:05:30	0|wumpus|if there's no special reason to pick a specific bit I'd suggest previous_bit+1
140 2016-05-05 19:05:31	0|btcdrak|8 is lucky in China
141 2016-05-05 19:05:53	0|sdaftuar|previous_bit + 1 makes sense to me...
142 2016-05-05 19:05:55	0|btcdrak|wumpus: ack
143 2016-05-05 19:05:55	0|sipa|so (1 << 1), also fine
144 2016-05-05 19:06:01	0|anchow101|+1
145 2016-05-05 19:06:14	0|BlueMatt|I'm with btcdrak
146 2016-05-05 19:06:22	0|wumpus|otherwise it leaves holes, not a big deal, but dealing out consecutively may reduce the chance of accidentally duplicate assignments
147 2016-05-05 19:06:32	0|btcdrak|are we ready to think about dates? even for testnet?
148 2016-05-05 19:06:50	0|jl2012|i think we should set the testnet date now?
149 2016-05-05 19:06:54	0|gmaxwell|sipa: whatever number you're proposing please post it to the mailing list.
150 2016-05-05 19:07:17	0|jl2012|start 1 Apr 2016, end 1 Jan 2018?
151 2016-05-05 19:07:26	0|wumpus|probably we should have some living document that keeps track of current bit assignments, outside the bips
152 2016-05-05 19:07:32	0|NicolasDorier|for testnet do we need a date ? we did not for csv
153 2016-05-05 19:08:24	0|anchow101|NicolasDorier, the dat for csv on testnet was March 1st
154 2016-05-05 19:08:27	0|anchow101|*date
155 2016-05-05 19:08:35	0|NicolasDorier|ok my bad
156 2016-05-05 19:09:47	0|btcdrak|wumpus: maybe we can add a file bip-0009/assignments.md in the bips repository
157 2016-05-05 19:09:50	0|anchow101|If the release can be out before June, what about June 1st for a mainnet start date? And May 1st for testnet?
158 2016-05-05 19:10:22	0|gmaxwell|Dates should not be set until the software is known ready for release, and we are not currently there.
159 2016-05-05 19:10:29	0|gmaxwell|There is no need to be over-eager.
160 2016-05-05 19:10:37	0|sipa|i think we need to have a deployment active on testnet before even beginning to consider a start time on mainnet
161 2016-05-05 19:10:52	0|wumpus|btcdrak: sounds good to me
162 2016-05-05 19:10:58	0|gmaxwell|I think june first would be fine, but it could be set the day before, for all the system cares.
163 2016-05-05 19:11:29	0|wumpus|#action add a file bip-0009/assignments.md in the bips repository to keep track of an overview of current bit assignments separate from their bips
164 2016-05-05 19:11:32	0|btcdrak|jl2012: no need to have such a long expiry date for testnet.
165 2016-05-05 19:13:27	0|wumpus|okay
166 2016-05-05 19:13:54	0|wumpus|so do people agree on june 1?
167 2016-05-05 19:14:04	0|morcos|for testnet?
168 2016-05-05 19:14:04	0|sipa|for testnet?
169 2016-05-05 19:14:10	0|morcos|i don't see why not make it earlier
170 2016-05-05 19:14:14	0|wumpus|that's what the discussion is about right?
171 2016-05-05 19:14:24	0|morcos|it kind of doesn't matter, just make it may 1st and it happens when it happens
172 2016-05-05 19:14:33	0|sipa|indeed
173 2016-05-05 19:14:37	0|btcdrak|morcos: ack
174 2016-05-05 19:14:37	0|wumpus|for mainnet it'd be kind of crazy to decide on an activation date now IMO
175 2016-05-05 19:14:43	0|sipa|we're not testing the deployment logic and teansitions
176 2016-05-05 19:14:48	0|gmaxwell|morcos +1 for testnet.
177 2016-05-05 19:14:58	0|sipa|may 1st for testnet sounds finr
178 2016-05-05 19:15:05	0|wumpus|may 1st? more time travel? I've seen enough deloreans this week
179 2016-05-05 19:15:10	0|jonasschnelli|hah
180 2016-05-05 19:15:12	0|morcos|i might be obnoxious and start now...  :)
181 2016-05-05 19:15:19	0|instagibbs|morcos, hostile softforks incoming
182 2016-05-05 19:15:28	0|gmaxwell|This date is not something that needs to be set _in advance_, and it also shouldn't be set without coordiating with other implementers (at least in principle)
183 2016-05-05 19:15:38	0|morcos|wumpus: its what we did with csv, it just means you can starg signaling immediately
184 2016-05-05 19:15:44	0|wumpus|okay, no decision on a date then
185 2016-05-05 19:16:02	0|wumpus|#action discuss testnet activation date on bitcoin-dev mailing list
186 2016-05-05 19:16:07	0|morcos|gmaxwell: i kind of disagree, i think that the code is mature enough that we should activate on testnet now
187 2016-05-05 19:16:16	0|gmaxwell|morcos: I'm not talking about testnet.
188 2016-05-05 19:16:25	0|morcos|gmaxwell: teh rest of us are  :)
189 2016-05-05 19:16:27	0|wumpus|we AREE talking about testnet
190 2016-05-05 19:16:31	0|gmaxwell|Testnet is fine. do whatever with testnet. If it causes turbulance there, oh well.
191 2016-05-05 19:16:33	0|wumpus|please don't confuse things
192 2016-05-05 19:16:49	0|gmaxwell|wumpus: _YOU_ are talking about testnet jl2012 and anchow101 were not.
193 2016-05-05 19:17:08	0|gmaxwell|I already +1 morcos for testnet.
194 2016-05-05 19:17:08	0|wumpus|huh *confused*
195 2016-05-05 19:17:09	0|jl2012|no, I'm talking about testnet
196 2016-05-05 19:17:29	0|phantomcircuit|haha
197 2016-05-05 19:17:36	0|morcos|ok so to summarize, email to bitcoin ML stating we are setting the testnet activation start date as may 1st because we believe at this point the activation start date is likely the only consensus change remaining with segwit
198 2016-05-05 19:18:12	0|gmaxwell|Because it's testnet and the delayed start logic doesn't apply there, we don't care about creating turbulance there if miners upgrade ahead of nodes.
199 2016-05-05 19:18:12	0|wumpus|makes sense
200 2016-05-05 19:18:21	0|morcos|this will allow anyone to test their various versions of segwit (different implementations and backports) against each other potentially even before merging
201 2016-05-05 19:18:48	0|anchow101|morcos: ack
202 2016-05-05 19:18:53	0|morcos|gmaxwell: yes there is no reason to delay, but there is reason to agree on the start date so that we all activate at the same time
203 2016-05-05 19:19:21	0|gmaxwell|morcos: yes, may first is fine.
204 2016-05-05 19:19:39	0|btcdrak|ok so (1<<1) with activation may 1st for testnet, and (1<<1) and date TDB for mainnet
205 2016-05-05 19:19:48	0|jonasschnelli|ack
206 2016-05-05 19:19:53	0|achow101|yes
207 2016-05-05 19:20:08	0|morcos|btcdrak: ack
208 2016-05-05 19:20:20	0|paveljanik|ack
209 2016-05-05 19:20:27	0|morcos|but what does TDB stand for?  :)
210 2016-05-05 19:20:45	0|gmaxwell|Totally delicious burger.
211 2016-05-05 19:20:49	0|jl2012|ack 1 May testnet, how about expiry date?
212 2016-05-05 19:20:55	0|cfields|ack, but we need to get the gbt changes in place quickly so that testnet is a valid representation of what miners will be running
213 2016-05-05 19:21:04	0|btcdrak|j2012: 1 year.
214 2016-05-05 19:21:09	0|morcos|ack 1 year
215 2016-05-05 19:21:27	0|BlueMatt|sgtm
216 2016-05-05 19:21:31	0|btcdrak|(1<<1) with activation may 1st and expiry 1 year for testnet, and (1<<1) and dates TBD for mainnet
217 2016-05-05 19:21:34	0|BlueMatt|phantomcircuit: when will we see testnet fork?
218 2016-05-05 19:21:47	0|morcos|cfields: can you summarize what GBT changes are needed still?
219 2016-05-05 19:22:57	0|morcos|does #7935 have anything at all to do with segwit?
220 2016-05-05 19:23:28	0|cfields|morcos: there's a proposal to bip9 that would require that miners set a flag signaling awareness of segwit
221 2016-05-05 19:23:46	0|cfields|*proposed amendment
222 2016-05-05 19:24:39	0|cfields|morcos: see https://github.com/bitcoin/bips/pull/365
223 2016-05-05 19:25:14	0|morcos|ok i haven't read through all that but i kind of thought it was orthogonal to segwit.  we already have versionbits SF's in the process of being activated.  is segwit somehow materially different.  if not, lets not confuse the issues
224 2016-05-05 19:25:58	0|gmaxwell|morcos: it's just that a non-sw aware miner can't use GBT w/ segwit and keep mining while they can use CSV.
225 2016-05-05 19:26:40	0|sdaftuar|gmaxwell: i don't follow why that is, can you explain?
226 2016-05-05 19:27:17	0|cfields|morcos: assuming that's adopted, some miners won't be creating blocks with commitments, so i'd like to make sure that we're testing on testnet. Otherwise it's not a great representation of mainnet mining.
227 2016-05-05 19:27:22	0|gmaxwell|I could be speaking out of my rear, my understanding at a distance was that non-SW ready gbt clients won't insert the commitment.
228 2016-05-05 19:27:33	0|sdaftuar|but the commitment is created by bitcoind
229 2016-05-05 19:28:02	0|gmaxwell|sdaftuar: classical GBT does not include a coinbase transaction, the client generates it using information from the template.
230 2016-05-05 19:28:13	0|morcos|if can't use GBT means can't change the txs selected by bitcoind then maybe you're right, but that seems a secondary problem
231 2016-05-05 19:28:15	0|cfields|sdaftuar: if a miner is too old to understand how to insert the commitment, bitcoind can provide only non-witness txs, so that the miner continues to produce valid blocks
232 2016-05-05 19:28:55	0|morcos|maybe we should take this up after the meeting.
233 2016-05-05 19:29:14	0|gmaxwell|sounds fine.
234 2016-05-05 19:29:53	0|cfields|ok. i only mentioned because i'd like to start upstreaming the mining/pool patches if we're going to deploy on testnet. And can't do that until the gbt stuff is finalized
235 2016-05-05 19:30:02	0|cfields|but fine to discuss later, i don't think it'll be an issue
236 2016-05-05 19:30:39	0|wumpus|ok, any other topics to be discussed?
237 2016-05-05 19:30:42	0|NicolasDorier|yes
238 2016-05-05 19:30:55	0|NicolasDorier|I just want opinion about
239 2016-05-05 19:31:00	0|NicolasDorier|making sure the wallet does not create uneconomical output based on current fees, and not based on mintxrelayfee (https://github.com/bitcoin/bitcoin/issues/7677)
240 2016-05-05 19:31:05	0|wumpus|nickler mentioned btcd segwit PR tests, but I'm not sure that was a topic suggestion
241 2016-05-05 19:31:08	0|morcos|cfields: i'd just like to distinguish between necessary changes and changes that are only needed if miners are going to be modifying the tx selection created by bitcoind.  the second category in my mind should not stand in the critical path
242 2016-05-05 19:31:46	0|NicolasDorier|I had problems with customers when mintxrelayfee where bump because occasionally wallet would produce bellow mintxrelayfee dust for other nods.
243 2016-05-05 19:31:57	0|wumpus|#topic uneconomical outputs in wallet based on current fees
244 2016-05-05 19:32:03	0|NicolasDorier|So I proposed to work on https://github.com/bitcoin/bitcoin/issues/7677
245 2016-05-05 19:32:04	0|nickler|wumpus: nope I was referring to the action item that mentioned roasbeefs implementation
246 2016-05-05 19:32:09	0|BlueMatt|also compact block bip, if anyone has bothered to read that
247 2016-05-05 19:32:16	0|wumpus|nickler: okay :)
248 2016-05-05 19:32:28	0|cfields|morcos: this has nothing to do with miners modifying tx output. it's that miners need to opt-in to segwit in order for bitcoind to give it witness tx. And that opt-in signal hasn't been implemented yet.
249 2016-05-05 19:33:35	0|gmaxwell|BlueMatt: was that a topic suggestion?
250 2016-05-05 19:34:10	0|wumpus|any opinions on the wallet issue mentioned by NicolasDorier?
251 2016-05-05 19:34:22	0|BlueMatt|gmaxwell: yes
252 2016-05-05 19:34:22	0|gmaxwell|NicolasDorier: I'll take a look at the issue.
253 2016-05-05 19:34:29	0|NicolasDorier|Breadwallet had issue also because of that when the mintxrelayfee was bumped
254 2016-05-05 19:34:39	0|NicolasDorier|so I think we should fix the wallet to not use mintxrelayfee
255 2016-05-05 19:34:51	0|NicolasDorier|but estimatedfee for determining the dust (only wallet part)
256 2016-05-05 19:35:14	0|NicolasDorier|would prevent having reliability issue in case it need to be increase in the future
257 2016-05-05 19:35:14	0|wumpus|it sounds sensible, wallet and relay policy are different things, although the mintxrelayfee should probably be the floor
258 2016-05-05 19:35:54	0|gmaxwell|or the dust threshould should just be made an infrequently changed fixed constant.
259 2016-05-05 19:36:20	0|NicolasDorier|gmaxwell: I am talking only about wallet, not relay policy
260 2016-05-05 19:36:38	0|NicolasDorier|ah
261 2016-05-05 19:36:59	0|NicolasDorier|I get your point. But well the problem would be the same with a constant. If we get a spam attack, we would increase it
262 2016-05-05 19:37:12	0|NicolasDorier|and then some wallet will produce below dust rejected by updated nodes
263 2016-05-05 19:37:15	0|morcos|yes, we should do both things
264 2016-05-05 19:37:18	0|gmaxwell|lets discuss on the issue.
265 2016-05-05 19:37:24	0|NicolasDorier|ok
266 2016-05-05 19:37:33	0|NicolasDorier|there is another quick topic I want to talk about
267 2016-05-05 19:37:51	0|morcos|we should separate wallet functionality to use some smarter higher value for "dust" and the floor for dust shoudl be a separate variable than the muliple of min relay that it is now
268 2016-05-05 19:38:21	0|morcos|(floor for dust = policy relay limit for dust)
269 2016-05-05 19:38:25	0|NicolasDorier|ok, seems good I'll start working on it. It made me some pain nin the past
270 2016-05-05 19:38:48	0|gmaxwell|morcos: I agree.
271 2016-05-05 19:39:35	0|NicolasDorier|My other quick topic is
272 2016-05-05 19:39:46	0|NicolasDorier|long time ago I made a PR to remove unused flag and code
273 2016-05-05 19:39:54	0|NicolasDorier|on https://github.com/bitcoin/bitcoin/pull/7574
274 2016-05-05 19:40:02	0|NicolasDorier|morcos a jtimon had a better idea
275 2016-05-05 19:40:08	0|NicolasDorier|instead of removing the flag
276 2016-05-05 19:40:26	0|NicolasDorier|transforming it into one flag for all consensus stuff
277 2016-05-05 19:40:36	0|NicolasDorier|I'm thinking working on it but
278 2016-05-05 19:41:00	0|NicolasDorier|if I understand it seems to be better to do such kind of work after the merge of segwit ?
279 2016-05-05 19:42:27	0|gmaxwell|NicolasDorier: usually if that question arises the answer is yes.
280 2016-05-05 19:42:39	0|wumpus|yes I think for such non-trivial consensus refactoring it's better to wait until after segwit
281 2016-05-05 19:42:52	0|NicolasDorier|ok so I'll keep it for later
282 2016-05-05 19:44:08	0|wumpus|ok
283 2016-05-05 19:44:24	0|gmaxwell|Next subject?
284 2016-05-05 19:44:24	0|wumpus|#topic compact block bip
285 2016-05-05 19:44:29	0|gmaxwell|I read it!
286 2016-05-05 19:45:04	0|BlueMatt|you're the only one :'(
287 2016-05-05 19:45:14	0|sdaftuar|not true...
288 2016-05-05 19:46:10	0|gmaxwell|BlueMatt: would you like other people to read it?
289 2016-05-05 19:46:21	0|BlueMatt|I would :p
290 2016-05-05 19:46:24	0|BlueMatt|next topic?
291 2016-05-05 19:47:36	0|cfields|heh, ack
292 2016-05-05 19:47:45	0|cfields|(ack to reading)
293 2016-05-05 19:47:54	0|btcdrak|^
294 2016-05-05 19:48:08	0|wumpus|so there's nothing about the contents to be discussed?
295 2016-05-05 19:48:18	0|BlueMatt|wumpus: not really...just hoping for feedback
296 2016-05-05 19:48:36	0|wumpus|that's what I mean, no feedback
297 2016-05-05 19:48:37	0|BlueMatt|wumpus: I think all the outstanding decisions were concluded between gmaxwell and I
298 2016-05-05 19:48:37	0|btcdrak|it's pretty dense reading, might need another week...
299 2016-05-05 19:48:44	0|BlueMatt|true
300 2016-05-05 19:48:56	0|gmaxwell|I gave a fair amount of feedback to Matt and he updated prior to putting it up.
301 2016-05-05 19:48:59	0|BlueMatt|so action to our army of devoted full-time code-reviwers? :p
302 2016-05-05 19:49:02	0|wumpus|(haven't read it yet)
303 2016-05-05 19:49:08	0|morcos|too much happening.  we need to clone ourselves.  at least wumpus
304 2016-05-05 19:49:12	0|BlueMatt|morcos: yea, that
305 2016-05-05 19:49:12	0|gmaxwell|BlueMatt: when will the PR be up?
306 2016-05-05 19:49:17	0|NicolasDorier|will read it. It takes me more time than most of you to understand it, can't say anything meaningful about it after reading it for 10min :p
307 2016-05-05 19:49:24	0|gmaxwell|BlueMatt: are you just waiting on feedback?
308 2016-05-05 19:49:28	0|BlueMatt|gmaxwell: I could do that this week...
309 2016-05-05 19:49:30	0|wumpus|#action read bluematt's compact block bip
310 2016-05-05 19:49:33	0|BlueMatt|gmaxwell: mostly
311 2016-05-05 19:49:34	0|wumpus|any URL?
312 2016-05-05 19:49:41	0|NicolasDorier|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html ?
313 2016-05-05 19:49:49	0|BlueMatt|wumpus: https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki
314 2016-05-05 19:49:49	0|wumpus|#link https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html
315 2016-05-05 19:50:02	0|wumpus|#link https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki
316 2016-05-05 19:50:37	0|wumpus|ok, any other topics?
317 2016-05-05 19:51:53	0|gmaxwell|Sounds like no.
318 2016-05-05 19:52:13	0|wumpus|hey not everyone is a fast typer :)
319 2016-05-05 19:52:17	0|wumpus|but indeed seems no
320 2016-05-05 19:52:23	0|NicolasDorier|well it's 4am here ! :p
321 2016-05-05 19:52:40	0|NicolasDorier|5 sorry
322 2016-05-05 19:52:46	0|wumpus|#endmeeting
323 2016-05-05 19:52:47	0|jonasschnelli|Japan people work always!
324 2016-05-05 19:52:47	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-05-19.01.log.html
325 2016-05-05 19:52:47	0|lightningbot|Meeting ended Thu May  5 19:52:46 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
326 2016-05-05 19:52:47	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-05-19.01.html
327 2016-05-05 19:52:47	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-05-19.01.txt
328 2016-05-05 19:52:58	0|NicolasDorier|jonasschnelli: not this week figure out
329 2016-05-05 19:52:59	0|BlueMatt|hey, we're early!
330 2016-05-05 19:53:03	0|NicolasDorier|this is golden week :p
331 2016-05-05 19:53:07	0|wumpus|yes it's an inconvenient time for japan
332 2016-05-05 19:53:57	0|morcos|cfields: sorry if you guys have been going over all this GBT stuff already..  i tried looking through the code and BIP PR's but seems like there is a bunch of detailed GBT stuff in there that has pretty much nothing to do with how most miners use it as far as i can tell
333 2016-05-05 19:54:33	0|morcos|is the problem that miners will replace the coinbase entirely, because the commitment won't actually change if the miners aren't doing witness txs right, so as long as they kept the output, i dont' think they should care
334 2016-05-05 19:54:45	0|cfields|morcos: np. It's fresh on my mind because i looked at it yesterday/today, otherwise I'd be clueless
335 2016-05-05 19:55:11	0|sipa|back
336 2016-05-05 19:55:15	0|jonasschnelli|landed?
337 2016-05-05 19:55:27	0|cfields|morcos: no, either way, miners will be using what bitcoind provides. We're not talking about modifications here
338 2016-05-05 19:55:31	0|morcos|sipa: segwit activated on testnet while you were gone.  pretty awesome huh
339 2016-05-05 19:55:59	0|cfields|(er, "will be using what bitcoind provides" for the sake of this discussion)
340 2016-05-05 19:56:21	0|sipa|jonasschnelli: yes, sfo
341 2016-05-05 19:56:29	0|morcos|cfields: yes i understand that we have narrowed the discussion to that case (although since the PR's are not narrowed to that case, they are harder to get through)
342 2016-05-05 19:56:52	0|sdaftuar|so to clarify: bitcoind will be including a coinbase tx with a valid commitment in response to gbt, right?
343 2016-05-05 19:57:35	0|sipa|sdaftuar: if there is at least one witness transaction in the block, and there is no commitment already
344 2016-05-05 19:57:38	0|sipa|(i think)
345 2016-05-05 19:57:44	0|sdaftuar|sipa: agreed
346 2016-05-05 19:57:46	0|morcos|what i'm asking is why in that case is it necessary for the miner to be segwit aware?  changing the coinbase doesn't change the commitment, but i'm guessing the problem is that miners override all the coinbase outputs and so that commitment will be lost, and so bitcoind would have to do more work to add it back in and recalc the merkle for the header
347 2016-05-05 19:58:30	0|gmaxwell|morcos: norma gbt right now has no coinbase transaction in it.
348 2016-05-05 19:58:31	0|sdaftuar|^ is morcos' guess here the issue?
349 2016-05-05 19:58:47	0|gmaxwell|normal*
350 2016-05-05 20:01:57	0|sdaftuar|gmaxwell: ah.  i am just now seeing where that coinbase gets stripped out of the response
351 2016-05-05 20:03:02	0|cfields|right, what gmaxwell said. miners insert the coinbase. but old miners don't know to insert the extra txout.
352 2016-05-05 20:04:03	0|sdaftuar|ok understood now.  so the idea would be to add a mode where CreateNewBlock just doesn't pick witness transactions, which old miners could use?
353 2016-05-05 20:04:27	0|cfields|if you only give them non-witness tx's, they'll continue to function fine. if they opt-in for the new serialization, no need to filter
354 2016-05-05 20:04:33	0|cfields|sdaftuar: right.
355 2016-05-05 20:04:34	0|gmaxwell|sdaftuar: right, and that mode would be default unless a special flag was sent.
356 2016-05-05 20:04:40	0|sdaftuar|got it
357 2016-05-05 20:05:03	0|gmaxwell|meaning that there is a guarenteed way to deploy with no mining infra updates.
358 2016-05-05 20:05:32	0|sdaftuar|yep
359 2016-05-05 20:05:56	0|cfields|but also a false sense of security while testing. so that's why i'd like to have the opt-in ready for miners to turn on asap
360 2016-05-05 20:07:10	0|morcos|yes this makes sense to me now too.  but INCREDIBLY frustrating.  we have to rewrite the API for minings. it's absurd to have all this consensus critical logic outside of bitcoind by default.
361 2016-05-05 20:08:27	0|morcos|sdaftuar points out that extra nonce makes that hard to fix
362 2016-05-05 20:10:23	0|morcos|cfields: so is there a PR that does what you're suggesting?
363 2016-05-05 20:10:57	0|cfields|morcos: afaik there's no implementation of the BIP yet.
364 2016-05-05 20:11:07	0|cfields|luke-jr: have you coded something up, or should I jump on it?
365 2016-05-05 20:11:16	0|cfields|(sorry, proposed BIP changes)
366 2016-05-05 20:12:56	0|cfields|morcos: to be more specific: the bip changes are PR'd, but the specific segwit case isn't implemented yet afaik
367 2016-05-05 20:12:58	0|cfields|sec for link
368 2016-05-05 20:13:20	0|cfields|morcos: https://github.com/bitcoin/bitcoin/pull/7935
369 2016-05-05 20:13:37	0|morcos|yeah i saw that, but i meant the code that only selects non witness txs for the block
370 2016-05-05 20:14:20	0|cfields|i'm assuming no
371 2016-05-05 20:27:23	0|GitHub180|[13bitcoin] 15kazcw opened pull request #8011: don't run ThreadMessageHandler at lowered priority (06master...06priority) 02https://github.com/bitcoin/bitcoin/pull/8011
372 2016-05-05 20:30:53	0|CodeShark|is meeting still underway?
373 2016-05-05 20:31:32	0|CodeShark|guess not..sorry I couldn't make it
374 2016-05-05 20:40:07	0|tripleslash|CodeShark: [2016/05/05 14:52:47] <wumpus> #endmeeting
375 2016-05-05 20:40:14	0|tripleslash|so about 50 minutes ago.
376 2016-05-05 20:43:44	0|CodeShark|yeah, already read through the scrollback. thx :)
377 2016-05-05 21:00:47	0|gmaxwell|morcos: if only someone had suggested that any hardfork would mask out the constant zero bits in PREV in the header so miners could use it as nonce....
378 2016-05-05 21:31:10	0|instagibbs|BlueMatt, I assume the XOR-adding scheme wraps around mod 2^64
379 2016-05-05 21:31:29	0|BlueMatt|instagibbs: yes
380 2016-05-05 21:31:32	0|BlueMatt|wait, no?
381 2016-05-05 21:31:35	0|BlueMatt|wait, whats your question?
382 2016-05-05 21:31:46	0|gmaxwell|he's asking if the addition is uint64_t addition, it is.
383 2016-05-05 21:31:59	0|BlueMatt|instagibbs: please suggest better wording
384 2016-05-05 21:32:17	0|BlueMatt|instagibbs: its this: https://github.com/TheBlueMatt/bitcoin/blob/udp/src/blockencodings.cpp#L37
385 2016-05-05 21:33:53	0|instagibbs|wasn't too confusing, but it wasn't stated in the bip
386 2016-05-05 21:34:12	0|instagibbs|(I'm also prejudiced from previous conversations so better to ask here)
387 2016-05-05 21:34:19	0|gmaxwell|I have a constructive proof that this scheme is not optimal but I don't think anyone cares.
388 2016-05-05 21:36:55	0|BlueMatt|yea, I'm not convinced its worth caring, and optimal versions are much more expensive
389 2016-05-05 21:37:03	0|BlueMatt|considering we're running that on so many txn, I'd prefer not.....
390 2016-05-05 21:38:40	0|gmaxwell|In an optimal scheme, for any to txids A and B, there should be a salt input C that makes them collide. If there is no such C, then someone trying to create collisions could avoid the pair A,B, and thus increase their success rate.  For this scheme, if A and B share the same even/oddness in each 64 bit word, then no C can make them collide. QED.
391 2016-05-05 21:38:54	0|gmaxwell|Yes, I don't think it matters but it's useful to know that this exists.
392 2016-05-05 21:40:13	0|instagibbs|just mentioning uint8 in the definition would be best, ill continue reading post family business
393 2016-05-05 21:43:13	0|roasbeef|nickler: Yeah, the test coverage on my PR leaves much to be desired. Most of the lingering TODO’s are related to increasing test coverage across the various packages (txscript+blockchain especially).
394 2016-05-05 21:43:56	0|roasbeef|nickler: Once I get the tests in, I’ll be restructuring the commits as they’ve started to sprawl a bit as I’ve fixed bugs, tweaked API’s, etc. I’ve been busy with other non-bitcoin stuff (this whole graduating thing), but hope to get the PR to it’s final form (insert Frieza meme ;) ) in the next week or two.
395 2016-05-05 23:06:16	0|nickler|roasbeef: sounds great! My comment was not meant to be judging; the idea was to exchange tests between multiple implementations if possible. Let me know when you've worked on the PR again. Good luck with your graduating thing.
396 2016-05-05 23:17:36	0|warren|A popular RPM package of Bitcoin uses this patch: https://togami.com/~warren/temp/2016/bitcoin-0.12.0-destchange.patch
397 2016-05-05 23:18:10	0|warren|To get rid of this patch what should we upstream?  Matt's guess was to add an optional parameter to an RPC
398 2016-05-05 23:23:32	0|roasbeef|nickler: No worries, I took no offense :). Great, I think there's a lot of value in exchanging tests across implementations. I plan to port over core's new json script, sighash and transaction tests to btcd. I'll contribute any additional cases I add upstream to core.
399 2016-05-05 23:34:25	0|GitHub80|[13bitcoin] 15Tyler-Hardin opened pull request #8012: Qt: Delay user confirmation of send (06master...06send-delay) 02https://github.com/bitcoin/bitcoin/pull/8012