1 2014-09-16 01:20:01 <dgenr8> I myself prefer unary. happy 111111111111111 September, don't ask what year.
2 2014-09-16 01:23:17 <skinnkavaj> http://two-bit-idiot.tumblr.com/post/97258629244/adept-ibm-samsung-bitcoin
3 2014-09-16 02:15:56 <jgarzik> Random:
4 2014-09-16 02:16:12 <jgarzik> sipa, I say go ahead and clang-format a few infrequently-touched files
5 2014-09-16 02:16:21 <jgarzik> have some examples in tree
6 2014-09-16 02:16:44 <sipa> jgarzik: was planning to do that indeed
7 2014-09-16 02:17:09 <Luke-Jr> Is there any undefined behaviour in this? ~((1 << ((bytesleft ? bytesleft : 4) * 8)) - 1)
8 2014-09-16 02:17:20 <Luke-Jr> GCC and LLVM are giving me opposite results :|
9 2014-09-16 02:23:29 <phantomcircuit> so
10 2014-09-16 02:23:51 <sipa> stackoverflow?
11 2014-09-16 02:24:10 <phantomcircuit> wallet with 630k outputs/590k spendable outputs
12 2014-09-16 02:24:36 <phantomcircuit> sendmany with 1k addresses and randomly sized outputs takes ~60 seconds to generate
13 2014-09-16 02:25:33 <phantomcircuit> afaict the only issue with huge wallets is load time and certain rpc calls timing out
14 2014-09-16 02:25:40 <phantomcircuit> (listunspent being the prime example)
15 2014-09-16 02:27:10 <sipa> doesn't seem unreasonable
16 2014-09-16 02:27:38 <phantomcircuit> sipa, nope seems entirely reasonable actually
17 2014-09-16 02:27:47 <phantomcircuit> im going to test some more of the rpc calls
18 2014-09-16 02:27:57 <phantomcircuit> oh well actually
19 2014-09-16 02:28:05 <phantomcircuit> 60 seconds is long enough that the rpc call times out
20 2014-09-16 02:28:09 <phantomcircuit> which is a problem
21 2014-09-16 02:29:38 <x48> does anyone know a good source of aggregate historical exchange data?
22 2014-09-16 02:30:01 <phantomcircuit> offtopic
23 2014-09-16 02:30:30 <x48> for #bitcoin then?
24 2014-09-16 02:46:07 <jgarzik> Luke-Jr, what is the type of 'bytesleft'?
25 2014-09-16 02:46:33 <jgarzik> Luke-Jr, '1' is subject to implicit type conversion
26 2014-09-16 03:17:14 <Luke-Jr> jgarzik: uint8_t
27 2014-09-16 03:29:27 <jgarzik> Luke-Jr, ...and possible range of bytesleft values?
28 2014-09-16 03:31:55 <Luke-Jr> 0 1 2 3
29 2014-09-16 03:35:08 <jgarzik> Luke-Jr, you might shift an 'int' 32 bits before doing other stuff
30 2014-09-16 03:35:52 <Luke-Jr> well, I replaced it with bytesleft ? (0xffffffff << (bytesleft * 8)) : 0 which works, but it was curious that LLVM did weird stuff with the previous expression
31 2014-09-16 03:36:15 <jgarzik> Luke-Jr, not curious
32 2014-09-16 03:36:26 <jgarzik> Luke-Jr, undefined behavior
33 2014-09-16 03:36:43 <Luke-Jr> the '1' type?
34 2014-09-16 03:37:05 <jgarzik> Luke-Jr, 1 is an int
35 2014-09-16 03:37:08 <jgarzik> Luke-Jr, 32 bits
36 2014-09-16 03:37:25 <jgarzik> Luke-Jr, what happens when you shift 0x00000001 32 bits left?
37 2014-09-16 03:38:01 <Luke-Jr> 0
38 2014-09-16 03:38:07 <gwillen> you morally should get 0
39 2014-09-16 03:38:10 <gwillen> but in C you get undefined
40 2014-09-16 03:38:13 <gwillen> because C hates you
41 2014-09-16 03:38:16 <Luke-Jr> *8 = 0; - 1 = -1; ~ = 0
42 2014-09-16 03:38:20 <jrick> it's signed
43 2014-09-16 03:38:36 <Luke-Jr> gwillen: shifting a 32-bit value 32 bits is undefined?
44 2014-09-16 03:38:39 <gwillen> correct
45 2014-09-16 03:38:52 <gwillen> see e.g. http://stackoverflow.com/questions/2648764/whats-bad-about-shifting-a-32-bit-variable-32-bits
46 2014-09-16 03:38:56 <jgarzik> in addition... it's an int
47 2014-09-16 03:38:57 <jgarzik> signed
48 2014-09-16 03:39:16 <Luke-Jr> I thought you could shift the full width, and beyond that was undefined. my bad
49 2014-09-16 03:39:19 <gmaxwell> you're not allowed to shift a 1 into the 'sign position' in a signed number, nor are you ever allowed to shift beyond the size of the type. It's undefined, and the compiler is permitted to end the universe as a result.
50 2014-09-16 03:39:28 <Luke-Jr> bleh
51 2014-09-16 03:40:22 <gmaxwell> Luke-Jr: well written C code should work on a ones compliment machine, if that makes it seem any more sensible to you.
52 2014-09-16 03:42:47 <Luke-Jr> 0xffffffff is guaranteed to be a >=32-bit-actual type, right? >_<
53 2014-09-16 03:46:36 <earlz> So, could anyone in here help me with gitian?
54 2014-09-16 03:52:55 <jgarzik> Luke-Jr, if you are ever worried, just explicitly type
55 2014-09-16 03:53:11 <jgarzik> Luke-Jr, 0xffffffffU (unsigned int), 0xffffffffULL (unsigned long long) etc.
56 2014-09-16 03:53:46 <jgarzik> Luke-Jr, e.g. you can use "1ULL << ..."
57 2014-09-16 03:56:11 <fanquake> earlz What the question?
58 2014-09-16 03:58:18 <earlz> fanquake: havign trouble using bin/make-base-vm
59 2014-09-16 03:58:20 <earlz> er
60 2014-09-16 03:58:41 <earlz> make-clean-vm
61 2014-09-16 03:58:58 <earlz> I just get this back from it lxc-execute: No such file or directory - failed to exec /usr/lib/x86_64-linux-gnu/lxc/lxc-init
62 2014-09-16 03:59:12 <earlz> I can get into the LXC VM though
63 2014-09-16 04:00:09 <fanquake> Thatâll be due to recent changes to gitian-builder, see https://github.com/devrandom/gitian-builder/blob/master/RELEASE_NOTES
64 2014-09-16 04:03:38 <earlz> wtf
65 2014-09-16 04:04:13 <earlz> and making a new VM doesn't automatically install it? that seems stupid
66 2014-09-16 04:06:59 <fanquake> I had the same issue this morning, didnât dig much into it. If your gitian setup was already working, you could just checkout the gitian-builder source to the commit previous to the lxc execute merge.
67 2014-09-16 04:08:33 <earlz> it wasn't already working
68 2014-09-16 04:08:45 <earlz> I tried going back a few commits and now I get more mystic errors
69 2014-09-16 04:08:54 <earlz> stdin: is not a tty
70 2014-09-16 04:08:54 <earlz> sudo: unable to resolve host debian
71 2014-09-16 04:09:01 <Luke-Jr> jgarzik: ah, didn't know ULL and such worked on hex
72 2014-09-16 04:09:12 <Luke-Jr> ACTION <.< at his syntax highlighter
73 2014-09-16 04:09:50 <fanquake> earlz best bet is to re-read the gitan guide and/or google.
74 2014-09-16 04:10:35 <earlz> I've been trying everything I can think of
75 2014-09-16 04:10:48 <earlz> I'm following this guide exactly https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
76 2014-09-16 05:06:56 <Luke-Jr> grr clang⦠http://dpaste.com/2K5M0MB
77 2014-09-16 05:18:09 <paveljanik> what is wrong with that? ;-)
78 2014-09-16 05:18:26 <paveljanik> I miss colors 8)
79 2014-09-16 05:18:56 <Luke-Jr> paveljanik: seems the only safe, standard-compatible way to convert from int to size_t while detecting an overflow (ie, int is wider than size_t) is to cast it to uintmax_t :x
80 2014-09-16 05:24:56 <paveljanik> this is not tautological warning anyway. It is arch. specific.
81 2014-09-16 05:25:48 <phantomcircuit> Luke-Jr, SIZE_MAX is for int
82 2014-09-16 05:25:56 <Luke-Jr> phantomcircuit: ?
83 2014-09-16 05:26:05 <phantomcircuit> but yeah that warning is wrong
84 2014-09-16 05:26:15 <Luke-Jr> paveljanik: yes, but I'm trying to get Travis to check my software with -Wall -Werror :p
85 2014-09-16 06:51:34 <warren> REJECT_INVALID, "bad-diffbits");
86 2014-09-16 06:51:34 <warren> return state.DoS(100, error("CheckBlockHeader() : block with too little proof-of-work"),
87 2014-09-16 06:51:56 <warren> master branch ... bad peers from some other network are triggering this error but they aren't being disconnected
88 2014-09-16 07:16:28 <pandamonieum> are the nodes connected in the regtest network actually mining anything? or are blocks generated only using the setgenerate command?
89 2014-09-16 07:36:39 <warren> Oh... I see it isn't a bug.
90 2014-09-16 07:49:26 <warren> OK, I'm curious why the peer is not disconnected in that case...
91 2014-09-16 07:52:38 <Luke-Jr> warren: git log tends to be insightful in general
92 2014-09-16 08:15:20 <warren> Anyone have the older signed alert messages saved anywhere? I am testing changes pertaining to alert relaying.
93 2014-09-16 08:16:41 <wumpus> warren: src/test/alert_tests has a few, also if you want to generate your own alert key for testing see https://github.com/bitcoin/bitcoin/pull/4883
94 2014-09-16 08:25:50 <warren> wumpus: https://github.com/wtogami/bitcoin/commit/f137e32f90504be24aaa9a06ec0f7f28c61a2e12 does this look reasonable? I am thinking to additionally add an option to set the MIN_PEER_PROTO_VERSION at startup instead of hard-coded.
95 2014-09-16 08:27:25 <wumpus> warren: looks fine to me; the only potential problem I see is if the alert protocol changes in an incompatible way
96 2014-09-16 08:27:37 <wumpus> warren: why would you add an option for that?!
97 2014-09-16 08:27:46 <wumpus> MIN_PEER_PROTO_VERSION is for hard incompatibilities only
98 2014-09-16 08:28:41 <wumpus> it's not something a user (that doesn't change the protocol code) has any business changing
99 2014-09-16 08:28:59 <warren> If the user wants to discourage the use of obsolete client versions
100 2014-09-16 08:29:12 <warren> It is also helpful in reducing log spam
101 2014-09-16 08:29:30 <warren> (lots of poorly coded alt coins)
102 2014-09-16 08:29:37 <wumpus> it is not meant to 'discourage the use of obsolete client versions', any programs that talk a valid protocol should be accepted on the network IMO
103 2014-09-16 08:29:47 <wumpus> there is more than just bitcoin core :)
104 2014-09-16 08:29:49 <warren> hence it is an option
105 2014-09-16 08:30:17 <warren> regarding "the only potential problem I see is if the alert protocol changes in an incompatible way" isn't that already a problem now?
106 2014-09-16 08:30:48 <wumpus> warren: well that was only a minor remark as I see the chances of the alert protocol changing as very slim
107 2014-09-16 08:31:20 <warren> will it be a problem on the receiving end to receive an alert message prior to the version negotiation?
108 2014-09-16 08:31:32 <wumpus> only if the format of the alert messages changed
109 2014-09-16 08:31:40 <wumpus> which, as I said, isn't really likely
110 2014-09-16 08:32:17 <warren> OK, I'll submit just this patch for now.
111 2014-09-16 08:33:18 <wumpus> but the protocol versioning is there to avoid problems with clients that just cannot communicate anymore with recent clients... it's not meant as an arbitrary option to discourage old clients, or something like that...also remember: protocol versions and client versions are disconnected
112 2014-09-16 08:33:58 <warren> as you said, there's more than Bitcoin Core
113 2014-09-16 08:34:12 <wumpus> yes
114 2014-09-16 08:34:15 <warren> I personally find it useful to bump up the MIN_PEER_PROTO_VERSION on my nodes as it reduces log spam
115 2014-09-16 08:35:25 <wumpus> toning down the amount of unecessary logging in those cases seems a better solution
116 2014-09-16 08:36:23 <warren> I rather not talk to bogus peers at all, I want that to be a personal choice.
117 2014-09-16 08:36:25 <wumpus> if it is known that a certain old version creates a lot of spammy log messages, then there's something wrong with logging, as logging is about unexpected things
118 2014-09-16 08:36:39 <wumpus> ok, keep it a personal patch then
119 2014-09-16 08:36:52 <warren> well, nothing wrong with this above patch is there?
120 2014-09-16 08:36:59 <Luke-Jr> ACTION bumps 0.5.x branch to claim to be the latest proto version
121 2014-09-16 08:37:18 <warren> Luke-Jr: you'll confuse bitcoinj =)
122 2014-09-16 08:37:19 <wumpus> not that I'm aware of - I was talking about the option
123 2014-09-16 08:37:32 <Luke-Jr> warren: good, maybe hearn can fix the bugs revealed
124 2014-09-16 08:37:53 <warren> I don't think he wants to fix the bugs like "relies entirely on DNS seeds"
125 2014-09-16 08:38:19 <Luke-Jr> warren: am I supposed to be concerned with this? :p
126 2014-09-16 11:22:11 <warren> wumpus: BTW, why does "ERROR: ProcessBlock() : block with too little proof-of-work" not disconnect the peer?
127 2014-09-16 11:22:23 <warren> was this a conscious decision?
128 2014-09-16 11:23:02 <wumpus> warren: I don't know
129 2014-09-16 11:23:25 <wumpus> does it flag it as misbehavior at all?
130 2014-09-16 11:23:49 <warren> REJECT_INVALID, "bad-diffbits");
131 2014-09-16 11:23:49 <warren> return state.DoS(100, error("ProcessBlock() : block with too little proof-of-work"),
132 2014-09-16 11:24:27 <wumpus> a DoS of 100 is supposed to disconnect the peer
133 2014-09-16 11:24:33 <warren> I thought I was in master but it actually is in 0.9.3
134 2014-09-16 11:24:40 <warren> the peer isn't disconnected after doing that
135 2014-09-16 11:25:01 <wumpus> (not immediately, but when it comes to the appropriate loop where fDisconnect is checked)
136 2014-09-16 11:25:45 <warren> getpeerinfo shows banscore of 0 on that peer
137 2014-09-16 11:25:53 <wumpus> that sounds like a possible bug, what is done with the state?
138 2014-09-16 11:26:18 <warren> AFAICT nothing actually checks nDoS after ProcessBlock
139 2014-09-16 11:27:03 <wumpus> right, state.DoS does not itself actually flag misbehavior
140 2014-09-16 11:27:21 <warren> I'm tired, I'll look harder tomorrow.
141 2014-09-16 11:27:51 <wumpus> there is usually a if (state.IsInvalid(nDoS)) { Misbehaving(node, nDos); } afterwards
142 2014-09-16 11:28:18 <wumpus> if not then indeed it is just ignored (this is done on purpose in some cases, with dummy states)
143 2014-09-16 11:29:10 <warren> banscore has nothing to do with DoS(), only Misbehaving?
144 2014-09-16 11:29:14 <warren> why are they separate?
145 2014-09-16 11:29:28 <wumpus> I just gave the reason ^
146 2014-09-16 11:30:02 <warren> haven't seen this before:
147 2014-09-16 11:30:04 <warren> 2014-09-16 09:47:28 UpdateTip: new best=00000000000000000aa1b9951862015e0fc35f2df69d75cea2fb296a9007f7d3 height=320949 log2_work=80.690339 tx=46812288 date=2014-09-16 09:47:21 progress=1.000000
148 2014-09-16 11:30:04 <warren> 2014-09-16 09:56:51 ERROR: Non-canonical public key: invalid length for uncompressed key
149 2014-09-16 11:30:04 <warren> 2014-09-16 09:56:51 ERROR: Non-canonical public key: neither compressed nor uncompressed
150 2014-09-16 11:30:13 <wumpus> sometimes you want to check without it having any consequences for a peer, note that a State object isn't even linked to a peer
151 2014-09-16 11:30:38 <warren> we do keep track of where a block came from
152 2014-09-16 11:30:46 <wumpus> I know that.
153 2014-09-16 11:30:53 <warren> so i wonder if it would be appropriate to use Misbehaving() instead?
154 2014-09-16 11:31:07 <wumpus> no, misbehaving should not be used *instead*
155 2014-09-16 11:31:11 <wumpus> <wumpus> there is usually a if (state.IsInvalid(nDoS)) { Misbehaving(node, nDos); } afterwards
156 2014-09-16 11:31:15 <wumpus> that's how it is done
157 2014-09-16 11:31:36 <warren> should I be concerned about that non-canonical error?
158 2014-09-16 11:31:47 <wumpus> so if it's supposed to have consequences for a node, you propagate the DoS from the state object into the node
159 2014-09-16 11:33:05 <wumpus> this is not always the case; it should be carefully evaluated if there is any risk that something could risk a network partitions
160 2014-09-16 11:33:12 <wumpus> no, that's just someone submitting a junk transaction
161 2014-09-16 11:34:03 <wumpus> in general you shouldn't be concerned unless *locks fail to validate, loose transactions failing is normal
162 2014-09-16 11:34:11 <wumpus> s/*locks/blocks/
163 2014-09-16 14:24:56 <michagogo> dammit
164 2014-09-16 14:25:12 <michagogo> wumpus: I took a closer look at the gitian changes
165 2014-09-16 14:25:29 <michagogo> The change is to use lxc-execute instead of lxc-start
166 2014-09-16 14:25:46 <michagogo> I don't know what the difference is and why the change was made
167 2014-09-16 14:26:16 <michagogo> But I now know this: it requires certain stuff to be available inside the container
168 2014-09-16 14:26:45 <michagogo> make-base-vm was changed, so now it installs the `lxc` package in the base VM, which makes it work
169 2014-09-16 14:27:36 <michagogo> It was breaking for me because lxc isn't installed in the base containers
170 2014-09-16 14:31:02 <michagogo> .whois devrandom devrandom
171 2014-09-16 14:31:05 <michagogo> gah
172 2014-09-16 14:35:26 <wumpus> michagogo: I wouldn't know either
173 2014-09-16 14:41:38 <michagogo> wumpus: would you have any idea how to add a package to the base VMs, as if it were there at the start?
174 2014-09-16 18:19:10 <gfawkes> Whois-output DOMAIN jayneclaire.com Registrar: JOKER.COM Status: hold,expired Owner Name: Jayne Ochoa Organization: Email: jayne@jayneclaire.com Address: 18081 Midway Rd. Apt. #1121 Postal code/City: 75287 Dallas State: TX Country: US Administrative contact: CCOM-502375 Technical contact: CCOM-502375 Billing contact: CCOM-502375 Nameserver: a.ns.joker.com b.ns.joker.com c.n
175 2014-09-16 18:24:44 <catlasshrugged> Is leveldb's use of snprintf() is prone to an off-by-one overflow? They tend to use it e.g. snprintf(rate, sizeof(rate), ...) in db_bench.cc
176 2014-09-16 18:25:02 <catlasshrugged> http://cwe.mitre.org/data/definitions/193.html
177 2014-09-16 18:26:16 <sipa> no
178 2014-09-16 18:26:29 <michagogo> Hm, how do you check out a Github PR locally?
179 2014-09-16 18:26:41 <michagogo> I found https://help.github.com/articles/checking-out-pull-requests-locally, but I don't see a "command line" link
180 2014-09-16 18:26:55 <michagogo> (on https://github.com/bitcoin/bitcoin/pull/4727 )
181 2014-09-16 18:27:05 <sipa> put this in your .git/config:
182 2014-09-16 18:27:07 <sipa> [remote "upstream-pull"] fetch = +refs/pull/*:refs/remotes/upstream-pull/* url = git@github.com:bitcoin/bitcoin.git
183 2014-09-16 18:27:14 <sipa> (with proper newlines)
184 2014-09-16 18:27:33 <sipa> then git fetch upstream-pull
185 2014-09-16 18:27:41 <sipa> git checkout upstream/NUM/head
186 2014-09-16 18:27:42 <michagogo> What are the proper newlines?
187 2014-09-16 18:27:54 <sipa> [remote "upstream-pull"]
188 2014-09-16 18:28:02 <catlasshrugged> sipa: why not?
189 2014-09-16 18:28:10 <sipa> fetch = +refs/pull/*:refs/remotes/upstream-pull/*
190 2014-09-16 18:28:13 <sipa> url = ...
191 2014-09-16 18:28:23 <michagogo> sipa: thanks
192 2014-09-16 18:28:23 <sipa> catlasshrugged: snprintf writes at most N bytes, including the terminating newline
193 2014-09-16 18:28:37 <sipa> perhaps a tab instead of 4 spaces
194 2014-09-16 18:28:45 <michagogo> sipa: hm, you put spaces in there, but it looks like the file uses tabs
195 2014-09-16 18:28:51 <sipa> so use tabs!
196 2014-09-16 18:29:02 <michagogo> Does that just go at the end?
197 2014-09-16 18:29:08 <sipa> anywhere
198 2014-09-16 18:29:14 <michagogo> Okay, thanks
199 2014-09-16 18:29:19 <michagogo> ACTION tries
200 2014-09-16 18:30:14 <michagogo> sipa: git@github.com? I thought GH was accessed with https://github.com?
201 2014-09-16 18:30:21 <catlasshrugged> sipa: ah, thanks. Guess that MITRE page is out of date/incorrect.
202 2014-09-16 18:31:22 <sipa> catlasshrugged: no, it's correct, but the problem there in that example is with the strcat, not snprintf
203 2014-09-16 18:33:37 <michagogo> 21:27:38 <sipa> git checkout upstream/NUM/head
204 2014-09-16 18:33:37 <michagogo> not upstream-pull?
205 2014-09-16 18:34:21 <catlasshrugged> sipa: got it. thanks.
206 2014-09-16 18:34:50 <sipa> michagogo: indeed
207 2014-09-16 19:29:44 <michagogo> coryfields: there?
208 2014-09-16 19:30:27 <michagogo> coryfields: what do I give to gbuild's --commit?
209 2014-09-16 19:30:47 <michagogo> (testing 4727)
210 2014-09-16 19:31:15 <jgarzik> New full node
211 2014-09-16 19:31:17 <jgarzik> https://github.com/coinbase/toshi
212 2014-09-16 19:31:23 <jgarzik> Ruby + Postgres
213 2014-09-16 19:31:45 <jgarzik> it's built to power large, web-scale applications.
214 2014-09-16 19:33:17 <jrick> I was under the impression that postgres was too ACID for webscale
215 2014-09-16 20:04:27 <potatowedge> **noob alert** Multisig: Is it possible to determine how many authenticated private keys are required to unlock funds from only one multisignature public address?
216 2014-09-16 20:06:36 <Luke-Jr> potatowedge: that doesn't make sense.
217 2014-09-16 20:07:04 <Luke-Jr> from the blockchain, you don't know anything about a P2SH address until it's spent
218 2014-09-16 20:07:13 <Luke-Jr> you don't even know it's multisig
219 2014-09-16 20:07:44 <Luke-Jr> what is the "public" qualifier to "address" supposed to mean to you?
220 2014-09-16 20:08:05 <sipa> as opposed to the private keys, i assume
221 2014-09-16 20:09:05 <sipa> but indeed, the answer is "intentionally, no"
222 2014-09-16 20:25:00 <potatowedge> Sorry if I am a noob about this. What I'm trying to ask is if I have a P2SH "public" address which requires m-of-n signatures to unlock; can I determine 'm' from only the Bitcoin URI?
223 2014-09-16 20:25:37 <potatowedge> Such as 2 out of three to unlock, where m=2.
224 2014-09-16 20:25:59 <sipa> no
225 2014-09-16 20:26:08 <potatowedge> Thanks :)
226 2014-09-16 20:26:13 <sipa> the p2sh address is the hash of the script
227 2014-09-16 20:26:23 <sipa> it is impossible to determine the script from the hash
228 2014-09-16 20:27:08 <potatowedge> Thanks sipa.
229 2014-09-16 21:57:52 <cotix> why does bitcoin core download the blockchain so slow? I know it is an intensive operation, but 1 blocke per ~10-20 seconds? cmon
230 2014-09-16 21:58:21 <sipa> it probably means it's just fetching it from a slow peer
231 2014-09-16 21:58:40 <sipa> the next release will improve the block fetching logic significantly
232 2014-09-16 21:58:50 <cotix> it also stops downloading after awhile and doesn start untill i restart bitcoind
233 2014-09-16 21:58:53 <cotix> great
234 2014-09-16 21:59:11 <cotix> such a pain that i need a week of downloading and restarting even with 1gbits symmetric
235 2014-09-16 21:59:28 <sipa> should be doable in a few hours
236 2014-09-16 21:59:50 <sipa> you can use bootstrap.dat, or use -connect=IP to a fast node to speed things up
237 2014-09-16 22:00:05 <cotix> ill try that connect thing
238 2014-09-16 22:00:29 <sipa> boostrap.dat is a file you fetch using bittorrent and then have bitcoin load it
239 2014-09-16 22:00:39 <sipa> it means more temporary storage
240 2014-09-16 22:00:43 <Happzz> implement bittorrent for blockchain syncing!
241 2014-09-16 22:01:24 <sipa> Happzz: we have parallel block fetching implemented, which is superior to bittorrent as it verifies on the fly without needing 25 GB storage temporary data before starting validation
242 2014-09-16 22:01:38 <gmaxwell> cotix: I can sync the whole chain from a gigabit connected peer in 2 hours 17 minutes.
243 2014-09-16 22:01:58 <cotix> That's odly specific time haha
244 2014-09-16 22:02:04 <Happzz> sipa you guys seriously need to think about some way to reduce the amount of data nodes use
245 2014-09-16 22:02:08 <cotix> I'll try the connect thing, maybe just some bad luck
246 2014-09-16 22:02:14 <Happzz> sipa especially in circumstances where they dont care about the whole history of a coin
247 2014-09-16 22:02:27 <midnightmagic> cotix: try #bitcoin next time for questions like that.
248 2014-09-16 22:02:59 <cotix> Also I dissabled ipv6 because I thought that might have to do with it, can I put that back on or should i stay on ipv4?
249 2014-09-16 22:03:26 <midnightmagic> cotix: #bitcoin please.
250 2014-09-16 22:48:55 <rrose> Hi, anyone got some experience with testnet in a box on OSX?