--- Log opened Fri Sep 20 00:00:58 2013
00:19 < warren> jgarzik: regarding CiviCRM, johns said he might have got students at Stanford to agree to do it, but if that falls through one of the grant submissions is the task as defined by johns.
00:21 < warren> jgarzik: one dev looked into CiviCRM and found a mess of poor or lacking documentation and broken examples.  I think he submitted only the Free Software part for the grant, and by the time he finishes that it should be easy for him to write separate Bitpay and Coinbase modules.
08:03 < HM> lol "Homeless, unemployed, and surviving on Bitcoins". Wired sure can write a headline
08:04 < HM> I think the picture features the entire dev team ? ;)
14:22 < jgarzik> It would be annoying as hell, but the first autonomous agent will likely be a beggar-bot
14:22 < jgarzik> "I'm the first autonomous agent, give me bitcoins or I die"
14:22 < gmaxwell> at least it would be true.
14:23 < gmaxwell> it could be a little more "fit" than that... perhaps like one of those bitcoin gems where the high bidder gets some free advertising.
14:23 < MoALTz> "i'll work your product into my conversations for bitcoins"
16:25 < HM> Bitfetch -> nice implementation, corrupts downloads
16:28 < amiller> i found a minor bug in this proof of work paper http://eprints.qut.edu.au/40036/6/40036-full-revised.pdf
16:28 < amiller> it doesn't really matter i guess
16:28 < amiller> but there are a bunch of nice things about his definition of puzzles and i want to import those
16:29 < amiller> but they're too strong, "correctness" says that there's some amount of time you can run such that you find a solution with probability 1
16:29 < amiller> and that's not the case with hashcash style puzzles (e.g., bitcoin)
16:30 < amiller> in fact if the input space is bounded, as is the case with bitcoin, there's a nonzero chance that there's *no solution* and the blocks are jammed
16:31 < amiller> this doesn't matter because there's less chance of that happening than finding a collision
16:31 < amiller> a design requirement it's important that the nonce + merkle root range is sufficiently large that is very unlikely to happen
16:33 < amiller> this basically just fits into my point that there's no existing definition for "proof-of-work" that actually describes what's important for bitcoin
16:34 < amiller> the more important point is that if t is the number of steps needed to find a solution with probability 1 or nearly 1 or whatever, even taking just a small number steps should give you a solution with approximately probability 1/t
16:34 < amiller> that's the main thing that's obviously essential for bitcoin and *isn't even close* to part of anyones definition of proof-of-work
16:36 < gmaxwell> its interesting that you mention it, there was a nice argument with adam back on the forum where he was arguing that bitcoin should be using a proof of work scheme which had cumulative small work
16:37 < gmaxwell> and people arguing that it wouldn't work for bitcoin, basically because it actually broke up the stochastic lottery behavior and that we actually need it.
16:40 < amiller> yeah, there's lots of papers with "perfect proof of work" puzzles that take exactly t units to solve and any less has zero chance of success, and that's obviously no good
16:40 < amiller> it shouldn't be hard to modify the definition so that it's like
16:41 < amiller> you put in t units of work, you get.... well the equivalent of t lotto chances, binomial distribution, whatever
16:41 < amiller> subdivided down to whatever asymptotically small little chunk
--- Log closed Sat Sep 21 00:00:01 2013