1 2013-02-10 00:01:09 <JWU42> crappy routing to both unfortunately
  2 2013-02-10 00:01:55 <JWU42> latter is best it seems
  3 2013-02-10 00:02:46 <jgarzik> 2013-02-09 19:38:24,240\tmerkleMaker\tWARNING\tChange from height 220419->220421; no longpoll merkleroots available!
  4 2013-02-10 00:02:49 <jgarzik> small reorg
  5 2013-02-10 00:02:50 <jgarzik> ?
  6 2013-02-10 00:11:12 <Luke-Jr> jgarzik: it premakes merkleroots for the next block
  7 2013-02-10 00:55:45 <gladoscc> How do I get the total balance of all accounts, and the actual balance on server?
  8 2013-02-10 00:56:05 <gladoscc> I'm trying to do a cold store system and I need to know how much BTC is on the wallet, and how much btc is in all accounts.
  9 2013-02-10 00:56:15 <jgarzik> gladoscc: 'getinfo' gives you the total balance of all coins.
 10 2013-02-10 00:56:33 <jgarzik> gladoscc: total of all accounts must be performed by summing all accounts
 11 2013-02-10 00:56:43 <gladoscc> jgarzik: hmm
 12 2013-02-10 00:58:05 <gladoscc> but since at the start, total balance should be balance of all accounts
 13 2013-02-10 00:58:18 <gladoscc> could I use an account to keep track of "coins not on server"?
 14 2013-02-10 00:59:27 <JWU42> gladoscc: you can do a watch only wallet on blockchain.info
 15 2013-02-10 00:59:44 <JWU42> just add the addresses
 16 2013-02-10 01:00:04 <gladoscc> nah, not using blockchain.info, down a lot
 17 2013-02-10 01:00:15 <gladoscc> I guess I'll just store it in the DB
 18 2013-02-10 01:00:41 <gmaxwell> JWU42: by doing that you expose yourself to the systemic risk of inaccuracy or compromise of the centralized service??? so be mindful of that.
 19 2013-02-10 01:01:02 <JWU42> watch only address - how does that matter?
 20 2013-02-10 01:01:33 <gladoscc> gmaxwell: yeah, another reason why I don't like relying on blockchain.info
 21 2013-02-10 01:01:40 <JWU42> and yes - I probably need to rethink the % of my BTC with piuk
 22 2013-02-10 01:02:29 <gmaxwell> JWU42: it depends on what you're going to be doing with them. If you're watching to tell if someone has paid you??? for example, there is a vulnerability.
 23 2013-02-10 01:03:09 <JWU42> I thought he was just looking for a way to have a consolidated view of his BTC balance
 24 2013-02-10 01:03:55 <gmaxwell> Yes. And?
 25 2013-02-10 01:03:55 <JWU42> otherwise would need to import all the private keys into one wallet?
 26 2013-02-10 01:04:26 <JWU42> then it isn;t "cold storage"
 27 2013-02-10 01:04:30 <gladoscc> gmaxwell: is this a good way to do an automated cold store system?
 28 2013-02-10 01:04:52 <gladoscc> wait, I can't count hot wallet refills
 29 2013-02-10 01:04:55 <JWU42> as i understand it
 30 2013-02-10 01:05:15 <gmaxwell> gladoscc: I just have an online copy of an offline wallet, which is encrypted with a totally random key.
 31 2013-02-10 01:06:00 <JWU42> 
ACTION tries to wrap his head around that one

 32 2013-02-10 01:06:23 <gladoscc> gmaxwell: I'm doing the cold store for an online service
 33 2013-02-10 01:06:34 <gladoscc> Like, every 10 minutes it sends 90% of total balance to the cold store address.
 34 2013-02-10 01:07:17 <JWU42> 
ACTION shuts up and watches with interest

 35 2013-02-10 01:07:24 <Luke-Jr> gladoscc: fail
 36 2013-02-10 01:07:59 <gladoscc> Luke-Jr: what do you mean
 37 2013-02-10 01:08:02 <Luke-Jr> gladoscc: don't resend it, then there's a risk
 38 2013-02-10 01:08:04 <JWU42> helpful comment there Luke-Jr ;)
 39 2013-02-10 01:08:09 <Luke-Jr> gladoscc: just have customers send direct to the offline wallet
 40 2013-02-10 01:08:22 <JWU42> 
ACTION nods

 41 2013-02-10 01:08:56 <JWU42> so we return to the "how to get the balance of th cold store"
 42 2013-02-10 01:09:05 <JWU42> ?
 43 2013-02-10 01:09:14 <gladoscc> yeah, but my service is like instawallet
 44 2013-02-10 01:09:15 <gmaxwell> gladoscc: Luke's commentary there is good though... the bounce through thing is not a grand idea.
 45 2013-02-10 01:09:24 <gladoscc> so a portion of the coins need to be on the server so people can spend it!
 46 2013-02-10 01:10:17 <gladoscc> can I do a bitcoind lookup of "transactions sent to X address"?
 47 2013-02-10 01:10:19 <Luke-Jr> hmm
 48 2013-02-10 01:10:27 <Luke-Jr> gladoscc: not currently
 49 2013-02-10 01:10:29 <gmaxwell> sure, so keep some coin on the server... and have deposits go offline. Then as coins are needed online move them there.
 50 2013-02-10 01:10:55 <benkay> Luke-Jr: how does blockchain.info track deposits to addresses?
 51 2013-02-10 01:11:00 <Luke-Jr> benkay: custom code
 52 2013-02-10 01:11:09 <benkay> 
ACTION facepalms

 53 2013-02-10 01:11:21 <gladoscc> gmaxwell: then I still need to keep track of transactions to addresses
 54 2013-02-10 01:11:26 <gladoscc> so I can credit deposits.
 55 2013-02-10 01:11:46 <gmaxwell> Sure.
 56 2013-02-10 01:11:54 <gmaxwell> benkay: whats the facepalm for?
 57 2013-02-10 01:12:12 <benkay> i should have known that
 58 2013-02-10 01:12:16 <Luke-Jr> gladoscc: you can scan every block with -blocknotify
 59 2013-02-10 01:19:25 <Luke-Jr> gladoscc: or perhaps try out Armory
 60 2013-02-10 01:19:38 <Luke-Jr> gladoscc: I *think* it has working deterministic wallets and watch-only wallets
 61 2013-02-10 01:59:49 <JWU42> for some reson I thought 0.8 used a smaller (total file size) blockchain
 62 2013-02-10 01:59:55 <JWU42> with a new DB of some sort
 63 2013-02-10 02:00:32 <kjj> the bulk of the old block files were blocks.  not much savings available
 64 2013-02-10 02:09:18 <JWU42> yeah
 65 2013-02-10 02:09:24 <JWU42> I see the files are all smaller
 66 2013-02-10 02:09:33 <JWU42> but total is still ~ 6GB
 67 2013-02-10 02:11:13 <Luke-Jr> JWU42: reducing the blockchain size was not a goal for 0.8
 68 2013-02-10 02:11:39 <Luke-Jr> JWU42: ultraprune (which you're likely thinking of) is about the UTXO set, which improves *performance*
 69 2013-02-10 02:12:14 <Luke-Jr> JWU42: the codebase *is* pretty close to one where you can outright delete blk0*.dat with some minimal hacking, though
 70 2013-02-10 02:15:50 <gmaxwell> Luke-Jr: yea, until there is a reorg and your node dies forever. or until you try to gettransaction on something, or a peer reuests a block from you.. :P
 71 2013-02-10 02:17:22 <Luke-Jr> gmaxwell: I did say minimal hacking
 72 2013-02-10 02:17:38 <Luke-Jr> gmaxwell: the undo files don't have enough to handle a reorg on their own?
 73 2013-02-10 02:18:24 <gmaxwell> Correct.
 74 2013-02-10 02:19:10 <Luke-Jr> well that sucks :p
 75 2013-02-10 02:19:28 <Luke-Jr> 
ACTION wonders what the block files could have that is missing from undos

 76 2013-02-10 02:28:03 <coingenuity> petertodd: Luke-Jr: nope, wasn't me, i actually know next to nothing about mixing
 77 2013-02-10 02:29:17 <Luke-Jr> oh, maybe it was copumpkin after all then :/
 78 2013-02-10 02:29:21 <Luke-Jr> co* someone XD
 79 2013-02-10 02:29:32 <coingenuity> heh
 80 2013-02-10 04:09:55 <MC1984> wowser i wake up and bitcoin is using 550mb ram for its sync
 81 2013-02-10 04:10:02 <MC1984> is it supposed to do that
 82 2013-02-10 04:10:24 <MC1984> looks like it went dog slow all night because it went into swap :\\
 83 2013-02-10 04:28:34 <phantomcircuit> MC1984, during initial sync that sounds about right
 84 2013-02-10 04:30:19 <MC1984> i tought it wasnt supposed to do that unless you play ith the dbcache
 85 2013-02-10 05:00:55 <weex> MC1984: daily txns have grown recently too
 86 2013-02-10 05:45:19 <muhoo> yesss... the dice effect
 87 2013-02-10 08:56:19 <Raccoon> Seriously, the progress bar UI hasn't been updated yet to approximate progress by transaction count or block size?
 88 2013-02-10 08:56:49 <Raccoon> I really thought that would have been tackled a year ago
 89 2013-02-10 08:57:31 <Raccoon> 100% of new users think that the bitcoin client has "locked up" once it reaches 80%
 90 2013-02-10 08:58:34 <Raccoon> gavinandresen: what gives?
 91 2013-02-10 09:01:35 <midnightmagic> :-P
 92 2013-02-10 09:01:45 <midnightmagic> i imagine patches are welcome
 93 2013-02-10 09:06:32 <jgarzik> Raccoon: "100% of new users"... seems like a dubious claim ;p
 94 2013-02-10 09:06:53 <Raccoon> can't be helped.  it is what it is. :)
 95 2013-02-10 09:07:57 <Scrat> wouldnt that require a way to get the blockchain size from the network?
 96 2013-02-10 09:08:24 <Raccoon> isn't it?
 97 2013-02-10 09:09:29 <Raccoon> it also seems reasonable that the client should attempt a full download up front so it can grind away while disconnected from the internet.
 98 2013-02-10 09:11:41 <Raccoon> Also seems reasonable that, since any bitcoin client itself relies a bit on trust (eg, trust that the epoc date is correct, and other such measurments) that the client should also have written into code the SHA512 hashes of each month of block data, so all this grinding can go away.
 99 2013-02-10 09:12:31 <Raccoon> just a quick hash of the chain would be all that's necessary for a new client install.
100 2013-02-10 09:12:51 <Scrat> there are checkpoints
101 2013-02-10 09:13:05 <Raccoon> there are no checkpoints
102 2013-02-10 09:13:24 <Raccoon> at least none that eliminate grinding
103 2013-02-10 09:15:45 <Scrat> what do you mean by grinding
104 2013-02-10 09:16:24 <Raccoon> where the client inspects each and every transaction since day 1 by hashing and testing each block or match
105 2013-02-10 09:16:26 <Raccoon> *for
106 2013-02-10 09:17:00 <Scrat> so you're arguing for lite nodes
107 2013-02-10 09:17:09 <Raccoon> yes and no.
108 2013-02-10 09:17:28 <Raccoon> the idea behind lite nodes is more of a remote cloud-based solution.
109 2013-02-10 09:17:51 <Raccoon> where the client doesn't retain the blockchain itself
110 2013-02-10 09:18:06 <Raccoon> i'm not suggesting that at all
111 2013-02-10 09:19:48 <Raccoon> i'm suggesting that the bitcoin code can have an array of checkpoints, which can be verified against a hundred trusted websites, and all the client has to do is quick hash a huge glob of blocks as one bundle.  Super Blocks
112 2013-02-10 09:20:54 <jgarzik> Raccoon: Oh, you weren't joking?  "100% of new users think that the bitcoin client has "locked up" once it reaches 80%" is a false claim, based on positive reports in the 0.8 rc1 testing threads.
113 2013-02-10 09:21:34 <jgarzik> Plus it seems self-evident that you are unlikely to be receiving reports from all new bitcoin users.
114 2013-02-10 09:22:23 <Raccoon> jgarzik: people who participate in testing threads are unlikely to be "new users".
115 2013-02-10 09:22:53 <Raccoon> "Bitcoin -- This is not your grandma's coin"
116 2013-02-10 09:24:10 <Raccoon> But yeah, my neighbors asked me why it locked up.  The expected by the rate of progress that they could turn off their computer before going to bed.
117 2013-02-10 09:24:20 <Raccoon> *They expected
118 2013-02-10 09:27:11 <Raccoon> I suggest every 4383 blocks be bundled as a "super block", SHA512 hashed, hash gets hard-coded into the client, and the hash list shared on sites like bitcoin.org, mtgox and blockexplorer
119 2013-02-10 09:28:10 <Raccoon> 4383 is the average number of blocks per month, considering 365.25 days a year, or 30.4375 days in a month.
120 2013-02-10 09:28:58 <Scrat> Raccoon: I dont see how that would make verification faster
121 2013-02-10 09:29:03 <Raccoon> Which works out with how the client calculates bounty every 4 years
122 2013-02-10 09:29:21 <Raccoon> Scrat: right now verification is slow because of harddrive seek times.
123 2013-02-10 09:30:02 <Raccoon> Scrat: The harddrive constantly reads small chunks at a time and verifies each little chunk.
124 2013-02-10 09:30:48 <Raccoon> Scrat: What it should be doing is loading a hundred megs into ram, then do a single SHA512 hash over the whole glob of data
125 2013-02-10 09:31:34 <Raccoon> (not literally 100 megs at once, but you get the idea)
126 2013-02-10 10:18:50 <Eliel> Raccoon: I don't understand your complaint. 0.8 rc1 definitely shows the number of blocks left rather than a percentage.
127 2013-02-10 10:20:05 <Eliel> although, granted, it'd make it much easier to estimate how much time it'll take if it showed the total transaction count instead.
128 2013-02-10 10:43:20 <Raccoon> Eliel: That's what I'm saying.  It -only- shows number of blocks left.  It has done this since at least 0.3
129 2013-02-10 10:43:46 <Raccoon> What it doesn't show is number of transactions, bytes, or appearance of time left.
130 2013-02-10 10:44:41 <Eliel> but accomplishing what you're asking would require at least a big reorganization of the code, possibly even a rewrite.
131 2013-02-10 10:46:14 <Eliel> the code that needs this overhaul to implement what you want is the most critical part of Bitcoin. Thus extreme care is needed when modifying it.
132 2013-02-10 10:48:24 <Raccoon> You're suggesting a protocol rewrite?
133 2013-02-10 11:06:49 <wumpus> running a full node is just not for everyone
134 2013-02-10 11:08:02 <wumpus> the problem for most users with running a full node is not at all that it's unclear how long they have to wait, but that they have to wait before the chain is downloaded before they can play at all
135 2013-02-10 11:14:52 <MC1984> just make a transparent SPV>full transition
136 2013-02-10 11:14:59 <MC1984> no more waiting like a chump
137 2013-02-10 11:15:08 <wumpus> discussing whether the progress bar should show transactions, bytes, or time left is just besides the point, it's bikeshedding, people that decide to run a full node should be aware it takes a while to jumpstart
138 2013-02-10 11:15:49 <wumpus> yes, either that or just run a SPV client
139 2013-02-10 11:16:05 <MC1984> no
140 2013-02-10 11:16:31 <MC1984> lul as many people as possible, who dont know or care anyway, into running a full node
141 2013-02-10 11:17:20 <MC1984> and that bar would be nice if its progress was linear somehow, whatever it measures
142 2013-02-10 11:18:07 <MC1984> or maybe just get rid of it once the SPV mode is in
143 2013-02-10 11:18:21 <wumpus> my vote would be to get rid of it or put it in the debug screen
144 2013-02-10 11:19:23 <wumpus> at least once it can do something without having all the blocks
145 2013-02-10 11:20:28 <Eliel> Raccoon: no, not protocol rewrite. Just a rewrite of the code that implements the current protocol.
146 2013-02-10 11:20:44 <Eliel> Raccoon: at the moment it just has no way to know how many transactions there are in total.
147 2013-02-10 11:20:51 <wumpus> then again, I'm starting to think that a full node is just too much for most people that simply want a payment solution, we should stop recommending it by default
148 2013-02-10 11:21:03 <Eliel> wumpus: I agree with that.
149 2013-02-10 11:21:20 <Eliel> it gives many people a bad impression when they end up trying that first.
150 2013-02-10 11:21:34 <Eliel> and have to wait ages for their first coins to show up ready to use.
151 2013-02-10 11:21:50 <MC1984> fuck it, lets just stick the full nodes on ec2 and call it a day
152 2013-02-10 11:22:10 <wumpus> yeah... a full node is great for getting people to support the network, but it can't be expected of everyone.. most people won't leave it running all day anyway
153 2013-02-10 11:22:26 <wumpus> a full node that runs 30 minutes a day is useless to the network
154 2013-02-10 11:22:47 <Eliel> perhaps even worse than useless :/
155 2013-02-10 11:23:09 <MC1984> i dont see why that is
156 2013-02-10 11:24:11 <ne0futur> would be great if the bitcoin protocol could give some kind of small reward for full nodes
157 2013-02-10 11:24:16 <wumpus> because bootstrapping nodes perform best if they have a stable peer
158 2013-02-10 11:24:43 <ne0futur> not generating, but always here
159 2013-02-10 11:25:42 <MC1984> verification fee?
160 2013-02-10 11:26:12 <MC1984> wumpus yes well i think wed expect work on the P2P to mitigate that
161 2013-02-10 11:26:19 <Eliel> that's hard to implement in a way that doesn't bloat the blockchain quite a bit.
162 2013-02-10 11:27:12 <MC1984> maybe a small fee every 10,000 verified txn or something
163 2013-02-10 11:27:24 <MC1984> souns impossible though
164 2013-02-10 11:27:39 <Eliel> yes, it's difficult to verify you've verified them.
165 2013-02-10 11:27:40 <ne0futur> I d setup many more full nodes
166 2013-02-10 11:27:41 <MC1984> also no way to verify long term storage
167 2013-02-10 11:28:08 <ne0futur> running 2 for now just for the glory, but I d have 10-20 with an incentive
168 2013-02-10 11:28:11 <Eliel> plus, who'd pay for it.
169 2013-02-10 11:28:12 <wumpus> is there a problem at all with # of full nodes? someone could set up something like torservers for bitcoin
170 2013-02-10 11:29:28 <Eliel> if there was a way for people sending a transaction to include a fee that gets given to a random full node that the tx passed through, it might work.
171 2013-02-10 11:29:35 <wumpus> I think there's enough enthousiasts that want to run a full node just for the heck of it
172 2013-02-10 11:29:46 <Eliel> but... I can't think of a way to do that sensibly.
173 2013-02-10 11:29:48 <MC1984> running mor than one is pointless i think
174 2013-02-10 11:30:14 <MC1984> the point of independent veriying nodes is the person who controls it is prob honest
175 2013-02-10 11:30:24 <MC1984> thus adding more "honesty" to the network
176 2013-02-10 11:30:38 <MC1984> more nodes from the same person does not add more honesty
177 2013-02-10 11:30:40 <MC1984> right?
178 2013-02-10 11:30:48 <wumpus> it should always be encouraged for people to run a full node, but they should know what they're doing, not expecting just to try out bitcoin for a bit quickly
179 2013-02-10 11:31:11 <Eliel> MC1984: if the person's nodes are honest, it will increase the density of honest nodes in the network, no?
180 2013-02-10 11:32:31 <MC1984> it only works that way for miners?
181 2013-02-10 11:33:07 <MC1984> everyone should run a full v node
182 2013-02-10 11:33:31 <MC1984> i just dont see it being a problem for most people going forward, especially if the block cap stays put
183 2013-02-10 11:33:46 <MC1984> if the cap stays put illbe running one on my phone in 5 years
184 2013-02-10 12:02:22 <Raccoon> Also, what happens now that we're reaching critical mass as far as number of transactions per block
185 2013-02-10 12:02:56 <Raccoon> how will the network ever grow to even cover a small % of coffee sold in the US, let alone replace Visa
186 2013-02-10 12:03:25 <Raccoon> When the number of coffees sold in the US is enough to max out the bandwidth of a small city
187 2013-02-10 12:03:46 <Raccoon> and fill up a 2TB harddrive in an hour
188 2013-02-10 12:04:33 <sipa> why would you want it to replace Visa?
189 2013-02-10 12:05:24 <Raccoon> If it's theoretically impossible to replace Visa, then it's actually impractical to suppliment Visa
190 2013-02-10 12:05:58 <Raccoon> The amount we use Visa today in 2013 is only 1% of Visa's usage in 2023
191 2013-02-10 12:05:59 <sipa> well you assume that all transactions in the bitcoin economy need to go through the block chain
192 2013-02-10 12:06:30 <Raccoon> Can Bitcon keep up with that 100 fold decadial pace?
193 2013-02-10 12:07:07 <Raccoon> sipa: It does if people are going to "use bitcoin", an not that bitcoin turns into another fiat system.
194 2013-02-10 12:07:40 <Raccoon> If you buy coffee with bitcoin, you're buying it with bitcoin... unless you're buying it with Gox Bux or Second Life dollars
195 2013-02-10 12:07:46 <Raccoon> that you bought with bitcoins
196 2013-02-10 12:07:59 <sipa> depends on your meaning of fiat (if you mean "government-declared value", no; if you mean "money without intrinstic value", yes)
197 2013-02-10 12:08:01 <Raccoon> Then it turns out that THOSE networks are more useful than Bitcoin itself
198 2013-02-10 12:08:53 <sipa> and it's inevitable to have some degree of _voluntary_ centralization
199 2013-02-10 12:09:19 <Raccoon> I mean, sure, I can buy a starbucks coffee with a sarbucks gift card I bought from an amazon gift card that I received from selling bitcoins.
200 2013-02-10 12:09:27 <Raccoon> but that's 7 degrees of separation
201 2013-02-10 12:09:33 <sipa> no need why it can't be bitcoins all the way
202 2013-02-10 12:09:37 <sipa> for example mtgox vouchers
203 2013-02-10 12:09:40 <Raccoon> that's not scanning a bitcoin qr-code at starbucks
204 2013-02-10 12:09:56 <sipa> i sure as hell hope no one ever needs to scan a QR code to pay with bitcoins
205 2013-02-10 12:10:00 <sipa> or see a bitcoin address
206 2013-02-10 12:10:05 <Raccoon> mtgox vouchers are NOT bitcoins by any stretch of the word
207 2013-02-10 12:10:10 <sipa> they aren't
208 2013-02-10 12:10:35 <axhlf> Raccoon: rather that they have NFC and just place the device on the counter and tap "accept"
209 2013-02-10 12:10:43 <Raccoon> sipa: what's wrong with scanning qrcodes?
210 2013-02-10 12:11:10 <sipa> inconvenient
211 2013-02-10 12:11:13 <Raccoon> axhlf: that'd be nice, except only 3 devices on the market have NFC capability, and nobody can agree on an NFC standard.
212 2013-02-10 12:11:25 <sipa> sure, compared to manally typing a bitcoin address, it's heaven
213 2013-02-10 12:11:33 <JWU42> so - with 0.8 - if you DO NOT start with a clean data dir the .dat files remain at 2GB?
214 2013-02-10 12:11:44 <Raccoon> it's less convenient to tap your finger on an icon than it is to tap your phone against the counter?
215 2013-02-10 12:11:51 <sipa> JWU42: they are hardlinked to their new locations
216 2013-02-10 12:12:00 <axhlf> Raccoon: well but there will be some time before starbucks accept btc ;)
217 2013-02-10 12:12:17 <JWU42> sipa: so if I wanted the smaller .dat files start with clean datadir...
218 2013-02-10 12:12:25 <JWU42> K
219 2013-02-10 12:12:25 <Raccoon> axhlf: starbux at least has access to printer paper
220 2013-02-10 12:12:27 <JWU42> thks
221 2013-02-10 12:12:37 <Raccoon> axhlf: 10 cents vs 1000 dollars
222 2013-02-10 12:13:04 <Raccoon> which is how much it would cost to set up NFC at each location
223 2013-02-10 12:13:05 <axhlf> Raccoon: who prints qr's?!
224 2013-02-10 12:13:14 <Raccoon> axhlf: you and I
225 2013-02-10 12:13:16 <Raccoon> anyone
226 2013-02-10 12:13:36 <Raccoon> starbucks would print them and place by the counter.
227 2013-02-10 12:13:44 <Raccoon> nice glossy laminate
228 2013-02-10 12:16:50 <Scrat> in the future bitcoin could just be the backbone on which centralized payment services are constructed
229 2013-02-10 12:17:14 <Raccoon> Scrat: that's how banks started and gold disappeared
230 2013-02-10 12:17:28 <Raccoon> banks started trading direct notes with each other
231 2013-02-10 12:17:46 <Raccoon> turns out gold was to inconvenient
232 2013-02-10 12:18:00 <sipa> and bitcoins are also inconvenient
233 2013-02-10 12:18:03 <Scrat> it's still too cumbersome and heavily regulated
234 2013-02-10 12:18:05 <Raccoon> my point.
235 2013-02-10 12:18:10 <Raccoon> it'd be first to go
236 2013-02-10 12:18:15 <sipa> though vastly more convenient than gold
237 2013-02-10 12:18:52 <Raccoon> sipa: more convenient for the middle-man to cut out the not-middle-man
238 2013-02-10 12:19:20 <sipa> i think the advantage that bitcoin has, is that becoming your own bank is more or less trivial
239 2013-02-10 12:19:21 <Eliel> interesting. I'm trying out 0.8 rc1 on windows XP and the syncing process seems to slow down gradually while the program is running.
240 2013-02-10 12:19:23 <Raccoon> suddenly you'll have some other entity with everyone in his walled garden
241 2013-02-10 12:19:25 <Raccoon> almost like mtgox
242 2013-02-10 12:19:35 <sipa> Eliel: very expected - later blocks are larger
243 2013-02-10 12:19:50 <Eliel> well, is it also expectec that if I restart it, it speeds up significantly?
244 2013-02-10 12:19:55 <sipa> Eliel: no
245 2013-02-10 12:20:16 <Eliel> it's addnoded with another ip on the local network.
246 2013-02-10 12:20:19 <Raccoon> Eliel: If it took a couple hours to get to 80%, it'll take about another day or 2 to reach 100%
247 2013-02-10 12:20:25 <Scrat> Raccoon: people like walled gardens
248 2013-02-10 12:20:32 <sipa> Raccoon: i hope that the fact that becoming a bank-like entity for bitcoin is so easy that there will be enough competition
249 2013-02-10 12:20:44 <Eliel> Raccoon: I thought that too, but it's going much faster now that I'm periodically restarting it.
250 2013-02-10 12:21:01 <sipa> Eliel: you're just syncing from the network?
251 2013-02-10 12:21:18 <Eliel> it's going ~10 blocks per display update right now.
252 2013-02-10 12:21:18 <JWU42> I did an install from a local client - took about an hour
253 2013-02-10 12:21:19 <Raccoon> Eliel restarting bitcoin only means you have to re-read gigs of data from the HDD
254 2013-02-10 12:21:30 <sipa> not at all
255 2013-02-10 12:21:35 <JWU42> now reindex on a win7 box - taking about the same time
256 2013-02-10 12:21:49 <JWU42> maybe just under an hour
257 2013-02-10 12:22:20 <sipa> 0.8 reads much less data from disk at statup
258 2013-02-10 12:22:33 <Raccoon> I calculated 2 hours 36 minutes to go when it was at 120 days remaining
259 2013-02-10 12:22:44 <Eliel> I'm running "version" : 70100 on another system on the LAN. the 0.8 rc1 node is connected to that one.
260 2013-02-10 12:22:45 <JWU42> yeah - the last 20-30% of the chain gets CPU and mem intensive
261 2013-02-10 12:23:11 <sipa> signature checking is only enabled after the last checkpoint
262 2013-02-10 12:23:36 <sipa> ;;calc 216116-[bc,blocks]
263 2013-02-10 12:23:38 <Eliel> anyway, it was doing under 1 block a second before I restarted it
264 2013-02-10 12:23:41 <gribble> -2982
265 2013-02-10 12:23:46 <JWU42> so the sig checking is what increases the mem and CPU usage?
266 2013-02-10 12:23:48 <Eliel> speeded up to about 10 blocks a second after restart
267 2013-02-10 12:23:52 <sipa> JWU42: only CPU
268 2013-02-10 12:24:16 <sipa> Eliel: try -connect=<ip>'ing to your other node
269 2013-02-10 12:24:25 <gribble> BTCUSD ticker | Best bid: 23.43508, Best ask: 23.44399, Bid-ask spread: 0.00891, Last trade: 23.44399, 24 hour volume: 52617.29114700, 24 hour low: 22.67000, 24 hour high: 23.98961, 24 hour vwap: 23.38145
270 2013-02-10 12:24:25 <moarrr> ;;ticker
271 2013-02-10 12:24:31 <Eliel> addnode is different?
272 2013-02-10 12:24:33 <JWU42> checkpoint = last block ?
273 2013-02-10 12:24:33 <sipa> initial download is gets less confused when just connected to a single peer
274 2013-02-10 12:24:44 <sipa> JWU42: last checkpoint in 0.8.0rc1 is 216116
275 2013-02-10 12:24:53 <JWU42> K
276 2013-02-10 12:24:54 <Eliel> ah, true it is
277 2013-02-10 12:24:59 <Eliel> I'll try that.
278 2013-02-10 12:25:05 <JWU42> so that is fixed and noting I can do about it ;)
279 2013-02-10 12:25:09 <sipa> Eliel: yes, -connect means 'only connect to', -addnode is sort of a 'try to stay connected to at least X'
280 2013-02-10 12:25:11 <JWU42> nothing*
281 2013-02-10 12:25:18 <sipa> JWU42: you can disable it, if you want to compare :)
282 2013-02-10 12:25:21 <sipa> -nocheckpoints
283 2013-02-10 12:25:25 <JWU42> 52 minutes
284 2013-02-10 12:25:41 <JWU42> win7 rig - using -dbcache=1000 -par=8
285 2013-02-10 12:26:03 <sipa> JWU42: reindex or sync from network?
286 2013-02-10 12:26:05 <JWU42> i7 920 on 1TB Sata drive
287 2013-02-10 12:26:08 <JWU42> reindex
288 2013-02-10 12:26:19 <JWU42> just fwiw
289 2013-02-10 12:26:36 <sipa> we should try to get 64-bit windows binaries at some point
290 2013-02-10 12:26:50 <sipa> as the ECDSA crypto code is about 2x faster on 64 bit
291 2013-02-10 12:27:01 <JWU42> the local network sync on a slower rig took just over 1 hour last night
292 2013-02-10 12:27:24 <JWU42> dual core AMD system
293 2013-02-10 12:27:46 <JWU42> 
ACTION ponders what to test next ;)

294 2013-02-10 12:29:37 <JWU42> sipa: can you pass a port with -connect?
295 2013-02-10 12:29:46 <sipa> yes
296 2013-02-10 12:29:56 <sipa> -connect=ip:port
297 2013-02-10 12:30:06 <sipa> or -connect=[ip]:port for ipv6
298 2013-02-10 12:30:09 <JWU42> K - that explains why 0
299 2013-02-10 12:30:22 <JWU42> I had it pointed to a rig using non std port
300 2013-02-10 12:33:18 <JWU42> hmm - still no connections
301 2013-02-10 12:33:37 <sipa> what is your exact command line?
302 2013-02-10 12:34:32 <JWU42> sipa: I have connect=lan_IP:nonstdport
303 2013-02-10 12:34:37 <JWU42> in the .conf
304 2013-02-10 12:34:58 <JWU42> will try other lanip on std port now and see if that works
305 2013-02-10 12:35:11 <sipa> debug.log may give a clue
306 2013-02-10 12:35:26 <JWU42> yeah - good idea
307 2013-02-10 12:36:07 <JWU42> connect timeout
308 2013-02-10 12:38:42 <JWU42> connects fine to other lanip (it uses standard port)
309 2013-02-10 12:40:19 <JWU42> hmm - both bitcoind running on non-std port aren't "listening"
310 2013-02-10 12:40:36 <sipa> what command lines were they started with?
311 2013-02-10 12:40:43 <sipa> or config options
312 2013-02-10 12:40:53 <JWU42> sipa: again - using port= in the conf
313 2013-02-10 12:41:52 <JWU42> http://pastebin.com/yvW1qRy5
314 2013-02-10 12:42:27 <sipa> JWU42: if you use -connect, listening is disabled
315 2013-02-10 12:42:28 <JWU42> the .conf for a 0.8 install
316 2013-02-10 12:42:39 <JWU42> and there we have it
317 2013-02-10 12:42:41 <JWU42> heh
318 2013-02-10 12:43:05 <sipa> -listen                Accept connections from outside (default: 1 if no -proxy or -connect)
319 2013-02-10 12:43:27 <JWU42> RTFM
320 2013-02-10 12:44:08 <JWU42> ok - back to the drawing board...
321 2013-02-10 12:44:10 <JWU42> thks sipa
322 2013-02-10 12:44:30 <sipa> also, -addnode is ignored when using -connect (i think)
323 2013-02-10 12:44:41 <JWU42> seems to work
324 2013-02-10 12:44:47 <sipa> ok
325 2013-02-10 12:44:57 <sipa> typically, you'd use specify -connect twice
326 2013-02-10 12:45:04 <JWU42> Luke-Jr: mentioned this yesterday
327 2013-02-10 12:45:26 <JWU42> [18:49] <Luke-Jr> JWU42: I'd do -connect=localhost -addnode=bigpools
328 2013-02-10 12:45:57 <sipa> ha
329 2013-02-10 12:46:02 <JWU42> seeing he mentioned both in context of a bitcoind on a non std port - they seem to work together
330 2013-02-10 12:55:37 <sipa> ;;bc,blocks
331 2013-02-10 12:55:38 <gribble> 219270
332 2013-02-10 12:57:59 <sipa> just reindexed (until block 218478) with 0.8.0rc1 in 23m44s
333 2013-02-10 12:59:57 <JWU42> =)
334 2013-02-10 13:04:31 <Eliel> hmm, this is a bit confusing from user interface point of view. The sync progress bar disappeared but it's still a month behind and syncing.
335 2013-02-10 13:05:31 <sipa> ;;later tell wumpus i wonder: can't we use the other criterion (last block max 90 minutes old, afaik) for deciding whether to show the sync progress bar too?
336 2013-02-10 13:05:32 <gribble> The operation succeeded.
337 2013-02-10 13:17:51 <JWU42> not faster with -nocheckpoints
338 2013-02-10 13:18:14 <JWU42> as the estimate stops at ~110K
339 2013-02-10 13:18:26 <JWU42> versus 216116
340 2013-02-10 13:38:17 <wumpus> sipa: I think the only criterion to determine whether to show the progress bar right now, is that the current block is smaller than the estimate of number of blocks of peers... if it doesn't show the progress bar it doesn't know the progress
341 2013-02-10 13:40:42 <wumpus> yes, just verified that
342 2013-02-10 13:42:25 <wumpus> there's no other way
343 2013-02-10 13:42:35 <wumpus> i guess that's another reason to just delete the progress bar
344 2013-02-10 13:45:51 <Eliel> wouldn't it be better to just fix it so it gets an estimate somehow?
345 2013-02-10 13:46:07 <wumpus> feel free to do so
346 2013-02-10 13:46:14 <wumpus> I wouldn't know how
347 2013-02-10 13:46:59 <Eliel> do you know what is the cause for not having an estimate?
348 2013-02-10 13:47:19 <wumpus> the android applet also simply displays the current date/time of last block, no progress bar
349 2013-02-10 13:47:55 <wumpus> I suppose you could even base a progress bar on time instead of block #
350 2013-02-10 13:48:02 <Eliel> ... actually that sounds like it might work.
351 2013-02-10 13:48:38 <Eliel> X days behind is actually more informative than the block number.
352 2013-02-10 13:48:42 <wumpus> would be an interesting experiment
353 2013-02-10 13:49:01 <wumpus> "where in time are we from the genesis block to now"
354 2013-02-10 13:50:48 <Eliel> the progress bar is probably unnecessary if you keep an updating view of how many days worth of blocks there is left to process.
355 2013-02-10 13:51:05 <wumpus> the advantage being that it doesn't need any estimate of the current block number
356 2013-02-10 13:51:44 <wumpus> yeah
357 2013-02-10 13:52:07 <Eliel> just, what will that do if the computer's time is wrong?
358 2013-02-10 13:52:27 <JWU42> heh - good point
359 2013-02-10 13:52:51 <Eliel> then again, if the computer's time being wrong already screws things up, perhaps that doesn't matter.
360 2013-02-10 13:53:04 <wumpus> well if the time is wrong by too much compared to the network, it will warn you already
361 2013-02-10 13:53:25 <wumpus> if it's just a bit wrong it doesn't matter
362 2013-02-10 13:54:02 <wumpus> at most it will show a wrong value
363 2013-02-10 13:54:45 <Eliel> of course, there's always the option to ignore the computer's time and show the days left based on network time.
364 2013-02-10 13:55:14 <wumpus> it doesn't really matter for a visual indication, which is always an estimate, I really don't want to bikeshed too much about that
365 2013-02-10 14:29:56 <eckey> is anyone here running Bitcoin-Qt on a MacBook Pro?
366 2013-02-10 14:52:54 <wumpus> looks like my idea is working pretty well
367 2013-02-10 15:03:40 <Eliel> wumpus: great! :)
368 2013-02-10 15:04:36 <Eliel> that increases the user friendlyness quite significantly. what kind of a message are you using for it?
369 2013-02-10 15:05:25 <sipa> wumpus: i'm fine with just "X time behind"
370 2013-02-10 15:05:33 <wumpus> I compute the progress bar based on time, and in the label I show the "X days ago"
371 2013-02-10 15:05:53 <wumpus> ago could be replaced by behind, indeed
372 2013-02-10 15:06:01 <Eliel> yes
373 2013-02-10 15:06:26 <sipa> ah, you're changing it to just use the time of the last block in the interval [genesis,now()] ?
374 2013-02-10 15:06:39 <wumpus> yes
375 2013-02-10 15:07:05 <wumpus> the advantage being that no estimate of the current block is needed anymore
376 2013-02-10 15:07:26 <wumpus> which is always wrong (and behind) anyway
377 2013-02-10 15:07:34 <Eliel> that's not the only advantage. It also makes much more sense to the average user
378 2013-02-10 15:07:46 <sipa> agree
379 2013-02-10 15:08:55 <Eliel> it might make sense to have it show hours too. more user friendly that they can see it advancing reasonably constantly.
380 2013-02-10 15:09:22 <wumpus> it currently shows hours when less than a day behind
381 2013-02-10 15:09:37 <Eliel> that's a nice touch too.
382 2013-02-10 15:09:46 <sipa> and what is the criterion for progressbar or not?
383 2013-02-10 15:10:02 <wumpus> there's something to be said for always showing hours, though, for the reason you say (seeing activity)
384 2013-02-10 15:10:20 <wumpus> sipa: 90 minutes behind, same as other places
385 2013-02-10 15:10:26 <sipa> ok
386 2013-02-10 15:11:15 <sipa> but in 0.8.0rc1, it uses a different criterion, no?
387 2013-02-10 15:11:34 <wumpus> yes
388 2013-02-10 15:11:46 <wumpus> <wumpus> sipa: I think the only criterion to determine whether to show the progress bar right now, is that the current block is smaller than the estimate of number of blocks of peers... if it doesn't show the progress bar it doesn't know the progress
389 2013-02-10 15:11:46 <wumpus> <wumpus> yes, just verified that
390 2013-02-10 15:12:32 <sipa> ok
391 2013-02-10 15:12:49 <sipa> i think changing that + using the time interval method would be an improvement then, indeed
392 2013-02-10 15:19:04 <Eliel> it would also be nice if the progress bar tooltip would explain more verbosely that the wallet can only see transactions up until X days ago.
393 2013-02-10 15:19:41 <wumpus> hmm
394 2013-02-10 15:21:10 <Jouke> Yes it would. Our business receives so many questions about when we will send the bought bitcoins, when in reallity the transactions already has loads of confirmations.
395 2013-02-10 15:21:27 <Jouke> *the bitcoins they bought
396 2013-02-10 15:22:08 <Jouke> We always send them to blockchain.info, but that is not really what we want to do.
397 2013-02-10 15:22:37 <wumpus> indeed, a progress bar that says 'XXX days and YYY hours behind' is already clearer in that regard
398 2013-02-10 15:23:37 <wumpus> if the transaction is from today and the client is 6 days behind, it's clear that you cannot see them yet
399 2013-02-10 15:23:53 <sipa> more than a month ago, i'd say an absolute date is more useful
400 2013-02-10 15:24:27 <sipa> things like "431 days behind" say less than "synchronized until 21 nov 2011"
401 2013-02-10 15:24:36 <sipa> but that's a nit
402 2013-02-10 15:24:39 <wumpus> hmm
403 2013-02-10 15:24:40 <Diapolo> once more the progressbar ;)?
404 2013-02-10 15:24:54 <wumpus> I like 'xxx days behind' better than an absolute date, but I suppose that's personal taste
405 2013-02-10 15:25:21 <sipa> the android app uses weeks/days
406 2013-02-10 15:25:28 <wumpus> yeah Diapolo
407 2013-02-10 15:25:43 <wumpus> same shit different day :)
408 2013-02-10 15:25:45 <sipa> but when it's more than a few weeks, i find it hard to interpret
409 2013-02-10 15:26:10 <sipa> anyway, not a large enough nit to keep picking :)
410 2013-02-10 15:26:37 <wumpus> it's hard to interpret, but so is a full date (to me), especially if it continuously updates
411 2013-02-10 15:27:08 <sipa> i guess so
412 2013-02-10 15:27:15 <wumpus> and counting down is fun!
413 2013-02-10 15:27:19 <Eliel> Jouke: Yes, it's the same for us.
414 2013-02-10 15:27:41 <Diapolo> wumpus: I don't want to argue over that again, so I'm just listening ^^ btw. I have some changes ready, that show the progressbar label, when we normally would hide everything there, to see what the client is doing (e.g. while reindexing)... guess I create a pull after that refactorings and 0.8
415 2013-02-10 15:28:54 <sipa> wumpus: hmm, not-so-very-random variations in the block timestamp can be up to 2 hours
416 2013-02-10 15:29:09 <sipa> so it may mean that the progressbar (or its label) jump back slightly
417 2013-02-10 15:29:34 <wumpus> yep I suppose that's possible
418 2013-02-10 15:29:53 <sipa> one way to fix that is using an average or median of a range of blocks
419 2013-02-10 15:29:58 <sipa> but i guess that's overkill
420 2013-02-10 15:30:10 <wumpus> Diapolo: okay, that's nice
421 2013-02-10 15:30:15 <wumpus> oh no, not another median filter :-)
422 2013-02-10 15:30:26 <sipa> it could be the same one :p
423 2013-02-10 15:31:11 <wumpus> we could also remember the last one and require it to never go down, then again, two hours of jitter doesn't really show on a time range from genesis block..now
424 2013-02-10 15:31:28 <Eliel> well, if you show the hours, it makes sense
425 2013-02-10 15:32:15 <Eliel> if (block_time > last_shown_time) show(block_time); :P
426 2013-02-10 15:32:37 <wumpus> I don't want to make it too complex, usually it's best to just show things as they are
427 2013-02-10 15:32:39 <sipa> that's a 0.005% variaton only
428 2013-02-10 15:33:18 <Diapolo> ^^
429 2013-02-10 15:33:19 <sipa> so unless someone has a 20000-pixel wide screen, he won't see anything indeed
430 2013-02-10 15:33:24 <wumpus> hehehe
431 2013-02-10 15:33:46 <Eliel> yes, for the progress bar it won't matter.
432 2013-02-10 15:50:58 <sipa> wumpus: i wonder if it makes sense to try to compensate for the speed difference between before/after last checkpoint
433 2013-02-10 15:52:11 <sipa> just a fixed heuristic speed factor, using a function like f(time) = (time < last_checkpoint_time) ? time : last_checkpoint_time + FACTOR*(time - last_checkpoint_time)
434 2013-02-10 15:53:20 <Scrat> convert the progress bar from logarithmic to linear
435 2013-02-10 15:53:22 <Scrat> </troll>
436 2013-02-10 15:53:53 <Scrat> well, exponential
437 2013-02-10 15:54:03 <Scrat> or whatever it's approximation is
438 2013-02-10 15:54:20 <sipa> the best estimate would be using the number of transactions
439 2013-02-10 15:54:28 <sipa> unfortunately, that is not known in advance
440 2013-02-10 15:54:56 <Scrat> blockchain size would be also easy
441 2013-02-10 15:55:01 <Scrat> to compute
442 2013-02-10 15:55:08 <sipa> also not known in advance
443 2013-02-10 15:55:14 <Scrat> yes
444 2013-02-10 15:57:32 <sipa> on my system, blocks after the checkpoint are about 9 times slower than those before
445 2013-02-10 15:58:08 <Scrat> would require protocol change. is that part modular? the part where it gets the max block height from peers
446 2013-02-10 15:58:59 <sipa> protocol changes are easy
447 2013-02-10 15:59:13 <sipa> but there is no way to convey that information in an authenticated way
448 2013-02-10 15:59:45 <sipa> sure, peers that lie don't matter much as long as you only use the information for GUI purposes
449 2013-02-10 16:00:14 <wumpus> sipa: indeed, it could use a scaling factor for the part before first checkpoint
450 2013-02-10 16:00:18 <Scrat> is that startingheight in getpeerinfo?
451 2013-02-10 16:00:52 <sipa> Scrat: yes
452 2013-02-10 16:00:53 <wumpus> would make sense, would need to do some timing experiments to see what's an appropriate factor
453 2013-02-10 16:02:00 <sipa> problem is that that factor is very system dependent
454 2013-02-10 16:02:09 <sipa> especially with parallel signature checking
455 2013-02-10 16:02:42 <sipa> and there's a significant difference between 32 and 64 bit too
456 2013-02-10 16:03:57 <wumpus> as long as the second part *appears* to go faster or just as fast as the first part it's good
457 2013-02-10 16:04:04 <wumpus> just not slower
458 2013-02-10 16:04:24 <sipa> on some systems, the factor may well be 50 or so
459 2013-02-10 16:04:46 <sipa> single-core, SSD, lots of RAM
460 2013-02-10 16:04:47 <wumpus> sure, though most people will be running it on crappy machines
461 2013-02-10 16:06:55 <sipa> more cores makes the factor closer to 1
462 2013-02-10 16:07:16 <sipa> faster disk makes the factor further from 1
463 2013-02-10 16:07:46 <Eliel> couldn't you just precalculate a function based on the actual transaction counts in the block?
464 2013-02-10 16:07:55 <Eliel> and just use that
465 2013-02-10 16:08:05 <wumpus> too much bother, I'll just keep the progress bar "honest"
466 2013-02-10 16:08:52 <Eliel> I mean, you could hardcode the transaction count on each checkpoint and use those to scale it.
467 2013-02-10 16:09:27 <sipa> true
468 2013-02-10 16:09:54 <wumpus> but how would that help you scale compared to blocks that are not in a checkpoint yet?
469 2013-02-10 16:11:33 <sipa> you could use a heuristic num_transactions_per_day factor, and use transactions_at_last_checkpoint + (now() - time_last_checkpoint)*num_transactions_per_day*slowdown_after_checkpoint_factor
470 2013-02-10 16:11:53 <sipa> and compare that to the total number of transactions in the currently-connected chain
471 2013-02-10 16:12:29 <sipa> (which is tracked)
472 2013-02-10 16:12:32 <wumpus> hmm
473 2013-02-10 16:12:56 <sipa> pindexBestBlock->nChainTx
474 2013-02-10 16:12:57 <wumpus> I like the simple time based progress bar
475 2013-02-10 16:13:19 <sipa> that's certainly the easiest solution
476 2013-02-10 16:13:35 <wumpus> it's also the least bug prone, you know what you get
477 2013-02-10 16:14:05 <sipa> although i think that something that compensates for sigchecking and/or transaction counts has all of the advantages that a time-based progressbar has
478 2013-02-10 16:14:13 <sipa> except simplicity
479 2013-02-10 16:14:19 <wumpus> and is not based on any uncertain number received from other nodes
480 2013-02-10 16:15:53 <sipa> CCheckpoints or whatever could expose a GuessTotalTransactions(time_t) function
481 2013-02-10 16:16:07 <sipa> but i suppose just using time now would already be a nice improvement
482 2013-02-10 16:16:30 <Scrat> lockunspent with the same arguments unlocks it, correct?
483 2013-02-10 16:16:38 <wumpus> yeah...
484 2013-02-10 16:17:56 <sipa> Scrat: first argument to lockunspent is a bool
485 2013-02-10 16:18:06 <sipa> false for locking, true for unlocking
486 2013-02-10 16:18:18 <Scrat> oh, fUnlock is an argument
487 2013-02-10 16:18:21 <Scrat> im derping
488 2013-02-10 16:58:45 <sipa> wumpus: do you intend to make those progressbar changes before 0.8?
489 2013-02-10 17:00:34 <wumpus> I'm now testing them
490 2013-02-10 17:00:50 <wumpus> so I suppose it's possible
491 2013-02-10 17:01:08 <sipa> can you push it to github?
492 2013-02-10 17:01:13 <wumpus> yeah
493 2013-02-10 17:05:48 <MobGod> can someone tell me where the wallet.dat file is on a mac
494 2013-02-10 17:06:09 <wumpus> sipa: https://github.com/bitcoin/bitcoin/pull/2294
495 2013-02-10 17:06:16 <sipa> MobGod: https://en.bitcoin.it/wiki/Data_directory
496 2013-02-10 17:06:29 <MobGod> looking at the docs it's not there
497 2013-02-10 17:08:36 <MobGod> sipa files are not there
498 2013-02-10 17:08:45 <MobGod> thats why i'm asking
499 2013-02-10 17:08:55 <sipa> MobGod: in that case, i can't help you - i know nothing about apple stuff
500 2013-02-10 17:09:32 <wumpus> why not just search for wallet.dat?
501 2013-02-10 17:12:41 <MobGod> wumpus telling me my info should be here but it's not
502 2013-02-10 17:12:43 <MobGod> ~/Library/Application Support/Bitcoin/
503 2013-02-10 17:15:53 <MobGod> sipa any idea how i can find this info
504 2013-02-10 17:16:06 <wumpus> yes but I mean why not run a 'find' command
505 2013-02-10 17:16:19 <wumpus> or whatever is the osx variant
506 2013-02-10 17:17:32 <MobGod> wumpus i've done that also lol
507 2013-02-10 17:18:49 <wumpus> well if that finds nothing I suppose it simply doesn't exist
508 2013-02-10 17:20:00 <BCB> ;;ticker --last
509 2013-02-10 17:20:03 <gribble> 23.61100
510 2013-02-10 17:20:55 <sipa> MobGod: what program are you using?
511 2013-02-10 17:21:01 <sipa> what bitcoin client, i mean
512 2013-02-10 17:24:16 <MobGod> qt\\
513 2013-02-10 17:24:23 <MobGod> qt*
514 2013-02-10 17:29:02 <MobGod> sipa latest release is 0.7.2 right
515 2013-02-10 17:29:41 <sipa> yes
516 2013-02-10 17:32:51 <MobGod> just not understanding why i can't find the files
517 2013-02-10 17:33:29 <MobGod> i'm in Application/Support but i don't see bit coin-qt or anything that has bitcoin
518 2013-02-10 17:39:45 <MobGod> this is crazy
519 2013-02-10 17:41:53 <sipa> MobGod: sorry, you'll have to ask an OSX user
520 2013-02-10 17:42:07 <sipa> wumpus: i implemented a transaction-count-based progress calculator
521 2013-02-10 17:42:19 <sipa> wumpus: it seems to be extremely slow initially...
522 2013-02-10 17:42:32 <Jouke> :o
523 2013-02-10 17:42:52 <MobGod> sipa ok
524 2013-02-10 17:42:52 <sipa> because early blocks have almost no transactions, that's expected
525 2013-02-10 17:45:12 <PsyKick> Library/Application, I think, is the correct folder you're looking for
526 2013-02-10 17:45:26 <wumpus> sipa: indeed
527 2013-02-10 17:47:22 <sipa> wumpus: see my 'progressbar' branch
528 2013-02-10 17:48:18 <sipa> hmmm, there must be a bug
529 2013-02-10 18:05:27 <denisx> MobGod: what you are looking for?
530 2013-02-10 18:07:16 <denisx> MobGod: my data is in ~/Library/Application\\ Support/Bitcoin/
531 2013-02-10 18:08:11 <MobGod> your on OSX?
532 2013-02-10 18:08:23 <denisx> yes
533 2013-02-10 18:10:54 <JWU42> 0.8 with 8 connections about 10-15 seconds faster relaying new block than 0.7.2 with 70 connections
534 2013-02-10 18:11:03 <JWU42> this over the last 10-15 blocks
535 2013-02-10 18:11:32 <JWU42> 0.8 better or too many connections on 0.7.2 ;)
536 2013-02-10 18:11:44 <sipa> how do you measure relay speed?
537 2013-02-10 18:11:51 <JWU42> faster HW on the 0.7.2 rig
538 2013-02-10 18:12:09 <JWU42> sipa: tailing debug.log on both
539 2013-02-10 18:12:35 <JWU42> and the 0.7.2 rig is running stratum pool and watching that console as well
540 2013-02-10 18:13:11 <JWU42> I saw the inverse happen previously - the faster rig with just 8 connections reporting new blocks sooner
541 2013-02-10 18:13:28 <JWU42> the older rig with 70+ being slower
542 2013-02-10 18:13:34 <sipa> 0.8 should definitely be faster in relaying
543 2013-02-10 18:13:41 <JWU42> which has me questioning the optimal number of peers
544 2013-02-10 18:14:00 <JWU42> perhaps relaying is the wrong word choice
545 2013-02-10 18:14:07 <JWU42> on my part
546 2013-02-10 18:14:12 <sipa> but you have no guarantee that both receive the same block at the same time, right?
547 2013-02-10 18:14:19 <JWU42> I see the change in block height first on the 0.8 rig
548 2013-02-10 18:14:40 <JWU42> sipa: correct
549 2013-02-10 18:15:29 <JWU42> I am too ignorant to figure how to test for that (0.7.2 vs. 0.8)
550 2013-02-10 18:15:55 <JWU42> =)
551 2013-02-10 18:34:33 <muhoo> yikes, btc has doubled since i first got some4 months ago. too bad i spent them almost immediately.
552 2013-02-10 18:52:26 <muhoo> hmm, is transaction  5d4dca620db4dac6ef666381bb95e9d49a920bc1a05bfdb41022018c9579a263: on the testnet all screwed u?
553 2013-02-10 18:52:39 <muhoo> from [exception: Script not of right size, expecting 2 but got 1]
554 2013-02-10 18:55:00 <sipa> which script?
555 2013-02-10 18:55:39 <muhoo> didn't say
556 2013-02-10 18:56:16 <sipa> i mean: which input or output #?
557 2013-02-10 18:58:10 <muhoo> can't say. looks like there is only 1
558 2013-02-10 18:59:12 <sipa> it has 28 inputs and 1 output
559 2013-02-10 18:59:38 <muhoo> hmm, yes it does. and each of those inputs throws the same error
560 2013-02-10 19:00:34 <muhoo> https://www.refheap.com/paste/11151 is what it looks like to me
561 2013-02-10 19:00:57 <muhoo> the output, 1000.00 BTC looks fine.
562 2013-02-10 19:01:37 <muhoo> what's different about that transaction?
563 2013-02-10 19:02:02 <sipa> what software is that?
564 2013-02-10 19:02:26 <muhoo> bitcoinj
565 2013-02-10 19:03:22 <muhoo> where are you looking to see the inputs and outputs of that transaction? is there a blockexplorer for the testnet?
566 2013-02-10 19:03:32 <sipa> yes
567 2013-02-10 19:03:36 <sipa> blockexplorer.com/testnet
568 2013-02-10 19:03:53 <sipa> and it seems bitcoinj doesn't support send-to-pubkeys
569 2013-02-10 19:04:04 <muhoo> i guess not. hmm.
570 2013-02-10 19:04:05 <sipa> so it doesn't understand those inputs
571 2013-02-10 19:05:31 <muhoo> thanks
572 2013-02-10 19:16:24 <Jamesonwa> ;;rate michail1 6 Sold atleast $5,000 worth of bitcoins in 30 days.  Safe dealings, cash in hand, local.
573 2013-02-10 19:16:40 <gribble> Rating entry successful. Your rating for user michail1 has changed from 4 to 6.
574 2013-02-10 21:54:53 <Eliel> this looks rather strange https://bitcointalk.org/index.php?topic=142395
575 2013-02-10 23:05:37 <TradeFortress> I get Warning: fopen(http://...@localhost:8333): failed to open stream: HTTP request failed! HTTP/1.1 404 when I try to connect with jsonRPCClient.php :/
576 2013-02-10 23:08:18 <TradeFortress> I am really out of clues on why this is happening.
577 2013-02-10 23:10:00 <upb> lrn2debug
578 2013-02-10 23:11:55 <TradeFortress> upb: no idea why I get 404. curl works fine.
579 2013-02-10 23:21:11 <D34TH> seriously?
580 2013-02-10 23:21:25 <D34TH> TradeFortress: try 8332
581 2013-02-10 23:22:01 <D34TH> should say something about method not found
582 2013-02-10 23:23:08 <D34TH> or something like that
583 2013-02-10 23:35:12 <asuk> Can anybody explain me the wiki page https://en.bitcoin.it/wiki/Getwork? especially,
584 2013-02-10 23:35:19 <asuk> "Because getwork provides the data in little endian, and"
585 2013-02-10 23:35:32 <asuk> "SHA256 works in big endian"  (???) ...
586 2013-02-10 23:35:36 <asuk> next
587 2013-02-10 23:35:44 <asuk> "SHA256 (SHA256 (bigEndianToLittleEndianForEach32BitBlock (data)))" ?
588 2013-02-10 23:38:27 <Luke-Jr> asuk: what's unclear?
589 2013-02-10 23:38:37 <Luke-Jr> the last line is wrong
590 2013-02-10 23:39:12 <asuk> What should it be?
591 2013-02-10 23:39:52 <Luke-Jr> calculate: hash = SHA256(SHA256(EndianFlipForEach32Bits(First80BytesOf(data))))
592 2013-02-10 23:40:50 <asuk> it's more understandable )
593 2013-02-10 23:41:08 <asuk> thank you
594 2013-02-10 23:41:08 <Luke-Jr> asuk: note that getwork is deprecated though ;)
595 2013-02-10 23:42:06 <asuk> yes. I just use this method to get some data
596 2013-02-10 23:42:13 <asuk> to play with
597 2013-02-10 23:42:39 <Luke-Jr> asuk: libblkmaker includes a very simple example that mines a share, FWIW
598 2013-02-10 23:42:54 <Luke-Jr> (CPU mining using libgcrypt, so not optimized at all)
599 2013-02-10 23:43:12 <Luke-Jr> (but it does include an example template that has an early-found share)