1 2014-07-07 00:51:09 <sipa> Emcy: who cares?
2 2014-07-07 00:51:18 <phantomcircuit> Emcy, increasing the memory hardness actually makes ASICs better
3 2014-07-07 00:51:44 <phantomcircuit> since you're pushing the working set to beyond the L1/L2/L3 size of a normal cpu/gpu
4 2014-07-07 00:52:05 <phantomcircuit> but i can make an ASIC using SRAM for the entire working set almost exactly
5 2014-07-07 00:52:37 <Emcy> some intel chips have 128mb of L4 now
6 2014-07-07 00:52:48 <Emcy> someone make haswellcoin lol
7 2014-07-07 00:52:54 <phantomcircuit> generate a TON of hash functions
8 2014-07-07 00:53:02 <sipa> #altcoin-dev, please :)
9 2014-07-07 00:53:18 <phantomcircuit> at least then the asic development is expensive
10 2014-07-07 00:53:30 <justanotheruser> ##altcoin-dev that is
11 2014-07-07 00:53:57 <Emcy> whats with the double pound
12 2014-07-07 00:54:13 <sipa> or if it's about generic properties of PoW and future systems... #bitcoin-wizards
13 2014-07-07 00:54:34 <phantomcircuit> sipa, is libsecp256k1 merged into mainline master?
14 2014-07-07 00:54:48 <sipa> no
15 2014-07-07 00:55:02 <sipa> the integration code is there, but the library itself not yet
16 2014-07-07 00:55:50 <Emcy> sipa is your library at a stage now where you want to put it in?
17 2014-07-07 00:56:54 <sipa> code is never finished :)
18 2014-07-07 00:57:10 <Emcy> i didnt say finished :P
19 2014-07-07 00:57:25 <sipa> it's usable
20 2014-07-07 01:00:05 <phantomcircuit> sipa, when you say integration you mean like a configure flag?
21 2014-07-07 01:00:09 <sipa> yes
22 2014-07-07 01:00:22 <sipa> and the key.cpp code to call libsecp256k1
23 2014-07-07 01:00:28 <Emcy> coupling it with better p2p should make it much less painful to run core
24 2014-07-07 01:00:41 <sipa> 'better p2p' ?
25 2014-07-07 01:01:31 <phantomcircuit> sipa, improving the logic a bit
26 2014-07-07 01:01:35 <phantomcircuit> it's still quite bursty
27 2014-07-07 01:01:43 <sipa> like #4468 ?
28 2014-07-07 01:02:33 <phantomcircuit> yeah like that
29 2014-07-07 01:04:14 <Emcy> concurrent block downloads to start
30 2014-07-07 01:04:23 <sipa> like #4468
31 2014-07-07 01:04:45 <Emcy> is that a github issue no
32 2014-07-07 01:04:49 <sipa> yes
33 2014-07-07 01:04:55 <Emcy> yes then
34 2014-07-07 01:05:05 <phantomcircuit> sipa, to really test that you probably want to add your own checkpoint
35 2014-07-07 01:07:42 <Emcy> oh nice 4468 is headers first actual code
36 2014-07-07 01:07:42 <sipa> eh?
37 2014-07-07 01:07:55 <Emcy> nice, all coming together
38 2014-07-07 01:12:35 <Emcy> sipa you must have rewitten like 80% of the client by now
39 2014-07-07 01:12:50 <sipa> nah, i just move bits around :)
40 2014-07-07 01:13:12 <Emcy> isnt that all modern coding is to an extent.........
41 2014-07-07 01:14:06 <Emcy> regardless of that, well done m8
42 2014-07-07 01:21:29 <phantomcircuit> sipa, i seem to have a ./src/secp256k1 directory
43 2014-07-07 01:21:42 <phantomcircuit> any chance you know the magic invocation of configure?
44 2014-07-07 01:22:00 <sipa> you need to put the libsecp256k1 in that directory first
45 2014-07-07 01:24:05 <phantomcircuit> huh
46 2014-07-07 01:24:21 <phantomcircuit> i guess the files in there are .gitignore'd
47 2014-07-07 01:24:42 <sipa> there's only an '.empty'
48 2014-07-07 01:25:16 <phantomcircuit> yeah i checked out your integration branch before though
49 2014-07-07 01:25:20 <phantomcircuit> so there was actually more than that
50 2014-07-07 01:25:53 <Emcy> i assume 4468 should help with those mental node bandwidth graphs people have been posting
51 2014-07-07 01:26:01 <Emcy> by spreading the load
52 2014-07-07 01:26:38 <gmaxwell> Emcy: perhaps not by itself in that it helps nodes pull a lot harder too.
53 2014-07-07 01:26:57 <Emcy> well yes, but thats desireable
54 2014-07-07 01:27:19 <sipa> i hope that after some tweaking (in subsequent PRs after 4468) the code will deal reasonably well with random mixes of fast and slow peers
55 2014-07-07 01:27:57 <sipa> when that is the case, and enough of the network uses that code, we can probably drop the restriction to only sync from outgoing connections, and add bandwidth limiting
56 2014-07-07 01:28:27 <Emcy> why only outgoing
57 2014-07-07 01:28:51 <sipa> because right now, setting -nolisten effectively helps reducing how much people download from you
58 2014-07-07 01:29:13 <sipa> with parallel download, naively, that would change
59 2014-07-07 01:29:25 <phantomcircuit> sipa, when you say i need to pub the lib in there
60 2014-07-07 01:29:26 <Emcy> yes
61 2014-07-07 01:29:33 <phantomcircuit> would just checking out your repo into that directory do it
62 2014-07-07 01:29:38 <sipa> yes
63 2014-07-07 01:29:45 <gmaxwell> my thought exactly wrt phasing in downloading from inbound peers.
64 2014-07-07 01:29:47 <sipa> but there is probably still some configure magic necessary
65 2014-07-07 01:30:09 <phantomcircuit> ./configure --help doesn't even show libsecp256k1
66 2014-07-07 01:30:10 <Emcy> i hope thats not another bit of zombie 'wisdom' in that case
67 2014-07-07 01:30:18 <phantomcircuit> but it's in the file as USE_LIBSECP256K1
68 2014-07-07 01:30:57 <gmaxwell> sipa: did you see my observation that it manages to keep the peer's ping time very high even where it should be cpu bound? That surprised me.
69 2014-07-07 01:31:00 <sipa> you'll probably need to manually tweak bitcoin-config.h or whatever to set USE_LIBSECP256K1
70 2014-07-07 01:31:18 <sipa> gmaxwell: see #4472
71 2014-07-07 01:31:43 <gmaxwell> ah, sorry been on planes all day, still catching up.
72 2014-07-07 01:32:11 <sipa> gmaxwell: if we have a long queue of blocks to process, no other message handling is done, meaning that a ping could be processed much later than it arrives
73 2014-07-07 01:33:11 <Emcy> is diskio/p2p/core threaded or async yet
74 2014-07-07 01:33:12 <phantomcircuit> sipa, yeah probably the ProcessMessage queue should be walked for trivial to handle messages
75 2014-07-07 01:33:27 <phantomcircuit> except i bet there's a bunch of stuff that expects ordered returns
76 2014-07-07 01:33:34 <phantomcircuit> that would be entertaining
77 2014-07-07 01:33:39 <sipa> it definitely needs to be ordered *per peer*
78 2014-07-07 01:33:49 <sipa> doesn't mean every message needs to be handled in receive order
79 2014-07-07 01:34:00 <phantomcircuit> sipa, well.... does it?
80 2014-07-07 01:34:07 <sipa> yes
81 2014-07-07 01:34:13 <phantomcircuit> why?
82 2014-07-07 01:34:26 <sipa> there are several examples of code relying on that property
83 2014-07-07 01:34:45 <sipa> in particular, using a ping to check whether the previous message was handled
84 2014-07-07 01:34:50 <phantomcircuit> the only one i know of is the initial block sync inv trigger thingie
85 2014-07-07 01:35:28 <sipa> or 4468 itself relying on being able to send a getheaders + getdata for the same block, and know that its headers will have been verified by the time the block arrives, without extra round trip
86 2014-07-07 01:36:03 <sipa> Emcy: there is a network messaging thread, and a message handling thread
87 2014-07-07 01:36:26 <sipa> so data goes from/to buffers while the verification code is doing other stuff
88 2014-07-07 01:36:27 <phantomcircuit> sipa, getheaders returns 50k headers right?
89 2014-07-07 01:36:30 <sipa> 2000
90 2014-07-07 01:36:46 <phantomcircuit> wat
91 2014-07-07 01:37:19 <dhill> 2000 per message
92 2014-07-07 01:37:26 <sipa> even with just a boring headers -> getheaders -> headers -> getheaders -> ... synchronous sequence, it takes around a minute to synchronize
93 2014-07-07 01:38:16 <gmaxwell> 2000 headers is 160kbytes ignoring overhead, so it's not really insanely too few.
94 2014-07-07 01:38:57 <sipa> 162024 bytes to be precise
95 2014-07-07 01:39:12 <phantomcircuit> gmaxwell, getdata's limit is 50k requests
96 2014-07-07 01:39:23 <phantomcircuit> which is way way more expensive than returning 50k headers
97 2014-07-07 01:39:41 <sipa> that's 1.6 MB
98 2014-07-07 01:40:12 <phantomcircuit> iirc more like 1.8
99 2014-07-07 01:40:13 <phantomcircuit> but yeah
100 2014-07-07 01:40:15 <phantomcircuit> it's large
101 2014-07-07 01:40:55 <phantomcircuit> given that i dont see any reason to restrict the one piece that is almsot certainly always goign to be latency sensitive to 160KB chunks
102 2014-07-07 01:41:09 <sipa> it's not latency sensitive
103 2014-07-07 01:41:32 <sipa> you only need long headers responses for initial sync
104 2014-07-07 01:41:56 <phantomcircuit> sipa, yeah so?
105 2014-07-07 01:41:59 <sipa> for block propagation it doesn't matter (unless we'd have a >2000 deep reorg)
106 2014-07-07 01:42:47 <phantomcircuit> IBS is cpu bound... but only after a point
107 2014-07-07 01:43:22 <sipa> fast initial sync is a nice property to have, but it's by no means essential to bitcoin's operation
108 2014-07-07 01:43:34 <sipa> and header sync is already such a tiny fraction of the whole sync
109 2014-07-07 01:43:46 <gmaxwell> phantomcircuit: so right now a sync is still a couple hours, shaving that minute down to 30 seconds wouldn't be worth a protocol change, and the larger the chunks have fairness/congestion implications too, so it's not free even ignoring the protocol change.
110 2014-07-07 01:44:34 <phantomcircuit> gmaxwell, well.... could detect when a peer connects with a height less than ours and spam them with block headers we think they need
111 2014-07-07 01:44:42 <gmaxwell> The headers aren't the long pole in the process in any case, even on early blocks, ... I think excessive seralization on the early blocks is much more of a factor.
112 2014-07-07 01:44:51 <sipa> ACTION votes: ignore 'startingheight' entirely
113 2014-07-07 01:45:06 <gmaxwell> yea, startingheight is useless.
114 2014-07-07 01:45:22 <phantomcircuit> but the pretty progress bar
115 2014-07-07 01:45:30 <phantomcircuit> or is that just using checkpoints now
116 2014-07-07 01:45:43 <gmaxwell> I'd like that whenever we do a new addr message we do a new kind of ping message where the peer gives you its current bestblock/height and network time.
117 2014-07-07 01:45:47 <gmaxwell> phantomcircuit: it uses the wallclock
118 2014-07-07 01:46:10 <phantomcircuit> gmaxwell, oh that's a neat way to do it
119 2014-07-07 01:46:11 <phantomcircuit> heh
120 2014-07-07 01:46:12 <gmaxwell> sure as hell doesn't use bullshit-o-tron, ahem, I mean starting height. :P
121 2014-07-07 01:50:20 <gmaxwell> (one of the reasons starting height is useless is that it never changes)
122 2014-07-07 02:54:56 <skinnkavaj> sipa: Why wouldn't you like LTC securing BTC's network? Litecoin would be BTCs bitch, _insertcoin_ would be Litecoins bitch..? Wouldn't it make the network more secure?
123 2014-07-07 02:56:01 <justanotheruser> skinnkavaj: how could litecoin secure bitcoin without a hardfork?
124 2014-07-07 02:56:43 <gmaxwell> please take this elsewhere.
125 2014-07-07 02:57:14 <justanotheruser> gmaxwell: sorry, I didn't realize this was -dev
126 2014-07-07 02:58:39 <skinnkavaj> gmaxwell: Why? I am curious what is the difference between this and tree chains
127 2014-07-07 02:58:42 <skinnkavaj> Read this at litecoin forum
128 2014-07-07 02:58:46 <skinnkavaj> "This community must keep in mind that there are some heavy hitter Bitcoin developers like Greg Maxwell and Adam Back seeking to destroy ALL alt coins via side side chains and or tree chains. It's a good idea. It basically makes Litecoin a side chain to Bitcoin. "
129 2014-07-07 02:59:20 <SomeoneWeird> sigh
130 2014-07-07 02:59:22 <SomeoneWeird> offtopic
131 2014-07-07 02:59:33 <SomeoneWeird> take it somewhere else or be kicked
132 2014-07-07 03:01:38 <justanotheruser> skinnkavaj: ##altcoin-dev