1 2014-03-31 00:00:52 <Genitrust> nevermidn it's working now... i removed blocks/ and chainstate/ directory
2 2014-03-31 00:02:36 <Genitrust> hmm, size of the blocks directory gets up to 23MB ... and then it stops growing...
3 2014-03-31 00:02:47 <Genitrust> (my bootstrap.dat is about 16GB maybe?)
4 2014-03-31 00:09:42 <sipa> Genitrust: then perhaps the data in your bootstrap is corrupted as well
5 2014-03-31 00:11:23 <Genitrust> bitcoind ... does this actually download the blockchain ?
6 2014-03-31 00:13:22 <Genitrust> so i started Armory... and now blocks/ size jumped to 27 MB o.O
7 2014-03-31 00:14:25 <sipa> Genitrust: yes it will automatically download
8 2014-03-31 00:14:43 <sipa> Genitrust: it's the reference client that pretty much runs the network
9 2014-03-31 00:15:01 <sipa> Genitrust: it will first try to process your entire bootstrap.dat though
10 2014-03-31 00:15:16 <sipa> and if one block in it corrupted, everything after it will fail
11 2014-03-31 00:17:08 <Genitrust> ahh i understand
12 2014-03-31 00:17:09 <Genitrust> thanks sipa !
13 2014-03-31 04:07:16 <todamoon> hola
14 2014-03-31 04:09:45 <todamoon> anyone knows why the target (bits field) is included in the block header?
15 2014-03-31 04:11:08 <Luke-Jr> todamoon: SPV nodes
16 2014-03-31 04:11:42 <wumpus> IIRC it allows for fast rejection of blocks with the wrong difficulty
17 2014-03-31 04:12:08 <todamoon> ok
18 2014-03-31 04:12:28 <todamoon> makes sense
19 2014-03-31 04:12:50 <Luke-Jr> wumpus: eh, not really..
20 2014-03-31 04:15:36 <todamoon> Luke-Jr: how does having the target in the header help with SPV?
21 2014-03-31 04:16:03 <Luke-Jr> todamoon: it immediately knows the difficulty without downloading all the history
22 2014-03-31 04:16:20 <wumpus> Luke-Jr: ok I remember reading it was used for that, I'm not trying to argue
23 2014-03-31 04:17:10 <todamoon> Luke-Jr: why do they need to know the difficulty? aren't they just suppose to accept the chain with highest PoW?
24 2014-03-31 04:18:28 <mr_burdell> highest height... I guess it could detect a fake difficulty based on previous difficulty values
25 2014-03-31 04:19:16 <mr_burdell> if I send an SPV node a new chain with greater height, but all my blocks have difficulty of 1, it could tell that it's fake
26 2014-03-31 04:19:32 <Luke-Jr> todamoon: you don't know the highest work without difficulty
27 2014-03-31 04:20:06 <todamoon> what I'm wondering is why is it part of the header if it needs to be computed by clients anyways
28 2014-03-31 04:20:23 <Luke-Jr> SPV clients don't need to compute it
29 2014-03-31 04:20:28 <Luke-Jr> you need all the past block headers to compute it
30 2014-03-31 04:20:43 <mr_burdell> don't SPV nodes download the headers though?
31 2014-03-31 04:20:49 <todamoon> right
32 2014-03-31 04:21:04 <Luke-Jr> on a limb: you aren't under the impression that the actual block header hash value is used itself for something, are you?
33 2014-03-31 04:21:19 <Luke-Jr> mr_burdell: they can, but don't need to necessarily
34 2014-03-31 04:26:48 <todamoon> it's not clear to me why SPV nodes need to know the difficulty or should trust it when they see it. it seems it'd be safer for them to just accept the chain with the most PoW (this could probably be determined by computing the average of all header hashes and choosing the chain with lowest average)
35 2014-03-31 04:28:37 <kadoban> Currently, non-push opcodes in transactions don't invalidate the transaction, right? Only in P2SH transactions, and BIP62 eventually?
36 2014-03-31 04:28:41 <kadoban> in the scriptSig I mean
37 2014-03-31 04:29:25 <Luke-Jr> kadoban: depends on the opcode
38 2014-03-31 04:29:52 <kadoban> Right, but they're not invaliding on their face just by being non-push, right?
39 2014-03-31 04:33:49 <wumpus> non-push opcodes in the input script make the transaction non-standard, but they don't 'invalidate' the transaction
40 2014-03-31 04:34:31 <kadoban> Okay, thanks. But in P2SH they do, correct?
41 2014-03-31 04:35:25 <wumpus> in P2SH the outer script still contains only push opcodes, but an validation script is pushed to the stack and that can contain non-push opcodes
42 2014-03-31 05:06:17 <saizai> FYI: Iâm going to be talking to the FEC this Thursday re. AO 2014-02, my PACâs Bitcoin AOR.
43 2014-03-31 05:34:55 <todamoon> is the original source code released by satoshi available for download somewhere?
44 2014-03-31 05:35:53 <todamoon> seems the git repo only goes back to 2011
45 2014-03-31 05:38:27 <Ghaleon> Locked down ubuntu so tight⦠i locked myself outâ¦
46 2014-03-31 06:00:22 <devrandom> ouch
47 2014-03-31 06:02:18 <Ghaleon> installed like 3 rootkit checks, port scanners, security auditor like tiger
48 2014-03-31 06:02:27 <Ghaleon> mod security with owasp defs
49 2014-03-31 06:02:31 <Ghaleon> mid evasive
50 2014-03-31 06:02:41 <Ghaleon> so much stuff, changed ports. fire walls
51 2014-03-31 06:02:59 <Ghaleon> fail2ban deny hosts
52 2014-03-31 06:03:02 <Ghaleon> the workz
53 2014-03-31 06:03:22 <Ghaleon> lol⦠now the btc is untouchable
54 2014-03-31 06:06:07 <Ghaleon> not really the best use of time.. as 90% of vulnerabilities are in the web code itself⦠in my experience
55 2014-03-31 06:06:27 <wumpus> please take this somewhere else, this is not bitcoin development discussion
56 2014-03-31 06:06:47 <Ghaleon> k
57 2014-03-31 07:08:41 <Genitrust> so just curious, why use a bootstrap.dat when you can just copy over the blocks/ and chainstate/ directories?
58 2014-03-31 07:14:16 <gmaxwell> Genitrust: because they are not reliably portable between systems and because they could contain incorrect data which could be used to attack you and/or the network.
59 2014-03-31 07:14:50 <gmaxwell> (also, this question belongs in #bitcoinâ but you asked here first so I saw it here first)
60 2014-03-31 07:15:56 <Genitrust> gmaxwell, thanks :)
61 2014-03-31 07:16:32 <Genitrust> I agree. so basically, the file structure/format or databases aren't compatible between each platform?
62 2014-03-31 07:16:51 <Genitrust> I am asking for the sake of installing this onto other employee's workstations
63 2014-03-31 07:17:33 <Genitrust> (btw, my question rephrases what you said because i'm just curious if by "systems" you are referring to the operating system platforms themselves...)
64 2014-03-31 07:18:54 <wumpus> right, the leveldb databases are somehow not compatible between OSes/CPU architectures
65 2014-03-31 07:19:07 <Genitrust> oooh, darn
66 2014-03-31 07:19:17 <Genitrust> even between unix/linux OSes? :(
67 2014-03-31 07:19:22 <wumpus> it's not entirely clear why, so if you feel like debugging it, be my guest
68 2014-03-31 08:19:49 <sipa> gmaxwell, Genitrust: copying bootstrap also means validsating it; if you copy a preprocessed database, you risk importing a state that makes your node think your attacker has more money than he does (and this is very hard to detect)
69 2014-03-31 08:20:12 <sipa> Genitrust: in general, the trust requirements foe bootstrap are much lower
70 2014-03-31 08:34:03 <Genitrust> sipa thanks....good answer :)
71 2014-03-31 11:10:30 <aschildbach_> I just tried running my bitcoind 0.9.0 node using disablewallet=1. Is it just me or is it replaying the blockchain much quicker? It seems to do ~10 bps while it used to scan at ~1 bps before. (It's a slow Atom processor.)
72 2014-03-31 11:41:02 <wumpus> could be, the time that a 'rescan' normally takes is expected to be subtracted from the full indexing time
73 2014-03-31 11:50:49 <warren> aschildbach_: wallet.dat keeps track of the last block it scanned
74 2014-03-31 11:51:05 <warren> aschildbach_: you can witness the same behavior by swapping out wallet.dat
75 2014-03-31 13:45:47 <Alina-malina> is it possible to tune the address like so for example if sender needs to send for example 10 btc with that address bitcoin autmatically keep fee of 1BTC and send to another wallet and continue storing that btc of 9 to destination?
76 2014-03-31 14:14:48 <viajero> !seen gmaxwell
77 2014-03-31 14:14:49 <gribble> gmaxwell was last seen in #bitcoin-dev 7 hours and 0 seconds ago: <gmaxwell> (also, this question belongs in #bitcoinâ but you asked here first so I saw it here first)
78 2014-03-31 14:26:27 <christophe> Alina-malina: No, but the payment protocol lets you specify outputs however you want. So a payment request could contain two outputs. If you're building a payment service, that's what you should be using.
79 2014-03-31 15:45:32 <Joric> hi all, gmaxwell
80 2014-03-31 15:48:14 <Alina-malina> someone please unban me from bitcoin channel.
81 2014-03-31 15:50:43 <Alina-malina> iwilcox, please unban me
82 2014-03-31 15:54:33 <andytoshi> for those curious, Alina-malina has been persistently trolling bitcoin for a few days, asking incoherent questions, ignoring advice and answers, and insulting those who tried to help
83 2014-03-31 15:54:48 <Alina-malina> andytoshi, proof it?
84 2014-03-31 15:55:05 <paveljanik> I have seen it...
85 2014-03-31 15:55:32 <Alina-malina> andytoshi, you are not helping you are yelling on me
86 2014-03-31 15:55:40 <edcba> anyway bitcoin is not bitcoin-dev asking unban in another channel is not a good idea
87 2014-03-31 15:57:22 <Alina-malina> andytoshi, allright unban me
88 2014-03-31 15:57:48 <andytoshi> Alina-malina: (a) no, (b) plonk, (c) this is OT for #bitcoin-dev, this is a logged development channel
89 2014-03-31 15:58:21 <Alina-malina> andytoshi, i bet if i was man you would not be so corage, shame on you
90 2014-03-31 16:04:36 <maaku> Alina-malina: attitude like that will get you banned here as well. this is off-topic, take it somewhere else
91 2014-03-31 16:05:12 <Alina-malina> maaku, how to unban?
92 2014-03-31 16:05:21 <maaku> Alina-malina: not here
93 2014-03-31 16:05:26 <Alina-malina> where?
94 2014-03-31 16:05:34 <maaku> i don't know and i don't care
95 2014-03-31 16:08:41 <Ry4an> this channel and that channel are unrelated. Coming in here to ask to be unbanned there is like going into a one bar and asking to be unbanned in another bar that happens to have some patron overlap. It will only confuse and annoy the people in the bar where you're not (yet) banned.
96 2014-03-31 16:15:25 <Alina-malina> Ry4an, so?
97 2014-03-31 16:16:04 <Alina-malina> eh
98 2014-03-31 16:16:40 <stonecoldpat> Its best just to ignore and just have the discussion thats supposed to be here
99 2014-03-31 16:59:23 <mappum> what are the differences between values of -checklevel on bitcoind?
100 2014-03-31 18:13:27 <hearn> hmm wow. the biteasy.com explorer got REALLY responsive
101 2014-03-31 18:18:21 <roasbeef> responsive in terms of design? Or user perceived latency in the web app?
102 2014-03-31 18:20:31 <roasbeef> :o nvm it's lightning fast now
103 2014-03-31 19:11:50 <gmaxwell> I'm skeptical about deploying a committed address ordered utxo... as it adds a considerable cost to verifying nodes, with the benefit of incentivizing address reuse. :P
104 2014-03-31 19:12:59 <hearn> well, iâll be damned. the dogecoin guys are actually implementing useful features in their wallets that bitcoin wallets donât have
105 2014-03-31 19:13:00 <hearn> https://www.youtube.com/watch?v=6ZKTunML8kI
106 2014-03-31 19:13:07 <hearn> hopefully it can be easily merged back into the bitcoin android app
107 2014-03-31 19:15:42 <sipa> hearn: relying on a central server :(
108 2014-03-31 19:16:01 <sipa> (no other way to do it right now, of course)
109 2014-03-31 19:16:04 <hearn> sure
110 2014-03-31 19:16:10 <hearn> iâll take that for now over the feature not existing at all
111 2014-03-31 19:23:30 <ad949kf> why does private key sweeping rely on a central server?
112 2014-03-31 19:24:03 <ad949kf> having looked at the dogecoin wallet code I think it could be merged back pretty easily
113 2014-03-31 19:24:16 <ad949kf> for some reason they are sticking to an obsolete version of android though
114 2014-03-31 19:24:43 <sipa> ad949kf: you need to find transactions affecting that address
115 2014-03-31 19:25:01 <sipa> ad949kf: and doing a full rescan of history ever would put massive load on the server you're asking it from
116 2014-03-31 19:25:10 <sipa> if it's likely just for a single transaction
117 2014-03-31 19:25:12 <ad949kf> go on
118 2014-03-31 19:25:32 <sipa> imho, such single-use "sweep code" keys should include the txid crediting it
119 2014-03-31 19:25:45 <sipa> so you can construct a sweep without even accessing the blockchain
120 2014-03-31 19:26:02 <hearn> yeah but that ship sailed â¦..
121 2014-03-31 19:26:30 <sipa> unfortunately
122 2014-03-31 19:26:43 <ad949kf> how is the blockchain.info app able to sweep private keys
123 2014-03-31 19:26:58 <sipa> i've suggested it to mike caldwell before, but he didn't like how much extra space it would require in his coins
124 2014-03-31 19:27:00 <hearn> it has a full db of the entire block chain
125 2014-03-31 19:27:04 <sipa> ad949kf: with a big-ass index
126 2014-03-31 19:27:17 <hearn> ideally these qrcodes would be URLs to files containing the needed data
127 2014-03-31 19:27:21 <hearn> but the self-contained nature is appealing ..
128 2014-03-31 19:27:29 <gmaxwell> hearn: a sweep code could be added.. and then you could skip the server it has one.
129 2014-03-31 19:41:57 <hemry> hey
130 2014-03-31 19:42:03 <hemry> anyone using kraken api?
131 2014-03-31 19:42:56 <hemry> what's the deal with gaps on OHLC or Trades API?
132 2014-03-31 19:43:36 <ad949kf> huge spread?
133 2014-03-31 19:44:27 <hemry> no, I mean data is missing entirely
134 2014-03-31 19:44:36 <hemry> and those gaps can be as large as few hours
135 2014-03-31 19:44:51 <hemry> and they happen too often to assume kraken was down at that time
136 2014-03-31 19:45:22 <hemry> also data is missing across all API methods. If its missing on OHLC it is also missing on trades and so on
137 2014-03-31 19:45:51 <hemry> shows up on a chart on their page, thought
138 2014-03-31 19:48:18 <daybyter> what language are you using, hemry?
139 2014-03-31 19:49:58 <hemry> daybyter: Java, but I don't see how that is important... you can see the gaps using browser..
140 2014-03-31 19:50:16 <daybyter> that was not my reason for asking.
141 2014-03-31 19:50:24 <daybyter> I'm using java, too.
142 2014-03-31 19:50:44 <daybyter> and my tradelib lacks a kraken implementation.
143 2014-03-31 19:50:56 <daybyter> maybe we could collaborate.
144 2014-03-31 19:51:10 <daybyter> that was my interest.
145 2014-03-31 19:51:42 <hemry> daybyter: check this out https://github.com/timmolter/XChange
146 2014-03-31 19:52:30 <daybyter> https://github.com/ReAzem/cryptocoin-tradelib
147 2014-03-31 19:53:56 <hemry> well I guess you'll have the same problem eventually
148 2014-03-31 19:54:24 <daybyter> I'm not far enough, I guess...
149 2014-03-31 20:29:44 <Anduck> is there any developing going on about removing the limits of bitcoin network? like the 7tx/sec
150 2014-03-31 20:30:08 <Luke-Jr> Anduck: yes
151 2014-03-31 20:30:26 <Anduck> how's it going? what has been developed?
152 2014-03-31 20:31:49 <Anduck> or is there any link i can read about that
153 2014-03-31 20:34:48 <Ademan> where does the 7tx/sec limitation come from anyways? Block size?
154 2014-03-31 20:35:11 <Anduck> it's just a fixed limit to make blocks not too big
155 2014-03-31 20:39:18 <ad949kf> what happened to blockchain pruning too
156 2014-03-31 21:15:45 <michagogo> cloud|Ademan: yes, block size
157 2014-03-31 21:18:22 <Ademan> michagogo|cloud: I assume that if block size ever becomes prohibitive, that the maximum will just be raised?
158 2014-03-31 21:18:33 <michagogo> cloud|Ademan: well, it's a hardfork
159 2014-03-31 21:20:21 <Ademan> what are the alternatives? I suppose halving the block time, but that would also require a hard fork (and for whatever reason, the admittedly arbitrary 10min block time seems to be gospel, so nobody would go for that)
160 2014-03-31 21:21:06 <Ademan> actually I don't know what validation regular nodes do regarding block time, maybe that only requires miners to play along?
161 2014-03-31 21:21:14 <irvingprime> There has been some talk about using smart transaction fees to influence block size. Transactions paying little or nothing in fees would then wait longer, I expect.
162 2014-03-31 21:21:22 <gmaxwell> Ademan: there is basically nothing in bitcoin that requires only miners to play along.
163 2014-03-31 21:21:57 <gmaxwell> irvingprime: miners already prioritize transactions based on fees per byte. The missing part there is just wallets being smarter on what fees they use.
164 2014-03-31 21:22:46 <Ademan> irvingprime: letting tx fees influence block size seems kind of dangerous, a malicious miner could inflate their blocks with untransmitted transactions which have high fees
165 2014-03-31 21:23:29 <Ademan> I'm not sure how dangerous miners sending out large blocks is though, I always assumed that was the reason for the block size limit thoughg
166 2014-03-31 21:26:01 <gmaxwell> Ademan: there is a scaling / decenteralization tradeoff in a global network.
167 2014-03-31 21:28:10 <gmaxwell> Ademan: e.g. imagine if blocks were a gigabyte each, and you had to have gigabits of connectivity to keep up with the chain... there would be huge centeralization gains, and perhaps only some big corporate data centers could validate... if they wanted to inflate, perhaps they could. Thats a insane extreme example, but just to illustrate the point. On the other end of the spectrum if blocks are too tiny then while everyon can validate and ...
168 2014-03-31 21:28:13 <Ademan> gmaxwell: are you saying the block size limit improves the decentralization of the network? If so I'm not sure I understand how, unless it has to do with propagation rate
169 2014-03-31 21:28:17 <gmaxwell> ... the security is good, few can transact.
170 2014-03-31 21:28:27 <Ademan> you can disregard that until I finish reading what you just wrote
171 2014-03-31 21:28:41 <gmaxwell> There are a number of ways to address this conflict, obviously just striking a good balance is one way.
172 2014-03-31 21:29:49 <blockQ> hey, is anyone around that's familiar with Blockchain.info API?
173 2014-03-31 21:29:50 <Burrito> There's also the factor of changing hardware/bandwidth specs to consider. The rate of growth of the network vs the rate of improvement in the hardware that (can) run it.
174 2014-03-31 21:30:09 <Ademan> ah that makes sense, so it's actually more that (blocksize / time) which affects centralization.
175 2014-03-31 21:30:21 <sipa> Ademan: time?
176 2014-03-31 21:30:38 <sipa> right, it's transactions/second itself that is the scalability problem
177 2014-03-31 21:30:45 <sipa> the size of blocks is only the result of that
178 2014-03-31 21:30:58 <sipa> (though very frequent blocks has other negative side effects)
179 2014-03-31 21:31:11 <Luke-Jr> Ademan: alternatives: there could be multiple "side chains" for daily use which get recycled regularly, and payments occur on at across 2 of those depending on which the payer/recipient use
180 2014-03-31 21:31:34 <blockQ> Luke-JR do you ever use the Blockchain.info RPC API?
181 2014-03-31 21:31:42 <Luke-Jr> gmaxwell: sipa: did anyone ever discuss pegging which can handle side-chain to side-chain transfers?
182 2014-03-31 21:31:49 <Luke-Jr> blockQ: no, and I wouldn't recommend it
183 2014-03-31 21:32:02 <blockQ> Luke-Jr : ah, thanks anyways
184 2014-03-31 21:32:17 <Ademan> sipa: I read something claiming that orphan rates, while obviously inversely proportional to block time, don't increase linearly (5 minute block times do not produce 2x orphans of a 10 minute block time)
185 2014-03-31 21:33:16 <sipa> Ademan: then they're not inversely proportional
186 2014-03-31 21:33:29 <sipa> (and indeed, that seems likely based on theory, though i don't have numbers)
187 2014-03-31 21:34:14 <gmaxwell> Ademan: it's very clearly not linear.
188 2014-03-31 21:34:40 <Ademan> sipa: maybe I'm mistaken, but given X and Y, if increasing X decreases Y, I call that inversely proportional (whether or not the relationship is linear, quadratic, exponential or whatever)
189 2014-03-31 21:35:05 <kazcw> Ademan: that's negatively correlated; inversely proportional is more specific
190 2014-03-31 21:35:06 <sipa> Ademan: no, that's just negatively correlated
191 2014-03-31 21:35:13 <gribble> Error: "hi5" is not a valid command.
192 2014-03-31 21:35:13 <sipa> !hi5 kazcw
193 2014-03-31 21:35:41 <Ademan> hrm, I guess my life is a lie
194 2014-03-31 21:35:55 <sipa> It's true-- you *were* adopted.
195 2014-03-31 21:36:44 <sipa> in theory, at least, it should be proportional to the CDF of an exponential distribution
196 2014-03-31 21:37:00 <sipa> assuming every node is at constant distance in the network to every other
197 2014-03-31 21:37:13 <sipa> (spherical cows, etc)
198 2014-03-31 21:37:31 <Ademan> of uniform density I assume
199 2014-03-31 21:37:39 <gmaxwell> and a universe that runs forever.
200 2014-03-31 21:39:18 <gmaxwell> e.g. it's easy to setup an imaginary cases where the behavior is very ugly. Say a network of two nodes, of precisely equal hashrate, which produce 1 block per nanosecond, spaced 1 light minute apart...
201 2014-03-31 21:39:48 <uiop> how many lightminutes away is the moon?
202 2014-03-31 21:39:58 <uiop> ACTION knows sun is about 8
203 2014-03-31 21:40:46 <sipa> 384k km
204 2014-03-31 21:40:50 <sipa> so about 1s
205 2014-03-31 21:41:14 <uiop> how convenient!
206 2014-03-31 21:41:30 <uiop> oh
207 2014-03-31 21:41:37 <uiop> s/oh//
208 2014-03-31 21:41:45 <gmaxwell> 2s for the round trip, if you google EME you can listen to recordings of ham operators communicating via moon bounce.
209 2014-03-31 21:42:08 <uiop> oh, nm. i misread minutes and seconds. moon is 1 *second*, sun is 8 *minutes*..
210 2014-03-31 21:42:18 <uiop> ACTION is disoriented, ignore him
211 2014-03-31 21:42:25 <sipa> so say you have 1% stale blocks given a certain block interval
212 2014-03-31 21:42:36 <uiop> gmaxwell: hah, i might have to add that to my to-google list
213 2014-03-31 21:42:57 <sipa> so say you have 1% stale blocks given a certain block interval, then you'd have 1.99% stale blocks with half that interval
214 2014-03-31 21:43:10 <sipa> (given same spherical cow network)
215 2014-03-31 21:43:30 <sipa> 9.5% with 1/10th of the interval
216 2014-03-31 21:44:15 <jcorgan> gmaxwell: interesting history to EME, it was borne out of trying to listen on cold-war enemies radio transmissions via moon reflection, nobody believed it was possible, until they tried it
217 2014-03-31 21:45:44 <gmaxwell> I have a set of books "A History of Engineering and Science in the Bell System" which are absolutely fasciating, one of the volumes deals mostly with radar and over-the-horizon-radar and such.
218 2014-03-31 21:46:04 <sipa> bell system?
219 2014-03-31 21:46:04 <uiop> the speed of light is such a inconvenience. e.g. satellite internet + anything interactive
220 2014-03-31 21:46:30 <gmaxwell> sipa: the US's now-dismantled quasi-monopoly telephone company.
221 2014-03-31 21:47:08 <sipa> ah, right
222 2014-03-31 21:47:20 <sipa> bell labs