1 2014-04-30 03:08:46 <amiller> does anyone have a tool that parses/dumps addrman.dat
  2 2014-04-30 03:14:33 <ncsupanda> Trying to figure out how to split a block reward between separate addresses. I know that we add a coinbase tx onto the block template, but how would we add more than one? Or rather, can we make separate outputs?
  3 2014-04-30 03:37:02 <iwilcox> Comments on (~1y old) https://github.com/bitcoin/bitcoin/issues/273 suggest DSL users were at that time just probably not able to help significantly by running full nodes, owing to crappy upload.  Is that still the case?
  4 2014-04-30 03:38:15 <iwilcox> I guess what it boils down to is: should I bother making a throttled-upload-over-ADSL node listen at all, given the suggestions of dearth of full nodes lately?
  5 2014-04-30 03:43:48 <iwilcox> Might be within my QoS-fu to cut off a node that appears to be syncing off me to the extent that I trigger its "misbehaving" thingy and it blacklists me, preventing the situation where a poor bootstrapping node somewhere takes weeks to come up, but maybe that's just trying too hard.
  6 2014-04-30 04:38:05 <sipa> ncsupanda: a coinbase can have multiple outputs
  7 2014-04-30 04:38:33 <ncsupanda> I'm trying to figure out how to actually edit those outputs, both for bitcoin and litecoin
  8 2014-04-30 04:39:38 <Luke-Jr> edit?
  9 2014-04-30 04:40:03 <ncsupanda> Not edit, sorry; how to actually add onto the coinbase
 10 2014-04-30 04:40:38 <Luke-Jr> you just create it how you want it initially..
 11 2014-04-30 04:41:42 <ncsupanda> So if I want a transaction to have two outputs, I can just create (for example, with litecoin) another entry for tx.NewVout?
 12 2014-04-30 04:42:28 <Luke-Jr> ncsupanda: this is #bitcoin-dev, not #litecoin-dev
 13 2014-04-30 04:44:02 <Luke-Jr> ncsupanda: for generation, there is a specific protocol used to control outputs; <number of outputs>\n<amount 1>\n<address 1>\n<…>
 14 2014-04-30 04:44:18 <Luke-Jr> I have no idea what code "tx.NewVout" would be part of
 15 2014-04-30 04:45:38 <ncsupanda> I believe it's the same idea. Sorry for questions that seem off-topic, I'm just trying to get a more firm grasp on both coins, not just one
 16 2014-04-30 04:46:27 <Luke-Jr> this channel is just about one.
 17 2014-04-30 06:06:19 <wumpus> I'm fine with splitting off the 0.9.2 branch already if there is a good reason
 18 2014-04-30 06:07:03 <wumpus> ie, if it would help future development along a lot
 19 2014-04-30 06:22:25 <wumpus> it does mean extra work for me; to merge/cherry-pick some changes into two branches, and to make sure the translations are the same on both branches
 20 2014-04-30 06:23:38 <warren> is there anything in paritcular ou want to merge that isn't suitable for 0.9.2?
 21 2014-04-30 06:25:05 <wumpus> not me, but a few people were talking about it while I was sleeping
 22 2014-04-30 06:25:20 <wumpus> just read back...
 23 2014-04-30 06:28:02 <warren> ripping out openssl is too radical for 0.9.2? =P
 24 2014-04-30 06:30:22 <wumpus> warren: seems we're having issues tiwh transifex
 25 2014-04-30 06:30:30 <warren> oh?
 26 2014-04-30 06:30:48 <wumpus> warren: I did a tx pull -a yesterday and didn't get all changes, diapolo did another one and got a different (more complete) set of changes
 27 2014-04-30 06:31:21 <warren> yeah ... tx pull behavior is confusing to me
 28 2014-04-30 06:32:01 <wumpus> warren: anything that potentially changes consensus is too radical for 0.9.2
 29 2014-04-30 06:32:08 <warren> wumpus: I was joking
 30 2014-04-30 06:32:12 <wumpus> okay :)
 31 2014-04-30 06:32:29 <warren> the translation commit was yours or diapolo's?
 32 2014-04-30 06:32:54 <wumpus> I made a commit yesterday, then diapolo submitted this pull later: https://github.com/bitcoin/bitcoin/pull/4105
 33 2014-04-30 06:33:08 <wumpus> 22 files changed in there, no way that translators made so many changes in the meantime :P
 34 2014-04-30 06:34:03 <wumpus> when I ran tx pull -a it skipped those; I don't know what rule it uses to determine whether to skip updating a translation
 35 2014-04-30 06:35:31 <warren> wouldn't -f have the same result (no diff) if there's no changes?
 36 2014-04-30 06:35:43 <warren> I agree -a behaves weird for me in another project
 37 2014-04-30 06:36:53 <wumpus> well, not really, it's pretty annoying but the .ts files contain line numbers of the messages... so a small change in a source file will cause line number updates *in all the translations*
 38 2014-04-30 06:37:28 <warren> isn't that desired?
 39 2014-04-30 06:37:53 <wumpus> no, it's not, it's noise
 40 2014-04-30 06:38:00 <wumpus> I really hate it
 41 2014-04-30 06:38:21 <wumpus> ideally I'd like to just see the messages that changed in a diff
 42 2014-04-30 06:38:35 <wumpus> btw another issue:  ko_KR contains control characters, that cannot be parsed by Qt's translation tools
 43 2014-04-30 06:38:56 <warren> isn't Diapolo on windows?
 44 2014-04-30 06:39:08 <wumpus> last time I manually removed them before committing, but they come back every time
 45 2014-04-30 06:39:23 <warren> perhaps tx pull uses some file attributes to determine the freshness of local files and it always fails on windows?
 46 2014-04-30 06:39:51 <warren> btw, can you share your .tx/config ?
 47 2014-04-30 06:40:03 <wumpus> I should probably remove them on transifex itself, however, it's not nice that it can generate invalid files in the first place
 48 2014-04-30 06:40:29 <warren> I'd like to see the invalid control character, also did you file a bug with transifex?
 49 2014-04-30 06:40:29 <wumpus> hey I just thought of something: I can remove the line numbers from the non-English TS files
 50 2014-04-30 06:40:50 <wumpus> they're only used to aid translators, so only make sense in the original file
 51 2014-04-30 06:41:31 <warren> so you would have a post-processing script to delete them before commit?
 52 2014-04-30 06:41:41 <wumpus> yep
 53 2014-04-30 06:41:50 <wumpus> I need that anyway to strip the control characters out
 54 2014-04-30 06:42:09 <warren> I want to see the control character, and I'll file a bug
 55 2014-04-30 06:42:09 <wumpus> and it would automatically call tx with the right argument (prolly -f)
 56 2014-04-30 06:42:33 <warren> what is your .tx/config ?
 57 2014-04-30 06:42:49 <wumpus> warren: http://www.hastebin.com/gugayimeta.ini
 58 2014-04-30 06:43:21 <warren> would be no harm to commit this to the source repo
 59 2014-04-30 06:43:34 <warren> oh ... except windows wants backslashes
 60 2014-04-30 06:43:38 <warren> tx should really handle that transparetly
 61 2014-04-30 06:46:32 <wumpus> warren: this is the file with control characters: https://raw.githubusercontent.com/Diapolo/bitcoin/translations/src/qt/locale/bitcoin_ko_KR.ts
 62 2014-04-30 06:46:45 <wumpus> if you put it in the src/qt/locale and build, qt will croak
 63 2014-04-30 06:47:10 <warren> which one is hte control character?
 64 2014-04-30 06:47:43 <wumpus> don't know by heart, you can find it yourself with the above step
 65 2014-04-30 06:48:12 <wumpus> I suppose: all characters < 32 would be invalid to have in the file
 66 2014-04-30 06:48:25 <wumpus> if you really need them, escape them as xml entities
 67 2014-04-30 06:48:49 <wumpus> but I don't think even Korean needs them :)
 68 2014-04-30 06:49:12 <warren> -        <translation>허용되지 않는다</translation>
 69 2014-04-30 06:49:13 <warren> +        <translation>허용되지 않는다^\</translation>
 70 2014-04-30 06:49:17 <warren> there?
 71 2014-04-30 06:49:28 <wumpus> yes, that's one, there are a lot
 72 2014-04-30 06:49:38 <warren> looks like the Won symbol
 73 2014-04-30 06:50:01 <wumpus> the Won symbol is ^\?!
 74 2014-04-30 06:50:15 <warren> well, that's how IRC converted it
 75 2014-04-30 06:50:29 <warren> i'm looking at it
 76 2014-04-30 06:50:33 <wumpus> ASCII 28
 77 2014-04-30 06:51:02 <wumpus> FS (file separator)
 78 2014-04-30 06:51:37 <warren>          <source>not accepted</source>
 79 2014-04-30 06:51:50 <warren> the string in transifex doesn't even match this
 80 2014-04-30 06:52:35 <warren> oh it does, just different font
 81 2014-04-30 06:53:00 <warren> I'll report this as a bug
 82 2014-04-30 06:53:11 <warren> bbl
 83 2014-04-30 06:53:16 <wumpus> well google translate makes "not allowed" of it, seems close enough, so the translation seems valid
 84 2014-04-30 06:53:19 <wumpus> okay thanks!
 85 2014-04-30 07:17:14 <warren> wumpus: can we check in the .tx/config ?
 86 2014-04-30 07:17:24 <warren> wumpus: it will make it easier for them to reproduce it
 87 2014-04-30 07:17:46 <wumpus> I don't like checking in dotfiles; I think I'm going to make the checkout script generate that file
 88 2014-04-30 07:17:58 <wumpus> (if it doesn't exist)
 89 2014-04-30 07:18:15 <warren> well .gitignore ...
 90 2014-04-30 07:29:36 <wumpus> ok, good point
 91 2014-04-30 07:29:39 <wumpus> I'm going to add it
 92 2014-04-30 07:33:34 <Naphex> anybody have anything against using DNS to do Name2Address resolve?
 93 2014-04-30 07:38:48 <jcorgan> .cl
 94 2014-04-30 07:40:36 <wumpus> Naphex: normal bitcoin addresses are not suited for that, as there are privacy issues with re-using them; there was some work on 'stealth addresses' that allow privacy while still having a stable identifier
 95 2014-04-30 07:42:01 <Naphex> well people whould want the privacy can just issue xpub or stealth addresses
 96 2014-04-30 07:42:56 <wumpus> everyone wants and needs privacy
 97 2014-04-30 07:43:31 <jcorgan> also, reusing addresses reduces the privacy of others you deal with
 98 2014-04-30 07:44:04 <wumpus> right, by giving out a public address you're screwing the privacy of those that want to send you money
 99 2014-04-30 07:45:21 <Naphex> i have a working example set up
100 2014-04-30 07:45:33 <Naphex>  $ host -t txt naphex.addresses.btcxchange.ro
101 2014-04-30 07:45:33 <Naphex> naphex.addresses.btcxchange.ro descriptive text "v:btc1 addr:12mVDqdWqFY6zrCqNqgHbxhDPB4ZVUuaTu signature:IGnKD8UQ5/AaWadgGc3aIQ5q9EmgxuF+Vw+F4SSYkB9R+TAVzvnDq+fTZql08JEWrRLlTCReF3lTQAtea66zv5A="
102 2014-04-30 07:46:16 <Naphex> signature is bitcoin signature, containing domain and dnsserver pub ksk key
103 2014-04-30 07:46:47 <Naphex> so if clients support it, might as well resolve to a steath address
104 2014-04-30 07:50:37 <wumpus> sounds useful in some cases
105 2014-04-30 07:50:42 <jcorgan> yeah, a stable stealth address would be a good thing for this
106 2014-04-30 07:51:13 <wumpus> for example, you could donate directory to a domain (given that DNS is really secure...)
107 2014-04-30 07:51:46 <Naphex> wumpus: the zone is signed
108 2014-04-30 07:51:48 <wumpus> send coins to: wikileaks.org ...
109 2014-04-30 07:52:03 <wumpus> but without stealth addresses it's a disaster waiting to happen
110 2014-04-30 07:52:04 <Naphex> while the address signature contains the dnskey for the dnsserver associated
111 2014-04-30 07:53:09 <wumpus> the advantage being that it would be somewhat easier to set up than a script that deals out bitcoin URIs/payment requests
112 2014-04-30 07:53:21 <Naphex> $ host -t dnskey addresses.btcxchange.ro                                                                                                                                                                     addresses.btcxchange.ro has DNSKEY record 257 3 13 hTj/xt+OErAHwCrCY7LKmkO9HhS4RG9c4yW2gowo8I2dwCGRkpbLE1b6 BJrA+4TGJcbdKfFWoT7dpK/zJPzgIg==
113 2014-04-30 07:54:55 <Naphex> this is the message that the txt signature - signs
114 2014-04-30 07:54:56 <Naphex> naphex.addresses.btcxchange.ro 257 3 13 hTj/xt+OErAHwCrCY7LKmkO9HhS4RG9c4yW2gowo8I2dwCGRkpbLE1b6
115 2014-04-30 07:55:16 <Naphex> so yeah advantages would be you could for example just send to a domain
116 2014-04-30 07:55:24 <Naphex> and services can host domain for its users
117 2014-04-30 07:55:49 <Naphex> addr: could be whatever client supports, Stealth Addresses, Static ones
118 2014-04-30 07:56:07 <Naphex> dns software can just roll it and change it as long as it signgs the zone
119 2014-04-30 07:57:09 <Naphex> or round robin from a batch
120 2014-04-30 11:58:07 <GAit> jgarzik: you there? can you ping me please?
121 2014-04-30 12:09:50 <sipa> s
122 2014-04-30 12:13:18 <venzen> i
123 2014-04-30 12:32:22 <GAit> p
124 2014-04-30 12:33:08 <survic> a
125 2014-04-30 12:38:44 <venzen> yay! \o/
126 2014-04-30 12:53:09 <jgarzik> GAit, hallo
127 2014-04-30 12:53:49 <GAit> jgarzik: hello, it's about bitpay, can i PM?
128 2014-04-30 12:57:57 <jgarzik> GAit, Yes you may PM.  But FWIW, most stuff is support@bitpay.com material...
129 2014-04-30 13:01:17 <GAit> if someone gets hold of the links they can see things about companies that may have privacy consequences
130 2014-04-30 13:35:42 <phedny> my testnet bitcoind reports getblockcount 224679 with hash 000000000001bf838a2364dd6598d0b3331f87416024f1c321cc59e153d8e01d, however it seems that that is an abandoned chain since April 15
131 2014-04-30 13:35:46 <phedny> how can I force bitcoind to pickup the correct chain again?
132 2014-04-30 13:38:43 <michagogo> cloud|phedny: are you on 0.9?
133 2014-04-30 13:39:59 <phedny>     "version" : 99900,
134 2014-04-30 13:41:15 <sipa> phedny: does debug.log have any indication of it attempting to switch chains, and failing?
135 2014-04-30 13:42:00 <michagogo> cloud|Could you pastebin a `grep -i invalid` of your debug.log?
136 2014-04-30 13:42:41 <phedny> michagogo|cloud: no lines with invalid; I must add that I restarted the daemon a couple of minutes ago as a first try to fix it
137 2014-04-30 13:44:06 <phedny> sipa: once in a while I see messages like: 2014-04-30 13:30:32 ProcessBlock: ORPHAN BLOCK 0, prev=000000001b62c97effb53e99bbedda21badaf005aa45f24cda791abd55f99b99
138 2014-04-30 13:44:24 <phedny> which seem to be valid blocks according to blockexplorer.com/testnet
139 2014-04-30 13:47:32 <michagogo> cloud|What's the latest block you have?
140 2014-04-30 13:47:48 <phedny> to me it is 000000000001bf838a2364dd6598d0b3331f87416024f1c321cc59e153d8e01d at height 224679
141 2014-04-30 13:47:52 <michagogo> cloud|Try grepping for the block hash after your latest one
142 2014-04-30 13:48:44 <phedny> that block hash is not found in debug.log
143 2014-04-30 13:49:00 <sipa> any InvalidBlock messaages?
144 2014-04-30 13:49:05 <phedny> no
145 2014-04-30 13:49:20 <sipa> how long has the node been running?
146 2014-04-30 13:49:59 <phedny> it had been running quite some time, don't know when I started it; but now it running just about half an hour because I restarted it
147 2014-04-30 13:50:26 <phedny> could be that it's running since Mar 19, that is when I started the mainnet bitcoind
148 2014-04-30 13:51:21 <phedny> by the way, it seems that coinplorer.com is stuck on the same chain https://coinplorer.com/BTCT
149 2014-04-30 13:54:49 <phedny> I can probably make a script to find out at what point the chain forked by checking when blockexplorer.com gives me a 200; is it possible to discard blocks from the history so it starts up at that point?
150 2014-04-30 13:58:40 <helo> you could perhaps dump the majority of your blk*.dat files into a bootstrap.dat, just ensuring that the fork point isn't included
151 2014-04-30 13:58:58 <helo> not sure how you would ensure that, though
152 2014-04-30 13:59:04 <sipa> phedny: can you send me the full debug.log since your last restart?
153 2014-04-30 13:59:10 <sipa> or upload it somewhere
154 2014-04-30 13:59:34 <helo> on the other hand, you could just dump all of your blk*.dat files into a bootstrap.dat, and see if it gets stuck again
155 2014-04-30 13:59:57 <sipa> phedny: or maybe, restart, and run with -debug, and wait half an hour
156 2014-04-30 14:00:19 <phedny> sipa: well, your first request is at http://pastebin.com/JB80xr9v
157 2014-04-30 14:00:43 <helo> the bootstrap.dat would include the blocks in the order that his node saw them to get stuck, wouldn't it?
158 2014-04-30 14:00:43 <phedny> restart around line 5536 though
159 2014-04-30 14:00:47 <phedny> 5336 *
160 2014-04-30 14:00:53 <sipa> phedny: that's not the whole run
161 2014-04-30 14:01:06 <phedny> that's the complete file as it is on disk
162 2014-04-30 14:01:06 <sipa> i want to see the beginning
163 2014-04-30 14:01:17 <sipa> yeah, the log gets truncated
164 2014-04-30 14:03:42 <phedny> let's restart with -debug than
165 2014-04-30 14:07:54 <phedny> with -debug, latest block from inventory it prints is 0000000000023acb449362f6548d0fbfee168c9143857d09918eca749c328265
166 2014-04-30 14:08:04 <phedny> it is both on blockexplorer.com and in my db
167 2014-04-30 14:08:17 <phedny> but rpc gives no nextblockhash, while blockexplorer does
168 2014-04-30 14:08:47 <phedny> also, rpc returns "confirmations" : -1,
169 2014-04-30 14:09:59 <sipa> wait until a new block is announced on testnet
170 2014-04-30 14:18:59 <michagogo> cloud|Which, if it doesn't happen by then, will be shortly after I get home in a few mins
171 2014-04-30 14:19:48 <michagogo> cloud|(I'll get out my block erupter and mine a diff 1)
172 2014-04-30 14:21:33 <phedny> ah, let's see
173 2014-04-30 14:21:57 <survic> phedny: new best #227310
174 2014-04-30 14:24:10 <phedny> http://pastebin.com/wabTLe3z
175 2014-04-30 14:24:26 <phedny> I'm still on the defunct #224679
176 2014-04-30 14:25:28 <sipa> phedny: i see the problem
177 2014-04-30 14:25:34 <sipa> and it's a bug in bitcoind
178 2014-04-30 14:29:20 <phedny> is there something I can supply to help fix the problem?
179 2014-04-30 14:29:24 <michagogo> cloud|What's testnet diff like these days?
180 2014-04-30 14:29:48 <phedny>     "difficulty" : 16384.00000000,
181 2014-04-30 14:30:11 <phedny> well, that is what my bitcoind reports, don't know if it is correct since it's off fromthe best chain
182 2014-04-30 14:30:47 <survic> michagogo|cloud: around 41k presently.
183 2014-04-30 14:30:50 <sipa> phedny: so the situation is that you have the 500 blocks in the main chain following the fork
184 2014-04-30 14:31:08 <gribble> The average time to generate a block at 330.0 Mhps, given difficulty of 41000.0, is 6 days, 4 hours, 13 minutes, and 45 seconds
185 2014-04-30 14:31:08 <michagogo> cloud|;;gentime 330 41000
186 2014-04-30 14:31:38 <sipa> phedny: but for some reason, they were no switched to when they were first received (presumably because another fork existed, longer than 500 blocks?)
187 2014-04-30 14:32:15 <sipa> phedny: now, when a new block is announced, bitcoin sees it as an orphan, and asks the peer it comes from for its list of headers between the known active best chain, and that orphan
188 2014-04-30 14:32:24 <sipa> phedny: at which point the peer replies with the first 500 such blocks
189 2014-04-30 14:32:33 <sipa> phedny: each of which we already have, so nothing happens
190 2014-04-30 14:33:11 <survic> helo: in the capacity people use it presently, it's just a private key protected with a password. people seem to have sufficient faith in it to post their private keys on public forums when using it. I don't know if this is misplaced or not.
191 2014-04-30 14:33:20 <survic> wrong window, sorry.
192 2014-04-30 14:34:18 <phedny> sipa: so that means somehow I got onto a fork that existed for more than 500 blocks and is now abandoned
193 2014-04-30 14:38:41 <michagogo> cloud|phedny: try this: getblockhash 224147
194 2014-04-30 14:39:00 <michagogo> cloud|Does it match http://paste.ubuntu.com/7366697/ v
195 2014-04-30 14:39:06 <michagogo> cloud|s/v/?/
196 2014-04-30 14:39:46 <phedny> no, it's more like 000000000000ede99f6b8a10c4af5c2b3ef16c2f08c15b80ac3442316eb7fe18
197 2014-04-30 14:40:12 <michagogo> cloud|What happens if you try getblock on that hash?
198 2014-04-30 14:40:28 <phedny> error: {"code":-5,"message":"Block not found"}
199 2014-04-30 14:41:04 <michagogo> cloud|And does getblockhash 224146 return 0...23acb449... ?
200 2014-04-30 14:41:27 <phedny> no
201 2014-04-30 14:41:35 <michagogo> cloud|Hm.
202 2014-04-30 14:41:35 <phedny> 000000004dad2d0973eca40ed4e5ad35652635da3f82d75118f881cb550f69d1
203 2014-04-30 14:42:50 <michagogo> cloud|Does 220000 return 0000...315a72a7ddd...?
204 2014-04-30 14:43:08 <phedny> yes
205 2014-04-30 14:43:21 <phedny> and 221000 returns ...2bf04..
206 2014-04-30 14:43:31 <michagogo> cloud|222000?
207 2014-04-30 14:43:42 <phedny> ...ad490..
208 2014-04-30 14:43:53 <michagogo> cloud|223000?
209 2014-04-30 14:44:01 <phedny> 00000000000f38d2e720ff4fb87bd3d12168c35bad5882592bacef8fb49f0ff4
210 2014-04-30 14:44:09 <michagogo> cloud|224000?
211 2014-04-30 14:44:18 <phedny> 00000000f14d1df5a673727eee687b01f216beb034f0b7915658f122bc632800
212 2014-04-30 14:44:33 <michagogo> cloud|224100?
213 2014-04-30 14:44:45 <phedny> hmm, going slower? :)
214 2014-04-30 14:44:53 <phedny> ...2b03c
215 2014-04-30 14:45:12 <michagogo> cloud|224200?
216 2014-04-30 14:45:18 <phedny> ...33347b
217 2014-04-30 14:45:35 <michagogo> cloud|Oh, wait
218 2014-04-30 14:45:48 <michagogo> cloud|224146 was already mismatched
219 2014-04-30 14:46:10 <michagogo> cloud|224070?
220 2014-04-30 14:46:17 <michagogo> cloud|Er, no
221 2014-04-30 14:46:21 <michagogo> cloud|224120
222 2014-04-30 14:46:33 <phedny> ..366ceae
223 2014-04-30 14:46:40 <michagogo> cloud|224130
224 2014-04-30 14:46:49 <phedny> ..bca8fd
225 2014-04-30 14:46:55 <michagogo> cloud|224140
226 2014-04-30 14:47:07 <phedny> ..12370a
227 2014-04-30 14:47:08 <phedny> no
228 2014-04-30 14:47:13 <phedny> .. 1370a
229 2014-04-30 14:47:27 <michagogo> cloud|Hm. I have ...129130...
230 2014-04-30 14:47:36 <michagogo> cloud|224135?
231 2014-04-30 14:47:37 <phedny> (123 is in my phone number, it's on auto-type in my fingers)
232 2014-04-30 14:47:49 <phedny> ..14bd4b
233 2014-04-30 14:47:59 <michagogo> cloud|224132?
234 2014-04-30 14:48:11 <phedny> ..c8397f
235 2014-04-30 14:48:26 <michagogo> cloud|224133 and 224134?
236 2014-04-30 14:48:48 <phedny> 000000000001ec136896f4d0b554e991394973ee6e070a21b44b809a4bea1d0a
237 2014-04-30 14:48:48 <phedny> 000000000002ae8c5405599ebac59a411db7ef556bfeff260c1e6f4de197ecdf
238 2014-04-30 14:48:48 <phedny> mark@cosmos:~/mip$ bitcoin/src/bitcoind -testnet getblockhash 224133
239 2014-04-30 14:48:48 <phedny> mark@cosmos:~/mip$ bitcoin/src/bitcoind -testnet getblockhash 224134
240 2014-04-30 14:48:58 <jouke> I remember some days (weeks) ago someone with a lot of hashing power succeeded to mine a shitload of blocks on testnet.
241 2014-04-30 14:49:08 <michagogo> cloud|224133 is first mismatch
242 2014-04-30 14:49:34 <phedny> jouke: probably April 15
243 2014-04-30 14:49:39 <michagogo> cloud|Hm. I wonder...
244 2014-04-30 14:49:56 <jouke> He talked about it in this channel.
245 2014-04-30 14:50:07 <michagogo> cloud|What happens if you submitblock this: paste.ubuntu.com/7366765/
246 2014-04-30 14:50:46 <phedny> rejected
247 2014-04-30 14:51:31 <michagogo> cloud|Anything in the log?
248 2014-04-30 14:51:47 <phedny> 2014-04-30 14:52:01 ERROR: ProcessBlock() : already have block 224133 000000002f
249 2014-04-30 14:51:47 <phedny> 2014-04-30 14:52:01 ThreadRPCServer method=submitblock
250 2014-04-30 14:51:51 <phedny> 92e10568c69f7fb5e177cec81c1ce736b08a916cb60089a98fda12
251 2014-04-30 14:51:54 <michagogo> cloud|Oh
252 2014-04-30 14:52:10 <phedny> sipa told me I probably have 500 more blocks on the good branch
253 2014-04-30 14:52:16 <michagogo> cloud|Actually, the log you pastebinned mentioned having 224146
254 2014-04-30 14:53:03 <michagogo> cloud|Can you grep your log for aad6237b76533 ?
255 2014-04-30 14:53:31 <phedny> it's not in there
256 2014-04-30 14:53:47 <michagogo> cloud|Try submitting Ubuntu paste 7366791
257 2014-04-30 14:53:55 <jouke> So a miner submitted a couple of hundreds of blocks at once, creating the longest chain, but somehow the mayority of the miningpower didn't switch to the longest chain?
258 2014-04-30 14:54:06 <jouke> And phedny did?
259 2014-04-30 14:54:33 <phedny> jouke: could be; but apparently also https://coinplorer.com/BTCT did
260 2014-04-30 14:54:37 <sipa> so first of all, was there a >500 long reorg?
261 2014-04-30 14:54:38 <phedny> they're stuck on the same place
262 2014-04-30 14:55:01 <michagogo> cloud|phedny: did it take that?
263 2014-04-30 14:55:07 <phedny> michagogo|cloud: it appears so; I got no output
264 2014-04-30 14:55:14 <michagogo> cloud|Check the log?
265 2014-04-30 14:55:22 <sipa> phedny: how far is your current tip ahead of the fork point?
266 2014-04-30 14:55:33 <phedny> 2014-04-30 14:55:23 ProcessBlock: ACCEPTED
267 2014-04-30 14:55:42 <jouke> phedny: We didn't have internet at the new office, so my testnet node wasn't running
268 2014-04-30 14:55:49 <survic> http://test.insight.is/ this block explorer seems to have the same chain phedny is stuck on
269 2014-04-30 14:55:57 <michagogo> cloud|phedny: just 1?
270 2014-04-30 14:56:09 <phedny> sipa:  224133 is first mismatch; my blockcount is 224679
271 2014-04-30 14:56:12 <survic> it's on the actual chain now, but it also has the orphaned blocks (marked "orphan")
272 2014-04-30 14:56:26 <sipa> phedny: ok, confirmed
273 2014-04-30 14:56:49 <michagogo> cloud|phedny: just one accept block?
274 2014-04-30 14:57:00 <phedny> michagogo|cloud: in the log, yes
275 2014-04-30 14:57:10 <michagogo> cloud|One sec, lemme do a quick script
276 2014-04-30 15:05:55 <jouke> Am I correct in thinking that the majority of hashing power did not switch to the longest testnet chain?
277 2014-04-30 15:06:14 <jouke> causing the problem phedny has now?
278 2014-04-30 15:06:44 <survic> that doesn't sound right. any fork with the majority of the hashrate becomes the longest over time.
279 2014-04-30 15:07:02 <sipa> survic: not if there is a bug that prevents switching to it
280 2014-04-30 15:07:31 <sipa> well, by definition the majority would not be mining on it, if they don't switch to it of course
281 2014-04-30 15:07:43 <survic> well, I was getting to that. sipa suggests there's a bug that stops reorganisations past 500 blocks, leaving the side chain orphaned with some people on it
282 2014-04-30 15:07:45 <jouke> survic: I believe that only one massive miner caused the longest chain, submitted all blocks and then stopped mining.
283 2014-04-30 15:07:49 <michagogo> cloud|phedny: okay, try this
284 2014-04-30 15:08:07 <michagogo> cloud|Download and run phedny.michagogo.cadoth.net/blocks.sh
285 2014-04-30 15:08:15 <survic> jouke: could be, but the client should be able to cope with any depth reorganisation. not being able to cope with in this case is a bug.
286 2014-04-30 15:08:53 <phedny> michagogo|cloud: that would probably fix the situation for me, but I'm also currently building a patch by sipa that should be a proper fix, so I'll try that first
287 2014-04-30 15:08:57 <michagogo> cloud|That should be submitblock commands for blocks 224148 to 224680
288 2014-04-30 15:09:19 <michagogo> cloud|Ah, that's also good :-)
289 2014-04-30 15:09:24 <survic> jouke: luckily to abuse this on the main network would need at least 500 blocks * 25BTC or around $5.5 million USD at risk.
290 2014-04-30 15:09:30 <michagogo> cloud|Actually
291 2014-04-30 15:10:20 <michagogo> cloud|phedny: it may be helpful if you stop the node and post your blocks/ dir before running with sipa's patch
292 2014-04-30 15:10:31 <michagogo> cloud|Maybe chainstate/ too
293 2014-04-30 15:10:41 <michagogo> cloud|To allow others to easily replicate the situation if needed
294 2014-04-30 15:10:55 <phedny> michagogo|cloud: actually I have made a backup of ~/.bitcoin/testnet3 folder for that case
295 2014-04-30 15:11:53 <michagogo> cloud|Wait a sec -- what's current block count? 227312?
296 2014-04-30 15:12:05 <jouke> But what caused the fork in the first place.
297 2014-04-30 15:12:07 <michagogo> cloud|One node (on cadoth) has that
298 2014-04-30 15:12:08 <survic> michagogo|cloud: yes
299 2014-04-30 15:12:19 <sipa> jouke: a fast hasher with a corrupted chainstate?
300 2014-04-30 15:12:30 <sipa> or just an intentional large reorganization
301 2014-04-30 15:12:58 <michagogo> cloud|But BCGUI on my desktop says "processed 227312 of 298460 (estimated) blocks
302 2014-04-30 15:13:07 <michagogo> cloud|Where's that number coming from?
303 2014-04-30 15:13:21 <phedny> seems mainnet
304 2014-04-30 15:13:40 <ndak> how do i check my bitcoin address?
305 2014-04-30 15:13:41 <survic> yeah, that's the mainnet height.
306 2014-04-30 15:13:44 <michagogo> cloud|Heh. How does that happen?
307 2014-04-30 15:13:48 <ndak> what is the command?
308 2014-04-30 15:13:56 <jouke> sipa: but why didn't all nodes switch to the longest chain?
309 2014-04-30 15:14:51 <michagogo> cloud|Wtf? Am I connected to a mainnet node somehow?
310 2014-04-30 15:14:52 <jouke> your bugfix fixes phednys problem, but not what caused it right? Or are you assuming that phedny and some blockexplorers were isolated from the rest of the network somehow?
311 2014-04-30 15:15:13 <michagogo> cloud|Getting spammed with "PROCESSMESSAGE: INVALID MESSAGESTART"
312 2014-04-30 15:15:23 <survic> jouke: a bug, it's not intended.
313 2014-04-30 15:15:45 <michagogo> cloud|jouke: I think the fork probably isn't the bug
314 2014-04-30 15:15:54 <survic> michagogo|cloud: is one of your peers being stupid and giving you main chain information on testnet?
315 2014-04-30 15:16:19 <michagogo> cloud|I think the bug is just in 500+ reorgs being broken
316 2014-04-30 15:16:33 <sipa> well, something had to cause the 500 deep reorg
317 2014-04-30 15:16:47 <ndak> how do i know my default bitcoin address?
318 2014-04-30 15:16:53 <sipa> ndak: no such thing
319 2014-04-30 15:17:08 <michagogo> cloud|I wish invalid messagestart included an address
320 2014-04-30 15:17:29 <sipa> ndak: if you need to receive coins, create an address
321 2014-04-30 15:17:36 <michagogo> cloud|Brb, firing up wireshark
322 2014-04-30 15:17:46 <survic> michagogo|cloud: getpeerinfo and look at the heights of your peers.
323 2014-04-30 15:18:09 <michagogo> cloud|Ah, one has -1
324 2014-04-30 15:18:14 <michagogo> cloud|Lemme try disconnecting it
325 2014-04-30 15:18:33 <survic> michagogo|cloud: that's normalish. clients like Armory return -1.
326 2014-04-30 15:18:50 <michagogo> cloud|Oh
327 2014-04-30 15:18:54 <michagogo> cloud|I'm an idiot
328 2014-04-30 15:20:01 <michagogo> cloud|I have BlueMatt's relay node addnoded
329 2014-04-30 15:20:21 <jouke> sipa, two massive reorgs at almost the same time?
330 2014-04-30 15:21:57 <michagogo> cloud|Wait, killing the connection to it didn't stop it
331 2014-04-30 15:22:23 <survic> michagogo|cloud: wireshark.
332 2014-04-30 15:22:33 <michagogo> cloud|I just killed all the connections to that process
333 2014-04-30 15:23:02 <michagogo> cloud|Idk what the invalid messagestart was, but here's the mainnet height thing solved:
334 2014-04-30 15:23:25 <michagogo> cloud|2014-04-30 15:22:04 receive version message: /testnetnodescrawler:x.x/: version 70001, blocks=298461, us=93.172.57.37:18333, them=0.0.0.0:0, peer=46.4.99.45:44556
335 2014-04-30 15:23:25 <michagogo> cloud|2014-04-30 15:22:07 receive version message: /testnetnodescrawler:x.x/: version 70001, blocks=227314, us=93.172.57.37:18333, them=0.0.0.0:0, peer=46.4.99.45:47610
336 2014-04-30 15:24:51 <michagogo> cloud|...and there go the messagestarts
337 2014-04-30 15:24:51 <survic> wonder why it gives two different block heights.
338 2014-04-30 15:25:36 <michagogo> cloud|Hm. Wireshark capturing on port 18333, nothing
339 2014-04-30 15:25:39 <survic> just a hunch, but the messagestart thing could mean they're using mainnet magic bytes on testnet? I'm not even sure if the magic bytes are even used there, but it seems plausible.
340 2014-04-30 15:25:55 <michagogo> cloud|survic: yes, I think that's what it os
341 2014-04-30 15:25:57 <michagogo> cloud|Is*
342 2014-04-30 15:26:09 <michagogo> cloud|Okay, I think it's the relay node thing
343 2014-04-30 15:26:17 <survic> michagogo|cloud: got the right interface? don't bother filtering by port, just use the bitcoin filter.
344 2014-04-30 15:26:32 <michagogo> cloud|Can you negate an addnode that's in the config?
345 2014-04-30 15:33:25 <michagogo> cloud|Okay, confirmed
346 2014-04-30 15:33:46 <michagogo> cloud|It was my mistake -- I had the BlueMatt relay node addnoded
347 2014-04-30 15:34:00 <michagogo> cloud|Because it's a different port and not 8333, the port is listed there
348 2014-04-30 15:34:31 <michagogo> cloud|And because it doesn't do handshaking, it's just a firehose of tx data...
349 2014-04-30 15:34:57 <michagogo> cloud|So as soon as I connected it started sending the tx messages, which were thrown out for being mainnet
350 2014-04-30 15:37:58 <michagogo> cloud|...I'll just take that out...
351 2014-04-30 15:47:13 <jouke> I am trying to understand what happened. Am i correct in thinking that we have one blockchain up to point A. The majority of steady hashing power created 900 blocks, A+B.
352 2014-04-30 15:47:16 <jouke> But some new player solo mined 1000 new blocks at Point A and did not submit them until he had a 1000 thousand blocks creating chain A+C, causing a big reorg with at least phedny and coinplorer on that chain.
353 2014-04-30 15:47:20 <jouke> Somehow majority hashing power stayed on A+B and slowly overtook chain A+C. The A+C nodes had to reorganise again, but failed because the fork was more than 500 blocks deep and the A+C nodes didn't recognize it hadn't reached the point where is was forked yet?
354 2014-04-30 16:02:26 <jouke> By requesting blockhashes it allready knew, because it had A + 900 blocks B? But maybe I am really misreading what Sipa said.
355 2014-04-30 16:14:19 <helo> would his blk?????.dat files be able to recreate the behavior?
356 2014-04-30 16:23:45 <sipa> helo: i believe so
357 2014-04-30 16:24:31 <survic> sipa: this would be a regression rather than an original design flaw wouldn't it?
358 2014-04-30 16:25:44 <sipa> survic: i believe this is a bug since 0.9
359 2014-04-30 16:34:35 <survic> sipa: makes sense.
360 2014-04-30 16:35:19 <chichov> is there an upper limit for: transaction size, transaction input count, transaction output count?
361 2014-04-30 16:35:31 <Luke-Jr> chichov: yes, read the cod
362 2014-04-30 16:35:55 <chichov> do you have a hint in which files this may be?
363 2014-04-30 16:36:24 <Luke-Jr> main.h
364 2014-04-30 16:36:53 <chichov> alright, thanks
365 2014-04-30 17:06:36 <chichov> is it correct that if an invalid/malformed transaction is received by a node then the sender is informed about it?
366 2014-04-30 17:07:01 <sipa> there's a recent addition to the protocol, a "reject" message
367 2014-04-30 17:07:29 <chichov> sipa: precisely, that's what I'm seeing right now (main.h: 70)
368 2014-04-30 17:07:37 <Luke-Jr> in most cases, I think the peer is just disconnected if it's really invalid
369 2014-04-30 17:07:52 <Luke-Jr> unless the reject is sent before booting them..
370 2014-04-30 17:08:33 <chichov> Luke-Jr: are you saying that if I'd send an invalid transaction, then I'd be disconnected by the peers I'm connected to?
371 2014-04-30 17:08:50 <sipa> chichov: no, to the ones you've sent it to
372 2014-04-30 17:09:03 <sipa> *by the ones you've sent it to
373 2014-04-30 17:09:58 <chichov> sipa: interesting. would I first receive a reject message?
374 2014-04-30 17:10:08 <sipa> maybe
375 2014-04-30 17:10:39 <chichov> that's a very funny thing to say about deterministic programs :P
376 2014-04-30 17:11:00 <chichov> what would it depend on?
377 2014-04-30 17:11:08 <sipa> i think the reject message is a hack, and i'm not sure how well it works
378 2014-04-30 17:11:38 <sipa> for testing, you can always look at the error logs on the receiving node
379 2014-04-30 17:11:49 <sipa> in production, you shouldn't send invalid transactions
380 2014-04-30 17:12:16 <hearn> chichov: for most failures yes. for double spending, the reject message is broken.
381 2014-04-30 17:12:25 <hearn> which is unfortunate because that’s one of the most common accidental failures
382 2014-04-30 17:12:43 <sipa> well, double spending is not reliably detectable in the first place
383 2014-04-30 17:13:12 <chichov> yep, lies in the nature of a distributed network
384 2014-04-30 17:13:15 <sipa> and if it's not, it is considered an orphan, which is not a rejection
385 2014-04-30 17:13:21 <sipa> chichov: eh no
386 2014-04-30 17:13:51 <sipa> chichov: it's just not distinguishable from a transaction where you're missing all parent transactions
387 2014-04-30 17:14:31 <chichov> oh, that's the issue you mean
388 2014-04-30 17:14:58 <sipa> the event of double spending itself is well defined from the point of every single node
389 2014-04-30 17:15:13 <sipa> but unless we keep track of all spent transactions, that is not detectable
390 2014-04-30 17:16:01 <hearn> yeah. it’s annoying :) probably you can detect an accidental double spend by seeing if a node asks for the parent transactions, when you think it should already have them
391 2014-04-30 17:30:55 <chichov> why was the data field in OP_RETURN limited to 80 bytes?
392 2014-04-30 17:31:38 <chichov> In theory, one could just split e.g. 200 bytes across 3 transaction outputs anyway
393 2014-04-30 17:32:23 <hearn> 40 bytes
394 2014-04-30 17:32:29 <hearn> only one output per tx
395 2014-04-30 17:32:31 <chichov> oh? weren't those 80?
396 2014-04-30 17:32:57 <survic> chichov: 40 bytes is standard, not 80.
397 2014-04-30 17:33:07 <chichov> according to https://bitcoinfoundation.org/blog/?p=290 it is 80
398 2014-04-30 17:33:15 <hearn> it was changed at the last minute
399 2014-04-30 17:33:44 <chichov> for any particular reason?
400 2014-04-30 17:33:44 <survic> chichov: https://github.com/bitcoin/bitcoin/blame/ae7e5d7cebd9466d0c095233c9273e72e88fede1/src/script.h#L26
401 2014-04-30 17:34:08 <survic> blame says "Per mailing list discussion.", so looking there would be a good start.
402 2014-04-30 17:34:23 <hearn> it was felt 40 bytes was enough for a hash and a few marker bytes
403 2014-04-30 17:34:27 <hearn> and that’s what it’s for
404 2014-04-30 17:34:58 <chichov> some desired to use this field for other purposes than just a hash, but alright
405 2014-04-30 17:35:15 <sipa> chichov: that's exactly the reason for decreasing it
406 2014-04-30 17:35:16 <survic> if you want to have more than a hash, you're doing something wrong.
407 2014-04-30 17:35:42 <chichov> where does the limitation of one output per tx come from?
408 2014-04-30 17:36:09 <survic> GAit: I never cared enough to read into it deeply, but it was basically made very centralised and gave huge riches to the company that bought it.
409 2014-04-30 17:36:16 <survic> sorry, windowing.
410 2014-04-30 17:36:20 <sipa> chichov: because that is all that is needed for making a transaction that commits to external data (the intended usecase)
411 2014-04-30 17:36:38 <sipa> chichov: the use case is not "adding arbitrary data to transactions"
412 2014-04-30 17:37:01 <chichov> so if OP_RETURN is used then only one transaction output for a transaction is allowed?
413 2014-04-30 17:37:17 <sipa> no, only one output with OP_RETURN in it
414 2014-04-30 17:37:25 <sipa> for other outputs, normal rules apply
415 2014-04-30 17:37:34 <chichov> hm, alright
416 2014-04-30 17:37:43 <chichov> so one OP_RETURN output per transaction
417 2014-04-30 17:38:16 <hearn> sipa: bitcoinj.org  whaddaya think? pretty nice huh?
418 2014-04-30 17:38:23 <hearn> saivann__ is the man
419 2014-04-30 17:39:34 <chichov> sipa: where in the code can I find that one-OP_RET-per-TX limitation?
420 2014-04-30 17:40:18 <survic> chichov: search for "mucho data"
421 2014-04-30 17:40:37 <sipa> that was changed, thankfully
422 2014-04-30 17:40:53 <sipa> IsStandardTx in main.cpp
423 2014-04-30 17:41:06 <survic> oh.
424 2014-04-30 17:41:14 <chichov> haha, thanks
425 2014-04-30 17:41:31 <sipa> hearn: nice :)
426 2014-04-30 17:42:21 <saivann__> sipa hearn: thanks! :)
427 2014-04-30 17:43:09 <survic> chichov: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L551
428 2014-04-30 17:43:46 <chichov> survic: thanks, I got it
429 2014-04-30 17:44:15 <survic> chichov: I miss the old message. it used to be mucho-data.
430 2014-04-30 17:44:36 <chichov> survic: no freedoms anymore eh?
431 2014-04-30 17:45:17 <survic> no more fun in the reference client.
432 2014-04-30 18:43:13 <petertodd> chichov: you can encode data more cheaply and more effectively by ways other than op-return; there's little reason to use it if you are publishing data
433 2014-04-30 18:45:27 <citra> can i ask a question about bitcoin-qt issues here
434 2014-04-30 18:47:50 <sipa> sure
435 2014-04-30 18:48:10 <sipa> github.com/bitcoin/bitcoin/issues is your friend though
436 2014-04-30 18:48:38 <citra> i was using an old version of bitcoin-qt on my mac, i set up an address to receive coins and sent them to that address, then realized things needed to be synchronized. i set up to synch and it gave me a bug 11DbException. i upgraded and kept my original wallet.dat file. i can't see the addresses i gave out anymore.
437 2014-04-30 18:49:10 <citra> i also don't see coins but it's not done synching
438 2014-04-30 18:49:24 <sipa> go to the debug console, and type
439 2014-04-30 18:49:39 <sipa> validateaddress [that address]
440 2014-04-30 18:49:44 <sipa> without the []
441 2014-04-30 18:49:57 <citra> ok
442 2014-04-30 18:49:59 <citra> in bitcoin-qt?
443 2014-04-30 18:50:01 <sipa> yes
444 2014-04-30 18:50:23 <citra> ok
445 2014-04-30 18:50:24 <citra> says it is valid
446 2014-04-30 18:50:31 <sipa> what does it say next to ismine?
447 2014-04-30 18:50:36 <citra> true
448 2014-04-30 18:50:41 <sipa> then you're good
449 2014-04-30 18:50:42 <citra> o ok, so that means it will show up when done synchronizing
450 2014-04-30 18:50:46 <citra> ok awesome, thanks so much for your help
451 2014-04-30 18:50:48 <sipa> just wait until it is synchronized
452 2014-04-30 18:51:06 <citra> do you know if that 11dbexception bug is just because i was using an old version
453 2014-04-30 18:51:07 <citra> it said something about memory
454 2014-04-30 18:51:22 <sipa> i can't say
455 2014-04-30 18:51:35 <citra> ah ok
456 2014-04-30 18:51:43 <citra> hopefully it doesn't come up again
457 2014-04-30 18:51:48 <citra> that's what stopped my wallet from synching
458 2014-04-30 18:51:57 <citra> and when i googled the error it just said to upgrade my version
459 2014-04-30 18:52:04 <sipa> is it making progress now?
460 2014-04-30 18:52:16 <citra> well yeah but it is starting over because i upgraded
461 2014-04-30 18:52:29 <citra> i didn't have enough space on my computer to download the blocks
462 2014-04-30 18:52:37 <citra> it got stuck around 250k or something
463 2014-04-30 18:52:40 <sipa> ok
464 2014-04-30 18:52:43 <citra> i think
465 2014-04-30 18:52:50 <sipa> do you have enough space now?
466 2014-04-30 18:53:06 <citra> no :( i run parallels so it takes up a ton of space
467 2014-04-30 18:53:24 <citra> i tried to move over a lot to my external but that bootstrap.dat file takes up 13 gb or something
468 2014-04-30 18:53:42 <citra> and i can't really get rid of the parallels stuff
469 2014-04-30 18:54:21 <sipa> so what are you trying to achieve?
470 2014-04-30 18:54:22 <helo> you might have to use a different wallet if you can't spare ~20GB
471 2014-04-30 18:54:46 <sipa> bitcoin core will not work without the entire chain
472 2014-04-30 18:55:04 <citra> hrm
473 2014-04-30 18:55:09 <citra> ok i'll have to clear up more space
474 2014-04-30 18:55:16 <sipa> you don't need bootstrap.dat though
475 2014-04-30 18:55:24 <citra> is there anyway for me to move it to a different computer as long as i have the wallet.dat file
476 2014-04-30 18:55:31 <sipa> yes
477 2014-04-30 18:55:37 <citra> ok, cool
478 2014-04-30 18:55:42 <citra> i think i'll do that, then
479 2014-04-30 18:55:59 <citra> in the past i had it working ok
480 2014-04-30 18:56:04 <citra> but that was 2 years ago
481 2014-04-30 18:56:10 <citra> and it didnt seem to take up too much space?
482 2014-04-30 18:56:11 <sipa> ha
483 2014-04-30 18:56:22 <sipa> well the chain has grown a bit since then :D
484 2014-04-30 18:56:28 <citra> yeah i figure heh
485 2014-04-30 18:59:27 <citra> if i have some coins on coinbase is there an advantage to moving them to my bitcoin-qt wallet
486 2014-04-30 18:59:56 <midnightmagic> I have a total of about 20GB here for blocks/* and chainstate/* together.
487 2014-04-30 19:00:53 <citra> i only have about 14 gb free atm
488 2014-04-30 19:00:58 <citra> i'll try to clear up more space