1 2016-12-16T00:04:27  *** wasi has joined #bitcoin-core-dev
  2 2016-12-16T00:07:37  *** Chris_Stewart_5 has quit IRC
  3 2016-12-16T00:10:09  <bitcoin-git> [bitcoin] funbucks opened pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
  4 2016-12-16T00:18:40  *** PRab_ has quit IRC
  5 2016-12-16T00:18:41  *** PRab has quit IRC
  6 2016-12-16T00:19:25  *** PRab has joined #bitcoin-core-dev
  7 2016-12-16T00:42:12  <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)
  8 2016-12-16T00:46:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  9 2016-12-16T00:54:03  <bitcoin-git> [bitcoin] theuni closed pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
 10 2016-12-16T01:23:09  <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?
 11 2016-12-16T01:28:04  <sipa> the CVarInt in serialize.h is a bitcoin core internal thing, only used for the utxo database and undo data
 12 2016-12-16T01:28:14  <sipa> and it doesn't appear anywhere in the p2p protocol
 13 2016-12-16T01:28:34  <sipa> CompactSize is the varint type used in the p2p protocol for vector sizes etc
 14 2016-12-16T01:30:29  <sipa> and yes, it's confusing...
 15 2016-12-16T01:30:38  <sipa> historical reasons :)
 16 2016-12-16T01:33:21  <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.
 17 2016-12-16T01:33:30  *** Chris_Stewart_5 has quit IRC
 18 2016-12-16T01:49:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 19 2016-12-16T02:17:22  *** Ylbam has quit IRC
 20 2016-12-16T02:21:28  *** jtimon has quit IRC
 21 2016-12-16T02:23:12  <Chris_Stewart_5> What is the criteria for setting the default dbcache value? Does a BIP have to be proposed to change it?
 22 2016-12-16T02:24:41  <sipa> no
 23 2016-12-16T02:24:53  <sipa> it doesn't affect the network in any way
 24 2016-12-16T02:25:05  <sipa> only your own memory/cpu tradeoff
 25 2016-12-16T02:27:32  <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)
 26 2016-12-16T02:27:58  <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.
 27 2016-12-16T02:27:59  <sipa> sure, but it doesn't need any consideration ahead of time
 28 2016-12-16T02:28:11  <sipa> we can just occasionally change defaults to keep up with technology trends
 29 2016-12-16T02:28:48  <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
 30 2016-12-16T02:29:03  <sipa> it's harder to do that in bitcoind, which we exapct to run on low-power devices too
 31 2016-12-16T02:29:05  <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
 32 2016-12-16T02:29:35  <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.
 33 2016-12-16T02:29:42  <gmaxwell> It isn't something where "interoperability" is required.
 34 2016-12-16T02:30:20  <sipa> BIP42 suggests that the currency symbol color should be considered
 35 2016-12-16T02:31:10  *** alpalp has quit IRC
 36 2016-12-16T02:33:51  <Chris_Stewart_5> sipa: That is interesting. I kind of like that idea wrt to reading mem and just setting it off of that.
 37 2016-12-16T02:34:23  <sipa> what idea?
 38 2016-12-16T02:34:37  <Chris_Stewart_5> your comment wrt to bitcoin-qt
 39 2016-12-16T02:34:45  <sipa> Chris_Stewart_5: not only does not affect consensus - it doesn't affect anything
 40 2016-12-16T02:35:01  <sipa> BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
 41 2016-12-16T02:35:16  <gmaxwell> Chris_Stewart_5: it would be a wrong assumption to assume the user wants all their memory used by bitcoin. :(
 42 2016-12-16T02:35:48  <Chris_Stewart_5> gmaxwell: absurd! :P
 43 2016-12-16T02:37:05  <gmaxwell> we could certantly reduce it based on the amount of free memory!
 44 2016-12-16T02:37:08  <Chris_Stewart_5> ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
 45 2016-12-16T02:39:52  *** alpalp has joined #bitcoin-core-dev
 46 2016-12-16T02:42:48  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9359: Fix CWalletTx::GetImmatureCredit() returning stale values. (master...pr/immature) https://github.com/bitcoin/bitcoin/pull/9359
 47 2016-12-16T02:42:51  <Chris_Stewart_5> sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
 48 2016-12-16T02:46:37  *** alpalp has quit IRC
 49 2016-12-16T02:47:55  *** alpalp has joined #bitcoin-core-dev
 50 2016-12-16T02:58:26  *** abpa has joined #bitcoin-core-dev
 51 2016-12-16T03:05:53  *** NielsvG has quit IRC
 52 2016-12-16T03:09:18  *** NielsvG has joined #bitcoin-core-dev
 53 2016-12-16T03:09:18  *** NielsvG has joined #bitcoin-core-dev
 54 2016-12-16T03:16:06  *** Alopex has quit IRC
 55 2016-12-16T03:17:12  *** Alopex has joined #bitcoin-core-dev
 56 2016-12-16T03:21:25  *** Kexkey has joined #bitcoin-core-dev
 57 2016-12-16T03:27:11  *** amiller has quit IRC
 58 2016-12-16T03:29:11  *** To7 has quit IRC
 59 2016-12-16T03:35:06  *** Alopex has quit IRC
 60 2016-12-16T03:36:11  *** Alopex has joined #bitcoin-core-dev
 61 2016-12-16T03:48:01  *** Alopex has quit IRC
 62 2016-12-16T03:49:06  *** Alopex has joined #bitcoin-core-dev
 63 2016-12-16T03:49:51  *** Atomicat_ has joined #bitcoin-core-dev
 64 2016-12-16T03:52:42  *** Atomicat has quit IRC
 65 2016-12-16T03:52:43  *** Atomicat_ is now known as Atomicat
 66 2016-12-16T03:53:28  *** Victor_sueca has joined #bitcoin-core-dev
 67 2016-12-16T03:55:40  *** Victorsueca has quit IRC
 68 2016-12-16T03:56:07  *** Kexkey has quit IRC
 69 2016-12-16T04:00:01  *** Alopex has quit IRC
 70 2016-12-16T04:01:06  *** Alopex has joined #bitcoin-core-dev
 71 2016-12-16T04:06:02  *** alpalp has quit IRC
 72 2016-12-16T04:10:04  *** MurhS0xFF has joined #bitcoin-core-dev
 73 2016-12-16T04:19:29  *** Chris_Stewart_5 has quit IRC
 74 2016-12-16T04:20:42  *** Victor_sueca has quit IRC
 75 2016-12-16T04:33:39  *** chris200_ has joined #bitcoin-core-dev
 76 2016-12-16T04:37:13  *** chris2000 has quit IRC
 77 2016-12-16T04:52:58  *** abpa has quit IRC
 78 2016-12-16T05:02:43  *** Giszmo has quit IRC
 79 2016-12-16T05:22:55  *** To7 has joined #bitcoin-core-dev
 80 2016-12-16T05:26:31  *** MurhS0xFF has quit IRC
 81 2016-12-16T06:00:49  *** justan0theruser has joined #bitcoin-core-dev
 82 2016-12-16T06:03:48  *** justanotheruser has quit IRC
 83 2016-12-16T06:20:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 84 2016-12-16T06:21:13  *** kadoban has quit IRC
 85 2016-12-16T06:50:10  *** [Author] has quit IRC
 86 2016-12-16T06:50:33  *** [Author] has joined #bitcoin-core-dev
 87 2016-12-16T06:51:04  *** Ylbam has joined #bitcoin-core-dev
 88 2016-12-16T07:19:39  *** wvr has quit IRC
 89 2016-12-16T07:30:51  *** jtimon has joined #bitcoin-core-dev
 90 2016-12-16T07:48:57  *** btcdrak has quit IRC
 91 2016-12-16T08:08:08  <gmaxwell> I currently have a node running 8695, 8808, 9039, 9045, 9125, 9138, and 9199 ... surprisingly all applied without conflict.
 92 2016-12-16T08:08:25  *** btcdrak has joined #bitcoin-core-dev
 93 2016-12-16T08:15:58  *** cannon-c has joined #bitcoin-core-dev
 94 2016-12-16T08:16:31  <NicolasDorier> When I do "fundrawtransaction" followed by a "getnewaddress" I noticed the generated address and the change of funrawtransaction are the same
 95 2016-12-16T08:16:37  <NicolasDorier> is it on purpose ?
 96 2016-12-16T08:17:09  <NicolasDorier> it is like funrawtransaction does not increment the index for generating the next address
 97 2016-12-16T08:17:44  <NicolasDorier> I can do a getnewaddress manually after FundRawTransaction, but first I would like if it is on purpose
 98 2016-12-16T08:19:36  <bitcoin-git> [bitcoin] kallewoof opened pull request #9361: Fix: OSX compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
 99 2016-12-16T08:22:34  <jonasschnelli> NicolasDorier: thats right. Fundrawtransaction does not keep the reserve key.
100 2016-12-16T08:23:20  <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
101 2016-12-16T08:23:28  <jonasschnelli> NicolasDorier: what you can and should do is call getrawchangeaddress and use this with fundrawtransaction (you can specify a change address there)
102 2016-12-16T08:23:33  <NicolasDorier> ah
103 2016-12-16T08:23:35  <NicolasDorier> yes
104 2016-12-16T08:23:39  <NicolasDorier> will do that thanks
105 2016-12-16T08:23:40  <jonasschnelli> NicolasDorier: yes. We should do that-.
106 2016-12-16T08:23:49  <jonasschnelli> It feels llike a serious bug
107 2016-12-16T08:23:52  <jonasschnelli> I'm opening an issue
108 2016-12-16T08:23:56  <NicolasDorier> thanks
109 2016-12-16T08:32:25  *** amiller_ has joined #bitcoin-core-dev
110 2016-12-16T08:33:54  *** paveljanik has quit IRC
111 2016-12-16T08:34:54  *** Alina-malina has quit IRC
112 2016-12-16T08:42:42  *** tunafizz has quit IRC
113 2016-12-16T08:43:26  *** tunafizz has joined #bitcoin-core-dev
114 2016-12-16T08:44:14  *** Alina-malina has joined #bitcoin-core-dev
115 2016-12-16T09:15:49  *** tunafizz has quit IRC
116 2016-12-16T09:16:52  *** tunafizz has joined #bitcoin-core-dev
117 2016-12-16T09:19:10  <bitcoin-git> [bitcoin] rebroad opened pull request #9363: Don't provide blocktxns for old blocks on a fork. (master...MinChainWorkBlocktxns) https://github.com/bitcoin/bitcoin/pull/9363
118 2016-12-16T09:20:50  *** rebroad has joined #bitcoin-core-dev
119 2016-12-16T09:32:10  <gmaxwell> rebroad: you know you can run all the tests that travis runs locally?
120 2016-12-16T09:36:13  <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.
121 2016-12-16T09:37:16  <rebroad> and anyway, "make check" is failing on my system... I raised an issue for it.
122 2016-12-16T09:38:45  <rebroad> gmaxwell, what prompted you to mention the travis tests?
123 2016-12-16T09:40:11  <rebroad> (well, 9 times out of 10 - re "make check")
124 2016-12-16T09:40:16  <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).
125 2016-12-16T09:41:47  *** LeMiner has joined #bitcoin-core-dev
126 2016-12-16T09:41:49  <rebroad> gmaxwell, how do I run them locally please? (I am re-reading the docs now, but have not seen this info as yet)
127 2016-12-16T09:42:38  <rebroad> my latest PR seems to have works all except for fundwartransaction.py (https://travis-ci.org/bitcoin/bitcoin/jobs/184479440)
128 2016-12-16T09:42:48  <rebroad> and that failed only on 1 of the 6 platforms
129 2016-12-16T09:43:18  <rebroad> I'm assuming if I run the tests locally it only tests my own platform
130 2016-12-16T09:43:30  <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
131 2016-12-16T09:43:36  <gmaxwell> vent fingerprinting" in net_processing.cpp.
132 2016-12-16T09:46:01  <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
133 2016-12-16T09:46:22  <rebroad> it also checks if it is in the activechain - it doesn't do this for getblocktxns
134 2016-12-16T09:46:42  <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
135 2016-12-16T09:46:46  <rebroad> for getblocktxns (from what I can tell) it checks if the height it within a certain height - a height comparison
136 2016-12-16T09:47:49  <rebroad> gmaxwell, thanks (re rpc-tests.py) runnnig it now.. somewhat obscure command which I would not have tried unless told
137 2016-12-16T09:47:59  <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.
138 2016-12-16T09:48:36  <wumpus> rebroad: https://github.com/bitcoin/bitcoin/tree/master/qa on running qa tests locally
139 2016-12-16T09:49:12  <wumpus> (this is all linked from the main README.md, you should have no problem finding this documentation if you bothered looking even casually)
140 2016-12-16T09:53:04  <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
141 2016-12-16T09:53:20  <rebroad> wumpus, I see the section now - yes, it is there - not sure how I missed it last time
142 2016-12-16T09:56:18  <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
143 2016-12-16T09:56:37  <jonasschnelli> Also, rebroad: you can setup travis for your own development branch
144 2016-12-16T09:56:48  <jonasschnelli> (in case you open PRs to have them run though travis)
145 2016-12-16T09:56:59  <wumpus> it was there for a long time, has been updated a few times
146 2016-12-16T09:57:05  <rebroad> jonasschnelli, that would be very useful indeed. thanks
147 2016-12-16T09:57:18  <jonasschnelli> Just head to http://travis-ci.org
148 2016-12-16T09:57:25  <wumpus> and yes you're supposed to keep up to date with the (extrememly minimal) development documentation if you do development
149 2016-12-16T09:57:27  <jonasschnelli> and enable you rebroad/bitcoin repo
150 2016-12-16T10:01:21  <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
151 2016-12-16T10:01:45  <jonasschnelli> understand travises interface?
152 2016-12-16T10:01:59  <wumpus> travis, too, has documentation
153 2016-12-16T10:02:30  *** Guyver2 has joined #bitcoin-core-dev
154 2016-12-16T10:03:57  <wumpus> it looks like the fundrawtransaction.py test is flaky at the moment
155 2016-12-16T10:05:40  <rebroad> running the extended tests locally fundrawtransaction.py passed, but walletbackup.py failed!
156 2016-12-16T10:05:43  <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.
157 2016-12-16T10:05:52  <rebroad> my one line change doesn't touch things that either of those tests test
158 2016-12-16T10:06:43  <wumpus> jonasschnelli: interesting - it's supposed to update the change address when it is actually used
159 2016-12-16T10:07:02  <wumpus> jonasschnelli: apparently that logic doesn't work
160 2016-12-16T10:07:13  <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.
161 2016-12-16T10:07:46  <rebroad> gmaxwell, by making that assumption it would respond to requests for any block of that height, whether on the active chain or not
162 2016-12-16T10:07:59  <rebroad> (at least, this is my understanding from the code)
163 2016-12-16T10:09:24  <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)
164 2016-12-16T10:10:18  <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
165 2016-12-16T10:11:19  <rebroad> my understanding is that as compact blocks relys on the memory pool, that old blocks on any chain are unnecessary
166 2016-12-16T10:11:24  <wumpus> yes this is intentional, it avoids fingerprinting attacks
167 2016-12-16T10:11:42  <rebroad> wumpus, it would allow fingerprint attacks, not avoid them
168 2016-12-16T10:11:56  <wumpus> peers could fingerprint nodes based on what alt-chains they own - this is avoided now
169 2016-12-16T10:12:22  <rebroad> wumpus, which PR are you referring to?
170 2016-12-16T10:12:45  <rebroad> wumpus, my PR is a change that avoids fingerprinting. the current master allows it
171 2016-12-16T10:12:47  <wumpus> I'm not refering to a PR, but to the reason that access is not allowed to old blocks on alt chains
172 2016-12-16T10:13:00  <rebroad> wumpus, my PR stops access to old blocks on alt chains
173 2016-12-16T10:13:12  <rebroad> in order to stop fingerprinting
174 2016-12-16T10:13:21  *** Alina-malina has quit IRC
175 2016-12-16T10:13:21  *** Alina-malina has joined #bitcoin-core-dev
176 2016-12-16T10:13:56  <wumpus> anyhow I can't reproduce the fundrawtransaction problem locally either
177 2016-12-16T10:14:06  <rebroad> #9363
178 2016-12-16T10:14:08  <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.
179 2016-12-16T10:14:29  *** jannes has joined #bitcoin-core-dev
180 2016-12-16T10:15:58  <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
181 2016-12-16T10:16:12  <rebroad> then once that is done, a getblocktxn request would reveal the fingerprint
182 2016-12-16T10:16:36  <rebroad> I have not tested this can be done, but from reading the code I believe it could
183 2016-12-16T10:17:47  <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
184 2016-12-16T10:18:20  *** murchandamus has quit IRC
185 2016-12-16T10:19:09  <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
186 2016-12-16T10:20:09  <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?
187 2016-12-16T10:20:19  <wumpus> why are you working on that at all, then?
188 2016-12-16T10:20:39  <rebroad> I don't claim to know anything as Aristotle once said
189 2016-12-16T10:20:48  <rebroad> I can go only on assumptions therefore
190 2016-12-16T10:20:54  <wumpus> I just don't understand your motivation
191 2016-12-16T10:21:18  <rebroad> wumpus, to help. what is your motivation?
192 2016-12-16T10:21:22  <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
193 2016-12-16T10:21:30  <wumpus> for which change?
194 2016-12-16T10:21:43  <rebroad> wumpus, for the project i mean
195 2016-12-16T10:21:57  <wumpus> that's off topic here and certainly not something I want to get into
196 2016-12-16T10:22:18  <rebroad> sorry, I answered assuming you were referring to the project, not the PR
197 2016-12-16T10:22:46  <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
198 2016-12-16T10:23:32  <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
199 2016-12-16T10:23:48  <rebroad> I mean understand not appreciate
200 2016-12-16T10:24:32  <rebroad> anyway, if I was wrong, and it's not important. I will close the PR
201 2016-12-16T10:25:01  <rebroad> but it does make me question why it was important for blocks but not blocktxns
202 2016-12-16T10:25:10  <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
203 2016-12-16T10:25:36  <rebroad> wumpus, ok, I will get to work on that.. but before I do.. can anyone explain to me why fingerprinting attacks are bad?
204 2016-12-16T10:25:40  <wumpus> if you don't, then don't waste your time
205 2016-12-16T10:25:49  <rebroad> wumpus, because if they are not that bad, then it's a lot of effort for something trivial
206 2016-12-16T10:26:03  <wumpus> if you don't think they are bad then donj't spend effort on it!
207 2016-12-16T10:26:10  <rebroad> wumpus, lol.. ok
208 2016-12-16T10:26:16  <wumpus> why do you need to be hand-held through every little thing
209 2016-12-16T10:26:39  <rebroad> wumpus, it takes two to hold hands
210 2016-12-16T10:27:22  <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.
211 2016-12-16T10:27:32  <rebroad> wumpus, I mean that we both needed to understand each other to work out the way forward
212 2016-12-16T10:27:59  <rebroad> wumpus, ah... thanks. i understand now in that context. thank you for explaining
213 2016-12-16T10:28:06  <wumpus> if you can distinguish and thus identify peers sending you a transaction you gain information you shouldn't have
214 2016-12-16T10:28:21  <wumpus> if you don't care about that, then well, don't
215 2016-12-16T10:28:45  <rebroad> wumpus, based on that explanation, I shall work on creating that test you asked for
216 2016-12-16T10:28:53  <wumpus> okay thanks
217 2016-12-16T10:29:17  *** JackH has joined #bitcoin-core-dev
218 2016-12-16T10:31:26  <wumpus> so fundrawtransaction.py test very regularly fails on travis with "Assertion failed: Mempool sync failed"
219 2016-12-16T10:31:33  <wumpus> but I can't reproduce this locally
220 2016-12-16T10:32:12  <luke-jr> timing maybe?
221 2016-12-16T10:32:44  <wumpus> some recent change must have triggered it, it was not the case before
222 2016-12-16T10:33:07  <jonasschnelli> wumpus: fundrawtx should not keep the CReserveKey, sendrawtx could, but what solutions do we offer for users broadcastign over different channels...
223 2016-12-16T10:33:15  <jonasschnelli> Maybe we should add a call
224 2016-12-16T10:33:29  <jonasschnelli> to reserve the used change key of a funded raw tx
225 2016-12-16T10:33:43  <jonasschnelli> or to reserve a key by a specific address
226 2016-12-16T10:33:51  <jonasschnelli> (and release)
227 2016-12-16T10:33:52  <wumpus> jonasschnelli: well for broadcasting over separate channels we can't offer automatic change address functionality
228 2016-12-16T10:34:30  <wumpus> jonasschnelli: unless there would be a way to tell the wallet of a transaction without broadcasting it
229 2016-12-16T10:34:44  <jonasschnelli> ah,.. right.
230 2016-12-16T10:35:12  <wumpus> right now the only way to tell the wallet is sendrawtransaction, which always broadcasts (walletbroadcast=0 setting won't help you there)
231 2016-12-16T10:35:24  <jonasschnelli> I guess we should add detecting the change key in sendrawtx and make sure we reserve it from the keypool
232 2016-12-16T10:35:52  *** laurentmt has joined #bitcoin-core-dev
233 2016-12-16T10:36:11  <wumpus> either that or indeed it should be an explicit step to reserve a change address, which should be returned if not used
234 2016-12-16T10:36:37  <wumpus> this was overlooked in the fundrawtransaction design
235 2016-12-16T10:38:17  <wumpus> fundrawtransaction doesn't even consistently fail in the same place (!)
236 2016-12-16T10:38:30  <wumpus> I mean the test
237 2016-12-16T10:38:46  *** murchandamus has joined #bitcoin-core-dev
238 2016-12-16T10:39:03  <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184431201 it's the sync_all on line 534 that fails
239 2016-12-16T10:39:14  <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184473580 it's the one on line 461
240 2016-12-16T10:40:21  <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184333528 it's line 449
241 2016-12-16T10:40:40  <wumpus> the only commonality is that the fundrawtransaction.py test fails, and it happens while syncing mempools
242 2016-12-16T10:41:16  *** laurentmt has quit IRC
243 2016-12-16T10:44:08  *** murchandamus has quit IRC
244 2016-12-16T10:46:40  *** rebroad_ has joined #bitcoin-core-dev
245 2016-12-16T10:50:13  *** rebroad has quit IRC
246 2016-12-16T10:50:25  *** murchandamus has joined #bitcoin-core-dev
247 2016-12-16T10:52:17  *** murchandamus has quit IRC
248 2016-12-16T10:54:13  <bitcoin-git> [bitcoin] laanwj opened pull request #9365: [testing] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
249 2016-12-16T10:54:30  *** murchandamus has joined #bitcoin-core-dev
250 2016-12-16T10:55:11  *** murchandamus has quit IRC
251 2016-12-16T10:57:36  *** murchandamus has joined #bitcoin-core-dev
252 2016-12-16T10:58:27  *** rebroad_ has quit IRC
253 2016-12-16T10:59:18  *** murchandamus has quit IRC
254 2016-12-16T10:59:53  *** MarcoFalke has joined #bitcoin-core-dev
255 2016-12-16T11:00:13  <MarcoFalke> wumpus: The cause of test failure is most likely already known
256 2016-12-16T11:00:53  <wumpus> MarcoFalke: what then?
257 2016-12-16T11:01:20  <MarcoFalke> (see scrollback of yesterday evening)
258 2016-12-16T11:01:28  <MarcoFalke> Might be some rounding in fee filter
259 2016-12-16T11:01:48  <MarcoFalke> at the floor (i.e. minrelayfee)
260 2016-12-16T11:02:15  <wumpus> can we work around this quicky to make travis pass again for unrelated pulls?
261 2016-12-16T11:02:51  <MarcoFalke> Sure, I can try to settxfee in fundrawtx.py
262 2016-12-16T11:03:14  <wumpus> reverting #9313 should help, then?
263 2016-12-16T11:03:16  <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.
264 2016-12-16T11:04:03  <wumpus> it started yesterday and the only pull merged yesterday affecting fees/feefilters is that one
265 2016-12-16T11:04:03  <MarcoFalke> Yes, would help.
266 2016-12-16T11:04:32  <MarcoFalke> But I'd like to get it in in another form then
267 2016-12-16T11:05:03  <wumpus> well we need a temporary workaround to make travis sane agian, we can always merge it again once this issue is solved
268 2016-12-16T11:05:40  <MarcoFalke> ok, fine w/ me
269 2016-12-16T11:05:43  <wumpus> anyhow going to try in #9365
270 2016-12-16T11:05:45  <gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
271 2016-12-16T11:06:20  *** murchandamus has joined #bitcoin-core-dev
272 2016-12-16T11:06:35  *** murchandamus has quit IRC
273 2016-12-16T11:06:50  <wumpus> if travis will consistently pass with that reverted, I'm going to revert it on master too
274 2016-12-16T11:07:26  <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
275 2016-12-16T11:08:15  <wumpus> btw can anyone else get results from seed.bitcoin.sipa.be? it's been giving me nothing for something like two weeks now
276 2016-12-16T11:08:38  <wumpus> but I've heard no one else compain about it
277 2016-12-16T11:10:54  *** rebroad_ has joined #bitcoin-core-dev
278 2016-12-16T11:12:48  <jonasschnelli> wumpus: we have a bug in the seeder somewhere...
279 2016-12-16T11:12:52  <jonasschnelli> I couldn't track it down.
280 2016-12-16T11:12:53  *** murchandamus has joined #bitcoin-core-dev
281 2016-12-16T11:13:09  <jonasschnelli> Seems to be introduced with the filtering option
282 2016-12-16T11:13:17  *** Victorsueca has joined #bitcoin-core-dev
283 2016-12-16T11:13:27  <wumpus> jonasschnelli: okay - yes your testnet seed fails too
284 2016-12-16T11:13:30  <jonasschnelli> Must be something with the cache... seeder is running but not results empty responses.
285 2016-12-16T11:13:40  <jonasschnelli> (need to attach the debugger)
286 2016-12-16T11:13:54  <jonasschnelli> But my long term plan is, to split the seeder in a crawler and a server
287 2016-12-16T11:14:02  <jonasschnelli> As server, I'd like to use djbdns
288 2016-12-16T11:14:10  <jonasschnelli> Shouldn't be that hard.
289 2016-12-16T11:15:10  <wumpus> so it never returns results, or starts returning nothing after a while?
290 2016-12-16T11:16:08  <wumpus> gah my dummy commit passed travis. Stupid heODODisenbug :)
291 2016-12-16T11:16:20  <wumpus> heisenbug*
292 2016-12-16T11:19:12  <btcdrak> wumpus: I also get no results from the seed, and I have complained about it on occasion
293 2016-12-16T11:21:44  <MarcoFalke> wumpus: It should fail at most 25% of the time
294 2016-12-16T11:24:47  *** murchandamus has quit IRC
295 2016-12-16T11:25:59  *** murchandamus has joined #bitcoin-core-dev
296 2016-12-16T11:27:40  <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?
297 2016-12-16T11:28:16  *** Victorsueca has quit IRC
298 2016-12-16T11:28:16  *** murchandamus has quit IRC
299 2016-12-16T11:29:23  *** Victorsueca has joined #bitcoin-core-dev
300 2016-12-16T11:41:20  <wumpus> btcdrak: okay, hadn't noticed then
301 2016-12-16T11:41:49  <wumpus> MarcoFalke: that seems true on travis - but I'm running it locally in a loop, has run ~100 times or so, no failures
302 2016-12-16T11:42:00  *** murchandamus has joined #bitcoin-core-dev
303 2016-12-16T11:42:34  <wumpus> in any case #9365 seems to be consistently passing with #9313 reverted
304 2016-12-16T11:42:36  <gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
305 2016-12-16T11:42:37  <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.
306 2016-12-16T11:43:27  <MarcoFalke> That is odd. I can no longer reproduce either. I surely saw it yesterday
307 2016-12-16T11:44:21  <MarcoFalke> Nah, just failed
308 2016-12-16T11:48:35  *** AaronvanW has quit IRC
309 2016-12-16T11:49:52  <MarcoFalke> rebroad_: qa/rpc-tests/p2p-compactblocks.py
310 2016-12-16T11:52:37  *** cannon-c has quit IRC
311 2016-12-16T11:52:44  <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
312 2016-12-16T11:53:09  <rebroad_> MarcoFalke, thanks though
313 2016-12-16T11:53:44  <rebroad_> these python tests are new territory for me.. so a bit of a learning curve..
314 2016-12-16T11:54:40  <rebroad_> my goodness the pruning test seems to take a while to run...
315 2016-12-16T12:02:12  *** rebroad_ has quit IRC
316 2016-12-16T12:10:00  *** AaronvanW has joined #bitcoin-core-dev
317 2016-12-16T12:23:14  <bitcoin-git> [bitcoin] kallewoof closed pull request #9361: [WIP] Fix: OSX QT compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
318 2016-12-16T12:25:43  <bitcoin-git> [bitcoin] kallewoof opened pull request #9366: Fix: OSX QT compile: use built-in swap if available, or defer (master...macosx-qt-build-fix2) https://github.com/bitcoin/bitcoin/pull/9366
319 2016-12-16T12:28:21  *** e4xit has quit IRC
320 2016-12-16T12:30:18  *** e4xit has joined #bitcoin-core-dev
321 2016-12-16T12:30:48  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
322 2016-12-16T12:44:03  *** Atomicat_ has joined #bitcoin-core-dev
323 2016-12-16T12:45:37  *** Atomicat has quit IRC
324 2016-12-16T12:45:45  *** Atomicat_ is now known as Atomicat
325 2016-12-16T12:50:21  *** rebroad_ has joined #bitcoin-core-dev
326 2016-12-16T13:11:48  <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.
327 2016-12-16T13:17:16  *** rebroad_ has quit IRC
328 2016-12-16T13:23:21  <phantomcircuit> wumpus, can you tell me about commit e8ef3da7 ?
329 2016-12-16T13:23:23  <phantomcircuit> it's from 2011 so im not expecting much
330 2016-12-16T13:23:35  <phantomcircuit> commit message is just "update core to d0d80170a2ca73004e08fb85007fe055cbf4e411 (CWallet class)"
331 2016-12-16T13:25:51  <phantomcircuit> nvm i see i should actually be asking sipa maybe?
332 2016-12-16T13:26:09  <phantomcircuit> nvm i see i should be asking s_nakamoto
333 2016-12-16T13:26:11  <phantomcircuit> :/
334 2016-12-16T13:45:43  *** jtimon has quit IRC
335 2016-12-16T13:49:45  *** rebroad has joined #bitcoin-core-dev
336 2016-12-16T13:50:16  <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?
337 2016-12-16T13:50:32  *** MarcoFalke has left #bitcoin-core-dev
338 2016-12-16T13:54:02  <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
339 2016-12-16T13:54:33  *** laurentmt has joined #bitcoin-core-dev
340 2016-12-16T13:54:38  *** laurentmt has quit IRC
341 2016-12-16T13:56:23  *** Giszmo has joined #bitcoin-core-dev
342 2016-12-16T13:57:18  <rebroad> instagibbs, ah. yes, makes sense. thanks.
343 2016-12-16T14:02:45  *** MarcoFalke has joined #bitcoin-core-dev
344 2016-12-16T14:03:05  <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
345 2016-12-16T14:04:40  *** MarcoFalke has left #bitcoin-core-dev
346 2016-12-16T14:09:52  <bitcoin-git> [bitcoin] s-matthew-english opened pull request #9368: change to declarative sentences. simplify links (master...patch-13) https://github.com/bitcoin/bitcoin/pull/9368
347 2016-12-16T14:18:52  <phantomcircuit> instagibbs, uh do you even need a segwit compatible wallet to spend segwit outputs?
348 2016-12-16T14:18:55  <phantomcircuit> i didn't think you did
349 2016-12-16T14:19:56  <phantomcircuit> i don't think you do actually
350 2016-12-16T14:20:01  <Chris_Stewart_5> phantomcircuit: Pretty sure you do, you won't be able to construct the tx in the proper structure without it
351 2016-12-16T14:20:02  <phantomcircuit> the utxo entries aren't changes
352 2016-12-16T14:20:13  <phantomcircuit> changed*
353 2016-12-16T14:20:38  <phantomcircuit> you'd have to know that there is a transaction output in the utxo to begin with
354 2016-12-16T14:20:53  <phantomcircuit> but if you have someone providing you transactions with the signatures stripped in normal format
355 2016-12-16T14:20:56  <Chris_Stewart_5> segwit P2WPKH outputs require a empty script sig, and P2WSH requires a push only scriptSig of 32 bytes i think
356 2016-12-16T14:21:07  <phantomcircuit> ok?
357 2016-12-16T14:21:07  <phantomcircuit> so
358 2016-12-16T14:21:41  <phantomcircuit> you're talking about inputs not outputs
359 2016-12-16T14:21:47  <phantomcircuit> which is what the person spending cares about
360 2016-12-16T14:22:02  <phantomcircuit> i mean maybe it's not easy to do
361 2016-12-16T14:22:08  <phantomcircuit> but you certainly should be able to
362 2016-12-16T14:22:43  <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?
363 2016-12-16T14:23:43  <phantomcircuit> Chris_Stewart_5, why would they care about the inputs to a transaction they're spending the outputs of?
364 2016-12-16T14:26:15  <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?
365 2016-12-16T14:33:34  <rebroad> phantomcircuit, if you have a non-segwit wallet, then you can spend any SegWit transaction... but it will never get mined :)
366 2016-12-16T14:34:05  <rebroad> well, it could get mined by the 5% still on the non-segwit fork.. but would soon get orphaned
367 2016-12-16T14:58:09  *** timothy has quit IRC
368 2016-12-16T14:58:49  *** timothy has joined #bitcoin-core-dev
369 2016-12-16T15:06:55  *** laurentmt has joined #bitcoin-core-dev
370 2016-12-16T15:07:11  *** laurentmt has quit IRC
371 2016-12-16T15:10:00  <phantomcircuit> rebroad, why?
372 2016-12-16T15:10:22  <phantomcircuit> the scriptPubKey is the same right?
373 2016-12-16T15:10:26  <phantomcircuit> wait maybe it's not
374 2016-12-16T15:10:27  <phantomcircuit> hmm
375 2016-12-16T15:11:03  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9369: Factor out CWallet::nTimeSmart computation into a method. (master...pr/atw-timesmart) https://github.com/bitcoin/bitcoin/pull/9369
376 2016-12-16T15:16:57  *** rebroad has quit IRC
377 2016-12-16T15:17:57  *** windsok has quit IRC
378 2016-12-16T15:20:28  *** Chris_Stewart_5 has quit IRC
379 2016-12-16T15:20:59  *** jtimon has joined #bitcoin-core-dev
380 2016-12-16T15:32:51  *** laurentmt has joined #bitcoin-core-dev
381 2016-12-16T15:32:59  *** laurentmt has quit IRC
382 2016-12-16T15:39:44  *** skyraider_ has joined #bitcoin-core-dev
383 2016-12-16T15:43:34  <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
384 2016-12-16T15:44:40  *** rebroad has joined #bitcoin-core-dev
385 2016-12-16T15:50:45  <bitcoin-git> [bitcoin] laanwj closed pull request #9365: [testing] [donotmerge] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
386 2016-12-16T15:52:57  *** windsok has joined #bitcoin-core-dev
387 2016-12-16T16:08:28  <phantomcircuit> rebroad, yeah i still dont see why you wouldn't be able to spend outputs from a segwit transactions with a normal transaction
388 2016-12-16T16:08:38  <phantomcircuit> the only thing being changed is the serialization of the script
389 2016-12-16T16:10:22  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9e00591cd3f...8c7947e09ff8
390 2016-12-16T16:10:22  <bitcoin-git> bitcoin/master fa16b8f MarcoFalke: If we don't allow free txs, always send a fee filter (take 2)
391 2016-12-16T16:10:23  <bitcoin-git> bitcoin/master 8c7947e Wladimir J. van der Laan: Merge #9367: If we don't allow free txs, always send a fee filter (take 2)...
392 2016-12-16T16:10:40  <bitcoin-git> [bitcoin] laanwj closed pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
393 2016-12-16T16:18:01  <instagibbs> phantomcircuit, if your wallet doesn't understand segwit, it has no idea how to sign, if nothing else
394 2016-12-16T16:18:08  <instagibbs> (sorry missed convo)
395 2016-12-16T16:19:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
396 2016-12-16T16:27:02  *** aalex has quit IRC
397 2016-12-16T16:28:22  *** aalex has joined #bitcoin-core-dev
398 2016-12-16T16:30:11  <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
399 2016-12-16T16:33:25  <sipa> rebroad: no wallet does anything with outputs they do not understand
400 2016-12-16T16:33:43  <sipa> *nodes* will treat those outputs as anyonecanspend, yes
401 2016-12-16T16:33:48  <sipa> but wallets don't
402 2016-12-16T16:34:13  <sipa> your wallet does not show you all anyonecanspend outputs on the network now, right?
403 2016-12-16T16:34:58  <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
404 2016-12-16T16:35:52  <rebroad> sipa, well, nodes, and modified pre-segwit wallets ;)
405 2016-12-16T16:36:05  <sipa> sure
406 2016-12-16T16:36:17  <sipa> they can try
407 2016-12-16T16:36:25  <sipa> but they won't confirm
408 2016-12-16T16:36:51  <rebroad> sipa, if they did confirm, miners would build upon those blocks
409 2016-12-16T16:37:06  <rebroad> at least, pre-segwit activation anyway
410 2016-12-16T16:37:26  <rebroad> but people would have to be a little foolish to create such a tx pre-segwit
411 2016-12-16T16:37:44  <sipa> pre-activation you shouldn't be creating segwit outputs
412 2016-12-16T16:37:48  <sipa> that's very dangerois
413 2016-12-16T16:41:50  *** face_ has joined #bitcoin-core-dev
414 2016-12-16T16:42:05  <Victorsueca> creating a segwit transaction without miners and nodes enforcing segwit yet can potentially lead to anyone-can-spend outputs
415 2016-12-16T16:43:06  <sipa> not potentially
416 2016-12-16T16:43:18  <sipa> by definition, they will be anyonecanspend outputs
417 2016-12-16T16:43:28  *** face_ is now known as face
418 2016-12-16T16:45:24  <rebroad> they need to be anyonecanspend outputs for segwit to be possible
419 2016-12-16T16:49:31  <Victorsueca> just had a quick thought about this....
420 2016-12-16T16:51:18  <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)...
421 2016-12-16T16:52:04  <Victorsueca> and with that block it reaches 95% required to activate it
422 2016-12-16T16:52:31  <sipa> that's not possible
423 2016-12-16T16:52:42  <sipa> there is another 2016 block before it activates
424 2016-12-16T16:52:48  <Victorsueca> ahh right
425 2016-12-16T16:53:03  <sipa> the 95% makes it go to the LOCKEDIN state
426 2016-12-16T16:53:37  <Victorsueca> welp, that solves it pretty much
427 2016-12-16T16:54:22  <Victorsueca> my quick thoughts don't make sense most of the times.... but last time one of them made sense it was a disaster
428 2016-12-16T17:01:01  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370
429 2016-12-16T17:11:43  <jonasschnelli> I would say that #9370 (or one of the alternative solutions) is a candidate for a 0.13.2 backport.
430 2016-12-16T17:11:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9370 | Fix fundrawtransactions address-reuse problem by jonasschnelli · Pull Request #9370 · bitcoin/bitcoin · GitHub
431 2016-12-16T17:18:08  <phantomcircuit> instagibbs, you're signing the new transaction not the old one
432 2016-12-16T17:18:37  <phantomcircuit> rebroad, that's not saying that the wallet needs to understand segwit
433 2016-12-16T17:18:52  *** abpa has joined #bitcoin-core-dev
434 2016-12-16T17:18:58  <phantomcircuit> just that it needs to get the utxo entries from somewhere other than the transaction data
435 2016-12-16T17:19:24  <phantomcircuit> wait no
436 2016-12-16T17:19:34  <phantomcircuit> the SIGNATURE isn't needed by the person spending
437 2016-12-16T17:19:42  <phantomcircuit> yeah im 99.99% sure you're wrong
438 2016-12-16T17:20:12  <phantomcircuit> sipa, segwit doesn't change the outputs at all, just the inputs with the signature
439 2016-12-16T17:20:27  <phantomcircuit> or does it and i am just very tired and hungry
440 2016-12-16T17:22:20  <sdaftuar> phantomcircuit: see BIP 141.  segwit outputs are constructed differently than non-segwit outputs.
441 2016-12-16T17:22:55  <phantomcircuit> hmm
442 2016-12-16T17:23:02  * phantomcircuit goes to find a thermometer
443 2016-12-16T17:26:16  <gmaxwell> rebroad: he changed the text, many times. Last I checked the current text was still wrong as heck.
444 2016-12-16T17:28:02  <phantomcircuit> 101...
445 2016-12-16T17:28:04  <phantomcircuit> ok then
446 2016-12-16T17:29:19  <phantomcircuit> oh right
447 2016-12-16T17:29:35  <Victorsueca> 101ºC?
448 2016-12-16T17:29:56  <Victorsueca> ;)
449 2016-12-16T17:30:13  <sipa> phantomcircuit: p2sh witness outputs are indistinguishable to the network from other p2sh outputs
450 2016-12-16T17:30:38  <sipa> but they are distinguishable to the receiver... who either knows the redeemscript and how to spend it, or not
451 2016-12-16T17:31:18  <phantomcircuit> sipa, it's the same as p2sh originally right
452 2016-12-16T17:31:45  <phantomcircuit> and is because of the change to the signature hashing basically meaning it's a "new" script language
453 2016-12-16T17:31:53  <Victorsueca> basically you can't know whether it is P2SH, P2WSH or P2WPKH until the outputs are redeemed
454 2016-12-16T17:32:33  <sipa> phantomcircuit: new signature hashing, and it takes inputs from the witness rather than from the scriptSig directly
455 2016-12-16T17:32:43  <Victorsueca> some extra privacy, that's always good
456 2016-12-16T17:34:33  *** laurentmt has joined #bitcoin-core-dev
457 2016-12-16T17:34:42  *** laurentmt has quit IRC
458 2016-12-16T17:44:00  *** aalex has quit IRC
459 2016-12-16T17:45:46  *** skyraider_ has quit IRC
460 2016-12-16T17:47:56  *** aalex has joined #bitcoin-core-dev
461 2016-12-16T17:54:43  *** MykelSIlver has joined #bitcoin-core-dev
462 2016-12-16T18:11:42  *** rebroad has quit IRC
463 2016-12-16T18:19:41  *** profall has joined #bitcoin-core-dev
464 2016-12-16T18:19:54  <profall> Hello, what is the default rpcworkqueue on 13.1 ?
465 2016-12-16T18:20:03  <profall> I want to increase it but I have no idea what the starting value is
466 2016-12-16T18:25:34  *** wasi has quit IRC
467 2016-12-16T18:30:31  *** jannes has quit IRC
468 2016-12-16T18:30:40  *** wasi has joined #bitcoin-core-dev
469 2016-12-16T18:31:17  <sipa> 16
470 2016-12-16T18:31:31  <profall> Thank You
471 2016-12-16T18:38:10  *** laurentmt has joined #bitcoin-core-dev
472 2016-12-16T18:43:04  *** laurentmt has quit IRC
473 2016-12-16T18:53:00  <gmaxwell> sipa: So the chainstate reindex without signature verification test with 300MB dbcache completed,  entry-per-txout is ~25% _faster_ than master!
474 2016-12-16T18:56:41  <sipa> gmaxwell: woah
475 2016-12-16T18:56:52  <sipa> wasn't only 6% at some point during sync?
476 2016-12-16T19:03:04  *** wasi has quit IRC
477 2016-12-16T19:03:18  <gmaxwell> I was screwing up the comparison when I was giving you those figures.
478 2016-12-16T19:05:03  <sipa> wasn't it around the same number for a 2000MB dbcache?
479 2016-12-16T19:05:58  <sipa> anyway great... more work, now we need to investigate this idea further
480 2016-12-16T19:07:51  *** grubles is now known as grubles__
481 2016-12-16T19:08:04  *** wasi has joined #bitcoin-core-dev
482 2016-12-16T19:09:59  *** matrix01 has joined #bitcoin-core-dev
483 2016-12-16T19:10:25  <matrix01> Who can help  to gave me a small amount of BTC or borow me some pm me thx!
484 2016-12-16T19:14:33  <sipa> matrix01: for experimenting purpose, use a testnet faucet. otherwise: this is not a place for begging
485 2016-12-16T19:22:27  *** paveljanik has joined #bitcoin-core-dev
486 2016-12-16T19:27:29  <bitcoin-git> [bitcoin] morcos opened pull request #9371: Notify on removal (master...notifyOnRemoval) https://github.com/bitcoin/bitcoin/pull/9371
487 2016-12-16T19:38:20  <gmaxwell> sipa: ~23% for 2000MB, so yes.
488 2016-12-16T19:38:44  *** sipa has quit IRC
489 2016-12-16T19:38:44  *** sipa has joined #bitcoin-core-dev
490 2016-12-16T19:42:39  *** wvr has joined #bitcoin-core-dev
491 2016-12-16T19:47:23  <Lightsword> was the networking code being reworked to use libevent or something similar? or was that just the rpc server stuff?
492 2016-12-16T19:48:23  <sipa> it's being reworked slowly
493 2016-12-16T19:48:27  <sipa> but it's not yet using libevent
494 2016-12-16T19:48:44  <sipa> but having the network code use libevent is indeed a goal
495 2016-12-16T19:52:12  <Lightsword> is the network refactoring in preparation for that? how close is it to being able to use libevent?
496 2016-12-16T19:52:28  <sipa> talk to cfields
497 2016-12-16T19:52:36  <sipa> i expect libevent to happen in 0.15
498 2016-12-16T19:53:30  <cfields> Lightsword: quite close, up and running locally. Upstreaming in chunks.
499 2016-12-16T19:54:37  *** MykelSIlver has quit IRC
500 2016-12-16T20:00:04  <matrix01> Who can help  to gave me a small amount of BTC or borow me some pm me thx!
501 2016-12-16T20:00:17  <sipa> matrix01: stop begging. last warning
502 2016-12-16T20:00:28  *** ChanServ sets mode: +o sipa
503 2016-12-16T20:06:01  *** matrix01 has left #bitcoin-core-dev
504 2016-12-16T20:07:17  *** jtimon has quit IRC
505 2016-12-16T20:12:12  *** Atomicat_ has joined #bitcoin-core-dev
506 2016-12-16T20:14:26  *** Atomicat has quit IRC
507 2016-12-16T20:14:33  *** Atomicat_ is now known as Atomicat
508 2016-12-16T20:20:31  *** Guyver2 has quit IRC
509 2016-12-16T20:28:34  <instagibbs> sipa, he's been doing this under various names repeatedly on other channels someone banhammer him
510 2016-12-16T20:32:57  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c7947e09ff8...b99a093afed8
511 2016-12-16T20:32:58  <bitcoin-git> bitcoin/master ed58969 Pieter Wuille: Batch construct batches...
512 2016-12-16T20:32:58  <bitcoin-git> bitcoin/master b99a093 Pieter Wuille: Merge #9346: Batch construct batches...
513 2016-12-16T20:33:14  <bitcoin-git> [bitcoin] sipa closed pull request #9346: Batch construct batches (master...reusebatch) https://github.com/bitcoin/bitcoin/pull/9346
514 2016-12-16T20:48:31  *** MykelSIlver has joined #bitcoin-core-dev
515 2016-12-16T20:56:37  *** MykelSIlver has quit IRC
516 2016-12-16T21:08:18  *** wvr has quit IRC
517 2016-12-16T21:13:24  *** jtimon has joined #bitcoin-core-dev
518 2016-12-16T21:27:25  <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?
519 2016-12-16T21:28:38  <achow101> date range is wrong?
520 2016-12-16T21:31:10  <gmaxwell> Hm? git log --no-merges shows commits from ~150 contributors (some name dupes) from 2015-12-16 to now.
521 2016-12-16T21:33:02  *** owowo has quit IRC
522 2016-12-16T21:33:36  <arubi> replacing 'type=c' with a mock 'type=none' lists 100 people
523 2016-12-16T21:37:18  <achow101> maybe some of the authors don't have their emails registered with github so they aren't shown?
524 2016-12-16T21:40:16  <achow101> they might also be counting committers and not authors
525 2016-12-16T21:42:20  <gmaxwell> achow101: nope, far too many.
526 2016-12-16T21:42:40  <gmaxwell> achow101: e.g. you're listed.
527 2016-12-16T21:43:06  <btcdrak> sounds like we need to report this to github, their data processing appears to be bugged
528 2016-12-16T21:43:37  <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
529 2016-12-16T21:44:03  <gmaxwell> achow101: yea, no-- not that either.
530 2016-12-16T21:44:17  <gmaxwell> there are people not listed that made PRs and had them merged.
531 2016-12-16T21:45:19  *** owowo has joined #bitcoin-core-dev
532 2016-12-16T21:46:24  <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
533 2016-12-16T21:46:39  <Chris_Stewart_5> but I'm not on the contributors list :/ not sure why
534 2016-12-16T21:49:05  <achow101> gmaxwell: are you sure? even though they opened PRs, some of them have the committer name as someone else or committed on GitHub
535 2016-12-16T21:49:52  <gmaxwell> achow101: https://github.com/bitcoin/bitcoin/pull/6842 take that one for example.
536 2016-12-16T21:50:15  <achow101> that commit is out of your time range
537 2016-12-16T21:53:05  <gmaxwell> achow101: ah it's merge isn't. Lemme find another.
538 2016-12-16T21:57:34  <gmaxwell> https://github.com/bitcoin/bitcoin/commit/8c1dbc5e9ddbafb77e60e8c4e6eb275a3a76ac12 < how about that?
539 2016-12-16T21:58:10  <achow101> no registered email with github
540 2016-12-16T22:00:05  <gmaxwell> okay, lemme try another!
541 2016-12-16T22:01:09  <gmaxwell> yea, that might be it.
542 2016-12-16T22:02:13  <achow101> gmaxwell: here's an example of a commit I was talking about: https://github.com/bitcoin/bitcoin/commit/203e2ddad8e544803491d1e9e9ca2b6e26a15f8e
543 2016-12-16T22:02:21  <achow101> laudaa is not even in the contributors list at all
544 2016-12-16T22:18:55  *** laurentmt has joined #bitcoin-core-dev
545 2016-12-16T22:31:03  *** laurentmt has quit IRC
546 2016-12-16T22:44:41  *** MykelSIlver has joined #bitcoin-core-dev
547 2016-12-16T23:01:20  *** Madars has quit IRC
548 2016-12-16T23:06:19  <sipa> morcos: any reason why ApplyTxInUndo can't use ModifyNewCoins?
549 2016-12-16T23:07:01  *** sipa sets mode: -o sipa
550 2016-12-16T23:11:14  *** alpalp has joined #bitcoin-core-dev
551 2016-12-16T23:11:14  *** alpalp has joined #bitcoin-core-dev
552 2016-12-16T23:22:37  *** alpalp has quit IRC
553 2016-12-16T23:29:32  *** Madars has joined #bitcoin-core-dev
554 2016-12-16T23:33:35  <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..
555 2016-12-16T23:36:34  <sipa> morcos: right, i was working on my per-txout branch... where it would apply for every spend
556 2016-12-16T23:36:52  <sipa> i mean: would it be safe to use?
557 2016-12-16T23:37:00  <morcos> heh, well then its a bit of a different question..
558 2016-12-16T23:38:13  *** Madars has quit IRC
559 2016-12-16T23:38:15  <morcos> i'd have to think about exactly how it works in a per-txout world..  but it seems like it should be.
560 2016-12-16T23:39:03  <sipa> assuming your database is not corrupted, the undo data is trusted
561 2016-12-16T23:39:19  *** dgenr8 has quit IRC
562 2016-12-16T23:39:27  <sipa> which means that you are certain that it (semantically speaking, from the chain point of view) is never overwriting anything
563 2016-12-16T23:40:27  *** dgenr8 has joined #bitcoin-core-dev
564 2016-12-16T23:47:27  <morcos> yep, and at least after #9107 ModifyNewCoins asserts that that is the case
565 2016-12-16T23:47:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub