1 2012-08-08 01:20:06 <BlueMattBot> Project Bitcoin build #6: STILL FAILING in 2 hr 8 min: http://jenkins.bluematt.me/job/Bitcoin/6/
  2 2012-08-08 01:30:58 <luke-jr> jgarzik: ping
  3 2012-08-08 01:36:20 <jgarzik> luke-jr: pong
  4 2012-08-08 01:37:06 <luke-jr> jgarzik: it has come to my attention that AMD's ADL SDK (for reading temperatures etc from AMD GPUs) is incompatible with the GPL, and I have been distributing binaries built linking originally-cpuminer code combined with it
  5 2012-08-08 01:37:33 <luke-jr> jgarzik: I wanted to request a re-issuance of the license to the cpuminer code; I have removed the ADL SDK dependency
  6 2012-08-08 01:37:51 <luke-jr> (by replacing it with interface-only headers which are not copyrightable)
  7 2012-08-08 01:38:33 <jgarzik> luke-jr: what is a re-issuance of a license?
  8 2012-08-08 01:38:54 <luke-jr> jgarzik: permission to use the code under the GPL again, since I infringed on it (unknowingly)
  9 2012-08-08 01:39:25 <luke-jr> actually, I guess the GPLv3 has the cure clause& which brings up another question: did you agree to the change of license to GPLv3?
 10 2012-08-08 01:42:14 <luke-jr> ok, sorry, did my homework& cpuminer said GPLv2-or-later, so I guess I'm ok
 11 2012-08-08 01:42:38 <midnightmagic> that partly depends on whether it's gplv2 pure (in which case it says "or at your option any later version blah")
 12 2012-08-08 01:43:44 <luke-jr> midnightmagic: yeah, I looked up the last git revision Jeff committed to, and it has the "or at your option&" clause in the headers
 13 2012-08-08 01:45:06 <lianj> jgarzik: if verify with pyhone means runnning the script and verify the signatures then yes
 14 2012-08-08 01:58:00 <Ferroh> so can't Electrum just not bother with keystretching (hashing 100000 times), and instead just add 4 characters to the password (making it millions of times harder to crack)?
 15 2012-08-08 01:58:24 <Ferroh> or does hashing 100k times actually make it more than millions of times stronger?
 16 2012-08-08 01:59:50 <gmaxwell> Ferroh: electrum uses words to make the password easier to remember.
 17 2012-08-08 02:00:04 <Ferroh> s/password/seed
 18 2012-08-08 02:00:17 <Ferroh> to crack an electrum wallet, you only need to start generating seeds
 19 2012-08-08 02:00:19 <gmaxwell> Four easily memorable characters do no increase the entropy that much.
 20 2012-08-08 02:00:32 <Ferroh> the seed is a random sequence of lowercase letters and numbers
 21 2012-08-08 02:00:36 <Ferroh> and is 32 chars long
 22 2012-08-08 02:01:07 <Ferroh> to generate an electrum bitcoin address, you hash the seed 100k times to get the master public key, then you do a couple more hashes
 23 2012-08-08 02:01:23 <Ferroh> so what im asking is
 24 2012-08-08 02:01:25 <gmaxwell> Yes, I know.
 25 2012-08-08 02:01:27 <Ferroh> why bother hashing the seed 100k times
 26 2012-08-08 02:01:37 <Ferroh> isnt it just as good to make the seed a few chars longer?
 27 2012-08-08 02:01:56 <gmaxwell> Because it increases the work an attacker must do e.g. when attacking a partially disclosed or insecurely derrived seed.
 28 2012-08-08 02:02:06 <Ferroh> so does increasing the seed by 3 chars
 29 2012-08-08 02:02:11 <gmaxwell> And the 100k iterations should take about 100ms, it's effectively free.
 30 2012-08-08 02:02:20 <Ferroh> it takes ~2000ms
 31 2012-08-08 02:02:23 <Ferroh> in python
 32 2012-08-08 02:02:27 <gmaxwell> Then your software is crap. :)
 33 2012-08-08 02:02:34 <Ferroh> it is python :)
 34 2012-08-08 02:03:06 <gmaxwell> Ferroh: because increasing the seed by any N characters does not help if its insecurely generated or partially disclosed, and the increases result in more to memorize when encoded as recovery words.
 35 2012-08-08 02:03:29 <Ferroh> okay I guess that makes sense
 36 2012-08-08 02:05:00 <Ferroh> sigh, the python argparse module is almost 3000 lines of code :/
 37 2012-08-08 02:05:05 <Ferroh> apparently it is very hard to parse an argument
 38 2012-08-08 02:21:21 <Ferroh> Does someone know the minimum possible length of a BTC address?
 39 2012-08-08 02:21:46 <Ferroh> (that is accepted natively by the bitcoind client)
 40 2012-08-08 02:23:33 <luke-jr> yes
 41 2012-08-08 02:23:44 <Ferroh> are you that someone?
 42 2012-08-08 02:24:36 <luke-jr> a lot of people are, it's a fairly easy calculation
 43 2012-08-08 02:24:56 <Ferroh> Since I don't know how to do said easy calculation,
 44 2012-08-08 02:25:03 <Ferroh> can you tell me what the minimum length is?
 45 2012-08-08 02:25:28 <luke-jr> >>> len(b58encode('\0'*(160/8+1)+'xffxffxffxff'))
 46 2012-08-08 02:25:30 <luke-jr> 27
 47 2012-08-08 02:25:36 <Ferroh> awesome, thank you
 48 2012-08-08 02:25:50 <Ferroh> how about the max? :)
 49 2012-08-08 02:26:32 <luke-jr> >>> len(b58encode('x05'+'xff'*(160/8+4)))
 50 2012-08-08 02:26:34 <luke-jr> 34
 51 2012-08-08 02:26:51 <Ferroh> thanks again luke-jr :)
 52 2012-08-08 02:27:19 <luke-jr> 35 if you want to accept testnet
 53 2012-08-08 02:27:27 <Ferroh> i dont
 54 2012-08-08 02:27:38 <luke-jr> also note that addresses do not all start with 1
 55 2012-08-08 02:27:49 <Ferroh> .. they dont?
 56 2012-08-08 02:27:50 <luke-jr> newer ones start with 3
 57 2012-08-08 02:28:03 <Ferroh> wtf
 58 2012-08-08 02:28:03 <luke-jr> eg 3P14159f73E4gFr7JterCCQh9QjiTjiZrG
 59 2012-08-08 02:28:41 <Ferroh> er
 60 2012-08-08 02:28:51 <Ferroh> lots of people have written validation that will dail on that then
 61 2012-08-08 02:28:53 <Ferroh> *fail
 62 2012-08-08 02:28:58 <Ferroh> e.g. electrum:
 63 2012-08-08 02:28:59 <Ferroh> ADDRESS_RE = re.compile('[1-9A-HJ-NP-Za-km-z]{26,}\\Z')
 64 2012-08-08 02:29:00 <luke-jr> they should fix it :P
 65 2012-08-08 02:29:07 <Ferroh> oh
 66 2012-08-08 02:29:09 <luke-jr> well, clients need to know *how* to send to it too
 67 2012-08-08 02:29:10 <Ferroh> that actually passes
 68 2012-08-08 02:29:14 <Ferroh> "1-9"
 69 2012-08-08 02:29:17 <luke-jr> :p\n4243420
 70 2012-08-08 02:32:29 <jgarzik> luke-jr: yes you have permission to use GPL code once again :)
 71 2012-08-08 02:34:50 <luke-jr> jgarzik: thanks :
 72 2012-08-08 04:00:20 <forrestv> "PUSH 129" encodes to "020081", right? and "PUSH -5" to "0185"?
 73 2012-08-08 04:01:08 <forrestv> ah, this is in the intro on the Script page, nvm
 74 2012-08-08 09:13:53 <epscy> how can i get a list of all addresses i have used from bitcoind
 75 2012-08-08 09:14:10 <epscy> getaddressesbyaccount only gives me 45 addresses
 76 2012-08-08 09:14:19 <epscy> i am sure i have used more than that
 77 2012-08-08 09:20:26 <spitteler> writing a php script for Silver and Gold prices to BTC but i have an error somewhere and could use another set of eyes.  I can pastebin the code if any php guru can give me a few moments of their time :)
 78 2012-08-08 09:40:12 <SomeoneWeird> spitteler, join #coinabul and type @gold
 79 2012-08-08 09:40:13 <SomeoneWeird> :)
 80 2012-08-08 09:41:00 <coingenuity> spitteler: http://coinabul.com/api.php
 81 2012-08-08 09:41:02 <coingenuity> ;)
 82 2012-08-08 09:41:53 <spitteler> Someone looking to add it to my own website, i have it mostly working but for some reason line 89 is giving me trouble (incorrect output)  http://pastebin.com/JmZE0hSZ    i added line 74 and 75 to debug, but that is giving me the corect output
 83 2012-08-08 09:42:01 <spitteler> not sure exactly whats wrong
 84 2012-08-08 09:42:13 <SomeoneWeird> your own site?
 85 2012-08-08 09:44:00 <spitteler> purchasing silver :)
 86 2012-08-08 09:44:12 <SomeoneWeird> >.>
 87 2012-08-08 09:44:21 <SomeoneWeird> got some competition coingenuity :P
 88 2012-08-08 09:44:44 <coingenuity> lol SomeoneWeird
 89 2012-08-08 09:45:24 <Goilio> Code works fine for me on my system...
 90 2012-08-08 09:45:44 <spitteler> for me it shows..   1oz Gold: $1,606.11
 91 2012-08-08 09:45:58 <coingenuity> lmfao
 92 2012-08-08 09:46:01 <spitteler> 0.09 BTC is cheap for gold ;)
 93 2012-08-08 09:46:04 <Goilio> Yep, just realised I made a mistake...
 94 2012-08-08 09:46:09 <Goilio> Need to read more.
 95 2012-08-08 09:46:29 <SomeoneWeird> spitteler, ill buy at that price
 96 2012-08-08 09:46:30 <SomeoneWeird> sorry coingenuity
 97 2012-08-08 09:46:32 <SomeoneWeird> >.>
 98 2012-08-08 09:46:32 <spitteler> but the debug lines for 74 and 75 ouput  "146.6767" which is correct
 99 2012-08-08 09:47:05 <spitteler> Someone, my site is the opposite of Coinbul, i want to buy silver for btc  (unless he does that too)
100 2012-08-08 09:47:11 <Diablo-D3> !ticker
101 2012-08-08 09:47:11 <gribble> Best bid: 11.01831, Best ask: 11.01832, Bid-ask spread: 0.00001, Last trade: 11.01831, 24 hour volume: 47073, 24 hour low: 10.7, 24 hour high: 11.14999
102 2012-08-08 09:47:26 <coingenuity> spitteler: yep, they do that
103 2012-08-08 09:47:57 <Goilio> $BitcoinAu = number_format(($MtGoxAVG/$GoldUSD), 4);
104 2012-08-08 09:51:33 <spitteler> Goilio, it can't be.. it needs to be gold/btc to get the rate of oz gold in bitcoins
105 2012-08-08 09:52:15 <Goilio> Yeah I know. I just noticed. You also shouldn't be rounding everything until you do your output.
106 2012-08-08 09:55:04 <Goilio> Fixed
107 2012-08-08 09:55:13 <Goilio> Putting it up now
108 2012-08-08 09:55:26 <spitteler> removed and even doing just $BitcoinAu = ($GoldUSD/$MtGoxAVG);  i get 1oz Gold = 0.0913242009132 BTC
109 2012-08-08 09:56:00 <spitteler> thank you soo much!
110 2012-08-08 09:56:41 <Goilio> http://pastebin.com/3fJqGksy
111 2012-08-08 09:58:39 <Goilio> Do not use the number_format on data you are going to manipulate. It should only be used for output formatting.
112 2012-08-08 09:59:10 <spitteler> thank you, and good to know for the future :)
113 2012-08-08 09:59:23 <nsh> could do with an ounce for 0.1BTC
114 2012-08-08 09:59:58 <Goilio> I would even take off all the round functions I have done on those variables and only putting the round on the actual output.
115 2012-08-08 10:00:45 <spitteler> yes, i will do that from now on
116 2012-08-08 10:01:31 <Goilio> I got an oz of silver today for $8 ;)
117 2012-08-08 10:02:25 <spitteler> awesome! my latest score was much higher at 26 per oz for 20 AES
118 2012-08-08 10:03:20 <spitteler> estate sale last saturday,  got a 1/10 oz GAE for $160 (so about spot except its 22kt)
119 2012-08-08 10:03:36 <Goilio> nice
120 2012-08-08 10:04:50 <Goilio> Now back to my coding :P
121 2012-08-08 10:05:00 <spitteler> thanks again for the help :)
122 2012-08-08 10:05:27 <Goilio> No problem :)
123 2012-08-08 10:05:45 <Goilio> I saw PHP and couldn't resist :P
124 2012-08-08 10:06:32 <spitteler> lol, now to store them in a db so i dont consistently overwhelm someone elses server (it's the polite thing to do)
125 2012-08-08 10:08:43 <Goilio> Just have a cron job that runs every 5-15 minuites that updates it to the DB. Don't forget to round them first ;)
126 2012-08-08 10:09:18 <Goilio> I use emoticons far too much...
127 2012-08-08 10:16:46 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/1655  < can I get a non-bot second set of eyes on this? (its pretty trivial but I don't like to pull my own work unless its totally trivial or I know it has had some review)
128 2012-08-08 11:01:37 <roconnor> TIL CVE-2012-1909
129 2012-08-08 11:03:56 <sipa> roconnor: yes?
130 2012-08-08 11:04:22 <roconnor> I didn't realise a CVE was made
131 2012-08-08 11:04:33 <sipa> https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
132 2012-08-08 11:05:07 <sipa> ah, i didn't know the meaning of "TIL"
133 2012-08-08 11:44:08 <t7> i hope people dont stop mining immediately after the reward drops
134 2012-08-08 11:44:29 <t7> otherwise it will be very slow for 2 weeks worth of blocks
135 2012-08-08 11:44:35 <slush> t7: With rising price it will be stillprofitable
136 2012-08-08 11:44:57 <slush> t7: actually with current difficulty and FPGA miners, the 25BTC/block will be still profitable
137 2012-08-08 11:48:32 <jeremias> unless asics arrive, and then we will see probably huge difficulty increases
138 2012-08-08 11:51:20 <t7> im gonna make an ASIC with some old logic gates i found in the warehouse
139 2012-08-08 12:06:23 <Ferroh> "<luke-jr> 27"
140 2012-08-08 12:06:28 <Ferroh> https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
141 2012-08-08 12:06:36 <Ferroh> states " Mainline addresses can be 25-34 characters in length "
142 2012-08-08 12:16:23 <sipa> yes!
143 2012-08-08 12:16:59 <sipa> ultraprune database extracted from stock bitcoind database exactly matches database constructed by ultraprune itself
144 2012-08-08 12:26:35 <gmaxwell> sipa: congrats!
145 2012-08-08 12:32:44 <Graph_Theory> is anyone interested in developing php marketplace script
146 2012-08-08 12:34:02 <epscy> is anyone interested in developing a facebook clone for bitcoin users?
147 2012-08-08 12:34:37 <jeremias> there already is one, was it coinconnect or something...
148 2012-08-08 12:34:45 <jeremias> I personally see no need for such a site
149 2012-08-08 12:35:29 <sipa> if even google can't build something that challenges the network effect of facebook, i really doubt the bitcoin community can :)
150 2012-08-08 12:43:50 <denisx> Diablo-D3: why are you not supporting the midstate mining-extension?
151 2012-08-08 12:44:22 <denisx> I thought you said you had the best miner in the world? ;)
152 2012-08-08 12:45:43 <iddo> i did txn that sent 300 bitcoins from one address to someone else, but i see that it also sent 20 BTC from another address in my wallet to a new address in my wallet, why?
153 2012-08-08 12:46:05 <denisx> iddo: thats the change
154 2012-08-08 12:46:38 <denisx> iddo: you had 320 initially
155 2012-08-08 12:46:48 <i256> $./bitcoin-qt
156 2012-08-08 12:47:21 <i256> is possible to compile bitcoin into old systems?
157 2012-08-08 12:47:31 <BlueMatt> yes, but you would have to compile ityourself
158 2012-08-08 12:48:05 <i256> I can not
159 2012-08-08 12:48:29 <iddo> denisx: i had in my wallet 300 under one address and 20 under another address, it send the 300 to someone else (not in my wallet) as i specified, and the 20 to a new address in my wallet
160 2012-08-08 12:48:30 <i256> old client already has stopped working
161 2012-08-08 12:48:45 <BlueMatt> what error do you get, or is there some other reason?
162 2012-08-08 12:48:49 <i256> please help me
163 2012-08-08 12:49:07 <i256> ./bitcoin-qt: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoin-qt)
164 2012-08-08 12:49:19 <BlueMatt> no, what error do you get when you try to compile it yourself?
165 2012-08-08 12:49:46 <i256> I can not compile
166 2012-08-08 12:50:01 <i256> it is difficult
167 2012-08-08 12:50:10 <sipa> what operating system is that?
168 2012-08-08 12:50:18 <sipa> /distro
169 2012-08-08 12:50:42 <i256> ubuntu 9.04
170 2012-08-08 12:51:17 <i256> my 0.3.21 client dont working/connecting/mining
171 2012-08-08 12:51:23 <BlueMatt> why cant you upgrade, that release has been unmaintained for a long time
172 2012-08-08 12:51:32 <BlueMatt> also, 0.3.21 is vulnerable to a number of security issues
173 2012-08-08 12:51:48 <sipa> and slow
174 2012-08-08 12:51:54 <i256> I have a loot of programs this is not possible
175 2012-08-08 12:52:11 <i256> new version not working
176 2012-08-08 12:52:11 <SphericalCow> upgrade, at least to 10.04
177 2012-08-08 12:52:17 <BlueMatt> (and other clients will reject connections from 0.3.21 because it is unable to act as a reasonable client on the network)
178 2012-08-08 12:52:42 <i256> SphericalCow, not working  troubkle with library
179 2012-08-08 12:53:09 <i256> please compile to my old system
180 2012-08-08 12:53:20 <SphericalCow> it's inadvisable to store your money on an operating system which hasn't received security updates for almost 2 years
181 2012-08-08 12:53:43 <i256> my english is not good
182 2012-08-08 12:53:56 <i256> i'm not undestod what you typing
183 2012-08-08 12:54:16 <BlueMatt> dont store your money on an old os that hasnt received security updates for 2 years
184 2012-08-08 12:54:31 <SphericalCow> shall I try my polish?
185 2012-08-08 12:55:21 <i256> Yes I use Polish
186 2012-08-08 12:55:50 <sipa> BlueMatt: in the shortened versions of the pull request comments your bot makes, you can't see whether they passed or not
187 2012-08-08 12:56:08 <SphericalCow> heh, now I have to think
188 2012-08-08 12:56:28 <sipa> can you change it to just be "Automatic testing: passed" or "Automatic testing: failed", and maybe some more explanation or just a link after that?
189 2012-08-08 12:56:33 <SphericalCow> nie przychowywac twoj pieniadze na stary OS
190 2012-08-08 12:56:37 <SphericalCow> rozumiesz?
191 2012-08-08 12:57:02 <BlueMatt> sipa: which shortened version? there are only two versions, either it passed or it didnt
192 2012-08-08 12:57:11 <sipa> BitcoinPullTester commented on pull request 1648 on bitcoin/bitcoin an hour ago
193 2012-08-08 12:57:14 <sipa> The following is an automatic comment from the Bitcoin Pull Tester. If you believe it is in error, please contact jenkins@bluematt.me This pull pas&
194 2012-08-08 12:57:18 <i256> rozumiem, ale dlaczego. Ja mam bardzo du|o oprogramowania kt??re dziaBa na tej wersji. Nie moge zmieni systemu.
195 2012-08-08 12:57:20 <SphericalCow> ubuntu 9.04 nie mial "updates" od 2009
196 2012-08-08 12:57:25 <sipa> BlueMatt: that's what you see in the summary
197 2012-08-08 12:57:32 <BlueMatt> sipa: oh, you mean it cuts off, ok yea, I can do that
198 2012-08-08 12:57:35 <sipa> and it's not very useful :)
199 2012-08-08 12:57:51 <BlueMatt> I didnt realize there was a summary for comments...
200 2012-08-08 12:57:52 <i256> SphericalCow, ale ten system i tak nie ma bezpo[redniego dostpu do internetu
201 2012-08-08 12:58:24 <SphericalCow> ok, ale ciagle nie dobry idea
202 2012-08-08 12:58:31 <i256> Wystarczy skompilowac program na starsza wersje
203 2012-08-08 12:58:35 <SphericalCow> you see how bad my polish is :) sorry
204 2012-08-08 12:58:42 <i256> nie moge obliczac bitcoins
205 2012-08-08 12:59:02 <sipa> i256: either upgrade or compile bitcoin yourself
206 2012-08-08 12:59:13 <sipa> i256: we won't distribute a version for an outdated operating system
207 2012-08-08 12:59:14 <i256> please compile the new client into old stdlib
208 2012-08-08 12:59:51 <i256> sipa, to nie jest zbyt uprzejme. Mysle, ze warto dbac o uzytkownik??w
209 2012-08-08 13:00:11 <BlueMatt> sipa:  should I just delete the "The following...please contact..." part?
210 2012-08-08 13:00:34 <sipa> BlueMatt: i'd just turn it into "Automatic testing: [RESULT]" and a link
211 2012-08-08 13:00:59 <SphericalCow> i256, ubuntu 9.04 jest nieobslugiwany
212 2012-08-08 13:01:23 <i256> szkoda
213 2012-08-08 13:01:47 <BlueMatt> sipa: fair enough, though I kinda like the explanation of possible reasons for failure
214 2012-08-08 13:02:06 <sipa> ok, put them after the result?
215 2012-08-08 13:02:30 <BlueMatt> will do
216 2012-08-08 13:03:33 <SphericalCow> i256, compile new version of glibc
217 2012-08-08 13:03:39 <SphericalCow> then compile bitcoin linking to that version of glibc
218 2012-08-08 13:03:42 <SphericalCow> it can be done I guess
219 2012-08-08 13:04:22 <SphericalCow> another satisfied customer.
220 2012-08-08 13:04:50 <BlueMatt> yea, I kinda hate to give that response, but encouraging people to run such an old os...
221 2012-08-08 13:05:09 <SphericalCow> he was offended that nobody would compile it for him
222 2012-08-08 13:05:34 <jgarzik> *yawn*
223 2012-08-08 13:05:39 <jgarzik> is it 11am already?
224 2012-08-08 13:05:45 <sipa> no, 5pm
225 2012-08-08 13:06:43 <BlueMatt> ok, the passed version is now "Automatic sanity-testing: PASSED, see " + linkUrl + "for binaries and test log."
226 2012-08-08 13:06:55 <sipa> BlueMatt: thanks!
227 2012-08-08 13:08:04 <BlueMatt> also, does someone wanna fix the util_DateTimeStrFormat tests which cause this failure: http://jenkins.bluematt.me/job/Bitcoin/6/console
228 2012-08-08 13:09:30 <sipa> %x yields a 2-digit year?
229 2012-08-08 13:09:54 <BlueMatt> apparently
230 2012-08-08 13:10:10 <sipa> which is not a problem
231 2012-08-08 13:10:18 <BlueMatt> I would think not
232 2012-08-08 13:10:39 <sipa> date/time strings are platform-dependent, so a unit-test that checks it being equal to a fixed string seems pointless
233 2012-08-08 13:11:09 <BlueMatt> agreed
234 2012-08-08 13:14:49 <sipa> or at least %s is platform-dependent
235 2012-08-08 13:15:07 <jgarzik> many strftime possibilities are platform-independent
236 2012-08-08 13:15:17 <jgarzik> speaking generally it depends on the code
237 2012-08-08 13:17:08 <sipa> yes, so the unit test should only test for independent strings
238 2012-08-08 13:17:43 <Edward_Black> A quick question, what is current "average" block propagation time for the entire net ?
239 2012-08-08 13:34:19 <helo> it's probably tough to know the delay from when a block is sent to when most of the nodes have seen it, unless you run a pool
240 2012-08-08 13:34:55 <gmaxwell> Edward_Black: I don't think anyone is paying much attention to the average.
241 2012-08-08 13:35:12 <helo> each node must receive it, validate it, and then broadcast it to its peers?
242 2012-08-08 13:35:23 <gmaxwell> (the longer outliers are more interesting)
243 2012-08-08 13:35:36 <gmaxwell> helo: Yes, but the fanout is exponential.
244 2012-08-08 13:37:22 <Edward_Black> Well, okay, wich is the "longest time it took a block to propagate, to date" ?
245 2012-08-08 13:37:55 <epscy> propagate from where to where?
246 2012-08-08 13:38:06 <gmaxwell> Edward_Black: Well a node which has been offline for a year takes a year to get the latest block...
247 2012-08-08 13:38:27 <gmaxwell> Edward_Black: to what you're actually meaning to ask, we've seen multiminute skews.
248 2012-08-08 13:38:45 <gmaxwell> E.g. 2+ minutes from hearing it to relatively complete propagation.
249 2012-08-08 13:40:31 <BlueMatt> I still think a bitcoin backbone with a few public nodes for solo/p2pool miners would solve a large portion of the issues
250 2012-08-08 13:40:54 <BlueMatt> at least for miners, which is really all that significantly matters here
251 2012-08-08 13:47:07 <helo> so if you want to mess stuff up, you know where to direct your attacks?
252 2012-08-08 13:50:05 <helo> i guess as long as the delay is acceptable, it's better to keep everything as distributed and faceless as possible
253 2012-08-08 13:52:21 <BlueMatt> yea, if you dos the crap out of the backbone, it will go down and everything keeps functioning, going back to the way it is now
254 2012-08-08 13:52:28 <BlueMatt> otherwise, you get lower latency
255 2012-08-08 13:53:49 <helo> unless resources were diverted non-backbone nodes to create the backbone
256 2012-08-08 13:54:01 <helo> diverted *from
257 2012-08-08 13:54:16 <BlueMatt> but they wouldnt
258 2012-08-08 13:55:27 <gmaxwell> "meh"  It's good to see efforts to maintain healthy nodes.
259 2012-08-08 13:56:08 <helo> i could see people running permanent fast nodes right now adding them to the backbone
260 2012-08-08 13:56:19 <gmaxwell> "adding"
261 2012-08-08 13:56:41 <gmaxwell> helo: I think you should think more concretely about that.. what does it even mean?
262 2012-08-08 13:57:21 <helo> it means you put your node's ip on the list of nodes to DOS
263 2012-08-08 13:57:55 <BlueMatt> we already have a fallback nodes  list, but a backbone is something different entirely
264 2012-08-08 13:57:57 <gmaxwell> helo: but if you had a fast public node that anyone could find it would already be on such a list were it competently constructed.
265 2012-08-08 13:58:09 <BlueMatt> and would use trusted nodes, not random people
266 2012-08-08 13:59:02 <gmaxwell> BlueMatt: Again, "meh". Trusted nodes cloud the understanding of the security model. (also, its weak indeed without authenticated addnode)
267 2012-08-08 13:59:36 <BlueMatt> well, doesnt need to be incredibly trusted, just trusted enough that sites like mtgox would be willing to give them their ip and not get dos'd by them
268 2012-08-08 14:00:34 <helo> it would be neat if someone would fund a group to run a backbone of nodes
269 2012-08-08 14:00:56 <BlueMatt> jgarzik: is working on it, but is kinda busy with the $dayjob to work on it much
270 2012-08-08 14:01:21 <luke-jr> Ferroh: I think 25 is a theoretical impossibility ;)
271 2012-08-08 14:01:41 <luke-jr> Ferroh: the only way to get 27 afaik is with the zero pubkey; and the checksum of that isn't zero too
272 2012-08-08 14:01:49 <helo> should fast nodes pretend to be not-so-fast as long as the network is functioning well without them?
273 2012-08-08 14:03:25 <BlueMatt> helo: what?
274 2012-08-08 14:03:33 <helo> a weird idea
275 2012-08-08 14:03:54 <BlueMatt> if they are getting dos'd, maybe...but I have yet to hear anything about any nodes getting dos'd
276 2012-08-08 14:04:12 <Ferroh> pretty silly to dos random nodes
277 2012-08-08 14:04:20 <BlueMatt> yep
278 2012-08-08 14:04:30 <BlueMatt> it really wouldnt do anything
279 2012-08-08 14:04:50 <gmaxwell> BlueMatt: pools are routinely DOS attacked by extortionists.
280 2012-08-08 14:05:00 <BlueMatt> pool sure, but random nodes
281 2012-08-08 14:05:35 <Ferroh> pretending to be "not fast" isnt a defense against getting DOSed anyway?
282 2012-08-08 14:06:07 <helo> if the most capable nodes acted exactly like average nodes most of the time, it would be harder to build a node hit list
283 2012-08-08 14:06:59 <helo> if you have a high capacity node, you could proxy its functionality across enough hosts so that it appears as "15" average nodes, or something... but that's getting pretty desperate
284 2012-08-08 14:07:21 <BlueMatt> I dont see how building a node hit list would do anything, which is why I fail to see the use
285 2012-08-08 14:08:21 <helo> it's along the same lines as being resilient against attacks because of a lack of structure
286 2012-08-08 14:09:30 <BlueMatt> is there any reason an attacker would work to make a hit list?
287 2012-08-08 14:09:43 <BlueMatt> ie what is their target, and how would that help?
288 2012-08-08 14:10:47 <helo> the goal could be to reduce confidence in bitcoin's reliability
289 2012-08-08 14:12:58 <BlueMatt> how would dos'ing a specific list accomplish that more than dos'ing random nodes, or, probably even better specifically targeting low-resource nodes
290 2012-08-08 14:13:04 <BlueMatt> easier and you get more total node count
291 2012-08-08 14:15:45 <helo> dunno :)
292 2012-08-08 14:34:38 <devrandom> hi BlueMatt
293 2012-08-08 14:35:51 <devrandom> I don't know if you are watching the gitian repo - I added a workaround for vmbuilder so it doesn't have to be patched manually
294 2012-08-08 14:48:34 <devrandom> BlueMatt: also, perhaps bitcoin should make use of https://www.updateframework.com/ or http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html
295 2012-08-08 14:49:13 <MC-Eeepc> autoupdate is bad
296 2012-08-08 14:52:56 <BlueMatt> MC-Eeepc: and its that blanket attitude that has led to severe upgrade apathy among bitcoin users, which results in worse network-wide security
297 2012-08-08 14:53:19 <BlueMatt> auto-update, done properly, and allowing the user to say no, is a good thing
298 2012-08-08 14:54:00 <BlueMatt> devrandom: how would those updaters fit into gitian?
299 2012-08-08 14:54:03 <MC-Eeepc> upgrade apathy or the apathy that lends people to cede control over the bitcoin that runs on thier machines to a central authority (you guys)
300 2012-08-08 14:54:05 <MC-Eeepc> pick one
301 2012-08-08 14:54:15 <BlueMatt> neither
302 2012-08-08 14:54:26 <MC-Eeepc> how
303 2012-08-08 14:54:39 <BlueMatt> you can say no, and it only asks you to update
304 2012-08-08 14:54:57 <MC-Eeepc> dude you know people just hammer yes as fast as possible
305 2012-08-08 14:55:09 <BlueMatt> and, its not a single central authority, it requires acks from a number of devs
306 2012-08-08 14:55:34 <MC-Eeepc> irrelevant
307 2012-08-08 14:56:13 <MC-Eeepc> not to mention the security risk of a non legit autoupdate going out somehow
308 2012-08-08 14:56:15 <BlueMatt> well Id rather people upgrade to secure versions than just sit around and get around to it later or not even see that there is an update
309 2012-08-08 14:56:20 <luke-jr> MC-Eeepc: running unpatched versions is stupid
310 2012-08-08 14:56:32 <luke-jr> MC-Eeepc: if you want to break the software monopoly, support other clients
311 2012-08-08 14:56:45 <luke-jr> but always run the a supported version of whatever client you choose
312 2012-08-08 14:56:53 <MC-Eeepc> one would hope that getting hacked to shit is an incentive to upgrade
313 2012-08-08 14:57:16 <BlueMatt> but, for most bitcoin users, its apparently not (probably many of them dont realize there is an update available)
314 2012-08-08 14:57:19 <luke-jr> BlueMatt: to users, "a number of devs" is central
315 2012-08-08 14:57:30 <luke-jr> BlueMatt: we do have an alert system
316 2012-08-08 14:57:32 <MC-Eeepc> well
317 2012-08-08 14:57:43 <MC-Eeepc> maybe there could be an upgrade alert sure
318 2012-08-08 14:57:52 <MC-Eeepc> just a link to the site maybe
319 2012-08-08 14:58:13 <BlueMatt> MC-Eeepc: and thats what it does, but it also makes it easier to upgrade, and significantly more secure than a link to a download url
320 2012-08-08 14:58:27 <MC-Eeepc> but at this point most remaining nodes are prob bitcoind right, mining away all alone
321 2012-08-08 14:58:33 <luke-jr> MC-Eeepc: the idea for autoupgrade is, let the user click a single button to update when it's available, rather than find the current wbesite etc
322 2012-08-08 14:58:58 <luke-jr> MC-Eeepc: miners use pools these days, often not using bitcoind at all
323 2012-08-08 14:59:11 <luke-jr> and any bitcoind older than April won't even mine valid blocks anymore
324 2012-08-08 14:59:19 <MC-Eeepc> well the pools then, who are too fucking lazy to upgrade
325 2012-08-08 14:59:29 <luke-jr> MC-Eeepc: only some pools ;)
326 2012-08-08 14:59:41 <MC-Eeepc> on thier heads be it
327 2012-08-08 14:59:43 <BlueMatt> pools generally do upgrade, at least pull important patches
328 2012-08-08 14:59:43 <luke-jr> and often for good reason (bitcoind refuses to support features they need)
329 2012-08-08 15:00:08 <devrandom> BlueMatt: I am thinking of approaching them to integrate gitian
330 2012-08-08 15:00:10 <MC-Eeepc> as i said what if a miscreant got inside the autoupdate system or something
331 2012-08-08 15:00:19 <luke-jr> MC-Eeepc: also, you could use 0.4.x without running an unmaintained version; 0.4.7 is fully patched
332 2012-08-08 15:00:25 <BlueMatt> devrandom: nice, that would be quite nice
333 2012-08-08 15:00:41 <BlueMatt> MC-Eeepc: then the update wouldnt get enough sigs and you'd be fine
334 2012-08-08 15:00:50 <luke-jr> MC-Eeepc: the autoupdate system verifies PGP signatures from 3+ devs before it proposes an update
335 2012-08-08 15:01:05 <luke-jr> as in, the clients doing the update
336 2012-08-08 15:01:08 <MC-Eeepc> what if you all lose your mind and conspire
337 2012-08-08 15:01:16 <luke-jr> MC-Eeepc: then you need to switch to another client
338 2012-08-08 15:01:17 <BlueMatt> then you'd be fucked anyway
339 2012-08-08 15:01:20 <MC-Eeepc> 3 people could take the network
340 2012-08-08 15:01:29 <MC-Eeepc> or be coerced to take it
341 2012-08-08 15:02:04 <luke-jr> MC-Eeepc: so help the client economy by usign other implementations
342 2012-08-08 15:02:16 <BlueMatt> or 1 person could be coerced to push a windows-update than stole wallet.dats, bitcoin being compromised should really be the least of your worries if you are worried about people being bribed/coerced
343 2012-08-08 15:02:26 <MC-Eeepc> sure, but for now the reference client is by far the most used
344 2012-08-08 15:03:00 <MC-Eeepc> which means that the 3 crazy devs could fuck the network regardless of any other clients
345 2012-08-08 15:03:33 <luke-jr> MC-Eeepc: that's already true
346 2012-08-08 15:03:33 <MC-Eeepc> if official bitcoin was below a third of the network or whatever, then ok
347 2012-08-08 15:03:56 <luke-jr> if tcatm went crazy, he could one-man replace the links on bitcoin.org
348 2012-08-08 15:04:12 <luke-jr> having your own client verify PGP signatures *improves* the situation
349 2012-08-08 15:04:14 <BlueMatt> among others
350 2012-08-08 15:04:21 <MC-Eeepc> fuck
351 2012-08-08 15:04:40 <luke-jr> it may not be perfect, but it is a signfiicant improvement
352 2012-08-08 15:04:51 <BlueMatt> devrandom: I dont know, how much does tuf or thandy provide over just implementing a simple gitian-updater wrapper (already done for bitcoin-qt)
353 2012-08-08 15:05:05 <MC-Eeepc> whats the numbers on old client usage?
354 2012-08-08 15:05:11 <BlueMatt> they arent pretty
355 2012-08-08 15:05:28 <luke-jr> MC-Eeepc: as in, older branches, or maintained vs unmaintained/exploitable?
356 2012-08-08 15:05:44 <MC-Eeepc> isnt there a secret message broadcast thing tht can be used to tell people to get off their ass and upgrade
357 2012-08-08 15:05:55 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/charts/security.html <-- updated/testing/vulnerable
358 2012-08-08 15:06:04 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html <-- branches
359 2012-08-08 15:06:26 <MC-Eeepc> wait, there is more than one branch....
360 2012-08-08 15:06:32 <MC-Eeepc> wat
361 2012-08-08 15:06:45 <luke-jr> MC-Eeepc: there's one master branch, and a couple of stable backport branches that I maintain
362 2012-08-08 15:06:58 <MC-Eeepc> why?
363 2012-08-08 15:07:13 <luke-jr> for people who can't/won't upgrade to bleeding edge
364 2012-08-08 15:07:14 <devrandom> BlueMatt: yes, I'm not sure how much it buys for bitcoin.  I'll dig into them
365 2012-08-08 15:07:28 <luke-jr> since bleeding edge often introduces new bugs too
366 2012-08-08 15:07:47 <luke-jr> (though I'm working on getting 0.6.3 promoted to stable for Gentoo)
367 2012-08-08 15:08:18 <MC-Eeepc> bitcoin *is* bleeding edge
368 2012-08-08 15:08:35 <MC-Eeepc> the whole thing is supposed to be an experiment
369 2012-08-08 15:08:39 <BlueMatt> devrandom: thanks, Ill look at them a bit too, but Id be really happy to see gitian being used for non-bitcoin projects (esp tor)
370 2012-08-08 15:08:39 <luke-jr> MC-Eeepc: supposed to be
371 2012-08-08 15:08:43 <MC-Eeepc> seems like its got far too much interial for that now
372 2012-08-08 15:08:53 <luke-jr> but it's attained value before being ready
373 2012-08-08 15:09:05 <luke-jr> so we have to deal with it
374 2012-08-08 15:09:29 <luke-jr> not everyone is as big as MtGox and can write their own implementation :p
375 2012-08-08 15:09:47 <MC-Eeepc> ok well what about the super secret broadcast key gavin has got or whatever
376 2012-08-08 15:10:00 <luke-jr> BlueMatt: your binaries link is dead :P
377 2012-08-08 15:10:08 <BlueMatt> luke-jr: for which pull?
378 2012-08-08 15:10:10 <luke-jr> MC-Eeepc: what about it?
379 2012-08-08 15:10:14 <luke-jr> BlueMatt: 1647
380 2012-08-08 15:10:31 <MC-Eeepc> send a message out "upgrade you fuckers"
381 2012-08-08 15:10:51 <luke-jr> I think he did
382 2012-08-08 15:10:57 <luke-jr> at least for the bigger exploits
383 2012-08-08 15:11:06 <MC-Eeepc> ive never seen one :(
384 2012-08-08 15:11:43 <MC-Eeepc> that pie chart says 75% of the netowrk is current
385 2012-08-08 15:11:50 <MC-Eeepc> doesnt seem too bad
386 2012-08-08 15:11:55 <luke-jr> no, 75% run 0.6.x :p
387 2012-08-08 15:12:04 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/charts/security.html shows current ;)
388 2012-08-08 15:12:10 <luke-jr> only 38%
389 2012-08-08 15:12:14 <MC-Eeepc> yeah thats reasonably current
390 2012-08-08 15:12:33 <luke-jr> MC-Eeepc: every branch except 0.3.x has a current ;)
391 2012-08-08 15:12:55 <MC-Eeepc> 60% have a known exploit?
392 2012-08-08 15:12:58 <luke-jr> yes
393 2012-08-08 15:13:11 <MC-Eeepc> shit
394 2012-08-08 15:13:27 <luke-jr> https://en.bitcoin.it/wiki/CVEs has pie charts linked for each exploit individually
395 2012-08-08 15:13:57 <MC-Eeepc> cool
396 2012-08-08 15:14:07 <luke-jr> looks like CVE-2012-2459 might hit 77% before the fall after all
397 2012-08-08 15:14:18 <MC-Eeepc> well maybe this autoupdate thing is cool then
398 2012-08-08 15:14:29 <MC-Eeepc> but 3 devs seems too low plurality
399 2012-08-08 15:14:46 <luke-jr> MC-Eeepc: unfortunately, even finding 3 devs is difficult at times
400 2012-08-08 15:14:59 <MC-Eeepc> if you do not underestimate bitcoins potential importance, its too low
401 2012-08-08 15:15:02 <luke-jr> find more people to dev Bitcoin, and we can increase it ;)
402 2012-08-08 15:15:18 <MC-Eeepc> not nessecarily devs
403 2012-08-08 15:15:23 <luke-jr> it has to be devs.
404 2012-08-08 15:15:35 <BlueMatt> luke-jr: thanks, fixed
405 2012-08-08 15:15:37 <luke-jr> non-devs lack the technical capability of ensuring the builds aren't compromised
406 2012-08-08 15:16:00 <MC-Eeepc> what about the bigger players?
407 2012-08-08 15:16:11 <MC-Eeepc> you said gox does code
408 2012-08-08 15:16:41 <luke-jr> Gox doesn't use bitcoind at all
409 2012-08-08 15:16:42 <MC-Eeepc> at the very least, lets not have the 3 signers under the same legal juristiction.....
410 2012-08-08 15:16:47 <luke-jr> and MagicalTux is very busy
411 2012-08-08 15:17:04 <luke-jr> hmm
412 2012-08-08 15:17:16 <luke-jr> MC-Eeepc: I don't know any way for software to determine where the signer is
413 2012-08-08 15:17:45 <MC-Eeepc> humans do that, before anyone gets 'gotten to'
414 2012-08-08 15:17:52 <MC-Eeepc> not after
415 2012-08-08 15:18:41 <luke-jr> MC-Eeepc: how do humans do it?>
416 2012-08-08 15:18:48 <MC-Eeepc> im just saying, what if you put out a call for interested and competent parties/stakeholders to have a role in ensuring nothing bad goes out over the new autoupdate system and fucks everyones investment
417 2012-08-08 15:18:55 <BlueMatt> yes because humans never fly to other jurisdictions
418 2012-08-08 15:19:26 <MC-Eeepc> well im just throwing things out here
419 2012-08-08 15:19:30 <luke-jr> MC-Eeepc: please do run a campaign to find more devs :p
420 2012-08-08 15:19:51 <gmaxwell> Hell... just more people testing would be very very helpful.
421 2012-08-08 15:19:56 <MC-Eeepc> as i said not necessarily devs, competent stakeholders
422 2012-08-08 15:20:07 <luke-jr> &
423 2012-08-08 15:20:12 <luke-jr> that makes no sense, MC-Eeepc
424 2012-08-08 15:20:19 <gmaxwell> (I mean, real testing, not just starting up next-text and noticing it crash but then just waiting for the next update)
425 2012-08-08 15:20:21 <BlueMatt> there was discussion about allowing certain people to nak releases without being able to support them
426 2012-08-08 15:20:21 <luke-jr> gmaxwell: yes, but not for the topic :p
427 2012-08-08 15:20:30 <gmaxwell> Oh, sorry, just tuning in.
428 2012-08-08 15:20:36 <luke-jr> gmaxwell: next-test doesn't crash ;)
429 2012-08-08 15:20:40 <luke-jr> the current one at least
430 2012-08-08 15:20:44 <gmaxwell> luke-jr: go talk to midnightmagic
431 2012-08-08 15:20:53 <MC-Eeepc> peple with large incentive to ensure nothing bad goes out on autoupdate, like bad code that spends everyones coins to oblivion or something
432 2012-08-08 15:20:59 <luke-jr> gmaxwell: I talk to him fairly often
433 2012-08-08 15:21:12 <gmaxwell> luke-jr: he's been saying that its crashing for him.
434 2012-08-08 15:21:43 <luke-jr> the current one? O.o
435 2012-08-08 15:22:03 <MC-Eeepc> if reference bitcoin is the vast majority of the network, and mot of those mash 'yes' on the update screen, the chain could be at risk like that right?
436 2012-08-08 15:22:30 <luke-jr> MC-Eeepc: only if 3 devs were compromised
437 2012-08-08 15:22:42 <MC-Eeepc> only 3 devs
438 2012-08-08 15:22:47 <MC-Eeepc> probably all in america
439 2012-08-08 15:22:50 <luke-jr> hmm
440 2012-08-08 15:22:52 <MC-Eeepc> right
441 2012-08-08 15:23:00 <luke-jr> BlueMatt: what if the upgrade thing showed the list of signers?
442 2012-08-08 15:23:13 <luke-jr> BlueMatt: so users could wait until they see a specific name, or more signers?
443 2012-08-08 15:23:33 <MC-Eeepc> 3 devs could all get national security letters telling them to fuck bitcoin, and they would never legally be allowed to tell anyone
444 2012-08-08 15:23:54 <luke-jr> MC-Eeepc: nobody likes that possibility, but there's nothing better right now
445 2012-08-08 15:24:12 <BlueMatt> luke-jr: right now, it doesnt download the gitian zip at all until you initiate upgrade, but if you wanna write support for 2-part process into gitian-downloader, Id surely upgrade it in bitcoin-qt
446 2012-08-08 15:24:16 <MC-Eeepc> jacob applebaum has gotten an NSL, but he cant say why
447 2012-08-08 15:24:25 <MC-Eeepc> prob about tor or wikileaks
448 2012-08-08 15:24:41 <BlueMatt> no doubt wikileaks
449 2012-08-08 15:24:47 <MC-Eeepc> prob
450 2012-08-08 15:25:02 <MC-Eeepc> but thats why im saying at least keep the 3 signers in different juristictions
451 2012-08-08 15:25:14 <MC-Eeepc> preferrably with one outside of The West all together
452 2012-08-08 15:25:48 <luke-jr> BlueMatt: shouldn't the binaries include the final gitian outputs?
453 2012-08-08 15:25:50 <BlueMatt> MC-Eeepc: as much as I love being secure against weird things like corrupt gov'ts, I think you are going a bit far on the conspiracy theory stuff here
454 2012-08-08 15:25:56 <MC-Eeepc> in fact, look at the root key model for dnssec
455 2012-08-08 15:26:13 <luke-jr> MC-Eeepc: I'm not sure we have ANY active devs outside the west&
456 2012-08-08 15:26:19 <BlueMatt> luke-jr: huh?
457 2012-08-08 15:26:28 <MC-Eeepc> BlueMatt it may seemt that way, but consider the potential of bitcoin to usurp
458 2012-08-08 15:26:30 <luke-jr> BlueMatt: the autobuilds
459 2012-08-08 15:26:34 <BlueMatt> Im not sure we have any active devs outside of the eu+us
460 2012-08-08 15:27:07 <MC-Eeepc> and stranger things have happened int he last ten years
461 2012-08-08 15:27:50 <luke-jr> MC-Eeepc: the only way to improve the security more than BlueMatt's proposal, is to drastically increase the pool of developers contributing
462 2012-08-08 15:28:01 <luke-jr> the only way to do that effectively, is to increase hte pool of testers
463 2012-08-08 15:28:20 <MC-Eeepc> its just that every thime i see a nexus point of control anywhere in the system, im all like yeah we should try and smooth that back down
464 2012-08-08 15:28:24 <MC-Eeepc> its all i talk about really
465 2012-08-08 15:28:44 <BlueMatt> thats great, but thats also what the current auto-update proposal does ;)
466 2012-08-08 15:29:12 <MC-Eeepc> well im convinced about the autoupdates
467 2012-08-08 15:29:28 <MC-Eeepc> but it should be spectacularly hard to put out malware via it
468 2012-08-08 15:29:40 <MC-Eeepc> even for state actors
469 2012-08-08 15:29:52 <MC-Eeepc> perhaps especially for state actors
470 2012-08-08 15:30:26 <MC-Eeepc> maybe a bit tinfoil, but just consider this sytems potential
471 2012-08-08 15:30:59 <MC-Eeepc> then again the whole codebase has never had a proper audit as it is eh
472 2012-08-08 15:31:11 <BlueMatt> currently, all you need to do is convince github and/or sourceforge to put some crap up
473 2012-08-08 15:31:31 <MC-Eeepc> yeah that troubles me
474 2012-08-08 15:39:37 <osmosis> im getting core dumps and exceptions for upgrading wallet using bitcoin-qt 0.6.3. Im going to post an issue on github.
475 2012-08-08 15:42:39 <MC-Eeepc> why is deployment at 77% before details of a sploit get released?
476 2012-08-08 15:42:44 <MC-Eeepc> why 77%
477 2012-08-08 15:47:10 <Eliel> MC-Eeepc: I expect someone just liked the number :)
478 2012-08-08 15:47:39 <osmosis> https://github.com/bitcoin/bitcoin/issues/1663
479 2012-08-08 15:47:44 <osmosis> core dump on wallet upgrade
480 2012-08-08 15:47:51 <Eliel> MC-Eeepc: and of course, it's roughly high enough that impact on the network would be small enough.
481 2012-08-08 15:50:47 <gigabird> Hi, I just read a miner source code (the one in the cotrib folder of bitcoin wallet called pyminer) and i saw that it was trying the nonce's in a sequential way, my q is that would checking the nonce's in a random-like way increase the our luck? how is this job done in modern miners like phoenix?
482 2012-08-08 15:50:55 <BlueMatt> osmosis: error looks like a corrupted wallet
483 2012-08-08 15:51:29 <gmaxwell> gigabird: in an actually random way would decrease performance. In a randomly ordered way would make no difference (other than the overhead from looking up the ordering rather than adding)
484 2012-08-08 15:52:18 <osmosis> BlueMatt, it came out of a encrypted archive with no decoding errors, so i doubt thats the case
485 2012-08-08 15:52:51 <gmaxwell> Db::open: Invalid argument
486 2012-08-08 15:52:55 <gmaxwell> it wasn't a clean backup.
487 2012-08-08 15:53:07 <gmaxwell> It's failing to open the database log files.
488 2012-08-08 15:53:12 <BlueMatt> maybe the block index is corrupt
489 2012-08-08 15:53:25 <gmaxwell> (assuming the error is wallet related at all)
490 2012-08-08 15:53:30 <osmosis> uhmm...i thought this was just about the wallet.dat
491 2012-08-08 15:53:45 <gmaxwell> osmosis: "this"?
492 2012-08-08 15:53:46 <gigabird> gmaxwell: thank you. so what if we learn from previous nonces? are they alike or completely random?
493 2012-08-08 15:53:52 <Eliel> osmosis: was the backup made by copying wallet.dat while bitcoin was running?
494 2012-08-08 15:53:52 <osmosis> this error
495 2012-08-08 15:53:58 <osmosis> the rest of the data files load fine with other wallet
496 2012-08-08 15:54:11 <osmosis> Eliel, i dont recall
497 2012-08-08 15:54:30 <Eliel> osmosis: if it was, that has a high chance to corrupt the wallet file.
498 2012-08-08 15:54:50 <Eliel> (the backup)
499 2012-08-08 15:55:02 <BlueMatt> gigabird: the result is effectively random based on the nonce (it is a cryptographic hash, after all)
500 2012-08-08 15:55:03 <gmaxwell> gigabird: They are completely radom.
501 2012-08-08 15:55:28 <Eliel> osmosis: I suggest trying wallet recovery tools
502 2012-08-08 15:55:34 <gmaxwell> osmosis: as I said it sounds like you managed to make a backup uncleanly (e.g. of a node that was running or not cleanly shut down)
503 2012-08-08 15:55:47 <gmaxwell> And its trying to use the db recovery logs, which you don't have.
504 2012-08-08 15:55:55 <BlueMatt> did you make the backup without the -detachdb option on a fairly-recent bitcoin?
505 2012-08-08 15:56:08 <gmaxwell> BlueMatt: you don't need detachdb for the wallet.
506 2012-08-08 15:56:12 <BlueMatt> (it would be really nice if we could just detach the wallet)
507 2012-08-08 15:56:17 <BlueMatt> oh, I thought you did...nevermind
508 2012-08-08 15:56:34 <gmaxwell> er. I really thought we did. crap. Now you have me doubting it!
509 2012-08-08 15:56:36 <gigabird> gmaxwell, BlueMatt: mmm.. i see..
510 2012-08-08 15:56:50 <BlueMatt> gmaxwell: I wouldnt know, I was just guessing
511 2012-08-08 15:56:57 <gmaxwell> Well I will coninue to believe we do, because I would have really opposed that change if it didn't.
512 2012-08-08 15:57:05 <osmosis> there are no coins in the wallet, so recovering this is just a drill
513 2012-08-08 15:57:22 <BlueMatt> gmaxwell: yea, makes sense, I would think others would have too
514 2012-08-08 16:02:34 <gigabird> is there any charts or graphs for founded nonces?
515 2012-08-08 16:04:02 <osmosis> Is there a known bug that when upgrading wallets, many transaction dates are replaced with the import date?  Thats what I am seeing.
516 2012-08-08 16:04:58 <sipa> gmaxwell, BlueMatt: wallet is always detached
517 2012-08-08 16:05:22 <MC-Eeepc> its funny cos whre i live, nonce is slang for a pederast
518 2012-08-08 16:05:39 <osmosis> transaction id on blockchain.info show  2012-01-08,  transaction in wallet import (different one this time), is show 8 Aug 2012.  No errors on -upgradewallet
519 2012-08-08 16:09:21 <gmaxwell> osmosis: the times on transactions show the time your node learned about the transaction.
520 2012-08-08 16:10:24 <osmosis> gmaxwell, is that information not saved in the wallet.dat? or only in newer wallet.dat's ?
521 2012-08-08 16:12:30 <gmaxwell> osmosis: it's in the wallets, but was that wallet saved before thos txn existed?
522 2012-08-08 16:12:55 <osmosis> gmaxwell, yes it was
523 2012-08-08 16:13:21 <gmaxwell> Well there you go then!
524 2012-08-08 16:14:03 <luke-jr> gigabird: generally, miners don't do them sequentially anymore
525 2012-08-08 16:14:19 <luke-jr> gigabird: often many nonces are tried in parallel
526 2012-08-08 16:14:47 <luke-jr> gigabird: also, most nonces found are lower, but not because lower has better chances
527 2012-08-08 16:14:58 <luke-jr> instead, it's because lower nonces get tested more ;)
528 2012-08-08 16:15:14 <gmaxwell> s/more/first/ really.
529 2012-08-08 16:20:50 <gigabird> luke-jr: thank you, What do you mean by 'because they get tested more' ?
530 2012-08-08 16:22:15 <osmosis> gmaxwell, actually..these are mostly transactions that were sent from the wallet. They are all missing their address label as well. wallet is from aug2011
531 2012-08-08 16:22:18 <luke-jr> gigabird: since miners start with 0 and go forward, lower numbers get tried sooner
532 2012-08-08 16:22:20 <Gladamas> gigabird: because the lower hash rate people mine only the first few nonces before they get more work
533 2012-08-08 16:24:16 <gigabird> luke-jr, Gladamas : oh, yes, you're right.. but luke-jr said founded nonce are lower. i dont get this why?
534 2012-08-08 16:24:36 <Gladamas> founded nonce?
535 2012-08-08 16:24:53 <Gladamas> found nonce?
536 2012-08-08 16:24:57 <gmaxwell> osmosis: if the wallet is from aug2011 then you won't know about transactions and labels from after that.
537 2012-08-08 16:25:14 <Gladamas> Because for the same reason, more low nonces are tested, so more blocks are found with a low nonce
538 2012-08-08 16:25:37 <Gladamas> every nonce has an equal chance of being a block
539 2012-08-08 16:25:43 <osmosis> gmaxwell, these are transactions that were sent from this actual wallet.
540 2012-08-08 16:28:15 <gmaxwell> osmosis: Yes, sent _after_ your backup was created.
541 2012-08-08 16:28:19 <gmaxwell> It isn't psychic!
542 2012-08-08 16:35:24 <osmosis> if I use bitcoin-0.5.4rc3-linux, wallet upgrade goes without an issue. No exception, no Db::open: Invalid argument, no core dump.
543 2012-08-08 16:37:51 <luke-jr> osmosis: at least use 0.5.6
544 2012-08-08 16:38:02 <devrandom> gmaxwell: BlueMatt: how should gitian NAKs work?  it seems that they should be retrieved from a source other than the main download site, since the people posting on the main site would have an incentive to exclude the NAKs
545 2012-08-08 16:38:12 <gmaxwell> osmosis: great, go bisect now and find the change that break it. :)
546 2012-08-08 16:39:00 <luke-jr> gmaxwell: you can't bisect 0.5.4rc3 with master :P
547 2012-08-08 16:39:05 <luke-jr> unless 0.5.6 is broken too? O.o
548 2012-08-08 16:39:20 <osmosis> luke-jr, 0.5.4 is what is available on http://sourceforge.net/projects/bitcoin/files/Bitcoin/
549 2012-08-08 16:39:25 <gmaxwell> devrandom: what we talked about was just having it poll all of N sites, and merge the results. Thats generally a good idea not considering NAKs in any case. To complete the security it would be useful if the threshold let you specify that N of M sites needed to respond.
550 2012-08-08 16:39:41 <osmosis> should I be pulling from github instead?
551 2012-08-08 16:39:53 <luke-jr> osmosis: well, nanotube should upload 0.5.6 <.<
552 2012-08-08 16:40:17 <gmaxwell> osmosis: I thought you started off reporting against git?
553 2012-08-08 16:40:19 <luke-jr> osmosis: if you can build from source, latest 0.5.x branch would be nice
554 2012-08-08 16:40:40 <luke-jr> gmaxwell: if he can reproduce with 0.5.x, it'll be easier to bisect
555 2012-08-08 16:40:56 <luke-jr> osmosis: git clone git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git -b 0.5.x
556 2012-08-08 16:40:56 <osmosis> gmaxwell, was just using bitcoin-0.6.3 before
557 2012-08-08 16:41:18 <gmaxwell> ah, sorry. My suggestion was based on assuming you were setup to build it already.
558 2012-08-08 16:42:48 <devrandom> gmaxwell: should polling be by HTTPS?  should we pin a specific certificate for each site?
559 2012-08-08 16:43:39 <gmaxwell> devrandom: That sounds like a very useful _option_. e.g. let the specification pin the cert if used.
560 2012-08-08 16:44:56 <gmaxwell> Someone connected with the tor project wrote a long academic paper on more secure automatic updates that addresses a lot of this stuff, I wish I could remember the name of the darn paper.
561 2012-08-08 16:44:59 <Parrot> hi there
562 2012-08-08 16:45:26 <Parrot> i checked the bitcoin api and cannot find the command to create a new bitcoin account in jsonrpc
563 2012-08-08 16:46:03 <gmaxwell> Parrot: getnewaddress [account] or assign an existing address to it.
564 2012-08-08 16:46:38 <Parrot> okay and [account] will be the new account name right ? and it will automatically create a new address then ?
565 2012-08-08 16:46:59 <BlueMatt> gmaxwell: maybe its linked somewhere here? http://www.cs.arizona.edu/stork/packagemanagersecurity/papers.html
566 2012-08-08 16:47:33 <gmaxwell> right, you don't 'create' accounts, you attach addresses to them either an existing address or a new one you've just created.
567 2012-08-08 16:48:04 <Parrot> another question. How can I delete an account with balance 0.00 ?
568 2012-08-08 16:48:41 <Parrot> attach all adresses to a new account ?
569 2012-08-08 16:48:48 <sipa> if you really have to
570 2012-08-08 16:49:00 <sipa> but the effect is almost nihil
571 2012-08-08 16:49:26 <Parrot> will these accounts still show up with a listaccounts command ?
572 2012-08-08 16:49:34 <Parrot> for now it's a real mess
573 2012-08-08 16:49:53 <sipa> i suppose they will
574 2012-08-08 16:50:22 <Parrot> ok this is just cosmetic but rather annoying when you have played with the api
575 2012-08-08 16:50:32 <devrandom> gmaxwell: sounds good
576 2012-08-08 16:51:53 <gmaxwell> devrandom: basically the idea is that even if ninjas assult the bitcoin developers conference and take sipa and gavin hostage and thats a critical mass for updates, that other people can kill the update before it does any/much damage.
577 2012-08-08 16:52:20 <gmaxwell> (or more realistically, exploits all the core devs by submitting a pull request with a malware makefile that we run before we notice it)
578 2012-08-08 16:52:31 <Parrot> now something strange i don't understand , when I list all the addresses of an account with "getaddressesbyaccount" and use "getaccountaddress" on this account , the latter does not show up in the getaddressesbyaccount list. How come ?
579 2012-08-08 16:53:23 <devrandom> gmaxwell: right
580 2012-08-08 16:54:10 <Graph_Theory> Hey
581 2012-08-08 16:54:21 <Graph_Theory> I am trying to get a Marketplace on bitcoinfans.com
582 2012-08-08 16:54:31 <Graph_Theory> where people can list items and servicces
583 2012-08-08 16:54:35 <Graph_Theory> and others can buy them
584 2012-08-08 16:54:41 <Graph_Theory> pay with bitcoins
585 2012-08-08 16:54:44 <Graph_Theory> then leave feedback
586 2012-08-08 16:55:08 <osmosis> following qt build instructions for unix, during make I get  src/headers.h:39:20: fatal error: db_cxx.
587 2012-08-08 16:55:22 <sipa> osmosis: install libdb++4.8-dev
588 2012-08-08 16:55:28 <sipa> or libdb++5.1-dev
589 2012-08-08 16:55:57 <Parrot> ok ignore my last question
590 2012-08-08 16:56:14 <luke-jr> osmosis: and then set BDB_INCLUDE_PATH to something useful
591 2012-08-08 16:56:19 <Parrot> what's annoying is that there is no way to remove unused accounts
592 2012-08-08 16:56:32 <Parrot> anyone here ?
593 2012-08-08 16:56:39 <sipa> no, sorry
594 2012-08-08 16:56:42 <osmosis> sipa, maybe libdb4.8-dev  on ubuntu 12.04
595 2012-08-08 16:56:51 <luke-jr> Parrot: if it were unused, it wouldn't be there in the first place
596 2012-08-08 16:57:14 <sipa> osmosis: libdb5.1++-dev
597 2012-08-08 16:57:25 <sipa> sorry, i swapped the 5.1 and the ++
598 2012-08-08 16:57:30 <luke-jr> osmosis: the Bitcoin PPA should have 4.8
599 2012-08-08 16:57:49 <Parrot> luke well I "played" with the thing and created accounts that I do not need.
600 2012-08-08 16:58:08 <Parrot> now i want to clear things up
601 2012-08-08 16:58:37 <osmosis> luke-jr, is it better I use the PPA then then libdb5.1++-dev ?
602 2012-08-08 16:59:00 <luke-jr> osmosis: 4.8 is what everything is tested with, and required for compatibility with other clients
603 2012-08-08 17:04:03 <Parrot> i tried to assign the existing address of an account to another account but the account is still there
604 2012-08-08 17:04:15 <Parrot> should i edit wallet.dat ?
605 2012-08-08 17:05:31 <sipa> if you have to, you can
606 2012-08-08 17:07:44 <Parrot> or shouls i create a new wallet.dat and transfer my funds to a new clean wallet.dat with only one account
607 2012-08-08 17:08:01 <sipa> that's possible too, but you'll lose the receive addresses in the new wallet
608 2012-08-08 17:08:02 <Parrot> it seems lame to me
609 2012-08-08 17:08:08 <sipa> unless you dump and re-import them
610 2012-08-08 17:08:48 <Parrot> if i make a new transfer i will lose some funds right
611 2012-08-08 17:08:52 <Parrot> the fees
612 2012-08-08 17:11:00 <sipa> if you have many small or recent coins
613 2012-08-08 17:12:43 <Parrot> what a mess
614 2012-08-08 17:29:07 <devrandom> gmaxwell: I just realized, you can't NAK a specific version, because the bad ninjas will keep releasing new versions and it will be difficult to keep up
615 2012-08-08 17:29:45 <devrandom> so what we really need is an "disable auto-updates" alert that is not version specific
616 2012-08-08 17:29:51 <devrandom> BlueMatt: ^^
617 2012-08-08 17:30:14 <gmaxwell> devrandom: Hm? No, you'll just keep naking them.
618 2012-08-08 17:30:34 <gmaxwell> Presumably if it's a real issue people will figure out how to be persistant with the naking.
619 2012-08-08 17:31:49 <gmaxwell> devrandom: probably where your problem is coming from is that you're not quarentining a new release? It should. e.g. mandatory X hour wait after the first seen ACK, to give time for the naks.
620 2012-08-08 17:32:55 <devrandom> I see
621 2012-08-08 17:33:38 <devrandom> what if bad ninjas serve different versions to different IPs?
622 2012-08-08 17:33:53 <gmaxwell> quarantining*
623 2012-08-08 17:35:11 <gmaxwell> Interesting thought. They put the keys online and every user gets a 'different' bad version.
624 2012-08-08 17:36:04 <BlueMatt> I still prefer to just require a higher % of sigs
625 2012-08-08 17:36:22 <BlueMatt> it simplifies it all and there are way fewer complicated attack scenarios
626 2012-08-08 17:37:03 <gmaxwell> BlueMatt: thats really orthorgonal. You can do both. The thinking with naks is "automatic updates should not be less secure than what we currently have"
627 2012-08-08 17:38:07 <devrandom> I'll bbl
628 2012-08-08 17:38:12 <gmaxwell> And right now one property of what we currently have is that 100% of the developers can be evil, put out a bad update... then before almost anyone deploys it because deployment is slow one diligent independant reviewer  can sound the alarm and prevent all or almost all of the harm.
629 2012-08-08 17:38:59 <BlueMatt> damn
630 2012-08-08 17:39:09 <BlueMatt> that should not be
631 2012-08-08 17:39:36 <BlueMatt> anyway...yea I agree the nak idea is certainly a cool one, and certainly makes sense in the way updates actually work
632 2012-08-08 17:41:00 <gmaxwell> NAKs also help with some kind of extortion.  "We've kiddnapped luke-jr and will kill him if all the developers don't sign our evil version" "Well, we can sign it, but there are 200 people who can kill the release, and we don't even know how to contact all of them"
633 2012-08-08 17:41:41 <BlueMatt> theres also the issue of rolling out releases that one person/group highly disagrees with
634 2012-08-08 17:41:44 <BlueMatt> (see: BIP16)
635 2012-08-08 17:41:49 <gmaxwell> "and besides, if we tell 200 people not to nak, and even if they all agree, it will leak and people will manually disable the autoupdater"
636 2012-08-08 17:42:24 <gmaxwell> I think BIP16 is actually a counter example for that concern.
637 2012-08-08 17:42:48 <gmaxwell> And the worst case is, of course, someone kills the autoupdate.. so a manual update is required for people to go forward. Not the end of the world.
638 2012-08-08 17:43:07 <BlueMatt> but maybe just a ton more transparency in the update window also solves some of the issues: list who has signed the given release, etc
639 2012-08-08 17:43:24 <BlueMatt> +do your peers have this update
640 2012-08-08 17:44:35 <gmaxwell> Also, randomly delaying it.. e.g. minimum 24 hour delay, up to X days delay randomly.. so even if a version is a trap there is time for the news to spread and people to abort the update.  I guess these things don't depend on NAKs being formally supported.
641 2012-08-08 17:44:45 <BlueMatt> yea
642 2012-08-08 17:45:59 <gmaxwell> though, yea, they would do better with a high threshold shut off updates killswitch.. because sometimes people are asleep at the switch. Maybe just a new update kills any pending ones and restarts the timer.
643 2012-08-08 17:46:40 <gmaxwell> So if there is a fight between keyholders (e.g. due to a compromised key) they can delay updates for as long as it takes to get people to manually update to an non-compromised keyset.
644 2012-08-08 17:48:19 <sipa> who had the alert key apart from satoshi and gavin?
645 2012-08-08 17:48:29 <sipa> was it theymos or tcatm?
646 2012-08-08 17:50:03 <BlueMatt> theymos
647 2012-08-08 17:52:09 <sipa> what i thought
648 2012-08-08 17:53:51 <gmaxwell> BlueMatt: even stupidly large delays like 1-2 weeks are way better than having no autoupdate.
649 2012-08-08 17:54:31 <BlueMatt> gmaxwell: true, but I dont think that would be the way to go...
650 2012-08-08 17:55:54 <BlueMatt> devrandom: anyway, the first step to a few of these updates is to do an intermediate step in gitian-downloader: first download-only and check sigs, then popup the update window then actually update
651 2012-08-08 17:56:18 <BlueMatt> could do it manually in bitcoin, but its cleaner to let gitian-updater do that imho
652 2012-08-08 17:56:20 <gmaxwell> BlueMatt: Conservative is good.  There is really no hope of using something like this for a warhol warm type situation it wouldn't be fast enough to help, and making the updates very fast has a lot of risk.
653 2012-08-08 17:57:09 <BlueMatt> absolutely, but for other issues, it should be reasonably fast enough
654 2012-08-08 17:58:52 <BlueMatt> so I guess in the intermediary, until more thought is pured into formal nak support, updates should be quarantined, and the update process should be made more verbose
655 2012-08-08 17:59:31 <gmaxwell> Well whats the purpose of autoupdates?  I'd still generally prefer users update manually when they're willing and able: They'll give better issue feedback that way, an update is less likely to catch them by surprise and interupt their operations.   My thinking is that there are two purposes:
656 2012-08-08 17:59:50 <gmaxwell> (1) get users who are updating manually cryptographically authenticated copies to install.
657 2012-08-08 18:00:06 <gmaxwell> (2) not leave the network running old versions in large numbers for months/years.
658 2012-08-08 18:00:19 <BlueMatt> agreed
659 2012-08-08 18:01:11 <sipa> i suppose we can have a policy not to push/publish the autoupdate data until 1 week after the actual release
660 2012-08-08 18:01:43 <gmaxwell> Neither of these need automatic updates to self-apply quickly. E.g. XXX hours hidden from the user, then one to two weeks  of manually triggered only would hit those points.
661 2012-08-08 18:01:59 <gmaxwell> sipa: if we don't then many users will manually download from sourceforge and get insecure versions.
662 2012-08-08 18:02:09 <gmaxwell> because they won't bother with the gpg sig checking.
663 2012-08-08 18:02:15 <sipa> right
664 2012-08-08 18:02:35 <gmaxwell> (We know for a fact that they don't already)
665 2012-08-08 18:02:38 <Eliel> you could also just have the old version show a notice of the new version and a short description of the changes once the new version has enough signatures (and add a warning if someone has nacked it)
666 2012-08-08 18:02:52 <BlueMatt> you would have that problem either way if you delay the update
667 2012-08-08 18:02:54 <Eliel> along with a button to download and install it if desired.
668 2012-08-08 18:02:57 <BlueMatt> (in-client or in policy)
669 2012-08-08 18:03:09 <gmaxwell> You'd make it available but give no notice.
670 2012-08-08 18:03:49 <Eliel> since bitcoin already has ecdsa encryption built-in, it would make sense to use that.
671 2012-08-08 18:03:59 <gmaxwell> Then after a delay you give a notice, make it more obviously available for manual update.. Then after another delay you install automatically. (if that isn't disabled)
672 2012-08-08 18:04:05 <sipa> ecdsa is not encryption :)
673 2012-08-08 18:04:21 <Eliel> sipa: just signatures?
674 2012-08-08 18:04:25 <sipa> yes
675 2012-08-08 18:04:40 <Eliel> ok, I stand corrected. But that's all this needs :)
676 2012-08-08 18:04:57 <luke-jr> gmaxwell: I'm so dead :<
677 2012-08-08 18:04:59 <BlueMatt> we already use gitian for build process, there is no reason not to use it for updates
678 2012-08-08 18:05:06 <gmaxwell> luke-jr: hahah
679 2012-08-08 18:05:53 <sipa> luke-jr: as soon as you claim to have given up your beliefs, we know you're held hostage ;)
680 2012-08-08 18:06:08 <luke-jr> sipa: I would never do that.
681 2012-08-08 18:06:24 <sipa> that's why :)
682 2012-08-08 18:06:37 <luke-jr> sipa: even if I were held hostage.
683 2012-08-08 18:06:47 <sipa> ok
684 2012-08-08 18:06:59 <Graph_Theory> hey guys
685 2012-08-08 18:07:18 <luke-jr> sipa: it's possible you'd hear about me being killed for refusal to do that though :p
686 2012-08-08 18:07:25 <luke-jr> (but not likely I hope)
687 2012-08-08 18:08:02 <nanotube> luke-jr: is 0.5.6 out, and gitian-signed by several builders?
688 2012-08-08 18:08:26 <luke-jr> nanotube: well, it's just the last RC renamed :P
689 2012-08-08 18:08:33 <Graph_Theory> can anyone in here mod a php marketplace
690 2012-08-08 18:08:38 <Graph_Theory> for it to accept bitcoins
691 2012-08-08 18:08:48 <Graph_Theory> instead of regular paymetn
692 2012-08-08 18:08:49 <luke-jr> nanotube: shall I re-zip it for uploading?
693 2012-08-08 18:08:50 <Graph_Theory> *payment
694 2012-08-08 18:10:57 <sipa> Graph_Theory: ask in #bitcoin-otc or in the marketplace
695 2012-08-08 18:11:25 <Graph_Theory> thanks
696 2012-08-08 18:45:25 <Graph_Theory> anyone in here interested in being admin and helping set up the forum
697 2012-08-08 18:45:36 <midnightmagic> sipa: at one point you had a wallet dumper which dumped even unseen addresses from a wallet into a format which could then be imported. currently I only see per-address dump and import. Was there a reason why the full wallet-dump wasn't brought in also? Or am I just missing the option and all I need is a wildcard somewhere?
698 2012-08-08 18:45:38 <Graph_Theory> im also looking for admins
699 2012-08-08 18:45:40 <Graph_Theory> for http://www.bitcoinfans.com/forums/
700 2012-08-08 18:45:48 <Graph_Theory> and ppl who can suggest categories they want to see
701 2012-08-08 18:46:11 <BlueMatt> Graph_Theory: seriously? you dont need to advertise every couple hours, and you dont need to fill everyone's screen with 5 lines each time
702 2012-08-08 18:46:38 <luke-jr> lol
703 2012-08-08 18:48:51 <sipa> midnightmagic: there were some problems with it still, at the time
704 2012-08-08 18:49:19 <sipa> midnightmagic: and i kinda neglected finishing it afterwarfs
705 2012-08-08 18:49:54 <midnightmagic> sipa: doh.
706 2012-08-08 18:50:17 <sipa> i suppose i still have a branch lying around
707 2012-08-08 18:50:37 <midnightmagic> sipa: What were the issues if you recall?
708 2012-08-08 18:51:20 <sipa> it had some logic to avoid rescanning too much, but at some point i realized therr were some cases where it would fail
709 2012-08-08 18:51:29 <midnightmagic> sipa: I seem to recall there was at one point a bit of a rough edge on different forms of keys, compressed and so on but I thought you fixed that. Was someone complaining about whether other wallet information should also be dumped or something?
710 2012-08-08 18:51:33 <midnightmagic> ah I see..
711 2012-08-08 18:51:52 <sipa> i can't remember the details, but i suppose i'd simplify things now if i would finish it
712 2012-08-08 19:18:44 <Graph_Theory> I set up software discussion board on http://bitcoinfans.com/forums/
713 2012-08-08 19:19:04 <Graph_Theory> Wanna see a particular category or forum? Register and let us know!
714 2012-08-08 19:19:10 <t7> are there any articles criticising the bitcoin source code/implementation?
715 2012-08-08 19:20:32 <luke-jr> t7: #bitcoin-dev isn't enough? :P
716 2012-08-08 19:21:45 <denisx> luke-jr: do you know if the patch from crypticmonkey for getworkex is compatible with getmemorypool?
717 2012-08-08 19:22:25 <jgarzik> denisx: <interested> what is getworkex? url?
718 2012-08-08 19:23:04 <denisx> jgarzik: https://github.com/CryptoManiac/pushpool/commit/980161e1b7e420d61e4b491adf0df5035dfcb658
719 2012-08-08 19:23:29 <denisx> jgarzik: he uses getworkex, but bitcoind has no getworkex
720 2012-08-08 19:23:37 <denisx> and his repos are all 404
721 2012-08-08 19:24:00 <denisx> his bitcoind clones
722 2012-08-08 19:26:05 <denisx> uh, his name is cryptomaniac and not crypticmonkey ;)
723 2012-08-08 19:28:51 <makomk> jgarzik: I think getworkex is one of my bits of code. It's another way to allow mining pools to modify the coinbase transaction that's designed to be relatively similar to getwork.
724 2012-08-08 19:29:13 <denisx> makomk: good to know
725 2012-08-08 19:29:44 <makomk> Basically you get the coinbase transaction and the merkle branch leading up to it and can submit a modified coinbase transaction with your block.
726 2012-08-08 19:30:34 <denisx> makomk: with getmemorypool?
727 2012-08-08 19:32:24 <makomk> denisx: nope, with getworkex. getmemorypool gives you a list of transactions and expects you to build your own coinbase transaction, make a block out of the transactions, and submit the entire block.
728 2012-08-08 19:32:54 <denisx> makomk: is there something compatible to getworkex in bitcoind?
729 2012-08-08 19:33:07 <denisx> I also have no problem with patching bitcoind
730 2012-08-08 19:33:17 <sipa> getworkex could be written on top of getmemorypool
731 2012-08-08 19:33:40 <denisx> is there some page describing getworkex?
732 2012-08-08 19:35:09 <luke-jr> denisx: what uses getworkex? :p
733 2012-08-08 19:35:22 <denisx> luke-jr: the link above from me
734 2012-08-08 19:35:24 <luke-jr> bitcoind doesn't really work for mining
735 2012-08-08 19:36:07 <denisx> luke-jr: for me it does
736 2012-08-08 19:36:09 <luke-jr> looks kinda like getworkex is some non-standard alternate for getmemorypool and BIP22
737 2012-08-08 19:37:32 <denisx> luke-jr: I mean I use a pushpoold which gets the work from bitcoind
738 2012-08-08 19:37:47 <denisx> I use bitcoind not directly for mining
739 2012-08-08 19:39:33 <osmosis> luke-jr, for the build from your 0.5.6 tree, an exception does occurs for the older wallet import.
740 2012-08-08 19:40:05 <luke-jr> osmosis: OK, are you familiar with git bisect?
741 2012-08-08 19:40:48 <osmosis> nope
742 2012-08-08 19:42:01 <luke-jr> osmosis: git bisect start v0.5.6 v0.5.4rc3
743 2012-08-08 19:42:14 <luke-jr> osmosis: git will pick out a version for you to test; build and test it
744 2012-08-08 19:42:25 <luke-jr> when you are 100% certain whether it works or not, use "git bisect good" or "git bisect bad"
745 2012-08-08 19:42:31 <luke-jr> git will give you another one to test
746 2012-08-08 19:42:46 <luke-jr> repeat until it's happy, then it will tell you what caused the bug
747 2012-08-08 19:42:52 <osmosis> ok
748 2012-08-08 19:45:00 <makomk> denisx: I keep meaning to port the pushpool version that uses getworkex to getmemorypool, but...
749 2012-08-08 19:47:03 <denisx> makomk: yes, but?
750 2012-08-08 19:47:19 <luke-jr> but why not just use Eloipool? :P
751 2012-08-08 19:47:48 <denisx> luke-jr: because I have my own pool
752 2012-08-08 19:47:56 <luke-jr> denisx: and?
753 2012-08-08 19:48:38 <denisx> luke-jr: your pool is in python?
754 2012-08-08 19:48:52 <luke-jr> denisx: yes
755 2012-08-08 19:48:54 <luke-jr> for now
756 2012-08-08 19:48:55 <makomk> But time, effort, debugging, spectacular disorganisational skills...
757 2012-08-08 19:48:58 <luke-jr> might port to C++ someday
758 2012-08-08 19:48:59 <denisx> too slow for me
759 2012-08-08 19:49:06 <luke-jr> denisx: Python isn't that slow :p
760 2012-08-08 19:49:15 <luke-jr> performs far better than pushpool at least
761 2012-08-08 19:49:20 <luke-jr> or rather, bitcoind
762 2012-08-08 19:50:02 <denisx> luke-jr: I don't think so
763 2012-08-08 19:50:28 <luke-jr> denisx: I only wrote it because pushpool/bitcoind wasn't keeping up :p
764 2012-08-08 19:50:54 <denisx> luke-jr: how many getworks can your eloipool handle per second?
765 2012-08-08 19:50:55 <osmosis> hmm..appears im on a revision where qmake/make  doesnt work anymore
766 2012-08-08 19:51:14 <luke-jr> denisx: depends on CPU
767 2012-08-08 19:52:23 <luke-jr> denisx: I have Eligius configured for up to 0x20000 bursts
768 2012-08-08 19:52:32 <denisx> makomk: is there some docu where I can see how getworkex looks like?
769 2012-08-08 19:53:48 <denisx> luke-jr: 131072 getworks/sec?
770 2012-08-08 19:54:04 <luke-jr> denisx: that's the burst I have configured, yes
771 2012-08-08 19:54:24 <sipa> 131072 getworks, or per second?
772 2012-08-08 19:54:25 <luke-jr> looks like the server finishes it in about 0.6 seconds
773 2012-08-08 19:54:45 <denisx> without delivering it I assume?
774 2012-08-08 19:54:50 <luke-jr> so about 200,000 max I suppose
775 2012-08-08 19:54:55 <luke-jr> denisx: yeah, delivery takes a bit
776 2012-08-08 19:55:00 <denisx> this is only generating
777 2012-08-08 19:55:14 <luke-jr> 2012-08-08 21:12:00,026 JSONRPCServer   INFO    Longpoll woke up 21308 clients in 7.725 seconds
778 2012-08-08 19:55:35 <makomk> denisx: I'm afraid the code is the documentation for getworked, which is one reason why no-one uses it. The Bitcoin side's in https://github.com/makomk/bitcoin/tree/poolserv-work-gen
779 2012-08-08 19:56:22 <luke-jr> makomk: should update it to use BIP 22, since getmemorypool is about to go away ;p
780 2012-08-08 20:03:20 <osmosis> luke-jr, not sure how to proceed on older rev, make: *** No rule to make target `bitcoin-qt.pro
781 2012-08-08 20:04:00 <sipa> which command line do you use to build?
782 2012-08-08 20:04:22 <luke-jr> osmosis: git bisect skip
783 2012-08-08 20:04:28 <osmosis> was just using   qmake; make;
784 2012-08-08 20:12:53 <Graph_Theory> News of the day: Everyone hates http://www.bitcoinfans.com
785 2012-08-08 20:13:16 <sipa> can you please stop?
786 2012-08-08 20:13:48 <sipa> this channel is not for advertizing websites, it is about the development of bitcoin clients
787 2012-08-08 20:17:12 <t7> no posts at all
788 2012-08-08 20:18:06 <sipa> i don't object to people linking to interesting stuff, but please don't keep advertizing something
789 2012-08-08 20:18:58 <t7> sipa am i right in thinking there is less than 1 transaction a second on the network?
790 2012-08-08 20:19:24 <t7> if so my crappy ECDSA code should be quick enough :)
791 2012-08-08 20:20:01 <osmosis> luke-jr,   they all failed, never got one that worked.  git returned, 1f56046fd529c0ef9e35d26d68995c497751c54f is the first bad commit
792 2012-08-08 20:20:06 <BlueMatt> t7: you only get 1/sec?
793 2012-08-08 20:20:13 <BlueMatt> and I thought bitcoinj was bad
794 2012-08-08 20:20:19 <t7> no a bit more than that lol
795 2012-08-08 20:20:28 <sipa> t7: which language?
796 2012-08-08 20:20:32 <t7> haskell
797 2012-08-08 20:21:05 <sipa> based on purecoin?
798 2012-08-08 20:21:09 <t7> i would have used roconner's Purecoin but the code isnt very readable/maintainable
799 2012-08-08 20:21:21 <BlueMatt> its haskell...
800 2012-08-08 20:21:21 <t7> nah i implemented from a paper online
801 2012-08-08 20:21:42 <sipa> haskell can be very readable or very obscure :)