1 2012-08-09 00:17:28 <osmosis> luke-jr, git bisect results identical after second round.
  2 2012-08-09 00:18:18 <luke-jr> O.o
  3 2012-08-09 00:19:00 <osmosis> issue updated: https://github.com/bitcoin/bitcoin/issues/1663
  4 2012-08-09 00:25:17 <sipa> BlueMatt: right now there are some scaling issues with mine
  5 2012-08-09 02:00:40 <devrandom> gmaxwell: BlueMatt: gitian-updater now has a waiting period option.  It keeps the package in a temp dir until the waiting period expires.  Also started on some unit tests.
  6 2012-08-09 02:45:14 <weex> has it been fully verified now that encrypting a wallet with bitcoin-qt leaves no trace of the privkeys on the system?
  7 2012-08-09 02:45:31 <weex> i mean does the program make a copy and delete the old one or rewrite to the same file?
  8 2012-08-09 04:25:17 <wumpus> weex: yes, with 6.0+ it does
  9 2012-08-09 04:25:40 <weex> it does what?
 10 2012-08-09 04:25:57 <wumpus> already forgot your question?
 11 2012-08-09 04:26:28 <weex> well my question wasn't yes or now :P
 12 2012-08-09 04:26:30 <weex> no*
 13 2012-08-09 04:27:05 <weex> so it overwrites the same file then?
 14 2012-08-09 04:27:11 <Ferroh> your first question was yes or no :)
 15 2012-08-09 04:27:51 <weex> gots to keep it simple
 16 2012-08-09 04:28:38 <wumpus> it resilvers the wallet
 17 2012-08-09 04:29:03 <weex> what is a resilver?
 18 2012-08-09 04:29:37 <wumpus> starting from scratch
 19 2012-08-09 04:31:11 <weex> any possibility of the plain-text being recovered from a low-level scan of the stroage device?
 20 2012-08-09 04:31:33 <wumpus> that's always possible
 21 2012-08-09 04:31:41 <wumpus> just not a low level scan of the file
 22 2012-08-09 04:32:41 <wumpus> with modern file systems it's impossible to guarantee that the data is not still somewhere
 23 2012-08-09 04:32:57 <weex> hmmm, that's a problem
 24 2012-08-09 04:33:02 <Ferroh> weex: why?
 25 2012-08-09 04:33:08 <wumpus> ie in some journal or staging area
 26 2012-08-09 04:33:30 <weex> because if someone has stored the unencrypted wallet, they may think they're safe once it's encrypted
 27 2012-08-09 04:33:34 <wumpus> there are utilities to wipe the unused space but ofcourse the paranoid question remains :-) there's nothing bitcoin can do about it, at lesat
 28 2012-08-09 04:33:40 <Ferroh> weex: just use 0.6+ on a livecd (or liveusb) then copy new wallet.dat onto a new system
 29 2012-08-09 04:34:06 <weex> Ferroh: good idea, i got this question from the wiki since it had a part about erasing plain-text wallets
 30 2012-08-09 04:34:22 <weex> then i thought well what about the normal process with the latest client
 31 2012-08-09 04:34:42 <weex> on setup, it would be good to have an option to make a new wallet that's encrypted from the start
 32 2012-08-09 04:34:57 <wumpus> yes, that would be useful
 33 2012-08-09 04:35:02 <weex> but the livecd method works until then for the truly paranoid
 34 2012-08-09 04:35:27 <wumpus> maybe submit an issue on github
 35 2012-08-09 04:35:51 <weex> "hey, i noticed you don't have a wallet file yet, would you like it to be encrypted from the start?"
 36 2012-08-09 04:35:57 <weex> ok, will do
 37 2012-08-09 04:36:03 <wumpus> I think there were plans for a born encrypted walet, but it was never implemented AFAIK
 38 2012-08-09 04:38:02 <weex> oh, it was discussed before?
 39 2012-08-09 04:38:58 <wumpus> yes a long time ago, when encrypted wallets were introduced
 40 2012-08-09 04:40:45 <wumpus> I don't know why it was never done, it maybe difficult to implement due to some reason, or it was just forgotten
 41 2012-08-09 04:41:51 <weex> i can't find an issue so i'll make one
 42 2012-08-09 04:42:14 <wumpus> good
 43 2012-08-09 04:46:09 <wumpus> BlueMatt: it would be cool if the pulltester slapped a 'Testing OK' or 'Testing NOK' label on pulls that were tested, to see it in the overview... though it seems that github doesn't display labels for pull requests :/
 44 2012-08-09 04:48:56 <wumpus> which is curious, as pull requests do show up in the issue overview with labels. hm seems I'm not the first to think of this http://devblog.springest.com/dear-github-please-fix-your-pull-requests
 45 2012-08-09 04:53:53 <luke-jr> wumpus: non-committers can't use labels at all
 46 2012-08-09 04:55:10 <weex> i didn't realize github is like a chatroom
 47 2012-08-09 04:55:39 <luke-jr> lol
 48 2012-08-09 04:57:09 <wumpus> luke-jr: right, buteven committers can't assign labels to pull requests through the pull request view (nor see them), but they can see and manipulate labels on the same 'objects' in the issues view...
 49 2012-08-09 04:57:29 <luke-jr> wumpus: yes, I know ;)
 50 2012-08-09 04:57:43 <luke-jr> probably because Issues were implemented later
 51 2012-08-09 04:57:53 <wumpus> a really strange omission
 52 2012-08-09 04:57:55 <wumpus> yes, could be
 53 2012-08-09 04:58:04 <wumpus> when I started on github they already both existed
 54 2012-08-09 04:58:24 <luke-jr> same here, but it's obvious which came first IMO :p
 55 2012-08-09 04:59:29 <luke-jr> I wish someone would make a free clone of GitHub - Gitorious really doesn't compare. :/
 56 2012-08-09 05:00:13 <luke-jr> (or even better: Launchpad with git support)
 57 2012-08-09 05:00:18 <wumpus> weex: it's not really suited as a discussion forum, as everythinga ppears in one long thread, but at least it's easier to refer to than a chat on irc
 58 2012-08-09 05:00:49 <wumpus> yes that would be nice
 59 2012-08-09 05:02:00 <weex> i guess it comes down to what to tell a new user who wants to be secure, don't use an address before encrypting
 60 2012-08-09 05:02:50 <weex> or put another way, immediately encrypt your wallet before doing anything else
 61 2012-08-09 05:03:24 <wumpus> it would still be nice to ask the user automatically
 62 2012-08-09 05:03:54 <weex> yeah sort of encouraging best practices with ui flow
 63 2012-08-09 05:04:32 <wumpus> 'this is your only chance to make a truly secure wallet!' lol
 64 2012-08-09 05:05:47 <weex> yeah a Danger sign and a scared clippy would be good
 65 2012-08-09 05:22:07 <amiller> what should I call it if I want to talk about a hypothetical future bitcoin with certain qualities, like scale-invariance
 66 2012-08-09 05:23:02 <amiller> i'm talking _about_ bitcoin, since there's really only room/need for one of these things, at least there will clearly be one best one.
 67 2012-08-09 05:23:22 <amiller> although any good idea that's talked about could and would go in an alt chain first
 68 2012-08-09 05:26:04 <amiller> maybe all that's missing is codewords to describe some different scopes of bitcoin conversation, researchcoin or futurecoin or such
 69 2012-08-09 05:28:05 <amiller> for things less urgent than a bip, but not necessarily less important
 70 2012-08-09 05:38:06 <weex> yeah the terminology could use some work
 71 2012-08-09 05:38:19 <weex> bitcoin-like
 72 2012-08-09 05:38:23 <weex> blockchain-based
 73 2012-08-09 05:39:28 <weex> i think altcoin or altchain is most often used for a system with significant differences
 74 2012-08-09 05:41:04 <sytse> or just for evil attempts to make money out of nothing, under the pretense of 'significant differences'
 75 2012-08-09 05:41:20 <sytse> which bitcoin was as well of course but still :D
 76 2012-08-09 05:41:21 <amiller> right, that's exactly what i don't mean to associate with
 77 2012-08-09 05:41:52 <weex> it can't be ignored that nobody would have any investment in a system with such differences
 78 2012-08-09 05:42:28 <amiller> i think that most people (and i) also feel that there's really only need for one of these things
 79 2012-08-09 05:42:41 <amiller> it's wide and open, like the internet. there aren't lots of competing internets, since that's not at all the point
 80 2012-08-09 05:42:52 <sytse> there were
 81 2012-08-09 05:42:55 <sytse> but not anymore
 82 2012-08-09 05:43:00 <sytse> (think minitel)
 83 2012-08-09 05:43:12 <amiller> the solution is typically to pick the largest and build on that
 84 2012-08-09 05:43:32 <weex> i thought for a time it might be interesting to have a chain that served as a way to fund a company by having some fraction of mined coins assigned to the company's treasury
 85 2012-08-09 05:45:59 <weex> i guess you just talk about a bip
 86 2012-08-09 06:01:32 <amiller> "bitcoin 2.0" and "hard fork wishlist" may be relevant
 87 2012-08-09 06:02:08 <amiller> https://en.bitcoin.it/wiki/Hardfork_Wishlist#Major_structural_changes
 88 2012-08-09 06:02:37 <amiller> for example if you look there, the first category has two forum threads that are both equivalent/predecessors to etotheipi's current post
 89 2012-08-09 06:03:16 <amiller> they used to call it "flip the chain" but now it's "merkle trees" and "coinbase commitment" and UTXO
 90 2012-08-09 06:11:06 <sytse> what's next? Quantum cryptography?
 91 2012-08-09 06:11:22 <amiller> quantum cryptography is in a whole other category
 92 2012-08-09 06:11:23 <sytse> a COBOL port?
 93 2012-08-09 06:11:38 <amiller> all of the above topics are all based on simple uses of collision resistant hashes
 94 2012-08-09 06:11:54 <amiller> i guess you would have to agree on some of the goals
 95 2012-08-09 06:12:05 <sytse> a millisecond-per-block subtree that's merged back into the main one?
 96 2012-08-09 06:12:16 <amiller> would everyone agree that the ideal form of bitcoin would eventually come to an agreement no matter what
 97 2012-08-09 06:12:18 <sytse> amiller: yes :)
 98 2012-08-09 06:12:48 <sytse> merkle trees don't seem like a bad idea
 99 2012-08-09 06:12:55 <amiller> it's been said that bitcoin solves the byzantine generals problem, but really it solves some different variant of the problem in a model that no one has looked at before
100 2012-08-09 06:13:10 <amiller> so even from a theoretical point of view there's work to do just clarifying what the point is and how you'd tell if it's working or not
101 2012-08-09 06:14:21 <amiller> i don't have a problem with something like checkpoints, especially as a practical decision now, but i would be a bit disappointed if the only possibility was to rely on them forever, if there was no other way.
102 2012-08-09 06:16:02 <amiller> i'm sure that 99% of suggested "improvements" are going to turn out to be totally worthless.
103 2012-08-09 06:27:26 <weex> so in the byzantine generals problem, bitcoin seems to offer another solution in giving the generals a problem that is hard to solve so only one of them is likely to solve it every so often.
104 2012-08-09 06:31:00 <sytse> byzantine generals with lots of sudoku puzzles
105 2012-08-09 06:31:21 <sytse> and they get warhorses when they solve one
106 2012-08-09 06:31:47 <weex> they have to send around beautifully carved sapphires
107 2012-08-09 06:32:19 <sytse> ah, and use their slaves to mine and carve them
108 2012-08-09 06:32:33 <weex> proof of work.
109 2012-08-09 06:32:55 <sytse> hopefully though, hannibal doesn't infiltrate the generals
110 2012-08-09 06:32:58 <sytse> that'd be a problem
111 2012-08-09 06:33:48 <weex> as long as he doens't infiltrate too many of them
112 2012-08-09 06:33:56 <sytse> I meant
113 2012-08-09 06:34:11 <sytse> hannibal has *lots* of slaves willing to work for overthrowing the system
114 2012-08-09 06:38:41 <weex> yeah, well if all the generals are surrounded anyway it makes the decision rather pointless
115 2012-08-09 06:50:55 <amiller> the reason i say it doesn't solve the byzantine generals problem is that that problem requires everyone not just to come to an agreement, but to declare they've reached agreement
116 2012-08-09 06:50:59 <amiller> it's about having a final answer
117 2012-08-09 06:51:09 <amiller> a more interesting (and more modern) problem is called stabilizing consensus
118 2012-08-09 06:51:41 <amiller> where the requirement is that you eventually converge. but it's not necessarily the case that you can say for sure that it has happened
119 2012-08-09 06:51:55 <amiller> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.1040&rep=rep1&type=pdf
120 2012-08-09 06:52:28 <amiller> this was introduced by Dana Angluin (by far one of the most famous distributed systems researchers) in 2006
121 2012-08-09 06:52:51 <amiller> for that matter, dijkstra is credited with the term "self-stabilizing system"
122 2012-08-09 06:54:36 <amiller> but the truth is there are so many plausible subtleties, and in the last thirty years every little variation of the problem leads to different and often unexpected results
123 2012-08-09 06:55:35 <amiller> the fact that bitcoin is about a network with unknown size and unknown identities places it outside the scope of 98% of distributed systems research
124 2012-08-09 06:57:49 <amiller> there's no reason to think it's impossible, although it's most likely the case that if we avoid making hard assumptions, we should be focusing on the family of 33% problems rather than the 51% problems
125 2012-08-09 07:06:08 <sipa> amiller: worry about upgrading the existing chain later; i think it's more interesting to think about something bitcoin-like
126 2012-08-09 07:08:19 <amiller> i suppose that's the way to go
127 2012-08-09 07:09:15 <t7> is there a schema for the bitcoind database(s) anywhere?
128 2012-08-09 07:09:44 <sipa> i've been thinking about other improvements some time ago with roconnor
129 2012-08-09 07:10:10 <sipa> i don't think all of it was ever written down, though
130 2012-08-09 07:12:18 <sipa> t7: no schema, they are just key-value stores
131 2012-08-09 07:12:44 <t7> sipa: is there a table for blocks and one for transactions or something
132 2012-08-09 07:12:48 <sipa> no
133 2012-08-09 07:12:50 <t7> i need to dig through the code
134 2012-08-09 07:13:02 <sipa> one tableper file
135 2012-08-09 07:38:25 <t7> there are so many 100+ line functions in bitcoin
136 2012-08-09 07:39:01 <sipa> patches welcome
137 2012-08-09 10:11:28 <[Tycho]> ::bc,help
138 2012-08-09 10:11:32 <[Tycho]> ::bc.help
139 2012-08-09 10:11:48 <gribble> Error: "bc.help" is not a valid command.
140 2012-08-09 10:11:48 <[Tycho]> ;;bc.help
141 2012-08-09 10:11:50 <sipa> ;;bc,help
142 2012-08-09 10:11:51 <gribble> Alias bc,24hprc, Alias bc,avgprc, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btcguild, Alias bc,calc, Alias bc,calcd, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias bc,fx, Alias bc,gen, Alias bc,gend, Alias bc,halfreward, Alias bc,help, Alias bc,hextarget, Alias bc,intersango, Alias (2 more messages)
143 2012-08-09 10:11:56 <[Tycho]> Thanks.
144 2012-08-09 10:12:13 <gribble> Estimated time of bitcoin block reward halving: Tue Dec  4 22:52:00 2012 | Time remaining: 16 weeks, 5 days, 18 hours, 40 minutes, and 0 seconds
145 2012-08-09 10:12:13 <sipa> ;;bc,halfreward
146 2012-08-09 10:12:32 <[Tycho]> What was that one to see the probability of not finding any block in a year with 10 GH/s ?
147 2012-08-09 10:12:50 <[Tycho]> ;;bc,calc 10000000
148 2012-08-09 10:12:51 <gribble> The average time to generate a block at 10000000 Khps, given current difficulty of 2036671.0886933 , is 1 week, 3 days, 2 hours, 59 minutes, and 3 seconds
149 2012-08-09 10:13:25 <[Tycho]> There was some command showing probability...
150 2012-08-09 10:13:43 <gribble> Error: "bc,estimete" is not a valid command.
151 2012-08-09 10:13:43 <[Tycho]> ;;bc,estimete
152 2012-08-09 10:13:45 <[Tycho]> ;;bc,estimate
153 2012-08-09 10:13:46 <gribble> 2146729.71298704
154 2012-08-09 10:15:19 <gribble> (bc,prob <an alias, at least 1 argument>) -- Alias for "math calc 1-exp(-$1*1000 * [seconds $*] / (2**32* [bc,diff]))".
155 2012-08-09 10:15:19 <[Tycho]> ;;bc,prob
156 2012-08-09 10:15:26 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression.  Please remove them.
157 2012-08-09 10:15:26 <[Tycho]> ;;bc,prob 10000000
158 2012-08-09 10:15:45 <[Tycho]> ;;bc,prob 10000
159 2012-08-09 10:15:46 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression.  Please remove them.
160 2012-08-09 10:15:58 <sipa> stupid bot
161 2012-08-09 10:16:18 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression.  Please remove them.
162 2012-08-09 10:16:18 <sipa> ;;bc,prob 1h
163 2012-08-09 10:16:22 <[Tycho]> Do you knoq how to use this command ?
164 2012-08-09 10:16:39 <sipa> yes, with a time after it
165 2012-08-09 10:16:54 <sipa> but it doesn't seem to work
166 2012-08-09 10:16:58 <[Tycho]> ;;bc,prob 10000000 1h
167 2012-08-09 10:16:59 <gribble> 0.0041070347725
168 2012-08-09 10:17:03 <[Tycho]> Cool
169 2012-08-09 10:17:06 <sipa> doh
170 2012-08-09 10:17:13 <[Tycho]> ;;bc,prob 10000000 1y
171 2012-08-09 10:17:14 <gribble> 1.0
172 2012-08-09 10:17:22 <[Tycho]> 1.0, really ?
173 2012-08-09 10:17:57 <sipa> with 10GH you have 100% chance to find a block in a year, yes
174 2012-08-09 10:18:04 <[Tycho]> Seems a bit wrong to me.
175 2012-08-09 10:18:15 <[Tycho]> It should never reach 100%, no ?
176 2012-08-09 10:18:27 <sipa> well, 0.999999999999999 something
177 2012-08-09 10:18:39 <gribble> 6.85891777098e-05
178 2012-08-09 10:18:39 <[Tycho]> ;;bc,prob 10000000 1m
179 2012-08-09 10:19:30 <gribble> 0.972817198941
180 2012-08-09 10:19:30 <[Tycho]> ;;bc,prob 1000000 1y
181 2012-08-09 10:19:47 <gribble> 0.999999985159
182 2012-08-09 10:19:47 <[Tycho]> ;;bc,prob 5000000 1y
183 2012-08-09 10:20:42 <BlueMatt> devrandom: yea, we have instructions for making a gitian zip in doc/release-process.,txt, but I dont think its ever actually happened yet
184 2012-08-09 10:23:29 <gribble> 0.999261095327
185 2012-08-09 10:23:29 <[Tycho]> ;;bc,prob 2000000 1y
186 2012-08-09 10:36:28 <BlueMatt> sipa: ok, Ill install mine again then, though Im really looking forward to switching
187 2012-08-09 10:37:06 <sipa> it works, but from time to time it starts using a lot of CPU, and eventually, if you kill it then, the datafile is gone
188 2012-08-09 10:37:22 <sipa> several bugs that are easy to fix, but i'd rather do it right in one go
189 2012-08-09 10:38:10 <BlueMatt> fair enough
190 2012-08-09 10:38:47 <BlueMatt> for those who's pulls were marked as failed earlier, sorry, disk space ran out in /var/www, Ive deleted a few comments and reset a few pulls
191 2012-08-09 10:59:23 <sead> hi - i would like to have some help/hint - can anyone tell me the price and amount of Tid 1344515801056587 (bid) mtgox trade? (got strange values here)
192 2012-08-09 10:59:43 <sipa> ask MagicalTux
193 2012-08-09 11:00:59 <sead> thx
194 2012-08-09 11:01:35 <Ferroh> so does the "target-confirmations" parameter in the listsinceblock RPC call basically just get ignored?
195 2012-08-09 11:01:43 <Ferroh> it doesn't seem to have any effect
196 2012-08-09 11:24:59 <t7> /usr/bin/ld: cannot find -lboost_system
197 2012-08-09 11:25:06 <t7> libboost-dev is already the newest version.
198 2012-08-09 11:25:11 <t7> wut
199 2012-08-09 11:26:41 <t7> ah its separate now
200 2012-08-09 11:30:11 <t7> ive really fucked up this sid install
201 2012-08-09 11:45:27 <Ferroh> weex: you could also just create a new wallet, then encrypt it, and then ask for 101 addresses. Only 100 addresses were created unencrypted so just don't use those.
202 2012-08-09 11:46:11 <wumpus> you don't have to 'ask for 101 addresses' even
203 2012-08-09 11:47:28 <BlueMatt> you could start with keypoolsize=0
204 2012-08-09 11:48:53 <sipa> when you encrypt a wallet, all old addresses are marked used
205 2012-08-09 11:49:20 <sipa> so any new address you ask for afterwards will always be one that never touched disk in unencrypted form
206 2012-08-09 11:59:36 <Eliel> while on this topic, what is it, exactly, that happens if you have encrypted wallet and run out of keypool while mining?
207 2012-08-09 11:59:53 <Eliel> I have heard lots of people say "don't mine on encrypted wallet" but not the reason :)
208 2012-08-09 12:00:10 <BlueMatt> it re-uses existing keys for new coinbases
209 2012-08-09 12:00:22 <BlueMatt> specifically, the default key iirc
210 2012-08-09 12:00:43 <gmaxwell> Eliel: Where did you hear this?
211 2012-08-09 12:01:01 <Eliel> too long ago to remember :)
212 2012-08-09 12:01:22 <BlueMatt> wait, no, that cant be right
213 2012-08-09 12:01:22 <Eliel> someone was just asking me about it so I thought I'd go find out what happens really :)
214 2012-08-09 12:01:27 <BlueMatt> hmm...I dont remember
215 2012-08-09 12:03:13 <t7> i think it should ask if you want encryption when you first start
216 2012-08-09 12:03:22 <t7> seems like a good idea
217 2012-08-09 12:03:35 <gmaxwell> t7: thats a fantastic way to cause the loss of coins.
218 2012-08-09 12:03:58 <t7> people forgetting their passwords?
219 2012-08-09 12:04:14 <gmaxwell> Especially some password they got prompted for before ever using bitcoin at all.
220 2012-08-09 12:04:29 <t7> put a disclaimer under the password box
221 2012-08-09 12:04:33 <t7> or something
222 2012-08-09 12:04:43 <sipa> disclaimers may help you avoid lawsuits
223 2012-08-09 12:04:44 <gmaxwell> Come on, you know that won't help.
224 2012-08-09 12:04:48 <gmaxwell> Right.
225 2012-08-09 12:04:48 <sipa> it will not help people to remember it
226 2012-08-09 12:04:58 <t7> gmaxwell: i thought it was only gonna be a choice
227 2012-08-09 12:05:03 <t7> not forced to encrypt
228 2012-08-09 12:05:25 <sipa> i wouldn't be opposed to a command-line option to have the wallet start in encrypted form, though
229 2012-08-09 12:05:28 <gmaxwell> In any case, I've not seen any evidence that what we currently have isn't sufficient.
230 2012-08-09 12:06:38 <gmaxwell> sipa: "meh". If you're going to remember to set the option you might as well turn on encrypt first thing you do.
231 2012-08-09 12:07:18 <sipa> though i think the real solution is multi-wallet support, and a dialog "create new wallet" with some advanced tab with settings like deterministic wallet seed, keypool size, encryption, ...
232 2012-08-09 12:07:46 <gmaxwell> sipa: sure, that sounds reasonable.
233 2012-08-09 12:08:34 <t7> i guess the client for joe average will have to be one that only downloads block headers too
234 2012-08-09 12:09:00 <gmaxwell> Perhaps, but thats not necessarily an "or" there.
235 2012-08-09 12:09:42 <gmaxwell> It's perfectly possible to have a client that starts off as a SPV node, but if the system has resources it quietly becomes a full  (or half-full, once we can do that) node in the background.
236 2012-08-09 12:13:05 <wumpus> I do think most people expect to enter a password on first wallet creation... I mean, how many e-wallet services work without a password?  it encourages some security by default
237 2012-08-09 12:13:50 <sipa> maybe force entering the password at startup (only in GUI mode though)?
238 2012-08-09 12:14:03 <gmaxwell> instawallet does but generally,  all these things that people normally use "passwords" for are _passwords_ not cryptographic keys. They're recoverable if lost.
239 2012-08-09 12:14:14 <wumpus> force? it doesn't have to be mandatory
240 2012-08-09 12:14:20 <gmaxwell> sipa: that is guarenteed loss unless you also force them to back up the password.
241 2012-08-09 12:14:27 <sipa> right
242 2012-08-09 12:14:55 <wumpus> also a lot of people have shared computers, so locking makes sense
243 2012-08-09 12:15:17 <gmaxwell> When people startup bitcoin they don't yet have anything valuable in it, so they'll just blah blah past prompts.
244 2012-08-09 12:15:58 <wumpus> something like bitcoin shouldn't be unencrypted by default, ideally
245 2012-08-09 12:16:02 <BlueMatt> hmm...I know we discussed the issue before wallet crypto was merged, but apparently not...it will gladly reuse the default key in coinbase (and thus break bip30)
246 2012-08-09 12:16:08 <Ferroh> ugh, from urllib2 documentation "HTTPS requests do not do any verification of the server???s certificate." umm maybe these guys should get on that...
247 2012-08-09 12:16:17 <BlueMatt> so, turns out Eliel was right, dont mine on an encrypted wallet, afaict
248 2012-08-09 12:16:20 <gmaxwell> I really wouldn't want to push any harder on encryption until we have reasonable recovery mechenisms.
249 2012-08-09 12:16:31 <wumpus> Ferroh: it can be enabled AFAIK
250 2012-08-09 12:16:37 <gmaxwell> BlueMatt: why? it just keeps giving out the last key when it hits the end.
251 2012-08-09 12:16:41 <BlueMatt> yea
252 2012-08-09 12:16:50 <BlueMatt> it even has code there to not do that, but its not used in mining
253 2012-08-09 12:16:55 <wumpus> Ferroh: but yeah it's a lousy default
254 2012-08-09 12:17:03 <gmaxwell> BlueMatt: but why do you think this is a problem?
255 2012-08-09 12:17:04 <BlueMatt> gmaxwell: not the last key, the default key
256 2012-08-09 12:17:11 <BlueMatt> gmaxwell: bip30?
257 2012-08-09 12:17:12 <wumpus> almost as bad as not using https at all
258 2012-08-09 12:17:33 <gmaxwell> BlueMatt: I thought we had code to prevent duplication for reused keys.
259 2012-08-09 12:17:39 <BlueMatt> nope
260 2012-08-09 12:17:42 <BlueMatt> not afaict
261 2012-08-09 12:17:47 <sipa> meh
262 2012-08-09 12:17:58 <BlueMatt> we have a fAllowReuse, but we dont use it for CreateNewBlock
263 2012-08-09 12:18:09 <BlueMatt> which I know fAllowReuse was added specifically to address this issue
264 2012-08-09 12:18:10 <Ferroh> wumpus I dont think you can enable it in the urllib2 module, but I could manually verify relatively easily with the SSL module
265 2012-08-09 12:18:15 <sipa> who uses getwork still, except miners that won't use an encrypted wallet anyway?
266 2012-08-09 12:18:22 <sipa> *except pools
267 2012-08-09 12:18:33 <wumpus> Ferroh: ok that's really sucky
268 2012-08-09 12:18:37 <BlueMatt> Id assume getmemorypool does the same
269 2012-08-09 12:18:48 <gmaxwell> BlueMatt: huh?
270 2012-08-09 12:19:10 <gmaxwell> All the GMP miners build their own coinbase txns.
271 2012-08-09 12:19:17 <wumpus> Ferroh: yes, seems you need to define your own https_open... :/
272 2012-08-09 12:19:44 <BlueMatt> gmaxwell: true... anyway well, its no huge deal, because no one uses it, true, but its still a bug, which I do find interesting because it was heavily discussed before merge
273 2012-08-09 12:21:39 <gmaxwell> wumpus: in any case, on the encryption stuff I think getting users to do good backups and setup lost key recovery are much more important now than pushing more encryption.
274 2012-08-09 12:21:59 <gmaxwell> wumpus: (and once those things are solved they make pushing more encryption safer)
275 2012-08-09 12:22:55 <wumpus> right, it's just that wallet.dats are so incredibly attractive to steal now, but I suppose (hope) people with a lot of coins will enable encryption anyway without needing any pushing, especially if they let others on their pc
276 2012-08-09 12:23:43 <sipa> it's been a while since heard about wallet thefts, right?
277 2012-08-09 12:23:45 <gmaxwell> Fortunately we haven't heard much theft noise since we introduced encryption, I'm pretty sure I've heard more loss noise.
278 2012-08-09 12:24:02 <wumpus> well about every rootkit/malware steals them these days, it's not news anymore
279 2012-08-09 12:24:21 <gmaxwell> I'm not talking about news, I'm talking about community discussion.
280 2012-08-09 12:24:36 <gmaxwell> But perhaps everyone who gets robbed now just feels incompetent and doesn't comment.
281 2012-08-09 12:24:43 <wumpus> yes just like irl
282 2012-08-09 12:26:08 <gmaxwell> In any case, loss is a real issue for sure as people do disuss it.  There are two things I think we could to improve that: Have a integrated feature to print the master key and prompt users to use it, and have an integrated feature to store an escrowed copy of the master key in the wallet.
283 2012-08-09 12:26:40 <gmaxwell> (and let the users pick their escrowing parties)
284 2012-08-09 12:27:20 <gmaxwell> the print stuff is more useful if it also backs up the wallet.. but thats hard without determinstic wallets.
285 2012-08-09 12:27:43 <wumpus> yes a print option would be nice
286 2012-08-09 12:29:10 <wumpus> though much more useful with a deterministic wallet as the code would be their wallet.. but maybe also less secure, as it suddenly requires only one component to be stolen
287 2012-08-09 12:30:19 <gmaxwell> wumpus: it could split the master key in two and print on seperate pages.
288 2012-08-09 12:32:38 <wumpus> yes so they could hide them in different places and would need both to recover
289 2012-08-09 12:32:59 <wumpus> anyway, printing the current encryption master key is a good idea
290 2012-08-09 12:33:38 <gmaxwell> It needs to make it difficult to save it to a file, otherwise doofuses will do that. (might as well leave the wallet unencrypted)
291 2012-08-09 12:33:46 <wumpus> it's also how it works when enabling ubuntu homedir encryption, you get the master key and are suggested to print it or stash it somewhere safe another way
292 2012-08-09 12:35:51 <wumpus> hehe well it would help against malware that steals wallet.dat but not any targeted attack
293 2012-08-09 12:36:33 <t7> there are people still not using a brain wallet?
294 2012-08-09 12:36:38 <t7> and writing tx by hand
295 2012-08-09 12:37:04 <t7> signing in my head can take a little while though :(
296 2012-08-09 12:37:41 <t7> i visualize an elliptic curve
297 2012-08-09 12:38:00 <wumpus> well the problem with brain wallet is that a lot of people use extremely insecure passwords, and everyone in the world can have a stab at guessing/bruteforcing
298 2012-08-09 12:38:41 <wumpus> without having to steal the wallet first
299 2012-08-09 12:38:56 <gmaxwell> Yup. Not just that but they can attack all in parallel with one unit of effort.
300 2012-08-09 12:39:33 <gmaxwell> And they can save their attack (even with space efficiency using a rainbow table) to fast reuse against new addresses as they show up.
301 2012-08-09 12:40:17 <Guest47255> why not prompt for name + password?
302 2012-08-09 12:40:29 <Guest47255> people will remember their names.
303 2012-08-09 12:40:47 <t7> its not a secret
304 2012-08-09 12:40:57 <Guest47255> the password is, that's enough.
305 2012-08-09 12:40:59 <wumpus> if they had only used a slow hash function such as bcrypt, but sha256 is just too easy to bruteforce
306 2012-08-09 12:41:14 <gmaxwell> Guest47255: you still get speedup (names have fairly low entropy), and really it's basically impossible to get a reasonable key out of a person.
307 2012-08-09 12:43:17 <Guest47255> the point is to protect against the parallel attack.
308 2012-08-09 12:43:42 <gmaxwell> Guest47255: I responded "you still get speedup (names have fairly low entropy)"
309 2012-08-09 12:43:51 <wumpus> memorizing a reasonable key is difficult for most people
310 2012-08-09 12:43:53 <gmaxwell> Our wallet encryption is already protected against parallel attack.
311 2012-08-09 12:44:13 <wumpus> yes we were talking about brainwallet
312 2012-08-09 12:44:19 <gmaxwell> wumpus: it's not especially difficult. But people can't generate one to begin with, and don't know they can't.
313 2012-08-09 12:44:57 <t7> i dont think computer illiterate people should be using bitcoin
314 2012-08-09 12:45:09 <t7> only because they wont realize they have malware
315 2012-08-09 12:45:09 <wumpus> gmaxwell: well if you really spend time memorizing it's possible, but that may be too much trouble for most
316 2012-08-09 12:45:10 <gmaxwell> ...
317 2012-08-09 12:45:43 <gmaxwell> t7: We're not talking about "computer illiterate people".
318 2012-08-09 12:47:01 <wumpus> how many bits of entropy would a reasonable key need?
319 2012-08-09 12:47:24 <wumpus> 128 or so?
320 2012-08-09 12:47:59 <gmaxwell> wumpus: 128 its generally considered the standard. You can encode that as 12 english words from a reasonably sized dictionary as the electrum recovery keys do.
321 2012-08-09 12:48:02 <wumpus> that's 8 words from a dictionary of 65536... hmm yeah should be possible
322 2012-08-09 12:49:00 <gmaxwell> Or 16 pgp words. (two dictionaries of size 256 selected for phonetic distinctiveness)
323 2012-08-09 12:49:36 <gmaxwell> wumpus: I have several such 128 bit keys memorized. Its not a big deal. But counting on memory for an otherwise unrecoverable cryptographic key is a bad idea.
324 2012-08-09 12:50:59 <wumpus> ideally it'd need to be randomly generated not chosen to be secure
325 2012-08-09 12:51:05 <t7> thats like an IPv6 address
326 2012-08-09 12:51:32 <t7> wait no
327 2012-08-09 12:53:57 <wumpus> Qt provides extensive cross-platform support for printing
328 2012-08-09 12:53:58 <wumpus> cool
329 2012-08-09 12:56:03 <gmaxwell> wumpus: right.
330 2012-08-09 13:02:18 <sipa> t7: yes an ipv6 address is 128 bits
331 2012-08-09 13:08:35 <BlueMattBot> Project Bitcoin build #7: STILL FAILING in 2 hr 7 min: http://jenkins.bluematt.me/job/Bitcoin/7/
332 2012-08-09 13:35:01 <weex> i was just thinking about stuff i saw in the wiki, but if wallet encryption is a best practice it's good for the default client to at least suggest that from the start
333 2012-08-09 13:36:02 <wumpus> yes, it is, but we decided we need more recovery options first
334 2012-08-09 13:43:28 <gmaxwell> weex: It's a best practice if and only if it's combined with other good practices.
335 2012-08-09 13:43:49 <gmaxwell> (good key selection and storage)
336 2012-08-09 13:44:46 <wumpus> one step at a time :)
337 2012-08-09 13:45:03 <jgarzik> *yawn* is it 11:45am already?
338 2012-08-09 13:45:16 <gmaxwell> weex: Encryption only does so much to protect you from malware and evil maids (they can install keyloggers) and it greatly increases the risk of lost coins due to mistyped/lost decryption keys. It's a good practice but only if care is taken to also protect against losing the keys.
339 2012-08-09 13:46:26 <t7> jgarzik: why?
340 2012-08-09 13:46:31 <t7> for fun(tm)?
341 2012-08-09 13:46:59 <jgarzik> because I wanna do lots of ACID, man
342 2012-08-09 13:47:05 <gmaxwell> My priorities would probably be more along the lines of {better wallet / key backup}, {better offline wallets}, {better multisign}. The ordering of the last two is mostly just because I think the UI issues for offline wallets are easier.
343 2012-08-09 13:48:10 <gmaxwell> (basically we just need watch-only wallets, plus some transaction export/import UI for offline wallets)
344 2012-08-09 13:49:11 <jgarzik> gmaxwell: speaking of priorities, once 0.7 is released, I think it is time to start discussion of what "version 1.0" and "removing the BETA label" means for the Satoshi client.  As the Satoshi client is already used in production, and other lightweight-focused clients exist, it's a question whether we need to wait for some moment of perfection to call it 1.0
345 2012-08-09 13:49:13 <wumpus> what device would you use for an offline wallet?
346 2012-08-09 13:49:17 <jgarzik> or whether we're close already
347 2012-08-09 13:49:48 <wumpus> if we want to get people to use offline wallets, it'd better be something that is readily available and easy to set up
348 2012-08-09 13:50:59 <wumpus> and is "offline" but can still communicate with the device running the bitcoin client in some way
349 2012-08-09 13:54:37 <wumpus> if it should be able to interface with different kinds of offline wallets we'd need some kind of API
350 2012-08-09 13:54:54 <gmaxwell> wumpus: Eventually it could be a very small program that runs on an old smartphone or netbook. There is a BIP specified for ascii messages for it.
351 2012-08-09 13:55:00 <wumpus> and vendors of the offline wallet would have to interface with that
352 2012-08-09 13:55:07 <gmaxwell> (or indeed, some kind of product)
353 2012-08-09 13:55:43 <wumpus> yes but how would it communicate with the pc? typing the transaction codes is probably too long :-)
354 2012-08-09 13:55:56 <wumpus> but that's the only way to be truly offline
355 2012-08-09 13:56:06 <wumpus> or maybe something using qr codes and webcam
356 2012-08-09 13:56:27 <gmaxwell> wumpus: by writing out a text file you can carry on usb, for example.  QR codes have the problem of not working the other way.
357 2012-08-09 13:56:41 <gmaxwell> If someone really cared I could write a modem to do it via audio.. but. meh.
358 2012-08-09 13:56:49 <wumpus> why wouldn't they not work the other way?
359 2012-08-09 13:57:12 <wumpus> yes it could also work though sound ofc... but that'd be pretty weird :-)
360 2012-08-09 13:57:50 <gmaxwell> You can do offline totally manually with our software now, but it's pretty hideous for usability at this point: http://people.xiph.org/~greg/signdemo.txt
361 2012-08-09 13:57:56 <wumpus> qr codes could work two ways with two devices facing each other (you could even make them animated and provide a full-blown protocol :-)
362 2012-08-09 13:58:25 <wumpus> but a text file on a usb stick, I guess that could work
363 2012-08-09 13:58:29 <wumpus> at least it's easy
364 2012-08-09 13:58:44 <wumpus> and manual
365 2012-08-09 13:59:22 <gmaxwell> https://en.bitcoin.it/wiki/BIP_0010  for the format etotheipi came up with.
366 2012-08-09 14:00:54 <wumpus> could be as easy as a menu option "Import transaction" which opens a file selection dialog
367 2012-08-09 14:02:08 <gmaxwell> right... the export part has the harder UI, since you'll need to run a watch only wallet thats the same as the offline one in order to draft transactions for it.
368 2012-08-09 14:03:30 <gmaxwell> The offline part signing part is trivial, and could be a rather small program instead of bitcoin-qt. (but we should also support it in bitcoin-qt)
369 2012-08-09 14:03:39 <wumpus> if the device has the private keys, why would you need to export anything?
370 2012-08-09 14:03:54 <wumpus> so it's client -> device -> client ?
371 2012-08-09 14:04:00 <gmaxwell> wumpus: The online wallet need to export the transaction you want signed.
372 2012-08-09 14:04:12 <gmaxwell> wumpus: it's not possible to write a transaction from an offline device.
373 2012-08-09 14:04:24 <gmaxwell> You must have copies of the inputs you want to spend to write a transaction.
374 2012-08-09 14:04:35 <wumpus> right... it would otherwise need the block chain
375 2012-08-09 14:05:07 <gmaxwell> So the workflow should be client (write transaction) -> device (review transaction and sign) -> client (import and announce transaction)
376 2012-08-09 14:06:09 <gmaxwell> You could alternatively shuttle copies of all the inputs over to the offline device and write the whole transaction there... but that requires a lot more code complexity and memory on the signing device, and probably isn't any better for security or usability.
377 2012-08-09 14:06:19 <wumpus> and if the offline device generates a new private key, it also needs to export the public key to the client
378 2012-08-09 14:06:55 <gmaxwell> wumpus: Right. Although I expect we'd only support these with HD wallets, so that the client doesn't have to do anything to keep up.
379 2012-08-09 14:08:01 <jgarzik> gmaxwell sipa: poke on 0.7 ACKs, pretty please with sugar on it
380 2012-08-09 14:08:24 <wumpus> what about MITM attacks at the client side?
381 2012-08-09 14:08:30 <BlueMatt> jgarzik: can we fix the test suite first
382 2012-08-09 14:09:03 <wumpus> the offline device can be considered secure, it would work if it first showed the transaction to be signed before the user pushes "confirm"
383 2012-08-09 14:09:10 <wumpus> on the device
384 2012-08-09 14:09:12 <jgarzik> BlueMatt: there is a list of pull reqs posted on bitcoin-devel.  if you feel a pull req needs to be added to the 0.7 list, feel free to reply on list...
385 2012-08-09 14:09:20 <BlueMatt> its not a pull yet
386 2012-08-09 14:09:27 <gmaxwell> wumpus: thus "review transaction", the signing device needs to say what it's paying and how much. Ultimately, I dont see any ways to solve the user being totally tricked about where the coins are going.
387 2012-08-09 14:09:53 <jgarzik> 0.7 release planning: https://sourceforge.net/mailarchive/forum.php?thread_name=CD11CEA3-F693-48D8-9BFF-1BB4C192007B%40gmail.com&forum_name=bitcoin-development
388 2012-08-09 14:10:10 <wumpus> true...
389 2012-08-09 14:10:25 <sipa> jgarzik: sorry been too buse the past few days; i'll go through the list tonight or tomorrow
390 2012-08-09 14:10:32 <sipa> *busy
391 2012-08-09 14:10:35 <jgarzik> tnx
392 2012-08-09 14:10:53 <wumpus> the online device could always mislead you into sending to the wrong address
393 2012-08-09 14:11:17 <wumpus> unless you communicate addresses through another channel
394 2012-08-09 14:11:56 <gmaxwell> wumpus: Right. No way around that though e.g. even if the transaction is authored entirely offline if your online device is compromised you're hosed.
395 2012-08-09 14:12:14 <sipa> my bank uses a standalone cardreader-like device, where you enter a challenge from the e-banking site + your PIN code, and it generates a response
396 2012-08-09 14:12:21 <sipa> if you do a large transaction
397 2012-08-09 14:12:27 <gmaxwell> My bigger concern was that an compromised online device not be able to trick you into spending all your bitcoins (to a fake change, or to fees).
398 2012-08-09 14:12:32 <sipa> it asks you to enter a challenge + the amount on the device
399 2012-08-09 14:13:17 <gmaxwell> wumpus: so an attacker could only steal what you intended to spend... and hopefully you'd find out (missing payments) before spending that much.
400 2012-08-09 14:13:24 <wumpus> yes but with your bank you probably know the bank number you're sending your money to, with bitcoin the addresses are much more random and less human readable
401 2012-08-09 14:14:31 <gmaxwell> If you want to be ... crazy... you can seralized out a SSL session from a site giving you a bitcoin address.. and make it so the signing device can validate that blob and show you the domain name.
402 2012-08-09 14:14:36 <wumpus> ...and change for every transaction (with best practives)
403 2012-08-09 14:14:45 <gmaxwell> But.. oy.. a lot of ugly data.. and ways for the signing device to itself be vulnerable.
404 2012-08-09 14:14:54 <BlueMatt> gmaxwell: no, you cant
405 2012-08-09 14:15:11 <gmaxwell> wumpus: the device knows its own keys, so it can tell you which outputs are change.
406 2012-08-09 14:15:13 <wumpus> signed bitcoin urls could maybe help
407 2012-08-09 14:15:20 <BlueMatt> gmaxwell: its ssl - it results in a symmetric key session, afaik all thats signed is the symmetric key
408 2012-08-09 14:15:27 <BlueMatt> or am I dreaming?
409 2012-08-09 14:15:33 <wumpus> the offline device could do validation on it.. though it'd need the vendor public key
410 2012-08-09 14:15:38 <gmaxwell> BlueMatt: oh duh, we had this discussion before and I think I told you that! :)
411 2012-08-09 14:15:47 <BlueMatt> yep, quite possible
412 2012-08-09 14:16:12 <gmaxwell> wumpus: right, you still have the cant-get-the-key problem. Doesnt really help. The reason I invoked SSL is because it does 'something' for that.
413 2012-08-09 14:16:34 <gmaxwell> but any of these things require a lot of non-trivial parsing code.... I don't really want that crap on my private key holder. :(
414 2012-08-09 14:16:43 <wumpus> yes the next step would be a centralized signining authority! :-)
415 2012-08-09 14:17:00 <gmaxwell> Well, or a namecoin SPV hash tree proof for a signing key.
416 2012-08-09 14:17:36 <wumpus> hehe, you keep plugging the usb stick
417 2012-08-09 14:17:51 <wumpus> first we need 3 roundtrips to authenticate, etc :-)
418 2012-08-09 14:18:22 <wumpus> nah the simple form would be useful already
419 2012-08-09 14:18:37 <gmaxwell> in any case, baby steps. I'm happy to get to 'can only retarget existing payments'.
420 2012-08-09 14:18:46 <wumpus> perfect security is impossible anyway, everything we can do to make it harder to steal coins is good
421 2012-08-09 14:18:57 <gmaxwell> If the attacker's payoff is very limited he won't compromise the online wallet in the first place.
422 2012-08-09 14:21:05 <jgarzik> it is very disappointing that python lacks an always sorted data structure
423 2012-08-09 14:21:19 <jgarzik> no btrees in sight anywhere
424 2012-08-09 14:23:05 <sipa> hmm, luke's block-creation tests were merged?
425 2012-08-09 14:23:16 <sipa> nice
426 2012-08-09 14:26:42 <sipa> luke-jr: should fJustCheck mode have an influence on signature checking?
427 2012-08-09 14:27:05 <sipa> (i know the current implementation doesn't, but maybe you want to avoid the skip-before-last-checkpoint rule in justcheck mode)
428 2012-08-09 14:27:32 <luke-jr> sipa: before the checkpoints, we won't be making blocks..?
429 2012-08-09 14:27:43 <luke-jr> oh, in the tests. maybe.
430 2012-08-09 14:31:57 <sipa> the (nTxFees < nMinFee) test is gone in CreateNewBlock ?
431 2012-08-09 14:40:35 <ajmal> hello!
432 2012-08-09 14:40:47 <ajmal> Any one there?!
433 2012-08-09 14:40:53 <sipa> nope, sorry
434 2012-08-09 14:41:21 <ajmal> thanks for the reply!
435 2012-08-09 14:41:33 <sipa> ;;bc,gen 346160
436 2012-08-09 14:41:34 <gribble> The expected generation output, at 346160 Khps, given current difficulty of 2036671.0886933 , is 0.170954237116 BTC per day and 0.00712309321315 BTC per hour.
437 2012-08-09 14:41:46 <gribble> 5.12862711348
438 2012-08-09 14:41:46 <sipa> ;;calc 30*0.170954237116
439 2012-08-09 14:41:49 <ajmal> can i know whether its possible to redeem Bitcoins As Dollars ... theres a lot with me... :D
440 2012-08-09 14:43:26 <jgarzik> ajmal: offtopic, try #bitcoin-otc
441 2012-08-09 14:43:29 <luke-jr> I think you're in the wrong channel.
442 2012-08-09 14:43:50 <ajmal> sorry ... thanks for that .. :)
443 2012-08-09 14:45:06 <jgarzik> BlueMatt: 1) the latest pulltester email gives a link that returns 404
444 2012-08-09 14:45:16 <BlueMatt> which pull?
445 2012-08-09 14:45:34 <jgarzik> BlueMatt: 2) it would be nice if the pulltester could tell you which gross step (pull, merge, build, test) failed.
446 2012-08-09 14:45:46 <jgarzik> BlueMatt: http://jenkins.bluematt.me/pull-tester/691c3a9506ef801e9a98069c4d1fabac2bd748be
447 2012-08-09 14:45:50 <luke-jr> ^ or even what the error is
448 2012-08-09 14:47:38 <sipa> ;;bc,gen 1000
449 2012-08-09 14:47:39 <gribble> The expected generation output, at 1000 Khps, given current difficulty of 2036671.0886933 , is 0.000493859016396 BTC per day and 2.05774590165e-05 BTC per hour.
450 2012-08-09 14:47:44 <sipa> ;;bc,gen 1000000
451 2012-08-09 14:47:45 <gribble> The expected generation output, at 1000000 Khps, given current difficulty of 2036671.0886933 , is 0.493859016396 BTC per day and 0.0205774590165 BTC per hour.
452 2012-08-09 14:50:35 <sipa> ;;bc,blocks
453 2012-08-09 14:50:36 <gribble> 193073
454 2012-08-09 14:56:36 <BlueMatt> why on earth would a vps at a major provider return something like "fatal: The remote end hung up unexpectedly" when checking out from github???
455 2012-08-09 14:56:46 <BlueMatt> also, why does that happen relatively often
456 2012-08-09 15:00:30 <Guest47255> that usually happens when somebody taps into your line
457 2012-08-09 15:01:25 <Guest47255> maybe you're being surveilled.
458 2012-08-09 15:01:27 <BlueMatt> on a regular basis to acomplish nothing?
459 2012-08-09 15:01:42 <BlueMatt> on a server that does nothing that is private or not publicly knowable?
460 2012-08-09 15:01:45 <BlueMatt> yes, that makes sense
461 2012-08-09 15:02:45 <SnapSnap> Guest47255: Are you suggesting that I'm under surveillance?
462 2012-08-09 15:03:05 <BlueMatt> also, no decent surveillance would reset a connection
463 2012-08-09 15:03:24 <BlueMatt> that would be some of the worse surveillance Ive ever heard of
464 2012-08-09 15:15:47 <BlueMattBot> Project Bitcoin build #8: STILL FAILING in 1 hr 34 min: http://jenkins.bluematt.me/job/Bitcoin/8/
465 2012-08-09 15:29:29 <gmaxwell> BlueMatt: which protocol are you using? some networks block git://
466 2012-08-09 15:30:17 <luke-jr> BlueMatt: github likes to terminate connections
467 2012-08-09 15:30:31 <luke-jr> it's more noticable when you configure your SSH to use persistent shared connections
468 2012-08-09 15:30:54 <luke-jr> if I don't push/pull for X minutes, I get that message
469 2012-08-09 15:37:00 <BlueMatt> gmaxwell: nope, its all https; luke-jr: so why would it only rarely happen, and unpredictably at that?
470 2012-08-09 15:37:19 <luke-jr> no idea
471 2012-08-09 15:51:53 <BlueMatt> next question, why did git still return 0 when its last line started with "fatal: "???
472 2012-08-09 15:57:48 <sipa> what changed?
473 2012-08-09 15:58:30 <gmaxwell> I mentioned testnet and elaborated on don't ask to ask. :)
474 2012-08-09 16:16:07 <makomk> gmaxwell: the link to the channel logs in the topic appears to have been cut off.
475 2012-08-09 16:17:38 <BlueMatt> jgarzik: https://github.com/bitcoin/bitcoin/pull/1549#issuecomment-7622170
476 2012-08-09 16:17:51 <BlueMatt> "Automatic sanity-testing: FAILED MERGE"
477 2012-08-09 16:18:20 <BlueMatt> only shows either MERGE or BUILD/TEST, but its something
478 2012-08-09 16:18:39 <gmaxwell> Hey, thats good.
479 2012-08-09 16:29:40 <gmaxwell> BlueMatt: speaking of that pull request... rebase that puppy so I can test it some and pull it.
480 2012-08-09 16:30:07 <BlueMatt> yea, I believe that was next on the todo list
481 2012-08-09 17:11:51 <wumpus> I have the same problem, github seems to be a tad unreliable sometimes, either the remote hung up unexpectedly or it just times out
482 2012-08-09 17:12:31 <wumpus> though it's ok now
483 2012-08-09 17:14:07 <BlueMatt> yea, its pretty rare, but it happens from time to time, it used to always hang up jenkins on its git polling and made it sit there without getting new changes for a month
484 2012-08-09 17:15:19 <BlueMatt> ok, pull-tester should be good, there may be one or two broken links on pulls tested earlier, if there is one someone wants bins/logs for, Ill re-run them
485 2012-08-09 17:17:04 <BlueMatt> sorry for the mess
486 2012-08-09 17:17:47 <BlueMatt> (If I just put a BETA at the end of each comment, would that make making a mess ok?, or is only google allowed to do that?)
487 2012-08-09 17:19:41 <luke-jr> BlueMatt: any chance it'd be easy to have a bot clean up the mess? :P