--- Log opened Thu May 30 00:00:47 2013
00:20 < Luke-Jr> if it works
01:05 < midnightmagic> so glorious, thank you for telling me about this place gmaxwell
01:06  * zooko revels in the glory
01:06 < Luke-Jr> lol
01:06 < zooko> Nice meeting you in person at Bitcoin2013, Luke-Jr.
01:06 < midnightmagic> zooko: they linked to http://arxiv.org/pdf/1305.5976v1.pdf in here, which is the first I saw of it.
01:06 < Luke-Jr> zooko: you too, though I have no idea who you were! :P
01:06 < midnightmagic> I'm busy scaring all my friends right now.
01:06 < Luke-Jr> midnightmagic: told you, you should have gone!
01:06 < midnightmagic> heh heh
01:07 < realazthat> midnightmagic: there is a whole list of proofs on the PvsNP page
01:07 < realazthat> (if you weren't aware)
01:07 < zooko> Luke-Jr: we spoke for about 10 seconds. I said I wanted to meet you because my friend amiller said he liked you.
01:07 < midnightmagic> realazthat: I was just about to look that up actually. I wasn't aware.
01:07 < zooko> Luke-Jr: you didn't really make eye contact with me.
01:07  * Luke-Jr wonders if he made eye contact with anyone O.o
01:08 < realazthat> midnightmagic: http://www.win.tue.nl/~gwoegi/P-versus-NP.htm
01:08 < realazthat> they tend not to ... pan out
01:10 < midnightmagic> realazthat: Indeed. My non-keeping-up first sanity check is that magic isn't happening yet.
01:11 < realazthat> mmm
01:11 < realazthat> I didn't read the paper
01:11 < midnightmagic> realazthat: Thanks for a link. I was combing through pvsnp on google.
01:11 < realazthat> but I did watch one of his vids from a long time ago
01:11 < realazthat> midnightmagic: it does leave some out actually
01:11 < realazthat> you can find more if you comb google
01:12 < realazthat> like this one
01:12 < realazthat> anyway I watched the vid from this guy a long time ago
01:12 < realazthat> I remember the data structure
01:12 < midnightmagic> google also leaves out the wooledge bash wiki when you goog for bash questions. never understood that.
01:12 < realazthat> from a quick scan of the paper, and remembering his video, he was very into testing random graphs
01:12 < realazthat> and that is suspicious right off the bat
01:13 < realazthat> because random graphs are easy
01:13 < realazthat> its suprisingly hard to get random hard problems
01:13 < Luke-Jr> midnightmagic: http://www.youtube.com/watch?v=kLueWNsYRno
01:13 < realazthat> one common way is to do RSA => SAT => HAM
01:13 < realazthat> and those fail all the solutions to HAM
01:13 < realazthat> and if they don't, well then you can profit :D
01:14 < realazthat> ah yeah
01:14 < realazthat> thats *awesome* vid
01:14  * realazthat is eagerly awaiting codes
01:15 < Luke-Jr> the more I think about it, the more I convince myself it's impossible
01:15 < realazthat> lol
01:15 < realazthat> I haven't gone through the math
01:15 < realazthat> I prolly wouldn't understand it
01:15 < Luke-Jr> is the math actually published yet?
01:15 < gmaxwell> Luke-Jr: there is basically a decade of papers behind this one.
01:15 < realazthat> mmm I think gmaxwell was saying he was gonna publish "tomorrow" a while back
01:15 < gmaxwell> The most important are the PCP from graph coloring problems papers, and the tinyram paper.
01:16 < realazthat> I haven't even begun to think applications yet
01:16 < realazthat> it is exciting :/
01:16 < Luke-Jr> gmaxwell: do they make sense to you? <.<
01:18 < zooko> I consider this more of a novelty than an important result, but: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1773169
01:18 < gmaxwell> Luke-Jr: I can follow parts of the math, not all of it.
01:18 < Luke-Jr> gmaxwell: enough that you can vouch for it being possible? ☺
01:18 < gmaxwell> http://eprint.iacr.org/2012/071.pdf < in any case, this is the paper to start research from right now.
01:19 < gmaxwell> Luke-Jr: oh yea, sure it's possible. Although the succinct proofs are not sound, they're only secure against a computationally bounded attackers. (like cryptographic security)
01:20 < gmaxwell> If you accept proofs which are polynomial in the amount of computations these systems can produce sound proofs, ones which can't be forged even if the attacker is not computationally bounded.
01:21 < gmaxwell> In addition to that paper, there is a earlier paper by Eli about RS codes over finite fields which is important to understand how the proofs are made succinct.
01:22 < realazthat> mmm so this seems to be a somewhat good solution to untrusted hardware perhaps, as well, no?
01:22 < realazthat> was that mentioned somewhere?
01:22 < Luke-Jr> gmaxwell: what stops me from simply redefining a crucial x86 opcode? ;p
01:22 < gmaxwell> realazthat: Yes, eli pointed that out specifically in discussion.
01:22 < realazthat> ok
01:23 < Luke-Jr> then it will run the same code, but produce a different result..
01:23 < gmaxwell> Luke-Jr: well, you're not executing x86 but instead "tinyram" which is a instruction set that has ~24 opcodes.
01:23 < Luke-Jr> hmm
01:24 < Luke-Jr> so the feature is an integrated part of an emulated CPU basically
01:24 < Luke-Jr> and I presume it has some way to stop me from redefining one of the 24 opcodes?
01:24 < gmaxwell> (add/mul/sub/and/or/xor/shal/shr/not/mov/cmp*/jmp/load/store)
01:25 < realazthat> if you redefine it, the signature will obviously not verify your output to the program
01:26  * Luke-Jr ponders a good way to distract himself from the urge to pester CareBear\ about his copyright issues so he can release BFG 3.1.0 already <.<
01:30 < midnightmagic> Luke-Jr: at a certain point, I'm not going to be able to resist an eve:online reference about carebear tears. :)
01:30 < Luke-Jr> midnightmagic: O.o
01:30 < Luke-Jr> aha, games
01:30 < Luke-Jr> that's how I cna distract myself
01:30 < petertodd> games? you mean like making cryptocurrencies?
01:31 < Luke-Jr> I mean like freeciv
01:31 < petertodd> well, you combined the two...
01:31 < gmaxwell> go try to read that paper. :P (of course, you'll need to go read the ones it references...)
01:31 < Luke-Jr> I did!
01:31 < Luke-Jr> my freeciv has a Cryptocurrency technology :P
01:31 < gmaxwell> that was pretty cool.
01:33 < petertodd> gmaxwell: usually I can pretend I have a real degree, reading that paper is not one of those times
01:34 < Luke-Jr> petertodd: you say that as if degrees have value!
01:34 < gmaxwell> One way of thinking about the proofs is that a reed-solomon code lets you efficiently verify the validity of data. Their work lets you use an RS code to verify that arbritary boolean constraints for data are true... then they run the program and create a transcript of the execution,
01:35 < gmaxwell> and reduce the program to a boolean set of constraints that only vaid transcripts would match....
01:35 < petertodd> Luke-Jr: heh, first and second year calc/analytics were well worth it, even if I failed the latter
01:35 < petertodd> *analysis
01:35 < Luke-Jr> petertodd: I bet you could have learned it faster on your own ;)
01:35 < petertodd> gmaxwell: I now have to recursively evaluate reed-solomon codes...
01:35 < gmaxwell> they apply an RS code to the result, and are able to then send only part of the RS code output, along with a proof that the constraints match the program, and a proof that the RS coded transcript matches the constraints.
01:36 < petertodd> Luke-Jr: No actually, absolutely not. The analysis part of the math I did take was by far the hardest thing I've ever done and there is no way in hell I would have gotten anywhere without uni. I know this because I tried going through the textbook the summer before...
01:37 < gmaxwell> the whole reduction of the programs execution to constraints is pretty tricky thing, it involves passing the execution through a sorting network and then using the sorting computation to create a graph coloring problem.
01:38 < petertodd> gmaxwell: See, I kinda follow that, but not in the sense that I would know if you were bullshitting me.
01:38 < Luke-Jr> lol
01:39 < gmaxwell> petertodd: I can't say that I understand it _that_ much better. I basically understand what they're doing but not in the kind of complete way needed to see problems with it.
01:39 < petertodd> oh lovely: https://www.btproof.com/ yet another timestamper... I think they're all using the blockchain.info API
01:40 < petertodd> gmaxwell: Yeah, as you say, 10 years of research.
01:42 < gmaxwell> also lots of deeply nested stuff, I wouldn't be surprised if no one person working on it really understands the whole thing.
01:43 < petertodd> Mostly true of Bitcoin too, if you include the inner workings of the crypto primitives in that set. (esp. hashing algorithms)
01:44 < gmaxwell> It's true.  ... or ... boost. :P
01:46 < petertodd> ...
01:47 < midnightmagic> gmaxwell: That's a really big beard. How long did it take you to grow that badboy?
01:47 < Luke-Jr> lol
01:47 < gmaxwell> midnightmagic: I trim it every couple weeks.
01:47 < gmaxwell> so no idea.
01:48 < gmaxwell> midnightmagic: what picture of me are you looking at?
01:49 < midnightmagic> http://www.youtube.com/watch?v=qgJtaBE6uT8#t=6m1s
01:49 < midnightmagic> That's you waving right?
01:49 < Luke-Jr> lol, gmaxwell is in it? XD
01:49 < Luke-Jr> apparently I'm right in the center of the altcoin Q&A XD
01:49 < gmaxwell> yes, thats me.
01:50 < midnightmagic> cool
01:51 < Luke-Jr> I should have feigned falling asleep when the ripple guy went on and on
01:51 < midnightmagic> lol
01:52 < realazthat> lol
01:53 < midnightmagic> Luke-Jr: http://www.youtube.com/watch?v=fZ85cssgDmI#t=0m29s  ah there you are.
01:53  * midnightmagic is growing sadder and sadder to have missed out
01:53 < gmaxwell> midnightmagic: yea, you suck. People asked about you multiple times.
01:53 < midnightmagic> aww
01:53 < Luke-Jr> midnightmagic: can't say we didn't try!
01:54 < midnightmagic> no sure can't.
01:54 < zooko> It would have been nice to have met you IRL.
01:54 < midnightmagic> zooko: You too!
01:55 < realazthat> there'll be another one
01:56 < realazthat> prolly
01:56 < realazthat> unless that P=NP paper does pan out after all :P
02:01 < petertodd> jgarzik: was thinking some more on the k-v store idea...
02:01  * zooko 's ears perk up
02:02 < petertodd> jgarzik: So I think the sacrifice specially marked txout needs to be able to back reference *two* prior txouts, and you should store cumulative size in there as well.
02:03 < petertodd> jgarzik: To incentivise small size k-v maps I'm still not sure... If the rule is largest total sacrifice always wins, that doesn't take storage size into account, but if it's value/size, then empty blocks win.
02:04 < petertodd> jgarzik: Probably want something in between, but now you get to pick a constant and... ugh
02:04  * petertodd feels like gavin...
02:04 < petertodd> zooko: did you see the discussion earlier?
02:05 < zooko> petertodd: I did not.
02:06 < petertodd> -wizards needs archives...
02:06 < petertodd> Essentially jgarzik needed a key-value store, and I came up with one based on a proof-of-sacrifice, where the best block is defined by total sacrifice. (roughly speaking)
02:07  * zooko boggles at the concept.
02:07 < petertodd> The trick is, the sacrifices in the Bitcoin blockchain are made to be identifiable, which means that if someone withholds the block associated with a sacrifice, you can be sure your fork wins by just sacrificing more than they did.
02:08 < petertodd> The incentive to build on others blocks, is then simply that you are building on their sacrifices, and in turn that gives an incentive to propagate your blocks.
02:09 < realazthat> I can paste logs
02:09 < petertodd> I've got them too
02:09 < realazthat> ok
02:09 < zooko> Is "proof of sacrifice" explained on the wiki or somewhere?
02:10 < zooko> Welcome, nejucomo. (I invited him.)
02:10 < petertodd> zooko: kinda: https://en.bitcoin.it/wiki/Fidelity_bonds
02:10 < nejucomo> Hello.
02:10 < zooko> Thanks.
02:11 < petertodd> zooko: logs: http://pastebin.com/Rj4bshY3
02:11 < zooko> Thanks.
02:13 < realazthat> mmm
02:13 < midnightmagic> hey nejucomo
02:16 < zooko> Hey, you folks were talking about the danger of miners discriminating among txns. (In http://pastebin.com/Rj4bshY3 .)
02:16 < Luke-Jr> zooko: O.o?
02:16 < Luke-Jr> miners are supposed to do that
02:17 < petertodd> Yeah, that's part of Adam Back's thing with his commit coins stuff.
02:17 < petertodd> Luke-Jr: we mean mike-style blacklists
02:17 < Luke-Jr> mike-stlye blacklists?
02:18 < petertodd> Luke-Jr: Yes, as in centrally/semi-centrally issued lists of coins that must not be allowed to move.
02:18 < zooko> Luke-Jr: the minimal service that we need from miners is just to not include conflicting double-spends in their block.
02:18 < Luke-Jr> petertodd: I don't see a problem, as long as it's not enforced on blocks miners make
02:18 < petertodd> zooko: assuming a limited blocksize...
02:18 < zooko> Other than that, if they could be blinded to the contents of transactions that would be good.
02:18 < Luke-Jr> zooko: also spam filtering
02:18 < zooko> petertodd: why?
02:19 < petertodd> zooko: With unlimited, then you *do* want spam filtering to keep UTXO set size sane.
02:19 < zooko> Luke-Jr: well, inasmuch as something is imposing an externality that it doesn't pay for, then yes.
02:19  * zooko nods.
02:19 < petertodd> Anyway, Luke and zooko are really talking about different things here...
02:20 < petertodd> zooko: I guess the key-value store stuff is about halfway down that paste.
02:21 < zooko> petertodd: still reading that paste...
02:29 < zooko> rs
02:29 < zooko> oops
02:32 < gmaxwell> petertodd: a position I've taken before is that we'd much rather have the miners not able to pick and choose, but if we can't eliminate that choke point and its costs and risks, then we darn well better also exploit the public benefits of having it there.
02:34 < petertodd> well, I'm not that concerned about UTXO growth with small blocks, so I figure if mining is decentralized enough, miners will greedily choose tx's by fees, and I consider fees apolitical
02:38 < petertodd> adam back's tx hiding stuff is nice, among other similar solutions, but if you are thinking about scenarios where it's needed for more than just plausible deniability, users will be forced to prove what's in the opaque containers anyway
02:38 < petertodd> meanwhile, being able to implement IsStandard() and similar has strong practical benifits
02:40 < gmaxwell> I'd give up all that in exchange for a non-problematic blinding... esp if blocksize is not infinite fees should also stop spam. But not that I think we have non-problematic binding.
02:40  * zooko too.
02:41 < Luke-Jr> SCIP could solve so many problems, that if I could be convinced it worked I'd be happy to depend on it :P
02:42 < Luke-Jr> maybe even could solve double spending. maybe.
02:42 < gmaxwell> Luke-Jr: well, that will just take time. It also will need to improve in performance before it solves many of them.
02:42 < gmaxwell> Nah, it doesn't prevent replay. I can't prove that I didn't seperately spin up another computing instance and do some computation twice.
02:42 < Luke-Jr> gmaxwell: will it? verifying one SCIP signature for the entire blockchain sounds nice XD
02:42 < Luke-Jr> gmaxwell: well, you could prove you delete the private key… then the question is can you prove you never copied it?
02:42 < petertodd> Luke-Jr: that's what the sales guys at amazon ec2 said as well
02:43 < petertodd> Luke-Jr: of course not
02:43 < realazthat> but you could make secure distributed cloud computing perhaps
02:43 < realazthat> I dunno if that is suggested anywhere
02:43 < realazthat> where people offer their computer time in exchange for bitcoins
02:44 < realazthat> all sorts of crazy ideas
02:44 < petertodd> realazthat: that's a long-standing problem with a whole bunch of efforts trying to solve it. Standard hardware and OS's just aren't up to the task
02:44 < realazthat> but SCIP can do it, no?
02:44 < petertodd> realazthat: TPM hardware is just too brittle
02:44 < zooko> Well, I'm not going to finish reading this chat log tonight...
02:44 < realazthat> I don't mean secret computing, just authenticated
02:44 < zooko> I'll leave it open in a browser tab...
02:45 < realazthat> ie. you can ask someone to do a job
02:45 < realazthat> they give you answer + signature
02:45 < petertodd> zooko: heh, it's deep, but hey, I did say "zooko's triangle" at one point in it :P
02:45 < realazthat> so you can make any problem verifyable
02:45 < petertodd> realazthat: yes, SCIP allows for that
02:45 < petertodd> realazthat: but you have to be very careful about what exactly you are saying the security is
02:46 < realazthat> so you can have people doing cloud computing
02:46 < realazthat> for things like protein folding etc.
02:46 < zooko> petertodd: cool! ☺
02:46 < zooko> petertodd: we didn't speak at the conference.
02:46 < realazthat> in exchange for bitcoins
02:46 < gmaxwell> realazthat: they can monitor the computing though, it's not private when someone else is running it.
02:46 < realazthat> right
02:46 < realazthat> but public good projects don't care about that
02:46 < petertodd> zooko: oh, you were there? too bad
02:46 < gmaxwell> realazthat: they can— go conduct an election.
02:47 < zooko> I saw you arguing heatedly with PVessenes at the core developers huddle. I said to him that the obligations for accounting are not expressed at the level of the Bitcoin protocol, they are merely that you have to "be able to identify+match" customers and their transactions.
02:47 < realazthat> gmaxwell: I don't understand
02:48 < petertodd> I remember that... he really should have kept his mouth shut. Lots of people have taken that as the foundation being actively anti-privacy.
02:50 < gmaxwell> realazthat: conducting an election is obvious public good thing, and the integrity and confidentiality of the election is important.
02:51 < realazthat> ah ofc
02:51 < realazthat> I meant the famous public projects like SETI@home
02:51 < realazthat> and Folding@home
02:51 < realazthat> and other scientific projects like that
02:52 < realazthat> ofc there wouldn't be confidentiality
02:52 < realazthat> but integrity, yes
02:52 < realazthat> homomorphics stuff could do confidentiality perhaps, but AFAIK that is totally impractical ATM
02:53 < petertodd> realazthat: unlikely. SCIP has a pretty big speed penalty, big enough that the usual method of just running work units on more than one computer would be far faster in practice.
02:53 < realazthat> mmm
02:54 < realazthat> interestingly, if SCIP is somehow used for proof-of-work for mining or somesuch, there would be huge incentives to improve it :D
02:54 < petertodd> and/or break it
02:54 < realazthat> yes lol
02:54 < realazthat> but imagine dedicated SCIP hardware
02:55 < petertodd> dedicated hardware typically only makes sense for simple algorithms - I'd be surprised if SCIP qualified
02:55 < realazthat> well, it needs to run a specialized assembly, essentially a VM
02:55 < petertodd> it's a lot more complex than that...
02:55 < petertodd> but I could be wrong
02:55 < realazthat> I think it makes sense to implement the virtual architecture, and take the signing to another CPU or w/e
02:56 < realazthat> maybe
02:56 < realazthat> I look forward to the source codes :D
02:56 < petertodd> I think you need to accept that neither of us know enough to have any idea if that's possible. :)
02:56 < realazthat> end of august for phase 1
02:56 < petertodd> which august? :P
02:56 < realazthat> this august if things go as planned, I guess
02:56  * petertodd works at a 12 year old startup
02:56 < realazthat> lol
02:57 < realazthat> software engineering
02:57 < realazthat> fun
02:57 < realazthat> always ontime :D
02:57 < petertodd> some problems are hard, and just become harder when you try to solve them
02:57 < realazthat> yes
02:57 < realazthat> I am being optimistic
02:57 < realazthat> because I wanna experiment with the so many practical ideas
02:58 < realazthat> that would come to be if it were usable
02:58 < realazthat> mmm
02:58 < realazthat> how about this,
02:58 < petertodd> well, look at how the existence of the blockchain has spawned all sorts of clever ways to use that magical data strucutre
02:58 < petertodd> er... almost none of which are implemented
02:59 < realazthat> mmm
02:59 < realazthat> yeah
02:59 < realazthat> if you have something very interesting that is easy, tell me
02:59 < realazthat> I'll implement it :D
03:00 < realazthat> most of the things I heard were nice ideas, but not very practically applicable
03:00 < petertodd> I'm probably the world leading expert on how to sacrifice your Bitcoins (a rather dubious honor...) and I've done exactly one such sacrifice, and I did it by hand
03:00 < realazthat> unlike SCIP
03:00 < realazthat> haha
03:00 < petertodd> implementing stuff is a lot of work...
03:01 < realazthat> mmm
03:01 < realazthat> I have yet to find something really worth implementing though
03:01 < realazthat> ie. I've seen things that sound nice
03:01 < realazthat> but have no practical purpose in the near future
03:04 < realazthat> (if you do have some ideas that are practical, lay them on me)
03:05 < Luke-Jr> realazthat: any ideas? :P
03:05 < realazthat> well I still get to choose to do them or not lol
03:05 < realazthat> bite sized ideas preferable :D
03:06 < Luke-Jr> realazthat: https://gist.github.com/luke-jr/5409899
03:11 < realazthat> mmm
03:11 < realazthat> both interesting ideas hehe
03:11 < realazthat> so what does ctx accomplish though
03:11 < realazthat> saving space?
03:11 < Luke-Jr> saving blockchain space, lower fees, more privacy
03:12 < realazthat> ah yes
03:12 < realazthat> makes sense
03:12 < realazthat> I don't understand how it works exactly, but thats ok
03:12 < Luke-Jr> <.<
03:12 < realazthat> "Add your signatures"
03:13 < realazthat> doesn't that take away the old signature?
03:13 < Luke-Jr> not necessarily'
03:13 < Luke-Jr> every input has a signature
03:13 < realazthat> right
03:14 < realazthat> mmm, I am just forgetting the protocol
03:14 < realazthat> what ensures that the output is not forged?
03:14 < realazthat> I'll just look taht up
03:14 < Luke-Jr> realazthat: you check it before signing :P
03:15 < realazthat> heh, I implemented a blockchain parser to figure all this stuff out
03:15 < realazthat> but I forgot some details already
03:18 < realazthat> Luke-Jr: so if you could remind me (since you are trying to be distracted anyway, I don't feel bad wasting your time), what stops a client that sees a tx from modifying the outputs?
03:18 < Luke-Jr> realazthat: the signatures include a hash of the outputs
03:24 < realazthat> oh I think I remember now
03:24 < realazthat> the inputs' scripts are written so that they strip all the other inputs and include the outputs
03:24 < realazthat> and they hash that
03:25 < Luke-Jr> yes
03:25 < realazthat> so how do we "fix" this when combining?
03:26 < realazthat> oh ah
03:26 < realazthat> does it go back to the originator who then resigns it?
03:26 < realazthat> and then back to you
03:26 < realazthat> and you resign it
03:27 < realazthat> if thats the way it works, then I think I at least understand it conceptually :D
03:44 < zooko> Here's what I did tonight instead of understanding this channel's conversation: https://twitter.com/zooko/status/340010405525061632
03:46 < realazthat> lol
03:47 < realazthat> is that a safe use of random?
03:48 < realazthat> I would use pycropto or somesuch
03:48 < Luke-Jr> realazthat: the signing is p2p :p
03:48 < realazthat> Luke-Jr: is it how I described?
03:48 < Luke-Jr> almost
03:49 < Luke-Jr> each change is rebroadcast, and everyone participating in it has to resign
03:49 < realazthat> right
03:49 < Luke-Jr> but they don't need to resign in any specific order
03:49 < realazthat> right
03:49 < realazthat> yeah I get it
03:49 < realazthat> I am wondering if I could do this all via the rpc
03:49 < Luke-Jr> probably
03:49 < realazthat> because I haven't touched bitcoin source itself
03:49 < realazthat> yeah I know how to construct the txs
03:49 < realazthat> so I think I can
03:50 < realazthat> mmm
03:50 < realazthat> but does this allow some sort of DOS
03:51 < realazthat> because how do peers know to resend a ctx if some of the sigs are missing/bad
03:51 < realazthat> a valid tx makes sense to rebroadcast
03:51 < realazthat> a half valid tx ...
03:51 < realazthat> I guess if the peer knows the origina ctx, and the new one, and sees that you combined
03:52 < realazthat> then it is worthy to rebroadcast
03:52 < Luke-Jr> ☺
03:59 < zooko> realazthat: good question. It would be unsafe if it were "random.choice" or "random.Random".
03:59 < zooko> But it is "random.SecureRandom", so it is safe.
03:59 < zooko> I wouldn't recommend relying on pycrypto...
03:59 < zooko> Goodnight!
04:00 < realazthat> random.SystemRandom
04:00 < realazthat> "The generators of the random module should not be used for security purposes. Use ssl.RAND_bytes() if you require a cryptographically secure pseudorandom number generator.
04:00 < realazthat> "
04:01 < realazthat> - py.random docs
05:55 < wumpus> the advantage of using SSL random is that it is more portable, it is secure even on systems that have insecure system random generators
05:56 < wumpus> and you can feed arbitrary additional entropy sources into SSL
12:44 < realazthat> wumpus: so random.SystemRandom is fine?
12:44 < realazthat> except for those advantages?
12:44 < realazthat> I would be suspcious of side-channel attacks :/
12:44 < realazthat> and just assume SSL does the most magic that it can
12:45 < realazthat> openssl
12:45 < realazthat> and hi wumpus :D
12:47 < wumpus> nah if random explicitly warns against using it for security you should likely heed that warning
12:47 < wumpus> hi realazthat
12:59 < zooko> There may be some confusion here. There is an explicit warning against using random.Random, not random.SystemRandom.
13:03 < realazthat> mmmm
13:03 < realazthat> "generators of the random module should not be used for security purposes"
13:03 < realazthat> dunno ...
13:03 < realazthat> random module
13:04 < realazthat> bad source of randomness is notorious for side-channel attacks
13:04 < realazthat> even if it is system
13:04 < realazthat> unless it is explicitly meant for crypto, I would not trust it
13:05 < realazthat> anyway
13:05 < realazthat> I don't think your program is susceptable
14:13 < realazthat> mmm
14:13 < realazthat> now that I think about it, if you use SCIP for proof of work in a blockchain, it doesn't really matter if there is a faster way to solve the problem; you must run the program
14:14 < realazthat> no?
14:16 < realazthat> or is that not a guarantee
14:33 < gmaxwell> realazthat: they can just simplify the SCIP computation. :)
14:34 < realazthat> yeah but its at least O(T), no?
14:34 < realazthat> oh
14:34 < realazthat> mmm
14:34 < realazthat> if T is less
14:35 < realazthat> than maybe SCIP is less, is what you saying?
14:35 < realazthat> gmaxwell: are you certain about that?
14:36 < realazthat> basically, to rephase question:
14:36 < realazthat> Is there a guarantee that there is no way to generate sig if a correct answer is otherwise found in a quicker manner than running `P`, the original, via running `Q` instead.
14:57 < Luke-Jr> I don't think SCIP supports sleep() :P
14:57 < Luke-Jr> almost certainly not random
14:58 < realazthat> mmm
14:58 < realazthat> thats beside the point
14:58 < realazthat> but anyway it does support random AFAICT
14:58 < realazthat> because you can have that as input
14:58 < realazthat> ie. int[] randoms
14:58 < realazthat> and input can be private
14:58 < realazthat> my point is,
14:59 < realazthat> can you do BogoSort
14:59 < realazthat> and force him to actually do bogosort
14:59 < Luke-Jr> but you can't guarantee the input was chosen randomly
14:59 < realazthat> or can he do an optimal sort instead
14:59 < realazthat> oh yeah
14:59 < realazthat> probably not
14:59 < realazthat> but again, I don't see how that answers or related to the question I am asking
21:02 < warren> http://www.coinchoose.com/charts.php  <--- looks scary, suggesting a lot of people are assigning stupid value to scam coins
21:02 < warren> but the methodology is wrong, the alts are a lot smaller than this chart suggests
21:46 < petertodd> warren: remind me to start an altcoin called "OneCoin" that has exactly one coin, just so I can claim is has a much higher OneCoin/USD ratio than Bitcoin itself
21:49 < Luke-Jr> ask them to replace BTC with kBTC
21:49 < Luke-Jr> <.<
21:54 < realazthat> ohcool
21:54 < realazthat> I gonna email eli
22:57 < zooko> Okay I finished reading http://pastebin.com/Rj4bshY3
23:51 < realazthat> mmm
23:51 < realazthat> just sent email
--- Log closed Fri May 31 00:00:51 2013