1 2013-08-05 02:49:32 <thestringpuller> is there a libcoin?
2 2013-08-05 02:51:47 <amiller> thestringpuller, there is, yes
3 2013-08-05 02:51:49 <amiller> https://github.com/libcoin/libcoin
4 2013-08-05 02:51:55 <amiller> thestringpuller, i wonder if there was more to your question?
5 2013-08-05 02:52:08 <nsh> however it occasionally explodes and kills all nearby livestock
6 2013-08-05 02:52:20 <nsh> and you can't use it in arid, landlocked countries
7 2013-08-05 02:52:31 <thestringpuller> uhhhh
8 2013-08-05 02:53:07 <thestringpuller> I just need is a generate address function.
9 2013-08-05 02:53:34 <nsh> in what language?
10 2013-08-05 02:54:04 <thestringpuller> C
11 2013-08-05 02:54:36 <thestringpuller> like libc but for btc...i'm bad with coding words sorry
12 2013-08-05 02:55:12 <amiller> https://github.com/amiller/cbitcoin/blob/master/examples/addressGenerator.c
13 2013-08-05 02:55:53 <amiller> thestringpuller, you might like using cbitcoin, it's not totally complete but it does have the advantage of being really small and compiles fast and very few other dependenices
14 2013-08-05 02:57:35 <Luke-Jr> http://bit-bit.yzi.me/theforum/learn-about-the-lendcoin-sytem/the-lendcoin-sytem/ <-- is it just me, or is this guy trying to do something impossible? :x
15 2013-08-05 02:58:42 <thestringpuller> thanks amiller
16 2013-08-05 03:04:26 <amiller> Luke-Jr, "The ability to give a loan without the risk of loosing the principle loan amount while also guaranteeing a profit on the principle" <- yeah, seems like it violates some kind of conservation law, like perpetual motion
17 2013-08-05 03:05:40 <amiller> "lending" in the sense of ripple doesn't count, because you're basically formalizing relationships with people who you know or trust for some other reason, typically you're using that relation as collateral
18 2013-08-05 03:06:11 <Luke-Jr> well, in theory, you could have a system generate coins to cover losses; but it'd be easily scammed
19 2013-08-05 03:07:09 <amiller> yeah, so an altcoin that formalizes the approach to risk management of "privatize the gains, socialize the losses"
20 2013-08-05 03:23:58 <nsh> amiller, it's perfectly possible to do that
21 2013-08-05 03:24:07 <nsh> you just fuck the entire economy up
22 2013-08-05 03:24:29 <nsh> (yes, there is a conservation effect with respect to risk)
23 2013-08-05 03:25:03 <nsh> what happened in the crash was an effort to distribute that risk wider and wider until it was paper thin but ubiquitous
24 2013-08-05 04:46:38 <Hadaka> hello! what is the status of bitcoin v0.9? is the preliminary source code viewable somewhere? (bitcoin/bitcoin on github didn't seem to have it) and relating to that, what is the status of BIP-70?
25 2013-08-05 04:48:20 <gmaxwell> Hadaka: bitcoin/bitcoin on github is the current work in progress code.
26 2013-08-05 04:49:41 <Hadaka> gmaxwell: it doesn't seem to have any major changes as far as I can see (still reading through to 0.8.3...)
27 2013-08-05 04:50:36 <gmaxwell> 0.8.3 was not released very long ago.
28 2013-08-05 04:51:55 <Diablo-D3> http://online.wsj.com/article/SB10001424127887323997004578644491403250124.html
29 2013-08-05 04:52:34 <Hadaka> okay, well, the reason I'm here is that the web is full of "bitcoin v0.9 will add this and that" - but is that only article editors going bonkers, or have some choices already been made and code written to that effect?
30 2013-08-05 04:53:28 <Hadaka> like: http://bitcoinexaminer.org/bitcoin-v0-9-release-will-bring-new-features-for-merchants/
31 2013-08-05 04:54:16 <gmaxwell> Other than the payment protocol, AFAIK nothing that isn't in already is slated to be in 0.9. (of course, other things will go in)
32 2013-08-05 04:54:29 <gmaxwell> Hadaka: are you specifically looking for the payment protocol stuff?
33 2013-08-05 04:55:35 <Hadaka> gmaxwell: well yeah, if that's one big chunk that contains everything
34 2013-08-05 04:56:02 <gmaxwell> Hadaka: https://github.com/bitcoin/bitcoin/pull/2539
35 2013-08-05 04:57:24 <Hadaka> gmaxwell: thanks!
36 2013-08-05 05:01:17 <Hadaka> hmmh, actually, is any of the payment request stuff visible in the block chain in any way? is this purely a client feature?
37 2013-08-05 05:04:12 <gmaxwell> no, it has no blockchain implications, ??? which is part of the point.
38 2013-08-05 05:04:28 <gmaxwell> If the blockchain is involved you get all the related privacy and scalablity challenges that come with that.
39 2013-08-05 05:05:21 <Hadaka> right, well that also explains why BIP-70 can still be draft when the implementation is going in soon - if it's all client stuff, it can be changed and improved at will and it doesn't really matter that others do not implement it yet
40 2013-08-05 05:07:16 <Hadaka> thanks, this has been very helpful!
41 2013-08-05 05:09:31 <Luke-Jr> Hadaka: X.509 isn't used at all for transactions like this article claims
42 2013-08-05 05:10:07 <Luke-Jr> or is poorly worded to claim
43 2013-08-05 05:10:23 <Hadaka> Luke-Jr: yeah, reading the BIP with some though clarified things a lot
44 2013-08-05 05:10:56 <Luke-Jr> Add to this the ability to provide a refund address to the act of paying, <-- hmm, I missed that testing Gavin's code; is it transparent from the keypool?
45 2013-08-05 05:11:58 <Hadaka> Luke-Jr: also, the article states that receipts will be signed - but I didn't find any signatures on the receipts in the BIP?
46 2013-08-05 05:12:40 <Luke-Jr> Hadaka: I'm not sure there would be a purpose to signing the receipt.
47 2013-08-05 05:12:53 <Luke-Jr> Hadaka: the transaction still needs to confirm in the blockchain before it's truly accepted
48 2013-08-05 05:14:30 <Hadaka> Luke-Jr: hmmh, yeah, with bitcoin maybe it doesn't matter as the transaction outcome is the real outcome on the basis of which disputes can be handled
49 2013-08-05 05:18:02 <Hadaka> oh, since I'm here - I've been wondering about bitcoin POS transactions, especially after reading https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation
50 2013-08-05 05:19:18 <Hadaka> but, for POS to be feasible, the actual transaction processing time must be less than 10 seconds - or 1-3 seconds to be competitive with current methods - or to be *really* competitive, it needs to allow offline, but that's a different can of worms
51 2013-08-05 05:20:21 <Hadaka> but, are such speeds like 1-3 seconds feasible with transactions? if a lot of the POS transactions were with bitcoin, does it scale to those transaction speeds?
52 2013-08-05 05:22:14 <gmaxwell> it's not clear what you mean by processing. You can't 1:1 map these things.
53 2013-08-05 05:23:16 <gmaxwell> Bitcoin transactions??? the registering of a provable intent to pay??? are instant (just however long it takes you to send the payee a few hundred bytes of data), but if the payer is malicious those payments could be reversed.
54 2013-08-05 05:23:30 <gavinandresen> Luke-Jr: yes, the refund address comes from the keypool. The code uses one refund address per merchant, and arranges things so that if you receive a refund it is properly labelled but otherwise doesn't appear in your address book /etc
55 2013-08-05 05:24:03 <gmaxwell> Likewise credit card payments can be reversed once authorized. The curvature of security vs time in each of the cases depends on what you are doing and what your risk tolerance is.
56 2013-08-05 05:25:50 <gavinandresen> speaking of point of sale transactions??? anybody actively working on "first double spend" detection / broadcast ?
57 2013-08-05 05:31:07 <tgs3_whooosh> guys
58 2013-08-05 05:31:20 <tgs3_whooosh> firefox 17 is compromised (by FBI) - popular version !
59 2013-08-05 05:31:38 <tgs3_whooosh> look into it. Any devels (with git access / signing etc) uses it on same desktop on which you sign?
60 2013-08-05 05:34:08 <Hadaka> gmaxwell: okay, yeah - what I mean by processing is basically that double-spending race attack is unlikely to succeed - the other attacks are probably not of real significance
61 2013-08-05 05:35:41 <Hadaka> "After a head start of merely several seconds, the original transaction would reach so much of the Bitcoin network that a fraudulent double-spend transaction would almost certainly be fruitless."
62 2013-08-05 05:37:26 <Luke-Jr> tgs3_whooosh: what file/line of code?
63 2013-08-05 05:38:17 <midnightmagic> Luke-Jr: it's just http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1690
64 2013-08-05 05:39:19 <Luke-Jr> looks like I already have the fix
65 2013-08-05 05:40:18 <tgs3_whooosh> Luke-Jr: the 0day that fbi used
66 2013-08-05 05:40:31 <Luke-Jr> tgs3_whooosh: and was fixed 6 months ago
67 2013-08-05 05:40:47 <midnightmagic> tgs3_whooosh: it's an old exploit and STOP CALLING IT A 0DAY
68 2013-08-05 05:41:16 <nsh> see: https://bugzilla.mozilla.org/show_bug.cgi?id=901365
69 2013-08-05 05:41:38 <midnightmagic> also http://www.mozilla.org/security/announce/2013/mfsa2013-53.html
70 2013-08-05 05:41:47 <tgs3_whooosh> midnightmagic: Im repeating after slashdot, myself I do not know yet. thanks for links
71 2013-08-05 05:42:09 <nsh> well, it's understandable to call it an 0day for the tor browser bundle as it was the latest version and not expected
72 2013-08-05 05:43:00 <nsh> and nightly builds of at least one branch of FF vulnerable. so, bobbing bug maybe. dunno what the term people use is
73 2013-08-05 05:43:05 <midnightmagic> It's only a 0day if it's analyzed and verified new by somekne. If you can't find an actual analysis of it, then please mock upstream people calling it 0day especially slashdot and demand an analysis.
74 2013-08-05 05:43:31 <nsh> ACTION nods
75 2013-08-05 05:44:45 <midnightmagic> nsh: The only thing I'm not clear on is whether the stable TBB is vuln. I know it's fixed in 3.0-dev branch but..
76 2013-08-05 05:46:16 <nsh> Last-Modified: Wed, 26 Jun 2013 21:34:29 GMT
77 2013-08-05 05:46:16 <nsh> q@Qbox:~$ curl -s -D - https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-i686-2.3.25-10-dev-en-US.tar.gz.asc | grep 'Last-Mod'
78 2013-08-05 05:46:37 <nsh> that's the sig of the main TBB download from https://www.torproject.org/download/download-easy.html.en
79 2013-08-05 05:46:55 <nsh> which would suggest it's not fixed. the mitigation suggest atm is "disable javascript"
80 2013-08-05 05:47:04 <nsh> so things aren't really in what i'd call an ideal state yet :)
81 2013-08-05 05:47:13 <midnightmagic> nsh: or uod. to dev branch i guess.
82 2013-08-05 05:47:19 <nsh> right
83 2013-08-05 05:47:49 <midnightmagic> meh, all i want is my mail from tormail.. i never did bother to download it all.
84 2013-08-05 05:48:34 <nsh> someone successfully logged into tormail a few hours ago
85 2013-08-05 05:48:42 <tgs3_whooosh> JS should be always disabled anyway, for anytihng to do with security of browsing...
86 2013-08-05 05:48:58 <tgs3_whooosh> nsh: FBI run honeypot now?
87 2013-08-05 05:49:01 <nsh> [Now-9h] <AnonUser008> successfully signed in to tormail via squirrel
88 2013-08-05 05:49:08 <midnightmagic> it's vaccilating between 404 and a login'able host. possible poorman failover
89 2013-08-05 05:49:29 <nsh> tgs3_whooosh, hard to establish trust again, there's no message on tormail.org which presumably would be unaffected by the raid
90 2013-08-05 05:49:46 <nsh> you could email admin@* but i wouldn't expect too timely a response atm
91 2013-08-05 05:49:47 <tgs3_whooosh> so tormail == FH or not?
92 2013-08-05 05:49:55 <nsh> only the web frontend was hosted on FH
93 2013-08-05 05:49:59 <midnightmagic> tgs3_whooosh: who cares, if they deliver mail, then everyone should be fine be ause everyone encrypts their mail so tormail can't read it rigt?
94 2013-08-05 05:50:01 <nsh> not the mailboxes or the clearnet domain
95 2013-08-05 05:50:16 <nsh> *onion frontend
96 2013-08-05 05:50:49 <tgs3_whooosh> midnightmagic: basically yes, but time of logging in, and who communicates who are important things too
97 2013-08-05 05:51:11 <midnightmagic> all presumed on a lijely honeypot anyway
98 2013-08-05 05:53:13 <midnightmagic> so nice of the FBI to deliver my encrypted emails and obfuscate my sendig address for me. :-)
99 2013-08-05 05:56:00 <nsh> aye, they're good lads
100 2013-08-05 06:31:37 <nsh> (just realised i was talking crack earlier, the latest download is patched against the onreadystate vulnerability: https://blog.torproject.org/blog/new-tor-browser-bundles-and-tor-02414-alpha-packages and http://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html )
101 2013-08-05 06:38:09 <BlueMatt> Luke-Jr: pull-tester *does* reproduce the may 15 hardfork
102 2013-08-05 06:39:07 <nsh> oh?
103 2013-08-05 06:42:16 <Luke-Jr> BlueMatt: I mean with a new block
104 2013-08-05 07:03:53 <JyZyXEL> i think tor browser bundle has javascript disabled by default and then you can choose to enable it per site basis
105 2013-08-05 07:07:16 <nsh> thinking is a poor substitute for knowing. (it's enabled by default in the bundled firefox and the noscript has javascript globally allowed by default)
106 2013-08-05 07:42:59 <n0ttgr> why can't we create a special type of transaction which takes as its input, a fraud proof (proof that a transaction was double-spent) along with the reference of the unspent outputs resulting from the double-spend, and sends the value to miners
107 2013-08-05 07:43:06 <n0ttgr> could deter double-spends by making them uneconomical
108 2013-08-05 07:43:11 <n0ttgr> because they can always be proven?
109 2013-08-05 07:47:20 <random_cat> too much glue, nsh. put down the tube
110 2013-08-05 07:56:21 <Luke-Jr> n0ttgr: some "double spends" are by design
111 2013-08-05 07:58:08 <Luke-Jr> n0ttgr: that being said, the merchant could theoretically do something like that
112 2013-08-05 07:58:45 <Luke-Jr> by spending their coin to 100% fee, and the miners running code that prefers such arrangements
113 2013-08-05 10:01:07 <bloke> amount of bandwidth bitcoind uses?
114 2013-08-05 10:01:07 <bloke> I am running a mining pool, and bitcoind is using up a lot of bandwidth (due to inbound connections I think). If I block port 8333 (i.e. with a firewall), that will stop all inbound connections. Will that interfere with the ability of bitcoind to work in this (mining pool) situation? (I've tested a bit on testnet, and it seems like it still works fine). Is there a better way to limit the
115 2013-08-05 10:01:36 <BlueMatt> limit connection count instead
116 2013-08-05 10:01:51 <bloke> this isn't "maxconnections" though, is it?
117 2013-08-05 10:02:04 <sipa> it is
118 2013-08-05 10:02:08 <bloke> oh
119 2013-08-05 10:02:14 <bloke> whats the default, 8 ?
120 2013-08-05 10:02:16 <bloke> max?
121 2013-08-05 10:02:25 <sipa> the default is 125 iirc
122 2013-08-05 10:02:26 <BlueMatt> 125 or something
123 2013-08-05 10:02:30 <bloke> inbound?
124 2013-08-05 10:02:31 <bloke> ok
125 2013-08-05 10:02:33 <sipa> total
126 2013-08-05 10:02:38 <bloke> Right. Thanks for that
127 2013-08-05 10:02:39 <sipa> there's always max 8 outbound
128 2013-08-05 10:02:40 <BlueMatt> outbound is always 8
129 2013-08-05 10:02:42 <bloke> right
130 2013-08-05 10:02:50 <sipa> but it's mostly inbound connections that consume bandwidth
131 2013-08-05 10:03:00 <bloke> ok, thats what i suspected
132 2013-08-05 10:06:03 <sipa> also, as a mining pool, you probably want many connections, as it means probably slightly faster block propagation
133 2013-08-05 10:06:27 <BlueMatt> so, essentially, stop trying to run a pool on a connection that doesnt have enough bandwidth
134 2013-08-05 10:06:33 <bloke> fair enough
135 2013-08-05 12:07:07 <BSaboia> guys, what is the exact purpouse of mining? i mean, what they do with the hashes? is the computational power required for finding a 'good' hash used to anything other than to mine bitcoins itself?
136 2013-08-05 12:11:18 <michagogo> BSaboia: Nope.
137 2013-08-05 12:12:10 <michagogo> BSaboia: Bitcoin mining has no purpose, no gain, no benefit whatsoever outside of bitcoin itself
138 2013-08-05 12:12:20 <BSaboia> michagogo, i see
139 2013-08-05 12:12:57 <phantomcircuit> bitcoin was really designed by the oil industry to consume electricity
140 2013-08-05 12:13:00 <phantomcircuit> bwahahahah
141 2013-08-05 12:13:14 <michagogo> lol
142 2013-08-05 12:13:18 <BSaboia> lol
143 2013-08-05 12:13:34 <BSaboia> michagogo, i remember that back in 1998 or something, i had a nasa screenserver that used my idle power to do some calculations. back then, i thought it was a very nice idea
144 2013-08-05 12:13:52 <BSaboia> i thought that bitcoins used this for generating some kind of value outside the bitcoin world...
145 2013-08-05 12:13:55 <michagogo> BSaboia: Might you by any chance be referring to a BOINC project?
146 2013-08-05 12:14:08 <michagogo> (of which there are many)
147 2013-08-05 12:14:26 <BSaboia> michagogo, something along that, yes
148 2013-08-05 12:15:03 <BSaboia> actually, i study economics and i'm doing a research about bitcoins. i am a programmer myself
149 2013-08-05 12:15:42 <BSaboia> so i though that bitcoins were trying to generate value outside the bitcoin economy itself
150 2013-08-05 12:15:57 <BSaboia> but you denied my vision
151 2013-08-05 12:16:24 <michagogo> BSaboia: Well, bitcoins arguably have value
152 2013-08-05 12:16:44 <BSaboia> michagogo, why?
153 2013-08-05 12:16:52 <michagogo> Because you can use them to buy things
154 2013-08-05 12:17:39 <BSaboia> michagogo, yes, of course. but then a dolar have value, real, euro. but they aren't backed up, BCs can make them out of thin air
155 2013-08-05 12:19:07 <michagogo> BSaboia: Neither dollars nor bitcoins are backed by anything
156 2013-08-05 12:19:14 <michagogo> They have value because people adree they have value.
157 2013-08-05 12:19:16 <michagogo> agree*
158 2013-08-05 12:19:20 <BSaboia> yes, i know
159 2013-08-05 12:19:26 <BSaboia> money nowdays is faith
160 2013-08-05 12:19:34 <BSaboia> it always was, as a matter of fact
161 2013-08-05 12:19:55 <michagogo> And yes, bitcoins are created out of thin air, but they're created at a measured pace, following strict rules
162 2013-08-05 12:20:02 <michagogo> Which is more than can be said for some fiats
163 2013-08-05 12:20:13 <BSaboia> yes, that's good
164 2013-08-05 12:20:21 <BSaboia> you can predict the increase on the supply
165 2013-08-05 12:20:49 <BSaboia> thus inflation is not a problem. as amatter of fact, i *think* that, in the long run, bitcoin will prove to be deflationary
166 2013-08-05 12:21:52 <BSaboia> but i though that the idea behind bitcoins was "well, this generating system is nonsense, lets make some currency that's backed on value, like the dolar was in the gold-standard era". but now i understand that its a currency like any other one, except that : 1.) anyone can generate it, it is not a BC monooply 2.) the rules to generate it are strict, open and well documented
167 2013-08-05 12:22:29 <BSaboia> you generate it through a proof of work, although the power used to generate it serves only for the generating purpouses
168 2013-08-05 12:22:30 <michagogo> BSaboia: And it's decentralized and consensus-driven
169 2013-08-05 12:23:05 <michagogo> As well as being psuedonymous, unchargebackable
170 2013-08-05 12:23:07 <BSaboia> michagogo, decentralized means what i wrote on 1, right? anyone can generate it, not just the bcs
171 2013-08-05 12:23:23 <michagogo> BSaboia: Right, but it's more than "anyone can generate"
172 2013-08-05 12:23:31 <BSaboia> what do you mean by consensus-driven?
173 2013-08-05 12:23:44 <michagogo> Being decentralized means that the entire system has no central authority, no central control point'
174 2013-08-05 12:23:47 <michagogo> point*
175 2013-08-05 12:23:56 <BSaboia> michagogo, hmm
176 2013-08-05 12:23:58 <michagogo> Like bittorrent, as opposed to, say, Napster
177 2013-08-05 12:24:07 <BSaboia> good analogy
178 2013-08-05 12:24:35 <BSaboia> so, there is no 'central server'. instead, just peers. is that it?
179 2013-08-05 12:24:44 <c0rw1n> yeah
180 2013-08-05 12:25:51 <BSaboia> c0rw1n, cool. i'm doing some reserach but it is very difficult to find things to cite. finding sources on bitcoin subjects (at least 'academic acceptable ones') is still very harsh
181 2013-08-05 12:26:08 <BSaboia> you guys helped me more than a ton of websites so far
182 2013-08-05 12:28:34 <jgarzik> mornin'
183 2013-08-05 12:28:50 <BSaboia> good morning
184 2013-08-05 12:29:18 <phantomcircuit> hello
185 2013-08-05 12:29:34 <michagogo> Hey, Jeff
186 2013-08-05 12:31:21 <Scrat> hey geoff
187 2013-08-05 12:36:01 <phantomcircuit> jgarzik, it's miserable and grey here
188 2013-08-05 12:36:16 <phantomcircuit> i assume it's still ridiculously hot for you
189 2013-08-05 12:36:45 <BSaboia> phantomcircuit, where do you live?
190 2013-08-05 12:36:57 <phantomcircuit> san francisco
191 2013-08-05 12:37:13 <phantomcircuit> home of tourists in shorts on a nice cold summers day
192 2013-08-05 12:37:14 <phantomcircuit> :)
193 2013-08-05 12:37:18 <jgarzik> 90F
194 2013-08-05 12:37:20 <BSaboia> i live in fortaleza, brazil. summer all the time here
195 2013-08-05 12:37:47 <phantomcircuit> jgarzik, heh
196 2013-08-05 12:37:56 <phantomcircuit> that sounds nice... for maybe 2-3 days
197 2013-08-05 12:38:53 <BSaboia> phantomcircuit, lol, never went to san francisco, but i assume that it's nice to wear shorts if its not too cold
198 2013-08-05 12:39:38 <phantomcircuit> BSaboia, the joke is it's almost always too cold for shorts
199 2013-08-05 12:39:45 <phantomcircuit> or at least an hour away from being too cold
200 2013-08-05 12:41:04 <BSaboia> phantomcircuit, lol
201 2013-08-05 12:41:53 <BSaboia> michagogo, i still don't get what you mean by 'consesus-driven'
202 2013-08-05 12:42:23 <michagogo> BSaboia: Well, each node is running the code
203 2013-08-05 12:42:39 <michagogo> No one person can decide to simply change the network rules by changing the code
204 2013-08-05 12:42:46 <BSaboia> michagogo, oh. so it's the analogy you give napster/bittorrent
205 2013-08-05 12:43:05 <BSaboia> gave*
206 2013-08-05 12:43:30 <michagogo> BSaboia: For a change to happen, the bitcoin community, as a whole, needs to agree to make the change, by running a version of the software with that change
207 2013-08-05 12:44:18 <BSaboia> michagogo, ok, thanks
208 2013-08-05 14:27:35 <jgarzik> Surprise! Just got two BFL miners -- when I thought only one was arriving. Always a pleasant surprise.
209 2013-08-05 14:31:42 <gjs278> dah jgarzik whats the hash rate expected on them
210 2013-08-05 15:02:52 <Xeno-Genesis> does somebody know if the Android PRNG is sufficiently secure?
211 2013-08-05 15:03:07 <helo> i'm betting it has been scrutinized quite a bit
212 2013-08-05 15:03:32 <helo> given all of the attacks against android
213 2013-08-05 15:04:35 <jgarzik> ACTION wonders if it uses the Linux kernel PRNG
214 2013-08-05 15:05:47 <Xeno-Genesis> I have some Bitcoins that disappeared from an Android phone, and I am investigating the possibility of a private key collission being found
215 2013-08-05 15:05:56 <BlueMatt> heh, have fun
216 2013-08-05 15:05:58 <BlueMatt> which app?
217 2013-08-05 15:06:01 <Xeno-Genesis> collision, sorry
218 2013-08-05 15:06:24 <Xeno-Genesis> Andreas Schildbach Android Wallet and Blockchain.info My Wallet for Android
219 2013-08-05 15:06:43 <BlueMatt> heh, yea, nope have fun
220 2013-08-05 15:06:54 <Xeno-Genesis> look at this forum post: https://bitcointalk.org/index.php?topic=251743.new#new
221 2013-08-05 15:07:01 <BlueMatt> unless its an old version of android...
222 2013-08-05 15:07:18 <phantomcircuit> Xeno-Genesis, there's more than one
223 2013-08-05 15:08:16 <Xeno-Genesis> two independent Android phone wallets get hacked (one Blockchain.info, and one Android Wallet)
224 2013-08-05 15:08:21 <Xeno-Genesis> during the last month
225 2013-08-05 15:08:31 <Xeno-Genesis> and both send the bitcoins to the same address
226 2013-08-05 15:08:39 <helo> Xeno-Genesis: both of yours?
227 2013-08-05 15:08:44 <Xeno-Genesis> nope
228 2013-08-05 15:08:47 <Xeno-Genesis> I just have the last one
229 2013-08-05 15:08:55 <helo> hmm
230 2013-08-05 15:09:26 <Xeno-Genesis> no applications downloaded outside of the Google Play store
231 2013-08-05 15:09:49 <Xeno-Genesis> only about five to ten apps ever installed, nothing particularly shady
232 2013-08-05 15:09:55 <helo> i've had bitcoin on my phone (from ~$50 to $300 worth) for months without losing it, so it's at least not pervasive
233 2013-08-05 15:10:14 <BlueMatt> what version of android?
234 2013-08-05 15:10:19 <jgarzik> ditto
235 2013-08-05 15:10:25 <jgarzik> have > $1000 on my phone
236 2013-08-05 15:10:28 <jgarzik> in bitcoins
237 2013-08-05 15:10:39 <helo> mine is 4.1.2
238 2013-08-05 15:10:42 <sipa> jgarzik: same
239 2013-08-05 15:10:45 <Xeno-Genesis> Android 4.2.1 in a Galaxy Nexus
240 2013-08-05 15:10:56 <sipa> 4.3 here
241 2013-08-05 15:11:09 <helo> Xeno-Genesis: did you ever do wallet backups?
242 2013-08-05 15:11:12 <gjs278> are you using a brain wallet
243 2013-08-05 15:11:24 <Xeno-Genesis> yes, wallet backups done
244 2013-08-05 15:11:37 <sipa> do you share the wallet between android and b.i?
245 2013-08-05 15:11:41 <Xeno-Genesis> offline, to an Ubuntu system via USB
246 2013-08-05 15:11:52 <Xeno-Genesis> the backup encrypted with a cryptographically secure passphrase
247 2013-08-05 15:11:54 <jgarzik> Kernel 2.6.35.7, firmware 2.3.6 (samsung galaxy s), build gingerbread.fc09
248 2013-08-05 15:12:03 <gjs278> did you personally generate the private key against a brain wallet phrase
249 2013-08-05 15:12:05 <jgarzik> no idea what 4.x version that is
250 2013-08-05 15:12:21 <jgarzik> Xeno-Genesis, good question, from gjs278
251 2013-08-05 15:12:24 <Xeno-Genesis> the private key has been in the clear only in the Android device
252 2013-08-05 15:12:26 <jgarzik> brain wallets are difficult to secure
253 2013-08-05 15:12:31 <Xeno-Genesis> no brain wallet
254 2013-08-05 15:12:38 <Xeno-Genesis> the key has been generated by the Android wallet
255 2013-08-05 15:12:48 <BlueMatt> ie by java.security.SecureRandom
256 2013-08-05 15:12:58 <Xeno-Genesis> I'm trying to confirm if the original poster of the forum thread also generated his wallet using Android's Blockchain.info
257 2013-08-05 15:13:05 <Xeno-Genesis> yes, SecureRandom
258 2013-08-05 15:13:21 <BlueMatt> nfc about the blockchain.info app, but "Bitcoin Wallet" uses java.security.SecureRandom
259 2013-08-05 15:13:25 <BlueMatt> so...if thats broken....
260 2013-08-05 15:13:39 <phantomcircuit> lol jeff
261 2013-08-05 15:13:50 <phantomcircuit> might not want to advertise that kind of thing to the entire world
262 2013-08-05 15:14:18 <sipa> needs a selfdestruct option
263 2013-08-05 15:14:42 <sipa> if you unlock using a particular (wrong) unlock code/pin/password, it destroys private date
264 2013-08-05 15:14:59 <phantomcircuit> BlueMatt, iirc on andoird java.security.SecureRandom just pulls from /dev/urandom
265 2013-08-05 15:15:15 <phantomcircuit> which on most phones isn't re-keyed frequently
266 2013-08-05 15:15:20 <helo> nah, just periodically create (and store for safekeeping) a tx that sends the phone's coin somewhere safe
267 2013-08-05 15:15:29 <phantomcircuit> but the entropy pool can pull high quality random data from most arm chips
268 2013-08-05 15:15:36 <phantomcircuit> but im not sure if that's actually enabled
269 2013-08-05 15:15:43 <BlueMatt> phantomcircuit: "By default, instances of this class will generate an initial seed using an internal entropy source, such as /dev/urandom. This seed is unpredictable and appropriate for secure use."
270 2013-08-05 15:15:44 <phantomcircuit> but really if /dev/urandom is broken that's a big deal
271 2013-08-05 15:16:06 <phantomcircuit> hmm i'd swear it pulled from there entirely
272 2013-08-05 15:16:18 <phantomcircuit> i guess it's plausible that it's broken
273 2013-08-05 15:16:29 <BlueMatt> nfc, the docs hint it might not, but suggest that just catting /dev/urandom would meet the spec as written
274 2013-08-05 15:16:45 <Xeno-Genesis> well, you tell me, I have the phone here
275 2013-08-05 15:17:25 <Xeno-Genesis> there's this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations
276 2013-08-05 15:17:47 <phantomcircuit> Xeno-Genesis, is the phone rooted?
277 2013-08-05 15:17:47 <Xeno-Genesis> can we do something on our side? something that can rule out the phone having been hacked?
278 2013-08-05 15:17:53 <Xeno-Genesis> no, it isn't rooted
279 2013-08-05 15:17:56 <helo> looks like /dev/urandom was fine in that vuln, it just wasn't being used
280 2013-08-05 15:17:57 <phantomcircuit> what model
281 2013-08-05 15:18:03 <phantomcircuit> what version
282 2013-08-05 15:18:09 <Xeno-Genesis> Samsung Galaxy Nexus
283 2013-08-05 15:18:23 <sipa> i have a galaxy nexus as well
284 2013-08-05 15:18:28 <sipa> with a android wallet
285 2013-08-05 15:18:32 <sipa> never used b.i though
286 2013-08-05 15:18:51 <Xeno-Genesis> let me provide version details
287 2013-08-05 15:19:25 <phantomcircuit> sipa, i installed the bi app once
288 2013-08-05 15:19:33 <phantomcircuit> decided to wipe my phone afterwards
289 2013-08-05 15:20:09 <Xeno-Genesis> Galaxy Nexus running Android 4.2.1, kernel 3.0.31-gd5a18e0 android-build@vpbs1.mtv.corp.google.com #1 Fri Nov 2 11:02:59 PDT 2012
290 2013-08-05 15:20:18 <Xeno-Genesis> build number JOP40D.I9250XWMA2
291 2013-08-05 15:20:37 <Xeno-Genesis> never installed Blockchain.info wallet on this phone
292 2013-08-05 15:21:11 <phantomcircuit> hmm
293 2013-08-05 15:22:15 <Xeno-Genesis> it's important to note that on the forum page both Android phones, one running Blockchain.info on July 07, and my friend's, running Andreas Schildbach wallet, got robbed by the same person
294 2013-08-05 15:22:57 <Xeno-Genesis> we're not connected in any way, the only commonality being Android, bitcoinj backend, and the address the funds went to
295 2013-08-05 15:23:10 <sipa> b.i's wallet is bitcoinj backed? :o
296 2013-08-05 15:23:18 <Xeno-Genesis> sipa, yes
297 2013-08-05 15:23:24 <sipa> i had no idea
298 2013-08-05 15:24:12 <Xeno-Genesis> I know there's a Master Key vulnerability in Android these days, but I don't expect non-shady applications downloaded from Google Play to hijack the phone
299 2013-08-05 15:25:01 <phantomcircuit> Xeno-Genesis, the play store doesn't use https
300 2013-08-05 15:25:17 <phantomcircuit> the primary issue there is mitm of the apk http downloads
301 2013-08-05 15:25:24 <Xeno-Genesis> phantomcircuit, well, then it means that a MITM is possible, but I don't know if the phone has been compromised
302 2013-08-05 15:25:36 <Xeno-Genesis> I don't know how to do this analysis against an Android phone
303 2013-08-05 15:25:41 <phantomcircuit> im thinking that is unlikely unless you're in china
304 2013-08-05 15:25:47 <Xeno-Genesis> Ireland
305 2013-08-05 15:25:56 <phantomcircuit> well maybe
306 2013-08-05 15:26:19 <phantomcircuit> the issue is semi automated attacks against that have been in the wild now for a while
307 2013-08-05 15:26:32 <phantomcircuit> but again i'd say it's fairly unlikely you got hit my it
308 2013-08-05 15:27:35 <Xeno-Genesis> I think both having had the phone compromised, and having someone finding a collision of the private key are unlikely
309 2013-08-05 15:27:49 <helo> the same destination address indicates automated
310 2013-08-05 15:27:56 <Xeno-Genesis> once one of those get discarded, whatever remains is what happened
311 2013-08-05 15:28:28 <phantomcircuit> my initial guess is that collision is unlikely
312 2013-08-05 15:28:41 <helo> what's the chance that a given collision would share the same public key?
313 2013-08-05 15:28:45 <phantomcircuit> however it's apparently possible to break SecureRandom by setting a bad seed manually
314 2013-08-05 15:29:03 <phantomcircuit> helo, 1
315 2013-08-05 15:29:07 <helo> o
316 2013-08-05 15:29:21 <sipa> eh, no
317 2013-08-05 15:29:30 <sipa> the address can cllide without the pubkey colliding
318 2013-08-05 15:29:34 <sipa> *wait
319 2013-08-05 15:29:49 <sipa> if it's caused by a crypto vulnerability, the pubkey will collide as well
320 2013-08-05 15:30:22 <phantomcircuit> i could see someone trying to "improve" SecureRandom by submitting stuff to setSeed and getting that wrong
321 2013-08-05 15:30:36 <BlueMatt> phantomcircuit: bitcoinj does not do that
322 2013-08-05 15:30:55 <Xeno-Genesis> bitcoinj uses the ECDSA key generator by Spongy Castle
323 2013-08-05 15:30:58 <phantomcircuit> BlueMatt, no but individual app creators might
324 2013-08-05 15:31:09 <BlueMatt> Bitcoin Wallet does not
325 2013-08-05 15:31:09 <sipa> is b.i's app opensource?
326 2013-08-05 15:31:11 <BlueMatt> no idea about b.i
327 2013-08-05 15:31:13 <BlueMatt> sipa: yes
328 2013-08-05 15:31:23 <Xeno-Genesis> sipa, yes
329 2013-08-05 15:31:55 <sipa> so go check :)
330 2013-08-05 15:32:01 <Xeno-Genesis> https://github.com/blockchain/My-Wallet-Android
331 2013-08-05 15:32:18 <Xeno-Genesis> https://github.com/blockchain/My-Wallet-Android/blob/master/bitcoinj-0.8/src/com/google/bitcoin/core/ECKey.java
332 2013-08-05 15:32:28 <helo> Xeno-Genesis: mind sharing the address the funds were sent to?
333 2013-08-05 15:32:32 <Xeno-Genesis> sure
334 2013-08-05 15:32:43 <BlueMatt> bitcoinj directly invokes spongy castle, which uses the SecureRandom provided without touching it
335 2013-08-05 15:33:13 <Xeno-Genesis> here's the TX: https://blockchain.info/tx/211c135e58dc55bcce4c71dc02eae2dffc5a55387c29e8144bf1cd1e8878e52e
336 2013-08-05 15:34:11 <Xeno-Genesis> this is the TX for the first guy that got robbed using the Blockchain.info wallet: https://blockchain.info/tx/c03c31067638033d8c75ad64ddc1dce1628a8d5ce10416f0d97890f5f3ab50a3
337 2013-08-05 15:34:58 <Xeno-Genesis> that transaction is weird because there's what seems to be a change output there, so it was not generated to send all of the funds to the robber's address apparently
338 2013-08-05 15:37:29 <Xeno-Genesis> if the phone itself was hacked, then it's no big deal, there's nothing bad with Android wallets, but if it isn't, then this could mean big trouble if private key collisions can be found
339 2013-08-05 15:38:09 <lianj> dont reuse an address too much
340 2013-08-05 15:38:31 <Xeno-Genesis> lianj, Bitcoin should be resistant to this address reuse
341 2013-08-05 15:38:39 <Xeno-Genesis> the underlying algorithms should resist
342 2013-08-05 15:44:20 <Xeno-Genesis> would some Android connoisseur direct me to information I can use to validate that the phone itself hasn't been hacked?
343 2013-08-05 15:46:16 <shesek> Xeno-Genesis, the underlying algorithms will not resist anything
344 2013-08-05 15:46:22 <shesek> it is just highly unlikely to happen
345 2013-08-05 15:46:36 <shesek> enough to be considered near impossible
346 2013-08-05 15:47:16 <Xeno-Genesis> shesek, hey, I have an Android phone that lost 0.9 bitcoins last night thanks to what seems to be an impossible hack
347 2013-08-05 15:47:37 <Xeno-Genesis> shesek, I can consider it impossible if nobody pulls it off
348 2013-08-05 15:47:46 <Xeno-Genesis> but it seems that the same person managed to pull this off twice within a month
349 2013-08-05 15:48:07 <shesek> are you using an online wallet or a local one?
350 2013-08-05 15:48:14 <Xeno-Genesis> local
351 2013-08-05 15:48:43 <shesek> I dunno... perhaps someone has access to your phone?
352 2013-08-05 15:49:23 <Xeno-Genesis> shesek, nobody, no physical access at least
353 2013-08-05 15:49:29 <Xeno-Genesis> and it's very unlikely to be compromised
354 2013-08-05 15:51:00 <lianj> there are so many vectors, where address reuse is just one. will be hard for you to find the cause
355 2013-08-05 15:51:55 <Xeno-Genesis> lianj, if the PRNG used is not secure, I expect more people to start seeing bitcoins disappear from their Android wallets
356 2013-08-05 15:52:23 <Xeno-Genesis> this could be a big deal, because it seems to be happening
357 2013-08-05 15:52:39 <Xeno-Genesis> I find it unlikely that the phone got hacked
358 2013-08-05 15:54:05 <lianj> Xeno-Genesis: if the prng is not secure then address reuse is more likely your issue than initial key generation
359 2013-08-05 15:55:31 <Xeno-Genesis> lianj, it stills point to big bad vulnerability in Android wallets, which are designed for address reuse
360 2013-08-05 15:55:42 <Xeno-Genesis> correction: still points
361 2013-08-05 15:56:06 <lianj> well, just saying???
362 2013-08-05 16:35:20 <phantomcircuit> fun fact
363 2013-08-05 16:35:39 <phantomcircuit> openssl 1.0.1c is incompatible with a certain polish banks ssl server
364 2013-08-05 16:35:43 <phantomcircuit> 1.0.0j isn't
365 2013-08-05 16:36:42 <phantomcircuit> trying to diff there's apparently ~40k lines in the diff
366 2013-08-05 16:36:50 <phantomcircuit> so i'll probably never know what the problem is
367 2013-08-05 16:37:39 <lianj> phantomcircuit: ^^
368 2013-08-05 16:38:01 <phantomcircuit> lianj, hmm?
369 2013-08-05 16:38:34 <lianj> @ 40k diff
370 2013-08-05 16:38:35 <phantomcircuit> the worst part is im about 90% sure i've debugged this exact problem before and came to the same conclusion >.>
371 2013-08-05 16:38:42 <phantomcircuit> ah
372 2013-08-05 16:39:04 <phantomcircuit> 37037 lines
373 2013-08-05 16:40:34 <CodeShark> I would focus on the specific operations that fail
374 2013-08-05 16:40:59 <CodeShark> can you reproduce these failures reliably?
375 2013-08-05 16:51:05 <phantomcircuit> CodeShark, yup but it fails remotely
376 2013-08-05 16:51:27 <phantomcircuit> ie the connection hangs and then eventually the remote peer closes the connection after a timeout
377 2013-08-05 16:51:42 <phantomcircuit> so there isn't a whole lot to go on
378 2013-08-05 16:55:08 <CodeShark> you could try doing the same negotiation with both 1.0.1c and 1.0.0j and compare the packets
379 2013-08-05 17:26:04 <BSaboia> phantomcircuit, i had a ssl problem that resemble yours in the past, with android
380 2013-08-05 17:26:19 <BSaboia> but at least i got the error back from the server, from what i can recall
381 2013-08-05 18:10:49 <FabianB> MultiBit has only 1 developer?
382 2013-08-05 18:12:19 <gmaxwell> FabianB: depends on how you define multibit, multibit is largely a GUI for bitcoinj.
383 2013-08-05 18:13:27 <FabianB> yeah, but still wondering how closedly releases are reviewed
384 2013-08-05 18:14:40 <BlueMatt> FabianB: the one developer does have a very thorough testing method before each release, though probably arent as reviewed as they should be
385 2013-08-05 18:14:59 <BlueMatt> I dont think any bitcoinj-based stuff is quite as mature re: developer count as bitcoind/-qt
386 2013-08-05 18:17:00 <FabianB> yeah, that was my feeling
387 2013-08-05 18:27:57 <lianj> why does bitcoin use ECDSA_sign for txs and ECDSA_do_sign so signed messages?
388 2013-08-05 18:30:44 <Luke-Jr> lianj: probably an oversight for signed messages
389 2013-08-05 18:31:02 <Luke-Jr> lianj: the transaction code more recently was changed to produce only standards-compatible signatures
390 2013-08-05 18:31:34 <gmaxwell> IIRC do_sign is just the function when you haven't precomputed the multiplier values.
391 2013-08-05 18:31:44 <gmaxwell> Luke-Jr: hm? it should have always _produced_ them iirc.
392 2013-08-05 18:34:44 <Luke-Jr> gmaxwell: I don't understand why we had to change the code to adjust them then..?
393 2013-08-05 18:35:09 <sipa> i probably did that
394 2013-08-05 18:35:15 <sipa> and there was probably a reason
395 2013-08-05 18:35:18 <sipa> let me look
396 2013-08-05 18:35:44 <Diablo-D3> http://www.dieselsweeties.com/archive/3375
397 2013-08-05 18:36:31 <sipa> ECDSA_sign doesn't let you access the signature in <r,s> form, it immediately DER-serializes it
398 2013-08-05 18:36:43 <sipa> and signed messages don't use DER signatures
399 2013-08-05 18:37:16 <lianj> yea thats what i noticed
400 2013-08-05 18:38:43 <sipa> so there is your answer :)
401 2013-08-05 18:39:54 <sipa> if your question is why don't message signatures use DER-serialization: that code was written as an experiment with compact signatures that offer recoverable pubkeys
402 2013-08-05 18:40:08 <sipa> and it was conveniently available when the message signing features was wanted
403 2013-08-05 18:40:18 <lianj> sipa, thats a better rephrase of my question
404 2013-08-05 18:40:47 <sipa> (which means you can verify using just an address, not needing the full pubkey)
405 2013-08-05 18:41:03 <sipa> in fact you need neither, but the RPC is a bit safer this way
406 2013-08-05 18:42:08 <lianj> so head = [ 27 + i + (pubkey_compressed ? 4 : 0) ].pack("C") is a bitcoin thing? and makes it possible to not try all 8 instead
407 2013-08-05 18:42:37 <lianj> (head + r + s format of compact signatures from signmessage
408 2013-08-05 18:43:46 <sipa> yes
409 2013-08-05 18:45:54 <lianj> thanks
410 2013-08-05 19:35:11 <michagogo> Has anyone looked at freeBSD's bitcoin port and seen what it does?
411 2013-08-05 19:35:29 <Luke-Jr> I just did
412 2013-08-05 19:35:29 <michagogo> It uses this makefile, fetching source from github: http://svnweb.freebsd.org/ports/head/net-p2p/bitcoin/Makefile?view=markup
413 2013-08-05 19:35:32 <michagogo> And?
414 2013-08-05 19:35:36 <Luke-Jr> looks pretty simple
415 2013-08-05 19:35:50 <michagogo> What do those patches in the files/ directory do?
416 2013-08-05 19:36:04 <Luke-Jr> mostly just adjust things to compile/link
417 2013-08-05 19:36:13 <Luke-Jr> whether it actually works, hard to tell <.<
418 2013-08-05 19:36:31 <michagogo> Luke-Jr: More importantly, do any of the patches have security implications?
419 2013-08-05 19:37:28 <Luke-Jr> michagogo: the patches, probably not.
420 2013-08-05 19:37:42 <michagogo> Anything else it does?
421 2013-08-05 20:02:21 <Luke-Jr> michagogo: dunno what the BSD differences are
422 2013-08-05 20:26:22 <sipa> the title of this article is worrying: http://bitcoinexaminer.org/the-13-most-promising-cryptocurrencies/
423 2013-08-05 20:26:59 <sipa> (not that i disagree much with it... the fact that there are so many that a subset of 13 can be called "most promising" already...)
424 2013-08-05 20:31:24 <jgarzik> heh
425 2013-08-05 20:32:48 <jgarzik> sipa, Those "Top $number Most $Adjective $Nouns" posts are pure SEO bait
426 2013-08-05 20:33:08 <jgarzik> probably took five minutes to write
427 2013-08-05 20:34:56 <edcba> you mean the article generator ? :)
428 2013-08-05 20:36:38 <nsh> sipa, something about imitation and flattery springs to mind
429 2013-08-05 20:38:49 <edcba> hmm primecoin
430 2013-08-05 20:39:16 <amiller> i wanna see all the coins fight and form alliances and generally interact with each other like bacteria in a petrie dish
431 2013-08-05 20:42:42 <michagogo> lol
432 2013-08-05 20:43:06 <edcba> ok primecoin paper is not made by a scientist i guess
433 2013-08-05 20:43:22 <gmaxwell> killrcoin: POW is proof of attacking other coins.
434 2013-08-05 20:43:57 <edcba> ddoscoin !
435 2013-08-05 20:45:21 <amiller> we're so far behind in understanding exactly what it takes to make a good bitcoin puzzle :/
436 2013-08-05 20:45:39 <amiller> one thing that's clear is that it's not actually "proof of work" according to the accepted definition for htat
437 2013-08-05 20:45:57 <edcba> why ?
438 2013-08-05 20:46:02 <amiller> the reason is that if you actually take a perfect proof-of-work function and plug it in, it sucks for bitcoin
439 2013-08-05 20:46:23 <amiller> the ideal proof-of-work takes *exactly* D steps to compute, no more no less
440 2013-08-05 20:46:23 <edcba> i don't see why
441 2013-08-05 20:46:40 <amiller> with like, a sequential machine
442 2013-08-05 20:46:57 <edcba> hashcash always had a difficulty parameter no ?
443 2013-08-05 20:47:13 <amiller> yes but the point is there's a lot of variance in how long it actually tkes to win a block
444 2013-08-05 20:47:15 <amiller> and that's good
445 2013-08-05 20:47:32 <amiller> even a single hash has a fair chance of winning, which makes the effect of latency pretty low and makes it viable for small participants to have a chance
446 2013-08-05 20:48:04 <amiller> if you had a perfect proof-of-work function, instead of hash cash, then only the fastest miner would always win and it wouldn't be a fair sampling the way it is now
447 2013-08-05 20:48:21 <edcba> yeah 1/10e10 instead of 1/10e3
448 2013-08-05 20:48:31 <edcba> they should be happy to be so lucky
449 2013-08-05 20:49:08 <edcba> i don't see where you saw that proof of work required exactly D steps
450 2013-08-05 20:49:14 <edcba> never saw that definition
451 2013-08-05 20:51:15 <edcba> anyway the problem is more making it non parallelizable while in same time having more ppl = more secure
452 2013-08-05 20:52:30 <sipa> amiller: how about metacoin?
453 2013-08-05 20:52:41 <amiller> so that's the thing, most proof of work definitions aim for non-parallelizable while bitcoin benefits from as-parallelizable-as-possible
454 2013-08-05 20:52:51 <sipa> (launching a succesful cryptocurrency counts as PoW)
455 2013-08-05 20:53:28 <sipa> edcba: hashcash's difficulty was the number of high zero bits
456 2013-08-05 20:54:34 <edcba> script should have been used to define pow
457 2013-08-05 20:55:30 <edcba> now the problem is to calculate whether the pow fn is fair or not
458 2013-08-05 20:55:35 <edcba> ie not precomputable
459 2013-08-05 20:55:49 <gmaxwell> any kind of stiocastic search is stupidly parallel. You can only make it not by doing something that effectively imposes a global consensus problem on it. Yo dawg.
460 2013-08-05 20:55:50 <edcba> and solvable :)
461 2013-08-05 20:57:14 <nsh> gmaxwell++
462 2013-08-05 21:40:34 <Diablo-D3> um
463 2013-08-05 21:40:37 <Diablo-D3> gmaxwell: http://i.imgur.com/Q0soRHv.png
464 2013-08-05 21:40:45 <Diablo-D3> somebodies been reading the best fanfic ever