1 2013-06-15 00:20:42 <Luke-Jr> super3: dunno, I prefer the older form for at least some of it..
  2 2013-06-15 00:21:00 <Luke-Jr> but I (and most people?) don't view as markup, just plain text
  3 2013-06-15 00:46:52 <super3> Luke-Jr, yeah that might make you a little biased. markdown works pretty well in plaintext too though
  4 2013-06-15 00:49:07 <Luke-Jr> super3: I'd prefer man markup :P
  5 2013-06-15 00:50:02 <super3> Luke-Jr, http://www3.picturepush.com/photo/a/6590021/img/Meme/So-Hardcore.jpg
  6 2013-06-15 00:50:24 <super3> Luke-Jr, he he
  7 2013-06-15 00:50:51 <super3> there is nothing wrong with that, but I think the docs needs to be readable to the average person browsing github
  8 2013-06-15 00:55:42 <Luke-Jr> why would the average person be browsing github, instead of opening the text file on their own PC?
  9 2013-06-15 01:18:57 <super3> i always look at docs in browser
 10 2013-06-15 01:19:10 <super3> its usually right along with my google searches
 11 2013-06-15 01:20:45 <sipa> i sometimes use github too for browsing the source, when i'm not at my own computer
 12 2013-06-15 01:21:07 <super3> either way the whole purpose of markdown is "readable as-is, without out looking like it's been marked up with tags or formatting instructions"
 13 2013-06-15 01:22:04 <super3> which is why i dislike reStructuredText so much
 14 2013-06-15 01:26:14 <warren> has anyone documented how to create your own testnet in a box?
 15 2013-06-15 02:11:06 <super3> warren, if you can't find it on bitcointalk it probably doesn't exsist
 16 2013-06-15 02:12:55 <super3> warren, what are you trying to do?
 17 2013-06-15 02:16:13 <warren> super3: create a new testnet between two nodes with PoW check disabled
 18 2013-06-15 02:18:14 <super3> yeah thats very specific. i don't think that has been done much less someone write documentation about it
 19 2013-06-15 02:20:01 <super3> id say use the regular testnet and be happy :-P
 20 2013-06-15 02:53:54 <Luke-Jr> warren: TNIAB is nothing special
 21 2013-06-15 02:54:16 <Luke-Jr> warren: it's just two nodes with -connect to each other on non-standard ports
 22 2013-06-15 02:54:42 <warren> ah, because -connect= avoids other nodes entirely
 23 2013-06-15 03:53:16 <petertodd> gmaxwell: that was jdillon raising trouble...
 24 2013-06-15 03:54:06 <petertodd> gmaxwell: note that he only timestamped the *fingerprints*, which aren't linked to the actual identities unfortunately, so it doesn't quite work
 25 2013-06-15 03:56:59 <gmaxwell> petertodd: hm? the fingerprints include the username/timestamp.
 26 2013-06-15 03:57:41 <petertodd> gmaxwell: nope, fingerprints are just the SHA1 hash of the primary key
 27 2013-06-15 03:58:05 <petertodd> gmaxwell: basically, given a primary key from the past, I can create a set of valid looking user ids
 28 2013-06-15 03:58:41 <gmaxwell> To make the fingerprint match you actually have to have the UID and timestamp matching. (I promise!)
 29 2013-06-15 04:00:10 <petertodd> gmaxwell: RFC4880 12.2 "Key IDs and Fingerprints": "A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field.  The Key ID is the low-order 64 bits of the fingerprint.  Here are the fields of the hash material, with the example of a DSA key:
 30 2013-06-15 04:00:28 <petertodd> Every one of the fields is key material, not user id.
 31 2013-06-15 04:07:36 <petertodd> In any case, the Wired message is only known to be encrypted to keyid 0x50917466b18f35b3f644f7001d0d97f22be0bc29, which isn't in the WoT strong set and wasn't timestamped.
 32 2013-06-15 04:10:09 <gmaxwell> petertodd: it must be different for different address types, because I know when reconstructing a key from a factored key I had to exactly match the UID/timestamp to get the same id.
 33 2013-06-15 04:10:39 <petertodd> gmaxwell: the *timestamp* is part of the hash, but the UID isn't
 34 2013-06-15 04:11:06 <gmaxwell> I ... wouldn't have thought to not match that. wtf pgp.
 35 2013-06-15 04:11:31 <petertodd> gmaxwell: No PGP version has ever included UID's in fingerprints unfortunately. Though for the trust model of PGP that makes sense really, it just doesn't work for timestamping.
 36 2013-06-15 04:11:55 <petertodd> gmaxwell: After all, changing your UID *is* a valid thing to do.
 37 2013-06-15 04:12:01 <gmaxwell> yea, okay but why include the timestamp?
 38 2013-06-15 04:12:30 <petertodd> Yeah, I'll admit the timesamp thing is odd... PGP has a lot of timestamps that do fuck all.
 39 2013-06-15 04:12:31 <gmaxwell> (doing that makes it cheap-er to search for partial collissions, so its the worst of all worlds! :) )
 40 2013-06-15 04:12:55 <petertodd> Heh, that's a very good point...
 41 2013-06-15 04:12:59 <gmaxwell> (not that it would really be expensive in the first place, since you if you're trying to get a collission you likely don't care if the key is strong)
 42 2013-06-15 04:13:25 <petertodd> Oh I dunno, I'd want my compromised communications to be strong against other blackhats. :P
 43 2013-06-15 04:13:43 <gmaxwell> you can still increment the modulus.
 44 2013-06-15 04:15:01 <petertodd> In any case, ask nicely and I'm sure jdillon would happily add another 200k UTXO's to timestamp all the UIDs too...
 45 2013-06-15 04:16:08 <gmaxwell> doh.
 46 2013-06-15 04:17:01 <petertodd> reminds me, did you ever see 1MBGavinWuiJCF6thGfEriB2WhDD5nhB2a?
 47 2013-06-15 04:17:16 <gmaxwell> No.
 48 2013-06-15 04:17:58 <petertodd> Seems that the guy who gave me $150 to turn my timestamper back on got pissed off and is now using UTXO's again for timestamping... with an extra one thrown in for politics.
 49 2013-06-15 04:29:41 <pjorrit> haha
 50 2013-06-15 04:58:49 <bitRippe1X> anyone know how the reddit bitcoin bot handles creating multiple wallets and how they handle authentication on the back end?
 51 2013-06-15 05:27:54 <weex> bitRippe1X: isn't the code available for the bitcoin tip bot? you'll need to read it most likely
 52 2013-06-15 06:51:36 <bitRippe1X> exit
 53 2013-06-15 06:51:37 <bitRippe1X> exit
 54 2013-06-15 10:41:31 <Mason-B> I was doing some datamining on the block chain and I found some inconsistencies
 55 2013-06-15 10:42:58 <Mason-B> It appears that there are some missing bitcoins
 56 2013-06-15 10:43:16 <Mason-B> almost 10 to be exact
 57 2013-06-15 10:43:54 <sydna> do show.
 58 2013-06-15 10:44:19 <Mason-B> Here let me push what I have to github
 59 2013-06-15 10:44:28 <Mason-B> and let me find some of the bad blocks
 60 2013-06-15 10:45:06 <Mason-B> I want to preface this by saying I think I have a bug in my code
 61 2013-06-15 10:45:25 <Mason-B> but wanted to check to see if you guys might now what I'm talking about first
 62 2013-06-15 10:46:20 <sydna> I'm not by any means a core developer, but it's always interesting to read other people's code. I'm sure someone else will chip in too.
 63 2013-06-15 10:47:05 <Mason-B> I take that back, the inconsistencies seem to amount to more than 60 bitcoins
 64 2013-06-15 10:47:18 <Mason-B> I thought it was actually my forgetting to remove satoshis block at first
 65 2013-06-15 10:47:40 <sydna> are you assuming that every coinbase contains the maximum block reward?
 66 2013-06-15 10:47:47 <sydna> (you can't assume that they do0
 67 2013-06-15 10:49:03 <Mason-B> could you clarify?
 68 2013-06-15 10:49:23 <sydna> I'm completely guessing with this one.
 69 2013-06-15 10:49:44 <Mason-B> I asumme that the first 210000 blocks rewards 50 btc + fees
 70 2013-06-15 10:49:50 <sydna> ah, you can't.
 71 2013-06-15 10:49:55 <Mason-B> why?
 72 2013-06-15 10:50:18 <sydna> the generator of the block could set some arbitrary amount under 50, and it would still be a valid block
 73 2013-06-15 10:50:58 <sydna> there's quite a number of blocks that contain less than the expected reward, though I don't have a list handy
 74 2013-06-15 10:51:19 <Mason-B> well thats
 75 2013-06-15 10:51:22 <Mason-B> ...
 76 2013-06-15 10:51:24 <Mason-B> wierd
 77 2013-06-15 10:51:41 <Mason-B> but this is the opposit scenario
 78 2013-06-15 10:52:06 <Mason-B> or
 79 2013-06-15 10:52:09 <Mason-B> hmm
 80 2013-06-15 10:52:13 <Mason-B> it might not be
 81 2013-06-15 10:52:17 <Mason-B> one sec
 82 2013-06-15 10:54:43 <Mason-B> it takes me a couple minutes to rewalk the chain
 83 2013-06-15 10:56:26 <sydna> I'd work out the first block with a < 50 reward, but I don't have a copy of the blockchian locally
 84 2013-06-15 10:56:59 <Mason-B> I filtered out ones with negative inconsistencies
 85 2013-06-15 10:57:34 <Mason-B> the positive inconsistencies represent fees that were not paid by the incoming transactions but that the miner claimed
 86 2013-06-15 10:59:25 <Mason-B> block-height 2818 has this inconsistency
 87 2013-06-15 10:59:36 <Mason-B> http://blockchain.info/block-index/4370/00000000d50a3cd05e451166e5f618c76cc3273104608fe424835ae5c0d47db9
 88 2013-06-15 10:59:46 <Mason-B> (actually 2817, since I 1 index them)
 89 2013-06-15 11:00:26 <Mason-B> accorind to my software it does, I am still trying to verify with that site
 90 2013-06-15 11:00:48 <sydna> I think I'm being thick, but I'm not seeing anything out of place in that case
 91 2013-06-15 11:01:52 <sipa> Mason-B: known fact
 92 2013-06-15 11:02:14 <Mason-B> so there are known blocks that make money up?
 93 2013-06-15 11:02:19 <sydna> ^ now you'll get better answers
 94 2013-06-15 11:02:20 <Mason-B> above the reward?
 95 2013-06-15 11:02:29 <sipa> above? :o
 96 2013-06-15 11:02:33 <sipa> no, below
 97 2013-06-15 11:02:49 <sipa> there is an gettxoutsetinfo RPC command in recent bitcoind versions
 98 2013-06-15 11:03:02 <sipa> and it lists the sum of all unspent outputs in the chain
 99 2013-06-15 11:03:27 <sipa> the result is something like 100-150 BTC below what you'd expect, iirc
100 2013-06-15 11:03:41 <Mason-B> Yea I'm gettign that
101 2013-06-15 11:03:46 <sipa> part of it is due to thr genesis blocks output not being spendable
102 2013-06-15 11:04:07 <sipa> part of it is duplicate coinbase transactions (there have been one or two)
103 2013-06-15 11:04:28 <sipa> and then there were random bugs were miners failed to claim all fees they could
104 2013-06-15 11:05:58 <Mason-B> well my problem seems to be extra bitcoins, fees claimed by miners that wern't fully covered
105 2013-06-15 11:06:15 <Mason-B> by the transactions in the block
106 2013-06-15 11:06:54 <sipa> that seems very unlikely
107 2013-06-15 11:07:01 <sipa> can you give an example?
108 2013-06-15 11:07:35 <Mason-B> I'm having trouble finding a good way to validate this, I need a place I can view the actual incoming outpoint instead of just the address
109 2013-06-15 11:07:52 <Mason-B> the block at height 2817 seems to exhibt this property
110 2013-06-15 11:08:02 <Mason-B> (I still think I have a bug in my code)
111 2013-06-15 11:08:17 <sipa> if you have your bitcoind with -txindex=1 you can look up arbitrary transactions using getrawtransaction
112 2013-06-15 11:09:10 <sipa> except the genesis
113 2013-06-15 11:09:16 <sydna> I don't see anything /wrong/ with the block 00000000d50a3cd05e451166e5f618c76cc3273104608fe424835ae5c0d47db9 personally
114 2013-06-15 11:09:58 <Mason-B> do all the incoming outpoints cover the fees and outputs?
115 2013-06-15 11:10:17 <Mason-B> I'm reading bitcoind's documentation now :p
116 2013-06-15 11:21:16 <Mason-B> I can't seem to get bitcoind to take my block hash
117 2013-06-15 11:21:31 <Mason-B> bitcoind getblock 00000000d50a3cd05e451166e5f618c76cc3273104608fe424835ae5c0d47db9
118 2013-06-15 11:21:41 <Mason-B> doesn't seem to work
119 2013-06-15 11:22:33 <sipa> are you synced up?
120 2013-06-15 11:23:33 <Mason-B> I believe so...
121 2013-06-15 11:23:47 <Mason-B> how would I check?
122 2013-06-15 11:24:21 <sipa> getinfo
123 2013-06-15 11:24:45 <sipa> what height is that block? sure the hash is correct?
124 2013-06-15 11:24:52 <sipa> and that it's in the main chain
125 2013-06-15 11:25:45 <kork> https://blockchain.info/tx/f322851970f8289e3593747c83a2cb4f27f89aaf8421143cca40d00f13f42a6a this is interesting, I sent 4.8 and 0.2 to the *same* address (1AAMwLpDc41967Nvr8d9CUVJuu4FhCeaiQ), yet 0.2 went to 19qB63tP7jSpHW3VdVo75LusisncN7B1yK, of which I know nothing
126 2013-06-15 11:25:57 <Mason-B> What would getinfo tell me if it wasn't sync'd
127 2013-06-15 11:26:34 <sydna> kork: https://en.bitcoin.it/wiki/Change
128 2013-06-15 11:27:10 <sydna> Mason-B: well, you'd have less than 241664 blocks.
129 2013-06-15 11:27:40 <Mason-B> ahh
130 2013-06-15 11:27:44 <Mason-B> well I have 0
131 2013-06-15 11:27:58 <sydna> .. so you've never synched.
132 2013-06-15 11:27:59 <Mason-B> , but I have three copies of the block chain downloaded by the bitcoin client
133 2013-06-15 11:28:13 <Mason-B> so how do I get ti to find them >.>
134 2013-06-15 11:28:35 <Mason-B> I've never run bitcoind
135 2013-06-15 11:28:40 <kork> sydna: aah, I see. and I don't have the 19qB63tP7jSpHW3VdVo75LusisncN7B1yK private key in my wallet because it was created from recovered private keys. well, guess I destroyed those 0.2 BTC then
136 2013-06-15 11:29:07 <sydna> you can manually set a bitcoin/ directory with -blockdir or something like that
137 2013-06-15 11:29:20 <sydna> kork: probably not. the change addresses are hidden from view in most clients.
138 2013-06-15 11:29:35 <sydna> kork: it wouldn't have been sent to the change address if it didn't exist in the wallet.
139 2013-06-15 11:31:07 <kork> sydna: oh, ok. my client believes it has sent the 0.2 to 1AAMwLpDc41967Nvr8d9CUVJuu4FhCeaiQ, too, but the transaction id of that 0.2 btc transaction can't be found on blockchain.info. guess I'll just have to wait?!
140 2013-06-15 11:32:25 <sydna> I've no idea. it sounds like you're doing something odd.
141 2013-06-15 11:32:31 <sydna> you certainly haven't lost the money though.
142 2013-06-15 11:33:20 <sipa> kork: how do you tell the client believes it sent to 1AAMwL?
143 2013-06-15 11:34:38 <kork> sipa: when I double click the transaction, I get this: http://dark-code.bulix.org/dk8uvs-83749
144 2013-06-15 11:36:19 <kork> for clarification, I used makomk's recovery tool to extract the private keys from a raw partition; it says on the forum "The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such)."
145 2013-06-15 11:36:30 <kork> so I guess my client didn't create new change addresses after restarting
146 2013-06-15 11:36:49 <sipa> is your wallet encrypted?
147 2013-06-15 11:36:56 <kork> no
148 2013-06-15 11:37:04 <kork> oh, never mind
149 2013-06-15 11:37:04 <sipa> then it certainly created a new keypool
150 2013-06-15 11:37:11 <kork> the transaction just went through
151 2013-06-15 11:37:42 <kork> https://blockchain.info/address/19qB63tP7jSpHW3VdVo75LusisncN7B1yK there, everything good :-)
152 2013-06-15 11:37:48 <kork> thanks for your help and the explanations, guys
153 2013-06-15 11:37:49 <sipa> and it used the change output you created with the previous transaction
154 2013-06-15 11:37:57 <kork> yes
155 2013-06-15 11:38:03 <sipa> so all is well
156 2013-06-15 11:38:10 <kork> indeed. thanks
157 2013-06-15 11:38:19 <sydna> people really do struggle with change
158 2013-06-15 11:39:00 <sipa> we really need to get people to think of wallets as wallets, and not as collections of addresses
159 2013-06-15 11:39:24 <kork> the explanation on https://en.bitcoin.it/wiki/Change
160 2013-06-15 11:39:26 <kork> really makes sense
161 2013-06-15 11:39:47 <sydna> blockchain.info is making the problem far, far worse
162 2013-06-15 11:39:57 <sydna> it removes much of the abstraction a wallet gives
163 2013-06-15 11:40:06 <sipa> indeed
164 2013-06-15 11:40:31 <sydna> and paper wallets, while suitable for some things, are disastrous
165 2013-06-15 11:41:24 <sydna> I saw a hilarious Chrome extension before that for some reason was designed to let you use a single brainwallet address as a "wallet".
166 2013-06-15 11:42:43 <sipa> :(
167 2013-06-15 11:43:42 <sydna> exactly.
168 2013-06-15 11:45:01 <sydna> it's somewhat worrying that people put their faith and currency in such flimsy containers
169 2013-06-15 11:50:52 <kork> another question while I'm here bugging you: I have a wallet file here that only contains 0.00089552 BTC. is there a point in keeping that file?
170 2013-06-15 11:53:11 <sydna> if you don't want it, donate it
171 2013-06-15 11:53:43 <kork> I can't even transfer anything out of there because of tx fees
172 2013-06-15 11:53:59 <sydna> you can often send without any fees
173 2013-06-15 11:54:11 <sipa> not such small amounts
174 2013-06-15 11:55:07 <kork> I tried satoshi dice. I'm sorry for spamming the block chain ;)
175 2013-06-15 11:58:14 <kork> anyway, again thanks for the explanations. bye
176 2013-06-15 13:46:54 <dangersalad> anyone know how to use th walletnotify option? I keep getting sh: 1 <my cammand here> not found
177 2013-06-15 13:47:46 <sipa> how do you call it?
178 2013-06-15 13:48:22 <dangersalad> walletnotify="/home/bitcoin/received %s"
179 2013-06-15 13:48:34 <dangersalad> received is an executale bash script
180 2013-06-15 13:48:42 <dangersalad> executable*
181 2013-06-15 13:49:02 <sipa> in bitcoin.conf?
182 2013-06-15 13:49:20 <dangersalad> yeah
183 2013-06-15 13:49:31 <sipa> try without the ""
184 2013-06-15 13:49:44 <dangersalad> sh: 1: /home/bitcoin/received fda26353d74389b4eb2b53c5c3d35ba3d3c2a4fe334bbb99126b800ae88???
185 2013-06-15 13:49:48 <dangersalad> 54bbf: not found
186 2013-06-15 13:50:12 <dangersalad> is what I end up getting (sorry for the split, text selected in tmux never behaves right)
187 2013-06-15 13:50:39 <sipa> it's now trying to execute the script with filename '/home/bitcoin/received fda26353d74389b4eb2b53c5c3d35ba3d3c2a4fe334bbb99126b800ae8854bbf'
188 2013-06-15 13:50:51 <sipa> as the "" are not stripped by bitcoind, and passed along to the shell
189 2013-06-15 13:52:59 <dangersalad> ah ha
190 2013-06-15 13:53:04 <dangersalad> worked like a charm, thanks
191 2013-06-15 13:56:39 <bitRipperX> what's the best way send notifications to a nodejs app using -blocknotify from the satoshi client? At the moment i'm writing to a named pipe and trying to get node to read from that pipe but it's shitty and not working consistently.
192 2013-06-15 13:56:55 <bitRipperX> socket? file? zmq?
193 2013-06-15 13:58:03 <sipa> there's a pullrequest that adds zmq support
194 2013-06-15 13:58:35 <bitRipperX> I tried the zmq build but couldn't get it to work. got tired of wasting time on it.
195 2013-06-15 13:58:44 <The_Fly> i have a working zmq fork
196 2013-06-15 13:59:00 <The_Fly> or have updated fredan's
197 2013-06-15 14:01:10 <The_Fly> he used some prefix infront of the message "block{ ... }" "transaction{ ... }" but ive opted for {type:"block", data: ... }
198 2013-06-15 14:01:25 <The_Fly> which means you can use type as a routing key for rabbitmq/amqp
199 2013-06-15 14:02:01 <The_Fly> perhaps a rabbitmq client in bitcoind would be better, but am just using message-pass to bridge zmq-rmq
200 2013-06-15 14:02:15 <The_Fly> for now
201 2013-06-15 14:10:09 <melvster> did dan kaminsky really hack he block chain?
202 2013-06-15 14:11:03 <lianj> define hack
203 2013-06-15 14:12:28 <melvster> i heard he intentionally spammed the live net with ascii art
204 2013-06-15 14:12:57 <melvster> im unsure if it's true tho
205 2013-06-15 14:13:04 <lianj> yes, but thats no hack. lots of people did it.
206 2013-06-15 14:13:07 <sydna> how is that a "hack"
207 2013-06-15 14:13:41 <lianj> melvster: the real quote from him is "I tried to hack BitCoin and failed"
208 2013-06-15 14:15:31 <melvster> im unsure of what he did, so i couldnt say one way or another at this point
209 2013-06-15 14:15:40 <melvster> just trying to find out
210 2013-06-15 14:15:46 <lianj> now you found out
211 2013-06-15 14:19:55 <melvster> hmmm still unsure ... im against block chain spam
212 2013-06-15 14:20:54 <melvster> just because many people do it, doesnt make it ok
213 2013-06-15 14:22:48 <melvster> i need to know the details to really understand
214 2013-06-15 14:23:00 <melvster> but certainly in europe there's laws against spam
215 2013-06-15 14:23:13 <sydna> email spam, specifically.
216 2013-06-15 14:24:35 <bitRipperX> The_Fly: I'm going to try it one more time. don't know if you remember but this is the correct repo right "git clone -b 0mq https://github.com/fredan/bitcoin.git"
217 2013-06-15 14:25:05 <The_Fly> hello
218 2013-06-15 14:25:24 <The_Fly> indeed, zmq branch
219 2013-06-15 14:25:36 <melvster> if he wanted to prove a point, he should have used the test net, imho
220 2013-06-15 14:25:39 <The_Fly> it should build but is not up to date
221 2013-06-15 14:25:56 <The_Fly> bitRipperX: the one i have is up to date but i've not pushed it online
222 2013-06-15 14:26:08 <The_Fly> what are you building bitRipperX?
223 2013-06-15 14:27:12 <bitRipperX> The_Fly: hmm, that's a problem. Not appropriate for a production env i suppose.
224 2013-06-15 14:27:41 <bitRipperX> The_Fly: I'm building a donation system with peer to peer and history elements thrown in.
225 2013-06-15 14:28:01 <The_Fly> interesting
226 2013-06-15 14:28:14 <bitRipperX> The_Fly: Having a bitch of a time finding a viable long term solution as this is my first time working with node.
227 2013-06-15 14:37:14 <bitRipperX> The_Fly: If you were limited to using -blocknotify on the satoshi client, how would you use it to communicate with a third party app?
228 2013-06-15 14:39:25 <The_Fly> there are many options, i guess
229 2013-06-15 14:40:31 <The_Fly> depends on your specific requirements
230 2013-06-15 14:43:05 <bitRipperX> The_Fly: if i want to notify people that have subscribed to a "channel" about a transation as close to as real time as possible
231 2013-06-15 14:43:46 <The_Fly> http://blockchain.info/api/api_websocket
232 2013-06-15 14:43:56 <The_Fly> if you dont want something in-house
233 2013-06-15 14:44:00 <bitRipperX> The_Fly: I want to scale it up to thousands of people and I don't want to hammer my satoshi client with rpc requests
234 2013-06-15 14:44:10 <sydna> it would probably be of benefit to not have every service based on blockchain.info
235 2013-06-15 14:44:11 <bitRipperX> The_Fly: i was looking at that, but I need something scalable.
236 2013-06-15 14:44:35 <sydna> that API also has horrible uptime
237 2013-06-15 14:44:36 <The_Fly> so you need your own db and queing system
238 2013-06-15 14:44:53 <The_Fly> im looking at this very thing now
239 2013-06-15 14:46:16 <The_Fly> you can scale node/socket.io/rabbitmq (or use amazon elastic load balancing, SMQ)
240 2013-06-15 14:46:30 <The_Fly> which is why the zmq branch is handy
241 2013-06-15 14:46:54 <The_Fly> no need for a process for every blocknotify/walletnotify too
242 2013-06-15 14:47:42 <The_Fly> and you'll need rpc requests to send from your wallet, obviously
243 2013-06-15 14:47:52 <The_Fly> but to query transactions etc. just defer to your internal db
244 2013-06-15 14:48:08 <sydna> big wallets don't scale.
245 2013-06-15 14:48:15 <sydna> people seem to constantly struggle with that one
246 2013-06-15 14:48:20 <sydna> bitcoind just gets slower and slower
247 2013-06-15 14:48:33 <The_Fly> that is not great, no
248 2013-06-15 14:48:34 <lianj> sydna: phantomcircuit improved that. but yea
249 2013-06-15 14:48:47 <The_Fly> how slow are we talking?
250 2013-06-15 14:48:59 <bitRipperX> The_Fly: how much effort did it take to get the zmq branch up to date?
251 2013-06-15 14:49:01 <sydna> uhm, btct.co was struggling recently
252 2013-06-15 14:49:11 <sydna> response times in the seconds
253 2013-06-15 14:49:16 <The_Fly> bitRipperX: not much, and i dont mind sharing mine
254 2013-06-15 14:49:21 <The_Fly> this is a charity project?
255 2013-06-15 14:49:26 <The_Fly> i'll msg you...
256 2013-06-15 14:50:00 <sydna> response times of the bitcoind process, that is
257 2013-06-15 14:51:52 <bitRipperX> The_Fly: charity? you mean open source? Yeah, I want bitcoin to have wider adoption so this is sort of a fun project to get learn how to bild something production level and further the cause at the same time.
258 2013-06-15 14:52:25 <The_Fly> i am working along the same lines...
259 2013-06-15 14:52:30 <bitRipperX> ah you mean will it be used for charities? yeah, I see that being the main target audience. but anyone can use it on their site I suppose.
260 2013-06-15 14:52:35 <The_Fly> doing something that just gets people interested
261 2013-06-15 14:52:54 <The_Fly> what i mean is, do you intend on making any profit? lol
262 2013-06-15 14:54:22 <bitRipperX> The_Fly: from this project, probably not, but I dream of quitting my job and doing something bitcoin related. I'm tired of working for the man. haha.
263 2013-06-15 14:55:23 <The_Fly> indeed ;)
264 2013-06-15 14:55:35 <sipa> the man?
265 2013-06-15 14:55:45 <The_Fly> you know... that man
266 2013-06-15 14:55:55 <The_Fly> that everyone works for
267 2013-06-15 14:57:02 <bitRipperX> It's an american colloquialism. working for the establishment.
268 2013-06-15 14:57:30 <The_Fly> https://en.bitcoin.it/wiki/Bitcoin_Church
269 2013-06-15 14:57:38 <The_Fly> praise satoshi
270 2013-06-15 14:58:31 <lianj> troll harder
271 2013-06-15 15:01:36 <The_Fly> :)
272 2013-06-15 15:02:28 <Corndawg> why so many blocks so quickly?
273 2013-06-15 15:02:44 <sydna> luck.
274 2013-06-15 15:03:25 <sipa> the global miner cabal has decided to start hashing faster, as of today
275 2013-06-15 15:03:53 <sydna> your graphs are looking ridiculous at the moment, sipa
276 2013-06-15 15:07:03 <matjeh> its never this fast when i need transactions confirmed
277 2013-06-15 15:07:05 <matjeh> never
278 2013-06-15 15:10:46 <sipa> sydna: what's ridiculous about them?
279 2013-06-15 15:11:11 <sydna> sipa: nothing to do with the graphs themselves, just the content is a little amusing
280 2013-06-15 15:11:40 <sipa> right
281 2013-06-15 15:11:50 <sydna> http://bitcoin.sipa.be/speed-small-lin.png ??? this one, where the difficulty has a long way to catch up
282 2013-06-15 15:12:22 <sipa> well, my algorithm is known to overshoot in case of spiky sudden hashrate changes
283 2013-06-15 15:12:43 <sipa> it's very accurate in case of ~constant growth
284 2013-06-15 15:13:32 <sydna> the algorithm for drawing the graph, or the internal target in bitcoind?
285 2013-06-15 15:14:12 <The_Fly> maybe bfl shipped :P
286 2013-06-15 15:14:21 <sydna> given that the hash rate is approaching vertical, I don't think the spike will have much effect
287 2013-06-15 15:23:04 <sipa> sydna: my algorithm for estimating the hashrate
288 2013-06-15 15:23:12 <sipa> it's intended to compensate for growth
289 2013-06-15 15:23:29 <sydna> gotcha.
290 2013-06-15 15:23:47 <sipa> it results in a maximum likelyhood result assuming the actual hashrate is an exponential function
291 2013-06-15 15:26:44 <sydna> I'm impressed with the number, no matter how inaccurate
292 2013-06-15 15:26:53 <sipa> same!
293 2013-06-15 15:27:14 <sydna> 125TH is just.. unbelievable. I've no point of reference to imagine just how fast that is
294 2013-06-15 15:28:17 <sydna> google tells me that it is 31250000 times the hashrate my macbook can sustain, but even that is stupid.
295 2013-06-15 16:57:42 <michagogo> What is the -txindex command-line option?
296 2013-06-15 17:00:17 <sipa> michagogo: it enables the transaction index
297 2013-06-15 17:00:25 <sipa> so you can use getrawtransaction
298 2013-06-15 17:00:44 <michagogo> Oh, on any transaction?
299 2013-06-15 17:00:52 <sipa> yes
300 2013-06-15 17:01:12 <sipa> except the genesis block's coinbase
301 2013-06-15 17:01:13 <michagogo> Which transactions does that work on at the moment?
302 2013-06-15 17:01:25 <michagogo> Just wallet and mempool, with this enabling it for blockchain as well?
303 2013-06-15 17:01:47 <sipa> normally it works with not fully spent transactions, or mempool transactions
304 2013-06-15 17:01:54 <sipa> wallet is irrelevant
305 2013-06-15 17:02:35 <michagogo> Ah, so it pulls from mempool and utxo?
306 2013-06-15 17:02:45 <sipa> yes
307 2013-06-15 17:02:57 <sipa> perhaps it should also pull from the wallet
308 2013-06-15 17:03:02 <michagogo> (is utxo just what's in the blockchain?)
309 2013-06-15 17:03:23 <sipa> yes, but it doesn't contain spent transactions
310 2013-06-15 17:03:31 <sipa> and it's many times smaller
311 2013-06-15 17:03:39 <michagogo> Right, ofc
312 2013-06-15 17:03:44 <michagogo> Also, how big are these transaction indices?
313 2013-06-15 17:04:35 <sipa> ~ 1 GB
314 2013-06-15 17:04:45 <sipa> (+ slower sync)
315 2013-06-15 17:05:28 <TheLordOfTime> sipa:  in the blocks db for bitcoin-qt, what's the largest file size of any individual file in that?
316 2013-06-15 17:05:44 <TheLordOfTime> asking because i need to figure out how to format the drive i'm going to use to move the thing from one system to another.
317 2013-06-15 17:06:02 <sipa> TheLordOfTime: new files shouldn't be larger than 128 MiB
318 2013-06-15 17:06:19 <TheLordOfTime> sipa:  good so i don't have to worry about anything being over 4 GB in size?
319 2013-06-15 17:06:39 <sipa> though the size of leveldb files isn't entirely under our control; if you set a ridiculously large dbcache (like 10s of GB), you could end up with log files that are above 4 GB
320 2013-06-15 17:07:05 <TheLordOfTime> yeah was afraid of that
321 2013-06-15 17:07:08 <TheLordOfTime> 
ACTION formats NTFS

322 2013-06-15 17:07:23 <sipa> by ridiculously, i mean that setting it that high would be ridiculous
323 2013-06-15 17:07:27 <TheLordOfTime> oh of course
324 2013-06-15 17:07:28 <sipa> by default it's 25 MB
325 2013-06-15 17:07:47 <sipa> though setting it to something like 1 GB improves performance significantly
326 2013-06-15 17:08:09 <TheLordOfTime> configurable setting or hard-coded?
327 2013-06-15 17:08:33 <sipa> configurable
328 2013-06-15 17:08:37 <sipa> -dbcache=X setting
329 2013-06-15 17:08:40 <sipa> with X in MiB
330 2013-06-15 17:09:30 <TheLordOfTime> ah so at-runtime arguments.
331 2013-06-15 17:10:55 <TheLordOfTime> makes sense.  thanks.
332 2013-06-15 17:11:39 <TheLordOfTime> sipa:  and if i'm copying the blockchain from one client to another i only need the %datadir%/.bitcoin/blocks/* folder right?
333 2013-06-15 17:11:45 <TheLordOfTime> or do i need anything else copied?
334 2013-06-15 17:13:36 <michagogo> TheLordOfTime: If you trust your copy, also take chainstate and blkindex.dat
335 2013-06-15 17:14:15 <michagogo> Not sure what .bitcoin/blk0001.dat is, though
336 2013-06-15 17:14:32 <TheLordOfTime> is it a problem if blkindex.dat == nonexistent?
337 2013-06-15 17:15:04 <grau> is there a working testnet block explorer around?
338 2013-06-15 17:15:06 <michagogo> TheLordOfTime: That's the block index, as the name implies
339 2013-06-15 17:15:17 <grau> http://blockexplorer.com/testnet is stuck at 20. May
340 2013-06-15 17:15:23 <TheLordOfTime> michagogo: tbh i just don't want to have to download two months of block data on the other client and wouldn't mind giving it a kickstart
341 2013-06-15 17:15:24 <michagogo> TheLordOfTime: Basically, that forces the equivalent of -reindex when you next start
342 2013-06-15 17:15:49 <michagogo> TheLordOfTime: You *can* just take the blocks folder (or bootstrap.dat)
343 2013-06-15 17:16:11 <michagogo> TheLordOfTime: If you take blkindex.dat, you can also save the time it takes to reindex
344 2013-06-15 17:17:49 <HaltingState> how many bytes is a bitcoin signature
345 2013-06-15 17:18:11 <TheLordOfTime> wheee, 10.1GB copy >.>
346 2013-06-15 17:18:23 <TheLordOfTime> 
ACTION loves his 16GB flash drives :P

347 2013-06-15 17:19:34 <sipa> HaltingState: 72 bytes
348 2013-06-15 17:19:59 <HaltingState> sipa, what is size of uncompressed private key
349 2013-06-15 17:20:14 <sipa> 32 bytes; private keys are never compressed
350 2013-06-15 17:20:35 <sipa> but you need a one bit state to know whether the corresponding public key is supposed to be compressed or not
351 2013-06-15 17:21:45 <HaltingState> sipa, I am getting 214 bytes for private key when i enable compression and 279 bytes without compression
352 2013-06-15 17:21:53 <HaltingState> for NID_secp256k1
353 2013-06-15 17:21:55 <HaltingState> am i doing something wrong
354 2013-06-15 17:21:59 <sipa> no
355 2013-06-15 17:22:08 <sipa> that's OpenSSL's DER encoded private keys
356 2013-06-15 17:22:24 <sipa> it contains private key, public key, field parameters, curve parameters and generator point
357 2013-06-15 17:22:28 <sipa> but you only need 32 bytes
358 2013-06-15 17:22:33 <HaltingState> how do i go from that to a 32 byte one?
359 2013-06-15 17:26:19 <grau> sipa: http://blockexplorer.com/testnet is stuck since more than 4000 blocks. Is there an other?
360 2013-06-15 17:26:41 <sipa> grau: not afaik
361 2013-06-15 17:28:38 <grau> There will be one in a few days. Working on it. I recognized that this does not work as I tried to reconcile
362 2013-06-15 18:43:14 <jiffe1> so in the GetDifficulty, double dDiff = (double)0x0000ffff / (double)(blockindex->nBits & 0x00ffffff); as nbits goes up diff goes down?
363 2013-06-15 18:44:41 <sipa> nBits is an encoded form for the target
364 2013-06-15 18:44:53 <sipa> using an exponent/mantissa representation
365 2013-06-15 18:45:03 <sipa> and when the target goes down, the difficulty goes up yes
366 2013-06-15 18:51:21 <TheUni> warren: around?
367 2013-06-15 19:02:27 <phantomcircuit> sipa, i think changing the key format in the wallet is generally a good idea
368 2013-06-15 19:02:37 <phantomcircuit> a serialized CKey is the secret right?
369 2013-06-15 19:03:26 <sipa> yes, just the 32 bytes
370 2013-06-15 19:04:17 <sipa> i'm thinking about ("key",cpubkey) -> ckey,hash(cpubkey+ckey),metadata
371 2013-06-15 19:04:36 <sipa> probably some header byte to be able to distinguish it from the old format
372 2013-06-15 19:05:08 <sipa> another possibility is a full new entry altogether, including from encrypted keys
373 2013-06-15 19:05:18 <sipa> *for
374 2013-06-15 19:06:39 <pro-tech> New LiteCoin Mining Pool with only 10 confirms http://ltc.pro-tech.bz.it
375 2013-06-15 19:15:35 <TheLordOfTime> sipa:  is there any harm in me rsync-ing the blockchain using rsync incremental updates *while* bitcoind / bitcoin-qt is running?
376 2013-06-15 19:15:58 <sipa> TheLordOfTime: the block data files, no
377 2013-06-15 19:16:03 <sipa> TheLordOfTime: the databases, yes
378 2013-06-15 19:16:32 <lupine> well, as long as the final rsync is when the source is turned off, and the destination isn't turned on until after then, all should work
379 2013-06-15 19:16:43 <sipa> sure
380 2013-06-15 19:29:39 <melvster> an interesting set of papers ... no other comments ... http://www.informatik.uni-trier.de/~ley/pers/hd/o/Okamoto:Tatsuaki.html
381 2013-06-15 19:30:01 <melvster> Tatsuaki Okamoto, An Efficient Divisible Electronic Cash Scheme, Advances in Cryptology
382 2013-06-15 19:30:18 <melvster> Tony Eng and Tatsuaki Okamoto, Single-Term Divisible Electronic Coins, Advances in Cryptology
383 2013-06-15 19:30:35 <melvster> Tatsuaki Okamoto and Kazuo Ohta, Universal Electronic Cash, Advances in Cryptology
384 2013-06-15 19:30:58 <melvster> Eiichiro Fujisaki, Tatsuaki Okamoto: Practical Escrow Cash System
385 2013-06-15 19:31:09 <melvster> Tatsuaki Okamoto, Atsushi Fujioka, Eiichiro Fujisaki: An Efficient Digital Signature Scheme Based on an Elliptic Curve
386 2013-06-15 19:31:31 <melvster> perhaps this guy would be interested in bitcoin :)
387 2013-06-15 19:31:54 <melvster> cc amiller_ sipa ^^
388 2013-06-15 19:32:22 <sipa> eh who knows?
389 2013-06-15 19:32:35 <sipa> ask him :p
390 2013-06-15 20:31:48 <phantomcircuit> sipa, generally i could think using a new identifier for a new format would be a good idea, the only reason i didn't was that appending the hash is backwards compatible
391 2013-06-15 20:31:56 <phantomcircuit> s/could/would/
392 2013-06-15 20:32:42 <phantomcircuit> sipa, possibly introducing a new format with a version number
393 2013-06-15 20:32:51 <melvster> phantomcircuit: new identifier format?  for what?
394 2013-06-15 20:32:51 <phantomcircuit> or maybe just calling it key2
395 2013-06-15 20:33:00 <phantomcircuit> melvster, wallet keys
396 2013-06-15 20:33:14 <melvster> public, private, or the hash of the public key?
397 2013-06-15 20:33:18 <phantomcircuit> the current format is unnecessarily bloated
398 2013-06-15 20:33:27 <phantomcircuit> <sipa> i'm thinking about ("key",cpubkey) -> ckey,hash(cpubkey+ckey),metadata
399 2013-06-15 20:33:49 <phantomcircuit> currently it's ("key", cPubKey) -> cPrivKey
400 2013-06-15 20:34:11 <phantomcircuit> cPrivKey is a DER encoded private key/public key
401 2013-06-15 20:34:40 <phantomcircuit> which is almost entirely unnecessary
402 2013-06-15 20:34:52 <melvster> phantomcircuit: would this mean changing bitcoin address, or something else?
403 2013-06-15 20:35:50 <phantomcircuit> melvster, no?
404 2013-06-15 20:35:58 <phantomcircuit> this would just make loading the wallet faster
405 2013-06-15 20:36:06 <melvster> oh right
406 2013-06-15 20:36:15 <melvster> cool
407 2013-06-15 20:44:15 <warren> TheUni: ?
408 2013-06-15 21:04:27 <phantomcircuit> melvster, i already changed a bunch of stuff which massively reduced the time to load, but if we're gonna change it best to change it to something better
409 2013-06-15 21:04:52 <melvster> great
410 2013-06-15 21:10:44 <Luke-Jr> any forum admins here?
411 2013-06-15 21:18:41 <Luke-Jr> BitForce SC firmware source code released: http://bitcointroll.org/?topic=235312
412 2013-06-15 22:09:21 <warren> petertodd: ping
413 2013-06-15 22:53:40 <amiller_> mevster, i assume you're saying because he's a cryptographer with a japanese name :3
414 2013-06-15 23:35:30 <wizkid057> there a way to remove/consolidate accounts yet?