1 2016-05-13T00:08:38  *** alpalp has joined #bitcoin-core-dev
  2 2016-05-13T00:08:54  *** alpalp has joined #bitcoin-core-dev
  3 2016-05-13T00:14:39  <sipa> $ ./walletbackup.py
  4 2016-05-13T00:14:44  <sipa> INFO: Restoring using dumped wallet
  5 2016-05-13T00:14:44  <sipa> Unexpected exception caught during testing: BrokenPipeError(32, 'Broken pipe')
  6 2016-05-13T00:14:51  <sipa> Stopping nodes
  7 2016-05-13T00:14:51  <sipa> WARN: Unable to stop node: CannotSendRequest('Request-sent',)
  8 2016-05-13T00:15:32  <gmaxwell> sipa: patrick got to you?
  9 2016-05-13T00:15:49  <gmaxwell> the question is-- why doesn't travis see it as failing?
 10 2016-05-13T00:18:13  <sipa> gmaxwell, wumpus, jonasschnelli:
 11 2016-05-13T00:19:07  <gmaxwell> sipa, sipa, sipa
 12 2016-05-13T00:20:21  <sipa> gmaxwell: are you wumpus and jonasschnelli?
 13 2016-05-13T00:20:44  <sipa> i wanted to paste my rorx results, but they seem to have disappeared into my terminal's forgotten history
 14 2016-05-13T00:20:57  <gmaxwell> No, are you?
 15 2016-05-13T00:21:10  <sipa> both rorxes were similar, and fastest
 16 2016-05-13T00:21:19  <gmaxwell> well, see.. I saved them seconds of disappointment by wisely preempting your summons.
 17 2016-05-13T00:23:55  <gmaxwell> sipa: did you see the usenix paper I linked to you some indeterminable number of days ago?
 18 2016-05-13T00:24:18  <sipa> i skimmed it, not enough to actually find the xor trick you were referring to
 19 2016-05-13T00:25:19  <gmaxwell> are you familar with cuckoo hashing?
 20 2016-05-13T00:25:32  *** d4de has joined #bitcoin-core-dev
 21 2016-05-13T00:25:59  <sipa> yes
 22 2016-05-13T00:27:02  <gmaxwell> So how do you support cuckoo hashing if the whole value can't be stored in the table? -- normally you rehash an entry to find its alternative location when you evict it.
 23 2016-05-13T00:28:48  <gmaxwell> The make the primary location   H(full value)->to offset and the secondary location H(short value) ^ location.  So you only need the current location and the short value to swap an entry between slots.
 24 2016-05-13T00:29:35  <gmaxwell> (and you don't need to track which one it was in, since the same xor relates them)
 25 2016-05-13T00:32:21  <sipa> gmaxwell, wumpus, jonasschnelli:
 26 2016-05-13T00:32:23  <sipa> SHA256_avx,175,0.00575656,0.0058105,0.00575941
 27 2016-05-13T00:32:23  <sipa> SHA256_basic,119,0.0088715,0.00893307,0.00887388
 28 2016-05-13T00:32:23  <sipa> SHA256_rorx,223,0.00482899,0.004861,0.00483046
 29 2016-05-13T00:32:23  <sipa> SHA256_rorx_x8ms,223,0.00475737,0.0047915,0.00476165
 30 2016-05-13T00:32:25  <sipa> SHA256_sse4,175,0.00574069,0.00577295,0.00574323
 31 2016-05-13T00:33:09  <sipa> i7-4800MQ, fixed at 2.6 GHz
 32 2016-05-13T00:34:12  *** alpalp has quit IRC
 33 2016-05-13T00:34:13  <phantomcircuit> is the first column cycle count?
 34 2016-05-13T00:34:25  *** alpalp has joined #bitcoin-core-dev
 35 2016-05-13T00:34:25  *** alpalp has joined #bitcoin-core-dev
 36 2016-05-13T00:34:31  <sipa> iteration count
 37 2016-05-13T00:34:35  <gmaxwell> phantomcircuit: it's number of times the freaky bench innerloop ran.
 38 2016-05-13T00:34:36  <phantomcircuit> ah
 39 2016-05-13T00:34:38  <sipa> how many tests were done
 40 2016-05-13T00:34:53  <sipa> each doing 1 MB of data
 41 2016-05-13T00:35:01  <phantomcircuit> ok
 42 2016-05-13T00:35:21  <phantomcircuit> neat
 43 2016-05-13T00:35:31  <gmaxwell> really for our usage running with 32 and 64 bytes of data is much more interesting.
 44 2016-05-13T00:35:56  <gmaxwell> might be useful to see if that changes the numbers at all... perhaps gives AVX a purpose for existing? :)
 45 2016-05-13T00:36:07  <sipa> sure, but it's just a proxy for the number of sha256 compression function runs
 46 2016-05-13T00:36:11  *** flybyguy has joined #bitcoin-core-dev
 47 2016-05-13T00:36:42  <gmaxwell> ah duh right, it doesn't have a finialization, so it's not going to change.
 48 2016-05-13T00:37:01  *** flybyguy has left #bitcoin-core-dev
 49 2016-05-13T00:37:22  <sipa> note, it's a mobile CPU; if i don't fix the clock speed, cpufreq increases my cpu speed somewhere during the rorx_x8m run
 50 2016-05-13T00:37:31  <phantomcircuit> gmaxwell, loading into the right registers takes some amount of work
 51 2016-05-13T00:37:37  <sipa> making it look wildly better than rorx
 52 2016-05-13T00:38:05  <phantomcircuit> sipa, test on a build box?
 53 2016-05-13T00:38:22  <phantomcircuit> gmaxwell, any idea if those have turbo or not?
 54 2016-05-13T00:38:29  <sipa> turbo is easy to disable
 55 2016-05-13T00:41:11  *** Ylbam has quit IRC
 56 2016-05-13T00:45:55  *** laurentmt has joined #bitcoin-core-dev
 57 2016-05-13T00:47:12  *** d4de has quit IRC
 58 2016-05-13T00:47:42  <sipa> on our 56-core machine:
 59 2016-05-13T00:47:44  <sipa> SHA256_avx,255,0.00397131,0.00401497,0.00397456
 60 2016-05-13T00:47:44  <sipa> SHA256_basic,175,0.00599988,0.00604987,0.00600181
 61 2016-05-13T00:47:44  <sipa> SHA256_rorx,319,0.00334556,0.003407,0.00334662
 62 2016-05-13T00:47:44  <sipa> SHA256_rorx_x8ms,319,0.00328553,0.00332999,0.00328678
 63 2016-05-13T00:47:46  <sipa> SHA256_sse4,255,0.00395919,0.00401807,0.00396108
 64 2016-05-13T00:47:53  <sipa> gmaxwell: what cpu is it?
 65 2016-05-13T00:51:41  <sipa> i'm surprised that our C code is only 45% slower than intel's optimized asm code
 66 2016-05-13T00:52:39  *** laurentmt has quit IRC
 67 2016-05-13T00:56:07  <gmaxwell> the 56-core are broadwell-ep
 68 2016-05-13T00:56:29  <gmaxwell> but 'only' at 2.2GHz.
 69 2016-05-13T00:58:19  <phantomcircuit> sipa, none of those are parallel calculation right?
 70 2016-05-13T00:58:52  <sipa> indeed, all single threaded
 71 2016-05-13T01:00:27  *** Guest13955 has quit IRC
 72 2016-05-13T01:00:27  *** Guest13955 has joined #bitcoin-core-dev
 73 2016-05-13T01:00:27  *** Guest13955 is now known as amiller
 74 2016-05-13T01:00:28  <gmaxwell> sipa: sha2 that computes four at once is a considerable additional speedup, but harder to use without more software changes.
 75 2016-05-13T01:01:19  <sipa> very doable inside merkle trees, though
 76 2016-05-13T01:01:40  *** mrkent_ has joined #bitcoin-core-dev
 77 2016-05-13T01:02:11  <gmaxwell> Yes. though thats pretty much the only place where it's very doable.
 78 2016-05-13T01:02:25  <sipa> also the place where it probably matters most
 79 2016-05-13T01:02:55  <gmaxwell> I'm sure if you want to write the merkle tree function wumpus will hapily do the work to give you a sha2x4 to call. :)
 80 2016-05-13T01:04:29  *** mrkent has quit IRC
 81 2016-05-13T01:05:09  *** dermoth_ has quit IRC
 82 2016-05-13T01:05:42  *** dermoth_ has joined #bitcoin-core-dev
 83 2016-05-13T01:11:55  <gmaxwell> my vague recollection was "the asm was 2x faster than the C, and the 4-way was 3x faster than the C" I dunno how that generalizes with the rorx.
 84 2016-05-13T01:12:22  *** jtimon has quit IRC
 85 2016-05-13T01:27:43  *** fengling has joined #bitcoin-core-dev
 86 2016-05-13T01:34:11  *** Giszmo has quit IRC
 87 2016-05-13T01:35:23  *** Giszmo has joined #bitcoin-core-dev
 88 2016-05-13T01:40:01  *** Alopex has quit IRC
 89 2016-05-13T01:41:07  *** Alopex has joined #bitcoin-core-dev
 90 2016-05-13T02:02:03  *** Giszmo has quit IRC
 91 2016-05-13T02:13:04  *** helo has quit IRC
 92 2016-05-13T02:14:38  *** helo has joined #bitcoin-core-dev
 93 2016-05-13T02:22:06  *** Giszmo has joined #bitcoin-core-dev
 94 2016-05-13T02:36:03  *** alpalp has quit IRC
 95 2016-05-13T02:42:43  *** CubicEarth has joined #bitcoin-core-dev
 96 2016-05-13T02:44:06  *** Chris_Stewart_5 has quit IRC
 97 2016-05-13T02:51:45  *** achow101 has quit IRC
 98 2016-05-13T02:53:00  <GitHub130> [bitcoin] sipa opened pull request #8051: Fix walletbackup.py failure (master...fixwalletbackup) https://github.com/bitcoin/bitcoin/pull/8051
 99 2016-05-13T02:56:55  *** dermoth__ has joined #bitcoin-core-dev
100 2016-05-13T02:59:30  *** dermoth_ has quit IRC
101 2016-05-13T03:02:09  <gmaxwell> sipa: considering your PR comments might it be a bit strong to call that 'fix'?  rather than 'mysteriously stir'? :)
102 2016-05-13T03:04:15  <sipa> gmaxwell: well, it's reproducible :)
103 2016-05-13T03:04:26  *** davec has quit IRC
104 2016-05-13T03:04:28  <sipa> maybe i should call it "seemingly fix"
105 2016-05-13T03:04:44  <sipa> done
106 2016-05-13T03:04:53  *** mrkent_ has quit IRC
107 2016-05-13T03:05:04  *** davec has joined #bitcoin-core-dev
108 2016-05-13T03:05:07  <gmaxwell> presumably it fails for you because your computer is fast and travis isn't.
109 2016-05-13T03:06:09  *** lecusemble has quit IRC
110 2016-05-13T03:06:18  <sipa> hmm, i started off by adding sleeps and that didn't help
111 2016-05-13T03:06:30  <sipa> but let me try again, by adding a sleep exactly there
112 2016-05-13T03:19:03  <sipa> gmaxwell: the sync blocks there causes a sleep of 1-2 seconds
113 2016-05-13T03:19:11  <sipa> gmaxwell: an explicit sleep of 60s does not fix it
114 2016-05-13T03:23:08  *** lecusemble has joined #bitcoin-core-dev
115 2016-05-13T03:23:44  <gmaxwell> uh how does that make any sense?
116 2016-05-13T03:23:59  <sipa> sense, it makes none
117 2016-05-13T04:52:31  *** lecusemble has quit IRC
118 2016-05-13T05:02:02  *** kadoban has quit IRC
119 2016-05-13T05:04:45  *** lecusemble has joined #bitcoin-core-dev
120 2016-05-13T05:13:12  *** paveljanik has quit IRC
121 2016-05-13T05:31:53  *** gabridome has joined #bitcoin-core-dev
122 2016-05-13T05:38:11  *** Arnavion has quit IRC
123 2016-05-13T05:38:38  *** Arnavion has joined #bitcoin-core-dev
124 2016-05-13T05:47:45  *** kadoban has joined #bitcoin-core-dev
125 2016-05-13T05:52:01  *** Giszmo has quit IRC
126 2016-05-13T05:53:22  *** Arnavion has quit IRC
127 2016-05-13T05:54:04  *** Arnavion has joined #bitcoin-core-dev
128 2016-05-13T06:11:55  *** Ylbam has joined #bitcoin-core-dev
129 2016-05-13T06:14:52  *** Arnavion has quit IRC
130 2016-05-13T06:15:08  *** Arnavion has joined #bitcoin-core-dev
131 2016-05-13T06:47:44  *** gabridome has quit IRC
132 2016-05-13T06:53:02  <jonasschnelli> sipa: I read something in the logs: is walletbackup.py fixed?
133 2016-05-13T06:53:20  * jonasschnelli reading https://github.com/bitcoin/bitcoin/pull/8051#issuecomment-218943822
134 2016-05-13T06:53:29  <sipa> jonasschnelli: for me it is
135 2016-05-13T06:54:05  *** gabridome has joined #bitcoin-core-dev
136 2016-05-13T07:02:32  <jonasschnelli> sipa: I can't reproduce the issue... but you fix looks strange. :)
137 2016-05-13T07:06:33  <sipa> without it, i just can't run rpc_tests.py
138 2016-05-13T07:06:38  <sipa> it runs forever
139 2016-05-13T07:08:24  <jonasschnelli> But you can run walletbackup.py independent?
140 2016-05-13T07:10:46  <sipa> no
141 2016-05-13T07:10:54  <sipa> see the paste in the PR
142 2016-05-13T07:10:56  <jonasschnelli> hmm...
143 2016-05-13T07:11:01  <jonasschnelli> Yes. Saw it...
144 2016-05-13T07:11:10  <jonasschnelli> like to debug it locally.
145 2016-05-13T07:12:26  *** JackH has joined #bitcoin-core-dev
146 2016-05-13T07:17:32  *** gabridome has quit IRC
147 2016-05-13T07:18:54  <sipa> maybe it depends on python version or something else
148 2016-05-13T07:19:09  <sipa> but something very fishy is going on, as it's not just a race condition
149 2016-05-13T07:20:36  *** CubicEarth has quit IRC
150 2016-05-13T07:21:08  *** gabridome has joined #bitcoin-core-dev
151 2016-05-13T07:21:11  *** CubicEarth has joined #bitcoin-core-dev
152 2016-05-13T07:24:07  *** BashCo has quit IRC
153 2016-05-13T07:24:44  *** BashCo has joined #bitcoin-core-dev
154 2016-05-13T07:25:55  *** CubicEarth has quit IRC
155 2016-05-13T07:26:10  *** CubicEarth has joined #bitcoin-core-dev
156 2016-05-13T07:29:29  *** BashCo has quit IRC
157 2016-05-13T07:30:47  *** gabridome has quit IRC
158 2016-05-13T07:32:01  *** gabridome has joined #bitcoin-core-dev
159 2016-05-13T07:34:53  *** gabridome has quit IRC
160 2016-05-13T07:45:38  *** BashCo has joined #bitcoin-core-dev
161 2016-05-13T07:50:24  *** zibbo has quit IRC
162 2016-05-13T07:51:36  *** CubicEarth has quit IRC
163 2016-05-13T07:53:21  *** kadoban has quit IRC
164 2016-05-13T07:58:57  *** CubicEarth has joined #bitcoin-core-dev
165 2016-05-13T07:59:51  *** Evel-Knievel has quit IRC
166 2016-05-13T08:00:24  *** Evel-Knievel has joined #bitcoin-core-dev
167 2016-05-13T08:03:51  *** CubicEarth has quit IRC
168 2016-05-13T08:08:18  *** CyrusV has quit IRC
169 2016-05-13T08:08:29  *** CyrusV has joined #bitcoin-core-dev
170 2016-05-13T08:22:08  *** AaronvanW has joined #bitcoin-core-dev
171 2016-05-13T08:31:33  *** molz has quit IRC
172 2016-05-13T08:47:23  *** grassass has quit IRC
173 2016-05-13T08:59:13  *** Guyver2 has joined #bitcoin-core-dev
174 2016-05-13T09:04:10  *** nub has joined #bitcoin-core-dev
175 2016-05-13T09:05:14  <nub> would it be possible to shorten the block creation time from 10 minutes to say 1 minute with a hard fork obviously dividing the reward by a factor of 10 that way confrimations would be much faster i'd imagine
176 2016-05-13T09:06:27  <sipa> yes, it wod be possible with a hars fork
177 2016-05-13T09:06:43  <sipa> a hars fork could also turn bitcoin into a frontend for paypal
178 2016-05-13T09:06:47  <sipa> *hard
179 2016-05-13T09:07:02  <nub> could you explain that?
180 2016-05-13T09:07:32  <nub> is that bad?
181 2016-05-13T09:07:36  <sipa> a hard fork is replacing the system with another system, where all participants agrwe to switch to different software
182 2016-05-13T09:07:44  <sipa> it can change anything
183 2016-05-13T09:07:57  <nub> could a soft fork change block time?
184 2016-05-13T09:08:08  <sipa> the question "is x possible with a hard fork?" always has "yes" as answer
185 2016-05-13T09:08:15  <sipa> no, a soft fork can't do that
186 2016-05-13T09:08:46  <sipa> it would also be a bad idea, as it would result is 10 times higher mining centralization pressure
187 2016-05-13T09:08:58  <sipa> and confirmations that have less meaning
188 2016-05-13T09:09:43  *** grassass has joined #bitcoin-core-dev
189 2016-05-13T09:09:44  <gmaxwell> sipa: actually not 10 times higher, but likely much higher, since the relationship is non-linear. :)
190 2016-05-13T09:09:57  <nub> how can we speed up transactions?
191 2016-05-13T09:10:01  <nub> or confirmations
192 2016-05-13T09:10:14  <sipa> nub: why do you want to do that?
193 2016-05-13T09:10:34  <sipa> if you want them to be fast enough to work at a point of sale, you'll need different technology
194 2016-05-13T09:10:55  <nub> im a store wanting to sell stuff accepting bitcoin but i dont want them to leave until the bitcoin is in my account....
195 2016-05-13T09:10:56  <sipa> there is simply no way to get global consensus within seconds
196 2016-05-13T09:11:03  <nub> that currently takes far too long
197 2016-05-13T09:11:14  <sipa> 1 minute is also far too long
198 2016-05-13T09:11:34  <sipa> you just can't use bitcoin blockchain transactions for that purpose
199 2016-05-13T09:11:45  <nub> what if the purchaser uses the same hosted wallet platfrom as the seller
200 2016-05-13T09:12:03  <nub> then it could be instant and no bitcoin would need to be sent\
201 2016-05-13T09:12:06  <sipa> that wouls be one example of another technology
202 2016-05-13T09:12:29  <sipa> now you're using the database of the wallet provider rather than the blockchain
203 2016-05-13T09:12:57  <nub> something like cassandra replicated to datacenters all around the world
204 2016-05-13T09:13:25  <sipa> if you have a centrally trusted party running those datacenters, it's easy :)
205 2016-05-13T09:13:42  <sipa> but that's not a luxury we have for bitcoin the base technology
206 2016-05-13T09:14:12  <nub> whats the aim of bitcoin now?
207 2016-05-13T09:14:18  <sipa> this discussion probably belongs in #bitcoin
208 2016-05-13T09:14:27  <nub> wanna move to there?
209 2016-05-13T09:14:40  <sipa> i'm going to sleep, but feel free :)
210 2016-05-13T09:15:15  <nub> is it ok to discuss how a hard fork could work here?
211 2016-05-13T09:15:47  <sipa> it's easy: make a change to the code that does what you want, and convince the whole world to switch to that code
212 2016-05-13T09:16:09  <sipa> and no, the interblock time is not going to change
213 2016-05-13T09:16:47  <nub> what if it was a slow transition say a client which works on both and at a certain (ntp time) it switches everyone
214 2016-05-13T09:17:21  <nub> could put that feature in a year beefore the planned fork so everyones updated to the client that supports that by then
215 2016-05-13T09:17:28  <sipa> you'd still need to convince the entire world to switch before that fkag date
216 2016-05-13T09:17:38  <nub> make the app do it automatically
217 2016-05-13T09:17:41  <nub> bitcoin core
218 2016-05-13T09:17:54  <sipa> bitcoin core does not decide what the rules of the network are
219 2016-05-13T09:18:01  <nub> fair enough
220 2016-05-13T09:18:09  <sipa> it very intentionally does not have an auto update function
221 2016-05-13T09:18:18  <sipa> as developers shouldn't be in charge of the rules
222 2016-05-13T09:18:20  <nub> it should
223 2016-05-13T09:18:26  <sipa> it absolutely should not
224 2016-05-13T09:18:28  <nub> and if not updated you can't connect
225 2016-05-13T09:18:37  <sipa> it would make developers central bankers
226 2016-05-13T09:18:39  <nub> devs could add whatever they want
227 2016-05-13T09:19:00  <nub> what if i were to hire them all?
228 2016-05-13T09:19:06  <sipa> try me
229 2016-05-13T09:19:17  <sipa> i'd find another job
230 2016-05-13T09:19:47  <nub> a surcharge could be added to mining which goes to devs instead
231 2016-05-13T09:20:06  <sipa> but even if you could, hopefully the ecosystem would protest and stop using bitcoin core
232 2016-05-13T09:20:38  <nub> wouldnt a 1 minute block time be welcomed for faster trasnactions?
233 2016-05-13T09:20:42  <sipa> no
234 2016-05-13T09:21:01  <sipa> it's a misconception that that would be beneficial
235 2016-05-13T09:21:12  <nub> it works for litecoin
236 2016-05-13T09:21:37  <sipa> "it works" does not mean it is better
237 2016-05-13T09:22:10  <nub> would bitcoin devs be interested in incorperating and being paid to develop?
238 2016-05-13T09:22:33  <nub> in america
239 2016-05-13T09:22:53  <sipa> see https://bitcoincore.org/en/2016/04/04/announcing_sponsorship_programme/
240 2016-05-13T09:23:00  <nub> banks want there software to run on blockchain technology
241 2016-05-13T09:23:08  <nub> we could be running the banks
242 2016-05-13T09:23:10  <sipa> they don't need proof of work or miners
243 2016-05-13T09:23:25  <nub> they dont
244 2016-05-13T09:23:39  <nub> they need a special client which can create and destroy coins
245 2016-05-13T09:23:46  <sipa> this is getting off topic, as you're not talking about developing bitcoin
246 2016-05-13T09:23:52  <sipa> #bitcoin please
247 2016-05-13T09:57:28  *** donal has joined #bitcoin-core-dev
248 2016-05-13T10:03:19  *** fengling has quit IRC
249 2016-05-13T10:05:11  *** fengling has joined #bitcoin-core-dev
250 2016-05-13T10:09:39  *** fengling has quit IRC
251 2016-05-13T10:18:56  *** fengling has joined #bitcoin-core-dev
252 2016-05-13T10:28:42  *** cjcj has quit IRC
253 2016-05-13T10:32:17  *** fengling has quit IRC
254 2016-05-13T10:41:34  <nub> could a soft fork increase block rewards
255 2016-05-13T10:42:20  <gmaxwell> nub: no, and please take further discussion elsewhere.
256 2016-05-13T11:03:12  *** laurentmt has joined #bitcoin-core-dev
257 2016-05-13T11:03:33  *** laurentmt has quit IRC
258 2016-05-13T11:14:44  *** cjcj has joined #bitcoin-core-dev
259 2016-05-13T11:24:31  *** LeMiner has quit IRC
260 2016-05-13T11:36:43  *** LeMiner has joined #bitcoin-core-dev
261 2016-05-13T11:47:44  *** jtimon has joined #bitcoin-core-dev
262 2016-05-13T11:52:36  *** cryptapus_afk is now known as cryptapus
263 2016-05-13T11:53:08  *** jannes has joined #bitcoin-core-dev
264 2016-05-13T12:17:52  *** cfields has quit IRC
265 2016-05-13T12:17:59  *** cfields has joined #bitcoin-core-dev
266 2016-05-13T12:22:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
267 2016-05-13T12:24:15  *** paveljanik has joined #bitcoin-core-dev
268 2016-05-13T12:24:15  *** paveljanik has joined #bitcoin-core-dev
269 2016-05-13T12:28:04  *** alpalp has joined #bitcoin-core-dev
270 2016-05-13T12:28:04  *** alpalp has joined #bitcoin-core-dev
271 2016-05-13T12:29:14  *** Chris_Stewart_5 has quit IRC
272 2016-05-13T12:30:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
273 2016-05-13T12:55:03  *** alpalp has quit IRC
274 2016-05-13T12:58:03  *** molz has joined #bitcoin-core-dev
275 2016-05-13T13:57:03  *** Chris_Stewart_5 has quit IRC
276 2016-05-13T14:02:40  *** jannes has quit IRC
277 2016-05-13T14:09:00  *** Giszmo has joined #bitcoin-core-dev
278 2016-05-13T14:13:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
279 2016-05-13T14:36:26  *** nub has left #bitcoin-core-dev
280 2016-05-13T14:39:07  *** zooko has joined #bitcoin-core-dev
281 2016-05-13T14:58:23  *** CubicEarth has joined #bitcoin-core-dev
282 2016-05-13T15:16:07  *** CubicEarth has quit IRC
283 2016-05-13T15:18:48  *** earlest has joined #bitcoin-core-dev
284 2016-05-13T15:22:04  *** bysherper has quit IRC
285 2016-05-13T15:29:05  *** muftop has quit IRC
286 2016-05-13T15:29:26  *** muftop has joined #bitcoin-core-dev
287 2016-05-13T15:31:26  *** cryptapus_ has joined #bitcoin-core-dev
288 2016-05-13T15:31:26  *** cryptapus_ has joined #bitcoin-core-dev
289 2016-05-13T15:40:21  *** zooko` has joined #bitcoin-core-dev
290 2016-05-13T15:41:48  *** zooko has quit IRC
291 2016-05-13T15:43:35  *** BashCo has quit IRC
292 2016-05-13T15:43:48  *** CubicEarth has joined #bitcoin-core-dev
293 2016-05-13T15:44:11  *** BashCo has joined #bitcoin-core-dev
294 2016-05-13T15:48:34  *** BashCo has quit IRC
295 2016-05-13T15:48:55  *** bysherper has joined #bitcoin-core-dev
296 2016-05-13T15:52:04  *** earlest has quit IRC
297 2016-05-13T15:56:56  *** CubicEarth has quit IRC
298 2016-05-13T16:07:05  *** BashCo has joined #bitcoin-core-dev
299 2016-05-13T16:09:16  *** CubicEarth has joined #bitcoin-core-dev
300 2016-05-13T16:16:30  *** CubicEarth has quit IRC
301 2016-05-13T16:17:23  *** mrkent has joined #bitcoin-core-dev
302 2016-05-13T16:19:23  *** mrkent has quit IRC
303 2016-05-13T16:24:09  *** CubicEarth has joined #bitcoin-core-dev
304 2016-05-13T16:33:44  *** BashCo_ has joined #bitcoin-core-dev
305 2016-05-13T16:37:28  *** BashCo has quit IRC
306 2016-05-13T16:39:54  *** zooko` has quit IRC
307 2016-05-13T16:43:45  *** CubicEarth has quit IRC
308 2016-05-13T16:44:13  *** CubicEarth has joined #bitcoin-core-dev
309 2016-05-13T16:50:04  *** cryptapus_ has quit IRC
310 2016-05-13T16:56:23  *** btcdrak has quit IRC
311 2016-05-13T16:56:23  *** binns has quit IRC
312 2016-05-13T16:56:25  *** ibrightly has quit IRC
313 2016-05-13T16:56:26  *** zmanian__ has quit IRC
314 2016-05-13T16:56:26  *** CodeShark has quit IRC
315 2016-05-13T16:56:26  *** NicolasDorier has quit IRC
316 2016-05-13T17:04:20  *** cryptapus_ has joined #bitcoin-core-dev
317 2016-05-13T17:05:28  *** Chris_Stewart_5 has quit IRC
318 2016-05-13T17:07:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
319 2016-05-13T17:12:38  *** binns has joined #bitcoin-core-dev
320 2016-05-13T17:15:51  <GitHub189> [bitcoin] kazcw opened pull request #8052: rpc tests: increase http timeout (master...rpcwallet-test-timeout) https://github.com/bitcoin/bitcoin/pull/8052
321 2016-05-13T17:17:47  *** ibrightly has joined #bitcoin-core-dev
322 2016-05-13T17:17:58  *** zmanian__ has joined #bitcoin-core-dev
323 2016-05-13T17:20:14  *** btcdrak has joined #bitcoin-core-dev
324 2016-05-13T17:23:48  *** CubicEarth has quit IRC
325 2016-05-13T17:24:41  *** CubicEarth has joined #bitcoin-core-dev
326 2016-05-13T17:25:29  *** CubicEarth has joined #bitcoin-core-dev
327 2016-05-13T17:30:31  *** CodeShark has joined #bitcoin-core-dev
328 2016-05-13T17:34:05  *** NicolasDorier has joined #bitcoin-core-dev
329 2016-05-13T17:42:52  *** wallet42 has quit IRC
330 2016-05-13T17:43:38  *** wallet42 has joined #bitcoin-core-dev
331 2016-05-13T17:44:00  *** CubicEarth has quit IRC
332 2016-05-13T17:44:32  *** CubicEarth has joined #bitcoin-core-dev
333 2016-05-13T17:46:26  *** CubicEarth has quit IRC
334 2016-05-13T17:47:42  *** CubicEarth has joined #bitcoin-core-dev
335 2016-05-13T18:21:32  *** Chris_Stewart_5 has quit IRC
336 2016-05-13T18:22:48  <arubi> nub did remind me of a question I was meaning to ask. and I'm sorry if this is obvious.  suppose we have a way to send an input entirely as miners' fee, then "provably" receive it as an output from a generation transaction in a block that the input->fee transaction was mined on.  if everyone decides one day to use this feature, then could we discard any blockchain data up until the block that this happened, essentially making this new block
337 2016-05-13T18:22:48  <arubi> the genesis block?  this might even be a soft in its "forkiness".  a new client might want to start syncing from the new genesis, and and old client won't care that it happened?  this is very theoretical, I'm just looking to validate my understanding of how this could play out
338 2016-05-13T18:23:53  <sipa> arubi: we can always declare a new block as the genesis block; just snapshot its utxo set
339 2016-05-13T18:25:47  <arubi> sipa, is that the same?  why not do it?
340 2016-05-13T18:25:57  *** cryptapus_ has quit IRC
341 2016-05-13T18:27:09  <arubi> well it's not the same.  I will still need to verify the utxo set to believe that it follows the history since genesis
342 2016-05-13T18:28:05  <sipa> arubi: you can do it. copy your chainstatre directory from someone you trust
343 2016-05-13T18:28:16  <arubi> but trust isn't needed if there's a mechanism like I suggested, right?  (maybe not)
344 2016-05-13T18:30:03  <sipa> of course you need trust in your model; you're relying on the assumption that everyone accepts that the new genesis block is in fact derived from the old one
345 2016-05-13T18:30:08  <sipa> and there is no way to verify that
346 2016-05-13T18:30:33  <sipa> we have no technology that can verify the correctness of the blockchain without seeing it :)
347 2016-05-13T18:31:38  <arubi> hm.  so you're saying that I'd still need to know the history up until that new genesis block, right?  I understand the issue if so
348 2016-05-13T18:32:05  <sipa> you don't need to know it if you trust that it's there
349 2016-05-13T18:32:16  <sipa> but that's no different from copying a chainstate from someone
350 2016-05-13T18:32:38  <arubi> right. thanks sipa.
351 2016-05-13T18:32:45  <sipa> there are ideas about committing the hash of the UTXO set to the blockchain
352 2016-05-13T18:33:08  <arubi> oh, so the utxo set could be shared?
353 2016-05-13T18:33:17  <instagibbs> arubi, miners would commit to utxo set
354 2016-05-13T18:33:26  <sipa> which would allow you to for example download/verify headers up to 1000 blocks in the past, then download a snapshot of the utxo set at that point from anyone, and verify that it matches the hash in the blockchain
355 2016-05-13T18:33:33  <instagibbs> spv trust for utxo set in other words
356 2016-05-13T18:33:52  <sipa> HOWEVER that still involved trust: you've now switched from a model of no trust in history to trusting that miners would not commit to an invalid history
357 2016-05-13T18:34:06  <sipa> which in practice may very well be sufficient, but it's a very different security model
358 2016-05-13T18:35:01  <arubi> so I'd really be trusting the network to verify and relay the chain correctly to me?
359 2016-05-13T18:35:12  <sipa> no
360 2016-05-13T18:35:24  <sipa> you'd be trusting miners to not build a chain with invalid history
361 2016-05-13T18:35:55  <arubi> but that's impossible now, if the network verifies
362 2016-05-13T18:36:14  <sipa> that's true but irrelevant
363 2016-05-13T18:36:22  <sipa> it's impossible because YOU verify, if you run a full node
364 2016-05-13T18:36:41  <sipa> if you assume the network verifies for you, you're trusting them
365 2016-05-13T18:37:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
366 2016-05-13T18:37:17  <arubi> right, so how is an spv node different in verifying the blocks?  is it about verifying the transactions themselves?
367 2016-05-13T18:38:49  <sipa> an spv node assumes that miners will not produce an invalid chain
368 2016-05-13T18:39:19  <sipa> (or that they're only connected to honest full nodes)
369 2016-05-13T18:40:59  <arubi> I think I understand, like you mentioned that they verify the headers (and not the block itself?), they trust that what they're verifying is the actual chain verifying nodes use
370 2016-05-13T18:41:22  <sipa> no, they assume that miners would not make an invalid chain
371 2016-05-13T18:41:40  <sipa> (or that full nodes would filter out such an invalid chain for them)
372 2016-05-13T18:43:32  <arubi> that's what I meant by "the actual chain..".  sure assuming miners won't produce an invalid chain is understandable, but if you somehow only connect to honest nodes, then you will not get it, and I see where this requires trust
373 2016-05-13T18:43:54  *** ebfull has quit IRC
374 2016-05-13T18:44:50  <sipa> well there is no "the actual chain", different nodes can have a different idea of what chain to accept
375 2016-05-13T18:45:58  <arubi> true.  the best chain used by the reference client is probably more specific, but also impossible to expect from just connecting to random nodes
376 2016-05-13T18:46:56  <sipa> no no, not by the reference client
377 2016-05-13T18:47:14  <sipa> every individual node, even if they are running the same software, could have a different idea of what the best chain is
378 2016-05-13T18:47:31  <arubi> I know, but there is physically only one best chain
379 2016-05-13T18:47:35  *** earlest has joined #bitcoin-core-dev
380 2016-05-13T18:47:50  <sipa> no
381 2016-05-13T18:47:51  <arubi> or maybe multiple "same height" chains.. that's bad in itself
382 2016-05-13T18:48:06  <sipa> every indidual node has an idea of what the best chain is
383 2016-05-13T18:48:14  <sipa> there is no guarantee that other nodes have the same idea
384 2016-05-13T18:48:44  <arubi> I get that, but really the chain with the most work will overtake the others quickly, no?
385 2016-05-13T18:48:54  <sipa> that's an assumption :)
386 2016-05-13T18:49:11  <arubi> it worked so far, even on the chaos that is testnet :)
387 2016-05-13T18:49:13  <sipa> and the correctness of the system relies on it, but it's anot a given
388 2016-05-13T18:49:24  <sipa> it's the result of economic and technical properties
389 2016-05-13T18:50:26  <sipa> and you change those if nodes in the network don't validate fully
390 2016-05-13T18:50:34  *** bysherper has quit IRC
391 2016-05-13T18:51:37  *** mrkent has joined #bitcoin-core-dev
392 2016-05-13T18:51:59  <arubi> or forks intentionally, or fails due to a bug, right.  correctness of the best chain that's advertised to my node is something I really took for granted until now
393 2016-05-13T18:52:13  <arubi> well, not my fully verifying node
394 2016-05-13T19:03:41  <Chris_Stewart_5> sipa: An example of a node not knowing what the longest chain could be is a sustained sybil attack correct?
395 2016-05-13T19:04:32  <sipa> Chris_Stewart_5: or any normal fork
396 2016-05-13T19:04:57  <sipa> Chris_Stewart_5: it's not so much "a node does not know what the best chain is", it is that there _is_ no best chain
397 2016-05-13T19:05:10  <sipa> best chain is something local to your client
398 2016-05-13T19:06:10  <sipa> and we build a system that aims to provide convergence: making sure that over time, blocks in the history of different nodes' best chains end up being the same over tim
399 2016-05-13T19:09:39  *** Don_John has joined #bitcoin-core-dev
400 2016-05-13T19:10:09  *** Don_John has quit IRC
401 2016-05-13T19:10:42  *** JackH has quit IRC
402 2016-05-13T19:21:17  <Chris_Stewart_5> interesting. Thanks - it's easy to forget we have 5k individual computers running on this network that need to reach convergence on what is right
403 2016-05-13T19:22:27  *** muftop has quit IRC
404 2016-05-13T20:11:38  *** Chris_Stewart_5 has quit IRC
405 2016-05-13T20:13:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
406 2016-05-13T20:24:34  *** CubicEarth has quit IRC
407 2016-05-13T20:25:09  *** CubicEarth has joined #bitcoin-core-dev
408 2016-05-13T20:32:39  *** Chris_Stewart_5 has quit IRC
409 2016-05-13T20:47:35  *** CubicEarth has quit IRC
410 2016-05-13T20:47:48  *** CubicEarth has joined #bitcoin-core-dev
411 2016-05-13T20:48:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
412 2016-05-13T20:48:48  *** cjcj has quit IRC
413 2016-05-13T21:07:52  *** cryptapus_ has joined #bitcoin-core-dev
414 2016-05-13T21:12:51  *** cryptapus_ has quit IRC
415 2016-05-13T21:14:09  *** nickler has quit IRC
416 2016-05-13T21:14:25  *** nickler has joined #bitcoin-core-dev
417 2016-05-13T21:17:23  <kanzure> those sleeps in the tests are architecturally unfortunate :( shouldn't this be stuff that gets pinged/notified instead of waiting forever aimlessly? e.g. crash could have happened seconds ago.
418 2016-05-13T21:17:59  <kanzure> or is that intentional etc...
419 2016-05-13T21:28:07  *** belcher has joined #bitcoin-core-dev
420 2016-05-13T21:30:28  *** BashCo has joined #bitcoin-core-dev
421 2016-05-13T21:32:32  *** BashCo_ has quit IRC
422 2016-05-13T21:35:51  *** nickler has quit IRC
423 2016-05-13T21:35:58  *** cryptapus is now known as cryptapus_afk
424 2016-05-13T21:37:46  *** nickler has joined #bitcoin-core-dev
425 2016-05-13T21:45:27  *** BashCo_ has joined #bitcoin-core-dev
426 2016-05-13T21:47:12  *** BashCo has quit IRC
427 2016-05-13T21:59:26  *** BashCo has joined #bitcoin-core-dev
428 2016-05-13T22:02:09  *** BashCo_ has quit IRC
429 2016-05-13T22:14:04  *** ghtdak has quit IRC
430 2016-05-13T22:14:45  *** supasonic has joined #bitcoin-core-dev
431 2016-05-13T22:14:48  *** ghtdak has joined #bitcoin-core-dev
432 2016-05-13T22:17:58  *** BashCo_ has joined #bitcoin-core-dev
433 2016-05-13T22:20:33  *** BashCo has quit IRC
434 2016-05-13T22:31:32  *** CubicEarth has quit IRC
435 2016-05-13T22:32:04  *** CubicEarth has joined #bitcoin-core-dev
436 2016-05-13T22:32:18  *** CubicEarth has joined #bitcoin-core-dev
437 2016-05-13T22:36:09  *** bysherper has joined #bitcoin-core-dev
438 2016-05-13T22:39:04  *** earlest has quit IRC
439 2016-05-13T22:41:16  *** Guyver2 has quit IRC
440 2016-05-13T22:42:42  *** Giszmo has quit IRC
441 2016-05-13T22:43:43  *** earlest has joined #bitcoin-core-dev
442 2016-05-13T22:43:58  *** Giszmo has joined #bitcoin-core-dev
443 2016-05-13T22:46:01  *** CubicEarth has quit IRC
444 2016-05-13T22:46:34  *** bysherper has quit IRC