12016-05-13T00:08:38  *** alpalp has joined #bitcoin-core-dev
  22016-05-13T00:08:54  *** alpalp has joined #bitcoin-core-dev
  32016-05-13T00:14:39  <sipa> $ ./walletbackup.py
  42016-05-13T00:14:44  <sipa> INFO: Restoring using dumped wallet
  52016-05-13T00:14:44  <sipa> Unexpected exception caught during testing: BrokenPipeError(32, 'Broken pipe')
  62016-05-13T00:14:51  <sipa> Stopping nodes
  72016-05-13T00:14:51  <sipa> WARN: Unable to stop node: CannotSendRequest('Request-sent',)
  82016-05-13T00:15:32  <gmaxwell> sipa: patrick got to you?
  92016-05-13T00:15:49  <gmaxwell> the question is-- why doesn't travis see it as failing?
 102016-05-13T00:18:13  <sipa> gmaxwell, wumpus, jonasschnelli:
 112016-05-13T00:19:07  <gmaxwell> sipa, sipa, sipa
 122016-05-13T00:20:21  <sipa> gmaxwell: are you wumpus and jonasschnelli?
 132016-05-13T00:20:44  <sipa> i wanted to paste my rorx results, but they seem to have disappeared into my terminal's forgotten history
 142016-05-13T00:20:57  <gmaxwell> No, are you?
 152016-05-13T00:21:10  <sipa> both rorxes were similar, and fastest
 162016-05-13T00:21:19  <gmaxwell> well, see.. I saved them seconds of disappointment by wisely preempting your summons.
 172016-05-13T00:23:55  <gmaxwell> sipa: did you see the usenix paper I linked to you some indeterminable number of days ago?
 182016-05-13T00:24:18  <sipa> i skimmed it, not enough to actually find the xor trick you were referring to
 192016-05-13T00:25:19  <gmaxwell> are you familar with cuckoo hashing?
 202016-05-13T00:25:32  *** d4de has joined #bitcoin-core-dev
 212016-05-13T00:25:59  <sipa> yes
 222016-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.
 232016-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.
 242016-05-13T00:29:35  <gmaxwell> (and you don't need to track which one it was in, since the same xor relates them)
 252016-05-13T00:32:21  <sipa> gmaxwell, wumpus, jonasschnelli:
 262016-05-13T00:32:23  <sipa> SHA256_avx,175,0.00575656,0.0058105,0.00575941
 272016-05-13T00:32:23  <sipa> SHA256_basic,119,0.0088715,0.00893307,0.00887388
 282016-05-13T00:32:23  <sipa> SHA256_rorx,223,0.00482899,0.004861,0.00483046
 292016-05-13T00:32:23  <sipa> SHA256_rorx_x8ms,223,0.00475737,0.0047915,0.00476165
 302016-05-13T00:32:25  <sipa> SHA256_sse4,175,0.00574069,0.00577295,0.00574323
 312016-05-13T00:33:09  <sipa> i7-4800MQ, fixed at 2.6 GHz
 322016-05-13T00:34:12  *** alpalp has quit IRC
 332016-05-13T00:34:13  <phantomcircuit> is the first column cycle count?
 342016-05-13T00:34:25  *** alpalp has joined #bitcoin-core-dev
 352016-05-13T00:34:25  *** alpalp has joined #bitcoin-core-dev
 362016-05-13T00:34:31  <sipa> iteration count
 372016-05-13T00:34:35  <gmaxwell> phantomcircuit: it's number of times the freaky bench innerloop ran.
 382016-05-13T00:34:36  <phantomcircuit> ah
 392016-05-13T00:34:38  <sipa> how many tests were done
 402016-05-13T00:34:53  <sipa> each doing 1 MB of data
 412016-05-13T00:35:01  <phantomcircuit> ok
 422016-05-13T00:35:21  <phantomcircuit> neat
 432016-05-13T00:35:31  <gmaxwell> really for our usage running with 32 and 64 bytes of data is much more interesting.
 442016-05-13T00:35:56  <gmaxwell> might be useful to see if that changes the numbers at all... perhaps gives AVX a purpose for existing? :)
 452016-05-13T00:36:07  <sipa> sure, but it's just a proxy for the number of sha256 compression function runs
 462016-05-13T00:36:11  *** flybyguy has joined #bitcoin-core-dev
 472016-05-13T00:36:42  <gmaxwell> ah duh right, it doesn't have a finialization, so it's not going to change.
 482016-05-13T00:37:01  *** flybyguy has left #bitcoin-core-dev
 492016-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
 502016-05-13T00:37:31  <phantomcircuit> gmaxwell, loading into the right registers takes some amount of work
 512016-05-13T00:37:37  <sipa> making it look wildly better than rorx
 522016-05-13T00:38:05  <phantomcircuit> sipa, test on a build box?
 532016-05-13T00:38:22  <phantomcircuit> gmaxwell, any idea if those have turbo or not?
 542016-05-13T00:38:29  <sipa> turbo is easy to disable
 552016-05-13T00:41:11  *** Ylbam has quit IRC
 562016-05-13T00:45:55  *** laurentmt has joined #bitcoin-core-dev
 572016-05-13T00:47:12  *** d4de has quit IRC
 582016-05-13T00:47:42  <sipa> on our 56-core machine:
 592016-05-13T00:47:44  <sipa> SHA256_avx,255,0.00397131,0.00401497,0.00397456
 602016-05-13T00:47:44  <sipa> SHA256_basic,175,0.00599988,0.00604987,0.00600181
 612016-05-13T00:47:44  <sipa> SHA256_rorx,319,0.00334556,0.003407,0.00334662
 622016-05-13T00:47:44  <sipa> SHA256_rorx_x8ms,319,0.00328553,0.00332999,0.00328678
 632016-05-13T00:47:46  <sipa> SHA256_sse4,255,0.00395919,0.00401807,0.00396108
 642016-05-13T00:47:53  <sipa> gmaxwell: what cpu is it?
 652016-05-13T00:51:41  <sipa> i'm surprised that our C code is only 45% slower than intel's optimized asm code
 662016-05-13T00:52:39  *** laurentmt has quit IRC
 672016-05-13T00:56:07  <gmaxwell> the 56-core are broadwell-ep
 682016-05-13T00:56:29  <gmaxwell> but 'only' at 2.2GHz.
 692016-05-13T00:58:19  <phantomcircuit> sipa, none of those are parallel calculation right?
 702016-05-13T00:58:52  <sipa> indeed, all single threaded
 712016-05-13T01:00:27  *** Guest13955 has quit IRC
 722016-05-13T01:00:27  *** Guest13955 has joined #bitcoin-core-dev
 732016-05-13T01:00:27  *** Guest13955 is now known as amiller
 742016-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.
 752016-05-13T01:01:19  <sipa> very doable inside merkle trees, though
 762016-05-13T01:01:40  *** mrkent_ has joined #bitcoin-core-dev
 772016-05-13T01:02:11  <gmaxwell> Yes. though thats pretty much the only place where it's very doable.
 782016-05-13T01:02:25  <sipa> also the place where it probably matters most
 792016-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. :)
 802016-05-13T01:04:29  *** mrkent has quit IRC
 812016-05-13T01:05:09  *** dermoth_ has quit IRC
 822016-05-13T01:05:42  *** dermoth_ has joined #bitcoin-core-dev
 832016-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.
 842016-05-13T01:12:22  *** jtimon has quit IRC
 852016-05-13T01:27:43  *** fengling has joined #bitcoin-core-dev
 862016-05-13T01:34:11  *** Giszmo has quit IRC
 872016-05-13T01:35:23  *** Giszmo has joined #bitcoin-core-dev
 882016-05-13T01:40:01  *** Alopex has quit IRC
 892016-05-13T01:41:07  *** Alopex has joined #bitcoin-core-dev
 902016-05-13T02:02:03  *** Giszmo has quit IRC
 912016-05-13T02:13:04  *** helo has quit IRC
 922016-05-13T02:14:38  *** helo has joined #bitcoin-core-dev
 932016-05-13T02:22:06  *** Giszmo has joined #bitcoin-core-dev
 942016-05-13T02:36:03  *** alpalp has quit IRC
 952016-05-13T02:42:43  *** CubicEarth has joined #bitcoin-core-dev
 962016-05-13T02:44:06  *** Chris_Stewart_5 has quit IRC
 972016-05-13T02:51:45  *** achow101 has quit IRC
 982016-05-13T02:53:00  <GitHub130> [bitcoin] sipa opened pull request #8051: Fix walletbackup.py failure (master...fixwalletbackup) https://github.com/bitcoin/bitcoin/pull/8051
 992016-05-13T02:56:55  *** dermoth__ has joined #bitcoin-core-dev
1002016-05-13T02:59:30  *** dermoth_ has quit IRC
1012016-05-13T03:02:09  <gmaxwell> sipa: considering your PR comments might it be a bit strong to call that 'fix'?  rather than 'mysteriously stir'? :)
1022016-05-13T03:04:15  <sipa> gmaxwell: well, it's reproducible :)
1032016-05-13T03:04:26  *** davec has quit IRC
1042016-05-13T03:04:28  <sipa> maybe i should call it "seemingly fix"
1052016-05-13T03:04:44  <sipa> done
1062016-05-13T03:04:53  *** mrkent_ has quit IRC
1072016-05-13T03:05:04  *** davec has joined #bitcoin-core-dev
1082016-05-13T03:05:07  <gmaxwell> presumably it fails for you because your computer is fast and travis isn't.
1092016-05-13T03:06:09  *** lecusemble has quit IRC
1102016-05-13T03:06:18  <sipa> hmm, i started off by adding sleeps and that didn't help
1112016-05-13T03:06:30  <sipa> but let me try again, by adding a sleep exactly there
1122016-05-13T03:19:03  <sipa> gmaxwell: the sync blocks there causes a sleep of 1-2 seconds
1132016-05-13T03:19:11  <sipa> gmaxwell: an explicit sleep of 60s does not fix it
1142016-05-13T03:23:08  *** lecusemble has joined #bitcoin-core-dev
1152016-05-13T03:23:44  <gmaxwell> uh how does that make any sense?
1162016-05-13T03:23:59  <sipa> sense, it makes none
1172016-05-13T04:52:31  *** lecusemble has quit IRC
1182016-05-13T05:02:02  *** kadoban has quit IRC
1192016-05-13T05:04:45  *** lecusemble has joined #bitcoin-core-dev
1202016-05-13T05:13:12  *** paveljanik has quit IRC
1212016-05-13T05:31:53  *** gabridome has joined #bitcoin-core-dev
1222016-05-13T05:38:11  *** Arnavion has quit IRC
1232016-05-13T05:38:38  *** Arnavion has joined #bitcoin-core-dev
1242016-05-13T05:47:45  *** kadoban has joined #bitcoin-core-dev
1252016-05-13T05:52:01  *** Giszmo has quit IRC
1262016-05-13T05:53:22  *** Arnavion has quit IRC
1272016-05-13T05:54:04  *** Arnavion has joined #bitcoin-core-dev
1282016-05-13T06:11:55  *** Ylbam has joined #bitcoin-core-dev
1292016-05-13T06:14:52  *** Arnavion has quit IRC
1302016-05-13T06:15:08  *** Arnavion has joined #bitcoin-core-dev
1312016-05-13T06:47:44  *** gabridome has quit IRC
1322016-05-13T06:53:02  <jonasschnelli> sipa: I read something in the logs: is walletbackup.py fixed?
1332016-05-13T06:53:20  * jonasschnelli reading https://github.com/bitcoin/bitcoin/pull/8051#issuecomment-218943822
1342016-05-13T06:53:29  <sipa> jonasschnelli: for me it is
1352016-05-13T06:54:05  *** gabridome has joined #bitcoin-core-dev
1362016-05-13T07:02:32  <jonasschnelli> sipa: I can't reproduce the issue... but you fix looks strange. :)
1372016-05-13T07:06:33  <sipa> without it, i just can't run rpc_tests.py
1382016-05-13T07:06:38  <sipa> it runs forever
1392016-05-13T07:08:24  <jonasschnelli> But you can run walletbackup.py independent?
1402016-05-13T07:10:46  <sipa> no
1412016-05-13T07:10:54  <sipa> see the paste in the PR
1422016-05-13T07:10:56  <jonasschnelli> hmm...
1432016-05-13T07:11:01  <jonasschnelli> Yes. Saw it...
1442016-05-13T07:11:10  <jonasschnelli> like to debug it locally.
1452016-05-13T07:12:26  *** JackH has joined #bitcoin-core-dev
1462016-05-13T07:17:32  *** gabridome has quit IRC
1472016-05-13T07:18:54  <sipa> maybe it depends on python version or something else
1482016-05-13T07:19:09  <sipa> but something very fishy is going on, as it's not just a race condition
1492016-05-13T07:20:36  *** CubicEarth has quit IRC
1502016-05-13T07:21:08  *** gabridome has joined #bitcoin-core-dev
1512016-05-13T07:21:11  *** CubicEarth has joined #bitcoin-core-dev
1522016-05-13T07:24:07  *** BashCo has quit IRC
1532016-05-13T07:24:44  *** BashCo has joined #bitcoin-core-dev
1542016-05-13T07:25:55  *** CubicEarth has quit IRC
1552016-05-13T07:26:10  *** CubicEarth has joined #bitcoin-core-dev
1562016-05-13T07:29:29  *** BashCo has quit IRC
1572016-05-13T07:30:47  *** gabridome has quit IRC
1582016-05-13T07:32:01  *** gabridome has joined #bitcoin-core-dev
1592016-05-13T07:34:53  *** gabridome has quit IRC
1602016-05-13T07:45:38  *** BashCo has joined #bitcoin-core-dev
1612016-05-13T07:50:24  *** zibbo has quit IRC
1622016-05-13T07:51:36  *** CubicEarth has quit IRC
1632016-05-13T07:53:21  *** kadoban has quit IRC
1642016-05-13T07:58:57  *** CubicEarth has joined #bitcoin-core-dev
1652016-05-13T07:59:51  *** Evel-Knievel has quit IRC
1662016-05-13T08:00:24  *** Evel-Knievel has joined #bitcoin-core-dev
1672016-05-13T08:03:51  *** CubicEarth has quit IRC
1682016-05-13T08:08:18  *** CyrusV has quit IRC
1692016-05-13T08:08:29  *** CyrusV has joined #bitcoin-core-dev
1702016-05-13T08:22:08  *** AaronvanW has joined #bitcoin-core-dev
1712016-05-13T08:31:33  *** molz has quit IRC
1722016-05-13T08:47:23  *** grassass has quit IRC
1732016-05-13T08:59:13  *** Guyver2 has joined #bitcoin-core-dev
1742016-05-13T09:04:10  *** nub has joined #bitcoin-core-dev
1752016-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
1762016-05-13T09:06:27  <sipa> yes, it wod be possible with a hars fork
1772016-05-13T09:06:43  <sipa> a hars fork could also turn bitcoin into a frontend for paypal
1782016-05-13T09:06:47  <sipa> *hard
1792016-05-13T09:07:02  <nub> could you explain that?
1802016-05-13T09:07:32  <nub> is that bad?
1812016-05-13T09:07:36  <sipa> a hard fork is replacing the system with another system, where all participants agrwe to switch to different software
1822016-05-13T09:07:44  <sipa> it can change anything
1832016-05-13T09:07:57  <nub> could a soft fork change block time?
1842016-05-13T09:08:08  <sipa> the question "is x possible with a hard fork?" always has "yes" as answer
1852016-05-13T09:08:15  <sipa> no, a soft fork can't do that
1862016-05-13T09:08:46  <sipa> it would also be a bad idea, as it would result is 10 times higher mining centralization pressure
1872016-05-13T09:08:58  <sipa> and confirmations that have less meaning
1882016-05-13T09:09:43  *** grassass has joined #bitcoin-core-dev
1892016-05-13T09:09:44  <gmaxwell> sipa: actually not 10 times higher, but likely much higher, since the relationship is non-linear. :)
1902016-05-13T09:09:57  <nub> how can we speed up transactions?
1912016-05-13T09:10:01  <nub> or confirmations
1922016-05-13T09:10:14  <sipa> nub: why do you want to do that?
1932016-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
1942016-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....
1952016-05-13T09:10:56  <sipa> there is simply no way to get global consensus within seconds
1962016-05-13T09:11:03  <nub> that currently takes far too long
1972016-05-13T09:11:14  <sipa> 1 minute is also far too long
1982016-05-13T09:11:34  <sipa> you just can't use bitcoin blockchain transactions for that purpose
1992016-05-13T09:11:45  <nub> what if the purchaser uses the same hosted wallet platfrom as the seller
2002016-05-13T09:12:03  <nub> then it could be instant and no bitcoin would need to be sent\
2012016-05-13T09:12:06  <sipa> that wouls be one example of another technology
2022016-05-13T09:12:29  <sipa> now you're using the database of the wallet provider rather than the blockchain
2032016-05-13T09:12:57  <nub> something like cassandra replicated to datacenters all around the world
2042016-05-13T09:13:25  <sipa> if you have a centrally trusted party running those datacenters, it's easy :)
2052016-05-13T09:13:42  <sipa> but that's not a luxury we have for bitcoin the base technology
2062016-05-13T09:14:12  <nub> whats the aim of bitcoin now?
2072016-05-13T09:14:18  <sipa> this discussion probably belongs in #bitcoin
2082016-05-13T09:14:27  <nub> wanna move to there?
2092016-05-13T09:14:40  <sipa> i'm going to sleep, but feel free :)
2102016-05-13T09:15:15  <nub> is it ok to discuss how a hard fork could work here?
2112016-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
2122016-05-13T09:16:09  <sipa> and no, the interblock time is not going to change
2132016-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
2142016-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
2152016-05-13T09:17:28  <sipa> you'd still need to convince the entire world to switch before that fkag date
2162016-05-13T09:17:38  <nub> make the app do it automatically
2172016-05-13T09:17:41  <nub> bitcoin core
2182016-05-13T09:17:54  <sipa> bitcoin core does not decide what the rules of the network are
2192016-05-13T09:18:01  <nub> fair enough
2202016-05-13T09:18:09  <sipa> it very intentionally does not have an auto update function
2212016-05-13T09:18:18  <sipa> as developers shouldn't be in charge of the rules
2222016-05-13T09:18:20  <nub> it should
2232016-05-13T09:18:26  <sipa> it absolutely should not
2242016-05-13T09:18:28  <nub> and if not updated you can't connect
2252016-05-13T09:18:37  <sipa> it would make developers central bankers
2262016-05-13T09:18:39  <nub> devs could add whatever they want
2272016-05-13T09:19:00  <nub> what if i were to hire them all?
2282016-05-13T09:19:06  <sipa> try me
2292016-05-13T09:19:17  <sipa> i'd find another job
2302016-05-13T09:19:47  <nub> a surcharge could be added to mining which goes to devs instead
2312016-05-13T09:20:06  <sipa> but even if you could, hopefully the ecosystem would protest and stop using bitcoin core
2322016-05-13T09:20:38  <nub> wouldnt a 1 minute block time be welcomed for faster trasnactions?
2332016-05-13T09:20:42  <sipa> no
2342016-05-13T09:21:01  <sipa> it's a misconception that that would be beneficial
2352016-05-13T09:21:12  <nub> it works for litecoin
2362016-05-13T09:21:37  <sipa> "it works" does not mean it is better
2372016-05-13T09:22:10  <nub> would bitcoin devs be interested in incorperating and being paid to develop?
2382016-05-13T09:22:33  <nub> in america
2392016-05-13T09:22:53  <sipa> see https://bitcoincore.org/en/2016/04/04/announcing_sponsorship_programme/
2402016-05-13T09:23:00  <nub> banks want there software to run on blockchain technology
2412016-05-13T09:23:08  <nub> we could be running the banks
2422016-05-13T09:23:10  <sipa> they don't need proof of work or miners
2432016-05-13T09:23:25  <nub> they dont
2442016-05-13T09:23:39  <nub> they need a special client which can create and destroy coins
2452016-05-13T09:23:46  <sipa> this is getting off topic, as you're not talking about developing bitcoin
2462016-05-13T09:23:52  <sipa> #bitcoin please
2472016-05-13T09:57:28  *** donal has joined #bitcoin-core-dev
2482016-05-13T10:03:19  *** fengling has quit IRC
2492016-05-13T10:05:11  *** fengling has joined #bitcoin-core-dev
2502016-05-13T10:09:39  *** fengling has quit IRC
2512016-05-13T10:18:56  *** fengling has joined #bitcoin-core-dev
2522016-05-13T10:28:42  *** cjcj has quit IRC
2532016-05-13T10:32:17  *** fengling has quit IRC
2542016-05-13T10:41:34  <nub> could a soft fork increase block rewards
2552016-05-13T10:42:20  <gmaxwell> nub: no, and please take further discussion elsewhere.
2562016-05-13T11:03:12  *** laurentmt has joined #bitcoin-core-dev
2572016-05-13T11:03:33  *** laurentmt has quit IRC
2582016-05-13T11:14:44  *** cjcj has joined #bitcoin-core-dev
2592016-05-13T11:24:31  *** LeMiner has quit IRC
2602016-05-13T11:36:43  *** LeMiner has joined #bitcoin-core-dev
2612016-05-13T11:47:44  *** jtimon has joined #bitcoin-core-dev
2622016-05-13T11:52:36  *** cryptapus_afk is now known as cryptapus
2632016-05-13T11:53:08  *** jannes has joined #bitcoin-core-dev
2642016-05-13T12:17:52  *** cfields has quit IRC
2652016-05-13T12:17:59  *** cfields has joined #bitcoin-core-dev
2662016-05-13T12:22:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2672016-05-13T12:24:15  *** paveljanik has joined #bitcoin-core-dev
2682016-05-13T12:24:15  *** paveljanik has joined #bitcoin-core-dev
2692016-05-13T12:28:04  *** alpalp has joined #bitcoin-core-dev
2702016-05-13T12:28:04  *** alpalp has joined #bitcoin-core-dev
2712016-05-13T12:29:14  *** Chris_Stewart_5 has quit IRC
2722016-05-13T12:30:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2732016-05-13T12:55:03  *** alpalp has quit IRC
2742016-05-13T12:58:03  *** molz has joined #bitcoin-core-dev
2752016-05-13T13:57:03  *** Chris_Stewart_5 has quit IRC
2762016-05-13T14:02:40  *** jannes has quit IRC
2772016-05-13T14:09:00  *** Giszmo has joined #bitcoin-core-dev
2782016-05-13T14:13:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2792016-05-13T14:36:26  *** nub has left #bitcoin-core-dev
2802016-05-13T14:39:07  *** zooko has joined #bitcoin-core-dev
2812016-05-13T14:58:23  *** CubicEarth has joined #bitcoin-core-dev
2822016-05-13T15:16:07  *** CubicEarth has quit IRC
2832016-05-13T15:18:48  *** earlest has joined #bitcoin-core-dev
2842016-05-13T15:22:04  *** bysherper has quit IRC
2852016-05-13T15:29:05  *** muftop has quit IRC
2862016-05-13T15:29:26  *** muftop has joined #bitcoin-core-dev
2872016-05-13T15:31:26  *** cryptapus_ has joined #bitcoin-core-dev
2882016-05-13T15:31:26  *** cryptapus_ has joined #bitcoin-core-dev
2892016-05-13T15:40:21  *** zooko` has joined #bitcoin-core-dev
2902016-05-13T15:41:48  *** zooko has quit IRC
2912016-05-13T15:43:35  *** BashCo has quit IRC
2922016-05-13T15:43:48  *** CubicEarth has joined #bitcoin-core-dev
2932016-05-13T15:44:11  *** BashCo has joined #bitcoin-core-dev
2942016-05-13T15:48:34  *** BashCo has quit IRC
2952016-05-13T15:48:55  *** bysherper has joined #bitcoin-core-dev
2962016-05-13T15:52:04  *** earlest has quit IRC
2972016-05-13T15:56:56  *** CubicEarth has quit IRC
2982016-05-13T16:07:05  *** BashCo has joined #bitcoin-core-dev
2992016-05-13T16:09:16  *** CubicEarth has joined #bitcoin-core-dev
3002016-05-13T16:16:30  *** CubicEarth has quit IRC
3012016-05-13T16:17:23  *** mrkent has joined #bitcoin-core-dev
3022016-05-13T16:19:23  *** mrkent has quit IRC
3032016-05-13T16:24:09  *** CubicEarth has joined #bitcoin-core-dev
3042016-05-13T16:33:44  *** BashCo_ has joined #bitcoin-core-dev
3052016-05-13T16:37:28  *** BashCo has quit IRC
3062016-05-13T16:39:54  *** zooko` has quit IRC
3072016-05-13T16:43:45  *** CubicEarth has quit IRC
3082016-05-13T16:44:13  *** CubicEarth has joined #bitcoin-core-dev
3092016-05-13T16:50:04  *** cryptapus_ has quit IRC
3102016-05-13T16:56:23  *** btcdrak has quit IRC
3112016-05-13T16:56:23  *** binns has quit IRC
3122016-05-13T16:56:25  *** ibrightly has quit IRC
3132016-05-13T16:56:26  *** zmanian__ has quit IRC
3142016-05-13T16:56:26  *** CodeShark has quit IRC
3152016-05-13T16:56:26  *** NicolasDorier has quit IRC
3162016-05-13T17:04:20  *** cryptapus_ has joined #bitcoin-core-dev
3172016-05-13T17:05:28  *** Chris_Stewart_5 has quit IRC
3182016-05-13T17:07:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3192016-05-13T17:12:38  *** binns has joined #bitcoin-core-dev
3202016-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
3212016-05-13T17:17:47  *** ibrightly has joined #bitcoin-core-dev
3222016-05-13T17:17:58  *** zmanian__ has joined #bitcoin-core-dev
3232016-05-13T17:20:14  *** btcdrak has joined #bitcoin-core-dev
3242016-05-13T17:23:48  *** CubicEarth has quit IRC
3252016-05-13T17:24:41  *** CubicEarth has joined #bitcoin-core-dev
3262016-05-13T17:25:29  *** CubicEarth has joined #bitcoin-core-dev
3272016-05-13T17:30:31  *** CodeShark has joined #bitcoin-core-dev
3282016-05-13T17:34:05  *** NicolasDorier has joined #bitcoin-core-dev
3292016-05-13T17:42:52  *** wallet42 has quit IRC
3302016-05-13T17:43:38  *** wallet42 has joined #bitcoin-core-dev
3312016-05-13T17:44:00  *** CubicEarth has quit IRC
3322016-05-13T17:44:32  *** CubicEarth has joined #bitcoin-core-dev
3332016-05-13T17:46:26  *** CubicEarth has quit IRC
3342016-05-13T17:47:42  *** CubicEarth has joined #bitcoin-core-dev
3352016-05-13T18:21:32  *** Chris_Stewart_5 has quit IRC
3362016-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
3372016-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
3382016-05-13T18:23:53  <sipa> arubi: we can always declare a new block as the genesis block; just snapshot its utxo set
3392016-05-13T18:25:47  <arubi> sipa, is that the same?  why not do it?
3402016-05-13T18:25:57  *** cryptapus_ has quit IRC
3412016-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
3422016-05-13T18:28:05  <sipa> arubi: you can do it. copy your chainstatre directory from someone you trust
3432016-05-13T18:28:16  <arubi> but trust isn't needed if there's a mechanism like I suggested, right?  (maybe not)
3442016-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
3452016-05-13T18:30:08  <sipa> and there is no way to verify that
3462016-05-13T18:30:33  <sipa> we have no technology that can verify the correctness of the blockchain without seeing it :)
3472016-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
3482016-05-13T18:32:05  <sipa> you don't need to know it if you trust that it's there
3492016-05-13T18:32:16  <sipa> but that's no different from copying a chainstate from someone
3502016-05-13T18:32:38  <arubi> right. thanks sipa.
3512016-05-13T18:32:45  <sipa> there are ideas about committing the hash of the UTXO set to the blockchain
3522016-05-13T18:33:08  <arubi> oh, so the utxo set could be shared?
3532016-05-13T18:33:17  <instagibbs> arubi, miners would commit to utxo set
3542016-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
3552016-05-13T18:33:33  <instagibbs> spv trust for utxo set in other words
3562016-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
3572016-05-13T18:34:06  <sipa> which in practice may very well be sufficient, but it's a very different security model
3582016-05-13T18:35:01  <arubi> so I'd really be trusting the network to verify and relay the chain correctly to me?
3592016-05-13T18:35:12  <sipa> no
3602016-05-13T18:35:24  <sipa> you'd be trusting miners to not build a chain with invalid history
3612016-05-13T18:35:55  <arubi> but that's impossible now, if the network verifies
3622016-05-13T18:36:14  <sipa> that's true but irrelevant
3632016-05-13T18:36:22  <sipa> it's impossible because YOU verify, if you run a full node
3642016-05-13T18:36:41  <sipa> if you assume the network verifies for you, you're trusting them
3652016-05-13T18:37:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3662016-05-13T18:37:17  <arubi> right, so how is an spv node different in verifying the blocks?  is it about verifying the transactions themselves?
3672016-05-13T18:38:49  <sipa> an spv node assumes that miners will not produce an invalid chain
3682016-05-13T18:39:19  <sipa> (or that they're only connected to honest full nodes)
3692016-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
3702016-05-13T18:41:22  <sipa> no, they assume that miners would not make an invalid chain
3712016-05-13T18:41:40  <sipa> (or that full nodes would filter out such an invalid chain for them)
3722016-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
3732016-05-13T18:43:54  *** ebfull has quit IRC
3742016-05-13T18:44:50  <sipa> well there is no "the actual chain", different nodes can have a different idea of what chain to accept
3752016-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
3762016-05-13T18:46:56  <sipa> no no, not by the reference client
3772016-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
3782016-05-13T18:47:31  <arubi> I know, but there is physically only one best chain
3792016-05-13T18:47:35  *** earlest has joined #bitcoin-core-dev
3802016-05-13T18:47:50  <sipa> no
3812016-05-13T18:47:51  <arubi> or maybe multiple "same height" chains.. that's bad in itself
3822016-05-13T18:48:06  <sipa> every indidual node has an idea of what the best chain is
3832016-05-13T18:48:14  <sipa> there is no guarantee that other nodes have the same idea
3842016-05-13T18:48:44  <arubi> I get that, but really the chain with the most work will overtake the others quickly, no?
3852016-05-13T18:48:54  <sipa> that's an assumption :)
3862016-05-13T18:49:11  <arubi> it worked so far, even on the chaos that is testnet :)
3872016-05-13T18:49:13  <sipa> and the correctness of the system relies on it, but it's anot a given
3882016-05-13T18:49:24  <sipa> it's the result of economic and technical properties
3892016-05-13T18:50:26  <sipa> and you change those if nodes in the network don't validate fully
3902016-05-13T18:50:34  *** bysherper has quit IRC
3912016-05-13T18:51:37  *** mrkent has joined #bitcoin-core-dev
3922016-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
3932016-05-13T18:52:13  <arubi> well, not my fully verifying node
3942016-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?
3952016-05-13T19:04:32  <sipa> Chris_Stewart_5: or any normal fork
3962016-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
3972016-05-13T19:05:10  <sipa> best chain is something local to your client
3982016-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
3992016-05-13T19:09:39  *** Don_John has joined #bitcoin-core-dev
4002016-05-13T19:10:09  *** Don_John has quit IRC
4012016-05-13T19:10:42  *** JackH has quit IRC
4022016-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
4032016-05-13T19:22:27  *** muftop has quit IRC
4042016-05-13T20:11:38  *** Chris_Stewart_5 has quit IRC
4052016-05-13T20:13:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4062016-05-13T20:24:34  *** CubicEarth has quit IRC
4072016-05-13T20:25:09  *** CubicEarth has joined #bitcoin-core-dev
4082016-05-13T20:32:39  *** Chris_Stewart_5 has quit IRC
4092016-05-13T20:47:35  *** CubicEarth has quit IRC
4102016-05-13T20:47:48  *** CubicEarth has joined #bitcoin-core-dev
4112016-05-13T20:48:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4122016-05-13T20:48:48  *** cjcj has quit IRC
4132016-05-13T21:07:52  *** cryptapus_ has joined #bitcoin-core-dev
4142016-05-13T21:12:51  *** cryptapus_ has quit IRC
4152016-05-13T21:14:09  *** nickler has quit IRC
4162016-05-13T21:14:25  *** nickler has joined #bitcoin-core-dev
4172016-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.
4182016-05-13T21:17:59  <kanzure> or is that intentional etc...
4192016-05-13T21:28:07  *** belcher has joined #bitcoin-core-dev
4202016-05-13T21:30:28  *** BashCo has joined #bitcoin-core-dev
4212016-05-13T21:32:32  *** BashCo_ has quit IRC
4222016-05-13T21:35:51  *** nickler has quit IRC
4232016-05-13T21:35:58  *** cryptapus is now known as cryptapus_afk
4242016-05-13T21:37:46  *** nickler has joined #bitcoin-core-dev
4252016-05-13T21:45:27  *** BashCo_ has joined #bitcoin-core-dev
4262016-05-13T21:47:12  *** BashCo has quit IRC
4272016-05-13T21:59:26  *** BashCo has joined #bitcoin-core-dev
4282016-05-13T22:02:09  *** BashCo_ has quit IRC
4292016-05-13T22:14:04  *** ghtdak has quit IRC
4302016-05-13T22:14:45  *** supasonic has joined #bitcoin-core-dev
4312016-05-13T22:14:48  *** ghtdak has joined #bitcoin-core-dev
4322016-05-13T22:17:58  *** BashCo_ has joined #bitcoin-core-dev
4332016-05-13T22:20:33  *** BashCo has quit IRC
4342016-05-13T22:31:32  *** CubicEarth has quit IRC
4352016-05-13T22:32:04  *** CubicEarth has joined #bitcoin-core-dev
4362016-05-13T22:32:18  *** CubicEarth has joined #bitcoin-core-dev
4372016-05-13T22:36:09  *** bysherper has joined #bitcoin-core-dev
4382016-05-13T22:39:04  *** earlest has quit IRC
4392016-05-13T22:41:16  *** Guyver2 has quit IRC
4402016-05-13T22:42:42  *** Giszmo has quit IRC
4412016-05-13T22:43:43  *** earlest has joined #bitcoin-core-dev
4422016-05-13T22:43:58  *** Giszmo has joined #bitcoin-core-dev
4432016-05-13T22:46:01  *** CubicEarth has quit IRC
4442016-05-13T22:46:34  *** bysherper has quit IRC