1 2011-09-29 00:31:46 <elkingrey> Can anybody explain this? http://pastebin.com/VymMjL1F
  2 2011-09-29 00:32:19 <casascius> elkingrey: do you have the bitcoin gui client running
  3 2011-09-29 00:32:49 <elkingrey> This is a server I am running on. Is that even possible?
  4 2011-09-29 00:33:05 <casascius> does bitcoin or bitcoind show up if you type: ps x
  5 2011-09-29 00:33:49 <elkingrey> http://pastebin.com/tnpWhHLR
  6 2011-09-29 00:34:16 <elkingrey> I don't know what to make of that.
  7 2011-09-29 00:34:45 <casascius> maybe need a bitcoin.conf
  8 2011-09-29 00:35:11 <elkingrey> Already got it. I was able to initiate bitcoind once, and it said server starting. But since then I haven't got anything else
  9 2011-09-29 00:35:52 <casascius> if you do ps x does the 42:01 keep increasing like a clock?
 10 2011-09-29 00:36:37 <luke-jr> elkingrey: tail -f ~/.bitcoin/debug.log
 11 2011-09-29 00:36:48 <elkingrey> yes it does
 12 2011-09-29 00:36:51 <elkingrey> ok
 13 2011-09-29 00:37:05 <casascius> what is it up to now
 14 2011-09-29 00:37:30 <elkingrey> It is increasing like a clock, but now I am tailing it
 15 2011-09-29 00:37:35 <elkingrey> It seems to be processing blocks
 16 2011-09-29 00:39:15 <casascius> normally mine needs a minute or two to think before it starts responding to rpc commands, but after that, it should respond, even if the block chain isn't downloaded
 17 2011-09-29 00:48:56 <luke-jr> ;;bc,diff
 18 2011-09-29 00:49:28 <gribble> 1689334.4045971
 19 2011-09-29 01:15:40 <CIA-101> libbitcoin: genjix * r7f401e7a257c /Makefile: Improved Makefile which builds libbitcoin.so
 20 2011-09-29 01:55:43 <CIA-101> libbitcoin: genjix * r1f0057e93baf / (16 files in 6 dirs): One line implementation of CBigNumber::set_uint64 :)
 21 2011-09-29 03:46:51 <AlexWaters> anyone have a minute to explain sign and verify messages to me? i'm trying to figure out the output I get when i sign a message
 22 2011-09-29 03:52:42 <AlexWaters> i'm able to sign and verify messages, but is there any way for a user to look up the message of an address?
 23 2011-09-29 03:53:11 <ThomasV> AlexWaters: what are you using?
 24 2011-09-29 03:53:45 <AlexWaters> i'm testing Sipa's #524 which is a revision of khalahan's #183
 25 2011-09-29 03:54:01 <ThomasV> oh I see
 26 2011-09-29 03:57:25 <ThomasV> AlexWaters: I wrote a python script that does the same, because I was not able to revise #183 myself
 27 2011-09-29 03:57:47 <ThomasV> nice to see it's going to be into bitcoind
 28 2011-09-29 03:59:44 <ThomasV> it would be nice to put a link on the #183 page
 29 2011-09-29 04:02:23 <AlexWaters> will do
 30 2011-09-29 04:04:33 <osmosis> Ive had my bitcoin server running for over a month, but it hasnt passed 100 connections. Should it be getting more?
 31 2011-09-29 04:18:30 <AlexWaters> osmosis: I don't think so, I wouldn't be concerned
 32 2011-09-29 04:55:10 <chris989> test
 33 2011-09-29 04:55:54 <chris989> Is anyone willing to briefly discuss importprivkey with me from a users perspective?
 34 2011-09-29 04:57:59 <chris989> Seems quiet. Wondering if my client is working.  Anyone care to just say hello so I know I am not talking into space...
 35 2011-09-29 04:58:28 <doublec> you are not talking into space
 36 2011-09-29 04:58:54 <theymos> It's always quiet at this time.
 37 2011-09-29 04:59:39 <chris989> OK.  Thanks for the feedback
 38 2011-09-29 04:59:49 <theymos> What's your question about importprivkey?
 39 2011-09-29 04:59:59 <diki> theymos:its slow
 40 2011-09-29 05:00:13 <diki> i had to import around half a million keys
 41 2011-09-29 05:00:22 <diki> i gave up when i found out it would take weeks
 42 2011-09-29 05:00:30 <chris989> I am wondering if there is a way for me as a user to import a private key into the windows client?
 43 2011-09-29 05:00:31 <theymos> Does it rescan after each key?
 44 2011-09-29 05:00:43 <diki> chris989:there is
 45 2011-09-29 05:00:50 <diki> pywallet
 46 2011-09-29 05:01:10 <chris989> Is pywallet an .exe I run in the windows OS?
 47 2011-09-29 05:01:15 <diki> its python
 48 2011-09-29 05:01:21 <diki> so you'd need the python interpreter
 49 2011-09-29 05:01:38 <chris989> But I can get a Win python interpreter I believe
 50 2011-09-29 05:01:38 <diki> and whatever it needs to run pywallet
 51 2011-09-29 05:01:39 <theymos> If importprivkey is included in the official releases as an RPC command, then you can use it on Windows. I don't know if it is, though.
 52 2011-09-29 05:01:54 <diki> theymos:afaik, its not
 53 2011-09-29 05:01:58 <diki> thought it should be
 54 2011-09-29 05:01:59 <chris989> I am not really a developer.  More of a power user
 55 2011-09-29 05:02:19 <chris989> so I could probably muddle through setting up python...
 56 2011-09-29 05:02:27 <chris989> but not certain
 57 2011-09-29 05:03:08 <diki> python is all next-next-next
 58 2011-09-29 05:03:21 <diki> the harder thing is installing dependencies
 59 2011-09-29 05:03:48 <chris989> OK on the next - next - next.  I can do that...
 60 2011-09-29 05:04:15 <midnightmagic> namecoin
 61 2011-09-29 05:04:19 <diki> because some dependencies need easy_install or whatever, other are egg files
 62 2011-09-29 05:04:25 <diki> which are actually zip files
 63 2011-09-29 05:04:40 <diki> midnightmagic:what about it
 64 2011-09-29 05:05:10 <chris989> Are you going to be around for a bit?  maybe I should install python and see how far I get.  I know you are not my tech support, but I appreciate the guidance so far.  Thanks.
 65 2011-09-29 05:05:20 <diki> chris989:probably not
 66 2011-09-29 05:05:41 <chris989> OK. Well, I have a direction at least.  Thanks.
 67 2011-09-29 05:05:48 <midnightmagic> diki: woops, I was trying to search for mentions of it. pay me no heed..
 68 2011-09-29 05:05:48 <theymos> Make sure you back up your wallet before messing with it, just in case.
 69 2011-09-29 05:07:25 <chris989> OK, and I do that by backing up the wallet.cpp and wallet.h, correct?  I can also find instructions on line I am sure.
 70 2011-09-29 05:07:40 <diki> lol
 71 2011-09-29 05:07:46 <diki> no you need to backup wallet.dat
 72 2011-09-29 05:07:55 <diki> which is located in %appdata%/Bitcoin
 73 2011-09-29 05:08:08 <chris989> got it.  I can do that.  Thx
 74 2011-09-29 05:08:31 <doublec> chris989: why do you need to import a private key?
 75 2011-09-29 05:09:14 <diki> doublec:why are you asking?
 76 2011-09-29 05:09:17 <diki> everybody has a reason
 77 2011-09-29 05:09:27 <chris989> doublec, I like the idea of transfering my balance to a physical paper public address (with a corresponding private address).
 78 2011-09-29 05:10:01 <chris989> Then I can keep my BTC safe in a physical location, and "reload" it into a new wallet when I decide to create one
 79 2011-09-29 05:10:19 <doublec> diki: because ordinary users don't normally need to so I was curious what the use case was
 80 2011-09-29 05:10:20 <diki> chris989:generate a random address or an address with your keyword with vanitygej
 81 2011-09-29 05:10:25 <diki> *vanitygen
 82 2011-09-29 05:10:32 <diki> and import the private key
 83 2011-09-29 05:11:26 <chris989> vanitygen?  I take it I can convert a private key to a phrase I create?
 84 2011-09-29 05:12:41 <diki> vanitygen is a bitcoin address generator
 85 2011-09-29 05:12:49 <diki> which also includes a privatekey
 86 2011-09-29 05:13:07 <diki> its idea is to make custom addresses, but the longer the word, the harder it is
 87 2011-09-29 05:13:18 <chris989> got it.  I will check that out too.
 88 2011-09-29 05:14:23 <chris989> @doublec: I like the idea of a paper address, because computers crash, and if you want to save your balance to paper, that seems to me a pretty safe place to save a sizable BTC balance for a longer period of time...
 89 2011-09-29 05:15:28 <diki> chris989:a bitcoin privatekey has upper case and lower case characters
 90 2011-09-29 05:15:34 <diki> it'd suck if you mistake just one
 91 2011-09-29 05:15:44 <chris989> ...I just don't trust having a large balance on my PC/Linux box while folks more skilled than I figure out ways to hack in a snatch my balance
 92 2011-09-29 05:16:34 <chris989> OK, gotcha on the potential of screwing up the privkey string
 93 2011-09-29 05:17:09 <chris989> but I still like the idea of saving to paper.  Do you see that as a valuable part of the overall bitcoin concept?
 94 2011-09-29 05:17:33 <diki> i guess
 95 2011-09-29 05:17:43 <doublec> I just have a seperate wallet I send to and have that encrypted and offline
 96 2011-09-29 05:17:48 <diki> is it not going to be hard to type it out by hand?
 97 2011-09-29 05:18:05 <diki> i'd honestly go crazy to type a privkey to some textbox
 98 2011-09-29 05:18:49 <chris989> yes, I agree with the complexity of typing the privkey string
 99 2011-09-29 05:19:38 <doublec> the thought of me stuffing up importing/exporting private keys using random python programs into and out of wallets containing my entire fortune worries me more than hackeres
100 2011-09-29 05:20:35 <chris989> Interesting.  I am thinking about things here.
101 2011-09-29 05:21:08 <diki> doublec:could you please not decourage the user with that crap?
102 2011-09-29 05:21:59 <diki> if pywallet was just a random python program, obviously people would've said something about the code
103 2011-09-29 05:22:25 <chris989> I don't know.  There is something comforting to me about being able to move value on and off line.  The value of course exists in the block chain, but I can bury that key in my metaphorical mason jar.
104 2011-09-29 05:23:03 <doublec> chris989: sure, nothing wrong with that. just be aware of risks.
105 2011-09-29 05:23:06 <chris989> ...mail it to my grandma.  put it in my will, etc...
106 2011-09-29 05:23:22 <doublec> chris989: there have been people in the past who accidentally deleted their wallet and backups while manually trying to improve their safety
107 2011-09-29 05:23:43 <chris989> I don't doubt it!
108 2011-09-29 05:24:31 <chris989> I once took my PC into a tech consultant to have him install a RAID array.  He overwrote my original HD.  I know the misery.
109 2011-09-29 05:25:27 <chris989> I really believe moving your BTC onto paper, and then bank to your electronic wallet would be a pretty important innovation for bitcoin.
110 2011-09-29 05:25:49 <chris989> Just my thought.  Maybe I am off base.
111 2011-09-29 05:26:07 <doublec> yes, a "print private key as barcode" option in the client would be nice
112 2011-09-29 05:26:09 <chris989> "back", not "bank".  See above...
113 2011-09-29 05:26:17 <doublec> with a 'scan from barcode" import
114 2011-09-29 05:26:27 <cjdelisle> yea
115 2011-09-29 05:26:29 <chris989> absolutely
116 2011-09-29 05:26:52 <cjdelisle> in the mean time something you could do is:   cat wallet.dat | openssl end -e -base64 > wallet.txt
117 2011-09-29 05:27:00 <cjdelisle> and then print wallet.txt
118 2011-09-29 05:27:07 <cjdelisle> then:  shred wallet.txt
119 2011-09-29 05:27:34 <chris989> OK.  those are linux commands, correct?
120 2011-09-29 05:27:43 <cjdelisle> sorry cat wallet.dat | openssl enc -e -base64 > wallet.txt
121 2011-09-29 05:27:56 <cjdelisle> that's bash but it can be done in winx
122 2011-09-29 05:28:14 <chris989> got it.  I can refresh my skills and do some of that...
123 2011-09-29 05:28:28 <theymos> The output from that will be thousands of characters. I'd hate to type that...
124 2011-09-29 05:28:41 <chris989> @cjdelisle: how do I get it back into a new client?
125 2011-09-29 05:28:56 <cjdelisle> scan and character recognition?
126 2011-09-29 05:29:05 <chris989> or maybe "wallet" is a better term
127 2011-09-29 05:29:14 <cjdelisle> oh
128 2011-09-29 05:29:40 <cjdelisle> cat wallet.txt | openssl enc -d -base64 > wallet.dat.backup
129 2011-09-29 05:30:01 <cjdelisle> after scanning in the paper to wallet.txt
130 2011-09-29 05:30:56 <chris989> Is there any momentum to develop what I am trying to do for less sophisticated users?  Getting private keys into wallets easily?
131 2011-09-29 05:31:13 <cjdelisle> not really
132 2011-09-29 05:31:28 <theymos> Didn't Gavin say he didn't like the idea?
133 2011-09-29 05:31:32 <cjdelisle> largely because there's a website that offers to make your private key for you
134 2011-09-29 05:31:55 <chris989> yes, but you have to get that private key into a wallet somehow
135 2011-09-29 05:32:07 <cjdelisle> right
136 2011-09-29 05:32:13 <cjdelisle> which makes the website not usefull
137 2011-09-29 05:32:28 <cjdelisle> so noone is going to lose their shirt because the website went bad
138 2011-09-29 05:33:37 <chris989> I was a financial planner for a long time.  Old people put there money in safety deposit boxes, make plans on paper with wills and trusts.  They don't leave thumb drives to their kids. This is the perspective I am coming from.
139 2011-09-29 05:33:39 <wumpus> the problem with simply adding private keys into your wallet is that you can't be sure that they are fully trusted (ie, someone else might have them as well).. which means that you'd have to handle them specially, don't send change to them etfc...
140 2011-09-29 05:34:37 <wumpus> it's better to simpy generate a new address in your wallet and dsend the coins there "from the received private key", instead of adding it to the wallet db
141 2011-09-29 05:34:49 <cjdelisle> chris989: I totally understand and I have been one of the loudest voices in favor of a more confortable UI but the "protect users from their mistakes" lobby seems to be winning so far.
142 2011-09-29 05:35:16 <AlexWaters> cjdelisle: I am in that lobby
143 2011-09-29 05:36:53 <wumpus> yes, printing the private keys in your wallet on paper (for example in Qr-code format) would certainly have a lot of use-cases, at least it's unhackable (protecting something physically is much more proven)
144 2011-09-29 05:37:21 <cjdelisle> I would favor designing a means of exporting a wallet as JSON which can be read by a human to see the valie and by a machine to build a new wallet...
145 2011-09-29 05:38:39 <wumpus> you want to print json? that's really, really low density.. and also harder to OCR reliably
146 2011-09-29 05:39:05 <cjdelisle> I want to be able to look at it and know what it says
147 2011-09-29 05:39:23 <cjdelisle> some random qrcode might aswell be a steriogram
148 2011-09-29 05:39:27 <wumpus> if you want t aprintout format better think it through very well, ie add error correction and such
149 2011-09-29 05:39:46 <AlexWaters> lol
150 2011-09-29 05:39:57 <cjdelisle> what does a stock or bond certificate look like? That's what I want
151 2011-09-29 05:40:03 <wumpus> which qr codes have.. (in some fashion, maybe not enough for long term storage)
152 2011-09-29 05:40:17 <AlexWaters> they have crypto images, i forget what they're called - but IMO better for this use case
153 2011-09-29 05:40:35 <wumpus> cjdelisle: so add some human readable headers and footers to recognize what it is
154 2011-09-29 05:40:44 <AlexWaters> where they're memorable, but don't convey any human readable info
155 2011-09-29 05:40:51 <chris989> the stock or bond cert idea is great.  Also, people not comfortable with a digital currency  will associate it with something of value
156 2011-09-29 05:41:28 <wumpus> the human and machine readable parts don't have to be the same. .that'd even add some redundancy
157 2011-09-29 05:41:44 <wumpus> ie, have the key in both hex and qr code...
158 2011-09-29 05:41:50 <chris989> Now you have to have a easy way to get it in and out of "the matrix"
159 2011-09-29 05:41:51 <cjdelisle> /nod
160 2011-09-29 05:42:36 <wumpus> well the biggest problem is that you'd ideally need an offline device to create the private keys, to make sure they never touch the net
161 2011-09-29 05:42:59 <wumpus> it just generates the key and prints it, and stores the public key somewhere to coins can be put on it
162 2011-09-29 05:43:14 <cjdelisle> the biggest problem is that you just said 'ideally'
163 2011-09-29 05:43:19 <chris989> wampus: yes, I totally agree
164 2011-09-29 05:43:33 <AlexWaters> isn't that what bitbills does?
165 2011-09-29 05:43:37 <wumpus> anything that is even connected to the net for a few seconds is potentially compromised
166 2011-09-29 05:44:01 <wumpus> AlexWaters: yes, I suppose so
167 2011-09-29 05:44:24 <wumpus> but you need to trust them to not store the private keys, in that case, like RSA turned out to do :')
168 2011-09-29 05:44:37 <cjdelisle> except bitbills knows the private key
169 2011-09-29 05:44:48 <cjdelisle> they promise to forget but... yea...
170 2011-09-29 05:45:41 <AlexWaters> surely someone could open source their tech, and hardware to make portable bitbill printers...
171 2011-09-29 05:46:09 <cjdelisle> like a computer running bitcoind without any internet connection?
172 2011-09-29 05:46:13 <wumpus> so it's not just 'a matter of ui'... the workflow would have to be thought through carefully , and no handwaving with regard to security
173 2011-09-29 05:46:35 <chris989> maybe bitbill kiosks, like an ATM?
174 2011-09-29 05:46:50 <AlexWaters> cjdelisle: that works
175 2011-09-29 05:46:57 <cjdelisle> that exists
176 2011-09-29 05:46:59 <cjdelisle> the ATM
177 2011-09-29 05:47:34 <cjdelisle> IMO it should interface with a bitcoind enabled haldheld device (like a cellphone) but that will probably be a future thing
178 2011-09-29 05:47:40 <chris989> yes, but it doesn't give you a tidy little number that you can deposit $1MM onto
179 2011-09-29 05:47:54 <wumpus> cjdelisle: you could use that, or even better, a simpler program that generates keys and does nothing else :)
180 2011-09-29 05:48:08 <cjdelisle> no
181 2011-09-29 05:48:30 <wumpus> if it's an embedded device you certainly don't want the entire bitcoin protocol cruft around
182 2011-09-29 05:48:59 <cjdelisle> best is bitcoind on a handheld which does all of the jobs, create keys, send payment, check balance
183 2011-09-29 05:49:15 <cjdelisle> identify received payments so you know who payd
184 2011-09-29 05:49:22 <wumpus> that already exists, the bitcoin android apps...
185 2011-09-29 05:49:34 <cjdelisle> there's your keygen
186 2011-09-29 05:49:39 <wumpus> but it needs needswork connectivity to check balance
187 2011-09-29 05:49:43 <wumpus> which is what you don't want
188 2011-09-29 05:50:03 <cjdelisle> then disable the network on yours
189 2011-09-29 05:50:13 <cjdelisle> the rest of the world won't
190 2011-09-29 05:50:13 <wumpus> and it's not suited for longterm offline storage
191 2011-09-29 05:50:23 <wumpus> you don't want to store your phone in a safe locker
192 2011-09-29 05:50:29 <chris989> I am going to go play with pywallet and vanitygen.  I really appreciate the conversation.  I hope you guys are here if/when I come back.  Thank you very much!
193 2011-09-29 05:50:36 <wumpus> so it seems you want something else than me
194 2011-09-29 05:50:57 <cjdelisle> I want the all-in-1 wallet solution
195 2011-09-29 05:51:05 <wumpus> that already exists
196 2011-09-29 05:51:10 <cjdelisle> you want a random number generator with point multiplication
197 2011-09-29 05:51:19 <cjdelisle> which also already exists
198 2011-09-29 05:51:19 <wumpus> yes.. which has a printer integrated
199 2011-09-29 05:51:39 <cjdelisle> but you are the only one who would use that
200 2011-09-29 05:51:44 <wumpus> it must be able to commit to paper (produce certificates) otherwise it's useless
201 2011-09-29 05:52:26 <wumpus> not really... it's the only way if you want 'perfect' security
202 2011-09-29 05:52:42 <cjdelisle> That's like compiling your os yourself on a compiler which you personally reviewed the assembler code to
203 2011-09-29 05:52:56 <cjdelisle> noone does it
204 2011-09-29 05:53:03 <wumpus> huh
205 2011-09-29 05:53:34 <wumpus> no, it'd be more like securing voting machines (which is hard, yes :P)
206 2011-09-29 05:55:17 <cjdelisle> wumpus: http://c2.com/cgi/wiki?TheKenThompsonHack
207 2011-09-29 05:55:23 <wumpus> it'd be a serious product, I don't think a large enough market exists at this moment, but if bitcoin keeps growing there will be
208 2011-09-29 05:56:07 <wumpus> it has to be very careful at least to not store the private key long enough in memory for interception
209 2011-09-29 05:58:00 <wumpus> but as soon as the key is on paper, in a safe, and it exists nowhere else you have perfect security (at least against hacks... not against old-fashioned bank robbers)
210 2011-09-29 05:58:36 <cjdelisle> http://cm.bell-labs.com/who/ken/trust.html
211 2011-09-29 05:58:52 <wumpus> whatever...
212 2011-09-29 06:01:23 <chris989> Yes, you have to have total security against electronic hacks.  I am a moderate power user, but not a programmer.  There will always be someone smarter than me, ahead of my skill level.  Until I can put that on paper in my safety deposit box, there is a real limit as to how much I can entrust to my electronic wallet.
213 2011-09-29 06:01:36 <wumpus> even if not "perfect" in theoretical sense, at least it'd be more secure than the current situation with large amounts of bitcoins sitting on user's day-to-day pcs
214 2011-09-29 06:02:14 <wumpus> exactly chris989
215 2011-09-29 06:03:23 <wumpus> one zero-day exploit is enough to subvert most if not all of the digital security a person can put in place, if the recent high-profile hacks have shown anything... it's not like those organizations are clueless
216 2011-09-29 06:03:32 <cjdelisle> A handheld device which can send and receive btc and does not have any other software on it, IE: no other ports are listening than 8333 and it's not calling anyone, would be much better and the average person would be able to use it.
217 2011-09-29 06:03:48 <cjdelisle> esp. since they could take it to stores and buy things with it
218 2011-09-29 06:03:59 <AlexWaters> i wish people had more comments at the bottom of their code explaining it to non-native speakers =P I don't see that hardly ever...
219 2011-09-29 06:04:47 <wumpus> I could add comment in dutch! (or broken german! :P)
220 2011-09-29 06:05:03 <cjdelisle> but this discussion has gone round and round and round, it always ends up at the same place, just noone is bothering to write the code
221 2011-09-29 06:05:15 <wumpus> my point is that this isn't simply about code
222 2011-09-29 06:05:44 <wumpus> it's about a workflow, code is only a very small (and relatively trivial) part of it
223 2011-09-29 06:06:01 <cjdelisle> or, build the androidish device to do it and make sure the attack surface is nothing other than bitcoind itself
224 2011-09-29 06:06:26 <wumpus> I wouldn't trust my life to a bitcoind connected to the open internet, personally...
225 2011-09-29 06:06:31 <wumpus> but yeah, that could be just me :-)
226 2011-09-29 06:07:26 <cjdelisle> You have no clue the level of security that exists in major financial insitutions and government. IE6 is universal just to give you the gist
227 2011-09-29 06:07:43 <wumpus> I know
228 2011-09-29 06:07:55 <cjdelisle> UI UI UI UI UI
229 2011-09-29 06:08:05 <cjdelisle> noone cares about perfect security
230 2011-09-29 06:08:29 <wumpus> if you're so convinced that you have a good idea, why don't you build it?
231 2011-09-29 06:08:43 <wumpus> it's not like you need validation from a few geeks in an irc channel
232 2011-09-29 06:08:47 <cjdelisle> + other irons in the fire
233 2011-09-29 06:09:39 <wumpus> also, no one cares about perfect security in the case that transactions can be reversed
234 2011-09-29 06:09:56 <chris989> Hey, can I sneak a python Q in here between the lines?  I have Python and the bsddb installed.  Do I just paste pywallet at the prompt, or do I need to educate my self on compiling the program.  Just point me in the right direction...
235 2011-09-29 06:10:04 <wumpus> but suppose that you owned gold you'd certainly care about perfect security
236 2011-09-29 06:10:29 <wumpus> especially if it's large amounts...
237 2011-09-29 06:10:59 <AlexWaters> chris989: I think you should be able to save the file as a .py and execute it from the command line. Is this what you mean?
238 2011-09-29 06:11:17 <wumpus> chris989: you don't need to compile python, you can simply run the script
239 2011-09-29 06:11:25 <cjdelisle> I happen to know that gold people don't touch computers in their business, everything is done over the phone or in person.
240 2011-09-29 06:11:27 <AlexWaters> i didn't have to compile when I copied some python the other day
241 2011-09-29 06:11:28 <chris989> yes, that is what I mean. OK, I will go work on it.
242 2011-09-29 06:11:52 <wumpus> cjdelisle: exactly... computers are not trustable in such cases
243 2011-09-29 06:12:18 <AlexWaters> cjdelisle: I vaguely remember gold finger owning a computer in the James Bond movie...
244 2011-09-29 06:12:23 <wumpus> which is exactly our point with offline paper wallets
245 2011-09-29 06:12:46 <AlexWaters> cjdelisle: and a few giant lasers
246 2011-09-29 06:12:55 <wumpus> hehe
247 2011-09-29 06:13:01 <cjdelisle> yea, +1 for paper, your little random number generator with a printer idea will get about 3 adopters in the world though
248 2011-09-29 06:13:26 <chris989> BTW, to the points above.  People don't care about perfect security, but they are scared of what they don't understand.  Your bitbill under your bed and a Colt .357 is not perfect, but at least you understand it.  That is just a coment on human nature...
249 2011-09-29 06:13:37 <AlexWaters> there are also the bitcoin magnet guys. i forget the name of their product - but they do what I think you're talking about
250 2011-09-29 06:13:47 <AlexWaters> and I think they sell the printer, not the end product
251 2011-09-29 06:14:00 <wumpus> cjdelisle: I don't need your validation on my ideas, if I were to develop it I'd do decent market research first and certainly not go by the opinion of people on irc :-)
252 2011-09-29 06:14:37 <cjdelisle> try to be a little less convincing
253 2011-09-29 06:14:57 <wumpus> AlexWaters: cool
254 2011-09-29 06:17:57 <wumpus> AlexWaters: please let me know if you come across it again, google doesn't turn op much
255 2011-09-29 06:19:45 <AlexWaters> ok they were at the btc conference, let me find it
256 2011-09-29 06:21:15 <chris989> Alexwaters: I am at the command line GUI of Python for Window, and pywallet.py is on my desktop.  Care to toss me another bone?
257 2011-09-29 06:22:20 <AlexWaters> chris989: I have no idea how pywallet works #python should be able to help though =/
258 2011-09-29 06:22:43 <chris989> OK.  Thanks.
259 2011-09-29 06:22:44 <AlexWaters> to output to a file I think you would do pywallet.py > file.txt
260 2011-09-29 07:40:28 <ThomasV> sorry to ask again, I gorgot : what is the .git url of a pull request? I don't find the link
261 2011-09-29 07:40:34 <ThomasV> *forgot*
262 2011-09-29 07:43:59 <TuxBlackEdo> https://github.com/gavinandresen/bitcoin-git.git
263 2011-09-29 07:47:58 <ThomasV> TuxBlackEdo: 4404
264 2011-09-29 07:48:02 <ThomasV> err, 404
265 2011-09-29 09:14:05 <diki> is there any bitcoin patch which adds an rpc command to get only generated and immature transactions
266 2011-09-29 09:14:22 <diki> i.e instead of getting ALL transactions with listtransactions i need to list only generated blocks
267 2011-09-29 09:14:34 <diki> generated/immature etc
268 2011-09-29 09:54:10 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * ra715a9b / .npmignore : Fix npm still including build-cc/.wafpickle-7. See #35. - http://git.io/BWtJfg
269 2011-09-29 11:12:02 <sipa> gmaxwell: have you done any implementation for your compressed block chain format?
270 2011-09-29 11:22:32 <gavinandresen> sipa: just sent you email RE: multisig transactions
271 2011-09-29 11:27:52 <sipa> gavinandresen: ack; having addresses in the store without private keys would be useful
272 2011-09-29 11:28:24 <sipa> that shouldn't be hard: we already have the ability for HaveKey() to return true, while GetKey() fails (wallets being encrypted)
273 2011-09-29 11:29:02 <gavinandresen> cool.
274 2011-09-29 11:29:16 <sipa> the only difference is that CreateTransaction can legitimately fail in that case
275 2011-09-29 11:30:24 <sipa> better would probably be to have SelectCoins skip coins that are accessibly through our-but-unavailable keys
276 2011-09-29 11:33:01 <sipa> only inconvenience: the 0.4 wallet format uses ckey entries that are index by pubkey
277 2011-09-29 11:33:14 <sipa> you need something indexed by address/hash160 for that
278 2011-09-29 12:57:25 <CIA-101> bitcoin: Gavin Andresen master * re8e0e23 / src/bitcoinrpc.cpp :
279 2011-09-29 14:39:13 <CIA-101> bitcoin: Nils Schneider master * r7dd4001 / src/bitcoinrpc.cpp :
280 2011-09-29 14:39:57 <diki> is there any bitcoin patch which adds an rpc command to get only generated and immature transactions
281 2011-09-29 14:40:09 <diki> generated/immature etc
282 2011-09-29 14:40:30 <diki> cause currently i loop over listtransactions and that isnt very good
283 2011-09-29 14:43:04 <luke-jr> diki: I had a patch for bitcoind to do that
284 2011-09-29 15:07:48 <genjix> gavinandresen: hey, about your DoS code... why did you choose a ranking algorithm over a more strict policy?
285 2011-09-29 15:08:16 <genjix> i was holding off disconnect policies for nodes based of how bitcoin behaves
286 2011-09-29 15:08:31 <genjix> but my default would be to insta-connect any node which misbehaves in the slightest
287 2011-09-29 15:08:33 <tcatm> genjix: IIRC there's a post about that on the mailing list
288 2011-09-29 15:08:36 <gavinandresen> genjix: hmm?  What would the more strict policy be?
289 2011-09-29 15:08:37 <genjix> *disconnect
290 2011-09-29 15:08:56 <genjix> a more strict policy = unforgiving policy
291 2011-09-29 15:09:03 <gavinandresen> genjix: ah, insta-disconnect...   well, DoS(100, ...) means insta-disconnect under the default limits
292 2011-09-29 15:09:33 <genjix> yep, but i'm just curious why if a node sends the version message twice, why isn't that grounds for dropping the link
293 2011-09-29 15:09:56 <gavinandresen> genjix: I wanted to be a little more forgiving in lots of cases where maybe a coding error in an alternate client resulted in mildly weird behavior
294 2011-09-29 15:10:58 <gavinandresen> genjix: and if you want a no-tolerance policy for your node, you can set -banscore=1  and get it
295 2011-09-29 15:11:43 <genjix> well by having an unforgiving policy from the start
296 2011-09-29 15:11:51 <genjix> it forces alt clients to get the protocol right
297 2011-09-29 15:12:02 <genjix> rather than letting errors creep in and having them deviate.
298 2011-09-29 15:12:30 <genjix> as the python mantra goes: http://www.python.org/dev/peps/pep-0020/
299 2011-09-29 15:12:43 <genjix> There should be one-- and preferably only one --obvious way to do it.
300 2011-09-29 15:12:50 <genjix> Errors should never pass silently.
301 2011-09-29 15:12:57 <genjix> Special cases aren't special enough to break the rules.
302 2011-09-29 15:13:39 <genjix> heh most of that applies here: "Explicit is better than implicit.", "Simple is better than complex."
303 2011-09-29 15:14:01 <gavinandresen> I'd like to see a release behaving properly with the default -banscore=100; we could switch the default to -banscore=1 if all goes well
304 2011-09-29 15:14:31 <genjix> k
305 2011-09-29 15:14:44 <phantomcircuit> im mildly regretting eating sushi in poland
306 2011-09-29 15:14:57 <gavinandresen> only mildly?  you're doing well, then
307 2011-09-29 15:14:57 <genjix> why
308 2011-09-29 15:15:11 <phantomcircuit> gavinandresen, iknorite
309 2011-09-29 15:15:16 <gavinandresen> (bad sushi can be really bad.... spend the day in the toilet bad...)
310 2011-09-29 15:15:24 <phantomcircuit> im going to wash it down with a bunch of coca cola
311 2011-09-29 15:15:27 <phantomcircuit> acid kills
312 2011-09-29 15:15:56 <genjix> i never ate sushi until a week ago. loved it :)
313 2011-09-29 15:16:20 <phantomcircuit> i suspect sushi in europe is consistently subpar
314 2011-09-29 15:16:24 <phantomcircuit> tuna was bland
315 2011-09-29 15:16:32 <genjix> one i ate was homemade
316 2011-09-29 15:16:35 <phantomcircuit> then again i cant imagine where it actually came from...
317 2011-09-29 15:16:50 <genjix> oh...
318 2011-09-29 15:16:57 <genjix> you're inland :o
319 2011-09-29 15:17:00 <phantomcircuit> the quality of the fish is far more important
320 2011-09-29 15:17:12 <genjix> ruh roh
321 2011-09-29 15:17:20 <genjix> hohoho
322 2011-09-29 15:17:40 <phantomcircuit> it's funny the way im processing bitcoin deposits works perfectly
323 2011-09-29 15:17:53 <phantomcircuit> but it spikes cpu usage every few seconds with the list transactions call
324 2011-09-29 15:18:35 <phantomcircuit> bah i cant get the qt gui to build
325 2011-09-29 15:20:48 <phantomcircuit> there's a dependency missing for QtDBus
326 2011-09-29 15:21:43 <genjix> there shouldn't be.
327 2011-09-29 15:21:51 <phantomcircuit> ah but there is
328 2011-09-29 15:21:52 <phantomcircuit> :P
329 2011-09-29 15:22:00 <genjix> DBus is part of the new desktops for gnome/kde
330 2011-09-29 15:22:15 <phantomcircuit> yes i know what dbus is
331 2011-09-29 15:22:25 <genjix> grep the qt headers i guess
332 2011-09-29 15:22:31 <phantomcircuit> it's used 99% to display desktop notifications
333 2011-09-29 15:22:37 <phantomcircuit> it's a library dependency
334 2011-09-29 15:22:45 <genjix> no it isn't
335 2011-09-29 15:22:48 <phantomcircuit> https://privatepaste.com/download/9b4e2be68b
336 2011-09-29 15:22:52 <phantomcircuit> genjix, lol yes it is
337 2011-09-29 15:22:54 <genjix> dbus is for messaging service
338 2011-09-29 15:23:00 <phantomcircuit> QtDBus.so
339 2011-09-29 15:23:11 <phantomcircuit> silly genjix
340 2011-09-29 15:23:18 <genjix> loads of apps use it behind the scenes but you don't notice it
341 2011-09-29 15:23:31 <genjix> it's how the kde toolchain communicates between each other
342 2011-09-29 15:23:51 <phantomcircuit> i hardly use any kde programs
343 2011-09-29 15:23:53 <phantomcircuit> so
344 2011-09-29 15:24:13 <genjix> yeah but i think gnome is the same
345 2011-09-29 15:24:15 <phantomcircuit> also there is something wrong with the Makefile generation
346 2011-09-29 15:24:23 <phantomcircuit> dbus was written for gnome
347 2011-09-29 15:24:27 <genjix> nope
348 2011-09-29 15:24:28 <phantomcircuit> so yeah im guessing it is
349 2011-09-29 15:24:31 <genjix> it was a kde program
350 2011-09-29 15:24:33 <genjix> dcop
351 2011-09-29 15:24:46 <phantomcircuit> cant be it would have been called kbus
352 2011-09-29 15:25:18 <phantomcircuit> anyways like i was saying
353 2011-09-29 15:25:26 <phantomcircuit> 99% of it's use it desktop notifications
354 2011-09-29 15:25:33 <genjix> well dcop is the old precursor to dbus (part of kde project). there was a program (a gui viewer for dcop) called kdcop
355 2011-09-29 15:25:51 <genjix> there's something similar now you can use to view all the programs and possible function calls
356 2011-09-29 15:26:37 <phantomcircuit> anyways this has nothing to do with what i was saying
357 2011-09-29 15:26:43 <CIA-101> bitcoinj: hegjon@gmail.com * r225 /wiki/UsingMaven.wiki: Updated links to reflect recent changes in our Maven repository
358 2011-09-29 15:26:49 <genjix> a linux desktop is more complex than you think. it's lots of background daemons, and you communicate using dbus
359 2011-09-29 15:27:08 <phantomcircuit> the bitcoin-qt.pro file is broken in that it's not generating a makefile which includes libQtDBus.so even when it's required
360 2011-09-29 15:27:30 <genjix> set LD_LIBRARY_PATH?
361 2011-09-29 15:27:38 <phantomcircuit> the library path is fine
362 2011-09-29 15:27:42 <phantomcircuit> the makefile is broken
363 2011-09-29 15:28:18 <phantomcircuit> simply adding -lQtDBus to the end of the g++ line resulted in a successful build
364 2011-09-29 15:28:27 <phantomcircuit> so obviously it's the build system
365 2011-09-29 15:30:36 <phantomcircuit> sorting by address in the gui is far too slow
366 2011-09-29 15:32:22 <phantomcircuit> looks good other than that
367 2011-09-29 15:50:21 <gavinandresen> phantomcircuit: there's a pull request to fix the dependency...
368 2011-09-29 15:50:29 <phantomcircuit> ah
369 2011-09-29 15:50:41 <phantomcircuit> anything about the speed of address sorting
370 2011-09-29 15:50:43 <CIA-101> bitcoin: Gavin Andresen master * r9a7e5ed / (15 files in 5 dirs):
371 2011-09-29 15:50:53 <gavinandresen> ^-- that one
372 2011-09-29 15:51:03 <phantomcircuit> lold
373 2011-09-29 15:51:26 <ThomasV> me?
374 2011-09-29 15:54:56 <copumpkin> it'd be nice if the bitcoin client showed you your balance at the point every transaction happened
375 2011-09-29 15:56:43 <tcatm> copumpkin: I think the QT gui supports csv export so you could calculate that easily using gnumeric or similar applications
376 2011-09-29 15:57:04 <copumpkin> oh, I'm sure I could calculate it :) I just meant from a "ease of use" perspective
377 2011-09-29 15:57:19 <gavinandresen> grr   qmake now gives me    RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_de.qm'
378 2011-09-29 15:57:50 <ThomasV> it's the germans!
379 2011-09-29 15:58:01 <ThomasV> they are always to blame
380 2011-09-29 15:58:12 <crazy_imp> :(
381 2011-09-29 15:58:32 <gavinandresen> I don't know nuthin about qt translation stuff....
382 2011-09-29 15:59:42 <crazy_imp> gavinandresen: guess you need to compile it for english - or just copy the english version of the file to locale/bitcoin_de.qm
383 2011-09-29 16:01:32 <phantomcircuit> i suspect he is
384 2011-09-29 16:01:47 <tcatm> does anyone know whether there's a cross-platform ByteSwap function in boost or libc?
385 2011-09-29 16:04:16 <tcatm> mhm, thinking about it and reading the code I'd like to change the format of getwork's data field to be not byteswapped at all. this might avoid byteswapping completely
386 2011-09-29 16:04:38 <genjix> tcatm: boost defines some macros
387 2011-09-29 16:04:57 <genjix> to see what kind of system you're on.
388 2011-09-29 16:05:44 <gavinandresen> tcatm: the #else part of your patch looks like it is cross-platform
389 2011-09-29 16:06:04 <copumpkin> tcatm: htons and friends? what kind of behavior do you need?
390 2011-09-29 16:06:18 <gavinandresen> tcatm: the #if bits are just optimizations .....
391 2011-09-29 16:06:28 <tcatm> gavinandresen: yes, but some platforms (x86) do have native bswap instructions and I'd like to use a library that knows about this
392 2011-09-29 16:06:50 <gavinandresen> tcatm: why?
393 2011-09-29 16:07:02 <gavinandresen> tcatm: is it a bottleneck for something critical?
394 2011-09-29 16:07:05 <copumpkin> that must be an awfully tight loop you're running :)
395 2011-09-29 16:07:24 <phantomcircuit> lol
396 2011-09-29 16:07:34 <copumpkin> and if it isn't, I hear there's a cream for that
397 2011-09-29 16:08:16 <tcatm> gavinandresen: cleaner code. I don't really like the bitshifting and or'ing in bitcoin and would prefer more abstract code.
398 2011-09-29 16:08:52 <gavinandresen> tcatm: as long as it doesn't add another dependency, I like not duplicating code
399 2011-09-29 16:09:06 <copumpkin> tcatm: htons? :P
400 2011-09-29 16:09:17 <copumpkin> they're pretty ubiquitous
401 2011-09-29 16:09:35 <genjix> tcatm: https://gitorious.org/libbitcoin/libbitcoin/blobs/master/src/util/serializer.cpp
402 2011-09-29 16:09:35 <tcatm> once midstate is deprecated we will be able to serialize CBlock directly without duplicating the seralizer in FormatHashBuffers()
403 2011-09-29 16:10:17 <tcatm> copumpkin: htons might work
404 2011-09-29 16:10:31 <copumpkin> there are a lot of similar ones for different sizes and directions
405 2011-09-29 16:10:46 <copumpkin> instead of thinking in terms of swapping, they just talk about sending stuff to and from network byte order
406 2011-09-29 16:10:58 <copumpkin> so they're either nops or a swap
407 2011-09-29 16:10:59 <tcatm> genjix: that code's license is not compatible with bitcoin's
408 2011-09-29 16:11:18 <copumpkin> the advantage is that they're everywhere, the disadvantage if you're in a tight loop is that they're function calls
409 2011-09-29 16:11:49 <copumpkin> but most of the time a call overhead is pretty low compared to other things you're doing when you're converting byte orders (typically writing to network or disk, which are many orders of magnitude more expensive than a swap)
410 2011-09-29 16:11:49 <phantomcircuit> they also just are for loops typically
411 2011-09-29 16:13:51 <phantomcircuit> tcatm, it's my understanding that special instructions for byte swapping only exist for 32 and 64 bit values
412 2011-09-29 16:14:22 <tcatm> phantomcircuit: yes. and we need to byteswap 32 bit values
413 2011-09-29 16:14:49 <phantomcircuit> unless you're going to be calling the function billions of times
414 2011-09-29 16:14:54 <phantomcircuit> you'll never notice the difference
415 2011-09-29 16:15:24 <phantomcircuit> the cost of byte swapping 32 bit integers as 4 instructions instead of 1 is pretty much non existent
416 2011-09-29 16:15:30 <genjix> yeah if you're worried about this
417 2011-09-29 16:15:36 <genjix> then stop using c++
418 2011-09-29 16:15:42 <tcatm> speed is not that important as it is called only like 64 times per getwork
419 2011-09-29 16:15:56 <genjix> vtables are a million times worse.
420 2011-09-29 16:16:07 <tcatm> but I'd like to have clean and precise code that doesn't re-invent byteswapping
421 2011-09-29 16:16:29 <genjix> well it isn't in the c++ standard afaik
422 2011-09-29 16:16:32 <lfm> it seems to me it just makes sense to use builtin and standard lib calls rather than writing them yourself
423 2011-09-29 16:16:33 <genjix> i looked around a bit
424 2011-09-29 16:16:49 <genjix> there was some reason or another, but cant remember
425 2011-09-29 16:17:03 <phantomcircuit> tcatm, i would agree except that the code already has to be there for byte swapping 128 bit integers
426 2011-09-29 16:17:08 <genjix> i think it was something like that even with systems, they dont use consistent byte ordering for different things
427 2011-09-29 16:17:15 <phantomcircuit> so reusing that code instead of using the library calls seems preferable
428 2011-09-29 16:17:24 <tcatm> however, it looks like FormatHashBuffers() byteswaps everything and the SHA256 wrapper will byteswap again before hashing it maybe we can avoid byteswapping completely
429 2011-09-29 16:17:33 <phantomcircuit> 256*
430 2011-09-29 16:18:22 <phantomcircuit> genjix, hey donald came on skype for a minute and then disappeared saying nothing useful
431 2011-09-29 16:19:15 <lfm> phantomcircuit: the byteswaps for sha256 are 32 bit
432 2011-09-29 16:20:02 <phantomcircuit> i seem to remember there being about 4 byteswaps for 1 number when looking at the scripting engine
433 2011-09-29 16:20:09 <phantomcircuit> so i dont think it's quite that simple
434 2011-09-29 16:21:16 <lfm> was this for a bigendian machine or something?
435 2011-09-29 16:29:05 <BlueMattBot> Project Bitcoin build #44: FAILURE in 17 min: http://jenkins.bluematt.me/job/Bitcoin/44/
436 2011-09-29 16:29:06 <BlueMattBot> * laanwj: show balance in sendcoins screen (issue #24)
437 2011-09-29 16:29:07 <BlueMattBot> * laanwj: Change define to determine use of DBUS to USE_DBUS, to prevent overlap with Qt-defined QT_DBUS
438 2011-09-29 16:29:08 <BlueMattBot> * jannepulk: Removing the if statement entirely - not needed.
439 2011-09-29 16:29:09 <BlueMattBot> * laanwj: use median filter for peer-reported reported number of blocks
440 2011-09-29 16:29:10 <BlueMattBot> * laanwj: Add assertion size>0 to MedianFilter
441 2011-09-29 16:32:52 <lfm> I agree with tcatm : the byteswaps in getwork (and its kin) are counterproductive in some cases just from a code size point of view. it would be better if the miners did all their own byteswaps if they needed them.
442 2011-09-29 16:42:41 <phantomcircuit> lfm, that seems reasonable
443 2011-09-29 16:43:10 <tcatm> I think we even have some ancient SSE2 compatibility code (alignup template) that is not used anymore.
444 2011-09-29 16:44:38 <genjix> if you're looking to shorten extraneous code, start with the BigNum implementation
445 2011-09-29 16:44:57 <genjix> damn
446 2011-09-29 16:46:27 <tcatm> I prefer to start with code I'm already very familiar with, like the miner :)
447 2011-09-29 16:47:21 <lfm> I expect bignum is written to be more general purpose than we need.
448 2011-09-29 16:48:02 <lfm> more abstract
449 2011-09-29 16:49:19 <tcatm> I suspect there's a lot of potential for more optimized code in all the serializer functions, too.
450 2011-09-29 16:51:03 <genjix> yeah a lot of that code is copy pasted
451 2011-09-29 16:51:05 <lfm> the serializer is generally tied with i/o tho Id think where the code efficiency should rightly be secondary to clearity since the i/o operations dominate the time
452 2011-09-29 16:51:37 <genjix> no need for macros either
453 2011-09-29 17:06:09 <CIA-101> bitcoin: Wladimir J. van der Laan master * r07e2882 / bitcoin-qt.pro :
454 2011-09-29 17:06:10 <CIA-101> bitcoin: - Start lrelease during qmake phase to prevent errors/warnings - http://git.io/j9Zg5w
455 2011-09-29 17:06:11 <CIA-101> bitcoin: Gavin Andresen master * re297ea9 / bitcoin-qt.pro :
456 2011-09-29 17:06:12 <CIA-101> bitcoin: qmake build system improvements - http://git.io/p7fYWw
457 2011-09-29 17:15:43 <BlueMattBot> Yippie, build fixed!
458 2011-09-29 17:15:44 <BlueMattBot> Project Bitcoin build #45: FIXED in 7 min 15 sec: http://jenkins.bluematt.me/job/Bitcoin/45/
459 2011-09-29 17:26:52 <topace> hmmm my bitcoind now says i have no transactions
460 2011-09-29 17:26:56 <topace> ./bitcoin listtransactions
461 2011-09-29 17:27:38 <topace> (and no balance)
462 2011-09-29 17:40:38 <genjix> HAHAHAHA
463 2011-09-29 17:40:49 <genjix> you jealous? http://yfrog.com/hsf2whbj and http://yfrog.com/o06i6bzj
464 2011-09-29 17:41:05 <CIA-101> bitcoin: various qmake_system_crypto++ * r821382..aaa1c3 bitcoind-personal/ (497 files in 64 dirs): (480 commits)
465 2011-09-29 17:43:50 <luke-jr> genjix: fail
466 2011-09-29 17:43:55 <luke-jr> that's called obsession :p
467 2011-09-29 17:45:04 <genjix> next you'll be saying: "i don't like cake anyway >:( "
468 2011-09-29 17:45:35 <luke-jr> well, that too
469 2011-09-29 17:45:37 <luke-jr> but that's personal preference
470 2011-09-29 17:45:42 <genjix> :)
471 2011-09-29 17:46:25 <genjix> don't have a sweet tooth?
472 2011-09-29 17:50:14 <CIA-101> bitcoin: Luke Dashjr * r3af49b11f611 gentoo/net-p2p/bitcoin-qt/ (Manifest bitcoin-qt-9999.1.ebuild bitcoin-qt-9999.ebuild): net-p2p/bitcoin-qt-9999: updated mainline build system
473 2011-09-29 18:10:40 <wardearia> Anyone around that lives in New York near JFK?
474 2011-09-29 18:11:56 <wardearia> or anyone available to visit JFK airport tomorrow morning to help me to get to Newark airport asap after I arrive at JFK.
475 2011-09-29 18:14:08 <eT-eB> Hi, does anyone know where i can get some BTC on the test network?
476 2011-09-29 18:50:13 <kalamajo> this stuff actually work?
477 2011-09-29 18:50:31 <kalamajo> so i can run a computer program and generate bitcoins then transfer to US $?
478 2011-09-29 18:53:47 <kalamajo> well i looks like people actually bid on these things on ebay
479 2011-09-29 18:54:01 <kalamajo> so it has some market valuje
480 2011-09-29 18:54:04 <kalamajo> value
481 2011-09-29 18:54:10 <strk> UNKNOWN EXCEPTION bitcoin in CMyApp::OnUnhandledException()
482 2011-09-29 18:59:17 <genjix> kalamajo: best to go ask that in #bitcoin
483 2011-09-29 18:59:22 <genjix> this is mostly developers here
484 2011-09-29 19:02:13 <luke-jr> kalamajo: if you have a good Radeon GPU, yes; see #Eligius
485 2011-09-29 19:04:32 <strk> if you had any question for me please ask again
486 2011-09-29 19:06:28 <kalamajo> So I should go out and upgrade my graphics car
487 2011-09-29 19:06:30 <kalamajo> card
488 2011-09-29 19:06:53 <kalamajo> how much $ per hour with an average computer with a good graphics card?
489 2011-09-29 19:07:06 <jrmithdobbs> 0
490 2011-09-29 19:07:06 <kalamajo> well bitcoin/hr
491 2011-09-29 19:07:23 <kalamajo> or equivalent
492 2011-09-29 19:07:36 <luke-jr> kalamajo: with a Radeon 5850, currently
493 2011-09-29 19:07:41 <gribble> The average time to generate a block at 308 Khps, given current difficulty of 1689334.4045971 , is 746 years, 51 weeks, 6 days, 11 hours, 16 minutes, and 44 seconds
494 2011-09-29 19:07:41 <luke-jr> ;;bc,calc 308
495 2011-09-29 19:07:44 <luke-jr> err
496 2011-09-29 19:07:46 <luke-jr> ;;bc,gen 308
497 2011-09-29 19:07:47 <gribble> The expected generation output, at 308 Khps, given current difficulty of 1689334.4045971 , is 0.000183382958624 BTC per day and 7.64095660933e-06 BTC per hour.
498 2011-09-29 19:07:50 <luke-jr> ^
499 2011-09-29 19:07:55 <luke-jr> wait
500 2011-09-29 19:07:56 <luke-jr> that's wrong
501 2011-09-29 19:07:58 <luke-jr> ;;bc,gen 308000
502 2011-09-29 19:07:59 <gribble> The expected generation output, at 308000 Khps, given current difficulty of 1689334.4045971 , is 0.183382958624 BTC per day and 0.00764095660933 BTC per hour.
503 2011-09-29 19:08:02 <luke-jr> ^ that's a 5850
504 2011-09-29 19:08:33 <luke-jr> so about 3 cents per hour at the current market rate
505 2011-09-29 19:08:56 <kalamajo> k
506 2011-09-29 19:09:09 <luke-jr> hint: bitcoin doesn't exist for mining, mining exists for bitcoin
507 2011-09-29 19:09:18 <luke-jr> bitcoin exists as a medium of trade
508 2011-09-29 19:09:26 <luke-jr> ie, you do work, you get paid bitcoind
509 2011-09-29 19:09:28 <luke-jr> bitcoins*
510 2011-09-29 19:09:37 <luke-jr> you want to get work done, you pay someone else bitcoins
511 2011-09-29 19:09:49 <kalamajo> oh
512 2011-09-29 19:10:08 <kalamajo> how many bitcoins would it take for you to mow my lawn?
513 2011-09-29 19:10:28 <strk> would making mining less expensive undermine security ?
514 2011-09-29 19:10:55 <genjix> strk: easier to reverse blockchain
515 2011-09-29 19:11:04 <kalamajo> !ping
516 2011-09-29 19:11:10 <genjix> hint it's not the work that matters but the resources to create that work
517 2011-09-29 19:12:02 <luke-jr> kalamajo: I don't mow lawns
518 2011-09-29 19:12:28 <genjix> yeah he only sells his body
519 2011-09-29 19:12:38 <luke-jr> kalamajo: I'll write code for 10 BTC/hr tho
520 2011-09-29 19:12:43 <vegard> strk: ah there you are again. the initial download time is only going to get worse with time
521 2011-09-29 19:12:56 <luke-jr> well, maybe. depends on the value
522 2011-09-29 19:13:00 <kalamajo> I see
523 2011-09-29 19:13:04 <strk> vegard: I started downloadin the tarball
524 2011-09-29 19:13:13 <strk> 46 secs to go
525 2011-09-29 19:13:19 <strk> if someone would have told me earlier...
526 2011-09-29 19:13:22 <vegard> it has how much of the block chain?
527 2011-09-29 19:13:37 <strk> I closed the client at 350k
528 2011-09-29 19:13:37 <vegard> and why doesn't anybody fix the bitcoin client to go faster?
529 2011-09-29 19:13:49 <strk> eh, see I moved in -dev ? :)
530 2011-09-29 19:13:57 <strk> I don't have bitcoin to pay for that service though
531 2011-09-29 19:14:07 <strk> but I'm a programmer too, so I could look at it for some coins :)
532 2011-09-29 19:15:34 <luke-jr> vegard: gavin recently merged an optimization for block chain download
533 2011-09-29 19:15:37 <luke-jr> vegard: should be in 0.5
534 2011-09-29 19:15:50 <vegard> ah, sounds nice
535 2011-09-29 19:16:25 <vegard> I'm still using an old version. is it harmful?
536 2011-09-29 19:16:49 <vegard> 32300
537 2011-09-29 19:17:00 <luke-jr> vegard: yes, and has known exploits
538 2011-09-29 19:17:10 <vegard> really? which ones?
539 2011-09-29 19:17:12 <luke-jr> unless you use Gentoo maybe
540 2011-09-29 19:17:20 <luke-jr> vegard: someone could crash your client
541 2011-09-29 19:17:29 <vegard> should upgrade then :-/
542 2011-09-29 19:17:38 <luke-jr> Gentoo has a patched 0.3.23 ;)
543 2011-09-29 19:17:48 <luke-jr> but probably still has other issues
544 2011-09-29 19:18:06 <luke-jr> ofc, Gentoo has 0.4.0 too
545 2011-09-29 19:19:36 <vegard> I love that the scalability page on the bitcoin wiki talks about gigabytes per block and you'd only need a new 3-terabyte disk every 21 days to keep up, etc.
546 2011-09-29 19:21:10 <luke-jr> vegard: by that time, 3 TB won't be a new disk
547 2011-09-29 19:21:47 <vegard> hm. I started up 0.4.0 from bitcoin.org/sourceforge and it printed "Bitcoin version 0.4.0-beta" in the log
548 2011-09-29 19:22:57 <luke-jr> lol
549 2011-09-29 19:24:48 <helo> should 1.0 not be the first non-beta?
550 2011-09-29 19:25:10 <lianj> luke-jr: thats what they told us about a cpu core too
551 2011-09-29 19:25:29 <luke-jr> lianj: what?
552 2011-09-29 19:25:54 <lianj> that its scales and scales
553 2011-09-29 19:26:50 <strk> EXCEPTION: 11DbException
554 2011-09-29 19:27:04 <strk> I've rsync'ed the .bitcoin dir from another host
555 2011-09-29 19:27:20 <strk> and just started the just-downloaded 0.4.0 64bit version
556 2011-09-29 19:27:28 <strk> the other machine was a 32bit one
557 2011-09-29 19:28:04 <strk> beside, the client doesn't die
558 2011-09-29 19:28:38 <strk> stuck in main loop
559 2011-09-29 19:29:00 <helo> did you stop the bitcoin running on the other host before the rsync?
560 2011-09-29 19:30:01 <luke-jr> strk: you need to shutdown bitcoind to make a backup/copy
561 2011-09-29 19:30:04 <strk> got me (no)
562 2011-09-29 19:30:33 <strk> now it's off
563 2011-09-29 19:30:56 <strk> but there's still a .lock in the dir
564 2011-09-29 19:31:08 <strk> may be related to the previously reported exception
565 2011-09-29 19:33:13 <strk> alright, .lock removed, re-synched and started ok
566 2011-09-29 19:33:24 <strk> except for a warning: (bitcoin:23812): IBUS-WARNING **: Connect to unix:abstract=/tmp/dbus-G680yHZTZP,guid=90601e9f7b54e212447da87e4e4d3819 failed: Failed to connect to socket /tmp/dbus-G680yHZTZP: Connection refused.
567 2011-09-29 19:34:12 <strk> ah, got first coin !
568 2011-09-29 19:39:44 <strk> I always get the bitcoin in CMyApp::OnUnhandledException() on exit (after exit)
569 2011-09-29 19:48:13 <vegard> I just had an idea
570 2011-09-29 19:49:02 <vegard> it is not necessary for any client to store the full history
571 2011-09-29 19:50:07 <genjix> fClient
572 2011-09-29 19:50:10 <vegard> it is enough to store enough history to be secure, let's say the previous N blocks/transactions
573 2011-09-29 19:50:29 <genjix> wont work
574 2011-09-29 19:50:43 <gmaxwell> vegard: are you describing a lite client?
575 2011-09-29 19:50:53 <gmaxwell> Certantly those work, but they can't do full chain validation, of course.
576 2011-09-29 19:50:53 <vegard> and it instead becomes the burden of the sender to store the block headers on top of their transaction output (their coins)
577 2011-09-29 19:50:59 <vegard> not a lite client. a full client
578 2011-09-29 19:51:38 <gmaxwell> vegard: how does it tell a block isn't BS?
579 2011-09-29 19:51:40 <vegard> so that when the spender wants to spend his/her coins, he provides this chain of blocks that "bury"/prove his/her old transaction
580 2011-09-29 19:51:44 <luke-jr> vegard: how would you send old blocks to new clients/
581 2011-09-29 19:51:48 <wardearia> Is anyone here from New York by any chance?
582 2011-09-29 19:51:59 <gmaxwell> vegard: it sounds like you're describing the lite clients.
583 2011-09-29 19:52:13 <luke-jr> vegard: a full client needs to be able to upload all the existing blocks
584 2011-09-29 19:52:17 <vegard> luke-jr: new clients can query existing clients. the longest proof-of-work chain wins
585 2011-09-29 19:52:29 <gmaxwell> vegard: A full client can tell if a particular block confirms to the rules, what you're describing doesn't sound like it could. Instead its depending on other nodes to do that for it.
586 2011-09-29 19:52:43 <gmaxwell> er conforms.
587 2011-09-29 19:53:28 <gmaxwell> I can't type today, lets try this again.
588 2011-09-29 19:53:40 <vegard> it's ok, I got the point
589 2011-09-29 19:54:08 <gmaxwell> The fundimental distinction between a lite client and a full one is that a lite client can only validate things with help. It can't take a new block and tell if it follows the bitcoin rules. :)
590 2011-09-29 19:54:13 <gmaxwell> OK.
591 2011-09-29 19:54:22 <gmaxwell> Lite clients are a good though.
592 2011-09-29 19:54:34 <vegard> no, forget about lite and full clients for a moment.
593 2011-09-29 19:54:46 <genjix> what you're saying is impossible
594 2011-09-29 19:54:54 <gmaxwell> genjix: ssh
595 2011-09-29 19:55:01 <vegard> so new clients cannot verify transactions, but clients that do have these last N blocks can
596 2011-09-29 19:55:03 <genjix> :p
597 2011-09-29 19:55:13 <vegard> what new clients can do is check that something is the longest chain
598 2011-09-29 19:55:33 <genjix> no they cannot because A depends on B depends on C
599 2011-09-29 19:55:37 <vegard> once they have the last N blocks of the longest chain, they can start verifying new transactions
600 2011-09-29 19:55:57 <genjix> no
601 2011-09-29 19:56:03 <gmaxwell> vegard: What happens if I give you a transaction that is spending an input that was already spend N+1 blocks ago?
602 2011-09-29 19:56:10 <gmaxwell> s/spend/spent/
603 2011-09-29 19:56:15 <genjix> who's to say the first block in that sub-chain is valid?
604 2011-09-29 19:56:25 <gmaxwell> genjix: you could have the headers from the genesis.
605 2011-09-29 19:56:45 <gmaxwell> The blocks extending the subchain demonstrate the validity of the subchain.
606 2011-09-29 19:56:54 <vegard> gmaxwell: then you need to provide the "missing" blocks as well
607 2011-09-29 19:57:05 <genjix> nope you cannot validate the chain gmaxwell without the full block
608 2011-09-29 19:57:07 <gmaxwell> vegard: How do I know it's missing?
609 2011-09-29 19:57:13 <vegard> gmaxwell: which you can, since you must keep them
610 2011-09-29 19:57:21 <genjix> even with headers it could have fraudalent txs
611 2011-09-29 19:57:26 <vegard> no it cannot
612 2011-09-29 19:57:33 <genjix> yes it can
613 2011-09-29 19:57:39 <vegard> because then the rest of the network wouldn't have accepted it
614 2011-09-29 19:57:55 <vegard> and you cannot forge the hash in retrospect, so it MUST have been valid
615 2011-09-29 19:58:05 <vegard> if the current chain extends it
616 2011-09-29 19:58:16 <genjix> the whole point is you validate a chain until told otherwise
617 2011-09-29 19:58:19 <gmaxwell> vegard: In block 10 TXN is A is first mined.  Then in 100 A is spent.  Then at 200 someone gives you a txn spending A. You only have 150+
618 2011-09-29 19:58:35 <genjix> that's what the checkpoints do. they lockin to the accepted chain
619 2011-09-29 19:59:03 <gmaxwell> vegard: in that situation how do you know that the transaction is invalid?
620 2011-09-29 19:59:04 <vegard> gmaxwell: the transaction itself contains the block headers from 100 to 200
621 2011-09-29 19:59:15 <gmaxwell> vegard: the blockheaders don't help you.
622 2011-09-29 19:59:15 <vegard> oh wait
623 2011-09-29 19:59:22 <vegard> sorry, let me read and consider again.
624 2011-09-29 19:59:37 <genjix> eventually when you start tracing txs back you're going to get a gap
625 2011-09-29 19:59:47 <gmaxwell> And the person who gives you the transaction is not your friend. He will carefully not tell you about the txn in block 100.
626 2011-09-29 19:59:50 <genjix> at some point you have to accept the origin as true
627 2011-09-29 20:00:36 <vegard> gmaxwell: I think you got me.
628 2011-09-29 20:05:53 <gmaxwell> vegard: yea, well, I've also solve that particular problem.
629 2011-09-29 20:06:09 <gmaxwell> vegard: https://bitcointalk.org/index.php?topic=21995.0
630 2011-09-29 20:07:40 <gmaxwell> Bytecoin made a somewhat more complete version of that proposal which completely reverses the direction of the chain referencing (so it's always an open txn commitment) which drastically reduces the required space.. because someone looking to spend an input could always be counted on to store the complete history back to some agreed checkpoints.
631 2011-09-29 20:09:56 <vegard> the receiver signs the transaction?
632 2011-09-29 20:11:48 <gmaxwell> vegard: no.
633 2011-09-29 20:12:24 <gmaxwell> The sender still does. But the point is that if someone gives you an input it's worth your time to maintain a copy of the proof that the input is valid yourself.
634 2011-09-29 20:12:36 <vegard> right
635 2011-09-29 20:13:41 <vegard> so they maintain a copy of the chain from the point at which they received the txn?
636 2011-09-29 20:14:54 <gmaxwell> They don't need to maintain the whole chain. Just the transaction itself plus the merkel root fragment required to prove that its an open transaction as of the last block.
637 2011-09-29 20:15:30 <gmaxwell> In any case, it's not something we can do within bitcoin as it exists today. It would require a major redesign.
638 2011-09-29 20:15:46 <vegard> yeah, of course.
639 2011-09-29 20:17:13 <genjix> gmaxwell: i had a similar idea a while back of checkpoint-blocks
640 2011-09-29 20:17:32 <genjix> special blocks where the chain can be pruned but contains the current network's state
641 2011-09-29 20:17:53 <gmaxwell> genjix: yea, what I was proposing on the forum would basically make every block into one of those.
642 2011-09-29 20:18:14 <genjix> why not every 2000th block?
643 2011-09-29 20:18:43 <gmaxwell> Because it's actually really cheap to do. You don't acutally retrainsmit the data, you just include an additional root in the coinbase.
644 2011-09-29 20:19:13 <gmaxwell> and updating it is fairly cheap.. ~log2(opentxn) hashes per block on average.
645 2011-09-29 20:19:33 <genjix> ohhh
646 2011-09-29 20:19:46 <genjix> i get you. and then i can request the data for that root separately
647 2011-09-29 20:20:01 <gmaxwell> Yes. Or only fragments of it.
648 2011-09-29 20:20:03 <genjix> we can actually do that now
649 2011-09-29 20:20:09 <genjix> using the input script of a coinbase tx
650 2011-09-29 20:20:18 <gmaxwell> E.g. if you only want to validate a single txn.
651 2011-09-29 20:20:50 <gmaxwell> The problem is that you need miners to reject blocks that have bad opentxn hashes in them. Otherwise I can mine a bogus one and use it to make it look like txn are open which are not.
652 2011-09-29 20:21:21 <gmaxwell> Not all miners need to do this, but most because ones who validate will fork the chain from ones who don't should someone write in a bogus hash.
653 2011-09-29 20:21:55 <gmaxwell> but yes, unlikely bytecoin's more expansive proposal mine could be added to bitcoin as it exists today.
654 2011-09-29 20:22:23 <gmaxwell> You'd first start writing in the hashes then as of some block number you'd start validating... and if the majority of miners do that, then it's the new normal.
655 2011-09-29 20:22:41 <genjix> yep
656 2011-09-29 20:22:48 <genjix> sounds like a good idea.
657 2011-09-29 20:22:54 <gmaxwell> It would make it possible to have semi-full nodes that can do real validation but don't have all the data.
658 2011-09-29 20:22:58 <vegard> gmaxwell: if the receiver also signs the transaction, they can at least prove that the transaction was spent. but still other clients cannot verify that it _wasn't_ spent in the absence of the original receiver.
659 2011-09-29 20:23:15 <genjix> i actually prefer this for a light client than the idea of a txmatch regex command
660 2011-09-29 20:23:24 <gmaxwell> vegard: thats the key point that bitcoin today makes impossible unless you have all the data.
661 2011-09-29 20:23:56 <vegard> I know :)
662 2011-09-29 20:23:57 <genjix> well you'd still need the txs though, but this is a good idea
663 2011-09-29 20:24:32 <gmaxwell> my idea is also good for a possible future where full nodes are rare because they are expensive to operate... in that future semi-full nodes could still keep the full ones honest by _randomly_ checking a fraction of the transactions.
664 2011-09-29 20:24:49 <gmaxwell> "Oh, this got mined? Prove it was valid."
665 2011-09-29 20:25:28 <gmaxwell> And they'd give you the tree fragments provine each of the inputs was live in the open set as of N blocks ago.
666 2011-09-29 20:25:32 <gmaxwell> er proving.
667 2011-09-29 20:25:32 <vegard> but is there really a need for lightweight nodes that connect directly to the bitcoin network?
668 2011-09-29 20:25:58 <vegard> if you rely on a trusted provider anyway, why not use custom software that interacts directly with the trusted provider
669 2011-09-29 20:26:04 <vegard> which, effectively, acts as your bank
670 2011-09-29 20:26:15 <gmaxwell> vegard: to lower the cost of the services of trusted providers, of course!
671 2011-09-29 20:27:00 <gmaxwell> If there is a decenteralized option which kinda sucks, the trusted services still need to provide superior service at a cost which justifies their value add. :)
672 2011-09-29 20:27:03 <vegard> surely their main cost will be network/storage for the full chain?
673 2011-09-29 20:27:34 <gmaxwell> Sure. And customer service.. and securing their systems.
674 2011-09-29 20:27:52 <vegard> they'll need that anyway
675 2011-09-29 20:28:17 <gmaxwell> Their costs aren't high.  But if thats the only way to have lite clients they'll be able to charge more than if the network had an effective way of supporting lite clients.
676 2011-09-29 20:28:44 <vegard> ok
677 2011-09-29 20:29:26 <vegard> I still get the feeling that bitcoin is not truly distributed, though :/
678 2011-09-29 20:30:05 <gmaxwell> Well, it's not completely because we don't yet have real software diversity.
679 2011-09-29 20:30:14 <gmaxwell> But I think we will someday.
680 2011-09-29 20:30:57 <vegard> I do believe there are real scalability problems
681 2011-09-29 20:31:31 <vegard> with no known solution, perhaps no solution at all (except "throw more resources at it")
682 2011-09-29 20:34:51 <gmaxwell> vegard: everything core to bicoin is linear with usage or better.
683 2011-09-29 20:35:02 <gmaxwell> So "throw more resources at it" should in fact be a real solution.
684 2011-09-29 20:35:16 <gmaxwell> But there is also "then don't use bitcoin for that".
685 2011-09-29 20:36:05 <gmaxwell> It's true that bitcoin would suck for direct use in a world where you pay a femto-cent to everyone whos shoes you like, for example. But the answer to that is don't use bitcoin for that.
686 2011-09-29 20:36:34 <gmaxwell> (in that case you should pay some few bitcoin into a femtopayment system, and then do your tiny transactions to that, settling your bitcoin balance every once in a while)
687 2011-09-29 21:06:56 <t3a> when will we see the bitcoin client deleting blocks to save space if ever? or is it being done now?