1 2014-02-15 00:14:51 <maaku> Luke-Jr: no i meant people being unable to figure out solo mining in general
  2 2014-02-15 00:15:16 <maaku> solopool shouldn't need to exist
  3 2014-02-15 00:15:22 <Luke-Jr> it doesn't.
  4 2014-02-15 00:19:03 <ahmed_bodi> maaku: a p2pool integrated would be much better than solo mining
  5 2014-02-15 00:19:11 <ahmed_bodi> even if it was via a config option
  6 2014-02-15 00:19:22 <ahmed_bodi> solo mining nowadays gets nothing
  7 2014-02-15 00:19:43 <Mallstromm> ahmed_bodi: depends on your hashrate :D
  8 2014-02-15 00:20:15 <ahmed_bodi> Mallstromm: True, but im sure even those with huge hashrates might like to p2pool mine on a local node
  9 2014-02-15 00:20:37 <Luke-Jr> ahmed_bodi: or they could mine on any of 10+ other pools
 10 2014-02-15 00:20:43 <ahmed_bodi> the only coin i know of thats adding p2pool is digitalcoin and thats in their lite wallet
 11 2014-02-15 00:20:58 <ahmed_bodi> Luke-Jr:  like i said some people like a local node
 12 2014-02-15 00:21:08 <ahmed_bodi> the whole idea of p2pool is to be distributed
 13 2014-02-15 00:21:19 <Luke-Jr> ahmed_bodi: yes, p2pool isn't the first nor the only of such pools
 14 2014-02-15 00:21:45 <ahmed_bodi> which others are there? (i've not heard of any others so forgive my ignorance)
 15 2014-02-15 00:22:20 <Luke-Jr> ahmed_bodi: BitPenny was the first one; it used a fork of bitcoind (and got broken with P2SH)
 16 2014-02-15 00:22:45 <ahmed_bodi> ahh i've heard of bitpenny didnt know it was like p2pool though
 17 2014-02-15 00:23:12 <Luke-Jr> ahmed_bodi: any pool that supports the GBT standard (eg, Eligius) is also decentralised from the network's perspective, and can in theory use a local node (though support for this is still very limited)
 18 2014-02-15 00:24:57 <ahmed_bodi> Luke-Jr:  thats true. but like you said you'reseld using a local node with gbt is limited
 19 2014-02-15 00:25:14 <ahmed_bodi> and the use of GBT is limited
 20 2014-02-15 00:25:31 <ahmed_bodi> the only pools with support afaik are triplemining, bitminter and eligius
 21 2014-02-15 00:27:28 <kinlo> ahmed_bodi: actually, triplemining dropped support :/
 22 2014-02-15 00:27:53 <Luke-Jr> ahmed_bodi: hopefully it will improve, as GBT implementation progresses
 23 2014-02-15 00:28:11 <Luke-Jr> once libblkmaker supports local nodes better, GBT bandwidth use drops signficantlty
 24 2014-02-15 00:28:27 <lechuga_> which reminds me
 25 2014-02-15 00:28:35 <lechuga_> i didn tget to my GBT change the other night as intended
 26 2014-02-15 00:29:03 <Luke-Jr> XD
 27 2014-02-15 00:29:34 <lechuga_> and now with this terrible holiday i wont be able to tonight either
 28 2014-02-15 00:29:40 <lechuga_> long weekend shud provide ample opportunity
 29 2014-02-15 00:29:50 <Luke-Jr> hey, don't insult St. Valentine! :P
 30 2014-02-15 00:29:56 <lechuga_> lol :)
 31 2014-02-15 00:33:01 <ahmed_bodi> kinlo: is that because they switched away from eloipool?
 32 2014-02-15 00:33:18 <ahmed_bodi> (well more a question of did they switch away :P)
 33 2014-02-15 00:37:47 <ahmed_bodi> kinlo: ? u guys dropped eloipool?
 34 2014-02-15 00:39:29 <arubi> Hi all, I wrote down an idea I had for long term storage of coins. If you could spare a couple of minutes, I could use some criticism : http://pastebin.com/YyLJvkAi
 35 2014-02-15 00:50:57 <kinlo> ahmed_bodi: we're currently still using eloi, just no more gbt :)
 36 2014-02-15 00:51:53 <ahmed_bodi> ahh i see. i tried eloi. cant get used to it though. much prefer stratum (mainly cause its quite tightly integrated with the MPOS frontend)
 37 2014-02-15 01:28:25 <etotheipi_> gmaxwell: you familiar with the Trezor implementation?
 38 2014-02-15 01:28:48 <etotheipi_> specifically, that they allow arbitrary message signing, thus a compromised online computer may be able to bypass supporting-tx check
 39 2014-02-15 01:29:11 <etotheipi_> (support-tx check == fee check)
 40 2014-02-15 01:29:43 <sipa> or you could be tricked into sending your fortune away as fees?
 41 2014-02-15 01:29:56 <gmaxwell> what?!
 42 2014-02-15 01:30:01 <gmaxwell> why would they do that?
 43 2014-02-15 01:30:09 <etotheipi_> gmaxwell: I guess not....
 44 2014-02-15 01:30:14 <gmaxwell> are you sure it's not just an implemention of signmessage?
 45 2014-02-15 01:30:15 <etotheipi_> gmaxwell: I'm not positive
 46 2014-02-15 01:30:21 <etotheipi_> that's why I'm asking
 47 2014-02-15 01:30:23 <sipa> signmessage should be fine
 48 2014-02-15 01:30:27 <gmaxwell> (which is safe, because we use another hash specifically to prevent this weakness)
 49 2014-02-15 01:30:29 <sipa> it cannot be used for transaction signing
 50 2014-02-15 01:31:26 <etotheipi_> do they do the supporting-tx thing?  I haven't really looked at it but one of my guys is saying he's not seeing it
 51 2014-02-15 01:32:03 <gmaxwell> I dunno anything about their details, alas. recieved no info and when I'd looked they'd not actually posted any implementation.
 52 2014-02-15 01:32:19 <etotheipi_> gmaxwell: okay, we'll do more investigation on our side
 53 2014-02-15 01:44:36 <etotheipi_> it also may be the case that the Trezor shield does not accurately represent what the final product will do
 54 2014-02-15 01:48:36 <andytoshi> YabaDabaDoge: what os are you running? can you compile from source?
 55 2014-02-15 01:49:59 <YabaDabaDoge> im in linuix   I don't know what the other guy is running
 56 2014-02-15 01:50:27 <andytoshi> YabaDabaDoge: you said your wallet is displaying a malleated tx, that you want removed?
 57 2014-02-15 01:50:35 <andytoshi> the other guy doesn't matter wrt your own display
 58 2014-02-15 01:50:38 <YabaDabaDoge> the other guy droped out of the channel so I cant help him
 59 2014-02-15 01:51:05 <andytoshi> to get the latest source code you can run
 60 2014-02-15 01:51:07 <andytoshi> git clone https://github.com/bitcoin/bitcoin.git
 61 2014-02-15 01:51:27 <YabaDabaDoge> thx
 62 2014-02-15 01:52:04 <andytoshi> there is a new bitcoind/bitcoin-qt command-line option -zapwallettx which removes all txes and rescans the blockchain to find the confirmed ones
 63 2014-02-15 01:52:21 <andytoshi> note that rescanning is a loong process, a few hours at least
 64 2014-02-15 01:55:27 <skinnkavaj> How long until soft fork?
 65 2014-02-15 01:56:19 <YabaDabaDoge> "a few hours"  O.O      thanks for the info
 66 2014-02-15 01:56:30 <andytoshi> YabaDabaDoge: actually you might not need to rescan at all, bitcoin-qt recognizes conflicted transactions now and should do the right thing
 67 2014-02-15 01:56:42 <andytoshi> (can someone corroborate that? i didn't test what the gui does)
 68 2014-02-15 01:56:48 <YabaDabaDoge> is it working w/ libboost1.53?
 69 2014-02-15 01:58:00 <andytoshi> i'm using 1.54, afaik 1.53 is fine
 70 2014-02-15 01:58:22 <andytoshi> there is a line in the configure file which explicitly says to use 1.53 on ubuntu if 1.54 is not working
 71 2014-02-15 02:00:21 <YabaDabaDoge> yep line 450
 72 2014-02-15 02:00:33 <YabaDabaDoge> good catch
 73 2014-02-15 02:33:19 <nezZario> do testnet block rewards confirm faster?
 74 2014-02-15 02:35:40 <nezZario> does tesetnet block rewards get handed out quicker?
 75 2014-02-15 02:36:09 <freewil> are you asking whether it's easier to mine blocks on testnet?
 76 2014-02-15 02:44:06 <nezZario> hm
 77 2014-02-15 02:44:15 <nezZario> i'm sorry i asked twice earlier
 78 2014-02-15 02:44:36 <nezZario> irssi was scrolled up and I didn't even notice until nothing had changed in a while
 79 2014-02-15 02:44:49 <nezZario> freewil: no, i thought it took 120 blocks to confirm.. is it faster on testnet?
 80 2014-02-15 02:45:06 <Luke-Jr> nezZario: it is 100 blocks, on both testnet and mainnet
 81 2014-02-15 02:45:16 <Luke-Jr> nezZario: testnet is intentionally as few changes from mainnet as reasonable
 82 2014-02-15 02:45:22 <nezZario> gotcha
 83 2014-02-15 02:46:13 <freewil> Luke-Jr: didn't it used to be 120
 84 2014-02-15 02:46:21 <Luke-Jr> no
 85 2014-02-15 02:46:43 <Luke-Jr> bitcoind/-qt enforces 120 artificially, but the network rule has always been 100
 86 2014-02-15 02:46:49 <freewil> ah ok
 87 2014-02-15 02:47:11 <Luke-Jr> miners/relays enforce 101 due to a bug
 88 2014-02-15 02:47:37 <Luke-Jr> (but accept 100 in blocks)
 89 2014-02-15 02:48:31 <freewil> interesting
 90 2014-02-15 02:48:36 <freewil> bitcoind reports "immature" for coinbases < 120 which is what i was thinking
 91 2014-02-15 02:49:18 <nezZario> oh i found a facet, that's good enough
 92 2014-02-15 04:10:15 <BlueMatt> muhoo: Luke-Jr yes, pull-tester briefly did coverage tests, but lcov was buggy as hell so it didnt work
 93 2014-02-15 04:11:00 <BlueMatt> muhoo: dont know what language you want, but some of the best tests you can write in general are the raw hex json stuff in src/test/data
 94 2014-02-15 04:11:48 <BlueMatt> behind that, if you want to write java, working on the bitciondcomparisontool in bitcoinj (which is part of pull-tester's runs) is also useful
 95 2014-02-15 04:12:18 <BlueMatt> its a nice way to do black-box testing of the most important part of bitcoind (the block acceptance stuff)
 96 2014-02-15 04:12:28 <BlueMatt> it also has some basic tx acceptance checks which could be significantly extended
 97 2014-02-15 04:15:27 <BlueMatt> it has missed a lot of bugs over the years, so it needs to be built out, really
 98 2014-02-15 04:15:44 <BlueMatt> but, if you want to write tests that are useful to lots of people, write script/txn tests in src/test/data
 99 2014-02-15 04:30:21 <johnsoft> does bitcoind expose network synchronization progress over RPC anywhere?
100 2014-02-15 04:31:04 <BlueMatt> dunno about direct, but you could getpeerinfo and getinfo and compare block heights
101 2014-02-15 04:31:29 <BlueMatt> and if you try to getblocktemplate and its not synced, you'll get an error
102 2014-02-15 04:32:05 <johnsoft> getpeerinfo sounds perfect, thanks
103 2014-02-15 04:32:28 <BlueMatt> (note that the block counts there are the block counts that the peer had at the time of connection, not now)
104 2014-02-15 04:33:56 <johnsoft> hm, it's still a ballpark number though, i guess it's close enough if there's nothing better
105 2014-02-15 04:34:51 <gmaxwell> johnsoft: there is no real synchronization progress it's always syncing.
106 2014-02-15 04:35:16 <gmaxwell> the gui thing is mostly just based on the date and tx count.
107 2014-02-15 04:39:03 <johnsoft> i guess to be precise i'm after the non-locally-verified block height claimed by each connected peer
108 2014-02-15 04:40:26 <johnsoft> or wherever the number in "processed x of y estimated blocks" comes from
109 2014-02-15 04:50:41 <gmaxwell> IIRC we don't use the local height for display purposes anymore, some jokers were intentionally doing stupid stuff when we did.
110 2014-02-15 04:51:41 <gmaxwell> the words "estimated blocks" don't appear to be in the current codebase.
111 2014-02-15 04:55:02 <johnsoft> oops, yeah, estimated isn't in there.
112 2014-02-15 04:55:14 <johnsoft> this is what i was thinking of http://i.imgur.com/gWUikOb.png
113 2014-02-15 04:56:28 <gmaxwell> oh hmph. indeed, we actually still do have the peer number— gui only.
114 2014-02-15 04:57:36 <denisx> I want to report that RenameThread() does work on FreeBSD
115 2014-02-15 04:57:42 <denisx> can't speak for openbsd though
116 2014-02-15 04:57:57 <johnsoft> guess I'll look into OCR software then
117 2014-02-15 04:58:07 <gmaxwell> johnsoft: OCR software, oh come on.
118 2014-02-15 04:58:11 <johnsoft> just kidding :) but thanks for the help
119 2014-02-15 04:58:36 <gmaxwell> johnsoft: getpeerinfo compute it yourself, keep in mind that the data doesn't update as the software runs, and it's sometimes BS.
120 2014-02-15 04:58:37 <johnsoft> i'll... use blockchain.info, i guess
121 2014-02-15 04:58:47 <gmaxwell> johnsoft: why would you do that?
122 2014-02-15 04:59:07 <gmaxwell> hell I think BC.i is wrong as often as getpeerinfo is. :P
123 2014-02-15 04:59:25 <johnsoft> it's just for an admin dashboard
124 2014-02-15 04:59:29 <gmaxwell> denisx: does it do anything bad or just nothing?
125 2014-02-15 04:59:45 <johnsoft> just a niceity, I've spent too much time on it as it is
126 2014-02-15 04:59:50 <denisx> gmaxwell: I said it DOES work!
127 2014-02-15 04:59:57 <gmaxwell> oh!
128 2014-02-15 05:00:06 <gmaxwell> omg someone reported something working!
129 2014-02-15 05:00:18 <denisx> gmaxwell: it is still commented out until someone reports that it does work
130 2014-02-15 05:00:38 <gmaxwell> johnsoft: yea, well enjoy the support calls when some bozos connect and claimd 6666666 blocks. :P
131 2014-02-15 05:56:48 <Logicwax> wow, insight is awesome
132 2014-02-15 05:56:54 <Logicwax> its like my own personal blockchain.info
133 2014-02-15 05:57:49 <Luke-Jr> not sure if compliment or insult <.<
134 2014-02-15 05:57:59 <Luke-Jr> also, I think insight is like my own personal Tcl/Tk debugger
135 2014-02-15 06:00:15 <Logicwax> huh?
136 2014-02-15 06:00:49 <Logicwax> https://github.com/bitpay/insight
137 2014-02-15 06:00:49 <Logicwax> i meant
138 2014-02-15 06:01:02 <Logicwax> bitpay released it
139 2014-02-15 06:01:05 <Logicwax> very cool
140 2014-02-15 06:01:16 <Logicwax> its like your own local bl.c
141 2014-02-15 06:01:28 <Logicwax> *blockchain.info
142 2014-02-15 06:02:11 <Luke-Jr> https://www.sourceware.org/insight/
143 2014-02-15 06:09:07 <waxwing> if i have two utxos as inputs in a 2 of 3 multisig txn, do i provide 2 signatures for each input, or just 2 signatures overall? i think the former but i've forgotten.
144 2014-02-15 06:11:03 <gmaxwell> the former, the there must be a signature for each input, they are independant.
145 2014-02-15 06:11:24 <waxwing> right thanks, an iirc the order of the sigs has to correspond to the order of the pubkeys in the address, right?
146 2014-02-15 06:11:30 <waxwing> an = and
147 2014-02-15 06:29:23 <Fistful_of_Coins> question about p2pool: could a miner withhold submitting a share that qualifies as a block to the pool, and submit it himself to claim the full reward?
148 2014-02-15 06:33:03 <Luke-Jr> Fistful_of_Coins: of course not
149 2014-02-15 06:36:15 <gmaxwell> waxwing: every input has a single "signature", the inputs and signatures are in the same order. Within a signature for a multisignature scriptpubkey there are internal signatures, and they must— indeed— be in the same order.
150 2014-02-15 06:37:47 <waxwing> gmaxwell, so like if A B C are the pubkeys to set up the msigaddress, then the sigs internally for 1 input have to be A B or A C or B C. Is that it?
151 2014-02-15 06:38:50 <gmaxwell> yes
152 2014-02-15 06:41:52 <waxwing> tks.  would it be possible for input 1 to be signed by A and B and input 2 to be signed by B and C? (Weird idea; just curious)
153 2014-02-15 06:51:01 <gmaxwell> waxwing: it's not weird at all, it's fine.
154 2014-02-15 06:51:30 <waxwing> gmaxwell, ok got it. appreciated.
155 2014-02-15 08:04:59 <anddam> can I list the RPC calls list from running daemon?
156 2014-02-15 08:05:18 <Luke-Jr> that's what the 'help' RPC is for
157 2014-02-15 08:05:31 <anddam> thanks
158 2014-02-15 08:08:42 <anddam> is reindexing time comparable to fetching the blockchain from zero?
159 2014-02-15 08:10:06 <anddam> I applied https://github.com/bitcoin/bitcoin/pull/3652 to master, should I make a blockchain backup before reindexing or will previous version of bitcoin be able to use it as well later?
160 2014-02-15 08:11:30 <jcorgan> hmm, not sure, easy enough for me to check
161 2014-02-15 08:12:10 <anddam> also while reindexing should I specify both flags -addrindex -reindex ?
162 2014-02-15 08:12:46 <jcorgan> yes.  i suggest putting addrindex=1 in your conf file, then you can run -reindex once on the cli but without it otherwise
163 2014-02-15 08:12:48 <anddam> what's -txindex for? Since I'm going with reindex should I specify -txindex too in order to reindex only once?
164 2014-02-15 08:13:23 <jcorgan> yes.  -txindex means to index all the transactions (by txid), and -addrindex (or conf file equivalents) mean to add an index by address as well
165 2014-02-15 08:13:33 <anddam> jcorgan: ok, thanks. What about the backward compatibility? I usually run 0.8.6
166 2014-02-15 08:13:42 <jcorgan> i'm checking that empirically now
167 2014-02-15 08:14:14 <anddam> jcorgan: oh I now realize you're the guy who updated the pull request
168 2014-02-15 08:15:02 <jcorgan> yeah, sipa did original work, blame me for any problems with the forward port
169 2014-02-15 08:15:29 <jcorgan> you're amad3us, right?
170 2014-02-15 08:15:32 <anddam> jcorgan: I slightly edited PR 2802 to work on top of 0.8.6 but main.{cpp,h} were slightly different, do you have a couple minutes to double check the patch and see if there's anything obviously wrong?
171 2014-02-15 08:15:35 <anddam> me?
172 2014-02-15 08:15:37 <anddam> no
173 2014-02-15 08:15:45 <anddam> neverheard, btw
174 2014-02-15 08:15:49 <jcorgan> oh nm
175 2014-02-15 08:16:03 <jcorgan> i can look at it, yes
176 2014-02-15 08:16:04 <anddam> if I were my nick would be "amad3us" :-)
177 2014-02-15 08:16:52 <anddam> again: will adding txindex=1 to conf as well before reindexing save me a reindex cycle?
178 2014-02-15 08:16:58 <anddam> let me upload those
179 2014-02-15 08:17:36 <jcorgan> so, add txindex=1 and addrindex=1 to your conf file
180 2014-02-15 08:17:46 <jcorgan> run bitcoind with -reindex until it is caught up
181 2014-02-15 08:18:03 <jcorgan> then either leave it alone or rerun it without the -reindex
182 2014-02-15 08:18:39 <anddam> how long should I expect it to take?
183 2014-02-15 08:18:48 <anddam> I'm on laptop not connected to power network now
184 2014-02-15 08:18:50 <jcorgan> so far it looks like 0.8.6 stock will open a blockchain database that was made by 0.9-git w/addrindex turned on, no complaints
185 2014-02-15 08:19:09 <jcorgan> depends a lot on your system; single digit hours seems typical
186 2014-02-15 08:19:29 <anddam> I'll wait to be at a desk then
187 2014-02-15 08:19:37 <jcorgan> "macbook air with SSD" was 5 hours by someone here
188 2014-02-15 08:20:02 <Luke-Jr> I would be surprised if 0.8.6 loaded a 0.9 index successfully
189 2014-02-15 08:20:40 <wumpus> Luke-Jr: it will not compain though, at most it will ignore the extra index
190 2014-02-15 08:21:08 <jcorgan> yeah, and if you run it long enough like that, you'd probably want to reindex when you go back to the addrindex patched version
191 2014-02-15 08:21:09 <Luke-Jr> wumpus: due to the pruning of OP_RETURN data carriers, I expect it will complain about "corruption"
192 2014-02-15 08:22:12 <jcorgan> well, no harm in backing up your datadir for safety
193 2014-02-15 08:22:35 <jcorgan> fyi, with both txindex and addrindex the current blockchain+db is 22G
194 2014-02-15 08:22:39 <wumpus> Luke-Jr: ... hmm ... no idea if that has any effect
195 2014-02-15 08:23:28 <wumpus> Luke-Jr: would be a pity if due to that reason it's no longer possible to downgrade to 0.8 without reindexing, we even went as far as patching leveldb for that
196 2014-02-15 08:25:36 <Luke-Jr> 
ACTION thought he mentioned it during that discussion

197 2014-02-15 08:26:23 <jcorgan> so three blocks have arrived while running on a 0.8.6 stock daemon using a datadir that was previously 0.9-git w/addrindex, no complaints logged in the debug.log
198 2014-02-15 08:26:44 <anddam> ouch at 22GB
199 2014-02-15 08:26:46 <anddam> jcorgan: http://trac.macports.org/changeset/117082
200 2014-02-15 08:27:09 <anddam> jcorgan: patch_bitcoin-bitcoin_pull-request_2802.diff is taken from the pull request minus main.cpp and main.h
201 2014-02-15 08:27:19 <anddam> those two I had to split in order to track the changed bits
202 2014-02-15 08:28:13 <anddam> the serialize is apart, it's some 0.8.6 clang idiosyncrasy with redefine, I noticed later on the insert redefine was removed
203 2014-02-15 08:28:50 <anddam> it's not pushed and about what you just wrote I guess it won't be until 0.9.0 tag is released
204 2014-02-15 08:29:46 <anddam> also this sounds wrong: running master bitcoind with -addrindex asks "Do you want to rebuild the block database now?" and the the program exits
205 2014-02-15 08:29:54 <anddam> that line suggests bitcoind should wait for input
206 2014-02-15 08:30:36 <jcorgan> -addrindex is not in the master branch, only in the pull request branch
207 2014-02-15 08:32:28 <jcorgan> it's too hard for me to look at your macports diffs and judge whether there are any issues; i'd apply everything and then post a diff off 0.8.6 that could be reviewed
208 2014-02-15 08:41:18 <wumpus> anddam: yea that message is really meant for the gui, the daemon auto-exits instead of asking
209 2014-02-15 08:42:22 <anddam> there should be a check, I guess with the forecoming separation of bitcoind/bitcoincli/bitcoinqt it'll be handled
210 2014-02-15 08:42:35 <anddam> so now I have the address querying api
211 2014-02-15 08:42:41 <anddam> I just lack the data to query :-)
212 2014-02-15 08:43:51 <wumpus> well the problem here is due to the separation: we don't want the core code to know if this is gui/not gui
213 2014-02-15 08:44:22 <wumpus> you could for example implement the interactive prompt in the daemon with a CLI interface
214 2014-02-15 08:44:29 <wumpus> currently it's not implemented at all :-)
215 2014-02-15 08:53:42 <maaku> a bitcoind REPL would be nice
216 2014-02-15 09:06:08 <anddam> wumpus: why is that about the core code?
217 2014-02-15 09:06:29 <anddam> I'd think that a full separation daemon/gui/cli would be better
218 2014-02-15 09:07:11 <anddam> cli would only wrap RPC, GUI would mantain a state by dealing with RPC as well
219 2014-02-15 09:08:28 <wumpus> anddam: because the query comes from the core code, it is 'broadcasted' as a signal so to say
220 2014-02-15 09:08:58 <wumpus> anddam: the GUI listens to this signal and shows a dialog, the daemon... prints the message, ignores the query and return 0's
221 2014-02-15 09:10:24 <wumpus> for the user it would be more clear to have a different message in the case of the daemon, as it doesn't have interactive prompts, but there is currently no way for the 'ui backend' to say I can do this and this
222 2014-02-15 09:10:47 <wumpus> sure that could be implemented, but there are lots of higher priority issues right now
223 2014-02-15 09:17:07 <wbaw> it would be good to have interactive prompts in the daemon
224 2014-02-15 09:17:35 <wbaw> for encrypting wallets, for example, to avoid leaking sensitive info on the command line
225 2014-02-15 09:18:04 <wumpus> wbaw: but it still has to account for the case in which there is no interactive terminal, for example bitcoind launched from init scripts
226 2014-02-15 09:18:23 <wbaw> at the moment if you encrypt a wallet on the command line in linux the password gets stored in .bash_history
227 2014-02-15 09:18:27 <wbaw> in plain text
228 2014-02-15 09:18:42 <wbaw> it'd only need to be for sensitive stuff
229 2014-02-15 09:19:18 <wumpus> wbaw: you mean that *bitcoin-cli* should have an interactive mode
230 2014-02-15 09:19:36 <wbaw> yes
231 2014-02-15 09:19:57 <wbaw> so it doesn't encourage you to leak wallet passwords mainly
232 2014-02-15 09:20:07 <wumpus> wbaw: see contrib/bitrpc/bitrpc.py in  the source distribution for a basic interactive cli
233 2014-02-15 09:20:24 <wbaw> thanks
234 2014-02-15 09:20:31 <wumpus> wbaw: you can use it to ask for wallet passphrase, for example
235 2014-02-15 09:21:13 <wumpus> I remember someone was working on a more extensive bitcoin cli but I have no idea how that's coming along
236 2014-02-15 09:21:35 <wbaw> something like that should be encouraged & typing the password on the command line disabled
237 2014-02-15 09:22:05 <wbaw> since the command line is usually logged in plain text
238 2014-02-15 09:22:48 <wumpus> you could add a warning in bitcoin-cli when someone provides the wallet passphrase on the command line, then again don't forget that bitcoin-cli is also used from scripts in which you don't want superfluous warnings and prompts
239 2014-02-15 09:23:24 <wbaw> it could read the password from stdin
240 2014-02-15 09:23:54 <wbaw> no point in having a password if it's stored in plain text
241 2014-02-15 09:25:03 <wumpus> sounds like a good idea, feel free to add a -readfromstdin option to bitcoin-cli
242 2014-02-15 09:26:02 <jouke> wbaw: when you put a white space in front of a command, it won't be stored in bash_history
243 2014-02-15 09:26:33 <wbaw> not everybody is going to know that
244 2014-02-15 09:28:33 <wbaw> it should have secure defaults, as much as possible
245 2014-02-15 09:30:49 <anddam>  wbaw | at the moment if you encrypt a wallet on the command line in linux the password gets stored in .bash_history <--  well, if you're using bash
246 2014-02-15 09:31:08 <anddam> you should read password from file anyway
247 2014-02-15 09:31:10 <wbaw> yeah, lots of people do
248 2014-02-15 09:31:30 <anddam> foolish people
249 2014-02-15 09:32:02 <wbaw> you should need to do something really purposefully stupid to leak the wallet password in plain text
250 2014-02-15 09:32:19 <wbaw> it shouldn't be possible by accident
251 2014-02-15 09:36:29 <wbaw> bash isn't the only shell that logs commands
252 2014-02-15 09:41:03 <wumpus> wbaw: should be pretty straightforward to implement, please help the project by submitting a pull request, arguing won't get anything solved :)
253 2014-02-15 09:41:31 <wbaw> i've got other things to do at the moment, it's just a suggestion
254 2014-02-15 09:41:54 <wumpus> a straightforward, sane way would be: if someone uses bitcoin-cli walletpassphrase without argument, ask for it
255 2014-02-15 09:41:56 <wbaw> i might have a look at it over the next week or so, is a pull request on github the correct way?
256 2014-02-15 09:42:18 <wumpus> yes
257 2014-02-15 09:43:08 <wbaw> i'll do that if i get a fix then, but i'm more of a php web dev than c, so, might be better for somebody better to look at it
258 2014-02-15 09:43:49 <wumpus> 'somebody better' will likely have more difficult issues to worry about, so this kind of simple stuff never gets done
259 2014-02-15 09:44:07 <wbaw> possibly, it does seem fairly simple
260 2014-02-15 09:44:26 <wbaw> i'm not just a good c programmer at all, can barely read it
261 2014-02-15 09:44:56 <wbaw> but i'll have a try if i get some free time & nobody else does it first
262 2014-02-15 09:44:58 <wumpus> then learn it, c/c++ is a very good skill to have as programmer, if you can write those languages without shooting yourself in the foot then you can master anything :)
263 2014-02-15 09:46:26 <anddam> I should give C++ a shot, I seriously dislike the syntax
264 2014-02-15 09:47:10 <anddam> but I learned that until you dive in and wait a little to settle in you cannot really judge
265 2014-02-15 09:47:12 <wumpus> yes that adds to the challenge
266 2014-02-15 09:51:28 <wbaw> i think rpcssl should be default on too
267 2014-02-15 09:53:03 <anddam> what should I backup before reindex?
268 2014-02-15 09:53:07 <anddam> reindexing*
269 2014-02-15 09:53:13 <anddam> I see blocks/ is 17GB
270 2014-02-15 09:53:28 <anddam> are chainstate/ and database/ worth backupping?
271 2014-02-15 09:53:33 <wumpus> always backup your wallet :p
272 2014-02-15 09:53:48 <anddam> wallet is backed up
273 2014-02-15 09:53:50 <anddam> and empty atm
274 2014-02-15 09:53:57 <wumpus> apart from that it doesn't make sense to backup anything before indexing
275 2014-02-15 09:53:58 <anddam> (thank you, mtgox)
276 2014-02-15 09:54:30 <anddam> that's due to what I wrote earlier, I'm willing to run 0.8.6 vanilla again later on
277 2014-02-15 09:54:37 <wumpus> (you won't ever lost your blocks due to reindexing, those are only read)
278 2014-02-15 09:54:49 <anddam> nice, I like my blocks
279 2014-02-15 09:54:54 <anddam> like a little tiny minecrafter
280 2014-02-15 09:54:57 <wumpus> hehe
281 2014-02-15 09:57:35 <anddam> txindex=1 addrindex=1 in bitcoin.conf, right?
282 2014-02-15 09:58:21 <anddam> is there a way to see progress in reindexing?
283 2014-02-15 10:00:15 <jcorgan> look at the debug.log, it will tell you the blocks it is processing
284 2014-02-15 10:00:30 <anddam> also is the reindexing CPU or I/O bound?
285 2014-02-15 10:00:38 <jcorgan> but like usual, the last 5% take up 95% of the time, and it is i/o bound
286 2014-02-15 10:01:58 <viajero> !seen sturles
287 2014-02-15 10:01:59 <gribble> sturles was last seen in #bitcoin-dev 2 days, 14 hours, 16 minutes, and 26 seconds ago: <sturles> To move 42 BTC from account a to account b: bitcoind move a b 42
288 2014-02-15 10:08:35 <anddam> jcorgan: thanks again
289 2014-02-15 10:08:50 <anddam> jcorgan: if you get a chance to check that patch drop me a line
290 2014-02-15 10:10:15 <jcorgan> no problem. if you get it working atop 0.8.6 it would worth posting a branch on github.  i doubt it would ever get considered for a pull for 0.8, but i'm sure some people would be interested in it.
291 2014-02-15 10:12:06 <anddam> jcorgan: it's already working, I asked for a double check since I'm not familiar with the codebase and just adapted what was obvious in the patch
292 2014-02-15 10:12:26 <anddam> but I'm running reindex with the 0.8.6 patched now
293 2014-02-15 10:13:26 <jcorgan> cool.  if you publish a branch at least make a comment on #3652 so people know about it.
294 2014-02-15 10:14:20 <anddam> I think it shouldn be added under #2802 with a note in #3652
295 2014-02-15 10:14:27 <anddam> since the .diff if from the former
296 2014-02-15 10:14:31 <anddam> 2014-02-15 10:13:24 ProcessBlock: ACCEPTED
297 2014-02-15 10:14:33 <anddam> 2014-02-15 10:13:24 SetBestChain: new best=000000000000033da037aa6b3305a44d6821f7e83aaf4916b26b94bd96577336  height=155885  log2_work=67.281196  tx=1963676  date=2011-12-03 16:17:08 progress=0.024466
298 2014-02-15 10:14:35 <jcorgan> make sense
299 2014-02-15 10:14:58 <anddam> sounds fair, the macbookpro is ready to lift off, according to the fan noise
300 2014-02-15 10:16:32 <jcorgan> ah, CPU waste heat, your personal contribution to the eventual heat death of the universe :)
301 2014-02-15 10:17:34 <anddam> Entropy is a bitch
302 2014-02-15 10:17:54 <jcorgan> but not a cold one :)
303 2014-02-15 10:20:58 <chairman_meow> hello
304 2014-02-15 10:21:10 <chairman_meow> did the recent "bug" require a hard fork?
305 2014-02-15 10:22:05 <jcorgan> of course not
306 2014-02-15 10:22:37 <chairman_meow> what was the bug about?
307 2014-02-15 10:22:53 <jcorgan> i don't know, you brought it up
308 2014-02-15 10:22:55 <anddam> chairman_meow: you mean the Mtgox thing?
309 2014-02-15 10:23:09 <chairman_meow> i read a news title
310 2014-02-15 10:23:18 <anddam> chairman_meow: or the DDoS-I-didnt-understand-what-it-was thing?
311 2014-02-15 10:23:31 <chairman_meow> a recent bug that caused theft of millions worth of theft
312 2014-02-15 10:23:44 <anddam> chairman_meow: better you link the article
313 2014-02-15 10:23:52 <wbaw> sr2?
314 2014-02-15 10:24:01 <anddam> chairman_meow: that doesn't make much sense
315 2014-02-15 10:24:05 <jcorgan> there was a DOS that exploited an well-known and documented edge case in bitcoin that some sites didn't account for properly
316 2014-02-15 10:24:14 <anddam> I mean said that way it didn't even regard bitcoin
317 2014-02-15 10:24:39 <jcorgan> thos sites are fixing their software
318 2014-02-15 10:24:57 <wbaw> there was a story about silk road 2 getting robbed, not sure how true it is
319 2014-02-15 10:25:01 <chairman_meow> i believe I read the words "transaction malleability"
320 2014-02-15 10:25:02 <anddam> jcorgan: my point in searching for address was exactly to look for mtgox double payments
321 2014-02-15 10:25:10 <anddam> wbaw: that's lollish
322 2014-02-15 10:25:31 <jcorgan> wbaw: the SR2 thing was more likely a case of self-hack using the network issues as a convenient cover
323 2014-02-15 10:25:37 <wbaw> yeah, i think so too
324 2014-02-15 10:25:42 <jcorgan> but there is no way to really know
325 2014-02-15 10:25:59 <wbaw> but it's the only story of a big 'theft' i've seen
326 2014-02-15 10:26:02 <chairman_meow> http://www.vcpost.com/articles/21639/20140214/protocol-flaw-exchange-shutdown-and-2-7m-heist-prompt-speculations-about-end-of-bitcoin.htm
327 2014-02-15 10:26:53 <jcorgan> don't believe everything you read
328 2014-02-15 10:27:21 <chairman_meow> so what is it really about? a bug in the exchange?
329 2014-02-15 10:27:41 <wbaw> silk road 2 is a blackmarket drug exchange
330 2014-02-15 10:27:49 <wbaw> they're probably lying
331 2014-02-15 10:28:47 <TZander> did this channel turn into #bitcoin ?
332 2014-02-15 10:29:08 <jcorgan> mtgox, in designing their own exchange software, failed to take into account something already understood about bitcoin ("transaction malleability"), which resulted in the ability for customers to make withdrawals that their accounting system didn't see correctly.  Then they compounded the error by issuing automatic retransmissions of those withdrawals in a way that allowed them to get exploited over and over again.
333 2014-02-15 10:29:17 <chairman_meow> sorry, i was asking for a technical explanation of the "bug"
334 2014-02-15 10:30:01 <jcorgan> yeah, this conversation could happen in #bitcoin
335 2014-02-15 10:37:01 <sipa> wumpus: yeah, the corruption check may fail in 0.8.6 when loading a 0.9 blockchain, if there has been a recent prunable output
336 2014-02-15 11:27:07 <murr4y> hi all, it looks like bitcoin-qt is sending 3 addr-messages after receiving getaddr. is that expected behaviour? the wiki docs says "The response to receiving this message is to transmit an addr message" which leads me to believe only one should be sent
337 2014-02-15 11:39:15 <wumpus> murr4y: it can send more addr messages
338 2014-02-15 11:39:26 <wumpus> murr4y: for example if there are more than 1000 addresses to report
339 2014-02-15 11:46:42 <_syslog> salut,
340 2014-02-15 11:50:01 <_syslog> 1- received ( my wallet addresses, the address which i get coin )
341 2014-02-15 11:50:01 <_syslog> 2- send addresses  ( the addresses which i send coin )
342 2014-02-15 11:50:01 <_syslog> i'm exploring bitcoin rpc calls.  ( listreceivedbyaddress )   how should i use to get
343 2014-02-15 11:50:35 <sipa> listreceivedbyaddress will tell you for each receive address how much you've received on it
344 2014-02-15 11:50:45 <sipa> it doesn't do anything wrt sends
345 2014-02-15 11:51:08 <sipa> getnewaddress will give you a new address (of yours, so to receive with)
346 2014-02-15 11:51:30 <sipa> getting a new send address: having someone else ask you to send money there
347 2014-02-15 11:52:12 <_syslog> i don't want to get new address, i want to lsit my address which i already have. ( like listaccounts call )
348 2014-02-15 11:52:38 <_syslog> *listaccounts doesn't shows wallet address, it only shows account.
349 2014-02-15 11:54:31 <sipa> getaddressesbyaccount
350 2014-02-15 11:55:48 <_syslog> it requires an account and returns only address with that account, it doesn't list all accounts on wallet.
351 2014-02-15 11:56:22 <_syslog> *address not account
352 2014-02-15 11:56:29 <_syslog> *sorry for wrong english
353 2014-02-15 11:59:05 <murr4y> wumpus: i see, thanks - i think that should be mentioned in the wiki :)
354 2014-02-15 12:00:57 <sipa> _syslog: if you're not using accounts, all addresses are assigned to the '' account
355 2014-02-15 12:01:18 <sipa> may i ask why you need to know all your addresses?
356 2014-02-15 12:03:01 <_syslog> i'm developing a multi wallet ( opensource ),  let me send you a screen shot
357 2014-02-15 12:04:17 <_syslog> http://s28.postimg.org/6xha8bm70/scp.jpg
358 2014-02-15 12:04:50 <wumpus> murr4y: yes, please fix the wiki
359 2014-02-15 12:05:15 <_syslog> in receive tab i want to list all bitcoin receiver address, and address book tab i want to show all other addresss
360 2014-02-15 12:16:30 <ikbenwouter> ;;seen amantonop
361 2014-02-15 12:16:31 <gribble> amantonop was last seen in #bitcoin-dev 3 days, 20 hours, 37 minutes, and 58 seconds ago: <amantonop> skype:aantonop
362 2014-02-15 12:28:15 <venzen> i'm trying to understand the occurence whereby a send transaction and a mutated version of the same transaction (ie txid has been changed) both exist on the network at the same time... which will be given preference to be included in a block and what happens if the same (miner) node sees the original and later the mutant - does it even know?
363 2014-02-15 12:30:06 <sipa> venzen: from the point of view of the network, it's just a double spend
364 2014-02-15 12:30:14 <sipa> which means that nodes will only accept the first one they see
365 2014-02-15 12:30:28 <sipa> and ignore the second one
366 2014-02-15 12:32:46 <venzen> sipa: so if the muant was seen first it will become the tx to go in the blockchain and get confirmed again and again?
367 2014-02-15 12:32:54 <venzen> *mtuant
368 2014-02-15 12:33:02 <venzen> **mutant :)
369 2014-02-15 12:37:17 <sipa> venzen: maybe
370 2014-02-15 12:37:22 <sipa> venzen: miner's discretion
371 2014-02-15 12:37:33 <sipa> they may dislike the mutant for other reasons
372 2014-02-15 12:37:56 <sipa> but the mutant may end up in the block chain, yes
373 2014-02-15 12:38:47 <venzen> ok, it's not guaranteed, but this occurred sometimes  with some custom wallets, in that the original txid never got confirmed and hence payment may have been sent again?
374 2014-02-15 12:39:43 <venzen> i think that's the nutshell of the recent TM scare...
375 2014-02-15 12:39:55 <sipa> you are right, except the 'hence'
376 2014-02-15 12:40:40 <sipa> if you resend because the original never confirms, you should at least make it a double spend, so not both can confirm
377 2014-02-15 12:42:24 <venzen> sipa, i see what you mean... IF the custom wallet used only txid to verify confirmation it could have been fooled
378 2014-02-15 12:42:37 <sipa> venzen: it should still see the mutant too
379 2014-02-15 12:42:56 <sipa> and even if it doesn't do that, if you reissue a payment because the original one doesn't confirm, make it a double spend
380 2014-02-15 12:43:04 <sipa> otherwise you still risk that both confirm
381 2014-02-15 12:43:10 <sipa> (regardless of malleability)
382 2014-02-15 12:43:41 <venzen> so if it looked for it, it would see the mutant in the blockchain?
383 2014-02-15 12:44:06 <sipa> normal wallet software tracks whatever transactions affect your balance
384 2014-02-15 12:44:10 <sipa> whether you sent them or not
385 2014-02-15 12:47:05 <venzen> sipa, thanks for taking the time to explain - i have not been able to follow (and form a complete picture) of everything that happened here this week...
386 2014-02-15 12:48:11 <venzen> i imagine the message is now clear to all stakeholders that tx outputs should be considered (besides only txid)
387 2014-02-15 12:48:42 <venzen> *should be considered -> should be used as verification
388 2014-02-15 12:48:53 <sipa> inputs, reallt
389 2014-02-15 12:49:07 <venzen> oh
390 2014-02-15 12:49:32 <sipa> it's the inputs that are signed by the sender
391 2014-02-15 12:49:35 <sipa> nobody can change those
392 2014-02-15 12:50:03 <venzen> time, amount, address (being sent to) are defined as inputs?
393 2014-02-15 12:50:35 <sipa> no
394 2014-02-15 12:50:44 <sipa> the previous outputs you're spending
395 2014-02-15 12:51:50 <venzen> right... and so where do the previous outputs come from, sipa?
396 2014-02-15 12:52:00 <sipa> ?
397 2014-02-15 12:52:08 <sipa> the sender's money
398 2014-02-15 12:53:39 <sipa> transactions consist of inputs and outputs: outputs create new coins, inputs consume coins created by previous transactions
399 2014-02-15 12:53:52 <sipa> it's those inputs that are signed, to prove ownership
400 2014-02-15 12:54:09 <sipa> the signatures can be modified, but not what is actually being spent
401 2014-02-15 12:58:23 <venzen> sipa, thanks for explaining
402 2014-02-15 15:24:57 <SeksiCKret> oh btw facists
403 2014-02-15 16:22:58 <anddam> jcorgan, wumpus:processing april '13 now
404 2014-02-15 16:23:24 <jcorgan> lol
405 2014-02-15 16:23:39 <anddam> I had to stop the job :-)
406 2014-02-15 16:42:28 <jcorgan> anddam: you could try moving the chainstate directory to a tmpfs or ramdisk and symlink it back to your datadir
407 2014-02-15 16:44:43 <sipa> ... just increase your database cache instead
408 2014-02-15 16:44:54 <sipa> that will have a much larger effect during reindex
409 2014-02-15 17:01:10 <jcorgan> sipa: you keep saying that and I keep forgetting that you have :)
410 2014-02-15 17:01:28 <jcorgan> is that a cli option?
411 2014-02-15 17:05:01 <anddam> can reindexing be interrupted?
412 2014-02-15 17:05:50 <anddam>  -dbcache=N
413 2014-02-15 17:06:09 <jcorgan> i don't think it can be, without it starting over
414 2014-02-15 17:06:13 <anddam> sipa: I think this guy knows better than you http://bitcoin.stackexchange.com/a/3331
415 2014-02-15 17:06:23 <anddam> (yes, I know)
416 2014-02-15 17:06:47 <anddam> jcorgan: start over is fine, I fear corruption
417 2014-02-15 17:07:17 <anddam> jcorgan: also it processed only up to 20130512 now
418 2014-02-15 17:07:34 <anddam> so about a month in 40 minutes
419 2014-02-15 17:07:52 <jcorgan> ouch
420 2014-02-15 17:08:22 <anddam> not a big deal, the CPU is not very busy so it's just running there
421 2014-02-15 17:08:48 <anddam> I did this in order to check those mtgox transaction, I'd like to figure some "suspect" for double payments
422 2014-02-15 17:09:06 <anddam> but I only have http://mtgox.com/api/0/bitcoin_tx.php
423 2014-02-15 17:09:36 <anddam> couldn't find historical data yet, that's a job for reddit, I suppose
424 2014-02-15 17:29:59 <maaku> <anddam> sipa: I think this guy knows better than you http://bitcoin.stackexchange.com/a/3331 <--- was that a joke?
425 2014-02-15 17:30:30 <copumpkin> lol
426 2014-02-15 17:42:34 <anddam> maaku: yes, as I wrote in the following line
427 2014-02-15 17:42:52 <maaku> ah
428 2014-02-15 17:48:18 <v_y> has mtgox given examples of mutated transactions?
429 2014-02-15 17:53:36 <andytoshi> v_y: https://gist.github.com/sipa/8907691 is how txes are mutated, i think (5) is mostly what we've seen
430 2014-02-15 17:54:36 <v_y> andytoshi: the OP_PUSHDATA2 appear on february 9th. mtgox announced they had been attacked on february 7th.
431 2014-02-15 17:54:52 <v_y> andytoshi: http://www.righto.com/2014/02/the-bitcoin-malleability-attack-hour-by.html
432 2014-02-15 17:55:09 <andytoshi> oh, the gox changes were (2), gox was encoding the sigs wrong in the first place and people were fixing them
433 2014-02-15 17:56:32 <v_y> ah ok
434 2014-02-15 17:56:38 <v_y> do you have a source on that?
435 2014-02-15 17:57:44 <andytoshi> hmm, don't have any links. but a lot of the weirdly-signed txes got into the blockchain, there is evidence out there
436 2014-02-15 17:57:55 <andytoshi> somebody else might have a better answer
437 2014-02-15 17:59:25 <maaku> i pushed a normative transaction ID branch which uses base-32 encoding and error correction codes : https://github.com/maaku/bitcoin/tree/normtxid
438 2014-02-15 18:00:51 <maaku> it includes a general mechanisn for boiling the uint<n> classes down to an ECC-protected base-32 code
439 2014-02-15 18:02:28 <maaku> so it might also be useful for serializing e.g. private keys, where the extra bits of the encoding can be used to indicate encryption or pubkey compression
440 2014-02-15 18:05:38 <sipa> jcorgan, anddam: yes, -reindex can be interrupted; just kill it, and restart (without -reindex the second time, otherwise you'll start over)
441 2014-02-15 18:07:12 <sipa> andytoshi: correct; mtgox changes were (2), the attack is (5)
442 2014-02-15 18:10:03 <jcorgan> -dbcache=1000 FTW, already at 50% reindexing after 40 minutes
443 2014-02-15 18:11:16 <anddam> sipa: the daemon recognize it has to complete the previous, incomplete indexing?
444 2014-02-15 18:11:25 <anddam> does the daemon*
445 2014-02-15 18:12:27 <sipa> anddam: yes
446 2014-02-15 18:12:48 <sipa> it stores a flag in the database "reindexing busy
447 2014-02-15 18:12:57 <sipa> and if that is present at startup, it continues
448 2014-02-15 18:13:47 <anddam> sipa: default db cache is 25 MB, what size should I put for a sensible boost?
449 2014-02-15 18:13:56 <sipa> as much as you can spare
450 2014-02-15 18:14:02 <sipa> the default is 120 iirc
451 2014-02-15 18:14:06 <anddam> and we're talking RAM here?
452 2014-02-15 18:14:08 <sipa> yes
453 2014-02-15 18:14:20 <sipa> over 1 GB doesn't help much anymore
454 2014-02-15 18:14:40 <sipa> on a 32-bit system, don't go over 2 GB
455 2014-02-15 18:14:51 <anddam> what the hell, I got 8GB and only chrome and a terminal emulator running
456 2014-02-15 18:15:07 <anddam> so I'm going with -dbcache=1000
457 2014-02-15 18:15:16 <anddam> the unit is MB, I understand
458 2014-02-15 18:15:32 <sipa> oh, the default is indeed 25 MB
459 2014-02-15 18:15:35 <sipa> we should change that
460 2014-02-15 18:15:43 <anddam> I took that from your SO answer
461 2014-02-15 18:15:59 <sipa> that's really outdated :)
462 2014-02-15 18:16:19 <sipa> we don't even use a cache for BDB anymore, and the database of that time was completely replaced by leveldb
463 2014-02-15 18:17:36 <anddam> is the debug log UTC?
464 2014-02-15 18:17:49 <anddam> I see it's a hour off with respect to my locale
465 2014-02-15 18:18:03 <sipa> yes
466 2014-02-15 18:18:16 <anddam> I guess it'd be better to append Z to it then
467 2014-02-15 18:19:00 <anddam> to make it self-explanatory
468 2014-02-15 18:19:14 <anddam> can I import a private key while reindexing?
469 2014-02-15 18:19:25 <sipa> i believe so
470 2014-02-15 18:20:06 <anddam> is the term "sathosi" subject to nominal inflection?
471 2014-02-15 18:20:24 <anddam> one sathosi, two satoshi   or   one satoshi, two satoshis ?
472 2014-02-15 18:20:24 <sipa> no idea, never heard about it
473 2014-02-15 18:20:29 <sipa> ah!
474 2014-02-15 18:20:33 <sipa> no idea
475 2014-02-15 18:20:50 <anddam> …you should have heard satoshi…
476 2014-02-15 18:20:50 <lnovy> I would say, both are legal
477 2014-02-15 18:21:20 <sipa> i have heard about satoshi, not about sathosi :)
478 2014-02-15 18:21:36 <anddam> I stand corrected
479 2014-02-15 18:21:38 <lnovy> :D
480 2014-02-15 18:21:40 <anddam> (typo)
481 2014-02-15 18:21:54 <sipa> yeah, i was just making fun of it, sorry :)
482 2014-02-15 18:21:58 <anddam> more often than not I switch to letters in a word
483 2014-02-15 18:22:30 <anddam> I call it "digital lapsus", with the double entendre
484 2014-02-15 18:22:35 <anddam> switch two letters*
485 2014-02-15 18:22:51 <anddam> and the "to letters" was just a typo
486 2014-02-15 18:23:48 <lnovy> most people on bitcointalk tends to use satoshis I think..
487 2014-02-15 18:24:59 <anddam> but I wouldn't use btctalk as reference for anything
488 2014-02-15 18:25:11 <anddam> the place is a mess
489 2014-02-15 18:25:37 <lnovy> googlefight is useless here i guess
490 2014-02-15 18:26:27 <anddam> sipa: I'm not sure I can see an increase in speed with 1 GiB dbcache, I think it processed 201307 very quickly but I may just have been distracted
491 2014-02-15 18:26:32 <anddam> now I'm looking at the 201308 output and it doesn't seem noticeably faster
492 2014-02-15 18:26:56 <sipa> "the 201308 output" ?
493 2014-02-15 18:27:21 <sipa> what output are you talking about?
494 2014-02-15 18:27:30 <anddam> I'm looking at the debug output and there are messages saying   "2014-02-15 18:27:15 SetBestChain: new best=000000000000004f16229625c1b1e43c0fac1de1c508348be83727e6c1a11c37  height=250850  log2_work=71.092527  tx=21726580  date=2013-08-08 05:45:17 progress=0.282906"