1 2017-01-05 02:36:00	0|gmaxwell|morcos: I'd like to review #9404 but it would be easier to do if you rebased on #9465 if you think you'll be doing that anyways.
  2 2017-01-05 02:36:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Make a second pass with same coins in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
  3 2017-01-05 02:36:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
  4 2017-01-05 02:38:09	0|gmaxwell|morcos: will #9404 increase the number of cases where you get change back when you were really trying to send all your funds? hm. I guess not, if you're doing a subtract fee from amount the second pass will subtract less.
  5 2017-01-05 02:38:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Make a second pass with same coins in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
  6 2017-01-05 02:38:29	0|gmaxwell|okay bot, we got the picture.
  7 2017-01-05 02:40:56	0|sipa|haha
  8 2017-01-05 02:41:07	0|sipa|maybe it needs rate limiting
  9 2017-01-05 02:43:08	0|btcdrak|what happens if you quote ticket A, which references B and in the title of B reference A? would gribble flood the channel?
 10 2017-01-05 02:58:36	0|sipa|btcdrak: i don't think it triggers based on things it says itself
 11 2017-01-05 03:06:57	0|morcos|gmaxwell: yep, i was going to do that, 9465 (just leave off the # if you don't want the bot) looks good to me, was just going to let it sit for a day before i rebased
 12 2017-01-05 03:08:09	0|morcos|9404 shouldn't have any affect when you were trying to send all your funds..  it only kicks in if you already had change and that change was big enough to absorb fees
 13 2017-01-05 03:09:01	0|morcos|i also have #9343 which makes a change to cases when you are subtractFeeFromAmount'ing which i think will make future improvements easier if we're willing to accept the change in behavior
 14 2017-01-05 03:09:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9343 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 15 2017-01-05 03:10:51	0|morcos|in any case, i think we should evaluate these as to whether they are better behavior than existing but not hold them to too high a standard b/c i think only a reasonable simple change has a chance for 0.14..  after that we can try to do something more complete
 16 2017-01-05 07:47:38	0|jonasschnelli|Hah. Eric Voskuli's answer to this nails it: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013431.html
 17 2017-01-05 08:20:06	0|gmaxwell|morcos: I agree that we need to focus on small improvements that make things simply better at the moment, and that a big redesign is out of scope at the moment.
 18 2017-01-05 08:33:13	0|jonasschnelli|We had 15208 github comments in 2016, from 517 users. That's an avg of ~41.5 comments per day.
 19 2017-01-05 09:29:15	0|bitcoin-git|13bitcoin/06master 140388afe 15Luke Dashjr: Let autoconf detect presence of EVP_MD_CTX_new...
 20 2017-01-05 09:29:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7dac1e5e9e88...70145064153a
 21 2017-01-05 09:29:16	0|bitcoin-git|13bitcoin/06master 147014506 15Wladimir J. van der Laan: Merge #9475: Let autoconf detect presence of EVP_MD_CTX_new...
 22 2017-01-05 09:29:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9475: Let autoconf detect presence of EVP_MD_CTX_new (06master...06EVP_MD_CTX_new) 02https://github.com/bitcoin/bitcoin/pull/9475
 23 2017-01-05 09:29:49	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/70145064153a...48d7e0d5e463
 24 2017-01-05 09:29:50	0|bitcoin-git|13bitcoin/06master 1448d7e0d 15Wladimir J. van der Laan: Merge #9474: Mark the minconf parameter to move as ignored...
 25 2017-01-05 09:29:50	0|bitcoin-git|13bitcoin/06master 14ce370c1 15Pieter Wuille: Mark the minconf parameter to move as ignored
 26 2017-01-05 09:30:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9474: Mark the minconf parameter to move as ignored (06master...06stale_minconf_parameter) 02https://github.com/bitcoin/bitcoin/pull/9474
 27 2017-01-05 09:43:54	0|wumpus|jonasschnelli: wow
 28 2017-01-05 09:49:29	0|bitcoin-git|13bitcoin/06master 14407cdd6 15Pieter Wuille: Do not evaluate hidden LogPrint arguments
 29 2017-01-05 09:49:29	0|bitcoin-git|13bitcoin/06master 14c4b7d4f 15Wladimir J. van der Laan: Merge #9417: Do not evaluate hidden LogPrint arguments...
 30 2017-01-05 09:49:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/48d7e0d5e463...c4b7d4f79c85
 31 2017-01-05 09:49:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9417: Do not evaluate hidden LogPrint arguments (06master...06bypass_debug) 02https://github.com/bitcoin/bitcoin/pull/9417
 32 2017-01-05 10:00:48	0|jonasschnelli|Currently verifying my data..
 33 2017-01-05 10:01:07	0|jonasschnelli|But I guess we had 1563 PRs opened in 2016.
 34 2017-01-05 10:01:30	0|jonasschnelli|1032 merged (66%)
 35 2017-01-05 10:01:49	0|jonasschnelli|146 still open (~9%)
 36 2017-01-05 10:02:11	0|jonasschnelli|385 closed (~24.6%)
 37 2017-01-05 10:02:30	0|jonasschnelli|(though the last one may have some false-positives [manual closed merges])
 38 2017-01-05 10:02:43	0|wumpus|it at least feels like it was a really busy year in that regard
 39 2017-01-05 10:11:51	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c4b7d4f79c85...cfe41d7a6034
 40 2017-01-05 10:11:52	0|bitcoin-git|13bitcoin/06master 147f7f102 15Karl-Johan Alm: Switched bitcoin-cli.cpp to use RAII unique pointers with deleters.
 41 2017-01-05 10:11:52	0|bitcoin-git|13bitcoin/06master 14e5534d2 15Karl-Johan Alm: Added std::unique_ptr<> wrappers with deleters for libevent modules.
 42 2017-01-05 10:11:53	0|bitcoin-git|13bitcoin/06master 14280a559 15Karl-Johan Alm: Added some simple tests for the RAII-style events.
 43 2017-01-05 10:12:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9387: [Refactor] RAII of libevent stuff using unique ptrs with deleters (06master...06raii-libevents) 02https://github.com/bitcoin/bitcoin/pull/9387
 44 2017-01-05 10:19:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cfe41d7a6034...406f35d99d0f
 45 2017-01-05 10:20:00	0|bitcoin-git|13bitcoin/06master 143c8f63b 15Doug: Make linearize scripts Python 3-compatible.
 46 2017-01-05 10:20:00	0|bitcoin-git|13bitcoin/06master 14d5aa198 15Doug: Allow linearization scripts to support hash byte reversal...
 47 2017-01-05 10:20:01	0|bitcoin-git|13bitcoin/06master 14406f35d 15Wladimir J. van der Laan: Merge #9373: Linearize script update (hash byte reversal and Python 3 support)...
 48 2017-01-05 10:20:12	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9373: Linearize script update (hash byte reversal and Python 3 support) (06master...06linearize-update) 02https://github.com/bitcoin/bitcoin/pull/9373
 49 2017-01-05 10:23:23	0|kallewoof|I am noticing that listsinceblock is sometimes including and sometimes not including a transaction that was double-spent and discarded by the network. Is this expected?
 50 2017-01-05 10:25:10	0|kallewoof|Should've asked on #bitcoin-dev. Migrating, sorry.
 51 2017-01-05 10:33:05	0|bitcoin-git|13bitcoin/06master 1473f4119 15Karl-Johan Alm: Refactoring: Removed using namespace <xxx> from bench/ and test/ source files.
 52 2017-01-05 10:33:05	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/406f35d99d0f...4cfd57d2e382
 53 2017-01-05 10:33:06	0|bitcoin-git|13bitcoin/06master 144cfd57d 15MarcoFalke: Merge #9281: Refactor: Remove using namespace <xxx> from bench/ & test/ sources...
 54 2017-01-05 10:33:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9281: Refactor: Remove using namespace <xxx> from bench/ & test/ sources (06master...06no-using-namespace-bench-test) 02https://github.com/bitcoin/bitcoin/pull/9281
 55 2017-01-05 10:33:37	0|wumpus|kallewoof: depends on the reason for 'sometimes' I suppose :)
 56 2017-01-05 10:36:42	0|wumpus|I'd say random non-deterministic behavior is never intended
 57 2017-01-05 10:37:40	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9476: Refactor: Remove using namespace <xxx> from rpc/ & script/ sources (06master...06no-using-namespace-rpc-script) 02https://github.com/bitcoin/bitcoin/pull/9476
 58 2017-01-05 10:42:06	0|kallewoof|@wumpus: http://pastebin.com/EqupZuFM (missing case) vs http://pastebin.com/Phy6mN3G (present case).
 59 2017-01-05 10:46:55	0|kallewoof|It is an automated test. Only thing I can think of is some weird timing, but I'm being very generous with letting things sync so not sure what's going on.
 60 2017-01-05 10:47:29	0|wumpus|I wonder, does listing transactions not in blocks make sense at all for "listsinceblock"
 61 2017-01-05 10:47:53	0|wumpus|apparently it's a difference with regard to what unconfirmed/conflicted transactions are listed
 62 2017-01-05 10:48:05	0|kallewoof|My assumption was that it would list anything affecting me given the last state of the block chain from the hash I give. I.e. if a tx was dropped it would be present.
 63 2017-01-05 10:48:52	0|kallewoof|Specifically an invoice system would do listsinceblock periodically to ensure payments did not get double spent or similar. As it is, you have to do extra work to detect those.
 64 2017-01-05 10:50:03	0|wumpus|in that case not showing "orphaned" transactions would be better
 65 2017-01-05 10:50:51	0|wumpus|but a difference like that could indeed be due to a timing or race condition, e.g. block not yet processed by the wallet
 66 2017-01-05 10:50:52	0|kallewoof|What is the proper way to detect a double spend, in that case? I thought listsinceblock seemed ideal. And it is, at least sometimes.
 67 2017-01-05 10:51:22	0|fanquake|wumpus Spoke with theuni about some depends changes yesterday, so waiting on some feedback from him about most of those prs.
 68 2017-01-05 10:52:05	0|fanquake|re libevent, I think potential code improvements should be in a followup PR? Such as removing work arounds, any no-longer needed version checks etc?
 69 2017-01-05 10:52:25	0|wumpus|fanquake: I think the libevent change is ok, not sure about the remark about that the hash is potentially not stable
 70 2017-01-05 10:52:40	0|wumpus|fanquake: well we're far from being able to remove those workaround
 71 2017-01-05 10:52:50	0|wumpus|fanquake: it should stil support building with stable libevent :)
 72 2017-01-05 10:53:00	0|wumpus|just with new libevent it can use the new features
 73 2017-01-05 10:53:09	0|wumpus|(which it already does, in some places)
 74 2017-01-05 10:53:27	0|fanquake|wumpus Yea I would have thought it would be stable also. However, there could be a "more stable" URL before 0.14.0
 75 2017-01-05 10:53:38	0|fanquake|Might even be a proper release!
 76 2017-01-05 10:54:03	0|wumpus|the only option for us I see there would be to copy the file somewhere and host it there
 77 2017-01-05 10:54:33	0|fanquake|Yes we can do that also, we already host some files as a backup on bitcoincore.org.
 78 2017-01-05 10:54:51	0|fanquake|I'd like to put Boost on there so we can remove our last use of SourceForge.
 79 2017-01-05 10:55:18	0|wumpus|should ask cfields for that though, I don't have access to that server AFAIK
 80 2017-01-05 10:56:19	0|fanquake|Yes I'll bring it up with him later on.
 81 2017-01-05 10:57:27	0|fanquake|Does #9475 mean a 0.13.3 release quite soon? Or waiting a while longer for more bug reports.
 82 2017-01-05 10:57:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub
 83 2017-01-05 10:58:03	0|wumpus|fanquake: if you ask me, I don't think a build system issue necessitates an urgent release
 84 2017-01-05 10:58:08	0|wumpus|we should focus on 0.14.0 now
 85 2017-01-05 11:01:16	0|wumpus|#9475 should just go on the stack of things to include when a 0.13.3 is released
 86 2017-01-05 11:01:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9475 | Let autoconf detect presence of EVP_MD_CTX_new by luke-jr · Pull Request #9475 · bitcoin/bitcoin · GitHub
 87 2017-01-05 11:07:06	0|bitcoin-git|13bitcoin/06master 14d29505d 15jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141.
 88 2017-01-05 11:07:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4cfd57d2e382...ce43630d1e97
 89 2017-01-05 11:07:07	0|bitcoin-git|13bitcoin/06master 14ce43630 15Wladimir J. van der Laan: Merge #8747: [rpc] Fix transaction size comments and RPC help text....
 90 2017-01-05 11:07:14	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #8747: [rpc] Fix transaction size comments and RPC help text. (06master...06rpc_comments) 02https://github.com/bitcoin/bitcoin/pull/8747
 91 2017-01-05 11:25:57	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9473: doc: Parameterize rpcauth help text for translation (06master...06Mf1701-transPara) 02https://github.com/bitcoin/bitcoin/pull/9473
 92 2017-01-05 11:28:07	0|MarcoFalke|wumpus: The rpcauth still needs a `make translate` to show up properly for translators in transifex.
 93 2017-01-05 11:28:18	0|MarcoFalke|Not super important, but letting you know.
 94 2017-01-05 11:29:06	0|MarcoFalke|Would you mind to create a pull request for `make translate` updates whenever this hasn't been done in months?
 95 2017-01-05 11:29:17	0|MarcoFalke|Thus, we could catch failures early
 96 2017-01-05 11:29:38	0|MarcoFalke|(Not after they have been propagated to transifex)
 97 2017-01-05 11:39:58	0|Alsazia|Premium link generator (30+ host supported) ---> www.galileo.pw
 98 2017-01-05 11:43:32	0|phantomcircuit|wumpus, listsinceblock should almost certainly not list things which aren't actually in a block
 99 2017-01-05 12:12:28	0|wumpus|MarcoFalke: the reason for having only a relatively small translation window is that it doesn't matter whether "make translate" is before that in the meantime
100 2017-01-05 12:12:45	0|wumpus|MarcoFalke: during the translation window (e.g. starting this month for 0.14) we have to make sure it is up to date though
101 2017-01-05 12:29:01	0|wumpus|(well that's one of the reasons; the other is to prevent translators from wasting time translating messages in the meantime that go away before the release anyway)
102 2017-01-05 12:39:58	0|fanquake|Pretty sure theuni has a patch to fix the weird 9472 error. However he's on a plane I think.
103 2017-01-05 13:33:42	0|sipa|kallewoof: is it about double spends tgat your node has seen? they're not usually relayed by the network
104 2017-01-05 13:35:42	0|sipa|fanquake: he's in NY
105 2017-01-05 13:50:59	0|fanquake|Just chased that code in 9451 back to "First commit"
106 2017-01-05 14:16:28	0|phantomcircuit|fanquake, i believe i was right there?
107 2017-01-05 14:16:35	0|phantomcircuit|seems to be about multi byte op codes
108 2017-01-05 14:17:22	0|sipa|even then it was redundant
109 2017-01-05 14:17:30	0|sipa|but it did make more sense
110 2017-01-05 14:34:30	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (06master...06replace-boostforeach) 02https://github.com/bitcoin/bitcoin/pull/9478
111 2017-01-05 14:36:57	0|phantomcircuit|i can fuzz test 9451 but not at the moment
112 2017-01-05 14:42:46	0|fanquake|kallewoof See the discussion in #8718 re bulk BOOST_FOREACH changes. Have a feel opinion may still be as it was a few months ago.
113 2017-01-05 14:42:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/8718 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
114 2017-01-05 14:44:26	0|fanquake|Although your changeset seems to be smaller than the previous attempt. 59 files now vs 75 previous.
115 2017-01-05 17:43:54	0|gmaxwell|sipa:
116 2017-01-05 17:43:57	0|gmaxwell|./.bitcoin/debug.log.reindex1  11670.622538
117 2017-01-05 17:44:00	0|gmaxwell|./.bitcoin/debug.log.reindex2  12182.296543
118 2017-01-05 17:45:27	0|gmaxwell|These are reindex times on a dbcache=2000 host from the time it hit block one till it hit tip, the first is normal, the second is with all signature checks enabled.
119 2017-01-05 17:46:01	0|gmaxwell|so it took eight and a half minutes longer, or a 4% slowdown.
120 2017-01-05 18:17:35	0|sipa|gmaxwell: i made a graph of progress (according to my pr) vs time
121 2017-01-05 18:17:45	0|sipa|on my laptoo
122 2017-01-05 18:17:47	0|sipa|*laptoo
123 2017-01-05 18:17:50	0|sipa|*laptoP
124 2017-01-05 18:18:13	0|sipa|and it shows a very clear change in slope at 295000
125 2017-01-05 18:19:26	0|gmaxwell|I'm doing a par4 run, to get more figures, in case verification parallelism beyond 4 actually works now. :P
126 2017-01-05 18:19:53	0|gmaxwell|But there being a change in slope doesn't refute my figures. sync is very fast at 295k and the utxo set is small.
127 2017-01-05 18:20:09	0|gmaxwell|so it makes a difference there, sure.. but it's only a small part of the chain.
128 2017-01-05 18:47:18	0|morcos|gmaxwell: it works!  at least to 16
129 2017-01-05 18:47:59	0|morcos|and beyond with some minor'ish tweaks that might be overfitting to checkqueue
130 2017-01-05 18:50:41	0|BlueMatt|note: meeting in 10 minutes...obviously a major point of discussion will be the huge volume of outstanding things for 0.14
131 2017-01-05 18:50:48	0|gmaxwell|morcos: even without the checkqueue changes?
132 2017-01-05 18:51:00	0|BlueMatt|if y'all get the time prior to the meeting, please think a bit about what you want for 0.14, and what you dont think needs to make it
133 2017-01-05 18:51:08	0|gmaxwell|BlueMatt: you mean the huge volume of things that are going to miss 0.14? :(
134 2017-01-05 18:51:19	0|BlueMatt|gmaxwell: yea, probably :(
135 2017-01-05 18:51:28	0|morcos|yeah the cuckoocache was the immediate bottle neck, so with that, we've definitely got improvement , but from 8 -> 16 isn't that great
136 2017-01-05 18:51:38	0|BlueMatt|need to be able to prioritize review for what can make it in a week, and what wouldnt without an extra week :/
137 2017-01-05 18:51:56	0|gmaxwell|morcos: if it really was we could have gotten a similar speedup by bypassing the cache in IBD. :P oh well. :)
138 2017-01-05 18:53:49	0|morcos|gmaxwell: ah yes i guess i wasn't talking about IBD...   well i don't remember now what my IBD results were, but i'd be surprised if you couldn't go past 4 previously...  actually having to do the signtures makes the parrellism more valuable
139 2017-01-05 18:53:50	0|sipa|gmaxwell: rebase #9319 ?
140 2017-01-05 18:53:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9319 | Break addnode out from the outbound connection limits. by gmaxwell · Pull Request #9319 · bitcoin/bitcoin · GitHub
141 2017-01-05 18:54:11	0|BlueMatt|yea, super want that one for 0.14, and should be an easy target
142 2017-01-05 18:54:21	0|BlueMatt|already has some acks, too
143 2017-01-05 18:55:20	0|sipa|can i have a few more acks on #8610? i think the rewrite invalidated prior review
144 2017-01-05 18:55:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/8610 | Share unused mempool memory with coincache by sipa · Pull Request #8610 · bitcoin/bitcoin · GitHub
145 2017-01-05 18:56:07	0|gmaxwell|sipa: oh I didn't know one was needed there.
146 2017-01-05 18:56:10	0|morcos|sipa: you didn't specify what you changed the last time, i looked and it seemed just the lock inversion fix?
147 2017-01-05 18:56:24	0|sipa|morcos: yes, just that
148 2017-01-05 18:56:34	0|sipa|morcos: i mean compared to before implementing your approach
149 2017-01-05 18:56:35	0|gmaxwell|oh now I kinda wish I didn't load that PR...
150 2017-01-05 18:58:20	0|BlueMatt|sipa: done (I recalled that I had already reviewed half of it yesterday...)
151 2017-01-05 18:59:55	0|morcos|if you guys trust my rebases, just merge #9138 already...  please?  (next time in exchange for more willing reviewers of fee estimation, i will break into smaller PR's)
152 2017-01-05 18:59:56	0|sipa|BLING
153 2017-01-05 18:59:58	0|BlueMatt|meeting
154 2017-01-05 18:59:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/9138 | Improve fee estimation by morcos · Pull Request #9138 · bitcoin/bitcoin · GitHub
155 2017-01-05 19:00:14	0|sipa|morcos: i was waiting for acks
156 2017-01-05 19:00:17	0|lightningbot|Meeting started Thu Jan  5 19:00:15 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
157 2017-01-05 19:00:17	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
158 2017-01-05 19:00:17	0|wumpus|#startmeeting
159 2017-01-05 19:00:19	0|jl2012|may I propose a topic first? need to sleep
160 2017-01-05 19:00:23	0|petertodd|hi
161 2017-01-05 19:00:27	0|BlueMatt|jl2012: go
162 2017-01-05 19:00:41	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
163 2017-01-05 19:00:46	0|jonasschnelli|Hi
164 2017-01-05 19:00:51	0|jl2012|proposed topic: repair the fork warning system: https://github.com/bitcoin/bitcoin/pull/9443
165 2017-01-05 19:01:01	0|wumpus|#topic  repair the fork warning system
166 2017-01-05 19:01:11	0|sipa|concept ack on fixing it if it's broken!
167 2017-01-05 19:01:19	0|BlueMatt|concept ack 100%
168 2017-01-05 19:01:24	0|wumpus|haha yes concept ack. Haven't looked at the code yet.
169 2017-01-05 19:01:29	0|jl2012|but this is more than just fixing it
170 2017-01-05 19:01:29	0|sipa|i haven't had time to look at the details... 0.14 is getting close
171 2017-01-05 19:01:39	0|BlueMatt|but we've fucked that up several times already, so needs careful review, I think
172 2017-01-05 19:01:46	0|instagibbs_|here
173 2017-01-05 19:01:57	0|sipa|jl2012: elaborate?
174 2017-01-05 19:02:05	0|jl2012|it also stores invalid headers
175 2017-01-05 19:02:08	0|morcos|jl2012: are you trying to say you think it NEEDS to be in 0.14
176 2017-01-05 19:02:44	0|phantomcircuit|huh what
177 2017-01-05 19:02:45	0|jtimon|oh, meeting, wasn't planning on attending today, but really nothing to do until one hour from now...
178 2017-01-05 19:02:46	0|phantomcircuit|oh
179 2017-01-05 19:02:48	0|jl2012|specifically, it stores valid headers under an invalid block
180 2017-01-05 19:03:01	0|kanzure|hi.
181 2017-01-05 19:03:03	0|jl2012|also, headers with invalid nVersion are stored
182 2017-01-05 19:03:11	0|sipa|jl2012: but those do have valid PoW?
183 2017-01-05 19:03:15	0|jl2012|yes
184 2017-01-05 19:03:24	0|jl2012|and valid nTime
185 2017-01-05 19:03:24	0|sipa|iirc that is our only invariant for the storage of headers
186 2017-01-05 19:03:31	0|BlueMatt|jl2012: do we need to store them or can we just store them in memory?
187 2017-01-05 19:03:39	0|BlueMatt|but, I'm fine either way
188 2017-01-05 19:04:04	0|BlueMatt|looking at invalid headers with valid pow for user-warnings sounds good to me
189 2017-01-05 19:04:11	0|sipa|there may be some DoS avenues that open up due to it, if they get accepted for chains that fork off early on
190 2017-01-05 19:04:11	0|wumpus|stored headers are forever, both on disk and in memory, unfortunately
191 2017-01-05 19:04:15	0|luke-jr|jl2012: does this do anything to address that nodes sending us such chains will be DoS banned
192 2017-01-05 19:04:17	0|luke-jr|?
193 2017-01-05 19:04:30	0|jl2012|won't be banned
194 2017-01-05 19:04:35	0|sipa|(but i shouldn't comment on that before looking at code)
195 2017-01-05 19:04:40	0|gmaxwell|I feel pretty blah about the utlity of that warning system, and warnings in general. I think we've burned people out with false warnings, and they weren't used usefully by most to begin with. :(
196 2017-01-05 19:05:00	0|wumpus|the alternative to fixing it would be to just disable the system, at least for 0.14
197 2017-01-05 19:05:05	0|BlueMatt|gmaxwell: having reliable warning messages is the first step towards fixing that trust :)
198 2017-01-05 19:05:06	0|luke-jr|jl2012: so this removes the DoS banning for invalid blocks?
199 2017-01-05 19:05:22	0|jl2012|luke-jr: just for valid header
200 2017-01-05 19:05:33	0|wumpus|shipping it broken, especially with risk of false positives, indeed isn't going to do anything good
201 2017-01-05 19:05:42	0|jl2012|if the block content is invalid (e.g. invalid script), still banned
202 2017-01-05 19:06:02	0|gmaxwell|There is currently no false positive risk from it AFAIK.
203 2017-01-05 19:06:04	0|luke-jr|jl2012: which will lead to you not getting future headers
204 2017-01-05 19:06:09	0|petertodd|jl2012: to be clear, if the block is too large it will be banned as well?
205 2017-01-05 19:06:10	0|wumpus|having to store more data forever just to be able to warn seems a bit inefficient to me though
206 2017-01-05 19:06:29	0|jtimon|mhmm, the block is still invalid here, no? https://github.com/bitcoin/bitcoin/pull/9443/files#diff-24efdb00bfbe56b140fb006b562cc70bR3038
207 2017-01-05 19:06:30	0|wumpus|the block headers are never pruned, and all loaded into memory at start
208 2017-01-05 19:06:31	0|BlueMatt|petertodd: i dont think it changes anything wrt consensus code? the way I read it
209 2017-01-05 19:06:35	0|gmaxwell|petertodd: we can't even deseralize it if its too large so how would we even know if the contet were invalid.
210 2017-01-05 19:06:37	0|jl2012|petertodd: should be, I don't change that part
211 2017-01-05 19:06:39	0|BlueMatt|petertodd: /any/ consensus logic
212 2017-01-05 19:06:44	0|sipa|i wonder if we need a detection of internal consensus errors (database corruption, CPU overheating, ...)
213 2017-01-05 19:06:56	0|petertodd|gmaxwell: we can deserialize if it's only a little bit too large though IIRC
214 2017-01-05 19:06:59	0|sipa|because 99.999% of all fork warning that are seen in practice as just broken nodes
215 2017-01-05 19:07:05	0|gmaxwell|An invarient we have right now is that we depnd on banning to make sure all our connection slots are not consumed by peers that are on an incompatible blockchain.
216 2017-01-05 19:07:25	0|gmaxwell|sipa: I think we do.
217 2017-01-05 19:07:54	0|gmaxwell|sipa: which ultimately should be used to trigger recovery from chainstate backup automatically. (I think)
218 2017-01-05 19:07:57	0|sipa|but i don't know how without having a thread in the background that computes Pi or so :p
219 2017-01-05 19:08:17	0|morcos|jl2012: i'd like to understand the context of the discussion, is that about the change in general or whether it shoudl be in 0.14.   Is the current status of master somehow worse than 13.1/2?
220 2017-01-05 19:08:26	0|wumpus|detecting database corruption on disk is pretty easy as everything is CRC-ed, CPU overheating or memory corruption on the other hand...
221 2017-01-05 19:09:03	0|jl2012|morcos: I think that has broken for a few versions
222 2017-01-05 19:09:24	0|gmaxwell|Broken just means that it won't trigger in all cases it might trigger, right?
223 2017-01-05 19:09:24	0|wumpus|good to know, yes, if it's been broken for a few versions there's no hurry to fix it for 0.14
224 2017-01-05 19:09:27	0|jl2012|so you may consider it as a new feature
225 2017-01-05 19:09:35	0|jl2012|gmaxwell: yes
226 2017-01-05 19:09:37	0|sipa|well it can be considered for 0.14.1 or so
227 2017-01-05 19:09:45	0|sipa|if it's a bugfix (which i think it is)
228 2017-01-05 19:10:01	0|wumpus|I wonder if it can be done without storing more headers though
229 2017-01-05 19:10:03	0|luke-jr|but it doesn't sounds like this PR will actually fix it, and fixing it may be more complicated than it seems due to the point gmaxwell raised
230 2017-01-05 19:10:19	0|gmaxwell|My understanding is that there are cases where invalid blocks make us ignore later headers (normally a good thing) which will prevent them from triggering the warning.
231 2017-01-05 19:10:36	0|wumpus|I really don't like storing otherwise unnecessary data forever
232 2017-01-05 19:10:44	0|BlueMatt|wumpus: store only headers required to prove to yourself upon restart that you should display a warning, and prune the (separate) storage for that?
233 2017-01-05 19:10:51	0|sipa|we could prune old header chains
234 2017-01-05 19:10:55	0|sipa|(both from disk and memory)
235 2017-01-05 19:11:00	0|BlueMatt|or that
236 2017-01-05 19:11:05	0|BlueMatt|from memory....sounds hard
237 2017-01-05 19:11:09	0|wumpus|we could, sure, but right now we don't, so should be careful not to store more than necessary
238 2017-01-05 19:11:11	0|BlueMatt|on-disk/restart-only sounds doable
239 2017-01-05 19:11:15	0|jtimon|re: invariant for storage of headers: remind you that matt moved the nTime check from CheckBlockHeader() to ContextualCheckBlockHeader()
240 2017-01-05 19:11:16	0|petertodd|wumpus: provided theres a reasonable minimum PoW to storing it, it'll never be all *that* much extra data given it's just headers
241 2017-01-05 19:11:17	0|sipa|yeah, on restart it trivial
242 2017-01-05 19:11:26	0|wumpus|yes on startup would be good enough
243 2017-01-05 19:11:35	0|morcos|I think it would be wise to use our limited time to concentrate on things people think are really important for 0.14, it doesn't sound like anyone is making that argument about this change?
244 2017-01-05 19:11:49	0|sipa|agree
245 2017-01-05 19:11:51	0|jl2012|ok, please move on
246 2017-01-05 19:11:56	0|gmaxwell|I'd like improvements here, but I don't think it's 0.14 critical.
247 2017-01-05 19:12:02	0|wumpus|other proposed topics?
248 2017-01-05 19:12:11	0|BlueMatt|0.14 prs-to-review...
249 2017-01-05 19:12:15	0|luke-jr|morcos: this change is mostly useful to plan for a future hardfork, but I don't think it's critical it's in 0.14
250 2017-01-05 19:12:22	0|wumpus|BlueMatt: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
251 2017-01-05 19:12:37	0|BlueMatt|wumpus: many of those are almost certainly not gonna make it
252 2017-01-05 19:12:40	0|morcos|luke-jr: heh, ok, i'll put tha ton my hard-fork planning list, i have it handy right here
253 2017-01-05 19:12:57	0|wumpus|BlueMatt: that's a chicken-egg problem though as it depends on who reviews it
254 2017-01-05 19:13:01	0|BlueMatt|true
255 2017-01-05 19:13:14	0|sipa|so the topic here for the discussion should be what to prioritize for review
256 2017-01-05 19:13:17	0|wumpus|I agree, though
257 2017-01-05 19:13:30	0|BlueMatt|well if we're short for topics parallel processmessages...if folks think they will not have time to review it, then I'll skip it, but I have one based on cory's current net pr at https://github.com/theuni/bitcoin/compare/connman-locks...TheBlueMatt:2017-01-parallel-processmessages?expand=1
258 2017-01-05 19:13:33	0|cfields|agree with sipa
259 2017-01-05 19:13:48	0|BlueMatt|and think it would be a huge improvement for some use-cases
260 2017-01-05 19:13:51	0|wumpus|I just meant that the lis is already very long, so let's at least try not to add much more
261 2017-01-05 19:13:55	0|sipa|so open question: what would people like to see in 0.14, if review effort wasn't a bottleneck
262 2017-01-05 19:14:03	0|wumpus|named arguments
263 2017-01-05 19:14:05	0|BlueMatt|or, what is the priority
264 2017-01-05 19:14:05	0|gmaxwell|I really feel uncomfortable with last minute concurrency changes.
265 2017-01-05 19:14:07	0|jtimon|proposed topic: custom blockchains for 0.14 (ie how realistic it is to hope to get https://github.com/bitcoin/bitcoin/pull/8994 merged for 0.14 ? )
266 2017-01-05 19:14:14	0|luke-jr|there was some desire for #8775 #8694 #7533 in 0.14, but they're not tagged as such
267 2017-01-05 19:14:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
268 2017-01-05 19:14:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
269 2017-01-05 19:14:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
270 2017-01-05 19:14:22	0|jtimon|custom chainparams really
271 2017-01-05 19:14:24	0|BlueMatt|gmaxwell: it tries very hard to limit concurrency changes - its whitelisted on messages, plus other things
272 2017-01-05 19:14:40	0|wumpus|gmaxwell: same
273 2017-01-05 19:14:56	0|morcos|i'd like to see the improvements to block relay #9375, #9441, #9447 and possibly parallel ProcessMessages
274 2017-01-05 19:14:57	0|BlueMatt|gmaxwell: no open prs of mine make any significant concurrency changes
275 2017-01-05 19:14:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
276 2017-01-05 19:15:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
277 2017-01-05 19:15:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9447 | Allow 2 simultaneous block downloads by morcos · Pull Request #9447 · bitcoin/bitcoin · GitHub
278 2017-01-05 19:15:10	0|BlueMatt|gmaxwell: or at least they try hard not to
279 2017-01-05 19:15:15	0|BlueMatt|s/not//
280 2017-01-05 19:15:20	0|cfields|wumpus: +1 for named arguments. Will re-review.
281 2017-01-05 19:15:32	0|gmaxwell|BlueMatt: we really have inadequate testing there, as cfield's version assert has shown us.
282 2017-01-05 19:15:36	0|morcos|+1 on named arguments as well... will amke future PR's easier/better
283 2017-01-05 19:15:50	0|BlueMatt|gmaxwell: helgrind works well, it turns out :), but, agreed
284 2017-01-05 19:16:05	0|gmaxwell|BlueMatt: only if you actually execute the codepaths.
285 2017-01-05 19:16:16	0|BlueMatt|sure
286 2017-01-05 19:16:31	0|gmaxwell|Where are we with the multiwallet support?
287 2017-01-05 19:16:36	0|cfields|BlueMatt: maybe you could briefly describe what you're hoping to immediately improve?
288 2017-01-05 19:16:47	0|instagibbs_|gmaxwell: there's one refactor outsanding I believe
289 2017-01-05 19:17:01	0|luke-jr|gmaxwell: 3 PRs left, 9375 and 9441
290 2017-01-05 19:17:16	0|sipa|9441? sure?
291 2017-01-05 19:17:23	0|luke-jr|err
292 2017-01-05 19:17:24	0|instagibbs_|8775
293 2017-01-05 19:17:27	0|luke-jr|8775 8694*
294 2017-01-05 19:17:36	0|gmaxwell|I had been hoping for that and the utxo scriptpubkey index (#8660) in 0.14, but it looks like the latter has been abandoned by its requester.
295 2017-01-05 19:17:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub
296 2017-01-05 19:18:03	0|wumpus|gmaxwell: yes, that's unfortunate
297 2017-01-05 19:18:40	0|sipa|i'd like to see #9441 in to get the performance benefit
298 2017-01-05 19:18:41	0|BlueMatt|cfields: specifically, because many miners rely on bitcoind submitblock -> p2p network latency to relay their blocks out, this ends up being pretty important for miners in several ways, so speeding up the relay (hopefully without introducing a ton of new concurrency outside of cmpctblock/getblocktxn/blocktxn message processing) would be a massive win for many miners
299 2017-01-05 19:18:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
300 2017-01-05 19:18:45	0|jtimon|for efficiency, maybe https://github.com/bitcoin/bitcoin/pull/8498 helps, but nobody has found the time to benchmark that in years...
301 2017-01-05 19:19:03	0|BlueMatt|yes, so multiwallet and at least the currently-open net prs are review focus
302 2017-01-05 19:19:04	0|gmaxwell|wumpus: I think it's suffered less attention than it would have recieved because it's poorly labled and people keep thinking its a blockchain index.
303 2017-01-05 19:19:21	0|morcos|ok well if i had to pick one, i think 9375 makes a huge difference
304 2017-01-05 19:19:44	0|wumpus|gmaxwell: looks like droark might pick it up
305 2017-01-05 19:20:05	0|gmaxwell|BlueMatt: well I had a PR that removed the biggest source of submitblock latency-- it's a couple lines changes,  I assume its functionality has been duplicated in one of cfields overlapping PRs that I closed that one in favor of.
306 2017-01-05 19:20:24	0|morcos|if nothing else the caching of the block/cmpctblock that you are about to send to all your peers reduces the time per per from 25ms to <1ms
307 2017-01-05 19:20:59	0|BlueMatt|gmaxwell: yes, its in the "Net: Massive speedup" one, but the validation time cost (which the parallel getblocktxn/processmessages stuff + the fast relay stuff fixes)
308 2017-01-05 19:21:25	0|BlueMatt|gmaxwell: for current-tip you really want both, but the net stuff you're referring to isnt the only thing here
309 2017-01-05 19:21:26	0|gmaxwell|I am going to be irritated if 9441 misses 0.14.  I had an alternative PR that resulted in the same speedup which I think was much less invasive, but I closed it because cfields prefered the other change because it serviced his overall refactor planning.
310 2017-01-05 19:22:03	0|BlueMatt|I think that one is pretty far along, its gotten a lot of eyes even if not so much acks
311 2017-01-05 19:22:44	0|BlueMatt|<BlueMatt> yes, so multiwallet and at least the currently-open net prs are review focus <-- any other things to add to that list
312 2017-01-05 19:22:45	0|BlueMatt|?
313 2017-01-05 19:22:55	0|wumpus|gmaxwell: let's focus on making that one get in then (I do think there's some regression risk, as it's a pretty invasive change to do last minute)
314 2017-01-05 19:23:01	0|sipa|i'll focus on the net locks overhault, named args, early compact block relay
315 2017-01-05 19:23:03	0|morcos|gmaxwell: so 9441 doesn't count as concurrency changes you are worried about merging now
316 2017-01-05 19:23:13	0|gmaxwell|wumpus: that was my feeling too but yea.
317 2017-01-05 19:23:20	0|morcos|+1 sipa's list
318 2017-01-05 19:23:29	0|gmaxwell|morcos: right, I think it's invasive but it shouldn't be meaningfully creating new concurrency.
319 2017-01-05 19:23:42	0|wumpus|sgtm
320 2017-01-05 19:23:45	0|wumpus|#action focus on the net locks overhault, named args, early compact block relay
321 2017-01-05 19:23:47	0|BlueMatt|sip, ok, named args it is, also multi-wallet?
322 2017-01-05 19:24:12	0|BlueMatt|a
323 2017-01-05 19:24:12	0|gmaxwell|The caching improvements as part of early compact block are nice. One option is if we feel uncomfortable about early compact blocks is that we disable that part and just take the caching.
324 2017-01-05 19:24:13	0|BlueMatt|sipa
325 2017-01-05 19:24:17	0|instagibbs_|luke-jr: might make sense to split out QT stuff for time
326 2017-01-05 19:24:30	0|luke-jr|instagibbs_: planning to do so, once 8775 is merged
327 2017-01-05 19:24:34	0|wumpus|multi-wallet may be still too many PRs away for 0.14 , dunno how realistic it is to get that in, though we certainly can make progress with the refactors
328 2017-01-05 19:24:36	0|jtimon|which pr is named args?
329 2017-01-05 19:24:50	0|sipa|jtimon: #8811
330 2017-01-05 19:24:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/8811 | rpc: Add support for JSON-RPC named arguments by laanwj · Pull Request #8811 · bitcoin/bitcoin · GitHub
331 2017-01-05 19:24:52	0|morcos|Obviously I think 9138 (improve fee estimation) needs to be merged, but i think its ACK'ed enough (excpet it had some rebases)
332 2017-01-05 19:24:56	0|BlueMatt|gmaxwell: the fast-relay stuff there has been /super/ scaled back...at this point its only a) if its the first thing you're annoucing at that height, and b) if its built directly on your tip
333 2017-01-05 19:25:02	0|BlueMatt|gmaxwell: so hopefully its easier to be comfortable with it
334 2017-01-05 19:25:03	0|gmaxwell|On the remaining multiwallet, I felt one of the outstanding refactor PRs introduced a fair amount of not very C++ish code, but who am I to judge? and I didn't know what to recommend instead, so I asked sipa to look at it but I doubt he's had a chance yet.
335 2017-01-05 19:25:10	0|luke-jr|instagibbs_: although Qt stuff ties in with RPC stuff for the debug window
336 2017-01-05 19:25:12	0|wumpus|morcos: if something is ready for merge you should let me know :)
337 2017-01-05 19:25:35	0|morcos|well at this point, my judgement isn't to be trusted.. :)
338 2017-01-05 19:25:54	0|gmaxwell|BlueMatt: remaining concerns are things like "are we going to accidentally DOS attack our peers by announcing something and then reorging" and things like that.
339 2017-01-05 19:26:09	0|jonasschnelli|Multiwallet: I think need to rebase this one: #8764
340 2017-01-05 19:26:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/8764 | [Wallet] get rid of pwalletMain, add simple CWallets infrastructure by jonasschnelli · Pull Request #8764 · bitcoin/bitcoin · GitHub
341 2017-01-05 19:26:14	0|BlueMatt|gmaxwell: yes, hence scaling it back...been discussing it a bunch with folks in the past few days
342 2017-01-05 19:26:29	0|luke-jr|jonasschnelli: that kinda conflicts with the current multiwallet stuff
343 2017-01-05 19:26:31	0|jonasschnelli|Maybe https://github.com/bitcoin/bitcoin/projects/2 needs update
344 2017-01-05 19:27:11	0|jtimon|maybe https://github.com/bitcoin/bitcoin/projects/6 needs to be...closed?
345 2017-01-05 19:27:33	0|luke-jr|might be more efficient to do 8764 after the basic parts are in
346 2017-01-05 19:28:53	0|gmaxwell|For 0.14 I really want to see the second pass through createtransaction change from morcos in... fixes some concerning fee overpayment corner case.
347 2017-01-05 19:29:03	0|gmaxwell|I don't know why #9312 isn't merged yet.
348 2017-01-05 19:29:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/9312 | Increase mempool expiry time to 2 weeks by morcos · Pull Request #9312 · bitcoin/bitcoin · GitHub
349 2017-01-05 19:29:23	0|morcos|#9404 is super easy now, although needs rebase after #9465 is merged
350 2017-01-05 19:29:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
351 2017-01-05 19:29:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9465 | [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. by gmaxwell · Pull Request #9465 · bitcoin/bitcoin · GitHub
352 2017-01-05 19:29:47	0|sipa|i read a few things about accidental extreme fee
353 2017-01-05 19:30:34	0|jtimon|maybe related to estimate fee for the very next block now disabled? (no idea, just thinking out loud)
354 2017-01-05 19:30:41	0|sipa|is that related to 9138 ?
355 2017-01-05 19:30:42	0|wumpus|gmaxwell: same holds for you, if something is ready for merging you should let me know
356 2017-01-05 19:30:50	0|sipa|or 9404?
357 2017-01-05 19:31:02	0|gmaxwell|#9404 though I really want it in, I haven't actually reviewed the code becuase I know it'll be simpler after 9465. (the story there is a user reported an issue that might be that fee bug, I went go fix it, realized it would be easier to fix after factoring out the signing.. did that.. then realized your preexisting patch was already the fix I wanted. :P )
358 2017-01-05 19:31:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
359 2017-01-05 19:31:14	0|wumpus|9312 clearly is
360 2017-01-05 19:31:23	0|morcos|sipa: both, well disabling fee estimates for 1 already went in, not part of 9138
361 2017-01-05 19:31:25	0|luke-jr|jtimon: https://www.reddit.com/r/Bitcoin/comments/5ltw5n/bitcoin_core_v0131_sends_enormously_high_fee/
362 2017-01-05 19:31:36	0|luke-jr|perhaps ^ should be our next topic
363 2017-01-05 19:31:37	0|morcos|but both could cause high fees
364 2017-01-05 19:31:38	0|wumpus|I think I stopped paying attention there when a certain person started trolling then lost track of it.
365 2017-01-05 19:31:40	0|sipa|can someone explain what causes this?
366 2017-01-05 19:31:48	0|sipa|(i don't visit reddit)
367 2017-01-05 19:31:51	0|morcos|yes
368 2017-01-05 19:31:56	0|BlueMatt|^ that
369 2017-01-05 19:32:01	0|kanzure|luke-jr: see 9404, i think
370 2017-01-05 19:32:06	0|gmaxwell|luke-jr: I believe its fixed by 9404.  Of course, I can't know for sure, not enough info.
371 2017-01-05 19:32:41	0|instagibbs_|gmaxwell: so it's wallet-related code, not estimation
372 2017-01-05 19:32:41	0|sipa|oh, is it change unnecessarily converted to fee?
373 2017-01-05 19:32:42	0|morcos|the 9404 case is caused when you select coins to pay for a tx, calculate fee and realize you dont' have enough, so you have to go and reselect coins.  you end up selecting many fewer for whatever reason, and now you have enough fee of course, and you end up paying the fee you calculated for the prior iteration
374 2017-01-05 19:32:47	0|luke-jr|gmaxwell: well, OP's post there said he's using estimatefee :/
375 2017-01-05 19:32:59	0|morcos|gmaxwell: 9404 is already rebased on 9465 as of this morning, so easy peasy to review now
376 2017-01-05 19:33:00	0|gmaxwell|But the user seemed to be reporting that it payed several times the fee estimator figures (at least thats my read on it), which supports 9404 over 9138  though 9138 needs to go in too.
377 2017-01-05 19:33:08	0|gmaxwell|morcos: oh missed that, will review.
378 2017-01-05 19:33:24	0|jonasschnelli|#9294 should also go into 0.14 (needs overhaul, my turn) and some form of a HD rescan would be great.
379 2017-01-05 19:33:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
380 2017-01-05 19:33:42	0|bitcoin-git|13bitcoin/06master 145f0e27f 15Alex Morcos: Increase mempool expiry time to 2 weeks
381 2017-01-05 19:33:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ce43630d1e97...a72f76ca3d5d
382 2017-01-05 19:33:43	0|bitcoin-git|13bitcoin/06master 14a72f76c 15Wladimir J. van der Laan: Merge #9312: Increase mempool expiry time to 2 weeks...
383 2017-01-05 19:33:44	0|luke-jr|gmaxwell: he sent you the debug log, did that indicate anything useful?
384 2017-01-05 19:33:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9312: Increase mempool expiry time to 2 weeks (06master...06longerexpiry) 02https://github.com/bitcoin/bitcoin/pull/9312
385 2017-01-05 19:34:08	0|gmaxwell|jonasschnelli:  do we still have nothing that removes key from the keypool when they show up in transactions out of order, so that a rescan while unlocked would successfully find everything?
386 2017-01-05 19:34:21	0|gmaxwell|luke-jr: no. unfortunately.
387 2017-01-05 19:34:45	0|gmaxwell|well it didn't suggest that the known ways that estimatefee could be high weren't being hit.
388 2017-01-05 19:34:46	0|jonasschnelli|gmaxwell: we don't. But I'm working on it. Got distracted with SPV/BFD and 2016 visualisation.
389 2017-01-05 19:35:12	0|gmaxwell|jonasschnelli: okay, I'll do it if you don't have time; I just figured you are much more recently familar with that code than I. Sorry to nag.
390 2017-01-05 19:35:13	0|morcos|sipa: its also possible that fee estimation could temporarily be very high..  was MUCH more likely for estimatefee 1 though, which has already been disabled
391 2017-01-05 19:35:24	0|sipa|morcos: ok
392 2017-01-05 19:35:30	0|jonasschnelli|gmaxwell: I'm happy if you do it.
393 2017-01-05 19:35:31	0|sipa|let's get those fixes in
394 2017-01-05 19:36:11	0|jonasschnelli|gmaxwell: maybe use some prework form https://github.com/bitcoin/bitcoin/pull/9370
395 2017-01-05 19:36:16	0|gmaxwell|TBH I knew about the issue fied by 9404 long ago, but I thought it had since been fixed... :(
396 2017-01-05 19:37:16	0|gmaxwell|jonasschnelli: oh I thought I'd acked the fundraw reuse fix.. will review.
397 2017-01-05 19:37:37	0|jonasschnelli|The correct one is: https://github.com/bitcoin/bitcoin/pull/9377
398 2017-01-05 19:38:07	0|jonasschnelli|The one above is an older try that could be useful for hd restore.
399 2017-01-05 19:38:43	0|jonasschnelli|Fun topic: 2016 Git Visualisation: I'd created a draft video, need feedback to overhaul it and place it on the bitcoincore.org website.
400 2017-01-05 19:38:49	0|jonasschnelli|https://vimeo.com/198242328
401 2017-01-05 19:38:52	0|jonasschnelli|Password coredev
402 2017-01-05 19:38:58	0|jonasschnelli|(will be there for a couple of mins)
403 2017-01-05 19:39:16	0|jonasschnelli|(sorry to spam the meeting)
404 2017-01-05 19:39:29	0|gmaxwell|okay I concept acked, well I'll complete the review.
405 2017-01-05 19:40:05	0|luke-jr|jonasschnelli: why password protect it and post the password in public? :P
406 2017-01-05 19:40:17	0|jonasschnelli|Security by obscurity.
407 2017-01-05 19:40:20	0|petertodd|luke-jr: MILITARY LEVEL BLOCKCHAIN SECURITY
408 2017-01-05 19:40:26	0|jonasschnelli|heh
409 2017-01-05 19:40:43	0|wumpus|hehe
410 2017-01-05 19:41:07	0|petertodd|anyway, I think that constitutes an "effective access control" under the DMCA...
411 2017-01-05 19:41:24	0|gmaxwell|Who called this meeting?
412 2017-01-05 19:41:29	0|sipa|jonasschnelli: short comment: overuse of capitalization (why are Day and Commit capitalized) and dashes (Code-contributors should be written with a space in between)
413 2017-01-05 19:41:48	0|jonasschnelli|sipa: Thanks, will adapt
414 2017-01-05 19:41:59	0|instagibbs_|any other topics?
415 2017-01-05 19:42:51	0|wumpus|apparently not!
416 2017-01-05 19:42:59	0|instagibbs_|everyone's watching the video
417 2017-01-05 19:43:10	0|kanzure|chainparams?
418 2017-01-05 19:43:22	0|wumpus|looks like we'll close the first meeting of 2017 early
419 2017-01-05 19:43:31	0|kanzure|8994
420 2017-01-05 19:43:31	0|wumpus|what is there to discuss about chainparams?
421 2017-01-05 19:43:47	0|kanzure|for 0.14, i think.
422 2017-01-05 19:43:55	0|BlueMatt|final list of things to focus for review? multi-wallet, currently-open net prs, fee ones, what else?
423 2017-01-05 19:44:08	0|BlueMatt|oh, and multiargs
424 2017-01-05 19:44:16	0|BlueMatt|rpcarg thing
425 2017-01-05 19:44:19	0|jonasschnelli|and hd chain-split/rstore
426 2017-01-05 19:44:24	0|jtimon|wumpus, on my part #8994
427 2017-01-05 19:44:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
428 2017-01-05 19:44:40	0|gmaxwell|I think that is really a lot less important than everything else listed.
429 2017-01-05 19:44:59	0|gmaxwell|(as people using that are also probably using git master)
430 2017-01-05 19:45:00	0|morcos|are we really trying to get all these wallet changes in?
431 2017-01-05 19:45:05	0|jtimon|sure, feedback is still welcomed though
432 2017-01-05 19:45:05	0|wumpus|yes it doesn't seem to make a lot of sense to focus last-minute review attention on that
433 2017-01-05 19:45:10	0|morcos|should we focus on some over others?
434 2017-01-05 19:45:12	0|BlueMatt|morcos: yea, I think thats more than will make it, but that was the list
435 2017-01-05 19:45:13	0|gmaxwell|(so merging it after 14 means just weeks of delay for someone who wants to use it)
436 2017-01-05 19:45:22	0|gmaxwell|jtimon: fair enough.
437 2017-01-05 19:45:25	0|wumpus|morcos: the fee fixes obviously have priority
438 2017-01-05 19:45:45	0|jtimon|I doubt it will get to 0.14 that's why I asked "how realistic..."
439 2017-01-05 19:45:47	0|wumpus|anything that can cause users to spend unnecessary coins should be first priority
440 2017-01-05 19:45:54	0|morcos|well i guess i meant between hd-chain/split and multiwallet
441 2017-01-05 19:46:00	0|BlueMatt|i think maybe multi-wallet is less likely so maybe less priority, but maybe others disagree since that would be a super nice user-facing feature
442 2017-01-05 19:46:09	0|instagibbs_|I think multiwallet would be great... lots of demand for something like that
443 2017-01-05 19:46:16	0|gmaxwell|I would prioritize fee fixes, net/relay things, hd/rescan improvements, multiwallet, the thousand other open PRs.
444 2017-01-05 19:46:19	0|instagibbs_|but yes bigger changes
445 2017-01-05 19:46:28	0|morcos|gmaxwell: in order?
446 2017-01-05 19:46:36	0|gmaxwell|There is a lot of demand for multiwallet and I feel like if we don't get it done it'll continue to slip.
447 2017-01-05 19:46:36	0|morcos|don't forget named args?
448 2017-01-05 19:46:40	0|gmaxwell|morcos: yes that was an order.
449 2017-01-05 19:46:40	0|instagibbs_|>thousand other open PRs
450 2017-01-05 19:46:52	0|jonasschnelli|gmaxwell: Would multiwallet in 0.14 include the GUI?
451 2017-01-05 19:47:09	0|wumpus|I think 0.14 multiwallet is too late - better to merge it as first thing for 0.15, then improve it in master
452 2017-01-05 19:47:10	0|jonasschnelli|Have we already discussed how to select the wallet over RPC?
453 2017-01-05 19:47:10	0|luke-jr|multiwallet is in Knots already, so may be less important in that sense (since users who want it can get it); stuff like HD split can't really go in Knots without being more final
454 2017-01-05 19:47:15	0|wumpus|it will need a lot of last-minute fixes Im sure
455 2017-01-05 19:47:28	0|luke-jr|jonasschnelli: a number of times :p
456 2017-01-05 19:47:32	0|wumpus|a big feature like that is not done once it's merged
457 2017-01-05 19:47:55	0|luke-jr|wumpus: it's not actually that big at this point
458 2017-01-05 19:48:16	0|gmaxwell|At least on my earlier review it seemed like most of it was the refactors.
459 2017-01-05 19:48:19	0|gmaxwell|Which helps.
460 2017-01-05 19:48:21	0|luke-jr|99% of it is renaming pwalletMain to pwallet in rpc files
461 2017-01-05 19:48:38	0|jonasschnelli|But we need to be careful. Running with many wallets needs some testing.
462 2017-01-05 19:48:43	0|morcos|sorry i'm not trying to be a downer, but both 9375 (fast compact block relay) and 9441 (net speedup) are big heavy review changes, so we shouldn't spread ourselves too thin if we realyl want those in
463 2017-01-05 19:48:44	0|wumpus|in any case there are plenty of PRs to focus on, as said before they can't make it all in
464 2017-01-05 19:48:46	0|jonasschnelli|Even if it's code-wise trivial
465 2017-01-05 19:49:18	0|luke-jr|overall, I think multiwallet can be delayed in Core if other things need time
466 2017-01-05 19:49:23	0|wumpus|if we can't make any choices to postpone things, either 0.13 will slip incredibly (I'd hate that) or we'll have to randomly drop things last minute
467 2017-01-05 19:49:33	0|wumpus|agree with morcos
468 2017-01-05 19:49:40	0|sipa|0.13 slipping now would indeed be terrible!
469 2017-01-05 19:49:46	0|luke-jr|heh
470 2017-01-05 19:49:49	0|sipa|;)
471 2017-01-05 19:49:51	0|gmaxwell|hah
472 2017-01-05 19:50:24	0|wumpus|lol
473 2017-01-05 19:50:48	0|gmaxwell|wumpus: if we slip it we slip it, but if people are active on review and testing I think we don't need to.  I really wish the net changes were less invasive but thats water under the bridge now.
474 2017-01-05 19:51:09	0|gmaxwell|I do believe the release will be delayed from fixes for just the things we already have in now.
475 2017-01-05 19:51:18	0|luke-jr|am I likely to be of any help reviewing the net stuff if I'm not up to speed on the net refactoring so far?
476 2017-01-05 19:51:22	0|wumpus|gmaxwell: I don't want to let it slip on features in any case, on bugfixes is more acceptable
477 2017-01-05 19:51:29	0|BlueMatt|note: we have at least 4 regressions in master which are 0.14-blocking which do not yet have prs open to fix them
478 2017-01-05 19:51:31	0|wumpus|so it's clear what to focus on then
479 2017-01-05 19:51:32	0|BlueMatt|so....thats a thing
480 2017-01-05 19:51:44	0|gmaxwell|wumpus: right, well ... you could just merge everything outstanding and then all slips are bugfix related! :P
481 2017-01-05 19:51:48	0|instagibbs_|BlueMatt: there a list?
482 2017-01-05 19:51:49	0|BlueMatt|oh, sorry, 1 has an open pr
483 2017-01-05 19:52:03	0|wumpus|BlueMatt: are the issues tagged appropriately?
484 2017-01-05 19:52:10	0|BlueMatt|yes, tagged 0.14, i believe
485 2017-01-05 19:52:14	0|wumpus|ok
486 2017-01-05 19:52:29	0|gmaxwell|AFAIK we are not actually waiting on the competion of any feature changes. (except perhaps some rescan improvements).. E.g. almost everything I think we might have in 0.14 has a PR already open.
487 2017-01-05 19:52:34	0|cfields|to reviewers, don't let the amount of commits in 9441 scare you. Almost all of them are very tiny, explicitly to make review easier
488 2017-01-05 19:52:48	0|BlueMatt|at least #9479, #9027, #9148 and #9212
489 2017-01-05 19:52:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9479 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
490 2017-01-05 19:52:50	0|BlueMatt|maybe others
491 2017-01-05 19:52:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub
492 2017-01-05 19:52:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
493 2017-01-05 19:52:51	0|sipa|confirming what cfields said
494 2017-01-05 19:52:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
495 2017-01-05 19:52:52	0|morcos|oh shit, yeah sorry, one is mine..  , lets quickly decide which direction we want to take on that.  Do we revert #9240 or do we not care about the notifications?  I think #9371 is too late for 0.14
496 2017-01-05 19:52:54	0|gmaxwell|completion*
497 2017-01-05 19:52:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
498 2017-01-05 19:52:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
499 2017-01-05 19:53:28	0|sipa|morcos: if 9371 is too late, we need to revert 9240... but maybe that is not something we need to know now?
500 2017-01-05 19:53:33	0|sipa|a revert can be do at the last minute
501 2017-01-05 19:53:41	0|sipa|*done
502 2017-01-05 19:53:44	0|BlueMatt|yea, we can revert on the 0.14 branch at that point?
503 2017-01-05 19:53:44	0|morcos|If we're reverting #9240, it'll conflict, definitely with 9138 and probably already, so let me know and I'll make a revert PR
504 2017-01-05 19:53:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9240 | Remove txConflicted by morcos · Pull Request #9240 · bitcoin/bitcoin · GitHub
505 2017-01-05 19:54:37	0|sipa|jtimon: 9472 removes checkpoints for the purpose of progress estimation
506 2017-01-05 19:54:41	0|morcos|sipa: well i like 9371, but it overlaps a lot with #8549 and we haven't resolved direction
507 2017-01-05 19:54:41	0|sipa|:)
508 2017-01-05 19:54:42	0|jtimon|I mean gmaxwell you had that practically done already
509 2017-01-05 19:54:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/8549 | zmq: mempool notifications by jmcorgan · Pull Request #8549 · bitcoin/bitcoin · GitHub
510 2017-01-05 19:54:53	0|jtimon|sipa: oh, nice, will have a look
511 2017-01-05 19:55:30	0|gmaxwell|jtimon: not going to have one either, not any time soon (1) it requires a consensus change; and I don't have the appetite to carry forward in the adversarial climate of the mailing list (which I am not on for a long time now), and (2)  Sipa disagrees with my one strategy for removing the signature checking dependency, and petertodd disagrees with the other.
512 2017-01-05 19:55:38	0|wumpus|Madars: what I don't like about 9371 is that is that it keeps the list of removed transactions on mempool, instead of an external object listening for signals
513 2017-01-05 19:55:46	0|wumpus|sorry s/Madars/Morcos
514 2017-01-05 19:56:03	0|wumpus|morcos: this means it can only support one client listening for removals at most
515 2017-01-05 19:56:10	0|gmaxwell|(sipa disagrees that we can just check all signatures; petertodd disagrees with the proposal that we use burried by 30 days of work+other conditions)
516 2017-01-05 19:56:20	0|jtimon|gmaxwell: mhmm, I didn't remember a consensus change, must be missing something, but sure, if it needs it, definitely no time to do it for 0.14
517 2017-01-05 19:56:40	0|wumpus|morcos: for the rest I'm ok with it, and it doesn't conflict with 8549 too much
518 2017-01-05 19:56:59	0|sipa|gmaxwell: what about the idea of once crossing a certain amount of work, requiring a higher minimum difficulty?
519 2017-01-05 19:57:10	0|gmaxwell|jtimon: the part of it that didn't either need a consensus change (uppping the minimum difficulty) and didn't change the signature checking,  has already been merged.
520 2017-01-05 19:57:18	0|morcos|wumpus: i was trying to keep notifications from happening while we were locked in reorg..   couldn't we later make it so the mempoolremovaltracker could interface with multiple clients or something
521 2017-01-05 19:57:23	0|sipa|ah, right, consensus change
522 2017-01-05 19:57:32	0|gmaxwell|sipa: it's a consensus change, and I implemented it, and asked for review which jtimon gave some, but... consensus change.
523 2017-01-05 19:57:54	0|wumpus|morcos: I just don't like making a notification mechanism stateful, but that may be a personal thing
524 2017-01-05 19:58:17	0|jtimon|thanks for the info, wasn't up to date on the subject
525 2017-01-05 19:58:18	0|wumpus|morcos: but ok maybe this is the only way to handle reorgs sanely
526 2017-01-05 19:58:20	0|gmaxwell|but I really have no interest in writing a bit and getting treated like shit by zander and voskull or whatever other trolls inhabit the list today.
527 2017-01-05 19:58:22	0|morcos|but isn't that what we've just done on purpose with ConnectTrace?
528 2017-01-05 19:58:40	0|morcos|i guess not quite the same thing... but accomplishes same goal
529 2017-01-05 19:58:46	0|jtimon|maybe in this 2 minutes...should I rebase the super-trivial #9279 ?
530 2017-01-05 19:58:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
531 2017-01-05 19:59:10	0|wumpus|morcos: well at least that's an external object passed in
532 2017-01-05 19:59:34	0|sipa|gmaxwell: maybe you should explain your idea to luke-jr
533 2017-01-05 19:59:56	0|morcos|i know... but so many layers..  anyway, ok we'll see what happens..  i'll make the revert later if i need to
534 2017-01-05 20:00:05	0|gmaxwell|sipa: https://github.com/gmaxwell/bitcoin/commit/2db190b183c5204da23191ca642c7f6cad412ae3
535 2017-01-05 20:00:08	0|instagibbs_|time of meeting has ended
536 2017-01-05 20:00:12	0|wumpus|#endmeeting
537 2017-01-05 20:00:13	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.log.html
538 2017-01-05 20:00:13	0|lightningbot|Meeting ended Thu Jan  5 20:00:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
539 2017-01-05 20:00:13	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.html
540 2017-01-05 20:00:13	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-01-05-19.00.txt
541 2017-01-05 20:00:33	0|bitcoin-git|13bitcoin/06master 1454f8026 15Jonas Schnelli: [CoinControl] Allow non-wallet owned change addresses
542 2017-01-05 20:00:33	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a72f76ca3d5d...fd7d8c7b35ae
543 2017-01-05 20:00:34	0|bitcoin-git|13bitcoin/06master 14fd7d8c7 15Jonas Schnelli: Merge #9413: [CoinControl] Allow non-wallet owned change addresses...
544 2017-01-05 20:00:36	0|jtimon|#9279 would make libconsensus lighter :p
545 2017-01-05 20:00:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
546 2017-01-05 20:00:48	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9413: [CoinControl] Allow non-wallet owned change addresses (06master...062016/12/qt_cc_change) 02https://github.com/bitcoin/bitcoin/pull/9413
547 2017-01-05 20:01:13	0|gmaxwell|sipa: presumably that explains the idea precisely enough. :)
548 2017-01-05 20:01:16	0|wumpus|morcos: I guess your mechanism could be extended to multiple clients if the start/stop timespans for storing mempool removals are not determined by the client
549 2017-01-05 20:01:27	0|wumpus|morcos: then the whole list of removed transactions could be passed to all listeners
550 2017-01-05 20:01:45	0|morcos|yes i think thats what i meant
551 2017-01-05 20:01:48	0|wumpus|morcos: and it's listener-agnostic without calling a signal for every transaction
552 2017-01-05 20:02:07	0|jtimon|what about fetching the minimum difficulty from the 6 biggest mining pools?
553 2017-01-05 20:02:30	0|gmaxwell|/kb jtimon
554 2017-01-05 20:02:33	0|wumpus|morcos: not sure what the batching granularity should be in that case though
555 2017-01-05 20:02:42	0|petertodd|jtimon: so long as we have a service that defines which those 6 pools are
556 2017-01-05 20:02:43	0|wumpus|morcos: per block, per reorg?
557 2017-01-05 20:02:57	0|jtimon|kb ?
558 2017-01-05 20:03:01	0|BlueMatt|jtimon: lol
559 2017-01-05 20:03:01	0|kanzure|kickban
560 2017-01-05 20:03:02	0|jonasschnelli|jtimon: heh. Read this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013432.html
561 2017-01-05 20:03:13	0|luke-jr|gmaxwell: sounds reasonable
562 2017-01-05 20:03:14	0|morcos|wumpus: well i batched it per lock of cs_main i think
563 2017-01-05 20:03:27	0|BlueMatt|jonasschnelli: lol, I hope that was a joke too
564 2017-01-05 20:03:47	0|morcos|which basically is ActivateBestChain(or Step can't remember) and per AcceptToMemoryPool
565 2017-01-05 20:04:02	0|jtimon|jonasschnelli: right, sorry, should have said 5, didn't remember correctly :p
566 2017-01-05 20:04:08	0|jonasschnelli|haha
567 2017-01-05 20:04:33	0|gmaxwell|luke-jr: A bip for it would probably want to specify how the timestamps must be distorted if difficulty gets down to the limit x 4.
568 2017-01-05 20:04:47	0|gmaxwell|luke-jr: which I've not bothered thinking through.
569 2017-01-05 20:05:37	0|luke-jr|gmaxwell: I'd be inclined to suggest if we ever got to that point, a PoW change may be necessary just to avoid attacks from the ex-miners?
570 2017-01-05 20:05:58	0|jtimon|anyway, should go back to vacations, we spaniards give the christmas presents tomorrow and stuff (yeah we like doing things late)
571 2017-01-05 20:06:05	0|gmaxwell|luke-jr: I fully agree. but it would be a little crazy if the software just ... breaks. on its own (e.g. picks a difficulty whos blocks they won't accept).
572 2017-01-05 20:06:10	0|luke-jr|jtimon: not just spaniards!
573 2017-01-05 20:06:29	0|jtimon|who else?
574 2017-01-05 20:06:30	0|luke-jr|gmaxwell: throw a JSON exception? ☺
575 2017-01-05 20:06:38	0|luke-jr|jtimon: we also do gifts on the Epiphany here
576 2017-01-05 20:07:07	0|jtimon|interesting, will ask more next time we meet, sorry everyone else for the offtopic
577 2017-01-05 20:07:34	0|gmaxwell|luke-jr: it should be as simple as (if difficulty < 4 * limit, there is a maximum timestamp for exach block).
578 2017-01-05 20:07:59	0|luke-jr|gmaxwell: yes, if it makes sense to continue that chain
579 2017-01-05 20:08:40	0|gmaxwell|maybe four lines of code, just would take a little thinking to figure out the right four lines.  doesn't even have to be a consensus rule, just a thing that createnetblock does.
580 2017-01-05 20:08:59	0|adiabat|luke-jr: but what about if the hashrate is actually down 5X "naturally"; e.g. global thermonuclear war? :)
581 2017-01-05 20:09:23	0|gmaxwell|adiabat: we're not talking about 5x. We're talking about 1/20000th.
582 2017-01-05 20:09:28	0|luke-jr|^
583 2017-01-05 20:09:51	0|adiabat|luke-jr: ahh, you mean 4X on min-difficulty
584 2017-01-05 20:09:57	0|gmaxwell|luke-jr: it probably doesn't make sense to continue the chain, but it would be goofy if in tests the system fails on its own because of the rule.
585 2017-01-05 20:10:07	0|adiabat|luke-jr: yeah not even thermonuclear war acheives that.
586 2017-01-05 20:10:40	0|gmaxwell|maybe it does, but then who cares? y'all be dead in those cases.
587 2017-01-05 20:11:41	0|luke-jr|XD
588 2017-01-05 20:12:08	0|kanzure|death is merely a temporary inconvenience for thermonuclear scaling
589 2017-01-05 20:12:20	0|gmaxwell|in any case, raising the minimum difficulty was one of the two remaining issues for checkpoint removal.
590 2017-01-05 20:12:28	0|gmaxwell|The other is the signature checking bypass.
591 2017-01-05 20:12:37	0|luke-jr|kanzure: I'm not sure it's scaling to decrease demand.
592 2017-01-05 20:13:46	0|gmaxwell|I have two proposals for that: (1) we just get rid of it,  sipa doesn't like this.  (2) we replace it with a non-checkpoint based bypass but instead a proof of work based one, and petertodd opposed the best proposal thus far (and I assume otherws would too)
593 2017-01-05 20:14:06	0|gmaxwell|https://github.com/bitcoin/bitcoin/pull/9180
594 2017-01-05 20:16:01	0|luke-jr|would it be so terrible to keep a single "checkpoint" just for sigcheck bypass?
595 2017-01-05 20:17:31	0|gmaxwell|luke-jr: for the purpose of people misunderstanding the security model I think thats just as bad as what we have now.
596 2017-01-05 20:18:00	0|luke-jr|what if it's a param the user can specify?
597 2017-01-05 20:18:08	0|luke-jr|(with a sane default)
598 2017-01-05 20:18:27	0|gmaxwell|luke-jr: the fact that you can -checkpoints=0 now doesn't prevent people from mistaking that for the origin of the security of the history.
599 2017-01-05 20:19:03	0|luke-jr|:<
600 2017-01-05 20:19:44	0|gmaxwell|I have been thinking that maybe a configurable known good value ANDed with the 9180 process might be good enough. But I'm not sure.
601 2017-01-05 20:20:28	0|gmaxwell|and the continued obession with checkpoints by people (esp. academics) makes me want to not work on bitcoin anymore, so I might not be thinking about it objectively.
602 2017-01-05 20:20:31	0|luke-jr|what if we have multiple such values, all but one of which are bogus valid chains? ☺
603 2017-01-05 20:21:59	0|gmaxwell|from a security perspective if I was happy with PR9180 on its own, then I'd be happy with it anded with a restriction on what chain(s) it applies to.  So I think thats fine, but the problem is that people focus on the freeking hardcoded value, so what I hoped to do was just eliminate it.
604 2017-01-05 20:26:56	0|gmaxwell|luke-jr:  in any case we are in an optimally bad situation now.
605 2017-01-05 20:28:39	0|gmaxwell|because these hardcoded values pin the consensus we won't move them forward, and won't find out if making them do less would resolve the people confusing them for the security model, but because they (maybe) make a meaningful impact on IBD speed we won't take them out.
606 2017-01-05 20:29:23	0|gmaxwell|and the alternative of using POW can be argued to give more control of the system to miners, so thats opposed too.
607 2017-01-05 20:29:55	0|gmaxwell|(I don't share that belief because the threshold is so large that miners that could do that could simply confiscate all the coins anyways by replacing the chain back to 295k)
608 2017-01-05 20:30:33	0|gmaxwell|(but I don't think the position is an absurd one)
609 2017-01-05 20:32:59	0|gmaxwell|luke-jr: perhaps we can do this in the short term.  Introduce a "all prior signatures known good" blockhash which is used for script checking but doesn't pin the chain. Ancestors of that block get scriptchecked.. and then we can set that to a current height.  Then the chain pining checkpoints can be eliminated once we've done something about the header flooding... but regardless we can leave the
610 2017-01-05 20:33:05	0|gmaxwell|m alone for now.
611 2017-01-05 20:33:24	0|sdaftuar|gmaxwell: +1, seems reasonable to me.
612 2017-01-05 20:34:32	0|luke-jr|Ancestors of that block get scriptchecked..?
613 2017-01-05 20:34:44	0|gmaxwell|er don't get scriptchecked. :)
614 2017-01-05 20:35:49	0|luke-jr|ok, that sounds pretty much like what I thought the near-term goal already was ☺
615 2017-01-05 20:37:58	0|gmaxwell|okay, well I'll go PR the scriptcheck skipping change I guess.
616 2017-01-05 20:49:02	0|gmaxwell|I guess I'll open this question up to more than sipa:
617 2017-01-05 20:49:03	0|gmaxwell|22:48 <gmaxwell> I'm not impressed by the bare pointer twizzling in this commit:  https://github.com/bitcoin/bitcoin/pull/8775/files#diff-ad6efdc354b57bd1fa29fc3abb6e2872R233 esp with the type punning can  you suggest to luke a more C++ way to do this?
618 2017-01-05 20:49:07	0|gmaxwell|22:49 <gmaxwell> (thats also the code I would have written, but I'd feel I was probably doing it wrong while doing it.)
619 2017-01-05 20:51:00	0|BlueMatt|are we staunchly against having a "class CWallet" in !define WALLET?
620 2017-01-05 20:51:12	0|BlueMatt|forward declaration, that is
621 2017-01-05 20:59:26	0|luke-jr|that would make things so much simpler XD
622 2017-01-05 21:07:09	0|gmaxwell|I think the problem is that it may not compile since disabling the wallet at compile time changes our dependencies.
623 2017-01-05 21:07:47	0|gmaxwell|I suppose it could be a dummy class CWallet that exists in that case though.
624 2017-01-05 21:08:04	0|gmaxwell|e.g. has no methods or fields.
625 2017-01-05 21:08:59	0|BlueMatt|gmaxwell: not dummy, forward declartion
626 2017-01-05 21:09:04	0|BlueMatt|gmaxwell: i think in this case it will still compile
627 2017-01-05 21:09:16	0|BlueMatt|since there are no actual uses of it, just a pointer to it
628 2017-01-05 21:09:24	0|BlueMatt|which the compiler knows how to do, even without knowing shit about the class
629 2017-01-05 21:11:53	0|gmaxwell|Makes sense. Even to my C loving eyes, the code in 8775 struck me as pretty yucky.  If it's forward declared and you try to use it when you shouldn't the result will fail to compile or link. So.. seems fine to me.
630 2017-01-05 21:12:03	0|gmaxwell|but I'm not the person likely to have useful opinions on that.
631 2017-01-05 21:12:27	0|BlueMatt|I kinda agree, i /think/ forward decl will work, easy to test at least
632 2017-01-05 21:13:09	0|sipa|if it compiles with just a forward declaration, it should be fine
633 2017-01-05 21:13:19	0|sipa|and i guess it should
634 2017-01-05 21:13:33	0|sipa|i wouldn't want that in a longer-term solution, but that code will be in flux for a while
635 2017-01-05 21:14:07	0|luke-jr|so I can use a fwd decl?
636 2017-01-05 21:14:43	0|BlueMatt|luke-jr: try it, if it compiles, yes :)
637 2017-01-05 21:14:58	0|luke-jr|pretty sure it will
638 2017-01-05 21:15:02	0|gmaxwell|If it works and someone thinks its somehow worse than functions with void pointers in their typedefs and typecasting all over the place I will argue with them. :P
639 2017-01-05 21:15:46	0|luke-jr|sipa: but..!
640 2017-01-05 21:16:04	0|sipa|luke-jr: i know, i know. bitcoin would be much more secure if it didn't compile
641 2017-01-05 21:16:07	0|gmaxwell|sipa: code that does not compile never crashes.
642 2017-01-05 21:16:10	0|luke-jr|lol
643 2017-01-05 21:17:08	0|BlueMatt|it also doesn't have bugs
644 2017-01-05 21:17:11	0|BlueMatt|(for some definition of bugs)
645 2017-01-05 21:17:23	0|BlueMatt|then again nothing has bugs for some definition of bugs
646 2017-01-05 21:18:56	0|luke-jr|but also everything has bugs for some definition of bugs <.<
647 2017-01-05 21:19:32	0|luke-jr|btw, this doesn't look like it's going to change more than a few lines of code in this particular PR
648 2017-01-05 21:19:48	0|luke-jr|and may have to still use the ugly cast in Qt code to pass through signals/slots, dunno
649 2017-01-05 21:37:28	0|bitcoin-git|13bitcoin/06master 14b3d7b1c 15Gregory Maxwell: Wallet: Do not perform ECDSA in the fee calculation inner loop....
650 2017-01-05 21:37:28	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fd7d8c7b35ae...a7d55c933853
651 2017-01-05 21:37:29	0|bitcoin-git|13bitcoin/06master 14a7d55c9 15Pieter Wuille: Merge #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop....
652 2017-01-05 21:37:46	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9465: [Wallet] Do not perform ECDSA signing in the fee calculation inner loop. (06master...06no_signing_in_inner_loop) 02https://github.com/bitcoin/bitcoin/pull/9465
653 2017-01-05 21:52:47	0|bitcoin-git|13bitcoin/06master 14ba3cecf 15Pieter Wuille: Share unused mempool memory with coincache...
654 2017-01-05 21:52:47	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a7d55c933853...c252685aa586
655 2017-01-05 21:52:48	0|bitcoin-git|13bitcoin/06master 14c252685 15Pieter Wuille: Merge #8610: Share unused mempool memory with coincache...
656 2017-01-05 22:22:43	0|bitcoin-git|[13bitcoin] 15sipa pushed 11 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c252685aa586...f646275b90b1
657 2017-01-05 22:22:44	0|bitcoin-git|13bitcoin/06master 144df4479 15Alex Morcos: Remove extraneous LogPrint from fee estimation...
658 2017-01-05 22:22:44	0|bitcoin-git|13bitcoin/06master 1460ac00d 15Alex Morcos: Don't track transactions at all during IBD....
659 2017-01-05 22:22:45	0|bitcoin-git|13bitcoin/06master 1484f7ab0 15Alex Morcos: Remove member variable hadNoDependencies from CTxMemPoolEntry...
660 2017-01-05 22:22:53	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9138: Improve fee estimation (06master...06refactorFeeEstimation) 02https://github.com/bitcoin/bitcoin/pull/9138
661 2017-01-05 22:33:25	0|instagibbs|BlueMatt, if it doesn't compile there is no unexpected behavior :)
662 2017-01-05 22:36:54	0|gmaxwell|luke-jr: fking signals/slots.
663 2017-01-05 22:59:41	0|gmaxwell|morcos: do you think it would be reasonable for CreateTransaction or its kin to log the feerate its using for its construction?  So that if there is further concern about strange fees there is log evidence if the strange fee was a result of the estimator vs something else?
664 2017-01-05 23:37:14	0|luke-jr|a bigger concern I think is that logging is not enabled until it's too late
665 2017-01-05 23:37:51	0|luke-jr|so unless you log it by default (which may be reasonable for manual activity?), it won't be there when you want it
666 2017-01-05 23:38:46	0|luke-jr|maybe log it by default ASAP and we can quiet it in a few releases after things have been sufficiently resolved?