1 2016-12-16 00:10:10	0|bitcoin-git|[13bitcoin] 15funbucks opened pull request #9358: Tell github to quit trippin (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9358
  2 2016-12-16 00:42:12	0|gmaxwell|Good news: for a dbcache of size 2000, sipa's "per utxo" cache model is now 22.6% faster than master in a signature validation free chainstate reindex! (benchmarking with a cache size of 300 now, will report back in a few hours)
  3 2016-12-16 00:54:03	0|bitcoin-git|[13bitcoin] 15theuni closed pull request #9358: Tell github to quit trippin (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9358
  4 2016-12-16 01:23:09	0|kallle|According to the bitcoin.it wiki, "CompactSize" is a var int, and CVarInt is an "even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here)". But it's described in all documentation there and elsewhere as a "varint". So the varint is the compact size and the CVarInt/VARINT refer to something else. Doesn't that cause confusion?
  5 2016-12-16 01:28:05	0|sipa|the CVarInt in serialize.h is a bitcoin core internal thing, only used for the utxo database and undo data
  6 2016-12-16 01:28:14	0|sipa|and it doesn't appear anywhere in the p2p protocol
  7 2016-12-16 01:28:34	0|sipa|CompactSize is the varint type used in the p2p protocol for vector sizes etc
  8 2016-12-16 01:30:30	0|sipa|and yes, it's confusing...
  9 2016-12-16 01:30:38	0|sipa|historical reasons :)
 10 2016-12-16 01:33:21	0|kallle|Seems like a candidate for renaming but I can see how it would cause issues as people have used the two as they are for years... esp if COMPACTSIZE becomes VARINT.
 11 2016-12-16 02:23:13	0|Chris_Stewart_5|What is the criteria for setting the default dbcache value? Does a BIP have to be proposed to change it?
 12 2016-12-16 02:24:42	0|sipa|no
 13 2016-12-16 02:24:54	0|sipa|it doesn't affect the network in any way
 14 2016-12-16 02:25:05	0|sipa|only your own memory/cpu tradeoff
 15 2016-12-16 02:27:33	0|Chris_Stewart_5|What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)
 16 2016-12-16 02:27:59	0|Chris_Stewart_5|I know blocksize/dbcache aren't really related, but I think I was thinking about that as policy for some defaults in bitcoin core.
 17 2016-12-16 02:27:59	0|sipa|sure, but it doesn't need any consideration ahead of time
 18 2016-12-16 02:28:12	0|sipa|we can just occasionally change defaults to keep up with technology trends
 19 2016-12-16 02:28:49	0|sipa|i think bitcoin-qt for example should just detect how much memory you have at startup, and based on that, choose something and let the user customize
 20 2016-12-16 02:29:04	0|sipa|it's harder to do that in bitcoind, which we exapct to run on low-power devices too
 21 2016-12-16 02:29:05	0|Chris_Stewart_5|I guess it seems like it could break out into a very politicized change, which is why I think the BIP process would be needed -- but I understand what you mean by it doesn't affect consensus
 22 2016-12-16 02:29:36	0|gmaxwell|Chris_Stewart_5: that would be like having a BIP for the color of your theme... it's a purely local thing .. it doesn't matter to you what anyone else uses.
 23 2016-12-16 02:29:43	0|gmaxwell|It isn't something where "interoperability" is required.
 24 2016-12-16 02:30:21	0|sipa|BIP42 suggests that the currency symbol color should be considered
 25 2016-12-16 02:33:52	0|Chris_Stewart_5|sipa: That is interesting. I kind of like that idea wrt to reading mem and just setting it off of that.
 26 2016-12-16 02:34:24	0|sipa|what idea?
 27 2016-12-16 02:34:38	0|Chris_Stewart_5|your comment wrt to bitcoin-qt
 28 2016-12-16 02:34:46	0|sipa|Chris_Stewart_5: not only does not affect consensus - it doesn't affect anything
 29 2016-12-16 02:35:01	0|sipa|BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
 30 2016-12-16 02:35:16	0|gmaxwell|Chris_Stewart_5: it would be a wrong assumption to assume the user wants all their memory used by bitcoin. :(
 31 2016-12-16 02:35:49	0|Chris_Stewart_5|gmaxwell: absurd! :P
 32 2016-12-16 02:37:06	0|gmaxwell|we could certantly reduce it based on the amount of free memory!
 33 2016-12-16 02:37:09	0|Chris_Stewart_5|ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
 34 2016-12-16 02:42:49	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9359: Fix CWalletTx::GetImmatureCredit() returning stale values. (06master...06pr/immature) 02https://github.com/bitcoin/bitcoin/pull/9359
 35 2016-12-16 02:42:51	0|Chris_Stewart_5|sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
 36 2016-12-16 08:08:08	0|gmaxwell|I currently have a node running 8695, 8808, 9039, 9045, 9125, 9138, and 9199 ... surprisingly all applied without conflict.
 37 2016-12-16 08:16:32	0|NicolasDorier|When I do "fundrawtransaction" followed by a "getnewaddress" I noticed the generated address and the change of funrawtransaction are the same
 38 2016-12-16 08:16:38	0|NicolasDorier|is it on purpose ?
 39 2016-12-16 08:17:09	0|NicolasDorier|it is like funrawtransaction does not increment the index for generating the next address
 40 2016-12-16 08:17:44	0|NicolasDorier|I can do a getnewaddress manually after FundRawTransaction, but first I would like if it is on purpose
 41 2016-12-16 08:19:36	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9361: Fix: OSX compile fix: defer to bswap_XX when defined. (06master...06macosx-qt-build-fix) 02https://github.com/bitcoin/bitcoin/pull/9361
 42 2016-12-16 08:22:34	0|jonasschnelli|NicolasDorier: thats right. Fundrawtransaction does not keep the reserve key.
 43 2016-12-16 08:23:20	0|NicolasDorier|what about adding a new parameter to fundrawtransaction for it to be the case ? I don't want same key used twice by mistake
 44 2016-12-16 08:23:28	0|jonasschnelli|NicolasDorier: what you can and should do is call getrawchangeaddress and use this with fundrawtransaction (you can specify a change address there)
 45 2016-12-16 08:23:34	0|NicolasDorier|ah
 46 2016-12-16 08:23:35	0|NicolasDorier|yes
 47 2016-12-16 08:23:39	0|NicolasDorier|will do that thanks
 48 2016-12-16 08:23:41	0|jonasschnelli|NicolasDorier: yes. We should do that-.
 49 2016-12-16 08:23:49	0|jonasschnelli|It feels llike a serious bug
 50 2016-12-16 08:23:53	0|jonasschnelli|I'm opening an issue
 51 2016-12-16 08:23:57	0|NicolasDorier|thanks
 52 2016-12-16 09:19:11	0|bitcoin-git|[13bitcoin] 15rebroad opened pull request #9363: Don't provide blocktxns for old blocks on a fork. (06master...06MinChainWorkBlocktxns) 02https://github.com/bitcoin/bitcoin/pull/9363
 53 2016-12-16 09:32:10	0|gmaxwell|rebroad: you know you can run all the tests that travis runs locally?
 54 2016-12-16 09:36:13	0|rebroad|gmaxwell, I assumed it was possible, although I have not yet worked out how to make it do so... I chose the --enable-extended-rpc-tests on the configure, but then couldn't work out what to do following that.
 55 2016-12-16 09:37:16	0|rebroad|and anyway, "make check" is failing on my system... I raised an issue for it.
 56 2016-12-16 09:38:46	0|rebroad|gmaxwell, what prompted you to mention the travis tests?
 57 2016-12-16 09:40:11	0|rebroad|(well, 9 times out of 10 - re "make check")
 58 2016-12-16 09:40:16	0|gmaxwell|rebroad: number of failing test on PR opens from you suggested to me that you weren't aware you could run them locally. (e.g. I follow the link when the bot mentions it in IRC and its failed already).
 59 2016-12-16 09:41:50	0|rebroad|gmaxwell, how do I run them locally please? (I am re-reading the docs now, but have not seen this info as yet)
 60 2016-12-16 09:42:38	0|rebroad|my latest PR seems to have works all except for fundwartransaction.py (https://travis-ci.org/bitcoin/bitcoin/jobs/184479440)
 61 2016-12-16 09:42:48	0|rebroad|and that failed only on 1 of the 6 platforms
 62 2016-12-16 09:43:19	0|rebroad|I'm assuming if I run the tests locally it only tests my own platform
 63 2016-12-16 09:43:30	0|gmaxwell|RE your latest PR, the same behavior exists for blocks it is pointless to be much more restrictive there for getblocktxn than blocks themselves. Also, we don't want to fail to reply to a getblocktxn we might have just offered by sending a compact block and then immediately having a reorg, as that will dos attack our peer.  For the code that avoids fingeringprinting with blocks search for "To pre
 64 2016-12-16 09:43:36	0|gmaxwell|vent fingerprinting" in net_processing.cpp.
 65 2016-12-16 09:46:01	0|rebroad|gmaxwell, "same behavior exists for blocks" - same behavior as what? For blocks it checks if it is more than 1 month old - quite different logic than is used for getblocktxns
 66 2016-12-16 09:46:22	0|rebroad|it also checks if it is in the activechain - it doesn't do this for getblocktxns
 67 2016-12-16 09:46:43	0|gmaxwell|rebroad: well you may not be able to test osx locally, though you could test windows if you wanted.  You can actually see exactly what travis runs by looking in the file .travis.yml   but the relevant command is qa/pull-tester/tpc-tests.py
 68 2016-12-16 09:46:46	0|rebroad|for getblocktxns (from what I can tell) it checks if the height it within a certain height - a height comparison
 69 2016-12-16 09:47:49	0|rebroad|gmaxwell, thanks (re rpc-tests.py) runnnig it now.. somewhat obscure command which I would not have tried unless told
 70 2016-12-16 09:48:00	0|gmaxwell|rebroad: yes but there is no point for the purpose of avoiding fingerprinting in making the test there _more_ restrictive than the one for blocks.
 71 2016-12-16 09:48:37	0|wumpus|rebroad: https://github.com/bitcoin/bitcoin/tree/master/qa on running qa tests locally
 72 2016-12-16 09:49:13	0|wumpus|(this is all linked from the main README.md, you should have no problem finding this documentation if you bothered looking even casually)
 73 2016-12-16 09:53:05	0|wumpus|I'm disappointed that you're constantly submitting issues and even pull request while you apparently don't even know how to run the tests
 74 2016-12-16 09:53:20	0|rebroad|wumpus, I see the section now - yes, it is there - not sure how I missed it last time
 75 2016-12-16 09:56:19	0|rebroad|I don't know when that info was added but it wasn't in there when I last read it - I'm not sure how often I am expected to re-read the README file
 76 2016-12-16 09:56:38	0|jonasschnelli|Also, rebroad: you can setup travis for your own development branch
 77 2016-12-16 09:56:48	0|jonasschnelli|(in case you open PRs to have them run though travis)
 78 2016-12-16 09:56:59	0|wumpus|it was there for a long time, has been updated a few times
 79 2016-12-16 09:57:05	0|rebroad|jonasschnelli, that would be very useful indeed. thanks
 80 2016-12-16 09:57:19	0|jonasschnelli|Just head to http://travis-ci.org
 81 2016-12-16 09:57:26	0|wumpus|and yes you're supposed to keep up to date with the (extrememly minimal) development documentation if you do development
 82 2016-12-16 09:57:28	0|jonasschnelli|and enable you rebroad/bitcoin repo
 83 2016-12-16 10:01:22	0|rebroad|jonasschnelli, it appears I enabled travis for my rebroad/bitcoin more than 9 months ago. I have just revisited it now, but so far am struggling to understand the interface
 84 2016-12-16 10:01:45	0|jonasschnelli|understand travises interface?
 85 2016-12-16 10:02:00	0|wumpus|travis, too, has documentation
 86 2016-12-16 10:03:58	0|wumpus|it looks like the fundrawtransaction.py test is flaky at the moment
 87 2016-12-16 10:05:40	0|rebroad|running the extended tests locally fundrawtransaction.py passed, but walletbackup.py failed!
 88 2016-12-16 10:05:44	0|jonasschnelli|wumpus: what do you think about https://github.com/bitcoin/bitcoin/issues/9362, it surprises me that nobody has complained about address reuse so far.
 89 2016-12-16 10:05:52	0|rebroad|my one line change doesn't touch things that either of those tests test
 90 2016-12-16 10:06:44	0|wumpus|jonasschnelli: interesting - it's supposed to update the change address when it is actually used
 91 2016-12-16 10:07:03	0|wumpus|jonasschnelli: apparently that logic doesn't work
 92 2016-12-16 10:07:13	0|rebroad|gmaxwell, I am struggling to understand the context of what you are referring to. you mention a "more restrictive test" - but I am not sure which test you mean. The test was previously checking that the height was within 10 blocks from active-tip - it is still that test, but no longer assumes only one chain.
 93 2016-12-16 10:07:47	0|rebroad|gmaxwell, by making that assumption it would respond to requests for any block of that height, whether on the active chain or not
 94 2016-12-16 10:07:59	0|rebroad|(at least, this is my understanding from the code)
 95 2016-12-16 10:09:25	0|rebroad|given the reason for the restriction was to avoid delving into old data and hard-disk read access, then the new check seems a better way, and doesn't apply any additional restrictions over the previous check (other than disallowing other chains where the work would have been much lower - therefore not a problem disabling this from what I can see)
 96 2016-12-16 10:10:18	0|rebroad|if it is intentional to allow access to old blocks on alt chains, but not on the active chain, then I am at a loss why this would be intentional
 97 2016-12-16 10:11:20	0|rebroad|my understanding is that as compact blocks relys on the memory pool, that old blocks on any chain are unnecessary
 98 2016-12-16 10:11:25	0|wumpus|yes this is intentional, it avoids fingerprinting attacks
 99 2016-12-16 10:11:43	0|rebroad|wumpus, it would allow fingerprint attacks, not avoid them
100 2016-12-16 10:11:57	0|wumpus|peers could fingerprint nodes based on what alt-chains they own - this is avoided now
101 2016-12-16 10:12:22	0|rebroad|wumpus, which PR are you referring to?
102 2016-12-16 10:12:45	0|rebroad|wumpus, my PR is a change that avoids fingerprinting. the current master allows it
103 2016-12-16 10:12:47	0|wumpus|I'm not refering to a PR, but to the reason that access is not allowed to old blocks on alt chains
104 2016-12-16 10:13:01	0|rebroad|wumpus, my PR stops access to old blocks on alt chains
105 2016-12-16 10:13:12	0|rebroad|in order to stop fingerprinting
106 2016-12-16 10:13:56	0|wumpus|anyhow I can't reproduce the fundrawtransaction problem locally either
107 2016-12-16 10:14:07	0|rebroad|#9363
108 2016-12-16 10:14:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/9363 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
109 2016-12-16 10:15:58	0|rebroad|in order for the fingerprinting to happen, a peer would need to be fed blocks on an alt chain until height within 10 from the current active tip
110 2016-12-16 10:16:13	0|rebroad|then once that is done, a getblocktxn request would reveal the fingerprint
111 2016-12-16 10:16:36	0|rebroad|I have not tested this can be done, but from reading the code I believe it could
112 2016-12-16 10:17:47	0|rebroad|i would like to be able to write a test to show this - i need to become more familiar with the python tests to be able to do this. apologies if I am wrong about my assumption based on reading the code
113 2016-12-16 10:19:09	0|rebroad|and to be honest, I am not even sure what the big deal about fingerprinting is, but given it is coded to be protected against, I assumed this vector ought to be closed also
114 2016-12-16 10:20:09	0|wumpus|I don't understand why you write and submit a patch to do something that you don't even know it's a big deal?
115 2016-12-16 10:20:19	0|wumpus|why are you working on that at all, then?
116 2016-12-16 10:20:39	0|rebroad|I don't claim to know anything as Aristotle once said
117 2016-12-16 10:20:48	0|rebroad|I can go only on assumptions therefore
118 2016-12-16 10:20:54	0|wumpus|I just don't understand your motivation
119 2016-12-16 10:21:18	0|rebroad|wumpus, to help. what is your motivation?
120 2016-12-16 10:21:23	0|wumpus|either you believe fingerprint attacks are a serious attack vector and you try to improve mitigation of them, or you don't just leave the logic alone
121 2016-12-16 10:21:30	0|wumpus|for which change?
122 2016-12-16 10:21:43	0|rebroad|wumpus, for the project i mean
123 2016-12-16 10:21:58	0|wumpus|that's off topic here and certainly not something I want to get into
124 2016-12-16 10:22:19	0|rebroad|sorry, I answered assuming you were referring to the project, not the PR
125 2016-12-16 10:22:47	0|wumpus|the only thing relevant here is the motivation to make specific changes to the code, as you need that to convince other people to care about your change
126 2016-12-16 10:23:32	0|rebroad|wumpus, I assume that given anti-fingerprinting code is already in the code, then a sufficient number of core developers appreciate its importance. I didn't consider that I therefore needed to appreciate it also
127 2016-12-16 10:23:48	0|rebroad|I mean understand not appreciate
128 2016-12-16 10:24:33	0|rebroad|anyway, if I was wrong, and it's not important. I will close the PR
129 2016-12-16 10:25:02	0|rebroad|but it does make me question why it was important for blocks but not blocktxns
130 2016-12-16 10:25:11	0|wumpus|well your described angle is fine if you care about it: write a test that demonstrates it, then demonstrate that your code fixes that attack
131 2016-12-16 10:25:37	0|rebroad|wumpus, ok, I will get to work on that.. but before I do.. can anyone explain to me why fingerprinting attacks are bad?
132 2016-12-16 10:25:41	0|wumpus|if you don't, then don't waste your time
133 2016-12-16 10:25:49	0|rebroad|wumpus, because if they are not that bad, then it's a lot of effort for something trivial
134 2016-12-16 10:26:04	0|wumpus|if you don't think they are bad then donj't spend effort on it!
135 2016-12-16 10:26:10	0|rebroad|wumpus, lol.. ok
136 2016-12-16 10:26:16	0|wumpus|why do you need to be hand-held through every little thing
137 2016-12-16 10:26:39	0|rebroad|wumpus, it takes two to hold hands
138 2016-12-16 10:27:23	0|wumpus|fingerprinting has to do with privacy, especially over tor or other anonymity layers. Theoretically you should not be able to identify a peer connecting to you over tor, but with fingerprinting tricks you can.
139 2016-12-16 10:27:32	0|rebroad|wumpus, I mean that we both needed to understand each other to work out the way forward
140 2016-12-16 10:28:00	0|rebroad|wumpus, ah... thanks. i understand now in that context. thank you for explaining
141 2016-12-16 10:28:07	0|wumpus|if you can distinguish and thus identify peers sending you a transaction you gain information you shouldn't have
142 2016-12-16 10:28:22	0|wumpus|if you don't care about that, then well, don't
143 2016-12-16 10:28:45	0|rebroad|wumpus, based on that explanation, I shall work on creating that test you asked for
144 2016-12-16 10:28:54	0|wumpus|okay thanks
145 2016-12-16 10:31:27	0|wumpus|so fundrawtransaction.py test very regularly fails on travis with "Assertion failed: Mempool sync failed"
146 2016-12-16 10:31:33	0|wumpus|but I can't reproduce this locally
147 2016-12-16 10:32:13	0|luke-jr|timing maybe?
148 2016-12-16 10:32:45	0|wumpus|some recent change must have triggered it, it was not the case before
149 2016-12-16 10:33:07	0|jonasschnelli|wumpus: fundrawtx should not keep the CReserveKey, sendrawtx could, but what solutions do we offer for users broadcastign over different channels...
150 2016-12-16 10:33:16	0|jonasschnelli|Maybe we should add a call
151 2016-12-16 10:33:30	0|jonasschnelli|to reserve the used change key of a funded raw tx
152 2016-12-16 10:33:44	0|jonasschnelli|or to reserve a key by a specific address
153 2016-12-16 10:33:52	0|jonasschnelli|(and release)
154 2016-12-16 10:33:53	0|wumpus|jonasschnelli: well for broadcasting over separate channels we can't offer automatic change address functionality
155 2016-12-16 10:34:30	0|wumpus|jonasschnelli: unless there would be a way to tell the wallet of a transaction without broadcasting it
156 2016-12-16 10:34:45	0|jonasschnelli|ah,.. right.
157 2016-12-16 10:35:13	0|wumpus|right now the only way to tell the wallet is sendrawtransaction, which always broadcasts (walletbroadcast=0 setting won't help you there)
158 2016-12-16 10:35:25	0|jonasschnelli|I guess we should add detecting the change key in sendrawtx and make sure we reserve it from the keypool
159 2016-12-16 10:36:12	0|wumpus|either that or indeed it should be an explicit step to reserve a change address, which should be returned if not used
160 2016-12-16 10:36:37	0|wumpus|this was overlooked in the fundrawtransaction design
161 2016-12-16 10:38:18	0|wumpus|fundrawtransaction doesn't even consistently fail in the same place (!)
162 2016-12-16 10:38:30	0|wumpus|I mean the test
163 2016-12-16 10:39:04	0|wumpus|in https://travis-ci.org/bitcoin/bitcoin/jobs/184431201 it's the sync_all on line 534 that fails
164 2016-12-16 10:39:15	0|wumpus|in https://travis-ci.org/bitcoin/bitcoin/jobs/184473580 it's the one on line 461
165 2016-12-16 10:40:22	0|wumpus|in https://travis-ci.org/bitcoin/bitcoin/jobs/184333528 it's line 449
166 2016-12-16 10:40:41	0|wumpus|the only commonality is that the fundrawtransaction.py test fails, and it happens while syncing mempools
167 2016-12-16 10:54:14	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9365: [testing] Dummy commit for checking travis failure (06master...062016_12_debug_travis_issue) 02https://github.com/bitcoin/bitcoin/pull/9365
168 2016-12-16 11:00:13	0|MarcoFalke|wumpus: The cause of test failure is most likely already known
169 2016-12-16 11:00:54	0|wumpus|MarcoFalke: what then?
170 2016-12-16 11:01:21	0|MarcoFalke|(see scrollback of yesterday evening)
171 2016-12-16 11:01:29	0|MarcoFalke|Might be some rounding in fee filter
172 2016-12-16 11:01:49	0|MarcoFalke|at the floor (i.e. minrelayfee)
173 2016-12-16 11:02:15	0|wumpus|can we work around this quicky to make travis pass again for unrelated pulls?
174 2016-12-16 11:02:52	0|MarcoFalke|Sure, I can try to settxfee in fundrawtx.py
175 2016-12-16 11:03:14	0|wumpus|reverting #9313 should help, then?
176 2016-12-16 11:03:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
177 2016-12-16 11:04:03	0|wumpus|it started yesterday and the only pull merged yesterday affecting fees/feefilters is that one
178 2016-12-16 11:04:04	0|MarcoFalke|Yes, would help.
179 2016-12-16 11:04:33	0|MarcoFalke|But I'd like to get it in in another form then
180 2016-12-16 11:05:03	0|wumpus|well we need a temporary workaround to make travis sane agian, we can always merge it again once this issue is solved
181 2016-12-16 11:05:40	0|MarcoFalke|ok, fine w/ me
182 2016-12-16 11:05:44	0|wumpus|anyhow going to try in #9365
183 2016-12-16 11:05:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
184 2016-12-16 11:06:52	0|wumpus|if travis will consistently pass with that reverted, I'm going to revert it on master too
185 2016-12-16 11:07:27	0|wumpus|in the mean time I've still managed to reproduce it locally 0 times - what makes this so special that it only happens on travis, I wonder
186 2016-12-16 11:08:16	0|wumpus|btw can anyone else get results from seed.bitcoin.sipa.be? it's been giving me nothing for something like two weeks now
187 2016-12-16 11:08:38	0|wumpus|but I've heard no one else compain about it
188 2016-12-16 11:12:49	0|jonasschnelli|wumpus: we have a bug in the seeder somewhere...
189 2016-12-16 11:12:53	0|jonasschnelli|I couldn't track it down.
190 2016-12-16 11:13:10	0|jonasschnelli|Seems to be introduced with the filtering option
191 2016-12-16 11:13:28	0|wumpus|jonasschnelli: okay - yes your testnet seed fails too
192 2016-12-16 11:13:31	0|jonasschnelli|Must be something with the cache... seeder is running but not results empty responses.
193 2016-12-16 11:13:40	0|jonasschnelli|(need to attach the debugger)
194 2016-12-16 11:13:55	0|jonasschnelli|But my long term plan is, to split the seeder in a crawler and a server
195 2016-12-16 11:14:03	0|jonasschnelli|As server, I'd like to use djbdns
196 2016-12-16 11:14:11	0|jonasschnelli|Shouldn't be that hard.
197 2016-12-16 11:15:11	0|wumpus|so it never returns results, or starts returning nothing after a while?
198 2016-12-16 11:16:08	0|wumpus|gah my dummy commit passed travis. Stupid heODODisenbug :)
199 2016-12-16 11:16:20	0|wumpus|heisenbug*
200 2016-12-16 11:19:13	0|btcdrak|wumpus: I also get no results from the seed, and I have complained about it on occasion
201 2016-12-16 11:23:23	0|MarcoFalke|wumpus: It should fail at most 25% of the time
202 2016-12-16 11:27:41	0|rebroad_|wumpus, my plan is to adapt the fingerprint test that (I presume) is already written to test that blocks cannot be fingerprinted - would you know which test file does that please? Is there a test already written to test fingerprint attacks at all?
203 2016-12-16 11:41:20	0|wumpus|btcdrak: okay, hadn't noticed then
204 2016-12-16 11:41:50	0|wumpus|MarcoFalke: that seems true on travis - but I'm running it locally in a loop, has run ~100 times or so, no failures
205 2016-12-16 11:42:35	0|wumpus|in any case #9365 seems to be consistently passing with #9313 reverted
206 2016-12-16 11:42:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
207 2016-12-16 11:42:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
208 2016-12-16 11:43:27	0|MarcoFalke|That is odd. I can no longer reproduce either. I surely saw it yesterday
209 2016-12-16 11:44:21	0|MarcoFalke|Nah, just failed
210 2016-12-16 11:49:53	0|MarcoFalke|rebroad_: qa/rpc-tests/p2p-compactblocks.py
211 2016-12-16 11:52:45	0|rebroad_|MarcoFalke, I already checked that file - it seems to be a test for compact blocks - I was asking about the test that tests that old alt-chain full-blocks cannot be requested...  this would be the closest to the test I want to create
212 2016-12-16 11:53:09	0|rebroad_|MarcoFalke, thanks though
213 2016-12-16 11:53:45	0|rebroad_|these python tests are new territory for me.. so a bit of a learning curve..
214 2016-12-16 11:54:40	0|rebroad_|my goodness the pruning test seems to take a while to run...
215 2016-12-16 12:23:15	0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #9361: [WIP] Fix: OSX QT compile fix: defer to bswap_XX when defined. (06master...06macosx-qt-build-fix) 02https://github.com/bitcoin/bitcoin/pull/9361
216 2016-12-16 12:25:43	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9366: Fix: OSX QT compile: use built-in swap if available, or defer (06master...06macosx-qt-build-fix2) 02https://github.com/bitcoin/bitcoin/pull/9366
217 2016-12-16 12:30:49	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (06master...06Mf1612-feeFilterAlways2) 02https://github.com/bitcoin/bitcoin/pull/9367
218 2016-12-16 13:11:49	0|morcos|MarcoFalke: thanks... i just got a chance to sit down and look and i'd forgotten how fundrawtransaction sets exactly min_relay_tx_fee, but i think the way you fixed it makes the most sense.
219 2016-12-16 13:23:22	0|phantomcircuit|wumpus, can you tell me about commit e8ef3da7 ?
220 2016-12-16 13:23:23	0|phantomcircuit|it's from 2011 so im not expecting much
221 2016-12-16 13:23:35	0|phantomcircuit|commit message is just "update core to d0d80170a2ca73004e08fb85007fe055cbf4e411 (CWallet class)"
222 2016-12-16 13:25:52	0|phantomcircuit|nvm i see i should actually be asking sipa maybe?
223 2016-12-16 13:26:10	0|phantomcircuit|nvm i see i should be asking s_nakamoto
224 2016-12-16 13:26:12	0|phantomcircuit|:/
225 2016-12-16 13:50:17	0|rebroad|gmaxwell, re this (https://botbot.me/freenode/bitcoin-core-dev/2016-12-15/?msg=78044110&page=4) - are you saying that one won't need a segwit wallet to spend a segwit tx?
226 2016-12-16 13:54:03	0|instagibbs|this is a bit #bitcoin but rebroad, you only need a segwit wallet to spend segwit outputs that you receive... but by definition you won't ask for them and receive legacy payments
227 2016-12-16 13:57:19	0|rebroad|instagibbs, ah. yes, makes sense. thanks.
228 2016-12-16 14:03:05	0|rebroad|gmaxwell, did zander change his article or did you misquote it? the sentence "So if a person doesn't upgrade they will eventually not be able to accept money from anyone." does not appear to be in the URL you posted on here
229 2016-12-16 14:09:52	0|bitcoin-git|[13bitcoin] 15s-matthew-english opened pull request #9368: change to declarative sentences. simplify links (06master...06patch-13) 02https://github.com/bitcoin/bitcoin/pull/9368
230 2016-12-16 14:18:52	0|phantomcircuit|instagibbs, uh do you even need a segwit compatible wallet to spend segwit outputs?
231 2016-12-16 14:18:56	0|phantomcircuit|i didn't think you did
232 2016-12-16 14:19:57	0|phantomcircuit|i don't think you do actually
233 2016-12-16 14:20:02	0|Chris_Stewart_5|phantomcircuit: Pretty sure you do, you won't be able to construct the tx in the proper structure without it
234 2016-12-16 14:20:03	0|phantomcircuit|the utxo entries aren't changes
235 2016-12-16 14:20:14	0|phantomcircuit|changed*
236 2016-12-16 14:20:39	0|phantomcircuit|you'd have to know that there is a transaction output in the utxo to begin with
237 2016-12-16 14:20:53	0|phantomcircuit|but if you have someone providing you transactions with the signatures stripped in normal format
238 2016-12-16 14:20:56	0|Chris_Stewart_5|segwit P2WPKH outputs require a empty script sig, and P2WSH requires a push only scriptSig of 32 bytes i think
239 2016-12-16 14:21:07	0|phantomcircuit|ok?
240 2016-12-16 14:21:08	0|phantomcircuit|so
241 2016-12-16 14:21:42	0|phantomcircuit|you're talking about inputs not outputs
242 2016-12-16 14:21:48	0|phantomcircuit|which is what the person spending cares about
243 2016-12-16 14:22:03	0|phantomcircuit|i mean maybe it's not easy to do
244 2016-12-16 14:22:08	0|phantomcircuit|but you certainly should be able to
245 2016-12-16 14:22:44	0|Chris_Stewart_5|how doe thes person spending an output not care about the input? Isn't that by definition the inputs to the script program to make it evaluate to true?
246 2016-12-16 14:23:44	0|phantomcircuit|Chris_Stewart_5, why would they care about the inputs to a transaction they're spending the outputs of?
247 2016-12-16 14:26:16	0|Chris_Stewart_5|phantomcircuit: 'transactions stripped in normal format' -- so you mean someoen is just providing you a serialized tx to hash, then sign the hash?
248 2016-12-16 14:33:35	0|rebroad|phantomcircuit, if you have a non-segwit wallet, then you can spend any SegWit transaction... but it will never get mined :)
249 2016-12-16 14:34:05	0|rebroad|well, it could get mined by the 5% still on the non-segwit fork.. but would soon get orphaned
250 2016-12-16 15:10:01	0|phantomcircuit|rebroad, why?
251 2016-12-16 15:10:22	0|phantomcircuit|the scriptPubKey is the same right?
252 2016-12-16 15:10:26	0|phantomcircuit|wait maybe it's not
253 2016-12-16 15:10:27	0|phantomcircuit|hmm
254 2016-12-16 15:11:04	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9369: Factor out CWallet::nTimeSmart computation into a method. (06master...06pr/atw-timesmart) 02https://github.com/bitcoin/bitcoin/pull/9369
255 2016-12-16 15:43:34	0|jonasschnelli|morcos: you once asked about a short description how the proposed spv-ish auxiliary block downloads works: https://github.com/bitcoin/bitcoin/pull/9171#issuecomment-267616678
256 2016-12-16 15:50:46	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9365: [testing] [donotmerge] Dummy commit for checking travis failure (06master...062016_12_debug_travis_issue) 02https://github.com/bitcoin/bitcoin/pull/9365
257 2016-12-16 16:08:28	0|phantomcircuit|rebroad, yeah i still dont see why you wouldn't be able to spend outputs from a segwit transactions with a normal transaction
258 2016-12-16 16:08:38	0|phantomcircuit|the only thing being changed is the serialization of the script
259 2016-12-16 16:10:22	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c9e00591cd3f...8c7947e09ff8
260 2016-12-16 16:10:23	0|bitcoin-git|13bitcoin/06master 148c7947e 15Wladimir J. van der Laan: Merge #9367: If we don't allow free txs, always send a fee filter (take 2)...
261 2016-12-16 16:10:23	0|bitcoin-git|13bitcoin/06master 14fa16b8f 15MarcoFalke: If we don't allow free txs, always send a fee filter (take 2)
262 2016-12-16 16:10:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (06master...06Mf1612-feeFilterAlways2) 02https://github.com/bitcoin/bitcoin/pull/9367
263 2016-12-16 16:18:01	0|instagibbs|phantomcircuit, if your wallet doesn't understand segwit, it has no idea how to sign, if nothing else
264 2016-12-16 16:18:09	0|instagibbs|(sorry missed convo)
265 2016-12-16 16:30:11	0|rebroad|phantomcircuit, segwit as I understand is an extra bunch of rules that pre-segwit wallets have no knowledge of... pre-segwit wallets simply see segwit txs as txs that anyone can spend, so the only thing pre-segwit wallets can do is treat them as such, which segwit wallets and miners will reject as it ignores the segwit rules
266 2016-12-16 16:33:26	0|sipa|rebroad: no wallet does anything with outputs they do not understand
267 2016-12-16 16:33:43	0|sipa|*nodes* will treat those outputs as anyonecanspend, yes
268 2016-12-16 16:33:49	0|sipa|but wallets don't
269 2016-12-16 16:34:14	0|sipa|your wallet does not show you all anyonecanspend outputs on the network now, right?
270 2016-12-16 16:34:59	0|sipa|the only way you will receive a segwit output is if you give out a segwit address, which will only happen if your wallet supports it
271 2016-12-16 16:35:53	0|rebroad|sipa, well, nodes, and modified pre-segwit wallets ;)
272 2016-12-16 16:36:06	0|sipa|sure
273 2016-12-16 16:36:17	0|sipa|they can try
274 2016-12-16 16:36:25	0|sipa|but they won't confirm
275 2016-12-16 16:36:51	0|rebroad|sipa, if they did confirm, miners would build upon those blocks
276 2016-12-16 16:37:06	0|rebroad|at least, pre-segwit activation anyway
277 2016-12-16 16:37:26	0|rebroad|but people would have to be a little foolish to create such a tx pre-segwit
278 2016-12-16 16:37:44	0|sipa|pre-activation you shouldn't be creating segwit outputs
279 2016-12-16 16:37:49	0|sipa|that's very dangerois
280 2016-12-16 16:42:06	0|Victorsueca|creating a segwit transaction without miners and nodes enforcing segwit yet can potentially lead to anyone-can-spend outputs
281 2016-12-16 16:43:06	0|sipa|not potentially
282 2016-12-16 16:43:18	0|sipa|by definition, they will be anyonecanspend outputs
283 2016-12-16 16:45:25	0|rebroad|they need to be anyonecanspend outputs for segwit to be possible
284 2016-12-16 16:49:32	0|Victorsueca|just had a quick thought about this....
285 2016-12-16 16:51:19	0|Victorsueca|let's say the last block in a 2016 block period is the one that decides if segwit activates in that moment or it will in the next period (or even, hopefully not, never)...
286 2016-12-16 16:52:05	0|Victorsueca|and with that block it reaches 95% required to activate it
287 2016-12-16 16:52:31	0|sipa|that's not possible
288 2016-12-16 16:52:42	0|sipa|there is another 2016 block before it activates
289 2016-12-16 16:52:49	0|Victorsueca|ahh right
290 2016-12-16 16:53:04	0|sipa|the 95% makes it go to the LOCKEDIN state
291 2016-12-16 16:53:38	0|Victorsueca|welp, that solves it pretty much
292 2016-12-16 16:54:23	0|Victorsueca|my quick thoughts don't make sense most of the times.... but last time one of them made sense it was a disaster
293 2016-12-16 17:01:02	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9370: Fix fundrawtransactions address-reuse problem (06master...062016/12/fix_frt_cop) 02https://github.com/bitcoin/bitcoin/pull/9370
294 2016-12-16 17:11:43	0|jonasschnelli|I would say that #9370 (or one of the alternative solutions) is a candidate for a 0.13.2 backport.
295 2016-12-16 17:11:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9370 | Fix fundrawtransactions address-reuse problem by jonasschnelli · Pull Request #9370 · bitcoin/bitcoin · GitHub
296 2016-12-16 17:18:09	0|phantomcircuit|instagibbs, you're signing the new transaction not the old one
297 2016-12-16 17:18:37	0|phantomcircuit|rebroad, that's not saying that the wallet needs to understand segwit
298 2016-12-16 17:18:58	0|phantomcircuit|just that it needs to get the utxo entries from somewhere other than the transaction data
299 2016-12-16 17:19:25	0|phantomcircuit|wait no
300 2016-12-16 17:19:34	0|phantomcircuit|the SIGNATURE isn't needed by the person spending
301 2016-12-16 17:19:43	0|phantomcircuit|yeah im 99.99% sure you're wrong
302 2016-12-16 17:20:13	0|phantomcircuit|sipa, segwit doesn't change the outputs at all, just the inputs with the signature
303 2016-12-16 17:20:28	0|phantomcircuit|or does it and i am just very tired and hungry
304 2016-12-16 17:22:21	0|sdaftuar|phantomcircuit: see BIP 141.  segwit outputs are constructed differently than non-segwit outputs.
305 2016-12-16 17:22:56	0|phantomcircuit|hmm
306 2016-12-16 17:26:17	0|gmaxwell|rebroad: he changed the text, many times. Last I checked the current text was still wrong as heck.
307 2016-12-16 17:28:03	0|phantomcircuit|101...
308 2016-12-16 17:28:05	0|phantomcircuit|ok then
309 2016-12-16 17:29:19	0|phantomcircuit|oh right
310 2016-12-16 17:29:36	0|Victorsueca|101ºC?
311 2016-12-16 17:29:57	0|Victorsueca|;)
312 2016-12-16 17:30:14	0|sipa|phantomcircuit: p2sh witness outputs are indistinguishable to the network from other p2sh outputs
313 2016-12-16 17:30:39	0|sipa|but they are distinguishable to the receiver... who either knows the redeemscript and how to spend it, or not
314 2016-12-16 17:31:19	0|phantomcircuit|sipa, it's the same as p2sh originally right
315 2016-12-16 17:31:46	0|phantomcircuit|and is because of the change to the signature hashing basically meaning it's a "new" script language
316 2016-12-16 17:31:54	0|Victorsueca|basically you can't know whether it is P2SH, P2WSH or P2WPKH until the outputs are redeemed
317 2016-12-16 17:32:34	0|sipa|phantomcircuit: new signature hashing, and it takes inputs from the witness rather than from the scriptSig directly
318 2016-12-16 17:32:44	0|Victorsueca|some extra privacy, that's always good
319 2016-12-16 18:19:54	0|profall|Hello, what is the default rpcworkqueue on 13.1 ?
320 2016-12-16 18:20:04	0|profall|I want to increase it but I have no idea what the starting value is
321 2016-12-16 18:31:17	0|sipa|16
322 2016-12-16 18:31:32	0|profall|Thank You
323 2016-12-16 18:53:01	0|gmaxwell|sipa: So the chainstate reindex without signature verification test with 300MB dbcache completed,  entry-per-txout is ~25% _faster_ than master!
324 2016-12-16 18:56:42	0|sipa|gmaxwell: woah
325 2016-12-16 18:56:53	0|sipa|wasn't only 6% at some point during sync?
326 2016-12-16 19:03:18	0|gmaxwell|I was screwing up the comparison when I was giving you those figures.
327 2016-12-16 19:05:03	0|sipa|wasn't it around the same number for a 2000MB dbcache?
328 2016-12-16 19:05:59	0|sipa|anyway great... more work, now we need to investigate this idea further
329 2016-12-16 19:10:26	0|matrix01|Who can help  to gave me a small amount of BTC or borow me some pm me thx!
330 2016-12-16 19:14:33	0|sipa|matrix01: for experimenting purpose, use a testnet faucet. otherwise: this is not a place for begging
331 2016-12-16 19:27:30	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9371: Notify on removal (06master...06notifyOnRemoval) 02https://github.com/bitcoin/bitcoin/pull/9371
332 2016-12-16 19:38:21	0|gmaxwell|sipa: ~23% for 2000MB, so yes.
333 2016-12-16 19:47:24	0|Lightsword|was the networking code being reworked to use libevent or something similar? or was that just the rpc server stuff?
334 2016-12-16 19:48:24	0|sipa|it's being reworked slowly
335 2016-12-16 19:48:27	0|sipa|but it's not yet using libevent
336 2016-12-16 19:48:45	0|sipa|but having the network code use libevent is indeed a goal
337 2016-12-16 19:52:13	0|Lightsword|is the network refactoring in preparation for that? how close is it to being able to use libevent?
338 2016-12-16 19:52:29	0|sipa|talk to cfields
339 2016-12-16 19:52:37	0|sipa|i expect libevent to happen in 0.15
340 2016-12-16 19:53:30	0|cfields|Lightsword: quite close, up and running locally. Upstreaming in chunks.
341 2016-12-16 20:00:05	0|matrix01|Who can help  to gave me a small amount of BTC or borow me some pm me thx!
342 2016-12-16 20:00:17	0|sipa|matrix01: stop begging. last warning
343 2016-12-16 20:28:35	0|instagibbs|sipa, he's been doing this under various names repeatedly on other channels someone banhammer him
344 2016-12-16 20:32:58	0|bitcoin-git|13bitcoin/06master 14ed58969 15Pieter Wuille: Batch construct batches...
345 2016-12-16 20:32:58	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8c7947e09ff8...b99a093afed8
346 2016-12-16 20:32:59	0|bitcoin-git|13bitcoin/06master 14b99a093 15Pieter Wuille: Merge #9346: Batch construct batches...
347 2016-12-16 20:33:15	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9346: Batch construct batches (06master...06reusebatch) 02https://github.com/bitcoin/bitcoin/pull/9346
348 2016-12-16 21:27:26	0|gmaxwell|https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-12-16&to=2016-12-16&type=c  < anyone know why this doesn't list 2/3rds of the people who have contributed?
349 2016-12-16 21:28:39	0|achow101|date range is wrong?
350 2016-12-16 21:31:10	0|gmaxwell|Hm? git log --no-merges shows commits from ~150 contributors (some name dupes) from 2015-12-16 to now.
351 2016-12-16 21:33:36	0|arubi|replacing 'type=c' with a mock 'type=none' lists 100 people
352 2016-12-16 21:37:18	0|achow101|maybe some of the authors don't have their emails registered with github so they aren't shown?
353 2016-12-16 21:40:17	0|achow101|they might also be counting committers and not authors
354 2016-12-16 21:42:20	0|gmaxwell|achow101: nope, far too many.
355 2016-12-16 21:42:40	0|gmaxwell|achow101: e.g. you're listed.
356 2016-12-16 21:43:07	0|btcdrak|sounds like we need to report this to github, their data processing appears to be bugged
357 2016-12-16 21:43:38	0|achow101|well I made commits. there are some commits that are like "X committed with Y" so they might be counting that commit as made by Y and not X
358 2016-12-16 21:44:03	0|gmaxwell|achow101: yea, no-- not that either.
359 2016-12-16 21:44:18	0|gmaxwell|there are people not listed that made PRs and had them merged.
360 2016-12-16 21:46:25	0|Chris_Stewart_5|gmaxwell: I've noticed this with other repos, such as bitcoin-dot-org -- here is a pull request I had merged https://github.com/bitcoin-dot-org/bitcoin.org/pull/1333
361 2016-12-16 21:46:40	0|Chris_Stewart_5|but I'm not on the contributors list :/ not sure why
362 2016-12-16 21:49:05	0|achow101|gmaxwell: are you sure? even though they opened PRs, some of them have the committer name as someone else or committed on GitHub
363 2016-12-16 21:49:53	0|gmaxwell|achow101: https://github.com/bitcoin/bitcoin/pull/6842 take that one for example.
364 2016-12-16 21:50:15	0|achow101|that commit is out of your time range
365 2016-12-16 21:53:06	0|gmaxwell|achow101: ah it's merge isn't. Lemme find another.
366 2016-12-16 21:57:35	0|gmaxwell|https://github.com/bitcoin/bitcoin/commit/8c1dbc5e9ddbafb77e60e8c4e6eb275a3a76ac12 < how about that?
367 2016-12-16 21:58:11	0|achow101|no registered email with github
368 2016-12-16 22:00:06	0|gmaxwell|okay, lemme try another!
369 2016-12-16 22:01:09	0|gmaxwell|yea, that might be it.
370 2016-12-16 22:02:13	0|achow101|gmaxwell: here's an example of a commit I was talking about: https://github.com/bitcoin/bitcoin/commit/203e2ddad8e544803491d1e9e9ca2b6e26a15f8e
371 2016-12-16 22:02:21	0|achow101|laudaa is not even in the contributors list at all
372 2016-12-16 23:06:20	0|sipa|morcos: any reason why ApplyTxInUndo can't use ModifyNewCoins?
373 2016-12-16 23:33:35	0|morcos|sipa: you mean for the case where it's the last spend (undo.nHeight != 0)?  I'm not sure I see how it would be any nicer..
374 2016-12-16 23:36:34	0|sipa|morcos: right, i was working on my per-txout branch... where it would apply for every spend
375 2016-12-16 23:36:52	0|sipa|i mean: would it be safe to use?
376 2016-12-16 23:37:00	0|morcos|heh, well then its a bit of a different question..
377 2016-12-16 23:38:16	0|morcos|i'd have to think about exactly how it works in a per-txout world..  but it seems like it should be.
378 2016-12-16 23:39:04	0|sipa|assuming your database is not corrupted, the undo data is trusted
379 2016-12-16 23:39:27	0|sipa|which means that you are certain that it (semantically speaking, from the chain point of view) is never overwriting anything
380 2016-12-16 23:47:28	0|morcos|yep, and at least after #9107 ModifyNewCoins asserts that that is the case
381 2016-12-16 23:47:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub