1 2016-01-06T00:03:32 *** tjader has quit IRC
2 2016-01-06T00:03:35 *** d_t has quit IRC
3 2016-01-06T00:05:03 *** ryitpm has joined #bitcoin-dev
4 2016-01-06T00:05:17 *** LeMiner has joined #bitcoin-dev
5 2016-01-06T00:05:53 *** swappermall has quit IRC
6 2016-01-06T00:07:58 *** tjader has joined #bitcoin-dev
7 2016-01-06T00:08:31 *** CubicEarth has joined #bitcoin-dev
8 2016-01-06T00:11:55 *** CubicEar_ has quit IRC
9 2016-01-06T00:12:44 *** CubicEar_ has joined #bitcoin-dev
10 2016-01-06T00:16:15 *** CubicEarth has quit IRC
11 2016-01-06T00:18:00 *** xss has quit IRC
12 2016-01-06T00:19:06 *** pfallenop has quit IRC
13 2016-01-06T00:19:13 *** AtnevRed has joined #bitcoin-dev
14 2016-01-06T00:19:32 *** pfallenop has joined #bitcoin-dev
15 2016-01-06T00:20:46 *** CubicEar_ has quit IRC
16 2016-01-06T00:24:03 *** AtnevRed has quit IRC
17 2016-01-06T00:25:35 *** cyphase has quit IRC
18 2016-01-06T00:26:59 *** Ahmed90 has quit IRC
19 2016-01-06T00:30:11 *** CubicEarth has joined #bitcoin-dev
20 2016-01-06T00:31:40 *** xss has joined #bitcoin-dev
21 2016-01-06T00:32:06 *** CubicEarth has quit IRC
22 2016-01-06T00:34:28 *** MrHodl has joined #bitcoin-dev
23 2016-01-06T00:34:29 *** fuc has quit IRC
24 2016-01-06T00:38:08 *** cyphase has joined #bitcoin-dev
25 2016-01-06T00:39:32 *** astj_ has quit IRC
26 2016-01-06T00:41:16 *** DougieBot5000 has joined #bitcoin-dev
27 2016-01-06T00:41:32 *** astj_ has joined #bitcoin-dev
28 2016-01-06T00:41:53 *** metalcamp has quit IRC
29 2016-01-06T00:44:25 *** mrkent_ has joined #bitcoin-dev
30 2016-01-06T00:45:12 *** mrkent has quit IRC
31 2016-01-06T00:49:44 *** ThomasV has quit IRC
32 2016-01-06T00:56:19 *** brson has joined #bitcoin-dev
33 2016-01-06T00:57:14 *** DevSauce has quit IRC
34 2016-01-06T00:57:15 *** DevSauce_ has quit IRC
35 2016-01-06T01:07:44 *** CheckDavid has joined #bitcoin-dev
36 2016-01-06T01:11:08 *** ThomasV has joined #bitcoin-dev
37 2016-01-06T01:15:20 *** xss has quit IRC
38 2016-01-06T01:15:35 *** ThomasV has quit IRC
39 2016-01-06T01:24:34 *** Ylbam has quit IRC
40 2016-01-06T01:25:56 *** Yoghur114_2 has quit IRC
41 2016-01-06T01:33:14 *** tjader has quit IRC
42 2016-01-06T01:35:17 *** cryptopeddler has quit IRC
43 2016-01-06T01:37:14 *** cryptopeddler has joined #bitcoin-dev
44 2016-01-06T01:37:35 *** tjader has joined #bitcoin-dev
45 2016-01-06T01:39:09 *** stevenroose_ has quit IRC
46 2016-01-06T01:47:42 *** xss has joined #bitcoin-dev
47 2016-01-06T01:48:59 *** cryptopeddler has quit IRC
48 2016-01-06T01:50:29 *** cryptopeddler has joined #bitcoin-dev
49 2016-01-06T01:54:49 *** cryptopeddler has quit IRC
50 2016-01-06T01:56:40 *** cryptopeddler has joined #bitcoin-dev
51 2016-01-06T02:00:16 *** d_t has joined #bitcoin-dev
52 2016-01-06T02:00:20 *** d_t has quit IRC
53 2016-01-06T02:00:47 *** d_t has joined #bitcoin-dev
54 2016-01-06T02:02:14 *** TheAdversary has quit IRC
55 2016-01-06T02:07:53 *** TheAdversary has joined #bitcoin-dev
56 2016-01-06T02:10:00 *** fuc has joined #bitcoin-dev
57 2016-01-06T02:10:48 *** MrHodl has quit IRC
58 2016-01-06T02:15:20 *** laurentmt has joined #bitcoin-dev
59 2016-01-06T02:16:19 *** laurentmt has quit IRC
60 2016-01-06T02:19:46 *** d_t has quit IRC
61 2016-01-06T02:20:00 *** AtnevRed has joined #bitcoin-dev
62 2016-01-06T02:24:55 *** AtnevRed has quit IRC
63 2016-01-06T02:38:04 *** AaronvanW has quit IRC
64 2016-01-06T02:39:22 *** bsm117532 is now known as Guest65074
65 2016-01-06T02:39:42 *** belcher has quit IRC
66 2016-01-06T02:41:00 *** RedEmerald has quit IRC
67 2016-01-06T02:52:26 *** p15 has joined #bitcoin-dev
68 2016-01-06T02:53:11 *** cryptopeddler has quit IRC
69 2016-01-06T02:54:44 *** cryptopeddler has joined #bitcoin-dev
70 2016-01-06T02:57:00 *** Dr-G has joined #bitcoin-dev
71 2016-01-06T02:57:00 *** Dr-G has joined #bitcoin-dev
72 2016-01-06T02:57:28 *** RedEmerald has joined #bitcoin-dev
73 2016-01-06T03:00:16 *** Dr-G2 has quit IRC
74 2016-01-06T03:02:56 *** tjader has quit IRC
75 2016-01-06T03:07:12 *** tjader has joined #bitcoin-dev
76 2016-01-06T03:08:03 *** roconnor has joined #bitcoin-dev
77 2016-01-06T03:11:47 <rusty> Hmm, bitcoin-cli giving me "error: couldn't parse reply from server" under load (couple of dozen of them running). Is this a known issue?
78 2016-01-06T03:12:59 <jgarzik> rusty, Sounds like truncated JSON, due to truncated reply. What RPC?
79 2016-01-06T03:13:23 <jgarzik> rusty, and is this modern libevent http server or prehistoric crapola server?
80 2016-01-06T03:13:43 <rusty> jgarzik: nothing exotic, just localhost... hmm, recent git build.
81 2016-01-06T03:14:16 <rusty> jgarzik: sometimes they all pass, sometimes they all fail. Let me just check it's not something weird I'm doing (though I'd expect a different error if my caller were screwing up)
82 2016-01-06T03:14:39 <rusty> v0.12.99.0-7922592
83 2016-01-06T03:16:13 *** phungus has joined #bitcoin-dev
84 2016-01-06T03:16:49 *** won9 has joined #bitcoin-dev
85 2016-01-06T03:18:14 <jgarzik> rusty, what RPCs? large data-output RPCs like getrawmempool?
86 2016-01-06T03:18:27 <rusty> jgarzik: nope, getrawtransaction
87 2016-01-06T03:19:10 <rusty> jgarzik: stracing now...
88 2016-01-06T03:19:39 <rusty> jgarzik: ah!
89 2016-01-06T03:19:41 <rusty> "HTTP/1.1 500 Internal Server Error\r\nDate: Wed, 06 Jan 2016 03:17:47 GMT\r\nContent-Length: 25\r\nContent-Type: text/html; charset=ISO-8859-1\r\nConnection: close\r\n\r\nWork queue depth exceeded", 184
90 2016-01-06T03:20:03 <jgarzik> bitcoin-cli error reporting could be improved
91 2016-01-06T03:20:10 <rusty> jgarzik: err.. yeah :)
92 2016-01-06T03:22:05 <rusty> jgarzik: so, the answer seems to be no more than 4 requests at once by default.
93 2016-01-06T03:22:47 <jgarzik> rusty, nod, easy to fix with command line option
94 2016-01-06T03:23:11 <jgarzik> rusty, the better fix is buffering requests rather than dropping
95 2016-01-06T03:23:15 *** DigiByteDev has joined #bitcoin-dev
96 2016-01-06T03:23:22 <jgarzik> that's what normal http servers do
97 2016-01-06T03:23:44 *** brson has quit IRC
98 2016-01-06T03:23:55 <rusty> Actaully, it's the queue limit. 16 per thread.
99 2016-01-06T03:24:07 *** brg444 has joined #bitcoin-dev
100 2016-01-06T03:25:10 *** DigiByteDev has quit IRC
101 2016-01-06T03:25:32 <rusty> Can also be adjusted, but I don't see why there's a limit there, really.
102 2016-01-06T03:27:13 *** DigiByteDev has joined #bitcoin-dev
103 2016-01-06T03:34:50 *** bsm117532 has joined #bitcoin-dev
104 2016-01-06T03:37:21 <phantomcircuit> rusty, memory exhaustion prevention? 16 seems low though
105 2016-01-06T03:37:27 *** MrHodl has joined #bitcoin-dev
106 2016-01-06T03:38:15 <rusty> phantomcircuit: AFAICT bitcoind's RPC doesn't have any async commands, so you can only have one command per socket fd. That seems sufficient limit to me.
107 2016-01-06T03:38:24 *** Chris_Stewart_5 has quit IRC
108 2016-01-06T03:40:06 *** fuc has quit IRC
109 2016-01-06T03:42:57 * rusty limits his daemon to serialize bitcoind usage.
110 2016-01-06T03:44:26 *** xss has quit IRC
111 2016-01-06T03:44:44 *** xss has joined #bitcoin-dev
112 2016-01-06T03:44:47 *** cryptopeddler has quit IRC
113 2016-01-06T03:46:38 *** cryptopeddler has joined #bitcoin-dev
114 2016-01-06T03:47:58 *** d_t has joined #bitcoin-dev
115 2016-01-06T03:53:03 *** Delta_ has joined #bitcoin-dev
116 2016-01-06T03:55:27 *** Subo1977 has quit IRC
117 2016-01-06T03:59:10 *** won9 has quit IRC
118 2016-01-06T03:59:47 *** p15 has quit IRC
119 2016-01-06T04:02:41 *** won9 has joined #bitcoin-dev
120 2016-01-06T04:03:17 *** oneeman has quit IRC
121 2016-01-06T04:04:37 *** p15 has joined #bitcoin-dev
122 2016-01-06T04:08:40 <jtoomim> what's the O( ) scaling for a single UTXO lookup from disk (e.g. SSD)?
123 2016-01-06T04:09:29 <jtoomim> vs UTXO set size
124 2016-01-06T04:11:58 <petertodd> jtoomim: O(<something log something>) likely, if you're talking about the theory and physics
125 2016-01-06T04:12:07 <petertodd> jtoomim: in practice it's lumpy; it's lot a O() scaling question
126 2016-01-06T04:12:20 <petertodd> *not a
127 2016-01-06T04:13:37 <jtoomim> lumpy because of the 4 kB block size of disks?
128 2016-01-06T04:14:36 <jtoomim> my question i guess is about the leveldb backend for coins entries, how it's organized, how it's searched, etc.
129 2016-01-06T04:15:02 <petertodd> jtoomim: it's lumpy because disks are physical things with finite bandwidth
130 2016-01-06T04:15:04 <jtoomim> it seems like it should be O(log n) if you're using a tree or something like that on disk
131 2016-01-06T04:16:08 <jtoomim> do we have any indexes for where to find certain utxos on disk, or do we just search all the entries until we find it?
132 2016-01-06T04:16:18 <jtoomim> is the index stored in memory, or is it on disk?
133 2016-01-06T04:16:34 <jtoomim> if you don't know offhand, no big deal, i'll read the code when i get around to it
134 2016-01-06T04:16:36 <petertodd> jtoomim: how would you "seach all the entries"...
135 2016-01-06T04:16:38 <jtoomim> just curious, really
136 2016-01-06T04:16:51 <phantomcircuit> jtoomim, with leveldb it is... O(log n) for n entires modulo a ton of implementation details
137 2016-01-06T04:17:14 <jtoomim> ok, thanks phantomcircuit
138 2016-01-06T04:17:42 <phantomcircuit> jtoomim, there's a *ton* of implementation details though
139 2016-01-06T04:18:01 <jtoomim> not surprised
140 2016-01-06T04:18:11 <jtoomim> needing atomic writes makes things tricky
141 2016-01-06T04:18:23 *** cryptopeddler has quit IRC
142 2016-01-06T04:18:37 <petertodd> jtoomim: like I say, this isn't a O() scaling question in practice
143 2016-01-06T04:19:10 <petertodd> jtoomim: keep in mind a lot of nodes are on shit VPS's
144 2016-01-06T04:19:28 <phantomcircuit> jtoomim, for example by default there's a ton of caching layers between bitcoin and the data
145 2016-01-06T04:19:38 <jtoomim> right
146 2016-01-06T04:19:55 <jtoomim> i'm just thinking if maybe we could have a different way of caching/storing the data
147 2016-01-06T04:20:11 <petertodd> jtoomim: have you seen my txo commitments?
148 2016-01-06T04:20:15 *** cryptopeddler has joined #bitcoin-dev
149 2016-01-06T04:20:19 <jtoomim> like maybe having a map in memory of address to disk index
150 2016-01-06T04:20:46 *** AtnevRed has joined #bitcoin-dev
151 2016-01-06T04:20:58 <jtoomim> to try to reduce the implementation details, and make better use of disk io
152 2016-01-06T04:20:59 <petertodd> jtoomim: random lookup of a set of things is always going to be a simple question of how many IOPs you can push, but you can make the size of that set small enough to fit into RAM
153 2016-01-06T04:21:10 <phantomcircuit> bitcoind internal cache L1, L2, L3 memory, os page cache L2, L3 memory, storage memory cache, storage itself
154 2016-01-06T04:21:11 <jtoomim> but at this point, i'm just doing shower thoughts
155 2016-01-06T04:21:14 <petertodd> jtoomim: <for some definition of "a small amount of ram">
156 2016-01-06T04:21:45 <jtoomim> petertodd: no i haven't seen txo commitments
157 2016-01-06T04:24:00 <phantomcircuit> each of those will have it's own independent complexity for random access
158 2016-01-06T04:24:00 <phantomcircuit> and each is more or less an order of magnitude slower than the previous
159 2016-01-06T04:24:00 <phantomcircuit> petertodd, i suspect there's something that could be done to improve memory usage of the dbcache but only at pretty extreme cpu cycle cost
160 2016-01-06T04:24:36 <phantomcircuit> it might be worth it but only on systems where power consumption is irrelevant
161 2016-01-06T04:24:36 <phantomcircuit> jtoomim, tl;dr optimization beyond what is already being done would require knowledge of the target hardware
162 2016-01-06T04:25:16 <petertodd> jtoomim: and if you need that kind of heroics, something is very wrong with your system in a decentralized environment...
163 2016-01-06T04:25:47 *** AtnevRed has quit IRC
164 2016-01-06T04:26:00 *** cryptopeddler has quit IRC
165 2016-01-06T04:26:35 <petertodd> jtoomim: it's really bad when getting into mining requires knowledge of a whole bunch of esotetic stuff like SSD optimization
166 2016-01-06T04:26:59 <petertodd> jtoomim: equally, that's a system with no safety margin
167 2016-01-06T04:27:01 <jtoomim> petertodd: i disagree on that point. I have no sympathy for lazy or incompetent miners who still want to be profitable.
168 2016-01-06T04:27:16 *** TheSeven has quit IRC
169 2016-01-06T04:27:23 <phantomcircuit> petertodd, ssd optimization? psh you clearly need more memory
170 2016-01-06T04:27:30 *** cryptopeddler has joined #bitcoin-dev
171 2016-01-06T04:27:35 <petertodd> phantomcircuit: heh, indeed
172 2016-01-06T04:27:51 <petertodd> phantomcircuit: which can be a pretty big fixed cost
173 2016-01-06T04:28:02 <jtoomim> like $200?
174 2016-01-06T04:28:16 <petertodd> jtoomim: we're designing a decentralized system; those miners add much needed diversity
175 2016-01-06T04:28:18 <jtoomim> compared to the cost of a single antminer S7, which is $1200?
176 2016-01-06T04:28:40 <petertodd> jtoomim: UTXO size can currently grow by gigabytes per year
177 2016-01-06T04:28:41 *** TheSeven has joined #bitcoin-dev
178 2016-01-06T04:28:56 <petertodd> jtoomim: lots of scenarios where that happens
179 2016-01-06T04:29:18 <jtoomim> are you talking about 50 GB per year, or 1 GB per year, or something in between?
180 2016-01-06T04:29:50 <jtoomim> 32 GB costs about $200
181 2016-01-06T04:29:55 <petertodd> jtoomim: equally, in a healthy system you need anonymity to blunt attacks, which means running a full node with sufficient speed to help minres be profitable can't be unusual
182 2016-01-06T04:30:06 <jtoomim> so if we had to spend that much on RAM each year, we would be... not spending much
183 2016-01-06T04:30:38 <petertodd> jtoomim: yes, we can grow up to ~50GB per year in theory, in practice some % of that, probably low double-digits is a realistic scenario
184 2016-01-06T04:31:00 <jtoomim> ok, petertodd, at this point you're just repeating points which you should know i disagree with, and not really answering my questions earlier about how the current system works
185 2016-01-06T04:31:02 <petertodd> jtoomim: VPS's with lots of ram are expensive
186 2016-01-06T04:31:43 <jtoomim> petertodd, i think you don't have a good idea of the economics of mining.
187 2016-01-06T04:31:56 <jtoomim> my company spends over $10k per month on electricity.
188 2016-01-06T04:32:03 <petertodd> jtoomim: I think this is a case where you're designing a different system than I am
189 2016-01-06T04:32:09 <jtoomim> and we've got about 0.2% of the network hashrate or something like that.
190 2016-01-06T04:32:29 <jtoomim> and we've also got very low electricity prices.
191 2016-01-06T04:32:30 <petertodd> jtoomim: your company depends on a wider community
192 2016-01-06T04:33:01 <jtoomim> the hardware cost to run a node is basically free to us, even when we overspend
193 2016-01-06T04:33:03 <petertodd> jtoomim: btw do you mine, or point that hashing power at a pool
194 2016-01-06T04:33:16 <phantomcircuit> jtoomim, to get the absolute lowest switching time possible you currently need like 64GB of ram
195 2016-01-06T04:33:19 <jtoomim> we do p2pool as much as possible
196 2016-01-06T04:33:20 <petertodd> jtoomim: again, the hardware cost that matters isn't your node, it's everyone elses nodes
197 2016-01-06T04:33:53 <petertodd> jtoomim: what % is p2pool at right now?
198 2016-01-06T04:34:04 <jtoomim> petertodd: less than 1%
199 2016-01-06T04:34:11 <jtoomim> it's about 1.4 PH/s
200 2016-01-06T04:34:43 <jtoomim> and don't you blame that on the costs of running a node, because that has nothing to do with p2pool's problems
201 2016-01-06T04:34:46 <petertodd> jtoomim: heh, you're probably in a position where you're actually taking away shares from other p2pool users in theory, although it's probably irrelevant compared to variance reduction benefits
202 2016-01-06T04:35:19 <petertodd> jtoomim: p2pool has all the perverse latency incentive issues that bitcoin does, but in minature
203 2016-01-06T04:35:22 <jtoomim> we operate several different nodes. we don't have all our hashrate on one node.
204 2016-01-06T04:35:36 <jtoomim> but yes, it's been a concern of mine
205 2016-01-06T04:36:06 <jtoomim> but the main concern of mine for p2pool is the fact that antminers don't work reliably with it
206 2016-01-06T04:36:09 <petertodd> jtoomim: what's the ping time between those nodes?
207 2016-01-06T04:36:10 <jtoomim> and lose hashrate
208 2016-01-06T04:36:20 <jtoomim> depends on what kind of ping you're talking about
209 2016-01-06T04:36:24 <jtoomim> p2pool is mostly cpu bound
210 2016-01-06T04:36:52 <petertodd> jtoomim: if you have lower average latency to the rest of the p2pool community you've get more than your fair share of p2pool shares
211 2016-01-06T04:36:53 <jtoomim> so the net-stack-level ping can be hundreds of milliseconds, or about our second for the slowest node
212 2016-01-06T04:36:58 <phantomcircuit> ;;calc 10000/((1400000 * 0.25)/1000)
213 2016-01-06T04:36:58 <gribble> 28.5714285714
214 2016-01-06T04:37:17 <jtoomim> in practice, it's mostly CPU, not network
215 2016-01-06T04:37:36 <phantomcircuit> ;;calc 28.57 / 730
216 2016-01-06T04:37:37 <gribble> 0.0391369863014
217 2016-01-06T04:37:39 <jtoomim> but yeah, 0.1 ms ping on the network stack
218 2016-01-06T04:37:46 <phantomcircuit> jtoomim, not a terrible price
219 2016-01-06T04:37:53 <phantomcircuit> assuming you're running S7s
220 2016-01-06T04:38:10 <jtoomim> $0.04/kWh? that's not what we pay
221 2016-01-06T04:38:34 <petertodd> jtoomim: how are you setup? I easily got lower cpu latency than that
222 2016-01-06T04:39:00 <rusty> jtoomim: last I did a rough check, UTXO tended to be very "recent first", so caching the last few blocks wins. I think it was ~25% of inputs come from last 6 blocks.
223 2016-01-06T04:39:07 <petertodd> jtoomim: and yeah, the 0.1ms between nodes is a big advantage
224 2016-01-06T04:39:09 <jtoomim> on p2pool with a about 100 TH/s on each node in about a dozen different users?
225 2016-01-06T04:39:26 <phantomcircuit> jtoomim, antminers dont work reliably on p2pool?
226 2016-01-06T04:39:27 <phantomcircuit> wat
227 2016-01-06T04:39:30 <jtoomim> p2pool's code doesnot scale very well
228 2016-01-06T04:39:47 <petertodd> jtoomim: right, so scale out - no need to have a dozen users on a p2pool node
229 2016-01-06T04:39:53 <jtoomim> antminers do not work reliably on p2pool because (a) they drop stale work instead of submitting it to the pool, and (b) they crash a lot with very high difficulty work
230 2016-01-06T04:40:15 <petertodd> jtoomim: and TH/s should have nothing to do with it in a proper setup - crank up share diff
231 2016-01-06T04:40:28 <jtoomim> when they (b) crash, they shut the fans off immediately, but the ASICs continue to generate heat for a couple of minutes, which means that p2pool can actually destroy the hardware
232 2016-01-06T04:40:37 <jtoomim> it's ... suboptimal
233 2016-01-06T04:40:42 <phantomcircuit> rusty, the whole thing in ram consumes ~6GB today then you need more to delay flushing the write buffer... basically forever
234 2016-01-06T04:41:02 <petertodd> jtoomim: why can't the mining software do the share filtering for you?
235 2016-01-06T04:41:11 <petertodd> jtoomim: crashing on high diff work is bizzare
236 2016-01-06T04:41:11 <phantomcircuit> jtoomim, they drop stale work for a reason, believe me you dont want them to change that :P
237 2016-01-06T04:41:32 <jtoomim> with p2pool work, you have share-stale work that is still block-valid work
238 2016-01-06T04:41:42 <rusty> phantomcircuit: sure, but if you're worried long term, there's a benefit to moving to a two-level approach.
239 2016-01-06T04:41:56 <jtoomim> this is for work for which there was a nonce successfully found
240 2016-01-06T04:42:01 <phantomcircuit> jtoomim, with spi chaining you can get the same piece of work submitted to the software in an infinite loop
241 2016-01-06T04:42:02 <jtoomim> this is not flushing the work out of the system
242 2016-01-06T04:42:07 <phantomcircuit> you really dont want that going to the pool
243 2016-01-06T04:42:11 *** cryptopeddler has quit IRC
244 2016-01-06T04:42:26 <jtoomim> phantomcircuit, i think the pool is a better determinant of that
245 2016-01-06T04:42:29 <jtoomim> especially with p2pool
246 2016-01-06T04:42:39 <jtoomim> where it's still valid work that's just for an old share
247 2016-01-06T04:42:41 <phantomcircuit> rusty, yes i agree the read caching ness of the cache needs to be improved, currently it's mostly a write cache by design
248 2016-01-06T04:42:47 <jtoomim> it could be valid blocks that you're throwing away
249 2016-01-06T04:43:12 <phantomcircuit> jtoomim, maybe but what if you have 1000 things connected to the pool all spewing nonsense?
250 2016-01-06T04:43:19 <phantomcircuit> there's a tradeoff to be made
251 2016-01-06T04:43:23 <jtoomim> phantomcircuit i don't understand the SPI chaining thing
252 2016-01-06T04:43:35 <phantomcircuit> jtoomim, hardware wizardry
253 2016-01-06T04:43:44 <jtoomim> i know what spi chaining is
254 2016-01-06T04:43:52 *** cryptopeddler has joined #bitcoin-dev
255 2016-01-06T04:43:54 <jtoomim> i don't understand how you think it can result in an infinite loop
256 2016-01-06T04:44:22 <phantomcircuit> jtoomim, the logic on any 1 of the chips getting wedged can leave it stuck flagging it has a result
257 2016-01-06T04:44:30 <jtoomim> especially since this bug has been fixed in alternate firmware, which bitmain just chose not to use...
258 2016-01-06T04:44:50 <phantomcircuit> you can also fix it by detecting duplicate nonce results
259 2016-01-06T04:44:56 <phantomcircuit> (but like two lines of code man)
260 2016-01-06T04:45:14 <jtoomim> ok, so if a chip is sending back bad results, usually the firmware chooses to shut off that asic
261 2016-01-06T04:45:23 <jtoomim> ... problem solved?
262 2016-01-06T04:45:31 <phantomcircuit> jtoomim, valid but duplicate results
263 2016-01-06T04:45:37 *** treaki_ has joined #bitcoin-dev
264 2016-01-06T04:45:48 <jtoomim> duplicate results are different from stale results
265 2016-01-06T04:45:51 <phantomcircuit> also i dont think you can really turn off the spi logic without shutting down the entire chain
266 2016-01-06T04:46:01 <phantomcircuit> oooh right
267 2016-01-06T04:46:04 *** patcon has joined #bitcoin-dev
268 2016-01-06T04:46:11 <jtoomim> and this check is after the spi communication
269 2016-01-06T04:46:16 <phantomcircuit> jtoomim, just modify p2pool not to set the flush flag?
270 2016-01-06T04:46:18 <jtoomim> afaik
271 2016-01-06T04:46:27 <jtoomim> no, that would kill your share orphan rate
272 2016-01-06T04:47:08 *** supasonic has joined #bitcoin-dev
273 2016-01-06T04:47:22 *** jarkinox has joined #bitcoin-dev
274 2016-01-06T04:47:29 *** Jaume has joined #bitcoin-dev
275 2016-01-06T04:47:47 <jtoomim> so back to the original question, any idea how many disk accesses are needed per UTXO lookup?
276 2016-01-06T04:47:58 <jtoomim> rough estimate
277 2016-01-06T04:48:06 *** cryptopeddler has quit IRC
278 2016-01-06T04:48:48 <phantomcircuit> jtoomim, "it depends"
279 2016-01-06T04:49:01 *** bsm117532 has quit IRC
280 2016-01-06T04:49:14 *** treaki has quit IRC
281 2016-01-06T04:49:19 <phantomcircuit> as little as 0 as high as thousands
282 2016-01-06T04:49:36 <jtoomim> any idea what the typical number is?
283 2016-01-06T04:50:07 *** cryptopeddler has joined #bitcoin-dev
284 2016-01-06T04:50:42 <jtoomim> i'm envisioning a system in which we could get the worst case down to 1 as long as you have enough ram for 10% of the total serialized UTXO set by storing in ram the location where you could get the actual data
285 2016-01-06T04:51:08 <jtoomim> so you just have to read that one spot, instead of walking a tree or something with disk accesses
286 2016-01-06T04:51:52 <phantomcircuit> jtoomim, i was serious
287 2016-01-06T04:51:55 <phantomcircuit> it totally depends
288 2016-01-06T04:52:12 <phantomcircuit> if you're me you can go and mess with things and use tons of memory such that it's basically always zero
289 2016-01-06T04:52:15 <phantomcircuit> otherwise
290 2016-01-06T04:52:30 <phantomcircuit> math.random
291 2016-01-06T04:52:38 <jtoomim> so for something that misses the cache?
292 2016-01-06T04:52:51 <petertodd> jtoomim: SSD's are internally rather complex these days - they're not a flat addressable memory
293 2016-01-06T04:53:11 <jtoomim> petertodd i don't think we need to know how the firmware of the SSD works
294 2016-01-06T04:53:12 <phantomcircuit> every step of caching is equally complex these days
295 2016-01-06T04:53:21 <phantomcircuit> jtoomim, oh but you do!
296 2016-01-06T04:53:23 <petertodd> jtoomim: not the firmware, the physical design
297 2016-01-06T04:53:29 <petertodd> jtoomim: (well, firmware matters too)
298 2016-01-06T04:53:31 <phantomcircuit> since it probably involves multiple disk accesses itself
299 2016-01-06T04:53:32 <jtoomim> the firmware hides the physical design from us
300 2016-01-06T04:53:42 <phantomcircuit> jtoomim, nah it *tries* to hide that
301 2016-01-06T04:53:43 <jtoomim> we give it an LBA address, it gives us back 4 kB
302 2016-01-06T04:53:43 <petertodd> jtoomim: at multiple levels you have limits on bandwidth for a given area
303 2016-01-06T04:53:45 <jtoomim> or the OS
304 2016-01-06T04:53:53 <phantomcircuit> they fail horribly at it with truly random access
305 2016-01-06T04:53:56 <petertodd> jtoomim: hell, even ram is structured that way too these days
306 2016-01-06T04:54:01 <jtoomim> and it does so in a few µs
307 2016-01-06T04:54:02 <petertodd> jtoomim: random access is a myth
308 2016-01-06T04:54:23 <phantomcircuit> jtoomim, lulz very very few ssds will actually return a random read in microseconds
309 2016-01-06T04:55:06 <jtoomim> ok, whatever, doesn't matter. the point i'm making is that we can probably do one UTXO, one disk read
310 2016-01-06T04:55:12 <jtoomim> and it sounds like we're not doing that
311 2016-01-06T04:55:19 <jtoomim> do we have a good reason for not doing that?
312 2016-01-06T04:55:38 *** cyphase has quit IRC
313 2016-01-06T04:55:44 <phantomcircuit> jtoomim, no the point is that you *cant* do that
314 2016-01-06T04:55:45 <petertodd> jtoomim: what makes you think we aren't doing that?
315 2016-01-06T04:55:55 <petertodd> jtoomim: indexes are cached in ram anyway
316 2016-01-06T04:56:16 <phantomcircuit> it's a tree, you try to shove as much of the top of the tree into ram as possible
317 2016-01-06T04:56:20 <jtoomim> petertodd because phantomcircuit said sometimes 1000 reads per utxo
318 2016-01-06T04:56:21 <petertodd> jtoomim: and the hardware physically can't do arbitrary random access
319 2016-01-06T04:56:36 <phantomcircuit> jtoomim, the magic of having to read a journal
320 2016-01-06T04:56:56 <jtoomim> you mean the filesystem journal? ext4 or whatever?
321 2016-01-06T04:56:58 <phantomcircuit> like i said
322 2016-01-06T04:57:03 <phantomcircuit> LOTS OF DETAILS
323 2016-01-06T04:57:12 <phantomcircuit> leveldb has a journal
324 2016-01-06T04:57:23 <jtoomim> ok
325 2016-01-06T04:57:25 *** patcon has quit IRC
326 2016-01-06T04:57:35 *** cryptopeddler has quit IRC
327 2016-01-06T04:57:44 <phantomcircuit> the bigger issue is that it really is O(log n)
328 2016-01-06T04:58:00 <phantomcircuit> but the cost of 1 operation is also variable based on system state
329 2016-01-06T04:58:35 <phantomcircuit> so yeah you had to call read() only once, but maybe that took 100 times longer than that other time you called read() 100 times
330 2016-01-06T04:58:40 <phantomcircuit> one the same hardware
331 2016-01-06T04:58:45 <phantomcircuit> on*
332 2016-01-06T04:59:04 <jtoomim> that's a leveldb read()?
333 2016-01-06T04:59:17 *** cryptopeddler has joined #bitcoin-dev
334 2016-01-06T04:59:25 <phantomcircuit> jtoomim, it's a k/v db so get() ? something like that
335 2016-01-06T04:59:34 *** Belxjander has quit IRC
336 2016-01-06T04:59:38 *** osalim has joined #bitcoin-dev
337 2016-01-06T04:59:58 <jtoomim> a seek(key) then a GetValue(result), i think
338 2016-01-06T05:00:01 <phantomcircuit> you could switch to something that isn't tree structured but then performance would be atrocious on hard drives and only slightly better on an ssd
339 2016-01-06T05:00:22 <phantomcircuit> jtoomim, the seek is totally virtual it's not like it moves the disk or anything
340 2016-01-06T05:00:30 <jtoomim> pcursor->seek...
341 2016-01-06T05:00:55 <phantomcircuit> the cursor stuff is for iterating over multiple values
342 2016-01-06T05:01:32 <phantomcircuit> pdb->Get
343 2016-01-06T05:01:50 <phantomcircuit> ok well lets have some fun tracing things
344 2016-01-06T05:02:05 *** jarkinox has quit IRC
345 2016-01-06T05:02:21 *** Belxjander has joined #bitcoin-dev
346 2016-01-06T05:03:04 <phantomcircuit> utxo lookups go through CCoinsViewCache which checks an std::unordered_map, O(1) average, but probably causes a main memory cache miss 99% of the time
347 2016-01-06T05:03:26 <phantomcircuit> assume that misses
348 2016-01-06T05:04:28 <phantomcircuit> pdb->Get calculates which sorted table file the result will be in and then does a bisecting search of the file O(log n)
349 2016-01-06T05:05:19 <phantomcircuit> so now you're actually doing O(log n) disk seeks since they're random access
350 2016-01-06T05:05:38 <phantomcircuit> but wait there is the os page cache!
351 2016-01-06T05:06:04 *** cryptopeddler has quit IRC
352 2016-01-06T05:06:16 <phantomcircuit> that's like lots of context switching and tons of main memory hits
353 2016-01-06T05:06:23 <phantomcircuit> so
354 2016-01-06T05:06:24 <phantomcircuit> yeah
355 2016-01-06T05:06:29 <phantomcircuit> jtoomim, there is no typical
356 2016-01-06T05:06:44 <phantomcircuit> and you cannot guarantee that only a single disk seek occurs
357 2016-01-06T05:06:58 <phantomcircuit> it's the nature of random access
358 2016-01-06T05:07:20 <jtoomim> if you know the exact position, to the byte, of the utxo entry, then you can do a single disk seek
359 2016-01-06T05:07:28 *** cryptopeddler has joined #bitcoin-dev
360 2016-01-06T05:08:08 <petertodd> jtoomim: so? most of that process will be cached in memory anyway
361 2016-01-06T05:08:39 <jtoomim> it should be. is it?
362 2016-01-06T05:08:40 <petertodd> jtoomim: also, remember that leveldb uses b-trees, so there aren't that many levels
363 2016-01-06T05:08:50 <jtoomim> i'm curious how much worse the average case is than the typical case, etc.
364 2016-01-06T05:08:58 <phantomcircuit> jtoomim, the hard part is figuring out where it is
365 2016-01-06T05:08:59 <petertodd> jtoomim: you mean worst case?
366 2016-01-06T05:09:22 <jtoomim> worst case is interesting too
367 2016-01-06T05:09:33 <phantomcircuit> oh yeah and you can construct a worst case block
368 2016-01-06T05:09:37 <petertodd> jtoomim: what do you mean by avg and typ cases?
369 2016-01-06T05:09:38 <phantomcircuit> i had forgotten about that actually
370 2016-01-06T05:09:45 <jtoomim> deviation of average from typical is another way of describing the bad-but-common case
371 2016-01-06T05:09:48 <phantomcircuit> well you cant anymore if obfuscation is on
372 2016-01-06T05:10:04 <petertodd> phantomcircuit: +1 <censored>
373 2016-01-06T05:10:32 <phantomcircuit> jtoomim, average and typical mean the same thing, worst case is the interesting thing to analyze especially if it can be intentionally triggered
374 2016-01-06T05:10:49 <jtoomim> average = mean, typical = mode
375 2016-01-06T05:11:43 <jtoomim> i probably could have stated that more clearly earlier, sorry
376 2016-01-06T05:12:09 <petertodd> jtoomim: again, worst case is the interesting one - get that right and everything else is likely to be a wash
377 2016-01-06T05:12:16 <jtoomim> i'm curious about what portion of the total UTXO lookup times are taken up by what parts of the latency-distribution
378 2016-01-06T05:12:38 <jtoomim> i.e. is it a very heavy-tail distribution where the extreme slow lookups take up almost all of the time, etc.
379 2016-01-06T05:13:28 <petertodd> jtoomim: with obfusecation the only interesting part of that will be cached vs. uncached lookups
380 2016-01-06T05:13:42 <jtoomim> if you want to avoid the worst case being bad, then the most efficient allocation of memory is to store the top levels of the tree, and not cache any actual UTXOs
381 2016-01-06T05:14:03 <jtoomim> if you want to help the typical case, then you store the most commonly used utxos, and don't store the parts of the tree that you don't use often
382 2016-01-06T05:14:16 <jtoomim> if you want to help the average case, then you have to balance those two strategies for memory allocation
383 2016-01-06T05:14:27 <petertodd> jtoomim: the degree to which that avoids the worst-case being bad is going to be sufficiently small as to not matter - utxo growth is a *constraint*
384 2016-01-06T05:17:03 *** jarkinox has joined #bitcoin-dev
385 2016-01-06T05:17:29 <petertodd> jtoomim: it's trivial to calculate worst case by deciding on a reference IOPs figure, dividing that by the number of UTXO's a block
386 2016-01-06T05:17:58 <petertodd> can need to lookup, and then doing themath on what orphan rate that'll end up with
387 2016-01-06T05:18:45 <phantomcircuit> petertodd, even that would end up not calculating a true worst case though
388 2016-01-06T05:19:01 <petertodd> you can make a reasonable assumption that a large, well-resourced, minre can push that number to basically zero, so then decide what's the orphan rate - read revenue -> profitability - difference you're willing to accept between small and large
389 2016-01-06T05:19:20 <petertodd> phantomcircuit: sure, but that should cover the attacker triggerable worst case fairly well
390 2016-01-06T05:19:33 <phantomcircuit> since a true worst case occurs when leveldb decided to rewrite one of the tables (in theory it happens in the background and doesn't effect operating time, in practice disks have limited resources and it doesn't work that way)
391 2016-01-06T05:19:53 <petertodd> phantomcircuit: so long as an attacker can't trigger that I'm not too worried
392 2016-01-06T05:20:37 <phantomcircuit> petertodd, they probably cant without also generating a huge amount of utxos
393 2016-01-06T05:20:44 *** cryptopeddler has quit IRC
394 2016-01-06T05:21:45 *** cryptopeddler has joined #bitcoin-dev
395 2016-01-06T05:22:45 <petertodd> jtoomim: now, if you're not willing to entertain a max orpahn rate difference between large/well-resourced minres and small/poorly-resourced miners, again, we're just don't have anything close to the same goals
396 2016-01-06T05:23:37 <jtoomim> how large is large? how small is small?
397 2016-01-06T05:23:49 <jtoomim> are we talking small = 1%? 0.1%? 0.01%?
398 2016-01-06T05:24:12 <petertodd> jtoomim: small = 0%
399 2016-01-06T05:24:19 <petertodd> jtoomim: large probably would mean 100%
400 2016-01-06T05:24:37 <petertodd> jtoomim: like I said, assume "large" has a 0% orphan rate
401 2016-01-06T05:24:50 <jtoomim> i'm not interested in those assumptions
402 2016-01-06T05:25:03 <jtoomim> i'm not interested in a full-node miner in every home
403 2016-01-06T05:25:09 <jtoomim> i don't think that's realistic
404 2016-01-06T05:25:23 <jtoomim> and i don't think that constraining bitcoin to that requirement is good for bitcoin
405 2016-01-06T05:25:39 <petertodd> jtoomim: like I said, you're not designing a system anything like what I'm interested in designing
406 2016-01-06T05:26:13 <phantomcircuit> jtoomim, are you assuming the only users of the system with a full node are miners?
407 2016-01-06T05:26:15 <petertodd> jtoomim: granted, so you admit that bitcoin doesn't scale, and as it grows you expect the % of the users trusting others to run the system to approach 100%?
408 2016-01-06T05:26:21 <phantomcircuit> if you are then you're designing a broken system
409 2016-01-06T05:26:36 <petertodd> phantomcircuit: ...also designing a much easier to design system!
410 2016-01-06T05:26:45 <petertodd> phantomcircuit: why bank chains are trivial in comparison
411 2016-01-06T05:26:48 <phantomcircuit> petertodd, yeah in that case
412 2016-01-06T05:26:55 <phantomcircuit> PATRICK SIGNS BLOCK #1!
413 2016-01-06T05:26:57 <jtoomim> phantomcircuit, no i'm assuming the only ones who need latency in processing a block to be a few seconds for adversarial conditions are miners or companies with deep pockets
414 2016-01-06T05:27:54 <phantomcircuit> jtoomim, normal users need to be able to complete initial block synchronization in about 6 hours before they start screaming bloody murder
415 2016-01-06T05:27:57 <jtoomim> joe running a full node in his basement for his wallet can afford to have block take a while to verify in some cases, even minutes (though that is distasteful)
416 2016-01-06T05:28:19 <phantomcircuit> build me a system that runs the full validation in that time on a $500 pc and we can talk
417 2016-01-06T05:28:26 <jtoomim> i don't think normal users should be using a full node wallet. i think that is for power users.
418 2016-01-06T05:28:37 <petertodd> jtoomim: so normal users are trusting others?
419 2016-01-06T05:28:38 <phantomcircuit> then you assume a system that will fail
420 2016-01-06T05:28:41 <jtoomim> power users can be patient for IBD.
421 2016-01-06T05:29:21 *** cryptopeddler has quit IRC
422 2016-01-06T05:29:28 <jtoomim> normal users might be paying other users for a contract giving them the data they need
423 2016-01-06T05:29:37 <jtoomim> and if there's fraud, then the full node operator is liable
424 2016-01-06T05:29:53 <petertodd> jtoomim: why bother with this mining stuff? Why not just pay a bank?
425 2016-01-06T05:29:54 <jtoomim> for most wallet users, i think that should be more than enough
426 2016-01-06T05:30:00 <petertodd> jtoomim: or hell, why not use a layer on top of bitcoin?
427 2016-01-06T05:30:08 *** won9 has quit IRC
428 2016-01-06T05:30:17 <brg444> sorry to interject but isn't the idea to minimize trust?
429 2016-01-06T05:30:32 <petertodd> jtoomim: adversarial forced soft-forks are bad enough already - in an environment where the super majority of the economy is trusting a small group sof miners... ugh
430 2016-01-06T05:30:35 <jtoomim> because you don't need to use a bank. you can run your own full node if you want to pay the hardware costs.
431 2016-01-06T05:30:44 <jtoomim> it's just a matter of convenience.
432 2016-01-06T05:30:50 <jtoomim> full nodes will never be convenient.
433 2016-01-06T05:30:53 <gijensen> brg444: There's sarcasm going around
434 2016-01-06T05:30:57 *** cryptopeddler has joined #bitcoin-dev
435 2016-01-06T05:31:23 <petertodd> jtoomim: anyway, this conversation isn't going to be productive - you have fundementally different goals than I do
436 2016-01-06T05:31:28 <jtoomim> the complete safety of full nodes is great for some use cases, but for a lot of people, they aren't a good tradeoff
437 2016-01-06T05:31:51 <jtoomim> i don't need to run a full node on my cell phone for it to be useful to me
438 2016-01-06T05:32:00 <jtoomim> yeah, fine, let's drop it
439 2016-01-06T05:32:06 <rusty> petertodd: to be fair, fraud proofs will allow a more nuanced range than "full validation" or "miner trust"
440 2016-01-06T05:32:34 <petertodd> rusty: I no longer think fraud proofs work very well
441 2016-01-06T05:33:01 <aj> petertodd: why not?
442 2016-01-06T05:33:04 <petertodd> rusty: you need the data to make a fraud proof, so we're much more likely to end up with validity challenges, where a fraud proof is simply an unmet challenge
443 2016-01-06T05:33:23 <petertodd> rusty: if I make a fraudulent block, why would I ever distribute the data necessary to prove it's fraudulent?
444 2016-01-06T05:33:28 <rusty> petertodd: sure, you withhold data.
445 2016-01-06T05:34:01 <petertodd> rusty: and if you design a system where it otherwise works in that scenario, I have strong doubts we can reliably make it work
446 2016-01-06T05:34:31 <petertodd> rusty: e.g., the converse is my client-side validation ideas in treechains, where there's no need for a fraud proof because the system doesn't work at all unless you validate (trivially ripped off)
447 2016-01-06T05:34:34 <rusty> petertodd: in pettycoin I forced you to present hashes of modified previous block's txs (back 1, 2, 4, ...), similar to the suggestions recently.
448 2016-01-06T05:34:36 *** won9 has joined #bitcoin-dev
449 2016-01-06T05:34:43 <aj> petertodd: doesn't probabilistic validation prevent that? ie, each of your 10 peers randomly asks for 10% of the transactions, and considers it a failure and won't forward if you don't have the data
450 2016-01-06T05:35:03 <petertodd> aj: how do you know those peers aren't a sybil attack?
451 2016-01-06T05:35:23 <rusty> aj: naah, miners are racing, so they build on blocks they can't validate.
452 2016-01-06T05:35:25 <petertodd> aj: probabalistic verification that's consensus enforced is plausible, but not the way you described it
453 2016-01-06T05:35:25 <aj> petertodd: this assumes i'm the attacker
454 2016-01-06T05:35:50 <phantomcircuit> rusty, i used to think that widely deployed fraud proofs offered a mechanism for security that was strong enough to make the need for full nodes reduced
455 2016-01-06T05:35:56 <phantomcircuit> rusty, i no longer believe that
456 2016-01-06T05:35:57 <petertodd> rusty: sure, but that's not really related to fraud proofs
457 2016-01-06T05:36:23 <petertodd> aj: if you're the attacker, sybil attack the network with nodes that don't follow that protocol
458 2016-01-06T05:36:25 <rusty> petertodd: it's related to witholding attacks, which are the remaining avenue once you have compact fraud proofs.
459 2016-01-06T05:36:31 <aj> petertodd: that is, i'm a miner producing invalid blocks, and my peers are exchanges trying to cheaply validate my block
460 2016-01-06T05:36:57 <petertodd> aj: now for something that could work, look at linearized coin history, which uses probabalistic techniques to check for fraud, while simultaneously institutionalizing it
461 2016-01-06T05:37:07 <rusty> aj: but you only need 1 flawed tx, and you can answer 90% of the queries...
462 2016-01-06T05:37:09 <petertodd> rusty: wait, what type of withholding attack?
463 2016-01-06T05:37:31 <rusty> petertodd: information witholding, where miner refuses to supply validation information for a block.
464 2016-01-06T05:38:15 <petertodd> rusty: right, which screws over other *honest* minres, but you still don't have a situation where users can reliably find fraud
465 2016-01-06T05:38:28 <petertodd> rusty: (without validating everything)
466 2016-01-06T05:39:08 <petertodd> rusty: fwiw, I strongly suspect that absent zkSNARKS you *must* have some amount of inflation to make the system scale with regard to validation costs
467 2016-01-06T05:39:36 <petertodd> rusty: (or put another way, with zkSNARKS validation is so easy that the inflation rate necessary to paper over fraud is zero)
468 2016-01-06T05:40:07 <rusty> petertodd: that's why you force miners to prove they knew something about prev block. But that itself becomes hard to disprove; you are back to relying on miners not trusting blocks they can't validate, which has proven a flawed assumption recently in bitcoin.
469 2016-01-06T05:40:16 <rusty> petertodd: that's quite possibly true.
470 2016-01-06T05:41:13 <petertodd> rusty: yeah, from the point of the user, those kinds of proofs are hard to check in a useful way - my segwit prev-block-proof proposal is something I know is pretty weak for instance
471 2016-01-06T05:41:55 <petertodd> rusty: equally, so what if the miners had the data? still doesn't prove all the data is valid if a majority of minres decide to change the protocol
472 2016-01-06T05:43:54 <rusty> petertodd: indeed. gmaxwell proposed a query-response scheme using fountain codes so you couldn't answer more than a very limited number of queries without revealing everything statistically, but I couldn't make sure it was robust against deliberate deceipt...
473 2016-01-06T05:45:46 <petertodd> rusty: yup, that's my experience playing with naive non-interactive proofs as well
474 2016-01-06T05:45:58 <rusty> petertodd: yes, I couldn't improve on your prev-block-proof scheme, either. pettycoin uses a single byte per prev-block (top of SHA256 of <this-block-output> <prevtxs...>).
475 2016-01-06T05:47:27 <petertodd> rusty: heh, well, I guess that's a good sign :/
476 2016-01-06T05:47:28 <rusty> You still end up vulnerable to some miner helpfully supplying the values to you, to optimize your block generation...
477 2016-01-06T05:49:06 <petertodd> rusty: oh I know - it just keeps us at the current status quo, no better
478 2016-01-06T05:49:36 <petertodd> rusty: I'm certainely not claiming that solution stops validationless mining, I just want something simple that will prevent the worst of it
479 2016-01-06T05:50:16 <rusty> petertodd: certainly it increases the work required to do it, which probably won't hurt.
480 2016-01-06T05:51:10 <petertodd> rusty: I'm mostly worried about lazy miners taking shortcuts, at least in the near term. Easy to get some pretty big reorgs that way
481 2016-01-06T05:51:10 *** Dizzle has joined #bitcoin-dev
482 2016-01-06T05:51:34 <rusty> petertodd: agreed.
483 2016-01-06T05:57:26 *** Belxjander has quit IRC
484 2016-01-06T05:57:59 *** AmpEater has joined #bitcoin-dev
485 2016-01-06T05:59:19 *** CheckDavid has quit IRC
486 2016-01-06T06:03:07 *** Belxjander has joined #bitcoin-dev
487 2016-01-06T06:03:38 *** tjader has quit IRC
488 2016-01-06T06:03:56 *** rusty has quit IRC
489 2016-01-06T06:07:53 *** tjader has joined #bitcoin-dev
490 2016-01-06T06:11:47 <jl2012> I'm lost in the discussion. Could that be a tree of H(current block coinbase outputs|previous block tx)? 1 previous block tx as 1 leave
491 2016-01-06T06:14:15 <phantomcircuit> jl2012, which one?
492 2016-01-06T06:14:28 *** jarkinox has quit IRC
493 2016-01-06T06:14:34 <jl2012> the previous block proof
494 2016-01-06T06:21:36 *** AtnevRed has joined #bitcoin-dev
495 2016-01-06T06:26:11 *** AtnevRed has quit IRC
496 2016-01-06T06:26:24 *** AmpEater has quit IRC
497 2016-01-06T06:27:32 *** Giszmo has quit IRC
498 2016-01-06T06:28:11 *** one_zero has joined #bitcoin-dev
499 2016-01-06T06:31:57 *** DigiByteDev has quit IRC
500 2016-01-06T06:35:36 *** Belxjander has quit IRC
501 2016-01-06T06:41:53 *** Belxjander has joined #bitcoin-dev
502 2016-01-06T06:46:12 *** won9 has quit IRC
503 2016-01-06T06:46:34 *** CubicEarth has joined #bitcoin-dev
504 2016-01-06T06:48:25 <jtoomim> trying to sleep, failing...
505 2016-01-06T06:48:42 <jtoomim> IIRC, an SSD and an HDD both read in 4 kiB chunks
506 2016-01-06T06:49:00 <jtoomim> so reading 1 byte is as expensive as reading 4 kiB, as long as the 4 kiB is aligned properly
507 2016-01-06T06:50:11 <jtoomim> if we want to be able to avoid more than 1 read, and if we had the utxo entries stored in an ordered fashion...
508 2016-01-06T06:50:36 <jtoomim> then we can figure out which block contains any given utxo knowing only the first utxo in that block
509 2016-01-06T06:51:19 <jtoomim> for 1 GiB of utxo / 4096 bytes per block, that means 244140 blocks, assuming they're all 100% full
510 2016-01-06T06:51:23 *** Belxjander has quit IRC
511 2016-01-06T06:51:58 <jtoomim> that's something like 8 MB of ram, right?
512 2016-01-06T06:52:08 <jtoomim> i'm probably missing something, though.
513 2016-01-06T06:53:37 *** Belxjander has joined #bitcoin-dev
514 2016-01-06T06:57:04 *** won9 has joined #bitcoin-dev
515 2016-01-06T07:00:48 *** Ylbam has joined #bitcoin-dev
516 2016-01-06T07:02:00 *** DigiByteDev has joined #bitcoin-dev
517 2016-01-06T07:02:12 *** Jaume has quit IRC
518 2016-01-06T07:03:04 *** missmogg_ has quit IRC
519 2016-01-06T07:05:08 *** missmogg has quit IRC
520 2016-01-06T07:06:51 *** mrkent_ has quit IRC
521 2016-01-06T07:09:31 *** ThomasV has joined #bitcoin-dev
522 2016-01-06T07:09:39 *** missmogg has joined #bitcoin-dev
523 2016-01-06T07:09:46 *** missmogg_ has joined #bitcoin-dev
524 2016-01-06T07:14:24 *** Dizzle has quit IRC
525 2016-01-06T07:26:15 *** neozaru has joined #bitcoin-dev
526 2016-01-06T07:26:24 *** nicknamenicknick has joined #bitcoin-dev
527 2016-01-06T07:27:46 *** markus-k has joined #bitcoin-dev
528 2016-01-06T07:28:16 *** Belxjander has quit IRC
529 2016-01-06T07:28:55 *** DevSauce has joined #bitcoin-dev
530 2016-01-06T07:33:20 *** tjader has quit IRC
531 2016-01-06T07:34:53 *** d_t has quit IRC
532 2016-01-06T07:36:14 *** ghtdak has quit IRC
533 2016-01-06T07:37:21 *** Belxjander has joined #bitcoin-dev
534 2016-01-06T07:38:02 *** tjader has joined #bitcoin-dev
535 2016-01-06T07:38:09 *** ghtdak has joined #bitcoin-dev
536 2016-01-06T07:41:45 *** CubicEarth has quit IRC
537 2016-01-06T07:43:50 *** IAmNotDorian has joined #bitcoin-dev
538 2016-01-06T07:43:51 *** IAmNotDorian has joined #bitcoin-dev
539 2016-01-06T07:43:51 *** ThomasV has quit IRC
540 2016-01-06T07:45:33 *** CubicEarth has joined #bitcoin-dev
541 2016-01-06T07:46:42 *** d_t has joined #bitcoin-dev
542 2016-01-06T07:49:28 *** IAmNotDorian has quit IRC
543 2016-01-06T07:50:14 *** Belxjander has quit IRC
544 2016-01-06T07:51:37 *** Belxjander has joined #bitcoin-dev
545 2016-01-06T07:58:18 *** justanotheruser has quit IRC
546 2016-01-06T08:00:22 *** justanotheruser has joined #bitcoin-dev
547 2016-01-06T08:00:35 *** LeMiner has quit IRC
548 2016-01-06T08:01:23 *** supasonic has quit IRC
549 2016-01-06T08:09:28 *** LeMiner has joined #bitcoin-dev
550 2016-01-06T08:10:17 *** neozaru has quit IRC
551 2016-01-06T08:11:58 *** LeMiner has quit IRC
552 2016-01-06T08:17:10 *** Belxjander has quit IRC
553 2016-01-06T08:18:26 *** DougieBot5000 has quit IRC
554 2016-01-06T08:19:53 *** LeMiner has joined #bitcoin-dev
555 2016-01-06T08:21:08 *** DigiByteDev has quit IRC
556 2016-01-06T08:21:37 *** DigiByteDev has joined #bitcoin-dev
557 2016-01-06T08:21:57 *** LeMiner has quit IRC
558 2016-01-06T08:22:26 *** AtnevRed has joined #bitcoin-dev
559 2016-01-06T08:23:04 *** Belxjander has joined #bitcoin-dev
560 2016-01-06T08:25:11 *** xss has quit IRC
561 2016-01-06T08:27:01 *** xss has joined #bitcoin-dev
562 2016-01-06T08:27:03 *** AtnevRed has quit IRC
563 2016-01-06T08:29:15 *** CubicEar_ has joined #bitcoin-dev
564 2016-01-06T08:30:21 *** ThomasV has joined #bitcoin-dev
565 2016-01-06T08:33:04 *** CubicEarth has quit IRC
566 2016-01-06T08:37:55 *** Grouver has joined #bitcoin-dev
567 2016-01-06T08:41:49 <bedeho> does nTweak vary from session to session in the bloom filter?
568 2016-01-06T08:50:42 *** CodesInChaos has quit IRC
569 2016-01-06T08:52:00 *** Ducky- has quit IRC
570 2016-01-06T08:56:47 *** DigiByteDev has quit IRC
571 2016-01-06T08:56:59 *** DigiByteDev has joined #bitcoin-dev
572 2016-01-06T08:57:28 *** oleganza has joined #bitcoin-dev
573 2016-01-06T08:58:41 *** Guyver2 has joined #bitcoin-dev
574 2016-01-06T09:03:41 *** tjader has quit IRC
575 2016-01-06T09:06:00 *** sparetire_ has quit IRC
576 2016-01-06T09:06:05 *** oleganza has quit IRC
577 2016-01-06T09:08:08 *** tjader has joined #bitcoin-dev
578 2016-01-06T09:08:53 *** CodesInChaos has joined #bitcoin-dev
579 2016-01-06T09:09:07 *** metalcamp has joined #bitcoin-dev
580 2016-01-06T09:10:43 *** justanotheruser has quit IRC
581 2016-01-06T09:12:20 *** justanotheruser has joined #bitcoin-dev
582 2016-01-06T09:17:36 *** Quent1 has quit IRC
583 2016-01-06T09:22:01 *** d_t has quit IRC
584 2016-01-06T09:29:41 *** AmpEater has joined #bitcoin-dev
585 2016-01-06T09:31:38 *** jtimon has joined #bitcoin-dev
586 2016-01-06T09:36:17 *** mrkent has joined #bitcoin-dev
587 2016-01-06T09:40:12 *** Belxjander has quit IRC
588 2016-01-06T09:41:37 *** DigiByteDev has quit IRC
589 2016-01-06T09:42:13 *** DigiByteDev has joined #bitcoin-dev
590 2016-01-06T09:45:13 *** DigiByteDev has quit IRC
591 2016-01-06T09:46:18 *** Belxjander has joined #bitcoin-dev
592 2016-01-06T09:48:30 *** one_zero has quit IRC
593 2016-01-06T09:49:11 *** ThomasV has quit IRC
594 2016-01-06T09:53:19 *** one_zero has joined #bitcoin-dev
595 2016-01-06T09:54:28 *** mrkent has quit IRC
596 2016-01-06T10:01:21 *** bit2017 has joined #bitcoin-dev
597 2016-01-06T10:01:27 <bedeho> is the inv response to a mempool message filtered by the bloom filter?
598 2016-01-06T10:01:32 *** _W_ has quit IRC
599 2016-01-06T10:03:58 *** roconnor has quit IRC
600 2016-01-06T10:08:08 *** flo626 has joined #bitcoin-dev
601 2016-01-06T10:09:23 <jl2012> I'm explaining Byzantine Generals Problem to my someone who has no computer science background at all. She asks whether generals with faster communication channel have any advantage. So smart. It's the whole problem for scaling bitcoin
602 2016-01-06T10:10:52 *** DigiByteDev has joined #bitcoin-dev
603 2016-01-06T10:12:26 *** moa has quit IRC
604 2016-01-06T10:13:00 *** cyphase_ has joined #bitcoin-dev
605 2016-01-06T10:13:01 *** cyphase_ has joined #bitcoin-dev
606 2016-01-06T10:14:20 *** Belxjander has quit IRC
607 2016-01-06T10:17:40 *** mrkent has joined #bitcoin-dev
608 2016-01-06T10:19:28 *** Belxjander has joined #bitcoin-dev
609 2016-01-06T10:23:15 *** AtnevRed has joined #bitcoin-dev
610 2016-01-06T10:27:55 *** AtnevRed has quit IRC
611 2016-01-06T10:33:23 *** tjader has quit IRC
612 2016-01-06T10:33:59 *** Belxjander has quit IRC
613 2016-01-06T10:35:09 *** stevenroose_ has joined #bitcoin-dev
614 2016-01-06T10:35:36 *** mnk has joined #bitcoin-dev
615 2016-01-06T10:36:06 *** xss has quit IRC
616 2016-01-06T10:37:15 *** melvster1 has quit IRC
617 2016-01-06T10:38:16 *** tjader has joined #bitcoin-dev
618 2016-01-06T10:38:45 *** ThomasV has joined #bitcoin-dev
619 2016-01-06T10:39:01 *** xiangfu has joined #bitcoin-dev
620 2016-01-06T10:39:13 *** DigiByteDev has quit IRC
621 2016-01-06T10:39:40 *** Belxjander has joined #bitcoin-dev
622 2016-01-06T10:40:18 *** p15 has quit IRC
623 2016-01-06T10:41:57 *** markus-k has quit IRC
624 2016-01-06T10:42:19 *** p15 has joined #bitcoin-dev
625 2016-01-06T10:43:00 *** p15 has quit IRC
626 2016-01-06T10:49:06 *** p15 has joined #bitcoin-dev
627 2016-01-06T10:49:41 *** melvster1 has joined #bitcoin-dev
628 2016-01-06T10:49:54 *** xabbix__ has joined #bitcoin-dev
629 2016-01-06T10:50:24 *** xabbix_ has quit IRC
630 2016-01-06T10:58:01 *** justice_ has quit IRC
631 2016-01-06T10:58:39 *** akrmn has joined #bitcoin-dev
632 2016-01-06T11:02:22 *** xiangfu has quit IRC
633 2016-01-06T11:08:17 *** CubicEar_ has quit IRC
634 2016-01-06T11:16:47 *** markus-k has joined #bitcoin-dev
635 2016-01-06T11:20:05 *** Belxjander has quit IRC
636 2016-01-06T11:24:26 *** akrmn has quit IRC
637 2016-01-06T11:25:10 *** Belxjander has joined #bitcoin-dev
638 2016-01-06T11:25:29 *** won9 has quit IRC
639 2016-01-06T11:26:28 *** ThomasV has quit IRC
640 2016-01-06T11:27:05 *** jtimon has quit IRC
641 2016-01-06T11:35:32 *** trixisowned has quit IRC
642 2016-01-06T11:37:55 *** markus-k has quit IRC
643 2016-01-06T11:38:42 *** markus-k has joined #bitcoin-dev
644 2016-01-06T11:43:26 *** trixisowned has joined #bitcoin-dev
645 2016-01-06T11:51:49 *** GamerSg has joined #bitcoin-dev
646 2016-01-06T11:55:29 *** AmpEater has quit IRC
647 2016-01-06T12:00:15 *** Ducky- has joined #bitcoin-dev
648 2016-01-06T12:02:05 *** gielbier has quit IRC
649 2016-01-06T12:03:44 *** tjader has quit IRC
650 2016-01-06T12:04:39 *** jaclupi has quit IRC
651 2016-01-06T12:06:31 *** brg444 has quit IRC
652 2016-01-06T12:08:24 *** tjader has joined #bitcoin-dev
653 2016-01-06T12:09:03 *** ThomasV has joined #bitcoin-dev
654 2016-01-06T12:12:18 *** mrkent has quit IRC
655 2016-01-06T12:13:22 *** cryptapus_ has joined #bitcoin-dev
656 2016-01-06T12:13:23 *** cryptapus_ has joined #bitcoin-dev
657 2016-01-06T12:21:23 *** p15 has quit IRC
658 2016-01-06T12:23:26 *** jaclupi has joined #bitcoin-dev
659 2016-01-06T12:24:06 *** AtnevRed has joined #bitcoin-dev
660 2016-01-06T12:28:36 *** IAmNotDorian has joined #bitcoin-dev
661 2016-01-06T12:28:37 *** IAmNotDorian has joined #bitcoin-dev
662 2016-01-06T12:28:47 *** AtnevRed has quit IRC
663 2016-01-06T12:40:24 *** tucenaber_ has quit IRC
664 2016-01-06T12:41:55 *** Belxjander has quit IRC
665 2016-01-06T12:44:53 *** antizionist__ has joined #bitcoin-dev
666 2016-01-06T12:45:10 *** one_zero has quit IRC
667 2016-01-06T12:45:14 *** c0rw|away is now known as c0rw1n
668 2016-01-06T12:46:29 *** K1773R has quit IRC
669 2016-01-06T12:49:15 *** Belxjander has joined #bitcoin-dev
670 2016-01-06T12:52:16 *** stevenroose has quit IRC
671 2016-01-06T12:59:42 *** K1773R has joined #bitcoin-dev
672 2016-01-06T13:05:36 *** justanotheruser has quit IRC
673 2016-01-06T13:06:59 *** stevenroose has joined #bitcoin-dev
674 2016-01-06T13:09:44 *** justanotheruser has joined #bitcoin-dev
675 2016-01-06T13:10:09 *** arowser has quit IRC
676 2016-01-06T13:10:16 *** akrmn has joined #bitcoin-dev
677 2016-01-06T13:10:38 *** arowser has joined #bitcoin-dev
678 2016-01-06T13:15:30 *** aschildbach has joined #bitcoin-dev
679 2016-01-06T13:16:02 *** trippysalmon has joined #bitcoin-dev
680 2016-01-06T13:16:10 *** bit2017 has quit IRC
681 2016-01-06T13:19:38 *** DevSauce has quit IRC
682 2016-01-06T13:19:47 *** Logicwax has quit IRC
683 2016-01-06T13:20:09 *** stevenroose has quit IRC
684 2016-01-06T13:20:13 *** stevenroose_ is now known as stevenroose
685 2016-01-06T13:20:23 *** stevenroose|BNC has joined #bitcoin-dev
686 2016-01-06T13:26:51 *** trippysalmon has quit IRC
687 2016-01-06T13:28:04 *** grassass has quit IRC
688 2016-01-06T13:46:04 *** Chris_Stewart_5 has joined #bitcoin-dev
689 2016-01-06T13:47:24 *** AaronvanW has joined #bitcoin-dev
690 2016-01-06T13:47:25 *** AaronvanW has quit IRC
691 2016-01-06T13:47:25 *** AaronvanW has joined #bitcoin-dev
692 2016-01-06T13:50:24 *** Chris_Stewart_5 has quit IRC
693 2016-01-06T13:50:28 *** flozon_ has quit IRC
694 2016-01-06T13:53:27 *** ThomasV has quit IRC
695 2016-01-06T13:54:33 *** cryptapus_ has quit IRC
696 2016-01-06T13:55:13 *** cryptapus_ has joined #bitcoin-dev
697 2016-01-06T13:55:14 *** cryptapus_ has joined #bitcoin-dev
698 2016-01-06T13:57:52 *** LeMiner has joined #bitcoin-dev
699 2016-01-06T13:57:52 *** LeMiner has joined #bitcoin-dev
700 2016-01-06T13:59:23 *** Quent has joined #bitcoin-dev
701 2016-01-06T14:00:52 *** laurentmt has joined #bitcoin-dev
702 2016-01-06T14:02:40 *** mnk has quit IRC
703 2016-01-06T14:02:57 *** mnk has joined #bitcoin-dev
704 2016-01-06T14:04:05 *** Chris_Stewart_5 has joined #bitcoin-dev
705 2016-01-06T14:22:05 *** laurentmt has quit IRC
706 2016-01-06T14:25:01 *** AtnevRed has joined #bitcoin-dev
707 2016-01-06T14:26:14 *** GGuyZ has quit IRC
708 2016-01-06T14:29:39 *** AtnevRed has quit IRC
709 2016-01-06T14:34:17 *** MrHodl has quit IRC
710 2016-01-06T14:36:30 *** matsjj has joined #bitcoin-dev
711 2016-01-06T14:36:43 *** tantalum has joined #bitcoin-dev
712 2016-01-06T14:37:15 *** Giszmo has joined #bitcoin-dev
713 2016-01-06T14:50:17 *** d_t has joined #bitcoin-dev
714 2016-01-06T14:50:22 *** d_t has quit IRC
715 2016-01-06T14:51:10 *** CheckDavid has joined #bitcoin-dev
716 2016-01-06T14:51:30 <gavinandresen> where is the latest versionbits BIP? Is it https://gist.github.com/sipa/bf69659f43e763540550 (created a year ago) ??
717 2016-01-06T14:51:39 <gavinandresen> ... draft bip ...
718 2016-01-06T14:51:43 *** dhill has quit IRC
719 2016-01-06T14:52:07 *** dhill has joined #bitcoin-dev
720 2016-01-06T15:00:16 <sipa> https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
721 2016-01-06T15:00:48 *** hashtag_ has quit IRC
722 2016-01-06T15:02:29 *** tjader has quit IRC
723 2016-01-06T15:03:46 *** rolandnsharp23 has quit IRC
724 2016-01-06T15:03:59 *** rolandnsharp has joined #bitcoin-dev
725 2016-01-06T15:04:49 *** Jaume has joined #bitcoin-dev
726 2016-01-06T15:08:08 *** tjader has joined #bitcoin-dev
727 2016-01-06T15:08:30 *** supasonic has joined #bitcoin-dev
728 2016-01-06T15:09:07 *** Jaume has quit IRC
729 2016-01-06T15:15:43 *** nicknamenicknick has quit IRC
730 2016-01-06T15:15:54 *** laurentmt has joined #bitcoin-dev
731 2016-01-06T15:16:59 *** laurentmt has quit IRC
732 2016-01-06T15:22:46 *** GamerSg has quit IRC
733 2016-01-06T15:24:10 *** sipi has joined #bitcoin-dev
734 2016-01-06T15:27:42 *** DigiByteDev has joined #bitcoin-dev
735 2016-01-06T15:28:05 <xabbix__> Are txids available for query (via decoderawtransaction) only when they are accepted into the mempool?
736 2016-01-06T15:28:29 *** PaulCapestany has quit IRC
737 2016-01-06T15:28:41 <sipa> decoderawtransaction takes a raw transaction and decodes it
738 2016-01-06T15:28:46 <sipa> it doesn't need anything
739 2016-01-06T15:29:08 <sipa> getrawtransaction works only for mempool txn, and for blockchain txn if -txindex is enabled
740 2016-01-06T15:29:15 <sipa> gettransaction works on wallet txn
741 2016-01-06T15:29:23 <xabbix__> I'm running getrawtranscation and decoderawtransaction on txids I see in my debug.log (under 'got inv: tx...'), sometimes I get the info and sometimes I get No information available about transaction (code -5)
742 2016-01-06T15:29:28 <xabbix__> even though I'm running with txindex=1
743 2016-01-06T15:29:38 *** chmod755 has joined #bitcoin-dev
744 2016-01-06T15:30:04 <sipa> what bitcoin core version?
745 2016-01-06T15:30:11 *** PaulCapestany has joined #bitcoin-dev
746 2016-01-06T15:30:32 <xabbix__> v0.11.2.0-g7e27892
747 2016-01-06T15:30:40 <xabbix__> but as you say, getrawtransaction only works on mempool txs
748 2016-01-06T15:30:48 <xabbix__> So maybe that's the issue
749 2016-01-06T15:31:49 <sipa> if you have -txindex, it works on blockchain txn as well
750 2016-01-06T15:31:55 <sipa> except the genesis block
751 2016-01-06T15:32:22 <xabbix__> sipa, as soon as I see 'got inv: tx <txid>' I should be able to run getrawtransaction and decoderawtransaction and get the correct results?
752 2016-01-06T15:32:32 <xabbix__> given I'm running with txindex=1
753 2016-01-06T15:32:40 <sipa> no
754 2016-01-06T15:32:42 *** luigi1111vaca is now known as luigi1111w
755 2016-01-06T15:32:55 <sipa> having the inv does not mean you have the transaction
756 2016-01-06T15:33:17 *** markus-k has quit IRC
757 2016-01-06T15:33:20 <sipa> it may take a while to request the actual txn
758 2016-01-06T15:33:40 <xabbix__> Oh, I see now. So got inv, then askfor tx and then requesting tx
759 2016-01-06T15:33:40 <sipa> and it may be a known invalid/nonconformant transaction, so we don't request it again
760 2016-01-06T15:34:22 <xabbix__> When is it safe to assume the tx is valid and I have it to query on it? When I see the 'AcceptToMemoryPool'?
761 2016-01-06T15:34:38 <sipa> when it's relayed :)
762 2016-01-06T15:34:46 <sipa> there is already a protocol for that :p
763 2016-01-06T15:34:56 *** DigiByteDev has quit IRC
764 2016-01-06T15:35:00 <xabbix__> :)
765 2016-01-06T15:35:29 *** PaulCape_ has joined #bitcoin-dev
766 2016-01-06T15:37:19 *** GGuyZ has joined #bitcoin-dev
767 2016-01-06T15:37:30 <kefkius> Also btw instead of getrawtransaction and decoderawtransaction you can just do 'getrawtransaction <txid> 1' and it will decode it for you
768 2016-01-06T15:37:40 *** PaulCapestany has quit IRC
769 2016-01-06T15:38:55 <xabbix__> kefkius: thanks, didn't know that!
770 2016-01-06T15:39:02 <kefkius> np :)
771 2016-01-06T15:50:03 *** c0rw1n is now known as c0rw|away
772 2016-01-06T15:51:10 *** HansiHE has quit IRC
773 2016-01-06T15:51:28 *** tucenaber has joined #bitcoin-dev
774 2016-01-06T15:51:28 *** tucenaber has joined #bitcoin-dev
775 2016-01-06T15:55:22 *** treehug88 has joined #bitcoin-dev
776 2016-01-06T16:00:25 *** jarkinox has joined #bitcoin-dev
777 2016-01-06T16:05:08 *** cryptapus_ has quit IRC
778 2016-01-06T16:05:39 *** cryptapus_ has joined #bitcoin-dev
779 2016-01-06T16:05:40 *** cryptapus_ has joined #bitcoin-dev
780 2016-01-06T16:06:30 *** MrHodl has joined #bitcoin-dev
781 2016-01-06T16:10:06 *** jarkinox has quit IRC
782 2016-01-06T16:10:28 *** PaulCape_ has quit IRC
783 2016-01-06T16:10:55 *** PaulCapestany has joined #bitcoin-dev
784 2016-01-06T16:11:31 *** hansihe has joined #bitcoin-dev
785 2016-01-06T16:12:34 *** DougieBot5000 has joined #bitcoin-dev
786 2016-01-06T16:16:35 *** atgreen has quit IRC
787 2016-01-06T16:18:53 *** jtimon has joined #bitcoin-dev
788 2016-01-06T16:19:36 <morcos> jtoomim: sorry i couldn't make it through all the back log, but it seems fairly obvious to me that the right thing to do is keep the whole utxo in memory (around 6GB?) but just not to infrequently also flush it to disk. or really maybe you don't even care about doing that. if that node crashes, switch to another with the utxo updated.
789 2016-01-06T16:20:00 <morcos> why would you ever be looking up the utxo on disk if you're mining
790 2016-01-06T16:20:59 <phantomcircuit> morcos, because you dont have umpteen GB of ram? :P
791 2016-01-06T16:22:40 *** akrmn has quit IRC
792 2016-01-06T16:22:56 *** K1773R has quit IRC
793 2016-01-06T16:22:57 *** dermoth has quit IRC
794 2016-01-06T16:23:12 *** xss has joined #bitcoin-dev
795 2016-01-06T16:23:29 *** dermoth has joined #bitcoin-dev
796 2016-01-06T16:25:25 *** Ahmed90 has joined #bitcoin-dev
797 2016-01-06T16:25:42 *** AtnevRed has joined #bitcoin-dev
798 2016-01-06T16:26:37 <jtoomim> morcos, i'm not necessarily thinking just about miners right now
799 2016-01-06T16:27:02 <jtoomim> i'm just thinking that it should be fairly inexpensive to optimize the worst-case to be effectively O(1)
800 2016-01-06T16:27:10 <jtoomim> and that sounds desirable
801 2016-01-06T16:27:11 *** K1773R has joined #bitcoin-dev
802 2016-01-06T16:27:40 <jtoomim> the conversation got derailed a bit, so most of the conversation history is not worth reading
803 2016-01-06T16:27:54 <morcos> phantomcircuit: i agree with many of jtoomins point's that i think some of you guys have got stuck in your heads the old view of mining operations. even a very small miner these days, the cost of a full node and good hardware is minimal
804 2016-01-06T16:28:28 <jtoomim> it's jtoomim, not jtoomin, by the way
805 2016-01-06T16:28:35 <jtoomim> (jtoomin won't tag me)
806 2016-01-06T16:29:29 <morcos> jtoomim: whoops, sorry. i think there is a lot that can be done to minimize the number of disk reads still by using our in memory utxo cache even if we don't try to cache the whole utxo
807 2016-01-06T16:29:29 <jtoomim> i've written up a summary of my DB idea
808 2016-01-06T16:29:33 <jtoomim> if you want i can email it to you
809 2016-01-06T16:29:47 <jtoomim> i'd rather hold off a little before posting it to the list in case there's anything i need to tweak
810 2016-01-06T16:29:57 <jtoomim> morcos agreed
811 2016-01-06T16:30:31 *** AtnevRed has quit IRC
812 2016-01-06T16:30:46 <morcos> we eliminated a lot of unneccessary reads for 0.12, but there is still one left even if everything is in cache (will be merged for 0.13 hopefully) but on top of that there is talk of switching the cache structure to be individual utxo based and not tx based, and combining that with smarter logic on which utxos to keep fresh.
813 2016-01-06T16:31:44 <morcos> right now when we flush the cache to disk, the cache is flushed, that's just plain silly. we should at least keep some stuff there. i experimented with that, and found it surprisingly hard to get much improvement due to deallocation overhead of the utxo storage on the order of 10's of ms.
814 2016-01-06T16:32:34 <morcos> that should have been improved with prevectors, but there is much to go, before trying to worry about optimizing leveldb usage itself i think
815 2016-01-06T16:32:50 <jtoomim> morcos i was thinking of rewriting GBT so that it submitted the template before deallocation, but that would mess up the RPC server system a bit
816 2016-01-06T16:32:55 *** gielbier has joined #bitcoin-dev
817 2016-01-06T16:32:56 *** gielbier has joined #bitcoin-dev
818 2016-01-06T16:32:56 <jtoomim> unless a clever hack was discovered
819 2016-01-06T16:33:04 <jtoomim> but this utxo DB thing is a very different idea
820 2016-01-06T16:33:19 <jtoomim> it's basically a different DB layout
821 2016-01-06T16:33:29 *** tjader has quit IRC
822 2016-01-06T16:33:52 <jtoomim> where you index each UTXO only to the 4 kiB page it sits in, then read that whole page to RAM, and then search the page for the actual UTXO
823 2016-01-06T16:34:09 <jtoomim> and you can do that using way less RAM than a more precise approach
824 2016-01-06T16:34:18 *** Guest65074 is now known as bsm117532
825 2016-01-06T16:35:15 <jtoomim> you just need to store in RAM the starting key value (which means implicitly the ending key value) for each page
826 2016-01-06T16:36:17 <jtoomim> excuse me, need to go power cycle a few miners...
827 2016-01-06T16:37:30 <morcos> jtoomim: sounds maybe interesting, but think its putting our optimization efforts at not the lowest hanging fruit
828 2016-01-06T16:37:47 <sipa> jtoomim: that's kindof how leveldb already works (nor quite, but it has acxeleration/index structures)
829 2016-01-06T16:38:15 *** tjader has joined #bitcoin-dev
830 2016-01-06T16:38:31 <sipa> jtoomim: but you still need to access disk at that point
831 2016-01-06T16:41:53 <jtoomim> sipa yes, a disk access may be unavoidable if you can't cache the UTXOs that you're interested in
832 2016-01-06T16:42:06 <jtoomim> i'm just trying to make the worst case better by guaranteeing only a single access
833 2016-01-06T16:42:09 *** melvster1 has quit IRC
834 2016-01-06T16:42:10 <jtoomim> at worst
835 2016-01-06T16:42:18 <jtoomim> and zero accesses when caching works
836 2016-01-06T16:42:39 <jtoomim> and being more efficient with the RAM usage for the acceleration/index structures that leveldb uses
837 2016-01-06T16:43:04 *** IAmNotDorian has quit IRC
838 2016-01-06T16:43:17 <jtoomim> leveldb is probably designed to be functional across a broad range of entry sizes, and utxos are pretty small, so i think we can make some tradeoffs more intelligently than leveldb
839 2016-01-06T16:43:51 <jtoomim> obviously, caching all the UTXOs in RAM is going to be the fastest. I'm not disagreeing with that. that is preferable for any miner.
840 2016-01-06T16:44:50 <jtoomim> but for non-miners (e.g. IBD) and for miners who don't know that they should change the -dbcache setting, improving performance by 2x or more could be possible
841 2016-01-06T16:45:03 *** d_t has joined #bitcoin-dev
842 2016-01-06T16:45:55 <jtoomim> morcos yes, maybe. I'm not looking at implementing this right now. it's just an early thought i had. i don't really understand the current db system well enough to be a good judge.
843 2016-01-06T16:49:02 <jtoomim> it would be nice if the project had a benchmark suite so we could easily and reliably compare the effects of different hardware and different algorithms...
844 2016-01-06T16:51:35 *** murch has joined #bitcoin-dev
845 2016-01-06T16:54:05 *** melvster1 has joined #bitcoin-dev
846 2016-01-06T16:54:58 *** xss has quit IRC
847 2016-01-06T16:58:03 *** arowser has quit IRC
848 2016-01-06T16:58:35 *** arowser has joined #bitcoin-dev
849 2016-01-06T16:59:02 *** hashtag_ has joined #bitcoin-dev
850 2016-01-06T16:59:55 *** trippysalmon has joined #bitcoin-dev
851 2016-01-06T17:00:35 *** Dizzle has joined #bitcoin-dev
852 2016-01-06T17:10:56 *** neozaru has joined #bitcoin-dev
853 2016-01-06T17:14:17 *** Grouver has quit IRC
854 2016-01-06T17:17:15 <maaku> Utxos are not necessarily small -- they are stored per tx not pet output
855 2016-01-06T17:18:59 *** flo626 has quit IRC
856 2016-01-06T17:26:00 *** sparetire_ has joined #bitcoin-dev
857 2016-01-06T17:26:41 *** brson has joined #bitcoin-dev
858 2016-01-06T17:27:15 *** brianhoffman has joined #bitcoin-dev
859 2016-01-06T17:29:20 *** brianhof_ has quit IRC
860 2016-01-06T17:29:23 *** bit2017 has joined #bitcoin-dev
861 2016-01-06T17:33:43 *** metalcamp has quit IRC
862 2016-01-06T17:36:06 <jtoomim> maaku: noted, thanks.
863 2016-01-06T17:36:42 *** elichai2 has joined #bitcoin-dev
864 2016-01-06T17:36:42 *** elichai2 has joined #bitcoin-dev
865 2016-01-06T17:39:29 *** metalcamp has joined #bitcoin-dev
866 2016-01-06T17:39:32 *** Belxjander has quit IRC
867 2016-01-06T17:48:22 *** Belxjander has joined #bitcoin-dev
868 2016-01-06T17:50:19 *** mrkent has joined #bitcoin-dev
869 2016-01-06T17:51:20 *** akrmn has joined #bitcoin-dev
870 2016-01-06T17:52:12 *** lsrp has joined #bitcoin-dev
871 2016-01-06T17:53:46 *** ThomasV has joined #bitcoin-dev
872 2016-01-06T17:56:18 *** jtimon has quit IRC
873 2016-01-06T17:58:46 *** elichai2 has quit IRC
874 2016-01-06T17:59:14 *** GAit has joined #bitcoin-dev
875 2016-01-06T18:01:31 *** lsrp has quit IRC
876 2016-01-06T18:01:32 *** Yoghur114_2 has joined #bitcoin-dev
877 2016-01-06T18:02:36 *** c-cex-yuriy has joined #bitcoin-dev
878 2016-01-06T18:03:50 *** tjader has quit IRC
879 2016-01-06T18:05:59 *** Yoghur114_2 has quit IRC
880 2016-01-06T18:07:46 *** Yoghur114_2 has joined #bitcoin-dev
881 2016-01-06T18:08:52 *** tjader has joined #bitcoin-dev
882 2016-01-06T18:09:34 *** Yoghur114_2 has quit IRC
883 2016-01-06T18:10:21 *** Yoghur114_2 has joined #bitcoin-dev
884 2016-01-06T18:11:19 *** kadoban has quit IRC
885 2016-01-06T18:12:08 *** Yoghur114_2 has quit IRC
886 2016-01-06T18:12:13 *** lsrp has joined #bitcoin-dev
887 2016-01-06T18:14:58 *** Yoghur114_2 has joined #bitcoin-dev
888 2016-01-06T18:16:17 *** erasmospunk has joined #bitcoin-dev
889 2016-01-06T18:21:05 *** trippysalmon has quit IRC
890 2016-01-06T18:26:35 *** AtnevRed has joined #bitcoin-dev
891 2016-01-06T18:29:22 <gavinandresen> jtoomim: there's a benchmark framework in place, see src/bench/
892 2016-01-06T18:30:50 <jtoomim> added 3 months ago. nice.
893 2016-01-06T18:30:59 *** nelisky has quit IRC
894 2016-01-06T18:31:04 <jtoomim> looks pretty sparse though
895 2016-01-06T18:31:23 *** AtnevRed has quit IRC
896 2016-01-06T18:31:24 *** AaronvanW has quit IRC
897 2016-01-06T18:32:19 *** atgreen has joined #bitcoin-dev
898 2016-01-06T18:33:41 <dgenr8> jtoomim: are you thinking of a utxo lookup scenario other than a full node keeping up with validation?
899 2016-01-06T18:34:21 <jtoomim> i try to think of all of the scenarios
900 2016-01-06T18:35:02 <jtoomim> e.g. a home p2pool miner who doesn't pay much attention to optimization
901 2016-01-06T18:35:22 <jtoomim> a medium-small-scale miner in a future with 50 GiB UTXO set who only has 32 GB of ram
902 2016-01-06T18:35:30 <jtoomim> a full node keeping up with validation
903 2016-01-06T18:35:35 <jtoomim> a full node doing IBD
904 2016-01-06T18:35:45 *** _yoy_ has joined #bitcoin-dev
905 2016-01-06T18:35:49 <jtoomim> each scenario has different needs
906 2016-01-06T18:36:30 <jtoomim> and it seems to me that no scenario would suffer from dedicating about 0.8% of the UTXO's size to a RAM table to make UTXO lookup O(1) and single-access
907 2016-01-06T18:36:35 <jtoomim> and a few of them would benefit
908 2016-01-06T18:36:55 <jtoomim> i'm not sure it's worth the programming effort, but it might be
909 2016-01-06T18:36:55 *** GAit has quit IRC
910 2016-01-06T18:36:59 <jtoomim> dgenr8
911 2016-01-06T18:37:35 *** GAit has joined #bitcoin-dev
912 2016-01-06T18:38:08 *** Skender has joined #bitcoin-dev
913 2016-01-06T18:38:39 <dgenr8> the scenario i like to think about is a SPV client asking the network to validate a utxo
914 2016-01-06T18:38:51 *** odlD2 has quit IRC
915 2016-01-06T18:38:56 *** YoY has quit IRC
916 2016-01-06T18:39:05 <jtoomim> ok, that's a good one too
917 2016-01-06T18:39:27 <jtoomim> eventually, there will be some limiting ratio of SPV wallets to full nodes based on the performance of that lookup
918 2016-01-06T18:39:47 <jtoomim> (there might be another limiting ratio that's smaller, of course)
919 2016-01-06T18:39:49 <dgenr8> for that, no cache needed. just indexes. and perhaps they could be distributed.
920 2016-01-06T18:41:27 <jtoomim> yeah, fermi est says SPV requests shouldn't be numerically significant
921 2016-01-06T18:42:53 <dgenr8> huh?
922 2016-01-06T18:43:00 <jtoomim> a fermi estimate
923 2016-01-06T18:43:55 <jtoomim> if the average SPV wallet requests a batch of 100 utxos once per day, that's about 1 request every 1000 seconds
924 2016-01-06T18:44:22 <jtoomim> if a full node can do about 1000 disk lookups per second, then one full node should be able to handle around 1 million SPV wallets
925 2016-01-06T18:44:43 <jtoomim> numbers accurate to within one or two orders of magnitude
926 2016-01-06T18:44:48 <phantomcircuit> morcos, it's true that miners today can afford a pretty expensive server since it's cheap relative to cost of hardware
927 2016-01-06T18:45:02 <phantomcircuit> morcos, the problem is that the entry cost is pretty damned high
928 2016-01-06T18:45:06 <jtoomim> dgenr8 so probably not relevant
929 2016-01-06T18:45:28 <phantomcircuit> morcos, ie the ecosystem is super messed up right now, why would we actively make it worse?
930 2016-01-06T18:45:46 *** lsrp has quit IRC
931 2016-01-06T18:45:47 <phantomcircuit> either way the issue is more that user of the system must run full nodes
932 2016-01-06T18:45:51 <phantomcircuit> and less about miners really
933 2016-01-06T18:46:16 <phantomcircuit> but that requires a more sophisticated argument about incentives which is why the focus seems to have been on miners
934 2016-01-06T18:47:12 <dgenr8> jtoomim: with cache an no index, full node needs a lot of memory. without a distributed index, it also needs a lot of disk. unless block size is tiny or course.
935 2016-01-06T18:47:45 <jtoomim> dgenr8: distributed index?
936 2016-01-06T18:48:30 <dgenr8> partial nodes collectively route and serve requests. future idea.
937 2016-01-06T18:48:41 <phantomcircuit> <morcos> right now when we flush the cache to disk, the cache is flushed, that's just plain silly. we should at least keep some stuff there. i experimented with that, and found it surprisingly hard to get much improvement due to deallocation overhead of the utxo storage on the order of 10's of ms.
938 2016-01-06T18:48:43 <phantomcircuit> wait what?
939 2016-01-06T18:51:04 <phantomcircuit> <dgenr8> the scenario i like to think about is a SPV client asking the network to validate a utxo
940 2016-01-06T18:51:09 <phantomcircuit> eh? that's totally useless
941 2016-01-06T18:51:21 <phantomcircuit> "hello random internet people please dont lie to me"
942 2016-01-06T18:51:37 *** odlD2 has joined #bitcoin-dev
943 2016-01-06T18:52:41 <Skender> Hello guys, I want to send some bitcoin packets over sockets but apparently I'm getting the checksum wrong. Is there something special about how bitcoin-qt calculates sha256(sha256(something))? I tried to verify the checksum of packets sent by bitcoin-qt and can't seem to get the right checksum. On the bitcoin developer reference it says that sha256(sha256(<empty string>)) should give 0x5df6e0e2 as the first 4 bytes.
944 2016-01-06T18:53:08 <phantomcircuit> Skender, iirc it's byte swapped
945 2016-01-06T18:53:21 <Skender> kk
946 2016-01-06T18:53:28 <Skender> so the full payload reversed?
947 2016-01-06T18:53:47 <phantomcircuit> Skender, no it's sha256(sha256(payload))
948 2016-01-06T18:53:52 <phantomcircuit> then reverse the result
949 2016-01-06T18:54:00 <dgenr8> phantomcircuit: that view is not surprising if you already thing SPV clients are useless
950 2016-01-06T18:54:03 <Skender> okay
951 2016-01-06T18:54:54 *** NicolasDorier has joined #bitcoin-dev
952 2016-01-06T18:55:20 *** AaronvanW has joined #bitcoin-dev
953 2016-01-06T18:55:21 <phantomcircuit> dgenr8, nobody has yet implemented an spv client as described in the whitepaper because nobody has implemented fraud proofs, because it turns out they dont work as well as we thought 5 years ago
954 2016-01-06T18:55:42 <phantomcircuit> the things people are using today which they call spv clients are just that clients
955 2016-01-06T18:56:07 <phantomcircuit> they are not network participants and do not provide any incentives alignment against miners arbitrarily changing the rules
956 2016-01-06T18:56:24 <phantomcircuit> like say increasing the subsidy payout in violation of the protocol
957 2016-01-06T18:56:54 <phantomcircuit> (which is exactly what some people have argued for, but in a very round about way that avoids explicitly calling for it)
958 2016-01-06T18:56:58 *** luigi1111w has quit IRC
959 2016-01-06T18:57:48 <Skender> Do I need to reverse the sha256 hash before hashing it again? So sha256("") -> reverse -> sha256 -> reverse? Because if I reverse it after double hashing I still don't get 0x5df6e0e2 :/
960 2016-01-06T18:59:01 <phantomcircuit> i was wrong it's not reversed
961 2016-01-06T18:59:05 <phantomcircuit> i dont know what you're doing but
962 2016-01-06T18:59:18 <phantomcircuit> sha256(sha256("")) == 0x5df6e0e2761359d30a8275058e299fcc0381534545f55cf43e41983f5d4c9456
963 2016-01-06T19:00:21 <Skender> This tool: http://www.xorbin.com/tools/sha256-hash-calculator as well as my local implementation says otherwise :/ I should maybe just use the sha256 implementation of the bitcoin-core on github.
964 2016-01-06T19:02:10 <Skender> How did you calculate the hash?
965 2016-01-06T19:02:13 <phantomcircuit> Skender, it sounds like you're calculating sha256(hex(sha256("")))
966 2016-01-06T19:02:19 <phantomcircuit> what result do you get
967 2016-01-06T19:02:29 <Skender> cd372fb85148700fa88095e3492d3f9f5beb43e555e5ff26d95f5a6adc36f8e6
968 2016-01-06T19:02:59 <dgenr8> phantomcircuit: improved SPV client and protocol is fertile ground
969 2016-01-06T19:03:01 <phantomcircuit> yup
970 2016-01-06T19:03:10 <phantomcircuit> Skender, you're calculating the hash of the hex string the second time
971 2016-01-06T19:03:19 <phantomcircuit> you need to calculate the hash of the binary result
972 2016-01-06T19:03:20 <Skender> okay ty
973 2016-01-06T19:03:52 <Skender> Got the right result :) ty
974 2016-01-06T19:03:57 <phantomcircuit> dgenr8, yes and i wish... someone else all the luck in the world on trying
975 2016-01-06T19:07:04 *** Guest43031 has joined #bitcoin-dev
976 2016-01-06T19:07:05 *** Guest43031 has joined #bitcoin-dev
977 2016-01-06T19:07:05 *** Guest43031 is now known as luigi1111w
978 2016-01-06T19:08:14 *** cyphase_ has quit IRC
979 2016-01-06T19:15:06 *** xss has joined #bitcoin-dev
980 2016-01-06T19:18:34 *** Guest43031 has joined #bitcoin-dev
981 2016-01-06T19:18:54 *** luigi1111w has quit IRC
982 2016-01-06T19:19:07 *** Guest43031 has quit IRC
983 2016-01-06T19:19:07 *** Guest43031 has joined #bitcoin-dev
984 2016-01-06T19:19:07 *** Guest43031 is now known as luigi1111w
985 2016-01-06T19:22:40 *** NicolasDorier has quit IRC
986 2016-01-06T19:22:58 *** lsrp has joined #bitcoin-dev
987 2016-01-06T19:28:51 *** fuc has joined #bitcoin-dev
988 2016-01-06T19:29:44 *** Logicwax has joined #bitcoin-dev
989 2016-01-06T19:32:03 *** MrHodl has quit IRC
990 2016-01-06T19:32:06 *** Burrito has joined #bitcoin-dev
991 2016-01-06T19:32:15 *** arubi has quit IRC
992 2016-01-06T19:34:11 *** tjader has quit IRC
993 2016-01-06T19:34:18 *** Skender has quit IRC
994 2016-01-06T19:38:02 *** matsjj has quit IRC
995 2016-01-06T19:38:58 *** tjader has joined #bitcoin-dev
996 2016-01-06T19:39:51 *** arubi has joined #bitcoin-dev
997 2016-01-06T19:41:12 *** CubicEarth has joined #bitcoin-dev
998 2016-01-06T19:41:17 *** Kexkey has joined #bitcoin-dev
999 2016-01-06T19:43:39 *** petrkr has joined #bitcoin-dev
1000 2016-01-06T19:49:47 *** lsrp has quit IRC
1001 2016-01-06T19:54:23 *** Logicwax has quit IRC
1002 2016-01-06T19:54:58 *** Logicwax has joined #bitcoin-dev
1003 2016-01-06T19:57:12 *** AaronvanW has quit IRC
1004 2016-01-06T19:59:07 *** aschildbach has quit IRC
1005 2016-01-06T20:04:10 *** cryptapus_ has quit IRC
1006 2016-01-06T20:04:46 *** cryptapus_ has joined #bitcoin-dev
1007 2016-01-06T20:04:46 *** cryptapus_ has joined #bitcoin-dev
1008 2016-01-06T20:09:58 *** rayn has joined #bitcoin-dev
1009 2016-01-06T20:11:45 *** erasmospunk has quit IRC
1010 2016-01-06T20:17:27 *** arubi has quit IRC
1011 2016-01-06T20:18:34 *** lsrp has joined #bitcoin-dev
1012 2016-01-06T20:20:22 *** lsrp has quit IRC
1013 2016-01-06T20:20:44 *** lsrp has joined #bitcoin-dev
1014 2016-01-06T20:23:51 *** tantalum has quit IRC
1015 2016-01-06T20:25:43 *** erasmospunk has joined #bitcoin-dev
1016 2016-01-06T20:25:57 *** lsrp has quit IRC
1017 2016-01-06T20:26:18 *** lsrp has joined #bitcoin-dev
1018 2016-01-06T20:27:28 *** lsrp has quit IRC
1019 2016-01-06T20:27:30 *** AtnevRed has joined #bitcoin-dev
1020 2016-01-06T20:29:34 *** lsrp has joined #bitcoin-dev
1021 2016-01-06T20:32:15 *** AtnevRed has quit IRC
1022 2016-01-06T20:33:50 *** arubi has joined #bitcoin-dev
1023 2016-01-06T20:33:54 *** nowan_ has joined #bitcoin-dev
1024 2016-01-06T20:34:53 *** MrHodl has joined #bitcoin-dev
1025 2016-01-06T20:35:59 *** nowan has quit IRC
1026 2016-01-06T20:37:59 *** nowan_ has quit IRC
1027 2016-01-06T20:39:39 *** AaronvanW has joined #bitcoin-dev
1028 2016-01-06T20:41:02 *** nowan has joined #bitcoin-dev
1029 2016-01-06T20:43:17 *** Kexkey has quit IRC
1030 2016-01-06T20:48:04 *** nowan has quit IRC
1031 2016-01-06T20:49:26 *** paveljanik has joined #bitcoin-dev
1032 2016-01-06T20:49:26 *** paveljanik has quit IRC
1033 2016-01-06T20:49:26 *** paveljanik has joined #bitcoin-dev
1034 2016-01-06T20:55:46 *** jtimon has joined #bitcoin-dev
1035 2016-01-06T20:56:09 *** Kexkey has joined #bitcoin-dev
1036 2016-01-06T20:56:21 *** nowan has joined #bitcoin-dev
1037 2016-01-06T20:57:44 *** nowan has quit IRC
1038 2016-01-06T20:59:53 *** lsrp has quit IRC
1039 2016-01-06T21:00:36 *** nowan has joined #bitcoin-dev
1040 2016-01-06T21:02:33 *** quetzalcotalus has joined #bitcoin-dev
1041 2016-01-06T21:04:32 *** tjader has quit IRC
1042 2016-01-06T21:05:05 *** atgreen has quit IRC
1043 2016-01-06T21:05:40 *** benrcole has joined #bitcoin-dev
1044 2016-01-06T21:08:45 *** lsrp has joined #bitcoin-dev
1045 2016-01-06T21:09:06 *** tjader has joined #bitcoin-dev
1046 2016-01-06T21:14:53 *** antimattero has joined #bitcoin-dev
1047 2016-01-06T21:15:48 *** benrcole1 has joined #bitcoin-dev
1048 2016-01-06T21:15:59 *** benrcole has quit IRC
1049 2016-01-06T21:19:50 *** lsrp has quit IRC
1050 2016-01-06T21:20:06 *** lsrp has joined #bitcoin-dev
1051 2016-01-06T21:21:36 *** ssa3512 has joined #bitcoin-dev
1052 2016-01-06T21:22:37 *** moa has joined #bitcoin-dev
1053 2016-01-06T21:28:08 *** patcon has joined #bitcoin-dev
1054 2016-01-06T21:37:16 *** brianhof_ has joined #bitcoin-dev
1055 2016-01-06T21:39:56 *** erasmospunk has quit IRC
1056 2016-01-06T21:40:15 *** lsrp has quit IRC
1057 2016-01-06T21:40:34 *** brianhoffman has quit IRC
1058 2016-01-06T21:42:27 *** lsrp has joined #bitcoin-dev
1059 2016-01-06T21:43:38 *** d_t has quit IRC
1060 2016-01-06T21:46:08 *** Emcy_ has joined #bitcoin-dev
1061 2016-01-06T21:46:09 *** Emcy_ has joined #bitcoin-dev
1062 2016-01-06T21:46:30 *** sipi has quit IRC
1063 2016-01-06T21:46:51 *** kadoban has joined #bitcoin-dev
1064 2016-01-06T21:46:56 *** kadoban has joined #bitcoin-dev
1065 2016-01-06T21:49:00 *** Emcy has quit IRC
1066 2016-01-06T21:51:00 *** lsrp has quit IRC
1067 2016-01-06T21:51:19 *** paveljanik has quit IRC
1068 2016-01-06T21:53:47 *** zookolaptop has joined #bitcoin-dev
1069 2016-01-06T21:55:04 *** patcon has quit IRC
1070 2016-01-06T21:55:58 *** t7 has joined #bitcoin-dev
1071 2016-01-06T21:57:15 *** Guest14655 has joined #bitcoin-dev
1072 2016-01-06T22:02:13 *** GAit1 has joined #bitcoin-dev
1073 2016-01-06T22:02:28 *** Dr-G2 has joined #bitcoin-dev
1074 2016-01-06T22:02:28 *** Dr-G has quit IRC
1075 2016-01-06T22:02:34 *** RazielZ has joined #bitcoin-dev
1076 2016-01-06T22:03:01 *** Raziel has quit IRC
1077 2016-01-06T22:03:03 *** RazielZ is now known as Raziel
1078 2016-01-06T22:04:04 *** PsychoticBoy_ has joined #bitcoin-dev
1079 2016-01-06T22:04:31 *** runeks_ has joined #bitcoin-dev
1080 2016-01-06T22:04:34 *** rolandnsharp has quit IRC
1081 2016-01-06T22:04:34 *** mr_burdell has quit IRC
1082 2016-01-06T22:04:35 *** Amnez777 has quit IRC
1083 2016-01-06T22:04:36 *** dlb76 has quit IRC
1084 2016-01-06T22:04:37 *** mr_burdell_ has joined #bitcoin-dev
1085 2016-01-06T22:04:39 *** wpalczynski_ has joined #bitcoin-dev
1086 2016-01-06T22:04:55 *** GAit has quit IRC
1087 2016-01-06T22:04:56 *** PsychoticBoy has quit IRC
1088 2016-01-06T22:04:56 *** aj has quit IRC
1089 2016-01-06T22:04:56 *** runeks has quit IRC
1090 2016-01-06T22:04:57 *** hno has quit IRC
1091 2016-01-06T22:04:57 *** nadio_ has quit IRC
1092 2016-01-06T22:05:01 *** mr_burdell_ is now known as mr_burdell
1093 2016-01-06T22:05:14 *** rusty has joined #bitcoin-dev
1094 2016-01-06T22:05:16 *** Ylbam has quit IRC
1095 2016-01-06T22:05:16 *** Squidicuz has quit IRC
1096 2016-01-06T22:05:16 *** flyingkiwi has quit IRC
1097 2016-01-06T22:05:16 *** ThomasKeller has quit IRC
1098 2016-01-06T22:05:17 *** Barbatos_ has quit IRC
1099 2016-01-06T22:05:18 *** Jaamg has quit IRC
1100 2016-01-06T22:05:22 *** Jaamg has joined #bitcoin-dev
1101 2016-01-06T22:05:28 *** runeks_ is now known as runeks
1102 2016-01-06T22:05:31 *** mr_burdell is now known as Guest31456
1103 2016-01-06T22:05:33 *** Amnez777 has joined #bitcoin-dev
1104 2016-01-06T22:05:36 *** CodesInChaos has quit IRC
1105 2016-01-06T22:05:36 *** TheSeven has quit IRC
1106 2016-01-06T22:05:36 *** wpalczynski has quit IRC
1107 2016-01-06T22:05:46 *** CodesInChaos has joined #bitcoin-dev
1108 2016-01-06T22:06:02 *** Amnez777 has joined #bitcoin-dev
1109 2016-01-06T22:06:02 *** aj has joined #bitcoin-dev
1110 2016-01-06T22:06:02 *** Amnez777 has quit IRC
1111 2016-01-06T22:06:09 *** ThomasKeller has joined #bitcoin-dev
1112 2016-01-06T22:06:40 *** Amnez777 has joined #bitcoin-dev
1113 2016-01-06T22:06:49 *** wpalczynski_ is now known as wpalczynski
1114 2016-01-06T22:06:49 *** PsychoticBoy_ is now known as PsychoticBoy
1115 2016-01-06T22:06:52 *** TheSeven has joined #bitcoin-dev
1116 2016-01-06T22:07:03 *** nadio has joined #bitcoin-dev
1117 2016-01-06T22:07:04 *** nadio has joined #bitcoin-dev
1118 2016-01-06T22:07:13 *** Amnez777 has joined #bitcoin-dev
1119 2016-01-06T22:08:50 *** petrkr has quit IRC
1120 2016-01-06T22:09:18 *** erasmospunk has joined #bitcoin-dev
1121 2016-01-06T22:10:29 *** hno has joined #bitcoin-dev
1122 2016-01-06T22:10:31 *** flyingkiwi has joined #bitcoin-dev
1123 2016-01-06T22:10:36 *** cryptapus_ has quit IRC
1124 2016-01-06T22:11:18 *** Barbatos has joined #bitcoin-dev
1125 2016-01-06T22:11:24 *** Emcy_ has quit IRC
1126 2016-01-06T22:11:36 *** melvster1 has quit IRC
1127 2016-01-06T22:11:50 *** Emcy_ has joined #bitcoin-dev
1128 2016-01-06T22:11:51 *** Emcy_ has joined #bitcoin-dev
1129 2016-01-06T22:12:42 *** dlb76 has joined #bitcoin-dev
1130 2016-01-06T22:18:32 *** treehug88 has quit IRC
1131 2016-01-06T22:18:35 *** rdekley_ has quit IRC
1132 2016-01-06T22:18:53 *** rdekley_ has joined #bitcoin-dev
1133 2016-01-06T22:19:38 *** Arnavion has quit IRC
1134 2016-01-06T22:19:48 *** Ylbam has joined #bitcoin-dev
1135 2016-01-06T22:20:01 *** Arnavion has joined #bitcoin-dev
1136 2016-01-06T22:20:56 *** c0rw|away is now known as c0rw|scrollback
1137 2016-01-06T22:21:03 *** AtashiCon has quit IRC
1138 2016-01-06T22:21:22 *** AtashiCon has joined #bitcoin-dev
1139 2016-01-06T22:22:54 *** neozaru has quit IRC
1140 2016-01-06T22:23:50 *** melvster1 has joined #bitcoin-dev
1141 2016-01-06T22:25:05 *** brg444 has joined #bitcoin-dev
1142 2016-01-06T22:25:08 *** Guyver2 has quit IRC
1143 2016-01-06T22:25:34 *** Squidicuz has joined #bitcoin-dev
1144 2016-01-06T22:27:39 *** lsrp has joined #bitcoin-dev
1145 2016-01-06T22:28:15 *** AtnevRed has joined #bitcoin-dev
1146 2016-01-06T22:32:08 *** Emcy has joined #bitcoin-dev
1147 2016-01-06T22:32:16 *** Emcy has joined #bitcoin-dev
1148 2016-01-06T22:32:17 *** tjader has quit IRC
1149 2016-01-06T22:33:05 *** jtimon has quit IRC
1150 2016-01-06T22:33:07 *** AtnevRed has quit IRC
1151 2016-01-06T22:33:30 *** won9 has joined #bitcoin-dev
1152 2016-01-06T22:35:35 *** Emcy_ has quit IRC
1153 2016-01-06T22:36:12 *** lsrp has quit IRC
1154 2016-01-06T22:37:50 *** lsrp has joined #bitcoin-dev
1155 2016-01-06T22:38:55 *** c0rw|scrollback is now known as c0rw1n
1156 2016-01-06T22:39:05 *** Diablo-D3 has quit IRC
1157 2016-01-06T22:39:13 *** tjader has joined #bitcoin-dev
1158 2016-01-06T22:39:16 *** Diablo-D3 has joined #bitcoin-dev
1159 2016-01-06T22:40:55 *** Heliox_ is now known as Heliox
1160 2016-01-06T22:45:30 *** rusty has quit IRC
1161 2016-01-06T22:51:45 *** JackH has quit IRC
1162 2016-01-06T22:55:41 *** cryptopeddler has quit IRC
1163 2016-01-06T22:57:09 *** cryptopeddler has joined #bitcoin-dev
1164 2016-01-06T22:57:33 *** JackH has joined #bitcoin-dev
1165 2016-01-06T22:59:17 *** Emcy_ has joined #bitcoin-dev
1166 2016-01-06T22:59:18 *** Emcy_ has joined #bitcoin-dev
1167 2016-01-06T23:00:01 *** oneeman has joined #bitcoin-dev
1168 2016-01-06T23:00:36 *** stevenroose has quit IRC
1169 2016-01-06T23:00:42 *** stevenroose|BNC is now known as stevenroose
1170 2016-01-06T23:01:56 *** stevenroose has quit IRC
1171 2016-01-06T23:02:40 *** kadoban has quit IRC
1172 2016-01-06T23:02:50 *** Emcy has quit IRC
1173 2016-01-06T23:03:05 *** lsrp has quit IRC
1174 2016-01-06T23:08:19 *** lsrp has joined #bitcoin-dev
1175 2016-01-06T23:11:16 *** kadoban has joined #bitcoin-dev
1176 2016-01-06T23:11:24 *** cryptopeddler has quit IRC
1177 2016-01-06T23:13:28 *** cryptopeddler has joined #bitcoin-dev
1178 2016-01-06T23:13:30 *** AaronvanW has quit IRC
1179 2016-01-06T23:14:41 *** murch has quit IRC
1180 2016-01-06T23:16:32 *** lorenzoasr has joined #bitcoin-dev
1181 2016-01-06T23:16:33 <lorenzoasr> hello
1182 2016-01-06T23:18:12 *** erasmospunk has quit IRC
1183 2016-01-06T23:19:13 <lorenzoasr> which is the minimum overall transaction amount that is not considered as "dust" ?
1184 2016-01-06T23:19:36 <sipa> depends on your relay fee, which is configurable
1185 2016-01-06T23:20:20 <sipa> in recent vereions of Bitcoin Corez with the exception of 0.11.2 (due to a temporary mempool bloating fix), the relay fee is by default 1 satoshi per byte
1186 2016-01-06T23:20:45 <sipa> which corresponds to a few hundred satoshi as dust limit
1187 2016-01-06T23:21:02 <sipa> as it would cost more to redeem the coin than leaving it
1188 2016-01-06T23:21:12 *** cryptopeddler has quit IRC
1189 2016-01-06T23:21:56 *** kadoban has quit IRC
1190 2016-01-06T23:22:40 *** cryptopeddler has joined #bitcoin-dev
1191 2016-01-06T23:27:32 *** kadoban has joined #bitcoin-dev
1192 2016-01-06T23:28:33 *** benrcole1 has quit IRC
1193 2016-01-06T23:28:37 <lorenzoasr> thank you sipa, so if I send a tx of 1 satoshi with 1 input and 1 output, the fee should be at least 200 satoshis as the overall weight will be around 200 bytes, is this correct?
1194 2016-01-06T23:29:34 *** Squidicuz has quit IRC
1195 2016-01-06T23:34:35 *** lsrp has quit IRC
1196 2016-01-06T23:35:34 *** mrkent has quit IRC
1197 2016-01-06T23:36:00 *** DougieBot5000 has quit IRC
1198 2016-01-06T23:36:01 *** mrkent has joined #bitcoin-dev
1199 2016-01-06T23:36:41 *** _W_ has joined #bitcoin-dev
1200 2016-01-06T23:36:43 *** rusty has joined #bitcoin-dev
1201 2016-01-06T23:36:56 *** droid has joined #bitcoin-dev
1202 2016-01-06T23:37:53 *** droid has quit IRC
1203 2016-01-06T23:39:49 *** lsrp has joined #bitcoin-dev
1204 2016-01-06T23:42:30 *** antimattero has quit IRC
1205 2016-01-06T23:44:00 *** patcon has joined #bitcoin-dev
1206 2016-01-06T23:46:24 *** gielbier has quit IRC
1207 2016-01-06T23:50:29 *** patcon has quit IRC
1208 2016-01-06T23:52:35 *** Belxjander has quit IRC
1209 2016-01-06T23:53:40 *** stevenroose|BNC has joined #bitcoin-dev
1210 2016-01-06T23:55:11 *** Belxjander has joined #bitcoin-dev
1211 2016-01-06T23:56:22 *** stevenroose has joined #bitcoin-dev
1212 2016-01-06T23:57:41 <stevenroose> does solo mining with bitcoind support longpolling?
1213 2016-01-06T23:59:24 *** lsrp has quit IRC