00:01:33 andytoshi: ... bad luck on that thread on bitcointalk. 00:02:12 luck? O.o 00:08:05 haha 00:08:45 i think i made him look like enough of a tool that people will hesitate to use his software 00:09:06 (not that people who need encryption would be searching bitcointalk anyway) 00:09:08 andytoshi: still waiting on that to work with tux 00:24:30 are there any serious or semi-serious proposals for how to fix an altcoin 1:1 to bitcoin without a large cost to bitcoin miners given some hardfork changes to bitcoin? 00:26:38 if not for the disabled operators you could probably do it without hardfork changes to bitcoin, though you would only have SPV security in the altcoin-bitcoin direction. 00:27:16 even getting spv security in the altcoin-> bitcoin direction is non-trivial, no? 00:27:26 (given hardfork to reenable opcodes) 00:27:54 you'd have to have the whole chain history, or some subset starting from the time of the bitcoin->altcoin transfer 00:28:03 well, whole block-header-chain-history 00:28:27 yea, you just write a script that can do a spv validation and then takes a chunk of headers of a prespecified sufficient difficulty. 00:28:44 the proof can start at the point the txn of interest was mined. 00:28:45 that gets pretty expensive? 00:28:57 I mean, it's 80 bytes per header. so not really. 00:29:02 very expensive if you hold the alt for an extended period... 00:29:21 well, no miner is gonna mine a tx that is 80 bytes*N where N is a few weeks/months of headers 00:29:24 BlueMatt: oh no, you don't do it over the life of the alt. 00:29:32 crazy no no thats not how it works. 00:30:25 you take some coin and assign it to a scriptPubKey that can be redeemed by anyone who provide a SPV fragment from the altcoin showing any of those coins being reassigned back to bitcoin, with a sum difficulty of at least X. 00:30:47 gmaxwell, BlueMatt: a 1:1 peg - doesnt that import security risk from the alt into bitcoin? (i suggested a 1 way peg "bitcoin staging" only so bitcoin is security firewalled) are we talking about the same area of feature 00:31:39 adam3us: only to the limit of the alt. say the alt was somehow totally insecure... you could then steal all the bitcoins that had been assigned to the altcoin. 00:31:44 but no more. 00:32:01 gmaxwell: hmm that might be ok 00:32:18 adam3us: what gmaxwell said (if you decide to put your btc in the alt, sucks for you) 00:32:43 BlueMatt: one problem there is that isn't really spv security, its "spv transcript" security, in that the bitcoin network isn't going to go out and find a longer chain. 00:32:48 BlueMatt: yes that is an acceptable trade off and already at risk with a 1-way peg 00:33:20 BlueMatt: But I did come up with a way to boost that to more like real SPV security with a bit more script power. 00:33:33 gmaxwell: well, ok, sum difficulty is one way...but very non-ideal 00:34:18 (you make the relase of coins back into bitcoin two phase. The first phase you do a header proof for the release.. and that gets mined.. but it can only output to a special holding script with the following rules: 00:35:13 after N blocks the releasing party can grab the coins. OR at any point, any party can show a longer chain to prove the release was bogus. and then they can only be redeemed with a new release on a chain longer than that one. 00:35:55 In any case I think most of the stuff thats been said of any technical substance on this is in the coinwitness thread (where I suggest using SNARKs for C to compact the proofs, though its not essential): https://bitcointalk.org/index.php?topic=277389.0 00:36:17 obviously if you compact the proofs things start sounding more interesting from a scaling perspective. 00:37:04 also if the headers of the altcoin form a MMR (insertion ordered binary tree) it may be cheaper to prove long spans of difficulty. 00:37:09 yea, though depending on cutting-edge crypto is ugly... 00:38:02 BlueMatt: well there are less ambitious (efficiency wise) ways to construct these proofs, but they're larger... though I'm not sure if we could get the direct proofs down with special support. Maybe. 00:38:08 SPV fragments can be pretty small. 00:39:02 yea, its all a bit expensive, really 00:39:23 it would be fun to be able to peg arbitrary altcoins to bitcoin as it really addresses the issues altcoins cause 00:40:02 allows them to innovate (ie risk people's money) while not costing bitcoin's digital scarcity/competing on store-of-value 00:40:51 BlueMatt: one way is easy— just have them validate bitcoin too. 00:40:55 BlueMatt: agreed 00:41:57 BlueMatt: one point is that you could coinjoin your cross chain merges perhaps, to make them smaller. e.g. one proof and then a dozen transactions hop the gap. 00:44:18 gmaxwell sure, but if you only peg one-way its really not particularly useful 00:44:40 well, it is, but not as useful 00:44:54 gmaxwell: sure, you could limit to like 1 coinjoin'd alt->btc tx per day 00:45:03 but even that could be expensive 00:45:29 I dunno, I mean, it's a seralized transaction and spv proof, plus some additional headers. 00:45:43 well, if you have 100 alts all doing that, it does 00:46:04 BlueMatt: I like 1:1 peg idea, I only suggested 1-way peg to insulate security, if you can insulate security to the coins in the alt, thats even better 00:47:41 as long as you limit it to the people who transferred their coins... 00:47:49 gmaxwell: hmm... 00:47:57 lets say there are 2^12 txn per altcoin block, ... lets imagine you make the altcoin txn themselves hashtree so you can get to only their outputs.. so say maybe 64 bytes for the altcoin output, 384 bytes for the spv tree. 4 bytes for a spv index, and 12 80 byte headers = 1.4k. 00:48:15 it's bigger than a typical ecdsa signature, but not murderous. 00:48:48 and if they coinjoin the biggest parts (960 bytes of headers, 384 bytes of hashes) can be shared. 00:49:56 adam3us: yea, I don't think there is a security need to make it one way. If you can never "pull back" more from an altcoin than was sent to it, then only the holders of the altcoin are at risk. 00:50:43 gmaxwell: seems plausible indeed, i just didnt think of it in those terms at the time. good 00:51:22 the altcoin is also a bitcoin node, and monitors bitcoin for coins assigned to the altcoin, and then permits someone on the altcoin to emerge those coins from thin air.. and then when you want to send them back you make a special transaction in the altchain and prove you did it to bitcoin. 00:51:23 gmaxwell: i suppose the other thing is it itself requires bitcoin changes, perhaps non-trivial ones, and that is part of the reason for the exercise. 00:51:46 yea, unfortunately it requires changes to bitcoin. 00:52:18 we could _almost_ do it in script without the disabled opcodes, but there are enough little corners that I suspect we can't. 00:52:19 gmaxwell: but an interesting enough change perhaps for motivation to be there as it creates an avenue for value preserving experimentation 00:52:24 12 blocks seems shallow to me given most altcoins have no miners... 00:53:00 * BlueMatt thinks this solves the "alt problem" 00:53:04 BlueMatt: probably have to overcome the merge mining / side chain incentive problems somehow 00:53:13 BlueMatt: yes i like it a lot :) 00:53:46 ***adam3us wants to destroy all new digital scarcity race alts 00:53:46 BlueMatt: namecoin's difficulty is 81% of bitcoin's. 00:53:59 gmaxwell: really? wow 00:54:11 gmaxwell: thats because of heavy merge-mining tho because its been around for a long time 00:54:13 I seem to recall telling you this at the meetup here too. :P 00:54:24 adam3us: sure, but this would be merged mined too. 00:54:36 Now, one annoying issue is that MM makes the @#$#@$@# SPV proofs much bigger. :( 00:56:05 gmaxwell: though it does mean bitcoin miners with bitcoin blocks can do more verification :) 00:56:06 basically doubles the hashtree size plus the size of a bitcoin coinbase. 00:56:18 (though not with existing disabled script opcodes) 00:56:54 in any case, its doable and not unrealistic. 00:57:27 personally, if there's one feature we should enable in bitcoin (testnet) its this 00:57:55 it's not even a hardforking change in bitcoin. 00:57:58 but, we need f**$@#%@ reviewers 00:58:00 it can be deployed like p2sh. 00:58:08 well, to re-enable the script opcodes... 00:58:46 well this needs a bit more than script opcodes, and really, to make it efficient it would probably best be implemented directly. 00:59:42 yes 01:00:36 one optimization would be to have only SPV security inside bitcoin for those proofs too. 01:01:15 E.g. the txn that releases coins in bitcoin has just a hash of the proof in its scriptsig. the actual proof must be provided along with blocks but only until they're sufficient burried in bitcoin. 01:01:45 (after all, if the emergence in the other chain has only SPV security, no reason to have better security in bitcoin) 01:01:46 gmaxwell: i was going to ask how does bitcoin know the transaction is non orphan on the alt? 01:02:10 adam3us: thats what the 12 or whatever headers are for from the alt. 01:02:49 gmaxwell: i might make it 100 like mining confirmations 01:03:22 100 was fairly arbitrary 01:03:25 though I dont like 12... 01:03:38 whatever, the altcoin could actually signal it with something in its headers. 01:04:15 yea 01:04:16 the big problem with making it big is that it creates a release delay in moving the coins back. 01:04:47 meh, who cares 01:04:55 even if the release delay is a day... 01:05:12 there are altcoins with 30 second blocks that advertise confirmed = 3 blocks … 01:05:45 meh, I dont care about altcoins that are working at dumb knob-tweaking, I'm talking about altcoins that do actually useful research 01:06:22 well, its a fungiblity thing. It's not really a bitcoin if it has a 24 hour ramp to move across. But one interesting thing is this: You could do CoinSwaps nearly instantly with reasonable security. So the real migration doesn't need to be fast because it's only needed to correct long term imbalances. 01:07:23 yep, thats what I was thinking 01:07:45 its really only to peg the value, not to act as something that need be traded regularly 01:07:45 gmaxwell, BlueMatt: yes agreed; cross chain atomic swa 01:08:06 gmaxwell: even with 1-way peg i was thinking it should have mostly balanced 01:08:07 (coinswaps require there to be two parties, one that wants altBitcoin and has bitcoin, one that wants Bitcoin and has altBitcoin... nice little trading business... but you need the bulk moves in order to not be constantly going broke on one side or the other) 01:09:12 and yea, in that case requiring 100 headers would be fine.. (but damn that would really bet nicer with a snark than 8kb++ of header data in the txn) 01:19:15 arguably, this is exactly the way to experiment with snarks 01:19:58 andytoshi: unless its your bitcoins in the alt :) 01:20:27 :P that's right, i keep forgetting these things are so valuable 01:23:22 IMO SINs are the best snark expirment. :P 01:25:25 BlueMatt: some extra points you might have already realized: the altcoin itself can do the "coinjoin". You make a tx there with a special ToBitcoin Txout and it adds a scriptPubKey to a list maintained by miners, and every {interval} that list is published in the block in a location that makes the proof for it really compact (e.g. at the top of the hashtree) and it has all the values and scriptpubkeys that need to move over. 01:25:47 yep 01:26:18 wait...can you do rolling outputs to the alt? 01:26:30 The next is that point I made about the redeem transaction being temporarly locked and 'reversable' via a longer chain means you don't need to have a long proof.. just a couple headers to prevent a dos attack, if someone cheats someone will unsteal the coins with a longer proof. 01:26:49 thats rolling outputs from the alt to bitcoin. 01:27:18 ie the alt always has one and only one output to it (if its in the standard form, anyone can create the next txn) that keeps track of all the outputs to the alt, and then to spend, you have to provide spv proof from the previous roll to the currnet chain? 01:27:40 Guest24232 is now known as amiller 01:27:46 yea thats what I was imagining the whole time. 01:27:55 ahh, ok, yea 01:28:13 somehow I was only picturing individual outputs and arbitrary spv proofs back some fixed distance 01:28:36 gmaxwell: some of us are slow :p 01:28:41 nah, then you get into granularity problems. :P sorry. 01:28:58 darnit I had one more idea and now I'm forgetting it. 01:29:01 yea, it seemed to not scale... 01:29:30 BlueMatt: give altcoins an annual demurrage rate of 50% 01:30:03 oh, how they pay their miners? I figured miners in the alts would be purely paid by transaction fees.. in bitcoins. 01:30:28 gmaxwell: yes, thats something I was largely ignoring for complexity reasons...needs thought 01:30:45 maaku: hmm? 01:30:48 that's a neat question, BlueMatt. 01:31:04 BlueMatt: oh ohoho the other point wrt security.... nothing stops bitcoin miners from also validating the altchains, they're just not required to. So if they do see a bogus proof they can just ignore it unless it gets into the chain. 01:31:14 was reading the log; that's for experimentation in an altcoin without threatening bitcoin as a store-of-value 01:31:57 maaku: well, there are plenty of ways to accomplish it, I just wanted to do it while allowing good scaling/storing value in btc in altchains 01:32:06 gmaxwell: hmm, yes 01:32:08 fun 01:32:36 though I think since we're willing to tolerate long release times, the ability to unsteal with a longer header is pretty good. 01:33:05 yup 01:41:41 chilero_ is now known as chilero 01:58:46 hello 01:59:01 can someone point me in the right direction for selling my 2011 first month of mint casascius bitcoin with the error in the hologram. the error is a misprint in the background of the hologram the casascius is missing the middle s 02:00:18 terribly, terribly wrong channel 02:01:28 ty bluematt i understand i am in the wrong place but as wizards should't you be able to help? 02:01:36 ebay? 02:02:20 valek1024: no, we cant help, go elsewhere 02:02:52 valek1024: we could design you a secure multi-party cryptographic auction protocol 02:03:06 but finding buyers is your job ;) 02:03:12 maybe #bitcoin 02:03:17 see that is helpfil 02:03:27 helpful 02:04:03 No. #bitcoin-otc for selling goods. 02:04:07 there is and was no reason to be rude sir, i was simply asking for help 02:04:22 #bitcoin will boot for that. 02:05:00 (we should too) 02:35:58 chilero_ is now known as chilero 02:41:58 gmaxwell, BlueMatt: suggest to write this up and get further details and efficiency worked out. i think its potentially very useful to combat the remaining rationale for the existence of alts (other than enriching their creators, preminers and early rented vsp early miners before their no real transaction bubble bursts) 03:34:19 adam3us: it also adds to the scalablity dialog... but perhaps what we should do is just do a trial implementation. 03:35:55 gmaxwell: yes! 03:35:59 you should totally find time to do that 03:36:33 fantastic :) i can maybe help out in some way 03:37:29 keyword *you* 03:37:55 Tweedledee coin, and tweedledum coin. 03:40:07 heh, yup 03:41:35 are the currently available snarks viable for a trial implementation? 03:41:40 don't these proofs take days to generate? 03:47:10 andytoshi, you can download pinocchio and use it now 03:48:08 andytoshi: if at all possible i would suggest to start with seeing how efficient it can be made without dependence on snark, bitcoin has simple & conservative crypto assumptions so far and that is a feature 03:48:10 andytoshi, it unsurprisingly relies on a windows binary kernel to run the actual fast crypto, but most of their actual work is in python and they're almost done making it fully open 03:48:45 andytoshi, it takes 15 seconds on a single core to prepare a proof about SHA1 on a small input 03:49:36 andytoshi, you can also use pantry, it's fully open but has baffling dependencies and i haven't personally gotten past that 03:50:31 awesome, i'll check them both out 03:50:42 adam3us: i think you are missing the point :) 03:51:13 andytoshi: to not lose bitcoins and enable alts to respect the 21 mil digital scarcity? 03:51:37 no, to be a wizard ;) 03:53:32 andytoshi: homomorphic encryption is cool too, but impractically inefficient. snark is cool and related and practically efficient, but has some newer crypto assumptions in my view. you dont want an alt to go up in smoke if someone finds a mathematical flaw in the deployed pairing params (eg) 04:01:08 in my view, the effort of trying to optimize an implementation of traditional homomorphic encryption is almost certainly an overoptimization 04:02:01 er premature optimization 04:03:02 well, that'd be a research project in itself 04:09:38 hey, pantry was developed partially here at UT austin 04:09:44 i can track these people down and ask how to build it :P 04:11:36 andytoshi: wait, you're in Austin? :o 04:12:59 Luke-Jr: i started my ph.d. here this september 04:13:11 i'm usually from vancouver 04:13:47 andytoshi: doh, I was just there last week XD 04:13:59 coulda met up 04:14:09 oh! damn 04:15:42 if we had a picture together, that'd show altoz that i'm not a sock puppet.. 04:16:24 altoz is silly, complaining that we're being rude(⁈) when his posts are the only ones that strike me as particularly rude O.o 04:16:47 yeah, i read through yours just to be sure, and that's my interpretation too 04:16:59 all i did was post a link and say "don't be rude" :P 04:17:50 about the rudest thing I did IMO was decide I wasn't responding to some stupid comments of his <.< 04:18:39 " 04:18:41 I am using ECIES, I think. I would need a more experienced cryptographer to examine the code to make sure, but it's fairly straightforward." 04:18:58 this is his latest resposne to "are you using ECIES?" 04:19:05 imo you should've been much ruder :P 04:20:24 lol 04:27:58 andytoshi: only the pinocchio (without the pairing crypto backend. :( ) and the pantry system are available 04:30:25 you mean the zk-snark stuff is not public? 04:34:33 pantry and pinocchio are both zk-snarks 04:34:54 there are three zk-snark implementations, pantry, pinocchio, and tinyram, of these tinyram is not yet available 04:36:35 oh, i see, thanks 04:37:14 i have only read the first couple pages of this latest paper, i think it talks a lot about the background 04:37:34 so i'll try to get straight what's been happening in this field 05:18:06 chilero has left #bitcoin-wizards 06:59:02 nOgAn0o is now known as nOgAnOo 07:31:21 well pinocchio is only kinda public, the circuit generator is public, but without the underlying crypto libraries, it's not useful. 07:34:11 amiller: oh have they made the resot of pinocchio public now? 07:35:33 in any case, I think the obvious thing to do with pinocchio/friends is make a blind sin proof. Though I don't see how to do it without having an ecdsa verification under the proof... which is probably going to hurt a bit. 07:36:04 s/verification/signature/ in fact. 07:38:21 e.g. You make a proof of the statement X is the hash of a determinstic-signature of data Y, using a key, committed to by a SIN transaction paying >=Z in fees, spv connected to header Q. 07:39:14 Feed in the name of a site in Y "bitcoin talk" and X is an identity you use to log into the site that can be banned, and replacing it costs you Z bitcoin. 07:39:38 But the site learns nothing about which bitcoin were yours... or nothing about identities you use on other sites !Y. 07:40:11 and if the proof takes a cpu hour to compute, well that actually doesn't reduce the usefulness all that much. 08:01:21 can I ask a dumb question?...whats a sin in this context? 08:02:50 google identity protocol 08:02:57 oh gribble's not here 08:03:25 ahh, ok 08:03:33 my google-fu was looking in the wrong places 08:03:40 https://en.bitcoin.it/wiki/Identity_protocol_v1 08:03:42 yeah 08:04:58 * maaku is still waiting for someone to come up with a v2 protocol so we can have a lively debate about the merits of original SIN 08:06:11 has anyone even started implementing identity protocol? 08:09:14 ahh, yes, there is 08:11:18 heh, ofc jgarzik wrote it in node.js... 08:33:29 * gmaxwell groans at maaku's pun 08:38:36 hey, its better than HD wallets 08:39:18 I continue to think HD wallets is a perfectly good name. 08:39:46 I continue to disagree (though considering how often I'm mia, thats rarely useful) 08:40:26 ;;ticker 08:40:27 MtGox BTCUSD ticker | Best bid: 500.5, Best ask: 500.97, Bid-ask spread: 0.47000, Last trade: 500.97, 24 hour volume: 48505.69491744, 24 hour low: 500.5, 24 hour high: 774.9899, 24 hour vwap: 628.33712 08:40:32 oops wrong window. :P 08:40:58 well, thanks for reminding me to buy cheap coins :) 14:21:21 maaku, gmaxwell: pun already made: http://garzikrants.blogspot.com/2013/08/original-sin.html 15:56:41 * Luke-Jr ponders how to respond to altoz this time. 16:12:34 i think he's just going to keep claiming not to be able to read what you're saying 16:13:09 if you PM him, idk if he'll receive the message if you're on his blacklist 16:34:22 Luke-Jr: I advise just dropping it. 17:12:00 Luke-Jr: I cracked his cryptosystem 17:12:47 lol 17:12:53 wow, nice 17:22:57 This is what I sent him: 17:23:03 Incidentally, I can compromise your cryptosystem for a single message with 2^64 known-ciphertext queries to a decryption oracle. E.g. you run a server that decrypts messages and returns the results and I obtain the ciphertext of a message someone else created (which the oracle refuses to decrypt for me, otherwise this would be trivial), and after making ~2^64 queries to your decryption oracle I can decrypt the unknown message. 17:23:09 This isn't the most grievous of weaknesses, but its somewhat surprising, and I could imagine someone using this in a way which made it actually exploitable for something. 17:23:12 I'm being a bit oracular because I thought you might enjoy figuring out what I'm thinking. 17:24:04 (I was hoping it would be 2^32 queries— then it would be reasonable to put up demonstration code) 17:24:13 (alas) 17:25:16 brute-forcing the keyspace would be 2^256? 17:27:21 ah, no, he is using aes-128 17:28:03 * gmaxwell refrains from giving hints. 17:28:43 sbbodhtimrj is now known as jrmithdobbs 17:29:07 im just wondering what oracular means 17:29:33 guess synonym verbose 17:29:41 Emcy: i think, you have to submit questions to gmaxwell, and he will decide whether to answer them 17:31:02 or rather, altoz does 17:31:43 Emcy: Where I say that I'm being oracular, I'm referring to the point that oracles— of the classic sort— answer questions in riddles. 17:32:18 "In Classical Antiquity, an oracle was a person or agency considered to interface wise counsel or prophetic predictions or precognition of the future, inspired by the gods." 17:32:28 hmm thats my werd lernin for today 17:33:17 how dod you get to know so much about crypto? Do you have any formal math background? 17:33:26 In my attack description I'm using the world oracle in the sense used in cryptographic lit. ... an oracle is some black box that performs some function. E.g. a remote server that signs messages for you or decrypts things for you would be an example of an oracle. 17:35:37 well I majored in math before I dropped out of college... but no, I was just one of those annoying kids who read most of the books in the library and remembered a few of them. 17:36:04 hmm ok pretty cool 17:36:36 its one thing to learn the maths it another to break someone elses maths 17:37:34 i had a tutor once who impressed upon me the difference between learning by rote and the power of original thought 17:37:50 he said the former end up tutoring in college and the latter end up tenured in university 17:37:58 I think a lot of people are short changed by education which focuses on learning by rote. 17:38:08 haha 17:39:59 The annoying thing about breaking cryptosystems is that even when you find a neat flat it usually only gets you 99% of the way there, but you can't expand it to a full compromise because of some accidental detail which isn't _just right_ for the attack to work. In this case I think it would actually work (I guess I could go weaken it further to be completely sure). 17:40:05 s/flat/flaw/ 17:40:50 is 2^64 queries to some soerver actually viable though 17:41:10 Yes it is, though not enough to demonstrate easily. 17:41:30 Or at least close enough to viable that its a surprising weakness. 17:41:53 Emcy: e.g. what if the "server" is a bitcoin trezor like device in your possession? 17:42:19 cry 17:42:45 But I mean that that often weaknesses are such that even allowing for "unreasonable" freedoms like 2^64 queries to a blackbox decryptor you still can't break it. 17:42:58 at least 2^64 packets over the actual internet though. Seems like a faff. Suppose you could be in no rush though 17:43:22 (It's hard to say if thats unreasonable or not, depends on the applications. Thats the bummer about generic constructs) 17:44:00 Emcy: yea, before I looked at the code again I thought it would be 2^32, in which case it would have been trivial even over the internet. 17:44:21 still i think 2^64 or 64 bits or whatever is not something you want to see in any cryptosystem any more afaik 17:44:37 right. 17:45:11 2^32 is only like 4 billion right 17:45:14 Right. 17:46:23 If there is also a simple software bug I can reduce it to one query. 17:46:32 Emcy: things like decryption-oracle attacks are fairly standard in cryptography and there is a lot written about them 17:46:47 like "Random Oracles are Practical" by Bellare and Rogaway is a paper the wizards pointed me to 17:46:55 would that be how the wifi hacks work 17:46:57 But I suppose that for some definition of "bug" thats always the case, e.g. bug: gives up the private key. 17:47:10 wifi attacks i think showed up on matthew green's blog.. 17:47:22 you packet inject until you get enough back to recover the key 17:47:38 the router is the oracle? 17:48:33 ah, yes 17:48:36 http://blog.cryptographyengineering.com/2011/09/when-things-fall-apart-part-1.html 17:48:39 Emcy: yea, well, the wifi attacks are very specialized... WEP uses RC4 which is a stream cipher, you put in a key, it puts out an infinite stream of 'random' bits. These bits get xored with the packets. 17:49:18 If RC4 were a perfect, you wouldn't be able to learn anything useful about the key just by knowing some of those random bits. 17:49:25 RC4 is far, far from perfect. 17:50:03 If you know some data in a packet, you can take an encrypted packet, xor it with the data you know, and you'll learn the output of RC4 in those known positions. 17:50:57 So the WEP attacks usually work by replaying an encrypted arp request (which you reconize by the size). The router acts as an orcale producing a stream of ARP replies which are encrypted. 17:51:08 But you know some bits of the arp replies because they're fixed in the packet syntax. 17:51:17 ha i was right 17:51:24 and some because they copy data from the arp request. 17:52:16 So you gather a bunch of rc4 output with different initilization vectors (incremented in every packet), and you can setup a system of equations that derrives the key. 17:53:22 Nothing _quite_ so fancy is needed for this encrypted message thing. 17:54:39 what you described doesnt seem so fancy to me 17:54:58 just seems like pattern matching 17:55:07 you just need enough pattern 17:55:39 sure, the gist of it is simple, the math somewhat less so. 17:55:51 sure 17:56:13 I find that nothing accomplished by men is actually all that complicated once put into the right terms. Otherwise we couldn't accomplish it. 17:56:49 do we have any systems that are too complex for a single mind to grasp alone? 17:56:59 layout of a modern CPU perhaps 17:58:02 sure, but you break them down. 17:58:28 And all the parts are sensible in isolation, and the overall design— ignoring the details— is also sensible. 17:58:59 It's actually quite reasonable to build software systems which are vastly beyond the ability of one person to comprehend at least all at once. 17:59:46 yes, but things get interesting when someone goes wrong due to an emergent property of how the parts interact. And no one can figure it out because no human has the cubic centimetres of brain required...... 18:00:08 i wonder if humans have a system like that anywhere 18:00:30 the OPERA neutrino thing maybe? that stumped em 18:01:28 Things like that crop up all over the place, we get them in Bitcoin... they show up in any sufficiently large piece of software or hardware design. In digital electronics you'll sometimes have problems when analog effects that you thought you could ignore crop up. 18:02:11 obviously its not such a big problem as i think then 18:02:51 are there any cryptosystems that are unkowable in full by human mind? 18:03:51 Well... 18:04:17 We depend on knowing the thing in order to make arguments for its security. Modern cryprosystems are build out of simple regular parts. Otherwise if you make something too complex you'll miss a weakness which will be obvious to someone who 'looks at it from another angle'. 18:04:27 So all the primitives we use are quite simple and straighforward. 18:05:13 Though in more recent times people have been building taller towers, systems which are only simple if you abstract away the details. 18:05:43 but they dont always interact in the way you think they should. 18:06:28 perhaps one day we will throw together enough primitives that it will turn around and ask us for clemency..... 18:09:40 Emcy: there is a good lesson about this in the history of tls 18:10:22 http://blog.cryptographyengineering.com/2012/09/on-provable-security-of-tls-part-2.html 18:12:26 im sure it is provably secure, the auth part is letting it down badly though these days 18:13:16 that link has a short blurb about the MAC fiasco in the 90's 18:14:05 wots taht 18:14:11 nm ill read 18:15:36 it's a classic "things interact in surprising ways when you pile them on" story 18:15:47 and the complexity of that probelm was not even very high.. 18:17:23 from what ive seen almost no servers still dont use tls 1.2 18:18:00 yeah, i don't think browsers will even accept tls 1.0 18:18:15 i always thought people used old shit because its been in the trenches longer than new shit. 18:19:46 i saw a server with tls 1.0 and 1024 rc4 or something recently 18:20:03 thats pretty bad 18:22:12 jesus christ it just rained the hardest its ever rained around here in 30 years 18:22:30 it was raining upwards....... 18:22:44 wall of water 18:23:26 well, i am off to the airport, good talking to you guys 18:24:30 good flight 18:24:33 oh 18:34:37 god dammit planetside 2 has been down for hours 18:35:04 i spose thats why its free 18:56:33 andytoshi, your link on tls -- reminds me of that scene from one of the hitch-hiker's guide books... 18:56:38 "Arthur goes to the village. He finds a woman seer who swats at flies in front of a cave. She smells horrible. She does her dead goat-like animals. He helps her take her photocopy machine out into the sun because it is solar-powered. She hands the photocopies to him. It is the story of her life. He should read it and not make the decisions she made to end up alone..." 18:56:42 ( http://www.bookrags.com/studyguide-mostly-harmless/chapanal005.html ) 18:57:05 someone should teach a remedial history of the internet, annotated at every point where we fucked it up 18:57:15 in case we get a chance to start over at some point :) 19:51:58 what do you think of **********DOGE********* 19:57:28 * nsh looks at eclark pointedly 20:07:42 gmaxwell has kicked eclark from #bitcoin-wizards 21:04:09 spinza_ is now known as spinza 21:59:06 andytoshi, luke: I went and posted the description of my attack on that cryptosystem. (since he tried and didn't figure it out and asked me to explain it) 22:03:01 gmaxwell do you have a link? 22:05:11 jtimon: https://bitcointalk.org/index.php?topic=374085.0 22:07:05 thanks 22:24:37 i don't really understand the assumption that you'd want to have much correspondence with someone you just performed a pseudoanonymous one-time transaction with. i rarely feel the urge to call the hot-dog stand for a chat... 22:25:04 warren has left #bitcoin-wizards 22:26:16 maybe authentication to some service that the one-time transaction paid for 22:26:35 mmm 22:34:31 people generally handle their bitcoin private keys more securely than most other kinds of private keys, so services that are cobbled together ontop of bitcoin's PKI smell ultra-secure 22:36:27 heh, shit...they recovered rsa pgp private keys from the noise a cpu makes... 22:36:36 yeah, was reading about that today 22:41:17 BlueMatt: none of the crypto we use for bitcoin is timing/power side channel immune. 22:41:39 I don't believe there exists constant time implementations of the primitives for secp256k1 at all right now. 22:41:54 gmaxwell: I didnt think they were, I just found this particular paper fun 22:42:14 i wonder how much of the efficiency advantage of EC is lost with constant time primitives... 22:43:12 nsh: the curve25519 stuff is constant time, and stupid fast... but its partly a result of having picked parameters with that in mind. 22:43:22 hmmm, okay 22:44:19 i wish djb would release the minimaLT code :/ 23:06:44 dear god. 23:06:54 this guy is wasting unbounded amounts of my time in private message. 23:07:14 so ignore him? 23:07:26 or limit your bw 23:07:28 I had hoped that I'd not be able to waste any time on him by dispatching luke to respond on the threat, but that ended up like a cesium / water reaction. 23:07:39 s/threat/thread/ 23:08:07 dude is convinced he's going to revolutionize bitcoin with his grand ideas, but his only expirence is with bc.i. 23:08:15 and he's all confused about how bitcoin works. 23:08:26 and every exchange I have with him is revealing another understanding. 23:09:00 like after message 6 I discover that he's planning on 'solving' the problem that the "messages in transactions are cleartext". 23:09:11 * nsh chuckles 23:09:24 gmaxwell: there are a dozen people on bitcointalk like that 23:09:51 if only the ignore bit were an option :\ 23:09:58 And the idea that a business that ships out goods to people would generate a new address for each payment seems to be completely foreign to him. 23:10:11 maaku: a dozen? really? theres like a few thousand... 23:10:16 heh 23:10:27 I could ignore him but I don't want him going and fucking stuff up with his earnest enthusiasm. 23:11:44 there should be a crypto playpen tarpit for people 23:11:56 * maaku fully expects him to find some inestor willing to throw insane amount of money at his ideas 23:12:39 or...we could just let people implement dumb crypto primitives, and use idiots to steal coins from 23:14:46 part of the problem, of course, is that even the broken and dumb ones are seldom so bad as to enable theft. 23:15:04 yup 23:15:56 like— this guys busted ass cryptography still would take 2^64 queries to a decryption oracle to crack one message. Even if someone had convinced him to reduce the mac to 32 bits, it likely would have only rarely been a pratical attack. 23:16:20 he also thinks he can do things with transaction "from" addresses. 23:16:54 how much would it cost to put an ad on bitcointalk that just says "THERE IS NO FROM ADDRESS, GET THAT THROUGH YOUR HEAD, IF YOU DONT GET IT, GO AWAY" 23:17:02 ehehe 23:17:50 BlueMatt: I wonder what the revenue stream from bc.i is? It can't be that great if its really just the ads and they don't have income from spying on people or whatever. 23:18:11 We could raise money to buy it and shut it down. 23:18:14 Without notice. 23:18:24 they have pretty reasonable vc funding iirc 23:18:32 so...they must have some business model, somewhere 23:18:33 And a full screen "HA HA WE TOOK YOUR MONEY, YOU WERE AN IDIOT FOR USING A CENTERALIZED SERVICE" 23:18:38 darn 23:18:40 even if its "down the road, we..." 23:18:48 (3) profit. 23:21:03 money up for grabs: https://telegram.org/crypto_contest 23:23:39 http://core.telegram.org/techfaq 23:24:30 uh. 23:24:38 that seems really dishonest to me. 23:25:02 it looks like the security is dependant on their server handing out the correct keys. 23:25:36 they claim you can also do dh p2p and then compare some image that represents the shared key or something 23:25:47 * BlueMatt didnt read closely, it just said "compare image after dh exchange" 23:26:48 Who are the bears? 23:26:58 gmaxwell has kicked nOgAnOo from #bitcoin-wizards 23:28:02 I wonder why they're using sha1, especially when they need 512 bits of KDF. 23:48:12 I see that news.ycombinator.com has similar thoughts to me, https://news.ycombinator.com/item?id=6931457 23:51:13 "Yeah, it's probably against the rules of the competition and will get you arrested if you try. But I think if someone does break into their central server and wins the competition that way, they should still be paid out." 23:51:15 i like those odds! 23:53:47 * gmaxwell contemplates that google search you did earlier today in #bitcoin ... :P 23:54:23 * nsh smiles 23:55:25 hm. I was trying to see what their physical location was, and it seems to be run by totally anonymous parties? 23:57:35 can you sell on the google play store anonymously? 23:58:34 LLCs are registered, but anyone can call themselves X LLC https://play.google.com/store/apps/developer?id=Telegram++LLC