1 2012-02-21 00:00:06 <Raccoon> or at least, how quickly they're moved
  2 2012-02-21 00:01:21 <nanotube> try blockexplorer. :P
  3 2012-02-21 00:01:27 <Raccoon> um, no.
  4 2012-02-21 00:01:53 <Raccoon> real time network map/mesh
  5 2012-02-21 00:02:03 <Raccoon> 2, 3, 4, 5 nodes out
  6 2012-02-21 00:02:34 <sipa> you're talking about TCP/IP network monitoring
  7 2012-02-21 00:02:39 <sipa> or coin monitoring?
  8 2012-02-21 00:02:42 <Raccoon> coin
  9 2012-02-21 00:03:25 <sipa> not really much of a network mesh to speak of then
 10 2012-02-21 00:03:36 <Raccoon> or it could expand nodes until 'your' coins become diluted to a certain factor
 11 2012-02-21 00:03:46 <sipa> yes
 12 2012-02-21 00:03:52 <Raccoon> eg, they'd quickly disappear when sent to mtgox
 13 2012-02-21 00:04:14 <Raccoon> or they might travel from new address to new address for quite some time
 14 2012-02-21 00:04:46 <smickles> almost there
 15 2012-02-21 00:05:21 <smickles> hmm
 16 2012-02-21 00:05:24 <smickles> santorum
 17 2012-02-21 00:05:34 <smickles> :D
 18 2012-02-21 00:05:35 <Raccoon> -.-
 19 2012-02-21 00:06:07 <smickles> Raccoon: you please me :)
 20 2012-02-21 00:08:50 <Raccoon> hmm.  i think the tooltip "Unconfirmed (2 of 6 confirmations)" is a little misleading
 21 2012-02-21 00:11:29 <smickles> sipa, gmaxwell, luke-jr, just thought i'd let ya'll know, my problem is officially solved
 22 2012-02-21 00:11:51 <Raccoon> smickles: that link solved all your problems?
 23 2012-02-21 00:12:11 <smickles> Raccoon: yes, laughter is the best medicine
 24 2012-02-21 00:20:55 <Raccoon> hmm
 25 2012-02-21 00:21:19 <gmaxwell> smickles: what solved your problem?
 26 2012-02-21 00:21:54 <smickles> reloading the blockchain gmaxwell
 27 2012-02-21 00:21:57 <Raccoon> in the script process for transfering bitcoins, would any of the cryptographic exchange permit for the sharing or release of a key that can be used elsewhere?
 28 2012-02-21 00:27:30 <gmaxwell> Raccoon: you can create transactions whos release depends on the disclosure of a value.
 29 2012-02-21 00:28:08 <Raccoon> by withholding part of the key?
 30 2012-02-21 00:28:14 <gmaxwell> E.g. make a transaction that can only be spent by someone discloses X such that H(X)=y for some y specified in the txn.
 31 2012-02-21 00:28:47 <Raccoon> interesting
 32 2012-02-21 00:29:45 <Raccoon> but are there any unique values that would only be known to the sender and the receiver of a transaction, due to their private knowledge of their own respective private keys?
 33 2012-02-21 00:30:31 <etotheipi_> racoon, look up diffie-hellman shared secrets
 34 2012-02-21 00:30:31 <Raccoon> or that is known by the receiver and revealed to the sender, or other similar scenario
 35 2012-02-21 00:31:06 <etotheipi_> if I only have my private key and your public key, I can compute the same value as you compute with your private key and my public key
 36 2012-02-21 00:31:13 <etotheipi_> but people with only the public keys cannot compute that value
 37 2012-02-21 00:31:31 <Raccoon> oh nice
 38 2012-02-21 00:32:01 <Raccoon> that could be handy for network message exchange, perhaps
 39 2012-02-21 00:32:09 <etotheipi_> mathematically speaking, a private key is a scalar a, and public key is a*G where G is a point on an elliptic curve
 40 2012-02-21 00:32:22 <etotheipi_> so I have a, and give you a*G, you have b and give me b*G
 41 2012-02-21 00:32:41 <etotheipi_> we can both computer a*b*G... but you cannot get there with only (a*G) and (b*G)
 42 2012-02-21 00:33:36 <Raccoon> nice explanation
 43 2012-02-21 00:34:40 <gmaxwell> Raccoon: its not useful for message exchange when you don't know the other parties actual public key.
 44 2012-02-21 00:34:57 <Raccoon> what about a value that could only be known to the sender, if they send a precise number of btc, that the receiver can compute well in advance
 45 2012-02-21 00:35:06 <etotheipi_> oh yeah... all parties have to know all other party's public keys, which isn't usually the case in Bitcoin
 46 2012-02-21 00:35:17 <Raccoon> ah
 47 2012-02-21 00:35:43 <etotheipi_> but it's not prohibitive either:  if we want to initiate this exchange, we just send each other public keys over email
 48 2012-02-21 00:36:03 <Raccoon> well, without leaving the bitcoin network
 49 2012-02-21 00:36:32 <Raccoon> say, if each client (optionally) queued a message exchange for N days
 50 2012-02-21 00:36:35 <etotheipi_> if an address has ever spent money on the network, you can get its public key (because it's part of the sending script)
 51 2012-02-21 00:37:15 <etotheipi_> but at some point you had to exchange addresses... why not just exchange public keys instead?
 52 2012-02-21 00:38:07 <Raccoon> address exchange could be remote as grabbing a QR-Code from some random location in absence of the owner
 53 2012-02-21 00:39:36 <Raccoon> why have two QR-Codes, one for receiving bitcoins, and one for messaging
 54 2012-02-21 01:32:08 <Raccoon> ug.  what's wrong with Window's bitcoind.exe that this command doesn't work?
 55 2012-02-21 01:32:10 <Raccoon> bitcoind.exe -? > bitcoind.txt
 56 2012-02-21 02:06:14 <phantomcircuit> Raccoon, try --help
 57 2012-02-21 02:06:45 <Raccoon> no dice
 58 2012-02-21 02:06:59 <Raccoon> still spits out to the console instead of the file.
 59 2012-02-21 02:07:05 <Raccoon> a zero byte file IS created.
 60 2012-02-21 02:12:23 <phantomcircuit> Raccoon, oh it's printing to stderr
 61 2012-02-21 02:12:39 <phantomcircuit> Raccoon, you need to redirect that... no idea how to do that in windows shell
 62 2012-02-21 02:13:08 <Raccoon> could that be considered a bug?
 63 2012-02-21 02:18:37 <phantomcircuit> Raccoon, no it's fairly standard to write help to stderr
 64 2012-02-21 02:18:54 <phantomcircuit> although maybe the behavior should be changed on windows
 65 2012-02-21 02:18:54 <Raccoon> first time i've seen it.
 66 2012-02-21 02:19:04 <Raccoon> eg, wget --help > wget.txt
 67 2012-02-21 02:21:11 <unclemantis> how can i get a record of the percentage of block solved by a particular mining pool?
 68 2012-02-21 02:22:17 <unclemantis> the last block was solved by deepbit. I want to know how often deepbit solves a block compared to the others since deepbit started
 69 2012-02-21 02:29:02 <Raccoon> blocks aren't solved incrimentally
 70 2012-02-21 02:29:09 <Raccoon> they are either solved or not
 71 2012-02-21 02:29:32 <unclemantis> i want to see how many deepbit solved
 72 2012-02-21 02:29:43 <Raccoon> that i don't know
 73 2012-02-21 02:32:47 <unclemantis> :
 74 2012-02-21 02:34:06 <Raccoon> would be nice if people, especially those with huge rigs, stopped using mining pools
 75 2012-02-21 02:34:22 <Raccoon> there's really very litte point unless you like losing money
 76 2012-02-21 02:34:41 <unclemantis> true
 77 2012-02-21 02:35:06 <unclemantis> i am getting this error while trying to send bitcoin from a client String ending with 'xea' can't be PCKS7-padded
 78 2012-02-21 02:35:31 <Raccoon> only plausable use for a pool is if you're installing mining software on thousands of desktops and don't care how slow they operate
 79 2012-02-21 02:36:06 <unclemantis> i am trying to send to this address 16edt3bc5D82HHnr7BtiQ1VWeYGo1dAnkx
 80 2012-02-21 02:36:19 <Raccoon> if you're just one of those slow desktops, why even bother.  can't do much with 0.0001 BTC every 3 weeks
 81 2012-02-21 02:37:36 <Raccoon> character ??
 82 2012-02-21 02:38:14 <unclemantis> what?
 83 2012-02-21 02:38:20 <Raccoon> that's xea
 84 2012-02-21 02:38:30 <unclemantis> well i don't see that in the address
 85 2012-02-21 02:38:33 <Raccoon> no idea what that is
 86 2012-02-21 02:38:36 <Graet> Raccoon, what is your hashrate?
 87 2012-02-21 02:38:44 <Raccoon> gribble: kilobits
 88 2012-02-21 02:38:48 <Raccoon> er Graet
 89 2012-02-21 02:38:56 <Graet> k..
 90 2012-02-21 02:39:02 <Raccoon> er kilohash
 91 2012-02-21 02:39:06 <Graet> yer
 92 2012-02-21 02:39:38 <Graet> what proof do you have that mining on pools "loses" miners money?
 93 2012-02-21 02:39:56 <Raccoon> Graet: um. simple and obvious economics
 94 2012-02-21 02:39:59 <imsaguy> 'pool fees'
 95 2012-02-21 02:40:12 <Graet> not all pools take fees...
 96 2012-02-21 02:40:12 <Raccoon> if the mining pool is earning money, you are losing it.
 97 2012-02-21 02:40:18 <Graet> lol
 98 2012-02-21 02:40:26 <Raccoon> name one
 99 2012-02-21 02:40:33 <Graet> one what?
100 2012-02-21 02:40:36 <unclemantis> is this a VALID address? 16edt3bc5D82HHnr7BtiQ1VWeYGo1dAnkx
101 2012-02-21 02:40:45 <Raccoon> one mining pool that doesn't collect fees
102 2012-02-21 02:40:50 <denisx> my pool did not take any fee
103 2012-02-21 02:40:54 <denisx> but that was before PPS
104 2012-02-21 02:40:58 <Graet> ozcoin - the one i run....
105 2012-02-21 02:41:16 <Raccoon> denisx: they didn't even keep transaction fees for themself?
106 2012-02-21 02:41:17 <Graet> only did for 1st few weeks of operation, back in june
107 2012-02-21 02:41:47 <denisx> Raccoon: No, you could mine without any fee on my pool
108 2012-02-21 02:41:51 <Graet> when ozcoin was a prop pool we also payed out txn fees and will be again soon on dgm, it isnt as trivial to work out
109 2012-02-21 02:42:38 <Graet> and there are other 0 fee pools paying out txn included wityh blocks, i suggest you do some more research before spreading fud, cheers :)
110 2012-02-21 02:42:40 <denisx> Raccoon: yes, we kept the transaction fees
111 2012-02-21 02:42:43 <Raccoon> denisx: so the operator has zero incentive to maintain the pool/
112 2012-02-21 02:42:56 <denisx> but we also paid a fee for the payouts
113 2012-02-21 02:43:01 <Graet> depends on what you call "incentive"
114 2012-02-21 02:43:32 <Graet> thinking bitcoin is awesome and wanting to do something to promote it and help it succedd?
115 2012-02-21 02:43:43 <Raccoon> denisx: evened out?
116 2012-02-21 02:43:57 <Raccoon> that's fine Graet
117 2012-02-21 02:44:01 <Graet> the fact that by providing a great fee free pool miners are choosing nto donate to the service?
118 2012-02-21 02:44:08 <Raccoon> but mining pools don't help it succeed.
119 2012-02-21 02:44:14 <denisx> Raccoon: now with 4% donation with PPS we are more or less even
120 2012-02-21 02:44:19 <Graet> that is your opinio yep
121 2012-02-21 02:44:57 <Raccoon> so mining pools are really only good for clocking up the block chain
122 2012-02-21 02:45:09 <Graet> clocking up the block chain?
123 2012-02-21 02:45:15 <Raccoon> every block solved guarantees 10,000 new transactions
124 2012-02-21 02:45:25 <Raccoon> as people are paid
125 2012-02-21 02:45:33 <Graet> actually most new bitcoin miners find pools a good place to start, most have easy setup and support
126 2012-02-21 02:45:54 <Graet> blocks will get mined if thewre are pools or not, as long as there are miners
127 2012-02-21 02:46:24 <Raccoon> just saying those meta-transactions are a waste of my harddisk space
128 2012-02-21 02:46:31 <Graet> um, no most pools use sendmany when they pay out and i dont think any havbe 10,000 users to pay at a time
129 2012-02-21 02:46:36 <Raccoon> transactions to facilitate mining of transactions
130 2012-02-21 02:46:42 <Graet> 'but nkjeep goingh , research isnt your strong point?
131 2012-02-21 02:46:54 <Raccoon> maybe they don't, today
132 2012-02-21 02:47:07 <Raccoon> whatever the numbers, it's still wonky.
133 2012-02-21 02:47:09 <denisx> Raccoon: payouts get accumulated
134 2012-02-21 02:47:33 <denisx> deepbit does not use sendtomany
135 2012-02-21 02:51:31 <Graet> lol Raccoon if you truly feel like that p2p pool, but please do some research BEFORE making blanket statements  about pools, i was and still am a miner, i opened the pool for miners - like many other pool ops
136 2012-02-21 02:51:45 <Graet> going out now have nice days guys :)
137 2012-02-21 03:04:33 <etotheipi_> is there a name for the private key format [0x80 | 32B priv | 4B checksum]?
138 2012-02-21 04:23:48 <JFK911> help
139 2012-02-21 04:23:51 <JFK911> cmp (a0,d5.l),d7
140 2012-02-21 04:23:52 <JFK911> this is a0+d5 bytes or words?
141 2012-02-21 04:24:17 <JFK911> i don't know if .l tells me the alignment or the width of the operation :(
142 2012-02-21 04:25:02 <JFK911> oh duh
143 2012-02-21 04:25:03 <JFK911> cmp.b
144 2012-02-21 05:04:21 <pickett> is it possible to use bitcoin-qt to connect to a bitcoind on another computer?
145 2012-02-21 05:05:14 <tcatm> If you want to use it as a frontend, no.
146 2012-02-21 05:22:31 <seco> pickett: but if you just want it to connect to the other bitcoin-client start it with -addnode or -connect and add local or internet-ip of the other computer!
147 2012-02-21 05:24:06 <pickett> and the transactions of the remote client will show up in the local bitcoin-qt client?
148 2012-02-21 05:25:51 <tcatm> Nope.
149 2012-02-21 05:27:34 <seco> next new user being confused by the network icon: someone needs to make the last row  green ..when all connections are reached :P
150 2012-02-21 05:27:46 <seco> on the bitcoin-qt client^^
151 2012-02-21 05:29:13 <BlueMatt> all but the last icon is normal for people who havnt properly forwarded their ports
152 2012-02-21 05:29:29 <BlueMatt> if you have forwarded port 8333 on your router to your bitcoin node, all the bars should light up after a while
153 2012-02-21 05:29:33 <pickett> it doesn't lite up all the way if you're nehind a nat
154 2012-02-21 05:29:39 <BlueMatt> exactly
155 2012-02-21 05:29:44 <BlueMatt> so you need to forward port 8333
156 2012-02-21 05:29:50 <BlueMatt> (enable upnp, do it manually, etc)
157 2012-02-21 05:33:03 <seco> never said there is no deeper logic behind it; just a bit criticism from "default user view": being operator for many years i would say there are very view people not behind a NAT nowadays on the main countries where bitcoin is widespread
158 2012-02-21 05:34:12 <BlueMatt> so they should enable upnp...
159 2012-02-21 05:34:20 <BlueMatt> (if you mean isp-level nat, they should get ipv6)
160 2012-02-21 05:39:46 <seco> i mean customers: in my opinion most are behin nat and firewalled routers nowadays...they simply just dont know
161 2012-02-21 05:39:53 <seco> behind*
162 2012-02-21 05:40:58 <seco> from inuitive point of view i would make all rows green when bitcoin-qt managed to get connected to the nodes he is deemed to
163 2012-02-21 05:43:18 <BlueMatt> Many torrent clients also put up a red flag if they dont have ports forwarded properly
164 2012-02-21 05:43:25 <BlueMatt> the lack of the last row indicates that there is a problem
165 2012-02-21 05:43:42 <BlueMatt> the popup probably should ask users to forward their ports, but...
166 2012-02-21 05:44:06 <BlueMatt> also, since upnp is enabled by default on bitcoin-qt and most consumer-level routers, it not working is a problem
167 2012-02-21 05:45:53 <seco> but i agree on your argumentation as well...its not me you have to convince :)
168 2012-02-21 05:46:18 <CRichard> has anyone ever suggested distributing parts of the block chain automatically by bittorrent protocol?
169 2012-02-21 05:46:23 <CRichard> guessing someone has?
170 2012-02-21 05:46:51 <BlueMatt> I used to always get requests to distribute torrents when I was releasing block chain snapshots
171 2012-02-21 05:46:57 <BlueMatt> but it really isnt worth it...
172 2012-02-21 05:47:27 <CRichard> no, I'm suggesting actually building bittorrent protocol into the reference client
173 2012-02-21 05:47:32 <BlueMatt> I mean you could do a new torrent, say, once a month, but then its always out of date
174 2012-02-21 05:47:35 <BlueMatt> ...
175 2012-02-21 05:47:44 <CRichard> so the clients can easily pick up the large chain from the network without overloading the actual transaction exchange network
176 2012-02-21 05:47:48 <BlueMatt> how is that any different from the current protocol...
177 2012-02-21 05:48:01 <BlueMatt> we go from a p2p network distributing blocks to...
178 2012-02-21 05:48:06 <BlueMatt> a p2p network distributing blocks...
179 2012-02-21 05:48:13 <CRichard> bittorrent is more specialized for distributing large amounts of data?
180 2012-02-21 05:48:26 <BlueMatt> no its not
181 2012-02-21 05:48:35 <BlueMatt> also, we have very small amounts of data
182 2012-02-21 05:48:37 <CRichard> idk specifics but I can download a 4 gb iso in a very short amount of time, but the chain takes days on a fresh install
183 2012-02-21 05:48:48 <seco> CRichard: distribution is not the bottleneck why it takes so long to get sync with the network after initial start; i guess if someone keeps http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/ up2date from year to year is enough
184 2012-02-21 05:48:50 <CRichard> chain is now a gb
185 2012-02-21 05:48:59 <BlueMatt> the chain takes long to download not because its slow, but because it has to check each block as it comes in
186 2012-02-21 05:49:07 <CRichard> ah hm
187 2012-02-21 05:49:22 <BlueMatt> even if we switched to another protocol, it would still be just as slow because we have to check the chain
188 2012-02-21 05:49:36 <BlueMatt> unless you want to go to a centralized system where everyone trusts the chain one node gives them...
189 2012-02-21 05:49:36 <tcatm> Are we still downloading from a single peer?
190 2012-02-21 05:49:37 <CRichard> ok, I see
191 2012-02-21 05:49:45 <BlueMatt> tcatm: yea, usually, so?
192 2012-02-21 05:49:52 <seco> the bottleneck is the local validation of ALL transactions of the current block you downloaded from the bitcoinnetwork: just start with 0 on a ramdrive, and youre donw after 2hours from what i hear :D
193 2012-02-21 05:50:03 <tcatm> Maybe that peer has a slow uplink...
194 2012-02-21 05:50:13 <BlueMatt> tcatm: it happens, but that is really rare
195 2012-02-21 05:50:38 <BlueMatt> tcatm: blocks are so small to begin with...
196 2012-02-21 05:50:49 <CRichard> someone had a suggestion that milestones be encoded regularly into the chain at interval, so that new clients didnt have to recheck the whole chain
197 2012-02-21 05:50:55 <tcatm> Sure, but it's still a huge chain.
198 2012-02-21 05:51:00 <BlueMatt> CRichard: already done
199 2012-02-21 05:51:03 <CRichard> really?
200 2012-02-21 05:51:11 <CRichard> is that being put into the reference client? or already in?
201 2012-02-21 05:51:34 <BlueMatt> CRichard: yea, bitcoin has been skipping checking the signatures in txes up to newest checkpoint for a long time now
202 2012-02-21 05:51:38 <BlueMatt> since like 0.4 or smth
203 2012-02-21 05:51:57 <tcatm> So 50ms longer downloadtime per block will be significant
204 2012-02-21 05:52:01 <CRichard> so then why does it still take so long to get the chain on a fresh install?
205 2012-02-21 05:52:33 <BlueMatt> tcatm: meh, we still spend 95% of our time checking blocks, so even if we cut down the chain download times, we only go up a tiny percent
206 2012-02-21 05:52:46 <BlueMatt> (unless your download peer is on ie 24k modem or smth...)
207 2012-02-21 05:52:58 <BlueMatt> CRichard: because there are other things that are required when checking the chain that we cant skip
208 2012-02-21 05:53:18 <BlueMatt> they can be sped up, but not really skipped
209 2012-02-21 05:53:57 <tcatm> Where did you get that 95% number from?
210 2012-02-21 05:54:07 <seco> CRichard: if you dont check the chain for your own, you never know how many coins are linked to your bitcoins currently: it might be possible someone send you bitcoins, but your wallet does not know it if client does not scan for transactions related to your adresses
211 2012-02-21 05:54:24 <seco> ehh linked to your bitcoin-addreses *hiding*
212 2012-02-21 05:54:26 <BlueMatt> tcatm: 89% of statistics are pulled out of my ass
213 2012-02-21 05:54:33 <CRichard> ah right, I see
214 2012-02-21 05:54:53 <CRichard> is this scanning for your own coins/addresses what now takes so much time?
215 2012-02-21 05:55:07 <BlueMatt> tcatm: but that seems realistic based on my watching debug.log fly by when downloading from the network...
216 2012-02-21 05:55:14 <BlueMatt> CRichard: nope
217 2012-02-21 05:55:16 <tcatm> Last time I checked a recent build could sync pretty fast on a loopback device.
218 2012-02-21 05:55:44 <CRichard> so what then does?
219 2012-02-21 05:55:52 <BlueMatt> CRichard: though that does take some time, its not anything huge (maybe like 5-10% on a medium-sized wallet)
220 2012-02-21 05:56:01 <BlueMatt> tcatm: and that one Ive actually benchmarked
221 2012-02-21 05:56:16 <CRichard> right, but a new installation has no addresses in the wallet, so this cannot take any time for such a case
222 2012-02-21 05:56:36 <BlueMatt> CRichard: it still has ~101 addresses it has to check against, so it still takes some time
223 2012-02-21 05:56:45 <BlueMatt> CRichard: keeping the ledger of which transactions have been spent is what takes the most time
224 2012-02-21 05:57:16 <BlueMatt> for each tx, bitcoin has to look up the txouts that the given tx spends and mark them spent so someone cant come along later and try to double spend
225 2012-02-21 05:57:36 <BlueMatt> and that is what kills performance (because it fsyncs after each block)
226 2012-02-21 05:57:41 <CRichard> oh right, so that the client can reject bad txs
227 2012-02-21 05:57:45 <CRichard> gotya
228 2012-02-21 05:58:07 <CRichard> so is it possible to have a checkpoint of unspent txs?
229 2012-02-21 05:58:20 <BlueMatt> CRichard: it could be done, yes
230 2012-02-21 05:58:33 <CRichard> would that significantly improve load times for new entrants?
231 2012-02-21 05:59:03 <BlueMatt> tcatm: though I think downloading from one peer is the least of our problems, I would like to fix that as a part of a laundry list of performance improvements I want to make after cblockstore is merged
232 2012-02-21 05:59:09 <BlueMatt> CRichard: yep
233 2012-02-21 05:59:20 <BlueMatt> CRichard: though you have to trust the people who release the checkpoint
234 2012-02-21 05:59:21 <CRichard> ah cool
235 2012-02-21 05:59:24 <finway> What's the latest block? 167754 ? about a hour ago
236 2012-02-21 05:59:24 <seco> it would make sense to draw a checksum-line onto the fat-clients from time to time if there is consensus on a spedific blockchain, so this can be reduced to a "simply trust the past" download without recheck; but its a question of politics, isnt it not to rock on the hill of the transaction-validation which keeps "bitcoin" as system together
237 2012-02-21 05:59:31 <finway> is mtgox down?
238 2012-02-21 05:59:35 <seco> specific*
239 2012-02-21 05:59:36 <CRichard> yeah mtgox is down
240 2012-02-21 05:59:45 <CRichard> should be up within 30min according to someone in the other channel
241 2012-02-21 05:59:47 <BlueMatt> finway: #mtgox
242 2012-02-21 05:59:50 <k9quaint> BlueMatt: did you kick the extension cord again?
243 2012-02-21 06:00:10 <BlueMatt> k9quaint: me? if I kick an extension cord my dnsseed and jenkins goes down, not mtgox...
244 2012-02-21 06:00:26 <k9quaint> tell me more about your seed
245 2012-02-21 06:00:42 <BlueMatt> uh...its a dnsseed...
246 2012-02-21 06:00:42 <CRichard> BlueMatt: so is this txout checkpoint thing on the cards, or is something more important in front of the devs atm?
247 2012-02-21 06:00:49 <BlueMatt> and it provides seeds via dns
248 2012-02-21 06:00:50 <BlueMatt> ...
249 2012-02-21 06:01:06 <finway> BlueMatt: what's your latest block? 167754?
250 2012-02-21 06:01:28 <BlueMatt> finway: I dunno, check blockchain.info
251 2012-02-21 06:01:35 <seco> ;;bc,blocks
252 2012-02-21 06:01:41 <gribble> timed out
253 2012-02-21 06:01:48 <seco> o_0
254 2012-02-21 06:01:55 <finway> wow, gribble's down
255 2012-02-21 06:01:57 <tcatm> finway: 167754 here
256 2012-02-21 06:02:02 <BlueMatt> CRichard: its been suggested several times and it is assumed that at some point someone will write something to checkpoint the list of open txes....
257 2012-02-21 06:02:15 <finway> tcatm: it's been a hour and 10 min
258 2012-02-21 06:02:16 <BlueMatt> CRichard: but for now, its not really something that anyone has bothered actually putting time into
259 2012-02-21 06:02:17 <denisx> 167754
260 2012-02-21 06:02:29 <tcatm> finway: Happens from time to time...
261 2012-02-21 06:02:38 <BlueMatt> CRichard: there are easier ways to get a ton more performance out of the current bitcoin without it
262 2012-02-21 06:02:51 <BlueMatt> (which would help with all new block downloads, not just up to the checkpoints)
263 2012-02-21 06:02:56 <CRichard> BlueMatt: what's the protocol for adding stuff to the reference client? do you just make a modification and post it somewhere?
264 2012-02-21 06:03:11 <BlueMatt> CRichard: yea, github.com/bitcoin/bitcoin
265 2012-02-21 06:03:34 <CRichard> would have to get added or are public pushes allowed?
266 2012-02-21 06:03:56 <CRichard> oh theres an faq, will read thanks
267 2012-02-21 06:04:16 <BlueMatt> you have to fork, pull request, and then get devs to read the code and check
268 2012-02-21 06:04:32 <BlueMatt> we have to be pretty careful about commiting bad code, this is financial software...
269 2012-02-21 06:04:42 <BlueMatt> (not that it never happens, but...)
270 2012-02-21 06:05:25 <CRichard> yeah fair point
271 2012-02-21 06:05:33 <CRichard> does the reference client have automatic tests?
272 2012-02-21 06:05:39 <BlueMatt> some, not enough
273 2012-02-21 06:05:50 <finway> tcatm: umm
274 2012-02-21 06:06:04 <CRichard> k, thanks for the info
275 2012-02-21 06:07:29 <finway> tcatm: just checking, since mtgox is "experiencing a technical difficulty"
276 2012-02-21 06:07:43 <denisx> 167755
277 2012-02-21 06:07:49 <BlueMatt> better chain downloading (preventing chain-fork ddos + downloading from multiple peers + buffering blocks so that we dont wait on block downloads at all), better disk-writing by caching txspending in memory and async-disk-writes (which also allows for much more detailed tests since we can avoid writing temp dbs)
278 2012-02-21 06:07:59 <BlueMatt> though I suppose we can test with on-disk dbs, but...meh
279 2012-02-21 06:08:10 <BlueMatt> s/ddos/dos/
280 2012-02-21 06:08:15 <finway> BlueMatt: i'll check what's "CBlockStore"
281 2012-02-21 06:08:22 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/771
282 2012-02-21 06:10:26 <finway> OK, it's 167755 now
283 2012-02-21 06:16:34 <CRichard> are we worried about the block numbers?
284 2012-02-21 06:18:46 <finway> CRichard : no we are not.
285 2012-02-21 06:22:33 <CRichard> k
286 2012-02-21 09:20:17 <conman> jgarzik, question, may I ask your permission to change cgminer aka ex-cpuminer into GPLv3 please?
287 2012-02-21 09:20:36 <Diablo-D3> oh yeah
288 2012-02-21 09:20:37 <Diablo-D3> thats right
289 2012-02-21 09:20:42 <Diablo-D3> I forgot you stole his code
290 2012-02-21 09:34:15 <gribble> New news from bitcoinrss: dooglus opened issue 879 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/879>
291 2012-02-21 11:01:48 <sturles> A common critisism against Bitcoin is the lack of anonymity because it is often very easy to pin a transaction to an IP address.  How about an option to delay the relaying of transactions by 250-500ms between each node?  This will increase the chance of a transaction relaying from another node before a "snooper" gets it from the sending node.
292 2012-02-21 11:03:53 <Graet> connect=<public node> in bitcoind.conf , public node is 1st network sees it at?
293 2012-02-21 11:04:01 <sturles> Node A is about to relay a transaction.  It's own or someone elses.  It is connected to nodes B through Z.  Instead of sending the transactions to B through Z immediatly, it first tells B (immediatly), wait 250 ms, tells C, waits 250 ms, tells D, etc.
294 2012-02-21 11:05:04 <sturles> Graet: Yes, but then you are completely dependant of public node to relay your transaction, and you have to trust puclic node.
295 2012-02-21 11:05:45 <sturles> If public node is an evil miner not relaying transactions with a fee, and you added a fee, the transaction will not propagate.
296 2012-02-21 11:06:58 <gmaxwell> sturles: the system already delays and randomizes its own announcements.
297 2012-02-21 11:07:34 <gmaxwell> sturles: bitcoin is not, however, a anonymity network.   Thats a silly criticism. Do the same people tell you not to use the web?
298 2012-02-21 11:07:51 <gmaxwell> If you want greater privacy/anonymity with bitcoin combine it with Tor.
299 2012-02-21 11:08:52 <sturles> gmaxwell: OK.  I didn't know that.  I know blockchain.info pins less than half of my transactions correctly on me, but I assumed it was due to my own slow network. :-)
300 2012-02-21 11:10:24 <sturles> Of course it is not an anonymity network, but there should be limits on what it reveals by default.
301 2012-02-21 11:10:38 <sturles> When avoiding it is simple.
302 2012-02-21 11:11:26 <Graet> sturles, luckily i have my own public nodes i  can trust :)
303 2012-02-21 11:12:24 <sturles> Graet: Me too, but Joe Average User may not.
304 2012-02-21 11:12:30 <Graet> :)
305 2012-02-21 11:13:07 <Graet> joe average isnt so concerned about hiding his ip either ;) generally
306 2012-02-21 11:15:34 <sturles> Unfortunately one get more and more reasons to be conserned about it.  Everything beeing logged and access to the information becoming a formality. :-(
307 2012-02-21 11:16:23 <gmaxwell> Personally, I block blockchain.info from my nodes.
308 2012-02-21 11:18:14 <Ferroh> gmaxwell: really?
309 2012-02-21 11:18:28 <Ferroh> So is there no way to use pywallet on newer wallets :/
310 2012-02-21 11:18:43 <Ferroh> How can I import a private key into a wallet that isnt pre version 3.25?
311 2012-02-21 11:19:03 <gmaxwell> Ferroh: use the import RPC?
312 2012-02-21 11:19:29 <Ferroh> blargh, okay I can do it that way
313 2012-02-21 11:19:39 <Ferroh> thanks
314 2012-02-21 11:20:15 <Ferroh> does the import RPC allow importing into an encrypted wallet? or should I use an unencrypted wallet
315 2012-02-21 11:20:27 <Ferroh> by encrypted I of course mean, encrypted by bitcoin-qt.
316 2012-02-21 11:21:21 <wumpus> you can import into an encrypted wallet but it will need to be unlocked first
317 2012-02-21 11:21:29 <gmaxwell> What wumpus says.
318 2012-02-21 11:31:22 <ThomasV> <gmaxwell> Personally, I block blockchain.info from my nodes. <-- why?
319 2012-02-21 11:32:21 <gmaxwell> ThomasV: Because they were chewing up 6 sockets here for the service of displaying my IP on a website someone might use to target me for DOS attacks.
320 2012-02-21 11:32:56 <gmaxwell> If they'd like to pay me to allow them to monitor me, I'd consider it... but I mostly think I'm getting nothing out of the deal.
321 2012-02-21 11:34:09 <ThomasV> hmm
322 2012-02-21 11:53:01 <gribble> New news from bitcoinrss: Flowdalic opened issue 880 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/880>
323 2012-02-21 12:12:42 <Ferroh> ugh the import rpc rescans the blockchain at every import ffs
324 2012-02-21 12:18:45 <wumpus> and you can only import one private key at a time :-)
325 2012-02-21 12:18:58 <Ferroh> gmaxwell: when you said use the import RPC, were you referring to a patch of bitcoind that is not in the official version?
326 2012-02-21 12:19:12 <Ferroh> I dont see any import rpc method in bitcoind 0.5.2
327 2012-02-21 12:21:16 <Ferroh> So there is basically no way to import private keys into a wallet.dat.
328 2012-02-21 12:21:24 <Ferroh> Doesn't that seem like pretty basic functionality to you guys?
329 2012-02-21 12:21:55 <wumpus> there's an "importprivkey" RPC call I'm looking at it right now
330 2012-02-21 12:22:02 <wumpus> not sure when it was merged though...
331 2012-02-21 12:22:16 <Ferroh> what version are you using
332 2012-02-21 12:22:21 <Ferroh> later than 0.5.2?
333 2012-02-21 12:22:24 <wumpus> git master
334 2012-02-21 12:22:55 <Ferroh> ;;isitdown bitcoin.org
335 2012-02-21 12:22:57 <gribble> http://bitcoin.org Is Up -> Check if your website is up or down?
336 2012-02-21 12:23:19 <gmaxwell> Ferroh: I'm not sure where it was merged, it's in 0.6rc at least.
337 2012-02-21 12:23:37 <Ferroh> well git master is 0.5.2 if im not mistaken
338 2012-02-21 12:23:41 <Ferroh> so I should have it :/
339 2012-02-21 12:23:55 <Ferroh> oh, wait
340 2012-02-21 12:24:01 <Ferroh> no git master is 0.6
341 2012-02-21 12:30:52 <Ferroh> Any tips as to why bitcoin 0.6 is not building for me?
342 2012-02-21 12:30:54 <Ferroh> Error:
343 2012-02-21 12:31:36 <gmaxwell> you need to have the libdb c++ headers installed. What distro are you building on?
344 2012-02-21 12:31:44 <wumpus> you don't have the  libdb4.8++-dev package installed
345 2012-02-21 12:32:02 <Ferroh> That package doesnt exist in the apt repo for ubuntu
346 2012-02-21 12:32:20 <wumpus> hm probably it some other name there
347 2012-02-21 12:32:24 <Ferroh> libdb4.8-dev does though
348 2012-02-21 12:32:29 <Ferroh> and libdb4.8-dev is installed
349 2012-02-21 12:32:39 <wumpus> you really need the ++ one
350 2012-02-21 12:32:53 <gmaxwell> see doc/build-unix.txt
351 2012-02-21 12:33:44 <Ferroh> I obviously did see that gmaxwell :P
352 2012-02-21 12:33:52 <Ferroh> those install instructions do not work.
353 2012-02-21 12:34:03 <Ferroh> anyway I got it working
354 2012-02-21 12:34:23 <Ferroh> on ubuntu you need to replace the line in the build-unix.txt file that says:
355 2012-02-21 12:34:28 <Ferroh> sudo apt-get install libdb4.8++-dev
356 2012-02-21 12:34:30 <Ferroh> with:
357 2012-02-21 12:34:41 <Ferroh> sudo apt-get install libdb++-dev
358 2012-02-21 12:34:55 <Ferroh> or you might have a bunch of confused users, for a moment at least
359 2012-02-21 12:35:03 <wumpus> maybe they dropped version 4.8 in your release
360 2012-02-21 12:35:11 <gmaxwell> Thanks! (although is that pulling 4.8 or .. something else??)
361 2012-02-21 12:35:16 <wumpus> libdb++-dev probably links to 5.1
362 2012-02-21 12:35:22 <gmaxwell> You'll need 4.8 if you want wallet files compatible with the public binaries.
363 2012-02-21 12:35:26 <Ferroh> probably does link to 5.1
364 2012-02-21 12:35:34 <wumpus> though I generally use 5.1 and never had trouble with it
365 2012-02-21 12:35:39 <Ferroh> but there is no 4.8++ in the apt-cache search that i just did so
366 2012-02-21 12:35:46 <gmaxwell> okay, if you run that bitcoin on your wallet you'll not be able to use a 4.8 based copy of bitcoin again.
367 2012-02-21 12:35:46 <wumpus> but yeah the wallet won't be backward compatible with 4.8...
368 2012-02-21 12:38:50 <Ferroh> um
369 2012-02-21 12:38:56 <Ferroh> there is no /bin folder after doing a make?
370 2012-02-21 12:39:04 <Ferroh> make appears to have completed successfully.
371 2012-02-21 12:39:53 <Ferroh> oh, it just dumps bitcoind in the src folder now
372 2012-02-21 12:39:54 <Ferroh> ok
373 2012-02-21 12:41:52 <Ferroh> Yeah so importprivkey is in 0.6, yay
374 2012-02-21 12:42:04 <Ferroh> now I can spend 24 hours waiting for keys to import :/
375 2012-02-21 12:42:38 <Ferroh> I wonder what sort of wallet file electrum uses
376 2012-02-21 12:43:01 <Ferroh> electrum doesnt have a command line client though does it?
377 2012-02-21 12:48:07 <wumpus> I guess you could patch the importprivkey call to accept multiple keys
378 2012-02-21 12:50:59 <Ferroh> or just not scan the block chain
379 2012-02-21 12:51:29 <Ferroh> Is there a way to export private keys from the wallet?
380 2012-02-21 12:51:33 <Ferroh> that would also work for me
381 2012-02-21 12:51:45 <Ferroh> oh, dumpprivkey is new
382 2012-02-21 12:51:46 <Ferroh> ok
383 2012-02-21 12:51:49 <Ferroh> i'll do it that way then
384 2012-02-21 12:51:58 <Ferroh> sigh, I have to rewrite a bunch of stuff now blah
385 2012-02-21 12:52:28 <wumpus> you need to scan the block chain at least once, I suppose
386 2012-02-21 12:52:39 <Ferroh> yes, but I want to import 10000 keys first
387 2012-02-21 12:52:50 <Ferroh> and not scan 10000 times ideally
388 2012-02-21 12:52:54 <wumpus> of course
389 2012-02-21 12:53:26 <Ferroh> its ok, I will just generate the keys using the satoshi client
390 2012-02-21 12:53:34 <Ferroh> and then dump the private keys out after
391 2012-02-21 12:53:49 <Ferroh> i didnt want to be forced to use the satoshi client, that's all :/
392 2012-02-21 12:54:57 <Ferroh> I guess I could just kill the wifi and move the blockchain temporarily out of the .bitcoin dir so that chain scans are fast
393 2012-02-21 12:55:21 <Ferroh> (because the blockchain would be just a few blocks)
394 2012-02-21 13:10:57 <Ferroh> oh, electrum does work from the command line
395 2012-02-21 13:17:19 <Ferroh> lol god damnit
396 2012-02-21 13:17:25 <Ferroh> so I make a new address with bitcoind
397 2012-02-21 13:17:28 <ThomasV> Ferroh: it worked from the CLI before it had a gui
398 2012-02-21 13:17:34 <Ferroh> then I do dumpprivkey <address>
399 2012-02-21 13:17:36 <Ferroh> and it says
400 2012-02-21 13:17:41 <Ferroh> error: {"code":-4,"message":"Private key for address 16stpbfQ3BidQct2QjmAX9ZbHnEhezUv6G is not known"}
401 2012-02-21 13:18:05 <Ferroh> ThomasV: Yes it seems that I might just want to use electrum. bitcoind is a headache so far
402 2012-02-21 13:18:22 <ThomasV> cool :)
403 2012-02-21 13:18:33 <Ferroh> Did you make it?
404 2012-02-21 13:18:41 <ThomasV> yes, most of it
405 2012-02-21 13:19:07 <Ferroh> Oh I see, it didnt "know" the private key because you have to unlock (decrypt) the wallet first.
406 2012-02-21 13:19:18 <Ferroh> electrum is suprisingly simple
407 2012-02-21 13:19:25 <Ferroh> wallet.py has most of the functionality
408 2012-02-21 13:19:31 <Ferroh> and it's <900 lines
409 2012-02-21 13:19:54 <Ferroh> (most of the client's functionality anyway)
410 2012-02-21 13:20:09 <ThomasV> and a good chunk of wallet.py is a copy/paste from pywallet
411 2012-02-21 13:31:53 <Joric> and pywallet is basically a copy/paste from wallet.py (from bitcointools)
412 2012-02-21 13:32:26 <ThomasV> Joric: thus, a fixed point has been reached
413 2012-02-21 13:36:00 <Joric> isn't electrum like super-centralized? they missing the whole point of bitcoin
414 2012-02-21 13:36:34 <ThomasV> no
415 2012-02-21 13:36:40 <Joric> multibit/bitcoinj is almost as lightweight as electrum
416 2012-02-21 13:38:51 <Joric> ThomasV, how does it work?
417 2012-02-21 13:39:21 <ThomasV> Joric: client-server. http://ecdsa.org/electrum/
418 2012-02-21 13:39:24 <Joric> they say it's based on a client-server protocol who's the server
419 2012-02-21 13:39:43 <ThomasV> there are several servers, 3 at the moment
420 2012-02-21 13:39:55 <helo> can a user run their own?
421 2012-02-21 13:40:03 <ThomasV> helo: yes
422 2012-02-21 13:40:30 <Joric> whoa a whole 3 servers
423 2012-02-21 13:40:41 <ThomasV> the big difference with bccapi is that the server does not need to know its users. the server is used as if it was a block explorer
424 2012-02-21 13:41:02 <helo> http?
425 2012-02-21 13:41:04 <Joric> 'Never take two chronometers to sea. Always take one or three.'
426 2012-02-21 13:41:13 <ThomasV> Joric: public servers are listening on #electrum
427 2012-02-21 13:42:16 <ThomasV> there might be private servers too
428 2012-02-21 13:43:27 <helo> i like the blue bitcoin logo... gold is so cheesy
429 2012-02-21 13:45:27 <Joric> it's brass, as in casascius coins )
430 2012-02-21 13:47:44 <ThomasV> Joric: multibit does not store the blockchain, but it still needs to download it
431 2012-02-21 13:48:15 <Ferroh> ThomasV: there is no help for the import command. Do you just do "electrum import <pubkey> <privkey>"?
432 2012-02-21 13:48:38 <Ferroh> oh you use a color
433 2012-02-21 13:48:40 <Ferroh> *colon
434 2012-02-21 13:48:40 <ThomasV> Ferroh: <address>:<privkey>, separated by a colon
435 2012-02-21 13:48:42 <Ferroh> ok got it
436 2012-02-21 13:48:52 <ThomasV> same format as for the export
437 2012-02-21 13:49:01 <Ferroh> am I safe to import 10000 keys?
438 2012-02-21 13:49:07 <Ferroh> does it query your server every time i do so or something?
439 2012-02-21 13:49:16 <Ferroh> if so, I can run my own server
440 2012-02-21 13:49:19 <ThomasV> https://en.bitcoin.it/wiki/Electrum#Export_and_import_addresses
441 2012-02-21 13:49:35 <ThomasV> Ferroh: 10000 will be too much
442 2012-02-21 13:49:50 <Ferroh> because it queries your server, or because electrum doesnt like a wallet that large?
443 2012-02-21 13:50:00 <ThomasV> no, because of the queries
444 2012-02-21 13:50:08 <Ferroh> ok so I can just run my own server and it's fine, right?
445 2012-02-21 13:50:33 <ThomasV> I have seen some client with about 1000 key, it slowed down the server
446 2012-02-21 13:51:16 <ThomasV> if you do it with your own server, it might be too slow as well. things will probably improve when we use libbitcoin, but for the moment servers use bitcoind
447 2012-02-21 13:51:26 <Ferroh> I see
448 2012-02-21 13:51:34 <ThomasV> bitcoind+abe
449 2012-02-21 13:51:48 <ThomasV> that's not very efficient
450 2012-02-21 13:52:15 <Ferroh> I guess im back to using bitcoind for now then :/
451 2012-02-21 13:52:35 <ThomasV> Ferroh: why do you need so many keys?
452 2012-02-21 13:53:14 <Ferroh> 1000 clients times 10 transactions each = 10k keys
453 2012-02-21 13:53:19 <Ferroh> i could use less, but it would be inconvenient
454 2012-02-21 13:53:45 <ThomasV> 1000 clients of what?
455 2012-02-21 13:53:57 <Ferroh> of bitcoin users
456 2012-02-21 13:54:31 <Ferroh> hmm
457 2012-02-21 13:54:33 <ThomasV> I don(t get it. is this for a service you're providing?
458 2012-02-21 13:54:38 <Ferroh> can i remove a key from the wallet with electrum?
459 2012-02-21 13:54:48 <Ferroh> ThomasV: yes
460 2012-02-21 13:54:56 <ThomasV> Ferroh: yes, with eval
461 2012-02-21 13:55:13 <Ferroh> if I can remove a key, then I could manage the keys separately in my own db, and just add and remove them as they are often only used once
462 2012-02-21 13:55:21 <ThomasV> electrum eval 'wallet.imported_keys.pop('address')'
463 2012-02-21 13:55:37 <Ferroh> ok, so maybe I'll do it that way
464 2012-02-21 13:57:06 <Ferroh> indeed
465 2012-02-21 13:57:36 <Ferroh> um
466 2012-02-21 13:57:41 <ThomasV> but it might be cool to try anyway
467 2012-02-21 13:57:44 <Ferroh> electrum lets you import a keypair twice
468 2012-02-21 13:57:53 <ThomasV> heh
469 2012-02-21 13:57:58 <ThomasV> sounds like a bug
470 2012-02-21 13:58:22 <ThomasV> does it double your balance?
471 2012-02-21 13:58:39 <Ferroh> no
472 2012-02-21 13:58:54 <ThomasV> too bad :)
473 2012-02-21 13:59:00 <Ferroh> wait,
474 2012-02-21 13:59:21 <Ferroh> oh the coins arent at the doubled address
475 2012-02-21 13:59:23 <Ferroh> ok let me try.
476 2012-02-21 13:59:52 <Ferroh> yes, it doubles your balance ThomasV.
477 2012-02-21 14:00:22 <Ferroh> it does not triple your balance if you import a 3rd time though
478 2012-02-21 14:01:50 <ThomasV> Ferroh: git pull
479 2012-02-21 14:02:47 <ThomasV> https://gitorious.org/electrum/electrum/commit/77696dcfdacdf60bfb66bea64d6d9a45204f1289/diffs/b0b8a5ec6bcdbeca098ebd1a79e37509c8040826
480 2012-02-21 14:03:09 <Ferroh> it still has a doubled balance
481 2012-02-21 14:03:15 <Ferroh> oh
482 2012-02-21 14:03:19 <Ferroh> i see you just changed import
483 2012-02-21 14:03:21 <Ferroh> well,
484 2012-02-21 14:03:27 <Ferroh> presumably that should work now, one sec
485 2012-02-21 14:03:45 <ThomasV> you'll need to remove it first from that wallet
486 2012-02-21 14:03:50 <Ferroh> yes
487 2012-02-21 14:03:58 <Ferroh> and yes it says "error" if you try to import a duplicate now
488 2012-02-21 14:04:05 <Ferroh> so I guess that's fine
489 2012-02-21 14:04:15 <Ferroh> it's a problem for anyone out there that imported a key twice already though :/
490 2012-02-21 14:04:20 <ThomasV> thanks for the report btw
491 2012-02-21 14:04:27 <Ferroh> np
492 2012-02-21 14:05:10 <ThomasV> initialy I did not like the idea of importing keys
493 2012-02-21 14:05:23 <ThomasV> it was supposed to be a deterministic wallet
494 2012-02-21 14:05:37 <ThomasV> this function was added later
495 2012-02-21 14:10:17 <helo> should the client say "Catching up..." if the last block it has seen is actually current (but still ~30 minutes old)
496 2012-02-21 14:13:04 <Ferroh> probably
497 2012-02-21 14:13:16 <Ferroh> i think the client just guesses at what the last block probably is based on the time
498 2012-02-21 14:13:33 <Ferroh> since the last block is pretty old right now (like 45 minutes), it might assume it's not the last block because it's so old
499 2012-02-21 14:13:44 <Ferroh> ;;bc,tslb
500 2012-02-21 14:13:49 <gribble> Error: unexpected EOF while parsing (<string>, line 1)
501 2012-02-21 14:13:54 <Ferroh> -.-
502 2012-02-21 14:15:18 <Graet> http://www.blockchain.info/ slush 2 mions ago
503 2012-02-21 14:15:34 <Ferroh> he asked the question 5 minutes ago though :P
504 2012-02-21 14:15:54 <Ferroh> the block before that was 53 mins ago
505 2012-02-21 14:16:14 <Ferroh> helo: so does the client say "up to date" now?
506 2012-02-21 14:16:46 <helo> yeah
507 2012-02-21 14:30:27 <ThomasV> Joric: https://en.bitcoin.it/wiki/User:188.19.180.201
508 2012-02-21 14:30:48 <ThomasV> what's the point?
509 2012-02-21 14:58:09 <Joric> delete it if you can
510 2012-02-21 15:02:42 <stani> hello mello
511 2012-02-21 15:41:22 <xorrbit> https://ogrr.com/viewtopic.php?f=74&t=1139
512 2012-02-21 15:42:22 <Joric> is it theoretically possible to eliminate double spending without logging every single transaction? did anyone study this question
513 2012-02-21 15:44:03 <luke-jr> Joric: you'd be a genius if you found a way
514 2012-02-21 15:47:01 <Ferroh> Joric: suppose you only need 75% of the transactions to know that no double spending has occurred. Is that worth the effort of implementation?
515 2012-02-21 15:47:31 <Ferroh> Anything you do to reduce the number of transactions that you need to log is not going to be much better than known compression methods anyway, so what is the purpose of this?
516 2012-02-21 15:52:41 <helo> 75% of the transactions will only allow you to know when no double spending has happened 75% of the time?
517 2012-02-21 15:58:37 <ThomasV> Joric: yes, with "local" subcurrencies
518 2012-02-21 15:59:56 <Joric> whoa
519 2012-02-21 16:00:12 <Joric> Davincij, hi dude!!
520 2012-02-21 16:07:47 <Ferroh> helo: It doesn't matter if that's true or not.
521 2012-02-21 16:10:09 <Ferroh> it's really annoying that you can't kill bitcoind no matter how much you want to
522 2012-02-21 16:10:27 <k9quaint> Ferroh: you are just not trying hard enough
523 2012-02-21 16:10:35 <Ferroh> yes, I could pull the power plug
524 2012-02-21 16:10:59 <k9quaint> bullets work too
525 2012-02-21 16:11:21 <k9quaint> fire probably
526 2012-02-21 16:11:24 <k9quaint> drowning
527 2012-02-21 16:11:41 <xorrbit> sudo kill -9 `pidof bitcoind`
528 2012-02-21 16:11:42 <k9quaint> you could also probably beat it to death with a heavy blunt object
529 2012-02-21 16:11:46 <xorrbit> easymode
530 2012-02-21 16:11:54 <k9quaint> xorrbit: that kills my fun too :|
531 2012-02-21 16:14:28 <vegard> xorrbit: that looks like sudo killall -9 bitcoind
532 2012-02-21 16:16:21 <xorrbit> TIL killall -9 works as expected :)
533 2012-02-21 16:17:07 <Ferroh> what does -9 do?
534 2012-02-21 16:17:57 <Ferroh> isnt signal  9 just SIGKILL?
535 2012-02-21 16:17:57 <Joric> http://www.monzy.com/intro/killdashnine_lyrics.html
536 2012-02-21 16:18:02 <Ferroh> doesnt it always send that anyway?
537 2012-02-21 16:18:08 <gmaxwell> kill -9 works fine.
538 2012-02-21 16:18:12 <gmaxwell> No, it sends term normally.
539 2012-02-21 16:18:13 <xorrbit> SIGKILL yeah
540 2012-02-21 16:18:18 <xorrbit> regualr kill is SIGTERM
541 2012-02-21 16:18:24 <gmaxwell> Term works too but it takes a minute while it cleanly shuts down.
542 2012-02-21 16:18:25 <Ferroh> killall bitcoind does not kill bitcoind btw
543 2012-02-21 16:18:27 <xorrbit> SIGTERM is like 'hey bro shut down please'
544 2012-02-21 16:18:30 <Ferroh> i mean it does, for a moment
545 2012-02-21 16:18:37 <Ferroh> oh okay
546 2012-02-21 16:18:38 <Ferroh> I see.
547 2012-02-21 16:18:43 <xorrbit> SIGKILL is like 'BOOM HEADSHOT'
548 2012-02-21 16:18:44 <gmaxwell> Ferroh: killall sends SIGTERM by default too.
549 2012-02-21 16:18:53 <Ferroh> yeah I see now
550 2012-02-21 16:18:57 <k9quaint> typing is for pansies
551 2012-02-21 16:19:03 <gmaxwell> You also will leave your database (block index, wallet) in an inconsistent state when you kill -9.
552 2012-02-21 16:19:18 <gmaxwell> It will recover fine but don't upgrade when you've killed it like that.
553 2012-02-21 16:19:22 <xorrbit> SIGKILL can't be ignored by the process, it goes straight to init and init stops the process
554 2012-02-21 16:19:30 <xorrbit> the process doesn't even know it's being killed
555 2012-02-21 16:19:35 <Ferroh> the database should be atomic :(
556 2012-02-21 16:19:56 <gmaxwell> Ferroh: It _is_ like any other database is: it's atomic by the fact that it can recover using the dblogs.
557 2012-02-21 16:20:14 <Ferroh> then why is upgrading a concern after such an event?
558 2012-02-21 16:20:47 <Ferroh> if that event prevents certain behavior, then it is not truly atomic.
559 2012-02-21 16:20:47 <gmaxwell> And like any other database you'll have problems if you upgrade it while in an inconsistent state. (e.g. both mysql and postgres are not guarenteed to be able to read the rollback logs of prior versions)
560 2012-02-21 16:21:07 <Ferroh> Oh, you're saying that a database update could cause problems.
561 2012-02-21 16:21:15 <Ferroh> Not necessarily a bitcoind update.
562 2012-02-21 16:21:18 <Ferroh> ?
563 2012-02-21 16:21:29 <gmaxwell> Yes. (and has in the past) Right. But new bitcoind may ship with a new libdb version.
564 2012-02-21 16:21:39 <gmaxwell> e.g. 4.6->4.7 had issues reading the logs from old versions.
565 2012-02-21 16:21:46 <gmaxwell> (libdb 4.6->4.7)
566 2012-02-21 16:35:10 <Ferroh> gmaxwell
567 2012-02-21 16:35:15 <Ferroh> if I killall -9 bitcoind
568 2012-02-21 16:35:19 <Ferroh> and then run bitcoind again
569 2012-02-21 16:35:23 <Ferroh> and let it recover
570 2012-02-21 16:35:28 <Ferroh> am i then safe to upgrade db?
571 2012-02-21 16:35:52 <gmaxwell> Ferroh: sure. Just shut it down cleanly (not kill -9) and then upgrade.
572 2012-02-21 16:35:59 <Ferroh> ok
573 2012-02-21 16:36:17 <Ferroh> it seems that I can just import a billion keys, and it will continue to import while it scans the blockchain
574 2012-02-21 16:36:22 <Ferroh> then you can just killall -9
575 2012-02-21 16:36:24 <Ferroh> and restart it
576 2012-02-21 16:36:35 <Ferroh> this way I dont have to patch it so that import works properly /eyeroll
577 2012-02-21 16:36:46 <gmaxwell> Ferroh: yes, but it may not have completed the rescan so you may be missing some txn until you start with -rescan
578 2012-02-21 16:37:19 <Ferroh> that's fine, im just trying to avoid rescanning the blockchain literally 10000 times
579 2012-02-21 16:37:23 <gmaxwell> Ferroh: this way I dont have to patch it so that import works properly???
580 2012-02-21 16:37:33 <Ferroh> gmaxwell: yeah, import is currently pretty useless
581 2012-02-21 16:37:34 <gmaxwell> oh. well, yuck.
582 2012-02-21 16:37:51 <gmaxwell> Ferroh: it's fine to import single keys. Why are you importing 10000 keys? 0_o
583 2012-02-21 16:37:59 <Ferroh> due to it only being able to import one key at a time before scanning the entire blockchain
584 2012-02-21 16:38:06 <Ferroh> yes, its fine for single keys.
585 2012-02-21 16:38:21 <Ferroh> ok well, im importing 5000 keys
586 2012-02-21 16:38:24 <gmaxwell> Yea, I get what you're saying that bugged me too but I didn't really see a usecase for otherwise.
587 2012-02-21 16:38:25 <Ferroh> so I guess i exaggerated
588 2012-02-21 16:38:41 <Ferroh> it might be worth it to manage the keys separately myself and then only import when they get used
589 2012-02-21 16:38:51 <Ferroh> but the reason is that I want to pregenerate a bunch of keys,
590 2012-02-21 16:38:56 <Ferroh> and then only put the public keys on my server
591 2012-02-21 16:39:06 <Ferroh> and store the private keys in a wallet
592 2012-02-21 16:39:26 <gmaxwell> Fair enough we'll have better support for that in the future.
593 2012-02-21 16:39:30 <Ferroh> otherwise i have to either run bitcoind on the server (bad), or manage the private keys myself separately
594 2012-02-21 16:39:40 <Ferroh> or, i'll need to generate keys more often
595 2012-02-21 16:39:50 <Ferroh> okie doke
596 2012-02-21 16:43:24 <Ferroh> basically all that's needed is a flag that prevents rescan on private key import, imo
597 2012-02-21 16:44:35 <devrandom> ;;later tell BlueMatt optional files feature is now implemented in latest gitian - add optionals array to descriptor and it will flow through to assertion
598 2012-02-21 16:44:36 <gribble> The operation succeeded.
599 2012-02-21 16:44:53 <BlueMatt> devrandom: nice, maybe Ill have time to do that for 0.6...
600 2012-02-21 16:46:08 <jrmithdobbs> Ferroh: err, you can batch import
601 2012-02-21 16:46:15 <Ferroh> oh?
602 2012-02-21 16:46:17 <Ferroh> how
603 2012-02-21 16:46:29 <jrmithdobbs> at least, you could in the versions of the patch i tested, let me look at what actually made it in ;p
604 2012-02-21 16:47:32 <Ferroh> Is it easy to disable the rescan on import? maybe i should just patch it
605 2012-02-21 16:47:40 <jrmithdobbs> no
606 2012-02-21 16:47:47 <Ferroh> I see :(
607 2012-02-21 16:48:00 <gmaxwell> hm? I don't see why that should be hard.
608 2012-02-21 16:49:56 <jrmithdobbs> oh
609 2012-02-21 16:50:08 <jrmithdobbs> sipa didn't merge the code that'd do the batching, haha
610 2012-02-21 16:50:10 <wumpus> Ferroh: could add a third argument to importprivkey for that (which defaults to true)
611 2012-02-21 16:50:45 <jrmithdobbs> Ferroh: this is what you really want
612 2012-02-21 16:50:48 <jrmithdobbs> Ferroh: https://github.com/bitcoin/bitcoin/pull/220
613 2012-02-21 16:50:55 <jrmithdobbs> dump/importwallet
614 2012-02-21 16:51:12 <wumpus> he's using that
615 2012-02-21 16:51:14 <Ferroh> i dont think it is o.O
616 2012-02-21 16:51:26 <Ferroh> What I want is to be able to import without doing a rescan, basically.
617 2012-02-21 16:51:28 <jrmithdobbs> wumpus: no, he's using what was actually merged which just lets you do a single key at a time
618 2012-02-21 16:51:39 <Ferroh> that merges an existing wallet,
619 2012-02-21 16:51:42 <jrmithdobbs> Ferroh: right that code will let you give it a json file with a list of keys
620 2012-02-21 16:51:44 <Ferroh> i dont have an existing wallet
621 2012-02-21 16:51:45 <Ferroh> i just have a key.
622 2012-02-21 16:51:49 <Ferroh> (well, 5000 keys)
623 2012-02-21 16:51:55 <Ferroh> I see.
624 2012-02-21 16:52:01 <jrmithdobbs> you just need to format it in the json as it expects and it wont do the rescan until after adding all of them
625 2012-02-21 16:52:47 <wumpus> as I see it it is pretty easy *not* to rescan... disable the ScanForWalletTransactions and ReacceptWalletTransactions in importprivkey function...
626 2012-02-21 16:53:03 <Ferroh> yeah, it seems easier to just disable rescanning really
627 2012-02-21 16:53:15 <wumpus> then let that depend on the third argument
628 2012-02-21 16:53:29 <badluck> .broson
629 2012-02-21 16:53:32 <jrmithdobbs> ya different code than i thought got merged, the privkey only stuff is straightforward
630 2012-02-21 16:53:53 <wumpus> so that if you can guarantee that a private key is never used, you can tell it not to rescan
631 2012-02-21 16:55:54 <Ferroh> its not even about guaranteeing that its not used
632 2012-02-21 16:56:04 <Ferroh> it's about delaying the rescan until after all keys are imported
633 2012-02-21 16:56:07 <Ferroh> anyways i made the change
634 2012-02-21 16:56:14 <Ferroh> everything should work now, lets see...
635 2012-02-21 17:20:53 <DrHaribo> Suggestion for "getwork" alternative: https://bitcointalk.org/index.php?topic=64777.0
636 2012-02-21 17:22:40 <Ferroh> so 250kb of private keys stored as plaintext
637 2012-02-21 17:22:55 <Ferroh> adds about 2000kb to the wallet.dat
638 2012-02-21 17:22:57 <Ferroh> :(
639 2012-02-21 17:23:37 <Ferroh> 2000kb is not really a big deal
640 2012-02-21 17:23:43 <Ferroh> that just seems like a lot of extra data
641 2012-02-21 17:29:04 <pingdrive> yo so blockchain.info ssays that my address contains transactions which maybe double spends
642 2012-02-21 17:29:07 <pingdrive> how do i fix that
643 2012-02-21 17:29:15 <pingdrive> or verify that is not the case
644 2012-02-21 17:31:20 <Ferroh> are they very recent transactions?
645 2012-02-21 17:31:31 <Ferroh> wait 6 blocks, then it will stop bitching I assume
646 2012-02-21 17:31:44 <pingdrive> hmm
647 2012-02-21 17:31:47 <pingdrive> oka
648 2012-02-21 17:31:52 <pingdrive> pretty annoying shiut
649 2012-02-21 17:32:02 <pingdrive> never saw that happen
650 2012-02-21 17:32:16 <pingdrive> with new transactions
651 2012-02-21 17:34:42 <Ferroh> I have never seen it happen either
652 2012-02-21 17:34:52 <Ferroh> where did you receive the coins from?
653 2012-02-21 17:34:58 <Ferroh> some random guy, or a site like mtgox?
654 2012-02-21 17:35:11 <Ferroh> pingdrive ^^
655 2012-02-21 17:35:17 <pingdrive> mining
656 2012-02-21 17:35:20 <Ferroh> oh
657 2012-02-21 17:35:24 <pingdrive> actually
658 2012-02-21 17:35:27 <Ferroh> weird
659 2012-02-21 17:35:38 <pingdrive> it was not showing it before
660 2012-02-21 17:35:43 <Ferroh> which site?
661 2012-02-21 17:35:48 <pingdrive> i had all the same txns
662 2012-02-21 17:35:49 <Ferroh> i mean, which mining pool
663 2012-02-21 17:35:56 <pingdrive> p2pool
664 2012-02-21 17:44:23 <pingdrive> okay looks like it might be blockchain.info issue
665 2012-02-21 17:44:44 <pingdrive> no need to panic yet
666 2012-02-21 17:49:21 <Joric> Ferroh, wallet.dat expands every 32-byte secret into 279-byte one i have no idea why it does that, it can be done inplace
667 2012-02-21 17:52:01 <badluck> hegaflope
668 2012-02-21 17:56:16 <Joric> though it's ASN1 and it contains metainformation while 32-byte secret doesn't even contain ec type
669 2012-02-21 17:57:36 <sipa> did i miss anything important the past day?
670 2012-02-21 18:15:02 <sipa> Joric: imho, that was done because Satoshi didn't know he could just store the 32-byte secret.
671 2012-02-21 18:15:38 <Joric> i dont think satoshi is a tool
672 2012-02-21 18:17:15 <sipa> Joric: It's not an unreasonable choice; he uses OpenSSL's EC_KEY objects, so when saving them to a file, he serializes those
673 2012-02-21 18:33:14 <sipa> jrmithdobbs: i didn't merge show/importwallet on purpose; there are some minor problems with it still
674 2012-02-21 18:39:57 <Ferroh> sipa: adding an argument to disable rescan on import was good enough for me.
675 2012-02-21 18:40:19 <Ferroh> (because it allows you to import as many keys as you want quickly)
676 2012-02-21 18:40:35 <sipa> good point
677 2012-02-21 19:05:53 <Kiba> hmm
678 2012-02-21 19:05:56 <hdon> hi all :) i have an idea for an online service that i want to do transactions in bitcoin. i want to start coding asap! where are docs on programming bitcoin transactions?
679 2012-02-21 19:08:33 <sipa> hdon: bitcoin.it, protocol specification
680 2012-02-21 19:10:16 <hdon> sipa: no this is not what i want.i want the API reference. thanks though :)
681 2012-02-21 19:10:36 <sipa> hdon: the RPC interface?
682 2012-02-21 19:11:00 <xorrbit> I think he wants a library that implements the protocol
683 2012-02-21 19:11:33 <hdon> yes, i just want to be able to write programs that, as part of their operation, send bitcoins, and can know when bitcoins are sent to the system
684 2012-02-21 19:11:45 <xorrbit> but without knowing what language/etc he's working in this is futile
685 2012-02-21 19:11:54 <sipa> hdon: you can do so using the RPC interface to bitcoind
686 2012-02-21 19:12:20 <hdon> i see there is a JSON-RPC API. this is convenient for me as i can work using Javascript on the server side
687 2012-02-21 19:14:14 <hdon> this looks excellent :) thanks!
688 2012-02-21 19:14:27 <xorrbit> the downside to that approach is you have to use javascript on the server side :)
689 2012-02-21 19:15:31 <hdon> xorrbit: i do a lot of server-side javascript development. i like the MVC pattern, and it's nice to write the controller in one language and be able to perform validation on the client when doing web development
690 2012-02-21 19:15:48 <xorrbit> to each his own
691 2012-02-21 19:16:06 <hdon> it's better than PHP!
692 2012-02-21 19:16:12 <sipa> <flamewar>
693 2012-02-21 19:16:15 <xorrbit> agreed
694 2012-02-21 19:16:32 <xorrbit> not much is worse tho :)
695 2012-02-21 19:16:39 <hdon> heh, true
696 2012-02-21 19:35:57 <DBordello> it appears taht even with minconf=0, sendfrom still won't send a transaction if the account has enough 0-conf funds.  Thoughts?
697 2012-02-21 19:36:00 <DBordello> that*
698 2012-02-21 19:36:33 <gmaxwell> DBordello: IIRC coin selection will not use unconfirmed transactions from anyone but itself.
699 2012-02-21 19:36:46 <sipa> gmaxwell is right
700 2012-02-21 19:36:54 <DBordello> coin selection?
701 2012-02-21 19:37:16 <gmaxwell> The code that selects inputs to be used.
702 2012-02-21 19:37:28 <sipa> The algorithm that chooses unspent transaction outputs ("coins") to serve as inputs for a requested transaction.
703 2012-02-21 19:37:46 <DBordello> so, wouldn't this qualify as "itself"?
704 2012-02-21 19:37:56 <DBordello> or is perhaps the fee screwing things up
705 2012-02-21 19:38:21 <DBordello> if I send 10 BTC to account "a", then try to withdraw 10 from "a" using sendfrom, but there is enough confirmed funds in another account to cover the fee?
706 2012-02-21 19:38:22 <sipa> It allows 0-confirmation for inputs from change outputs, and from send-to-selfs.
707 2012-02-21 19:38:26 <gmaxwell> DBordello: depends on where those inputs came from if they are change or otherwise signed by this client's private keys, then it will use them.
708 2012-02-21 19:38:47 <DBordello> oh, no, they are from another host
709 2012-02-21 19:38:58 <sipa> Which host they are from is irrelevant.
710 2012-02-21 19:39:04 <DBordello> well, different wallet
711 2012-02-21 19:39:18 <DBordello> so, that won't work then'
712 2012-02-21 19:39:21 <gmaxwell> DBordello: sendfrom doesn't do what you think it does I suspect.
713 2012-02-21 19:39:36 <gmaxwell> It controls which account is charged for the txn, but has nothing to do with what inputs are used.
714 2012-02-21 19:39:47 <DBordello> okay
715 2012-02-21 19:39:54 <sipa> Read this: https://en.bitcoin.it/wiki/Accounts_explained
716 2012-02-21 19:41:38 <DBordello> okay
717 2012-02-21 19:41:44 <DBordello> so, basically, no unconfirmed spending
718 2012-02-21 19:41:46 <DBordello> unless it is from change?
719 2012-02-21 19:42:06 <gmaxwell> Right, even the unconfirmed change is only used as a last resort.
720 2012-02-21 19:42:52 <DBordello> Got it
721 2012-02-21 19:43:04 <sipa> just received a verack with wrong checksum
722 2012-02-21 19:43:25 <gmaxwell> sipa: see!
723 2012-02-21 19:43:27 <gmaxwell> they do exist.
724 2012-02-21 19:43:48 <BlueMatt> jm9000: ping
725 2012-02-21 19:44:21 <BlueMatt> ;;later tell jm9000 just fyi, we found out last night that the debugable binaries built with debug symbols are only debugable in gdb as the symbol format differs from compiler to compiler...
726 2012-02-21 19:44:21 <gribble> The operation succeeded.
727 2012-02-21 19:44:27 <sipa> gmaxwell: the preceeding "version" was correct, however
728 2012-02-21 19:45:13 <gmaxwell> sipa: so now try replacing addrme with all RFC1918 addresses. :)
729 2012-02-21 19:45:33 <sipa> ?
730 2012-02-21 19:45:48 <helo> are the distributed binaries compiled with -g, and then stripped?
731 2012-02-21 19:46:31 <BlueMatt> helo: no
732 2012-02-21 19:46:43 <helo> i guess may result in worse performance
733 2012-02-21 19:46:45 <BlueMatt> helo: I hope to (maybe) make that a reality for 0.6 though
734 2012-02-21 19:47:07 <BlueMatt> helo: even unstripped binaries offer little to no performance difference
735 2012-02-21 19:47:14 <helo> it's pretty nice being able to get useful core dumps :D
736 2012-02-21 19:48:19 <helo> oh, i guess -g doesn't imply -Oanything. but for maximally useful core dumps, -O0 is best afaik
737 2012-02-21 19:48:37 <BlueMatt> yea, but we arent gonna release -O0 binaries
738 2012-02-21 19:48:45 <helo> understandable heh
739 2012-02-21 19:48:48 <BlueMatt> -O2 -g is still pretty useful
740 2012-02-21 19:49:13 <BlueMatt> -O3 starts to get really ugly, but even then -g would be much, much more useful than nothing
741 2012-02-21 19:50:18 <sipa> and -O1 is still debugable
742 2012-02-21 19:52:14 <BlueMatt> I would still argue for keeping it at -O2 for released binaries
743 2012-02-21 19:52:21 <BlueMatt> debuging is still really damn useful there
744 2012-02-21 19:52:37 <sipa> sure
745 2012-02-21 19:54:59 <BlueMatt> ;;seen gavinandresen
746 2012-02-21 19:54:59 <gribble> gavinandresen was last seen in #bitcoin-dev 23 hours, 23 minutes, and 44 seconds ago: <gavinandresen> Ok, ignore Luke's knee-jerk window bashing, then
747 2012-02-21 20:11:40 <sipa> ;;bc,calcd 4000 0.06
748 2012-02-21 20:11:41 <gribble> The average time to generate a block at 4000 Khps, given the supplied difficulty of 0.06, is 1 minute and 4 seconds
749 2012-02-21 20:12:19 <luke-jr> jgarzik: ping
750 2012-02-21 21:19:23 <luke-jr> jgarzik: don't suppose you'd know how to recover from a process lockup in kernelspace?
751 2012-02-21 21:19:31 <luke-jr> or anything about the USB subsystem?
752 2012-02-21 21:19:51 <jrmithdobbs> luke-jr: unload the modules for it is about all you can do, if they wont you're p much fucked
753 2012-02-21 21:21:40 <alexwaters> does anyone know the name of that long-term bitcoin storage solution that was shown off at the NYC conference? it used some kind of printer with magets...
754 2012-02-21 21:22:59 <BlueMatt> you mean a deterministic wallet with a printer to print its seed?
755 2012-02-21 21:24:55 <alexwaters> possibly, it was some kind of miracle that used magnets. and they had ferrous dust to show a hash when you touched the string of magnets to the dust container
756 2012-02-21 21:25:07 <alexwaters> iirc
757 2012-02-21 21:25:14 <BlueMatt> that seems unreliable...