1 2011-06-14 00:00:05 <jgarzik> ArtForz: I'm definitely interested in a PCIe mining board
  2 2011-06-14 00:00:44 <jgarzik> Lachesis: well, forum.bitcoin.org is sirius-m (and theymos?)
  3 2011-06-14 00:00:48 <jgarzik> Lachesis: gavin and others can change the front page, which is hosted @ SF
  4 2011-06-14 00:01:01 <shLONG> why the hell is php so obscure
  5 2011-06-14 00:01:04 <Lachesis> jgarzik, cool
  6 2011-06-14 00:01:05 <Lachesis> shLONG, how does it fail?
  7 2011-06-14 00:01:12 <shLONG> nothing
  8 2011-06-14 00:01:27 <Lachesis> does it follow the wrong branch? does it fail to run? what's the problem?
  9 2011-06-14 00:01:27 <shLONG> it just doesnt return true when the address is valid
 10 2011-06-14 00:01:39 <shLONG> it follows false when its meant to be true
 11 2011-06-14 00:01:43 <Lachesis> what does echo $data['isvalid'] do?
 12 2011-06-14 00:01:58 <shLONG> good idea
 13 2011-06-14 00:02:06 <shLONG> 1
 14 2011-06-14 00:02:23 <Lachesis> for a valid address or a invalid one?
 15 2011-06-14 00:02:24 <shLONG> for a valid one
 16 2011-06-14 00:02:26 <Lachesis> ok
 17 2011-06-14 00:02:30 <Lachesis> now try an invalid one
 18 2011-06-14 00:02:52 <shLONG> same
 19 2011-06-14 00:02:55 <Lachesis> well
 20 2011-06-14 00:02:57 <Lachesis> there's your problem
 21 2011-06-14 00:03:02 <Lachesis> where is data['isvalid'] getting set?
 22 2011-06-14 00:03:09 <shLONG> $data = $bitcoin->validateaddress($recvaddr);
 23 2011-06-14 00:03:22 <Lachesis> print the whole data structure
 24 2011-06-14 00:03:34 <Lachesis> print_r($data);
 25 2011-06-14 00:03:52 <Lachesis> and what are your two addresses?
 26 2011-06-14 00:04:02 <Lachesis> just want to make sure one of them is actually invalid :)
 27 2011-06-14 00:04:44 <Lachesis> ;;seen sirius-m,
 28 2011-06-14 00:04:45 <gribble> I have not seen sirius-m,.
 29 2011-06-14 00:04:46 <shLONG> Array ( [isvalid] => )
 30 2011-06-14 00:04:47 <gribble> sirius-m was last seen in #bitcoin-dev 3 days, 2 hours, 42 minutes, and 54 seconds ago: <sirius-m> sipa: it's updated already?
 31 2011-06-14 00:04:47 <Lachesis> ;;seen sirius-m
 32 2011-06-14 00:05:06 <shLONG> 14qYPyX8L898gQhCze3aPMkF7EQJC7ESxw - valid
 33 2011-06-14 00:05:19 <shLONG> take a char out of it and it should be invalid
 34 2011-06-14 00:08:03 <shLONG> just makes no sense, why would it return a struct like that
 35 2011-06-14 00:08:47 <upb> var_dump it out
 36 2011-06-14 00:09:13 <upb> iirc print_r doesnt allow you to differentiate between null and ''
 37 2011-06-14 00:09:35 <shLONG> array(1) { ["isvalid"]=> bool(false) }
 38 2011-06-14 00:09:43 <shLONG> so it thinks the address is invalid :
 39 2011-06-14 00:09:53 <shLONG> but when i check via command prompt
 40 2011-06-14 00:09:55 <shLONG> it is valid
 41 2011-06-14 00:10:04 <upb> so read the code of the function
 42 2011-06-14 00:10:17 <shLONG> ?
 43 2011-06-14 00:10:26 <upb> the function that returns this array to you
 44 2011-06-14 00:11:01 <shLONG> OH SHIT
 45 2011-06-14 00:11:03 <shLONG> I KNOW WHY
 46 2011-06-14 00:11:07 <upb> see what it sends and receives, see whether theres any differences to what youre doing manually
 47 2011-06-14 00:11:08 <shLONG> im "" around it
 48 2011-06-14 00:11:10 <upb> heh
 49 2011-06-14 00:11:22 <shLONG> BUGGER
 50 2011-06-14 00:11:40 <shLONG> well it works now
 51 2011-06-14 00:11:48 <shLONG> but i learnet a lot
 52 2011-06-14 00:12:02 <shLONG> im sure that debugging help will come in handy in future too :D
 53 2011-06-14 00:12:05 <shLONG> tyx
 54 2011-06-14 00:31:22 <Lachesis> what's the status of IPv6 support in bitcoin?
 55 2011-06-14 00:31:57 <Lachesis> actually nm; l4d2 time :)
 56 2011-06-14 00:40:18 <IoWn3rU> is the ticker working finally?
 57 2011-06-14 00:42:33 <jrmithdobbs> wait a minute
 58 2011-06-14 00:43:09 <jrmithdobbs> looking at gavin's b58encode in bitcointools ... looks like he was having the same problem I am and cheated
 59 2011-06-14 00:43:49 <jrmithdobbs> and stuffs the ending remainder onto the front of the string after the encode loop
 60 2011-06-14 00:43:55 <jrmithdobbs> is that what has to be done?
 61 2011-06-14 00:44:03 <Detritus> btc -> mtgox -> dwolla -> amazon -> cat food
 62 2011-06-14 00:44:26 <Detritus> Opps wrong tab
 63 2011-06-14 00:44:43 <jrmithdobbs> (ending remainder encoded, obviously)
 64 2011-06-14 00:44:46 <muffinz> ;;bc,stats
 65 2011-06-14 00:44:49 <gribble> Current Blocks: 130649 | Current Difficulty: 567358.22457067 | Next Difficulty At Block: 131039 | Next Difficulty In: 390 blocks | Next Difficulty In About: 1 day, 16 hours, 5 minutes, and 0 seconds | Next Difficulty Estimate: 843694.97199947
 66 2011-06-14 00:46:03 <jrmithdobbs> holy crap
 67 2011-06-14 00:46:10 <jrmithdobbs> bitcoinj does the exact same thing
 68 2011-06-14 00:46:41 <jrmithdobbs> did i seriously just waste 4 hours in gdb and then adding #ifdef DEBUG code for nothing
 69 2011-06-14 00:47:29 <lfm> jrmithdobbs: do you have an example of that?
 70 2011-06-14 00:49:04 <luke-jr> [Tycho]: ping
 71 2011-06-14 00:49:50 <jrmithdobbs> lfm: http://home.jrbobdobbs.org/mith/b58.wtf.txt
 72 2011-06-14 00:50:47 <jrmithdobbs> lfm: lines in question: bitcoinj: s.insert(0, ALPHABET.charAt(bi.intValue())); bitcointools: result = __b58chars[long_value] + result
 73 2011-06-14 00:51:15 <jrmithdobbs> how the fuck does satoshi's code work? it clearly does not do this in base58.h
 74 2011-06-14 00:52:03 <lfm> jrmithdobbs: no I ment an address that demostrated the problem I oculd try with my code.
 75 2011-06-14 00:52:20 <jrmithdobbs> lfm: reproducable with any binary data
 76 2011-06-14 00:53:05 <jrmithdobbs> lfm: my code is sticking what ends up as the first char in satoshi's code as the last char
 77 2011-06-14 00:53:21 <lfm> jrmithdobbs: oh well my code seems to produce the right address string for now. I was thinking you found a special case I might have mised
 78 2011-06-14 00:53:32 <jrmithdobbs> lfm: looks like bitcoinj/bitcointools would too if they didn't do that
 79 2011-06-14 00:54:05 <jrmithdobbs> lfm: yours published?
 80 2011-06-14 00:54:26 <jrmithdobbs> cause I'm seriously confused by satoshi's code now
 81 2011-06-14 00:54:56 <lfm> not well, I could put a fresh copy up I spoze but who knows if its any easier to follow than any other. it is just plain C tho
 82 2011-06-14 00:55:12 <jrmithdobbs> lfm: so's mine, haha
 83 2011-06-14 01:00:02 <jrmithdobbs> holy shit, just figured it out
 84 2011-06-14 01:00:06 <jrmithdobbs> lol
 85 2011-06-14 01:00:12 <jrmithdobbs> OBO is fun
 86 2011-06-14 01:02:10 <jrmithdobbs> was looking at the wrong portion of the damned code
 87 2011-06-14 01:02:31 <jrmithdobbs> encoding was right, final endian swap was OBO which makes perfect sense now that I know
 88 2011-06-14 01:02:34 <jrmithdobbs> lol
 89 2011-06-14 01:03:32 <lfm> ya they are numbers with least significant part to right
 90 2011-06-14 01:03:43 <jrmithdobbs> no I understand that
 91 2011-06-14 01:04:05 <jrmithdobbs> was -1'ing a counter that was at the right value not +1 from where it should be ;P
 92 2011-06-14 01:04:17 <lfm> oh ok
 93 2011-06-14 01:04:26 <jrmithdobbs> on my final reverse_inplace() call ;P
 94 2011-06-14 01:18:03 <shLONG> is it possible to delete transaction logs from the bitcoin daemon
 95 2011-06-14 01:18:51 <shLONG> or is it possible to setup two accounts on one daemon and supply a recieve address for each account
 96 2011-06-14 01:19:01 <shLONG> so I can maintain two different balances
 97 2011-06-14 01:20:23 <shLONG> as far as I can tell, all new addresses deposit into my main address
 98 2011-06-14 01:21:37 <samr7> shLONG, each acct is separate, but the gui displays the aggregate balance
 99 2011-06-14 01:24:20 <upb> jrmithdobbs: hah, i noticed that the session id is not regenerated on session expire )
100 2011-06-14 01:24:41 <jrmithdobbs> upb: send MagicalTux an email
101 2011-06-14 01:24:43 <upb> so even though the site doesnt allow session fixation via url
102 2011-06-14 01:24:54 <upb> everyone is using the same sid until they close their browsers
103 2011-06-14 01:24:58 <jrmithdobbs> upb: he may actually be aware, he has some big backend changes coming
104 2011-06-14 01:25:03 <upb> oh
105 2011-06-14 01:25:19 <jrmithdobbs> (inherited code atm)
106 2011-06-14 01:25:21 <CIA-90> bitcoin: Daniel Folkinshteyn * r75885be34c9c supybot-bitcoin-marketmonitor/OTCWebsite/ (5 files): OTCWebsite: stuff all user inputs through htmlentities/html_entity_decode, to thwart html/js injection. http://tinyurl.com/3g762yr
107 2011-06-14 01:25:34 <shLONG> samr7: well I supplied a recieve address for deepbit and recieved 0.4btc, when checking my accounts the 0.4btc didnt end up in my recieve address it ended up in my main address?
108 2011-06-14 01:26:33 <samr7> shLONG, try using the listreceivedbyaccount RPC
109 2011-06-14 01:28:47 <Joric> what happens on the 100th address? are they looped?
110 2011-06-14 01:29:26 <Joric> i'm worrying about the old copy of a wallet
111 2011-06-14 01:30:44 <MagicalTux> [12:24:20] <upb> jrmithdobbs: hah, i noticed that the session id is not regenerated on session expire ) <- I improved that a bit, now :)
112 2011-06-14 01:31:09 <jrmithdobbs> upb: told ya ;P
113 2011-06-14 01:31:45 <sanity> my stupid genetic algorithm is currently expecting the price to drop to $13, at which point it will buy
114 2011-06-14 01:32:03 <alystair> lol @ genetic algo applied to market situations
115 2011-06-14 01:32:05 <sanity> i need to stop watching it so closely, it is bad for my blood pressure
116 2011-06-14 01:32:26 <sanity> alystair: oh?  do elaborate please...
117 2011-06-14 01:32:36 <lfm> sanity: how much money does it have to play with? grin
118 2011-06-14 01:32:52 <jrmithdobbs> lfm: a lot.
119 2011-06-14 01:33:45 <upb> MagicalTux: good :)
120 2011-06-14 01:34:16 <sanity> lfm: not a lot
121 2011-06-14 01:34:51 <jrmithdobbs> sanity: shhh just say a lot it's more fun
122 2011-06-14 01:35:25 <sanity> i wish it was a lot because over the last few days it has beaten the market by about 30%
123 2011-06-14 01:36:00 <sanity> but that could be a fluke, who knows
124 2011-06-14 01:36:02 <Joric> looks like key pool tops-up with 100 new keys after every 100 transactions, am i right?
125 2011-06-14 01:36:02 <upb> what does it have as inputs btw if its not a secret ?
126 2011-06-14 01:36:03 <jrmithdobbs> mtgox data of course
127 2011-06-14 01:36:06 <jrmithdobbs> or whatever market
128 2011-06-14 01:36:07 <upb> yes but is it just order fills
129 2011-06-14 01:36:16 <upb> or also bid/ask sizes
130 2011-06-14 01:36:32 <sanity> when i did my PhD on GAs with the currency markets, they were competing against much more sophisticated trading algorithms than appear to be active on MtGox right now
131 2011-06-14 01:37:41 <sanity> the real advantage of these systems for markets though is that they tend to encourage market stability, which Bitcoin seems to need
132 2011-06-14 01:39:57 <sanity> upb: the inputs are various, mtgox data, bitcoin transaction data (ie. when bitcoins are moved into accounts that seem to be linked to mtgox)
133 2011-06-14 01:40:12 <sanity> upb: the last one seems to be very predictive of sell-offs, surprise surprise
134 2011-06-14 01:40:27 <sanity> upb: but it would be unfair not to give it every available advantage
135 2011-06-14 01:40:59 <Joric> could anyone explain how many keypairs a wallet have? how often i should make backups?
136 2011-06-14 01:41:33 <sanity> upb: the mtgox data includes everything that mtgox provides, including all current open orders
137 2011-06-14 01:41:41 <Joric> i don't quite understand what's happening with keypairs currently
138 2011-06-14 01:42:07 <sanity> Joric: you can create lots of keypairs, ideally one for every transaction you do
139 2011-06-14 01:42:25 <Joric> continue, kind sir
140 2011-06-14 01:42:31 <sanity> Joric: they are like accounts that can send and/or receive money
141 2011-06-14 01:42:39 <sanity> um. s/money/bitcoins
142 2011-06-14 01:43:20 <sanity> Joric: your wallet is a collection of these keypairs/addresses
143 2011-06-14 01:44:16 <Joric> looks like i'll lose all new transactions if i'll restore from an older copy of a wallet, unless there would be a pregenerated pool of addresses
144 2011-06-14 01:44:27 <sanity> Joric: i think so, yes
145 2011-06-14 01:44:35 <Joric> so,
146 2011-06-14 01:44:52 <sanity> Joric: if you lose a keypair, you lose the ability to send the bitcoins in it to anyone else - ie. they become useless
147 2011-06-14 01:44:53 <Joric> what's happening on keypoolsize+1 send?
148 2011-06-14 01:45:03 <jrmithdobbs> sanity: except when things go wrong (re: stability) ... p sure that jump to 30 was an algorithm gone bad
149 2011-06-14 01:45:35 <jrmithdobbs> Joric: right now? 100 new keys get genned at once before send
150 2011-06-14 01:45:37 <sanity> jrmithdobbs: i agree, i think the main advantage of employing GAs is to achieve better market stability
151 2011-06-14 01:46:15 <sanity> jrmithdobbs: as it stands, some early bitcoin adopter can sell a bunch and crash the market - which hurts bitcoin's overall credibility and utility
152 2011-06-14 01:46:17 <jrmithdobbs> sanity: not that my bank account is complaining about said jump, of course
153 2011-06-14 01:46:29 <Joric> jrmithdobbs, so the keypoolsize become 200?
154 2011-06-14 01:46:31 <sanity> jrmithdobbs: not if you got out at the right time
155 2011-06-14 01:46:50 <jrmithdobbs> sanity: and I did. Goodby cc debt. ;P
156 2011-06-14 01:47:01 <sanity> jrmithdobbs: good for you :-)
157 2011-06-14 01:47:21 <Joric> i've really tired of digging through code it's not that readable
158 2011-06-14 01:47:30 <sanity> jrmithdobbs: but you should never have been in cc debt in the first place, of course
159 2011-06-14 01:47:56 <upb> unless its interest free :)
160 2011-06-14 01:49:17 <sanity> once my GA is relatively stable, my intention is to allow people to participate in the pool it controls.  NOT as a get-rich-quick scheme, but because it will help market stability.  my GA is designed to always bet on stability, and thus if its pool is big enough, it will counter large sudden jolts that damage Bitcoin's credibility
161 2011-06-14 01:50:23 <sanity> ...while making a decent return for participants, *if* the market remains reasonably stable
162 2011-06-14 01:51:12 <jrmithdobbs> upb: it was mostly, actually, lol
163 2011-06-14 01:52:07 <jrmithdobbs> sanity: it wasn't that much cc debt, got into financial trouble end of last year cause of health issues and the us' wonderful healthcare system ;P
164 2011-06-14 01:52:34 <jrmithdobbs> cc debt or not eating is a p easy choice
165 2011-06-14 01:53:27 <jrmithdobbs> sanity: sounds good to me. only a matter of time before several people are doing the same.
166 2011-06-14 01:54:23 <jrmithdobbs> sanity: nice blurb on your cv too ... "First bitcoin-backed mutual fund." ;P
167 2011-06-14 02:00:48 <sanity> jrmithdobbs: hah, not sure if i'd call it a mutual fund - perhaps a mutual pool ;-)
168 2011-06-14 02:01:13 <Kireji> ;;bc,mtgox
169 2011-06-14 02:01:15 <gribble> {"ticker":{"high":24.5,"low":16,"vol":75005,"buy":19.72,"sell":19.74,"last":19.74}}
170 2011-06-14 02:03:53 <Joric> i'm having doubts about a particular address
171 2011-06-14 02:04:46 <Joric> after restoring from an older copy i see the transaction in a client but client doesnt say that address is 'yours' and it's not in the list of receiving addresses
172 2011-06-14 02:05:38 <Joric> i assume it is in the pool but it is hidden, or there's something else
173 2011-06-14 02:06:36 <Joric> ? may i have a keypair that doesn't show up in a list of a receiving addresses?
174 2011-06-14 02:15:03 <CIA-90> bitcoin: Daniel Folkinshteyn * r3a8c186fe287 supybot-bitcoin-marketmonitor/MarketMonitor/plugin.py: MarketMonitor: fix for the changed bitcoincharts feed format http://tinyurl.com/6g3yrjm
175 2011-06-14 02:24:17 <luke-jr> tcatm: did you break it? -.-
176 2011-06-14 03:24:57 <AnonX> Is the bitcoin-wallet that you download from bitcoin.org open source, as in can you make changes on it and customize it?
177 2011-06-14 03:41:26 <gjs278> ;;bc,stats
178 2011-06-14 03:41:28 <gribble> Current Blocks: 130672 | Current Difficulty: 567358.22457067 | Next Difficulty At Block: 131039 | Next Difficulty In: 367 blocks | Next Difficulty In About: 1 day, 14 hours, 1 minute, and 31 seconds | Next Difficulty Estimate: 842214.36433008
179 2011-06-14 03:43:01 <Joric> got 5/unconfirmed after a hour, is that normal? paid 0.001 for 'oversized transacton'
180 2011-06-14 03:44:33 <doublec> Joric: normal. the client considers anything under 6 to be unconfirmed.
181 2011-06-14 03:44:59 <manveru> yo
182 2011-06-14 03:45:45 <manveru> i'm poring through the source of pushpoold, and see "rewrite returned 'target' to difficulty-1" - anybody there to explain what that means?
183 2011-06-14 03:47:35 <doublec> manveru: it makes the client miner think the difficuty is 1 so it will return a result when it reaches that target
184 2011-06-14 03:47:57 <doublec> manveru: this allows the pool to count 'difficulty 1 shares' and work out how much the miner is contributing to the pool
185 2011-06-14 03:48:08 <manveru> oh, ok
186 2011-06-14 03:48:15 <doublec> manveru: the pool will pass the result up the chain to the bitcoind to see if it solved the real target
187 2011-06-14 03:48:39 <manveru> but that also means the pool gets a ton more results?
188 2011-06-14 03:49:12 <doublec> yes
189 2011-06-14 03:49:55 <manveru> so it's better to cook up some math to calculate based on the real difficulty?
190 2011-06-14 03:50:15 <doublec> I'm not sure what you mean
191 2011-06-14 03:51:07 <manveru> well, i can only imagine that rewriting to 1 is to make calculation of contribution easier
192 2011-06-14 03:51:17 <manveru> haven't tried it yet...
193 2011-06-14 03:51:47 <manveru> but if the server load goes through the roof just to make that calculation easier, i reason that it's better to fix the calculation instead
194 2011-06-14 03:52:06 <doublec> just up the difficulty that gets rewritten
195 2011-06-14 03:52:29 <manveru> hm
196 2011-06-14 03:52:31 <manveru> ah, i see
197 2011-06-14 03:52:36 <Joric> wow i've got confirmed
198 2011-06-14 03:52:41 <manveru> if it's too high, clients will never get back with a share
199 2011-06-14 03:53:03 <Joric> it took 1h20m
200 2011-06-14 03:53:15 <Joric> kinda sucks
201 2011-06-14 03:53:47 <doublec> Joric: you can use the coins after the first confirmation
202 2011-06-14 03:53:47 <Joric> maybe because of the 'oversized transaction'
203 2011-06-14 03:53:54 <Joric> but i've paid a fee
204 2011-06-14 03:53:58 <doublec> Joric: you don't need to wait for all 6
205 2011-06-14 03:54:27 <Joric> i've got first confirmation after 50m then
206 2011-06-14 04:01:29 <alystair> what format is the DB file in?
207 2011-06-14 04:01:55 <manveru> alystair: which db file?
208 2011-06-14 04:02:25 <manveru> the blk0001.dat ?
209 2011-06-14 04:20:35 <Prodego> why thank you BCBot - (I'd note chanserv can send entry /notices automatically)
210 2011-06-14 04:25:30 <hdon-> hi all :) where should i begin reading the bitcoin source code? no goal other than exploration/curiosity
211 2011-06-14 04:39:40 <Kireji> I've left 4 cpu cores running for 10 days atraight, and made 0.06 bitcoin in a pool, or about $1.20 ->  conclusion: CPU mining is totally hopeless
212 2011-06-14 04:39:51 <Kireji> hdon-: github
213 2011-06-14 04:40:09 <CIA-90> bitcoin: Jeff Garzik * r4c57a66012e9 pushpool/ (AUTHORS ChangeLog NEWS configure.ac): Version 0.5. http://tinyurl.com/6he7tc9
214 2011-06-14 04:44:02 <Joric> Kireji, i've got about the same results on a nvidia 9800 GT gpu, so nvidia is hopeless as well
215 2011-06-14 04:44:58 <Joric> even high-end nvidias are like 5-10 slower than average ati's
216 2011-06-14 05:17:24 <manveru> corecode: ?
217 2011-06-14 05:21:50 <Joric> transactions take up to 2 hours now, don't you think the whole system will stop eventually
218 2011-06-14 05:26:34 <hdon-> Kireji, no i mean... any tips for browsing the source code?
219 2011-06-14 05:26:36 <hdon-> i have github tip already
220 2011-06-14 05:30:06 <jgarzik> Joric: huh?
221 2011-06-14 05:30:26 <jgarzik> Joric: transactions are confirmed every 10 minutes, on average.  right now... even faster
222 2011-06-14 05:31:12 <Joric> i've sent 0.5 btc with a fee it took 50 minutes to the first confirmation
223 2011-06-14 05:31:49 <zamgo> there is a mod_whois for apache, to make apache act as a whois server.  It be possible to do mod_bitcoin, to make apache act as a node and/or rpc server
224 2011-06-14 05:32:10 <zamgo> but... would it be worth anything?
225 2011-06-14 05:33:35 <jgarzik> Joric: sure, that happens on occasion
226 2011-06-14 05:33:56 <jgarzik> Joric: but right now there are 9.67 confirmations per hour, from the past 24 hours
227 2011-06-14 05:34:02 <jgarzik> Joric: so that is not representative at all
228 2011-06-14 05:38:28 <Joric> btw after restoring wallet it looked like i've lost a keypair but it suddenly appeared after the last transaction
229 2011-06-14 05:38:39 <Joric> i guess it's from the pool
230 2011-06-14 05:38:54 <bob2> no your keypair is not stored in the bitcoin network
231 2011-06-14 05:39:06 <Joric> don't know how often i should do backups now
232 2011-06-14 05:39:25 <jgarzik> Joric: backup after every single transaction
233 2011-06-14 05:39:29 <Joric> bob2, i know that
234 2011-06-14 05:39:31 <jgarzik> Joric: that you send
235 2011-06-14 05:39:36 <Joric> jgarzik, yeah
236 2011-06-14 05:45:12 <Joric> sorry i've got disconnected
237 2011-06-14 05:45:16 <Joric> jgarzik, how does it work now if i've used the whole pool? does it generate next 100 addresses?
238 2011-06-14 05:49:30 <Joric> or it expands a pool every time to have a 100 new addresses ahead
239 2011-06-14 06:29:30 <jgarzik> Joric: pool continually expands
240 2011-06-14 06:29:42 <Joric> got it
241 2011-06-14 06:32:44 <CIA-90> bitcoin: Han Lin Yap master * rc60da73 / (8 files in 8 dirs): Consistent Bitcoin example address - http://bit.ly/jDL5ZI
242 2011-06-14 06:33:08 <CIA-90> bitcoin: Jeff Garzik master * r6f460ba / (locale/sv/LC_MESSAGES/bitcoin.po src/util.cpp):
243 2011-06-14 06:33:10 <nathan7> lala
244 2011-06-14 06:37:18 <BlueMattBot> Project Bitcoin build #53: FAILURE in 1 min 10 sec: http://www.bluematt.me/jenkins/job/Bitcoin/53/
245 2011-06-14 06:37:20 <BlueMattBot> * codler: Double check translation and improved a translation string
246 2011-06-14 06:37:21 <BlueMattBot> * codler: Update swedish translation
247 2011-06-14 06:47:46 <FellowTraveler> Does anyone know the best code to use if you want to accept Bitcoins as payment on your own website? Like a shopping cart?
248 2011-06-14 06:51:30 <manveru> FellowTraveler: mtgox has some
249 2011-06-14 06:51:53 <CIA-90> bitcoin: Jeff Garzik master * rc02ec54 / src/util.cpp : FormatFullVersion: build fix related to recent translation improvement - http://bit.ly/ksWTCB
250 2011-06-14 06:52:12 <jgarzik> FellowTraveler: mybitcoin.com or mtgox.com merchant API
251 2011-06-14 06:52:20 <manveru> FellowTraveler: https://mtgox.com/merch/about
252 2011-06-14 06:57:02 <TommyBoy3G> then the new version of client will come out? .23?
253 2011-06-14 06:58:18 <TommyBoy3G> its out, but not updated on both pages
254 2011-06-14 06:58:22 <TommyBoy3G> suks
255 2011-06-14 06:58:51 <TommyBoy3G> New version of Bitcoin (0.3.23) is out - http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/
256 2011-06-14 07:03:24 <TommyBoy3G> jgarzik please update topic on bitcoin chan about new version.
257 2011-06-14 07:06:01 <CIA-90> bitcoin: Jeff Garzik master * r19ea442 / (11 files):
258 2011-06-14 07:19:34 <Akinava> Help make a example hash '00' of the address
259 2011-06-14 07:19:45 <Akinava> http://blockexplorer.com/q/hashtoaddress/00 -> 112edB6q
260 2011-06-14 07:20:47 <Akinava> Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash'00')) 1406e05881e299367766d313e26c05564ec91bf721d31726bd6e46e60689539a
261 2011-06-14 07:20:57 <Akinava> addres in hex 1406e058+00 ?
262 2011-06-14 07:22:12 <lfm> Hi are you asking something?
263 2011-06-14 07:22:51 <BlueMattBot> Yippie, build fixed!
264 2011-06-14 07:22:52 <BlueMattBot> jgarzik: FormatFullVersion: build fix related to recent translation improvement
265 2011-06-14 07:24:03 <Akinava> lfm, Yes, I want to get an address from the hash
266 2011-06-14 07:27:29 <lfm> Akinava: ok you want to hash a public key and get and address?
267 2011-06-14 07:28:21 <phuzion> How would one go about building their own testnet?
268 2011-06-14 07:28:58 <lfm> phuzion: take two computers and use -connect=192.168.x.x on them both
269 2011-06-14 07:29:18 <lfm> phuzion: to connect them to each other only
270 2011-06-14 07:29:23 <Akinava> lfm, I know hash, I want get address
271 2011-06-14 07:29:41 <phuzion> lfm: isn't there something that you have to change in the source so you can make it start with its own new blockchain?
272 2011-06-14 07:29:56 <lfm> well you started with a key tho, right? or not right?
273 2011-06-14 07:30:19 <lfm> phuzion: Im not sure how youd do that
274 2011-06-14 07:30:51 <lfm> Akinava: some hashes you can turn into addresses and some you cant
275 2011-06-14 07:31:40 <coblee> hey maybe someone can help me here. i sent a transaction more than half an hour ago, but it's still not showing up on http://bitcoincharts.com/bitcoin/ and i have 8 connections and my blocks are up-to-date 130709
276 2011-06-14 07:31:54 <coblee> is my client just confused and not broadcasting the transaction?
277 2011-06-14 07:32:02 <lfm> Akinava: the hashes I know of that you can turn into keys are 20 bytes, not like yours
278 2011-06-14 07:32:22 <coblee> restarting the client doesn't help. what should i do?
279 2011-06-14 07:32:40 <lfm> coblee: some transactions take a very long time. a day or so
280 2011-06-14 07:32:52 <coblee> but shouldn't it be at least broadcasted?
281 2011-06-14 07:33:10 <coblee> i can understand that it can take a long time to pick up (if it's large with no fees)
282 2011-06-14 07:33:23 <coblee> but if it's not on http://bitcoincharts.com/bitcoin/ then no one even knows about it, right?
283 2011-06-14 07:33:39 <lfm> coblee: ya but I dont think anyone else will even see it till it gets 1 confirmed block
284 2011-06-14 07:33:45 <Akinava> I understand the theory of the address
285 2011-06-14 07:34:03 <doublec> coblee: I've had an error on sending that resulted in it not being broadcast
286 2011-06-14 07:34:11 <doublec> coblee: it took a few hours to go out in the end
287 2011-06-14 07:34:14 <Akinava> lfm, I want to understand the theory of the address
288 2011-06-14 07:34:43 <coblee> so just wait and it will somehow go out? or can i speed it up by clearing my local transaction list and restart and resend the btc?
289 2011-06-14 07:35:24 <lfm> Akinava: well as I understand it you start with a key that is I think 65 bytes and do ripem150(sha256(key)) to get a 20 byte hash
290 2011-06-14 07:35:29 <Akinava> sorry, ill know the language
291 2011-06-14 07:35:31 <lfm> Akinava: then ..
292 2011-06-14 07:36:07 <Akinava> lfm, yes ripem150(sha256(key) turned
293 2011-06-14 07:36:46 <lfm> Akinava: add a zero byte in front of it and convert to the base58 representation then add a 1 in front for every zero byte in fron of the 21 byte block
294 2011-06-14 07:37:36 <lfm> you treat the 21 byte value as a very large number and divide by 58 repeatedly
295 2011-06-14 07:38:19 <doublec> coblee: I just waited
296 2011-06-14 07:38:26 <coblee> doublec: ok thanks
297 2011-06-14 07:40:22 <lfm> Akinava: you understand ripem160() produces a 20 byte result right?
298 2011-06-14 07:40:50 <Akinava> lfm, yes
299 2011-06-14 07:41:14 <lfm> akin ok where are you getting lost? the base58 long arithmetic?
300 2011-06-14 07:41:41 <Akinava> example python hashlib.sha256(hashlib.sha256(('00').decode('hex')).hexdigest().decode('hex')).hexdigest()
301 2011-06-14 07:41:54 <Akinava> yps
302 2011-06-14 07:42:07 <lfm> I dont know python, thats not ripem160 tho
303 2011-06-14 07:42:13 <Akinava> wrong
304 2011-06-14 07:43:00 <gjs278> I swear every nick that comes in here that starts with an "A" is always a piece of crap
305 2011-06-14 07:43:24 <lfm> oh ya, I forgot the checksum, take that sha256(sha256(21byte value)) and use the first 4 bytes from the result
306 2011-06-14 07:43:27 <topi`> FellowTraveler: such code shouldn't be difficult to implement yourself, since you just need to do RPC calls to the locally running bitcoin client
307 2011-06-14 07:43:54 <lfm> as a checksum added on to the end of the 21 byte vector to make it 25 bytes then convert to base58
308 2011-06-14 07:44:20 <coblee> doublec: the transaction is there now. wonder why it took so long.
309 2011-06-14 07:44:25 <denisx> is there a reason why the hash in pushpoold is somehow backwards?
310 2011-06-14 07:44:37 <doublec> coblee: probably an error on the initial send
311 2011-06-14 07:44:45 <doublec> coblee: if you look in the debug.log you might see it
312 2011-06-14 07:44:46 <coblee> yeah, probably
313 2011-06-14 07:45:03 <topi`> denisx: the hash needs to be "reversed" for comparison purposes
314 2011-06-14 07:45:09 <topi`> this is just a LSB/MSB issue
315 2011-06-14 07:45:16 <doublec> coblee: it's stress inducing if there's someone waiting for the other end of the transaction :)
316 2011-06-14 07:45:22 <lfm> coblee: thats been happening a lot latly, not sure why. I think people are working on stuff that should help in the next version but who knows
317 2011-06-14 07:45:29 <corecode> oh god the bitcoin code is chaotic
318 2011-06-14 07:45:37 <topi`> corecode: welcome to the club :D
319 2011-06-14 07:45:52 <topi`> corecode: somehow C++ is a good language to encourage chaotic coding
320 2011-06-14 07:45:57 <coblee> doublec: yeah, luckily i was just sending chrome my checking to saving
321 2011-06-14 07:46:19 <coblee> i actually had to quit the app right after i sent. so maybe that's why
322 2011-06-14 07:46:33 <corecode> topi`: no, this is just bad coding
323 2011-06-14 07:46:36 <coblee> next time i won't quit until transaction is broadcasted
324 2011-06-14 07:46:40 <corecode> i mean, this code is far away from being portable
325 2011-06-14 07:47:07 <lfm> corecode: I think it was specificlly intended to be non portable
326 2011-06-14 07:47:11 <corecode> i bet it doesn't work for any LPI64 processors
327 2011-06-14 07:47:12 <topi`> corecode: exactly. especially with regard to endianness.
328 2011-06-14 07:47:49 <lfm> corecode: if lpi64 are big endian then ya, it would be very hard to port
329 2011-06-14 07:47:59 <topi`> lfm: what could such motivation be? only Intel or other LE vendors would benefit from such a decisin :)
330 2011-06-14 07:48:21 <samr7> I think he means sizeof(int) == 8
331 2011-06-14 07:49:09 <lfm> topi`: When Satoshi wrote it I dont think he wanted people to make competing implentations too soon, He wanted to just have the one authoritive implementation (for pcs). Im just guessing tho
332 2011-06-14 07:49:18 <corecode> yea, what's up with that byteswapping?
333 2011-06-14 07:50:12 <corecode> lfm: just looks like a) inexperienced programmer or b) ugly on purpose
334 2011-06-14 07:50:27 <lfm> ya I am thinking b)
335 2011-06-14 07:50:39 <corecode> what for?
336 2011-06-14 07:50:51 <corecode> that just means that people will rewrite it
337 2011-06-14 07:50:59 <corecode> i just had a look at the mining code
338 2011-06-14 07:51:00 <lfm> like I told Topi just now, to dicourage porters
339 2011-06-14 07:51:18 <corecode> why would you want to discourage porters?
340 2011-06-14 07:51:38 <corecode> also, ugly code is perfect to hide cryptographic (implementation) errors
341 2011-06-14 07:52:12 <lfm> corecode: well the mining code is a special reason it is so bad is cuz it has had the crap optimized out of it by every programmer who ever got interested in bitcoins
342 2011-06-14 07:53:01 <corecode> if my students wrote that code i wouldn't pass them
343 2011-06-14 07:53:15 <corecode> and there are memcpys all over the place
344 2011-06-14 07:53:25 <corecode> that can not possibly be optimized
345 2011-06-14 07:53:33 <lfm> corecode: ya well students are not spozed to optimize, they are spozed to make it easy for the markers to read
346 2011-06-14 07:53:45 <corecode> any programmer
347 2011-06-14 07:54:14 <lfm> well some programmer do optimize wheather they're spozed to or not
348 2011-06-14 07:54:34 <doublec> corecode: do you have a specific example of bad code?
349 2011-06-14 07:54:45 <gjs278> corecode are you an actual teacher or a hypothetical teacher
350 2011-06-14 07:54:53 <lfm> corecode: the reason is the mining code, faster makes more money for those who run it
351 2011-06-14 07:55:32 <corecode> gjs278: actual
352 2011-06-14 07:55:37 <gjs278> what school
353 2011-06-14 07:55:45 <corecode> not your business
354 2011-06-14 07:55:54 <gjs278> well
355 2011-06-14 07:55:56 <gjs278> level
356 2011-06-14 07:55:57 <gjs278> of teaching
357 2011-06-14 07:56:00 <lfm> the mining code was much worse a short time ago, it had asm bits all over
358 2011-06-14 07:56:02 <gjs278> not the actual school
359 2011-06-14 07:56:03 <corecode> university
360 2011-06-14 07:56:29 <corecode> doublec: just look at the BitcoinMiner() loop and the calls
361 2011-06-14 07:56:40 <corecode> especially FormatHashBlocks or so
362 2011-06-14 07:56:43 <corecode> i closed the file
363 2011-06-14 07:56:43 <doublec> corecode: what specifically about it do you deem bad
364 2011-06-14 07:56:49 <gjs278> I've seen the garbage college students write, you must fail a lot of your students if this is what you consider unpassable
365 2011-06-14 07:56:52 <doublec> it's easy to say "this is bad"
366 2011-06-14 07:57:04 <doublec> harder to say "this is bad because of X and should be done like Y"
367 2011-06-14 07:57:44 <lfm> gjs278: naw, no one ever seems to teach real code that does real stuff like bitcoin. its all toy problems
368 2011-06-14 07:57:52 <corecode> doublec: 0 portability, implicit reliance on the size of int, aliasing, cast to pointers and subsequent assumption of padded structures
369 2011-06-14 07:58:03 <doublec> corecode: show me an example
370 2011-06-14 07:58:05 <gjs278> shuffle this deck of cards and determine what hand will win in a game of war using arrays!
371 2011-06-14 07:58:08 <corecode> doublec: read it
372 2011-06-14 07:58:13 <corecode> doublec: voila example
373 2011-06-14 07:58:18 <doublec> corecode: yeah I didn't think you could
374 2011-06-14 07:58:27 <doublec> corecode: I guess you're right, you are a teacher
375 2011-06-14 07:59:07 <corecode> doublec: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3424
376 2011-06-14 07:59:07 <lfm> corecode: ya it assumes int is always 4 bytes cuz on a PC it will be 4 bytes no matter if you have a 32 bit OS or a 64 bit OS (os + compiler system).
377 2011-06-14 07:59:20 <topi`> once upon a time I ported the source of "doom" to alpha architecture. it was *very* time consuming since the code was casting pointers to integers all the time, and an alpha 6bit pointer would not fit into a 32bit int
378 2011-06-14 07:59:49 <lfm> 64 bit pointer
379 2011-06-14 08:00:12 <topi`> lfm: on my OSX system all pointers are 64 bits wide
380 2011-06-14 08:00:32 <corecode> doublec: tmp assumes int are 4 byte little endian, FormatHashBlocks assumes that pbuffer is back-padded with up to 64 bytes
381 2011-06-14 08:00:53 <corecode> lfm: only by convention
382 2011-06-14 08:01:20 <lfm> corecode: the 64 byte padding is part of the sha256 algorithm actually
383 2011-06-14 08:01:42 <corecode> lfm: yes, but the way FormatHashBlocks is called
384 2011-06-14 08:01:49 <corecode> lfm: it lumps together the data and the padding
385 2011-06-14 08:02:01 <doublec> corecode: so now's a good time to fix it the way you think it should be fixed and do a pull request
386 2011-06-14 08:02:02 <lfm> corecode: ya convention on PCs is default int is 32 bits even on 64 bit systems
387 2011-06-14 08:02:09 <corecode> doublec: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3184
388 2011-06-14 08:02:15 <corecode> doublec: why +12?
389 2011-06-14 08:02:39 <lfm> which version of bitcoin is it?
390 2011-06-14 08:02:40 <corecode> lfm: yes, because they didn't dare making it LPI64 :)
391 2011-06-14 08:02:44 <gjs278> int + 12
392 2011-06-14 08:03:00 <lfm> what the heck is a lpi64 anyway?
393 2011-06-14 08:03:14 <corecode> lfm: long, pointer, int = 64 bits
394 2011-06-14 08:03:20 <corecode> vs LP64 for PCs
395 2011-06-14 08:03:29 <corecode> well, linux,windows,osx
396 2011-06-14 08:03:31 <lfm> you want a long int use a long it
397 2011-06-14 08:03:51 <corecode> there are other architectures where int and long int are 64bit
398 2011-06-14 08:04:05 <lfm> and ya, no one uses default ints of 64 bits
399 2011-06-14 08:04:15 <lfm> on PCs
400 2011-06-14 08:04:35 <corecode> ah, most call it ilp64
401 2011-06-14 08:04:50 <lfm> never heard of either actually
402 2011-06-14 08:05:21 <corecode> oh hey
403 2011-06-14 08:05:27 <corecode> windows does llp64
404 2011-06-14 08:05:35 <corecode> where a long int is also 32 bits
405 2011-06-14 08:05:53 <corecode> and a long long is 64
406 2011-06-14 08:05:58 <lfm> oh ya on windows 32
407 2011-06-14 08:05:59 <corecode> seems on 64
408 2011-06-14 08:06:00 <lfm> same as linux 32
409 2011-06-14 08:06:01 <corecode> https://secure.wikimedia.org/wikipedia/en/wiki/LP64#Specific_C-language_data_models
410 2011-06-14 08:06:58 <lfm> ok well maybe with a switch on ms compilers or something. bitcoin I think uses mingw compiler
411 2011-06-14 08:07:32 <d1234> ;;bc,stats
412 2011-06-14 08:12:15 <lfm> corecode: if you look at bitcoin, you should find it doesnt use long much. it uses int for 32 and "long long" for 64 bits to work on both 32 bit and 74 bit linux and mswin system
413 2011-06-14 08:12:30 <lfm> 74 -> 64
414 2011-06-14 08:12:42 <directhex> all the best computers are 74-bit
415 2011-06-14 08:14:53 <gjs278> 74 bit so you have a bit buffer on your 64bits
416 2011-06-14 08:15:00 <lfm> directhex: I used to work on a 36 bit system (univac 1100 seies)
417 2011-06-14 08:15:29 <directhex> lfm, and the precursor to ibm's zseries were 31-bit. at least the VMs were.
418 2011-06-14 08:15:44 <lfm> I sudder to think what C would be like on it
419 2011-06-14 08:16:13 <lfm> shudder
420 2011-06-14 08:16:26 <lfm> directhex: zseries? you sure?
421 2011-06-14 08:16:31 <directhex> lfm, the old s/390
422 2011-06-14 08:16:58 <lfm> lfm ya, the s/390 was from the s/370 and s/360 and they were all 32 bits
423 2011-06-14 08:17:18 <directhex> 32ish!
424 2011-06-14 08:17:23 <topi`> lfm: I shudder to remember working in BCPL on the Amiga (the dos.library was written in BCPL)
425 2011-06-14 08:17:35 <topi`> BCPL pointers were, um, a joy!
426 2011-06-14 08:17:51 <lfm> it might be certain models of hardware were limited to 31 bit addresses or something but internally the software was all 32 bit
427 2011-06-14 08:17:51 <vegard> electrologica x1 from 1958 had 27 bits :D
428 2011-06-14 08:18:15 <directhex> lfm, address space limited to 31-bit. the 32nd was used as a flag for 24-bit support.
429 2011-06-14 08:18:58 <lfm> ya some of the addresses were 24 bit but it is generally considered a 32 bit architecture
430 2011-06-14 08:19:45 <directhex> average it out as 28-bit, that's the best plan
431 2011-06-14 08:21:00 <lfm> best for who! hehe. plain 32 bit would be better for most things, all those 24 bit and 31 bit addresses would be for backward compatibility with the dark ages
432 2011-06-14 08:24:28 <Gxxxx> ;;bc,timetonext
433 2011-06-14 08:25:08 <Diablo-D3> bots dead
434 2011-06-14 08:25:24 <Gxxxx> damn
435 2011-06-14 08:26:51 <lfm> est next difficulty: 842056.51, in 1.80 days
436 2011-06-14 08:27:22 <gjs278> doesn't scare me
437 2011-06-14 08:27:33 <JFK911> ;;bc,gen 800000
438 2011-06-14 08:27:42 <gjs278> bots dead
439 2011-06-14 08:27:42 <JFK911> im scared
440 2011-06-14 08:27:46 <JFK911> dangit
441 2011-06-14 08:27:48 <gjs278> thats how scared the bot is
442 2011-06-14 08:27:56 <JFK911> that bot's right
443 2011-06-14 08:27:59 <JFK911> imho
444 2011-06-14 08:29:54 <lfm> difficulty could be 1 million in 2 weeks
445 2011-06-14 08:30:05 <kish> what is it now
446 2011-06-14 08:30:09 <gjs278> my processor cant handle that many bits
447 2011-06-14 08:31:03 <lfm> est next difficulty: 842056.51, in 1.80 days
448 2011-06-14 08:31:10 <lfm> est next difficulty: 842056.51, in 1.80 days
449 2011-06-14 08:31:21 <lfm> bah, cat copy and paste it right
450 2011-06-14 08:31:23 <kish> but i havent even begun mining opertilns
451 2011-06-14 08:31:34 <kish> i my be too late
452 2011-06-14 08:31:47 <lfm> curr diff =567269.5302
453 2011-06-14 08:33:21 <kish> i'm arranging a solar storm that will destroy your miners with an emp blast
454 2011-06-14 08:33:26 <eureka^> oh no
455 2011-06-14 08:33:43 <lfm> kish ok, I give up, you got me
456 2011-06-14 08:34:19 <topi`> that's a crazy difficulty
457 2011-06-14 08:34:24 <topi`> will turn off my miners :(
458 2011-06-14 08:34:47 <Wuked> it should increase the price of a coin even more ? :o
459 2011-06-14 08:34:50 <kish> what will difficulty be in 12 months time
460 2011-06-14 08:35:01 <lfm> kish 3.00
461 2011-06-14 08:35:08 <lfm> after the crash
462 2011-06-14 08:35:29 <kish> without crash
463 2011-06-14 08:35:58 <lfm> its unavoidable. ever since that emp took out most of the miners
464 2011-06-14 08:38:30 <cosurgi> ;;bc,stats
465 2011-06-14 08:49:24 <lfm> Average interval since last diff change: 6.71 min
466 2011-06-14 08:50:25 <lfm> est next difficulty: 845466.14, in 1.46 days
467 2011-06-14 08:53:25 <hybriz_> http://bitcoin.bluematt.me/bitcoin-nightly/win32-i686-patched/ -> what features does this patched version has over normal bitcoin ?
468 2011-06-14 08:55:10 <gjs278> well
469 2011-06-14 08:55:17 <gjs278> it has several useful features
470 2011-06-14 08:55:22 <gjs278> but only BlueMatt knows what those are
471 2011-06-14 08:55:53 <gjs278> note that they're pretty old
472 2011-06-14 08:55:58 <gjs278> so I doubt they're anything special
473 2011-06-14 08:56:41 <hybriz_> k
474 2011-06-14 08:56:47 <hybriz_> 10x
475 2011-06-14 08:57:00 <denisx> when I solomine and I find a block, I can only spend it after 120 confirmations?
476 2011-06-14 08:57:16 <lfm> denisx: ya
477 2011-06-14 09:07:25 <iera> is minfee already 0.0005 in 0.3.23?
478 2011-06-14 09:09:20 <iera> ah it seems so
479 2011-06-14 09:15:11 <Joric> oh it was released, sweet
480 2011-06-14 09:15:41 <Joric> yes, i've used it for a while
481 2011-06-14 09:26:44 <sneak> hi guys
482 2011-06-14 09:27:36 <lfm> Hi
483 2011-06-14 09:28:50 <sneak> what happened to the python bitcoin client?
484 2011-06-14 09:28:53 <sneak> is that still around?
485 2011-06-14 09:31:42 <lfm> sneak: I dont think it is compleat yet
486 2011-06-14 09:32:41 <lfm> sneak:  the java one is closer
487 2011-06-14 09:32:50 <sneak> yeah but java is way yuckier than python
488 2011-06-14 09:33:02 <lfm> not so loud!
489 2011-06-14 09:33:17 <sneak> oh god the python bitcoin client guy reimplemented the irc bootstrapping that the mainline client does
490 2011-06-14 09:33:24 <sneak> why on earth would he do that
491 2011-06-14 09:33:35 <sneak> there are at least a dozen stable seed nodes for peer exchange now
492 2011-06-14 09:34:32 <lfm> you dont have to use irc with the mainline client if you dont want it
493 2011-06-14 09:52:10 <sipa> jgarzik: betterheaders seems to break build
494 2011-06-14 09:52:36 <sipa> ui.h and noui.h need an #include <boost/function.hpp>
495 2011-06-14 09:56:23 <sipa> roconnor: are your questions in #haskell related to your bitcoin implementation?
496 2011-06-14 09:56:32 <roconnor> yes
497 2011-06-14 09:56:53 <sipa> nice :)
498 2011-06-14 10:00:17 <roconnor> sipa: I'm keeping a map of all outstanding coins at the end of every block.
499 2011-06-14 10:00:35 <roconnor> sipa: but it is hard for me to judge how much memory this should be using.
500 2011-06-14 10:01:04 <roconnor> sipa: at first it seems like a huge number of maps; however some fraction of those maps will be shared between each other.
501 2011-06-14 10:01:10 <roconnor> sipa: I hoping that fraction is big.
502 2011-06-14 10:01:41 <sipa> you keep the entire set of unredeemed coins in memory?
503 2011-06-14 10:03:17 <roconnor> not only that the set of unredeemed coins at the end of every block in memory.
504 2011-06-14 10:03:40 <sipa> i think just the set of unredeemed coins is unreasonable
505 2011-06-14 10:04:00 <roconnor> if there is a fork you need to go back.
506 2011-06-14 10:04:02 <sipa> probably still possible right now
507 2011-06-14 10:05:35 <lfm> besides coinbase txn - Total number of transactions: 597685
508 2011-06-14 10:06:44 <sipa> the c++ implementation just keeps all transactions, and marks things spent or unspent in the currently active best chain
509 2011-06-14 10:07:00 <roconnor> lfm: should be 130733 coinbase txs
510 2011-06-14 10:07:08 <lfm> yup
511 2011-06-14 10:07:20 <roconnor> sipa: and when there is a fork in the chain?
512 2011-06-14 10:07:40 <sipa> and when doing a reorganisations, rewinds back to the branching point (marking things unspent again), and then applies the new branch (marking things there spent)
513 2011-06-14 10:07:44 <sipa> *reorganisation
514 2011-06-14 10:08:08 <lfm> roconnor: ya you should undo the txn in a reorg
515 2011-06-14 10:08:11 <roconnor> sipa: I'm not storing the blocks
516 2011-06-14 10:08:11 <sipa> entirely on disk, this information is not kept in memory
517 2011-06-14 10:08:33 <roconnor> why would I use a disk when I have virtual memory?
518 2011-06-14 10:08:34 <roconnor> :D
519 2011-06-14 10:08:56 <lfm> mmap the disk and then its both
520 2011-06-14 10:09:17 <cosurgi> ;;bc,stats
521 2011-06-14 10:09:19 <sipa> it should be possible, certainly
522 2011-06-14 10:09:24 <diki> was wondering, if a lower than 1 diff is used in a pool, would it still have the same chance to beat the current diff?
523 2011-06-14 10:09:28 <sipa> currently, in memory
524 2011-06-14 10:09:34 <lfm> est next difficulty: 844111.53, in 1.46 days
525 2011-06-14 10:09:44 <cosurgi> who maintains gribble?
526 2011-06-14 10:09:50 <sipa> nanotube
527 2011-06-14 10:09:55 <cosurgi> nanotube: help :)
528 2011-06-14 10:10:09 <roconnor> sipa: the total footprint (memory + disk) seems about the to me either way.
529 2011-06-14 10:10:13 <lfm> cosurgi: what info you looking for?
530 2011-06-14 10:10:22 <cosurgi> when i snew difficulty
531 2011-06-14 10:10:27 <lfm> est next difficulty: 844111.53, in 1.46 days
532 2011-06-14 10:10:33 <cosurgi> thx
533 2011-06-14 10:10:44 <lfm> roughly
534 2011-06-14 10:10:45 <sipa> ;;bc,estimate
535 2011-06-14 10:11:09 <lfm> sipa est next difficulty: 844111.53, in 1.46 days
536 2011-06-14 10:11:22 <sipa> roconnor: yes, but you don't need that set for every block, i think
537 2011-06-14 10:11:54 <sipa> without using ST or IO, you don't have much choice though
538 2011-06-14 10:11:58 <roconnor> any block is a potential fork just waiting to happen. :D
539 2011-06-14 10:12:11 <lfm> roconnor: yup
540 2011-06-14 10:12:15 <roconnor> anyhow, first make the code simple, then make it fast.
541 2011-06-14 10:12:51 <roconnor> I could do all sorts of things like having a queue of 100 block and deleting things after that and reconstructing them if I need to.
542 2011-06-14 10:12:57 <roconnor> but simple first :D
543 2011-06-14 10:13:24 <nanotube> sipa: cosurgi: thanks... gribz is back now. :)
544 2011-06-14 10:13:25 <sipa> oh you should be prepared to go back to reorganize, definitely
545 2011-06-14 10:13:50 <roconnor> sipa: so they way I have it now is that the "chain" is kept in a priority search queue
546 2011-06-14 10:14:01 <roconnor> the block with the most work has the highest priority
547 2011-06-14 10:14:11 <roconnor> and you just dump blocks into the PSQ
548 2011-06-14 10:14:19 <lfm> roconnor: since the whole block chain is still just 259423000 bytes, it should be no problem keeping it in memory
549 2011-06-14 10:14:22 <sipa> that's very clean
550 2011-06-14 10:14:27 <sipa> roconnor: nice
551 2011-06-14 10:14:29 <roconnor> and if one day a new block somehow has a higher priority, it magically jumps to the top.
552 2011-06-14 10:14:41 <roconnor> lfm: that's what I figure.
553 2011-06-14 10:15:18 <roconnor> lfm: over in #haskell I'm having trouble with my fixed heap of 512MB being exhasted; I'm trying to figure out why.
554 2011-06-14 10:15:29 <roconnor> the heap profiling numbers are all much smaller than 512MB
555 2011-06-14 10:15:56 <lfm> overhead
556 2011-06-14 10:16:00 <lfm> fragmentation
557 2011-06-14 10:16:11 <roconnor> sure, but I'm dying in april-2010; haven't even gotten to the big stuff lately
558 2011-06-14 10:16:45 <sipa> i wonder if you can't replace it with a specialized impure (but observably pure) data structure that only stored spentness of the highest-priority chain, and calculates all other things by rewinding to a branchpoint and back
559 2011-06-14 10:17:04 <diki> sipa, what is the most lowest possible difficulty ?
560 2011-06-14 10:17:09 <roconnor> in my latest test run I ran the GC after every block; only 8 MB lost to fragmentation reported.
561 2011-06-14 10:17:25 <lfm> sipa definatly the way to go
562 2011-06-14 10:17:27 <roconnor> sipa: ya, something like how diffArray works
563 2011-06-14 10:17:34 <lfm> diki: 1/2^32
564 2011-06-14 10:17:34 <sipa> roconnor: yes, but then for a tree instead of an array :)
565 2011-06-14 10:17:40 <roconnor> yep.
566 2011-06-14 10:17:59 <roconnor> In principle it is possible; since diffArray is possible.
567 2011-06-14 10:18:05 <lfm> diki that would make EVERY hash a winner
568 2011-06-14 10:18:44 <sipa> roconnor: i think it would be nice if there was a verify-only haskell implementation that could be considered the reference ("if this program validates the transactions/blocks you create, it's valid bitcoin")
569 2011-06-14 10:18:45 <roconnor> lfm: such low difficulties are not allowed by the protocol.
570 2011-06-14 10:18:56 <roconnor> sipa: that's what I'm trying to build :D
571 2011-06-14 10:18:59 <sipa> nice
572 2011-06-14 10:19:11 <roconnor> sipa: but still functional enough to run resaonably okay on the real chain
573 2011-06-14 10:19:40 <gmaxwell> That would be great... it could be a good alarm system.
574 2011-06-14 10:20:02 <gmaxwell> (to have an implementation that wasn't even in any use except as a reference)
575 2011-06-14 10:20:04 <roconnor> gmaxwell: right now my client is probably buggier that the standard client :D
576 2011-06-14 10:20:11 <gmaxwell> Sure sure.
577 2011-06-14 10:20:33 <lfm> diki: about 2.328E-10
578 2011-06-14 10:20:35 <roconnor> but it is getting there.
579 2011-06-14 10:20:43 <gmaxwell> Bitcoin needs moar diversity.
580 2011-06-14 10:21:05 <roconnor> I want to turn this into a literate Haskell program that is an English specification with Haskell code as well.
581 2011-06-14 10:21:45 <lfm> roconnor: I think the protocol would allow it, there may be policies in the code to stop it getting that low. like for the main block chain it is 1.00 and for testnet it is 0.0625 or something
582 2011-06-14 10:21:48 <diki> so diff 2,32?
583 2011-06-14 10:22:17 <lfm> diki no. 0.00000000023283
584 2011-06-14 10:22:35 <roconnor> testnet is 0.125
585 2011-06-14 10:23:10 <lfm> roconnor: ya that is just various policies for various block chains, the protocol would allow 1/(2^32)
586 2011-06-14 10:23:16 <roconnor> lfm: verifiying that the target doesn't drop below the minimum target for the chain is part of the protocol.
587 2011-06-14 10:24:18 <lfm> roconnor: I call it a policy, the protocol is the format of the stuff on the net that is exchanged by nodes. it is easy to change policies but hard to change the protocol
588 2011-06-14 10:24:52 <roconnor> In GetNextWorkRequired it does:
589 2011-06-14 10:24:55 <sipa> i call it a policy as soon as a client can implement it without causing a block chain split
590 2011-06-14 10:25:01 <roconnor> if (bnNew > bnProofOfWorkLimit)
591 2011-06-14 10:25:02 <roconnor> bnNew = bnProofOfWorkLimit;
592 2011-06-14 10:25:18 <sipa> if you change the proof of work limit, you have a chance for introducing a split
593 2011-06-14 10:25:24 <roconnor> GetNextWorkRequired is part of the protocol I argue.
594 2011-06-14 10:25:30 <lfm> roconnor: ya, fine, it looks easy to change to me
595 2011-06-14 10:25:44 <sipa> sure it is easy
596 2011-06-14 10:25:48 <sipa> but not correct
597 2011-06-14 10:26:17 <lfm> if I wanted to make another block chain of  my own like the main net or the testnet, I could easily change that policy
598 2011-06-14 10:26:20 <roconnor> lfm: That's true, but it would be a different protocol, one that might happen to be compatible with the chain built so far, but a different protocol.
599 2011-06-14 10:26:32 <lfm> but I would still be using the same protocol
600 2011-06-14 10:26:48 <roconnor> I guess it depends on exactly what we mean by "protocol"
601 2011-06-14 10:26:56 <sipa> introducing a new script opcode, would that be changing the protocol for you, lfm?
602 2011-06-14 10:27:01 <gmaxwell> We had a stupid debate over this in #bitcoin a day ago.
603 2011-06-14 10:27:34 <roconnor> In my use, testnet and mainnet are running different protocols
604 2011-06-14 10:27:39 <lfm> like I said the protocol is the format of the data on the net, that is exchanged by nodes. it is polies that restrict what data is put into those formats
605 2011-06-14 10:27:43 <gmaxwell> I think we decided that the blockchain rules were not protocol they were "algorithm" because they must be followed the same exactly by everyone.
606 2011-06-14 10:27:45 <roconnor> but I can see why someone would claim they are running the same protocol
607 2011-06-14 10:27:54 <roconnor> gmaxwell: ah okay
608 2011-06-14 10:27:55 <gmaxwell> (wherease you can gateway from protcol to protocol)
609 2011-06-14 10:28:04 <roconnor> I'm happy to use whatever termonology is most clear.
610 2011-06-14 10:28:29 <gmaxwell> well thats what #bitcoin (or at least me and one other person) agreed on. So take that for whatever its worth.
611 2011-06-14 10:28:33 <roconnor> clearly the wiki page on protocol_rules should be retitled :D
612 2011-06-14 10:28:52 <roconnor> anyhow
613 2011-06-14 10:29:22 <gmaxwell> It's very likely that there will be multiple network protocols for the single blockchain in the future in any case.. ::shrugs:: (actually depending on how you count things, there already are)
614 2011-06-14 10:29:29 <lfm> or just have the wiki state what definition of "protocol" it is using
615 2011-06-14 10:30:12 <gmaxwell> The debate in bitcoin arose because of confusion about what couldn't change without chainging all of bitcoin vs what two nodes can agree to do on their own.
616 2011-06-14 10:30:23 <sipa> well maybe the wiki is good - there can be multiple data format level protocols that still have the same rules about the data they can legally encode
617 2011-06-14 10:30:26 <sipa> hence protocol rules :)
618 2011-06-14 10:30:27 <gmaxwell> And things like relay flooding policy vs blockchain rules.
619 2011-06-14 10:32:45 <roconnor> gmaxwell: it is an important disinction
620 2011-06-14 10:33:24 <roconnor> the minWork isn part of the block chain rules, not like a retransmission policy for peers.
621 2011-06-14 10:33:28 <lfm> and the fact that testnet and main net use different limits but I would say use the same protocol means to me that the limit is not part of the protocol
622 2011-06-14 10:34:09 <gmaxwell> I'd normally say that e.g. the blockchain rules are clearly distinct from "protocol" becaus protocol is what cares about things like byte ordering and structure padding... except for the fact that the blockchain does care about these things due to the hashes.
623 2011-06-14 10:34:38 <roconnor> BTW, the fact that testnet has a different limit is kinda annoying :D
624 2011-06-14 10:34:59 <sipa> so, let's call it 1. rules (what the semantic data can be to be called bitcoin), 2. protocol (the current p2p transport layer) and 3. policies (relay policy, fee policy, block incusion policy) which may be needed to good usability of the system, but can be changed without breaking things
625 2011-06-14 10:35:11 <lfm> roconnor: I agree with that actually, and its not needed
626 2011-06-14 10:35:30 <gmaxwell> I wish the testnet had a low _maximum_ difficulty. It's annoying to test things where you have to mine in the testnet.
627 2011-06-14 10:36:19 <lfm> sipa ok you and gmaxwell seem to agree that policies are flexable from node to node where "rules" need to be the same for the whole net
628 2011-06-14 10:36:35 <gmaxwell> sipa: that sounds agreeable to me.
629 2011-06-14 10:37:17 <gmaxwell> Yea, rules are "that which fork the network when you disagree" pretty much. Any change in rules and you'll eventually have parallel blockchains.
630 2011-06-14 10:37:18 <sipa> and 1. and 2. are indeed closely linked, as roconnor notes, through the hashing functions
631 2011-06-14 10:38:04 <roconnor> the minWork is not part of the transport layer, which is why I wasn't calling it the protocol. :D
632 2011-06-14 10:38:08 <gmaxwell> Though they don't have to be. You could have transport which is entirely different then converts back to the canonical form. Dunno why (paranoid security?) but you could.
633 2011-06-14 10:38:37 <roconnor> gmaxwell: exactly
634 2011-06-14 10:39:06 <lfm> like you could specifiy that the minWork value exists within the protocol but not specify its value
635 2011-06-14 10:39:28 <CIA-90> bitcoinj: hearn@google.com * r92 /trunk/src/com/google/bitcoin/core/Wallet.java: Fix an assertion in Wallet to use the correct type.
636 2011-06-14 10:39:57 <lfm> the value would be part of the spcifications for each net
637 2011-06-14 10:40:13 <lfm> rules if you will
638 2011-06-14 10:40:14 <roconnor> indeed
639 2011-06-14 10:40:35 <sipa> ah yes, the protocol could be common for all networks, while the rules can differ
640 2011-06-14 10:41:59 <lfm> so you also have rules for the address prefix (00 for main net and 111 for testnet)
641 2011-06-14 10:42:47 <gmaxwell> the above definitions have nice scoping too:  Rules must be common to everyone, Protocol must be common between two communcating nodes, policy can be node-specific.
642 2011-06-14 10:43:10 <gmaxwell> (everyone in a single hash-chain universe, at least!)
643 2011-06-14 10:44:27 <lfm> protocol is common beyond "communicating nodes" to other nets using the bitcoin protocl. if you change it you should change the name of it too I think
644 2011-06-14 10:44:55 <sipa> moreover, protocol is independent from which block chain you are using
645 2011-06-14 10:45:58 <lfm> the rules could be implemented in a config file even I think
646 2011-06-14 10:46:55 <lfm> or if you think that is too flexable, a header file
647 2011-06-14 10:47:16 <gmaxwell> or a cpp file that overlays varrious objects...
648 2011-06-14 10:47:21 <gmaxwell> and you could call it namecoin.
649 2011-06-14 10:47:23 <gmaxwell> ;)
650 2011-06-14 10:47:31 <diki> ;;bc,calcd 400000 1333
651 2011-06-14 10:47:32 <gribble> The average time to generate a block at 400000 Khps, given the supplied difficulty of 1333, is 3 hours, 58 minutes, and 32 seconds
652 2011-06-14 10:47:48 <lfm> welcome back gribble
653 2011-06-14 10:49:35 <CIA-90> bitcoinj: hearn@google.com * r93 /trunk/src/com/google/bitcoin/examples/PingService.java: Improve the documentation for the PingService. Patch by Gary Rowe.
654 2011-06-14 10:50:38 <CIA-90> bitcoinj: hearn@google.com * r94 /trunk/src/com/google/bitcoin/examples/PingService.java: Mention testnet in a box in the PingService docs.
655 2011-06-14 10:51:31 <gmaxwell> hahah someone actually mined against an address I've used in IRC for example eligius URLs and I just got a generate txn payment of 0.00003585 BTC.
656 2011-06-14 10:52:12 <lfm> you're rich!
657 2011-06-14 10:55:52 <TommyBoy3G> sipa update bitcoin.org
658 2011-06-14 10:56:26 <TommyBoy3G> and please inclute changelog for users what's in new version
659 2011-06-14 11:01:46 <lfm> who made the new bitcoin tar.gz for linux?
660 2011-06-14 11:02:12 <CIA-90> bitcoinj: hearn@google.com * r95 /trunk/ (2 files in 2 dirs): Add a SeedPeers class that contains a pre-compiled list of IP addresses taking part in the Bitcoin network for a long period of time, for use if IRC and DNS are unavailable. Based on a patch by Micheal Swiggs.
661 2011-06-14 11:03:01 <sipa> TommyBoy3G: i don't have access to the homepage
662 2011-06-14 11:05:31 <topi`> haha. I tried mining on a 3ghz Pentium4. the C algo gives 106 khash/s :) :)
663 2011-06-14 11:07:43 <lfm> sipa do you know who made the new 0.3.23-linux.tar.gz file? they did not put in a base directory, just tared up "." current dir it seems so it extracts all over your current dir instead of making a nice new dir
664 2011-06-14 11:08:07 <sipa> lfm: that could be my fault - i built it and sent it to jgarzik
665 2011-06-14 11:09:30 <lfm> sipa ok, dont be too surprized if you get some hate mail over it! grin. it didnt bather me too much but I did notice
666 2011-06-14 11:11:06 <lfm> ohoh , the version in the help menu (linux gui version still sez it is BETA too
667 2011-06-14 11:11:48 <sipa> it is
668 2011-06-14 11:12:17 <ArtForz> iirc it always did
669 2011-06-14 11:12:21 <lfm> oh, I thot it was a full release
670 2011-06-14 11:12:40 <sipa> all versions up to 1.0 will be called beta, i assume
671 2011-06-14 11:12:48 <ArtForz> yup, makes sense
672 2011-06-14 11:13:05 <sipa> or we could go google-style and call it beta forever
673 2011-06-14 11:13:09 <lfm> oh ok ya, makes sense
674 2011-06-14 11:13:13 <sipa> beta - it's the new stable!
675 2011-06-14 11:13:19 <ArtForz> yep
676 2011-06-14 11:13:34 <ArtForz> but well, current mainline sure as hell aint 1.0 material
677 2011-06-14 11:13:42 <lfm> so like version 1.0 is the last version
678 2011-06-14 11:14:09 <lfm> ever
679 2011-06-14 11:14:30 <sipa> or we could go latex-style and converge to some irrational number :)
680 2011-06-14 11:15:33 <lfm> what is some nice irrational number < 1.0
681 2011-06-14 11:15:49 <lfm> just 1/e
682 2011-06-14 11:16:28 <lfm> .36787944117144232159
683 2011-06-14 11:16:34 <sipa> ;;calc 1/e
684 2011-06-14 11:16:36 <gribble> 1 / e = 0.367879441
685 2011-06-14 11:16:59 <d1234> ;;bc,stats
686 2011-06-14 11:17:01 <gribble> Current Blocks: 130752 | Current Difficulty: 567358.22457067 | Next Difficulty At Block: 131039 | Next Difficulty In: 287 blocks | Next Difficulty In About: 1 day, 5 hours, 25 minutes, and 3 seconds | Next Difficulty Estimate: 847754.23151239
687 2011-06-14 11:17:49 <lfm> equivalent of
688 2011-06-14 11:17:59 <lfm> ;;calc e(-1)
689 2011-06-14 11:18:04 <gribble> e * (-1) = -2.71828183
690 2011-06-14 11:18:14 <lfm> ;;calc exp(-1)
691 2011-06-14 11:18:16 <gribble> exp(-1) = 0.367879441
692 2011-06-14 11:23:09 <roconnor> (produced as an output from a transaction, not from coinbase)
693 2011-06-14 11:23:21 <jrmithdobbs> roconnor: almost never
694 2011-06-14 11:23:30 <roconnor> I guess so
695 2011-06-14 11:23:46 <jrmithdobbs> roconnor: old old client let you do it though so it is a possibility
696 2011-06-14 11:24:44 <jrmithdobbs> roconnor: https://en.bitcoin.it/wiki/Incidents see first section
697 2011-06-14 11:24:47 <sipa> clients now allow it too
698 2011-06-14 11:24:51 <sipa> just do a spend to self
699 2011-06-14 11:24:56 <sipa> and then another transaction
700 2011-06-14 11:25:03 <roconnor> oh
701 2011-06-14 11:25:09 <sipa> with not enough other coins available
702 2011-06-14 11:25:16 <roconnor> then they might be a little more common than I thought
703 2011-06-14 11:38:36 <jrmithdobbs> sipa: did you change the magic version numbers in your showwallet tree?
704 2011-06-14 11:38:59 <sipa> those haven't changed since the first dumpprivkey patch
705 2011-06-14 11:39:35 <jrmithdobbs> ok and the format is: <version><privkey bigendian><checksum prev portion of string> yes?
706 2011-06-14 11:39:48 <jrmithdobbs> "string"
707 2011-06-14 11:40:52 <jrmithdobbs> i ask cause my results are not ending up with a 5 at the front after being base58 encoded but my base58 encoding is def working
708 2011-06-14 11:41:16 <CIA-90> bitcoinj: hearn@google.com * r96 /trunk/src/com/google/bitcoin/core/Wallet.java: Add more info to the Wallet.toString() output.
709 2011-06-14 11:41:18 <jrmithdobbs> (same data on bitcointools/bitcoinj's base58 produce same output)
710 2011-06-14 11:42:44 <CIA-90> bitcoinj: hearn@google.com * r97 /trunk/src/com/google/bitcoin/examples/RefreshWallet.java: Add a program that just loads a wallet, runs through the block chain, and then saves/prints out the resulting wallet at the end.
711 2011-06-14 11:58:58 <CIA-90> bitcoinj: hearn@google.com * r98 /trunk/AUTHORS: Refresh AUTHORS file.
712 2011-06-14 12:07:22 <sipa> ;;bc,blocks
713 2011-06-14 12:07:23 <gribble> 130759
714 2011-06-14 12:23:27 <diki> ;;bc,stats
715 2011-06-14 12:23:29 <gribble> Current Blocks: 130765 | Current Difficulty: 567358.22457067 | Next Difficulty At Block: 131039 | Next Difficulty In: 274 blocks | Next Difficulty In About: 1 day, 4 hours, 9 minutes, and 40 seconds | Next Difficulty Estimate: 849476.82996476
716 2011-06-14 12:23:51 <diki> ;;bc,calc 660000
717 2011-06-14 12:23:52 <gribble> The average time to generate a block at 660000 Khps, given current difficulty of 567358.22457067 , is 6 weeks, 0 days, 17 hours, 34 minutes, and 58 seconds
718 2011-06-14 12:24:02 <diki> ;;bc,gen 660000
719 2011-06-14 12:24:03 <gribble> The expected generation output, at 660000 Khps, given current difficulty of 567358.22457067 , is 1.17006628694 BTC per day and 0.0487527619556 BTC per hour.
720 2011-06-14 12:24:21 <diki> ;;bc,gend 660000 849476.82996476
721 2011-06-14 12:24:21 <gribble> The expected generation output, at 660000 Khps, given the supplied difficulty of 849476.82996476, is 0.781477148957 BTC per day and 0.0325615478732 BTC per hour.
722 2011-06-14 12:25:39 <Wuked> When did this forum limit come into force ?
723 2011-06-14 12:25:46 <Wuked> I was happily posting a few  days ago
724 2011-06-14 12:25:56 <Wuked> now I'm stuck in the n00b section :)
725 2011-06-14 12:26:18 <gribble> The expected generation output, at 480000 Khps, given the supplied difficulty of 849476.82996476, is 0.568347017423 BTC per day and 0.023681125726 BTC per hour.
726 2011-06-14 12:26:18 <JunK-Y> ;;bc,gend 480000 849476.82996476
727 2011-06-14 12:27:33 <Anon176> hello
728 2011-06-14 12:28:26 <Anon176> i would like to talk about the issues of deflation and hoarding
729 2011-06-14 12:29:22 <Anon176> i think i have a solution although unfortunately i think bitcoin would not be able to or want to use it and a new currency would have to be created
730 2011-06-14 12:30:03 <CIA-90> bitcoin: Daniel Folkinshteyn * r6afe6d2dd4df supybot-bitcoin-marketmonitor/Market/plugin.py: Market: update mtgox urls to https, since http stopped working... http://tinyurl.com/44ktz5e
731 2011-06-14 12:30:27 <Anon176> as we know, there are only a limited amount of bitcoins, and that is not necessarily the problem.
732 2011-06-14 12:31:18 <sanity> anyone have any idea why my script would suddenly be getting a HTML page in response to http://mtgox.com/code/data/getDepth.php since today, yet when I visit the same URL in my browser I get the JSON object as before?
733 2011-06-14 12:31:38 <Anon176> but, some people have argued that because deflation with bitcoin is predicted, it won't be a problem.
734 2011-06-14 12:33:06 <Anon176> but, they are wrong, because as it is we cannot predict the rate of deflation, we only know there will be deflation.
735 2011-06-14 12:33:43 <Anon176> which then becomes as much of a problem as unpredictable inflation.
736 2011-06-14 12:34:27 <Anon176> and the reason of unpredictability is this: bitcoins are immortal.
737 2011-06-14 12:35:13 <Anon176> if people lose their wallets, the money never goes back into the system, so the value of bitcoins increases, and that is unpredictable.
738 2011-06-14 12:35:58 <Anon176> bitcoins become more and more scarce. which also means the early adopters are disproportionally rich.
739 2011-06-14 12:36:30 <md2k7> sanity: HTTP headers, especially user-agent or a cookie
740 2011-06-14 12:37:09 <Anon176> and all of this encourages hoarding, as opposed to actual use as a currency.
741 2011-06-14 12:37:11 <sanity> md2k7: what, its discriminating against particular user agents?
742 2011-06-14 12:38:01 <md2k7> sanity: that's just what comes to my mind, given that both accesses were from the same machine.
743 2011-06-14 12:38:24 <Anon176> so here is my suggestion for technical developers: define a decomposing rate for bitcoins.
744 2011-06-14 12:38:25 <md2k7> sanity: ah, or browser cache.
745 2011-06-14 12:38:48 <SomeoneWeird> Guys, just released BitMiner Beta 4!
746 2011-06-14 12:38:57 <SomeoneWeird> http://forum.bitcoin.org/index.php?topic=12135.0
747 2011-06-14 12:39:00 <sipa> Anon176: what is a composing rate?
748 2011-06-14 12:39:06 <sipa> *decomposing?
749 2011-06-14 12:39:25 <sipa> you mean coins that devaluate over time?
750 2011-06-14 12:39:30 <topi`> Anon176: you mean that you want to have demurrage in bitcoins?