00:00:35 possibly William / Jordan A Baker http://trademarks.justia.com/860/10/telegram-86010749.html 00:00:41 (no mention of encryption in the trademark application though) 00:01:45 ( http://companies.findthecompany.com/l/32066563/Telegram-Llc-in-Wilmington-DE ) 00:21:33 chilero_ is now known as chilero|Away 00:32:46 BlueMatt has left #bitcoin-wizards 00:43:47 hmm this coinmessage thread is locked so i cant join in! i was going to explain that what the sender claims is R.x from R=rP can be s st there is no solution to s=f(x) ie s is not on the curve. he doesnt seem to get that (re comments about s being > n) 00:45:49 I thought I mentioned x could be not on the curve! I think his code actually tests though. 00:47:06 gmaxwell: ok. just his response to your explaining that was "an invalid nonce means the attacker sends an x that's past p but less than 2^256." which is not the point at all! 00:47:24 oh I didn't even notice that. 00:47:31 (that he responded to that point) 00:48:57 gmaxwell: #11 - is it locked because he did that as the thread starter? 00:50:05 No. I locked it because it was becoming a totally stupid war. If you'd like to post I can unlock it. 00:50:15 I've been talking to the guy in PM and woah lots of misconceptions. 00:50:30 adam3us: do you like my attack? 00:51:01 gmaxwell: yeah dont worry. it was him creating the flame war. 00:52:41 Is there any client that has a "message" field that autosubmits the message to bc.i? 00:53:01 guy in PM is telling me that his desktop client has a "message" field that he thought showed up on bc.i. 00:53:43 probably, but dont know which 00:53:48 probably like the bc.i desktop client 00:53:53 "my browser is my desktop!" 00:55:04 gmaxwell: your attack, IECS R=rPQ, k1||k2=KDF(R), send R.x, c=E(k,m), MAC(k2,c); but i take it he used ctr mode for AES for E 00:55:19 gmaxwell: oops R=rQ rather 00:56:02 Yup. he used counter mode and a 64 bit MAC. 00:56:34 (at first I thought he used a 32 bit MAC and I was going to post a demonstration, alas... by random chance it wasn't quite that weak) 00:58:52 gmaxwell: actually that was also was wrong R=rQ, k1||k2=KDF(R) but send S.x from S=rG, c=E(k,m), MAC(k2,c) .. thats better 01:03:30 gmaxwell: ok so then you send S.x, c'=0, m=counter, and increase counter until it passes the mac. consequently you get c=p xor E(k1,ctr0) and c'=p' xor E(k1,ctr0) and therefore c xor c' = p xor p'; and you know p' because the oracle told you so p = c xor c' xor p'. qed :) nice 01:09:14 gmaxwell: btw i presume you are aware of http://eprint.iacr.org/2011/615.pdf because you mentioned the RSA problem, they provide a security argument for shared-key ECIES & ECDSA though unless there is some burning reason to reuse keys like you said that is a generically bad idea 01:09:52 gmaxwell: (we may even have discussed that paper here... i forget) 01:11:05 Ah, I didn't recall any argument for shared-key ECIES & ECDSA... I didn't even look for one, because considering the state state of security proofs for ECDSA I didn't expect to find any. 01:11:51 I don't think it's pratically insecure of course, but ... I was just pointing it out as a generally good pratice. 01:14:36 gmaxwell: agreed. i would be worried about that argument and any assumptions it makes; sometimes proofs are artificial. it seems inherently dangerous/fragile inviting people to ask you to answer challenges involving the same d as used in ECDSA - we know how fragile ECDSA is already without deterministic DSA! wouldnt take much to push it over the edge, just single bit here and there 01:16:23 yea, esp with a small mac potentially allowing you to use a decryption thing as a multiplication oracle of some sort. ... though the hash and AES certantly help. 01:16:52 the guy is busy arguing with me about address reuse in private message now. 01:17:15 :( 01:17:32 bitcoin.org/bitcoin.pdf 01:17:38 Already cited. 01:17:38 gmaxwell: well even just at the asymmetric level. eg say you could get timing from mac failure vs success or something. 01:17:39 iirc there's a section on that... 01:17:43 Section 10. It's like a keyboard reflex. 01:17:47 heh 01:19:46 gmaxwell: u know on sci.crypt there was this annoying guy very young, school kid; some of the regulars clubbed together and sent him some crypto books, evidently he read them and eventually wrote a quite well regarded crypto library and got crypto employment if i recall. http://libtom.org 01:20:27 Yea, I read sci.crypt religiously throught the 90s. 01:21:59 endless "I have made an ultimately secure cipher because none of you can break it!" 01:22:28 gmaxwell: sometimes noob status + enthusiasm leads somewhere :) altoz tendency to /ignore forum handles not giving criticism in the way he like might not help his learning curve tho! 01:22:54 yea, well, I've been responding to the guy. but ouch. 01:23:44 lots of earnest enthusiasm, but also layered cluelessness. :) He seems to respect me (the fool!) so at least my conversation with him is having forward progress. 01:24:36 hey, I havent failed out of bitcoin yet (despite repeated efforts), so maybe he can prove useful :p 01:24:41 too 01:26:42 gmaxwell: the sci.crypt ones i enjoyed most were the new factoring methods :) but yes the "i challenge you to break my new cipher" were endlessly amusing also 01:30:22 gmaxwell, adam3us: those factoring posts were still happening as of 3-4 years ago.. 01:30:55 also thx gmaxwell for posting your break, i'll check it out 01:37:11 Fistful_of_AFK is now known as Fistful_of_DOGE 01:37:44 Fistful_of_DOGE is now known as Fistful_of_DOGEC 01:37:49 Fistful_of_DOGEC is now known as Fistful_of_DOGE 01:38:56 gmaxwell: on https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29 it says 01:38:59 By now, CTR mode is widely accepted, and problems resulting from the input function are recognized as a weakness of the underlying block cipher instead of the CTR mode.[18] 01:39:17 i read that to suggest that altoz was safe from attacks such as yours 01:39:23 ha ha 01:39:33 which obtain a ciphertext which can just be xor'd with the desired message 01:39:58 (not that i would go implementing such a system based on 30 seconds of wikipeiaing) 01:40:02 nah, thats just what countermode does, turns a nice pretty blockcipher into a stupid stream cipher. :P 01:40:18 I am personally not a fan of CTR mode. It is widely used and respected, and you can certantly get yourself into trouble with blockcipher modes too. 01:40:20 huh, that's what it looked like to me 01:40:29 but "one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier" suggested i was being naive 01:40:55 gmaxwell: i reckon some of nsa $250m proto sabotage budget went into touting ctr mode... fragile & dangerous 01:40:57 But this case is a nice example of how CTR mode can contribute to a cryptosystem being brittle. 01:41:25 cool, i'll definitely work through your attack to make sure i know what's going on 01:41:34 but my next flight is boarding, i gtg for now 01:41:38 adam3us: okay, I feel better to hear you say that. I _think_ these sorts of things, but I try to not say them. :P 01:41:42 andytoshi: scroll up i did the math 01:42:14 gmaxwell: ctr mode seems like the dsa of cipher modes - inexplicably optimized for fragility 01:43:41 well I know a lot of people (esp hardware people) just really would prefer stream ciphers. 01:43:53 adam3us: in what way? 01:43:54 GCM's popularity surprises me. 01:44:24 maaku: fails totally completely to key/iv reuse and any amount of known plaintext. 01:56:24 gmaxwell: exactly any single reuse breaks it wide open; and there is no clear in-standard defined way to robustly avoid reuse so everyone does their own crappy time, counter, guid iv thing with semi public input or influencable input; similar to dsa, even the original dsa specified rng had enough bias that bleichenbaker figure out how to recover the private key in 1mil msgs 02:04:29 Did a matonis or someone write some article extolling "DAC" lately, IRC seems to be getting flooded with jabber about them? 02:04:47 DAC? 02:05:24 gmaxwell, Vitalik is writing software for it as part of Dark Helmet^WWallet 02:06:15 gmaxwell, Bitcoin Magazine did a series of articles, and Jerry Brito recently wrote http://reason.com/archives/2013/12/16/the-coming-robotic-world 02:07:36 LOL @ Dark Helmet ref 02:07:56 jgarzik: poke, never got a response on Fedora UNIX group for USB devices :P 02:08:34 jgarzik, gmaxwell: i think its more useful to call it a self-funding bot 02:09:11 DAC is the term protoshares/bitshares is using to mean "future app that will make our altcoin useful" 02:09:30 though i suppose they are hypothesizing about share-holder votes so there could be human owners; i think its more fun for a money making bot to go rent its own VPS with its own profit and own itself (right up until it hacked and loses its bitcoin stash:) 02:10:14 wasn't it bitshares' guy who was recently proposing a license that forbids any usage of software by anyone who consents to copyright law? -.- 02:10:18 pigeons: yeah i saw DAC on invictus site, some of their rhetoric was cringe worthy 02:10:18 DAC = Distributed Autonomous Corporation, AFAIK, which does not necessarily equal autonomous agent 02:10:35 Some people appear to be using the term simply for an extranational / virtual corporation 02:10:39 jgarzik: this is true 02:11:10 Luke-Jr: to enforce that license you need to enforce copyright, rendering yourself unable to use your own software? 02:11:39 warren: you don't need a license to use your own software :? 02:11:40 :/ 02:12:05 the alt story: step1. make useless alt; step2. make up some BS buzz about why its cool; step3 premine/postmine the heck out of it; step4 profit. 02:12:07 well, the point is you need copyright to enforce such a license 02:13:00 corollary to alt story: screw up just about every param choice, mining function choice that you possibly can; and yet inexplicably still profit (protoshares!) 02:13:37 ::sigh:: "Another point of evidence on address reuse is the popularity of vanity addresses. Are you suggesting people spend hours, sometimes days searching for an address only to use them once? I somehow find that unlikely." 02:13:47 adam3us: thats basically the story of all altcoins. 02:15:25 sadly true 02:15:26 I mean, even freicon bubbled up to 0.0005 BTC per FRC and its supposted to be inflationary and not go through these speculative bubbles! :P 02:15:31 ***adam3us wants to kill all alts 02:15:46 I like the proof-of-$somethingelse experiments 02:16:00 just fiddling with algo choice or params is droll 02:16:05 well, I'm certantly more happy when they write more than 0 lines of code with their alt. 02:16:15 * Luke-Jr likewise 02:16:33 I thought someone was going to do an altcoin maker? 02:16:33 I especially like that Freicoin also tries to deter scammers from abusing their alt 02:16:33 ah that reminds me, i was thinking there might be a way to let people play with alts without wasting electricity 02:16:48 adam3us: regtest? merged mining? 02:17:02 lawcoin: relies on proof-of-wasted-paperwork-filed-at-city-hall 02:17:04 or at least it would be interesting if a way could be found :) eg just some central trusted server would do, like coinwarz 02:17:36 jgarzik: I had a few fun ideas like that, ... but SSL doesn't have any way to sign the traffic through it. 02:17:48 There is that AWS thing for SSL quasi-non-repudiation though. 02:18:31 Proof-of-frivilous-litigation: You must file a nussance lawsuit against pirate40 to mine a block. 02:18:35 gmaxwell: yes so general framework for merge mining plus dont waste cpu. pay some virtual VPS and the central server allocates you some corresponding alts, proceeds go to something useful 02:18:44 precisely 02:19:51 I realized the existing merged mining code would only take a few lines of code to turn into a proof-of-attack against the chain its merging with. 02:20:19 I do something wonder what the world would look like, if "bitcoin1" remained at 1MB etc. forever, and "bitcoin2" was layered on top of that as a day-to-day transactional currency, used in tandem with the asset-store bitcoin1. 02:20:23 *sometimes 02:20:28 i mean these alts are mostly just a game, and have no non-speculative transactions; so they'd just as well own up to that reality. 02:21:00 jgarzik: did u see the idea BlueMatt & gmaxwell were talking about yesterday... a 1:1 peg feature, a better way to do bitcoin-staging 02:21:29 adam3us, interesting, though not quite what I was thinking 02:21:30 jgarzik: I dunno if you saw the sub-chain discussion from here with bluematt 24 hours ago. Sounds like we could pretty 'easily' with some changes (perhaps just softforking) have a sub-coin where you could move bitcoin to and from the subcoin. 02:21:45 jgarzik: then we could make a bitcoin2 that safely allowed coins to be move between bitcoin1 & bitcoin2. (the protection is only coins moved into it can be moved back so there is no security risk for people not participating) 02:21:51 I just openly wonder about keeping 1MB forever 02:22:17 My statement has always been "it will probably change"... notably not stating "it should change" of which I'm not yet convinced 02:22:28 and then logically extend from there 02:22:51 one of the complicating issues is that some of these ideas— like the subchain stuff really only work if Bitcoin1 remains reasonable cheap to validate, because all the sub-things below it must commonly validate bitcoin1 (but not each other) 02:23:00 jgarzik: i think the 1:1 peg is he best idea i heard in quite a while in bitcoin land. with that we could move ahead and develop the queued ideas and fixes without risking bitcoin1 funds 02:23:53 jgarzik: and yet avoiding the alt-coin trap and with no market / arbitrage cost/risk and no security risk to bitcoin1 funds 02:23:56 adam3us: it's not even a new idea really, we've know for a long time that it was possible to do something like this, subject to some limitations. As I mentioned before script is _almost_ powerful enough to express it directly. 02:24:34 hmm 02:25:04 bah, baby bedtime, bbiah 02:25:58 adam3us: the point you make about -staging is interesting though, I know you'd proposed 1way for staging, but I think one-way is not so interesting, the point that subchains would be useful for playing with new cryptocoin ideas is quite interesting. 02:27:09 gmaxwell: too much idea backlog to trace as close as i got was the 1-way peg; i was thinking a) cant change bitcoin because thats the problem the peg is trying to solve; and b) 1:1 peg while desirable requires btc change; and c) i didnt go further 02:27:10 sort of interesting to consider that maybe in the future the bitcoin network goes away and its replaced with ... another bitcoin network.. and it all happens in a fully consentual way with people just migrating their coins into another system. 02:27:26 adam3us: well I think we can make the one change to rule them all. 02:27:50 ... the more useful things a change does the more justifyable the effort. 02:28:11 gmaxwell: yes i like it; i like that its seemingly possible with a focused change to do this, and this does seem like the one change to rule them all which is why i was interested in the staging idea - i think it solves a real-world dev problem 02:29:07 gmaxwell: forking things could be done on this network; maybe you can even move coins out, upgrade, move them back; or roll out new forking versions with the analogous coin move protocol 02:29:17 gmaxwell: all without risking bitcion n-1 funds 02:30:39 gmaxwell: and also version1.0 could reject further non-defect changes and focus on being a value store afterwards 02:31:23 gmaxwell: that could be the stable IP protocol on which payment internet is built (or other stupid / non-transferring analogies people like to make) 02:32:32 gmaxwell: (mostly they actually mean "yay were going to flood bitcoin scarce broadcast channel as if its an IP datagram network") 02:33:54 and eg people doing well considered script changes would have somewhere to do them outside of alt-space (eg like freimarket extensions) 02:35:24 gmaxwell: the idea of a 1:1 peg is that bitcoin1 could remain easy to verify forever since txn just happen on bitcoinN 02:36:16 BlueMatt: and reward mining could happen only on bitcoin1 02:36:24 yup 02:36:34 (eg 1MB blocks forever on bitcoin1...) 02:38:25 BlueMatt: moreover, that kind of design strongly favors bitcoin1 being fairly small blocked, simply because you want bitcoin* also verifying it (so at least security in one direction was _full_, and so if a false proof shows up in the other direction the bitcoinN nodes can take action). 02:38:52 this has long been one of my concerns with cranking the block size— that once it happens some scalablity solutions are harder. 02:39:55 it's also more egalitarian— developers of your coin turning down your awesome automatic stolen coin recovery feature? Okay fine, create a new altcoin, and migrate your coins into it. 02:40:51 it could even go in hierarchies. Say that your "alt system" is too unblockchain like to be directly bound into bitcoin with this one-change-to-rule-them-all feature. 02:41:14 yup 02:41:14 thats alright, you migrate your coins to bitcoin3 which has SNARK scriptpubkeys, and with those you can bind your wacky offchain system. 02:41:48 yup 02:44:32 you could, if you wanted, even expirement with different economic formulas. You can't create bitcoin out of thin air, but you could tax inbound, store, and/or outbound coins. 02:45:34 oh man, this guy won't give up. 02:45:36 "'m not certain it's very much discouraged. I've been reading here and /r/bitcoin actively for the past 10 months and this is the first time I'm hearing about the importance of using addresses only once." 02:45:55 wtf 02:46:27 this is the point where you say "I'm sorry, but you're wrong, You should go ask people who actually know (ie work on bitcoin as devs) and give up reading idiots all day" 02:46:58 maybe the bitcoin fungibility thread might get the msg over (or not) 02:47:04 Well, I'm not talking with him for the sake of arguing. I don't care about right and wrong, he is in my petri dish now. 02:47:26 people with that level of understanding are dangerous to be writing code others might use 02:47:35 brainwallet.org level 02:47:44 He seems to be especially sour about avoiding reuse, I think because he'd been building an empire in his mind based on having identity services around static addresses. 02:48:15 So I'm not sure how much is due to that vs the popularity of that misunderstanding in the population, I suspect its a bit of both. 02:48:59 he was responding to me writing this: 02:49:02 I hope I didn't come across as suggesting it never happens. Only that its problematic, discouraged, and not done by many (esp. those who know better, or whos livelihoods depend on using Bitcoin well). Because of the rapid growth the overwhelming majority of people you interact with in Bitcoin space are very new to Bitcoin... and pick up bad habits like using "brainwallet" which sound appealing but often burn them with subtle ... 02:49:08 ... complications. 02:49:10 ... 02:49:24 he continued in his response: " I have friends that have been using bitcoin for years and they use the same address because it's very convenient for peer-to-peer transmission (you don't have to ask a new one all the time). Heck, I'm working on a project (not this one) right now and that's reusing addresses in certain cases. 02:49:30 If this is as important as you've made it seem, this needs to be a lot more prominently communicated to the general public, explaining all the risks of not changing addresses with every outgoing transaction." 02:49:49 which I think is probably fair enough. 02:50:03 It's not communicated well, especially since there is some wallet software that basically forces reuse. 02:50:09 (e.g. multibit) 02:50:10 we need a much, much, much better bitcoin intro for devs 02:50:23 and bitcoin wallet on android :( 02:51:05 We're also failing to use the existing software as an educational tool. There really should be some warning emblem that comes up on transactions that reuse addresses. 02:52:34 * BlueMatt desperately wants to have a good bitcoin library that provides nice apis to encourage proper use 02:52:46 but, sadly, that requires lots of effort... 02:53:13 gmaxwell: i think Luke-Jr is on the right track with eligius policy there ;) just need wider adoption of his patch "why is my transaction not completing"... well did u read the doco? no address reuse 02:53:21 well, there is A bitcoin library, bitcoinj but basically um.. all (?!) its users are not so good on the best practices front 02:53:53 there's also libbitcoin 02:53:58 I don't think you can both provide enough flexibility to really be a toolbox without making it easy to abuse. 02:54:18 gmaxwell: well, bitcoinj goes very far in making abuse easy 02:54:47 gmaxwell: even bitcoinj fails to get it right by far 02:55:01 (hell, all the apps that use it reuse the hell out of addresses) 02:55:35 gmaxwell: easy to abuse != easy to use right and possible to abuse 02:55:48 okay, thats a point. 02:55:59 Luke-Jr: does libbitcoin do an actually good job here? 02:56:04 BlueMatt: not sure 02:56:18 oh, well if we're just listing bitcoin libraries...there's millions 02:56:30 there are? 02:56:49 theres the one in go, theres ones (multiple) in python 02:56:52 theres another one in java 02:56:55 well if you limit them to c-callable... 02:57:01 theres bitcoin js theres bitcoin-ruby..... 02:57:14 gmaxwell: meh, you can call pretty much all of those from c with the right wrappers 02:57:24 i kind of like the public public derivation method (sender multiply Q by r and encrypt r for recipient, plus some bloom filter hint to reduce that below full node trial decrpt all payments) for this reason - safe to reuse because the uncompressed address is randomized during payment 03:26:43 jgarzik: proof of $somethingelse... doesnt proof of stake give a reward bias to those with lots of btc? 03:29:06 jgarzik: interesting result for efficiency, and self-interest to not damage the network, but side-effect an ongoing mining advantage to large btc holders 04:06:05 adam3us: only if subsidy is on those blocks.. 04:06:19 proof-of-stake without subsidy might be interesting 04:55:57 Guest25482 is now known as amiller 05:06:12 Fistful_of_DOGE is now known as Fistful_of_AFK 05:53:16 gmaxwell: http://qdb.us/64573 about that riddle. :) 05:55:49 http://it.slashdot.org/story/13/12/18/2122226/scientists-extract-rsa-key-from-gnupg-using-sound-of-cpu well shit 06:23:41 adam3us Luke-Jr: there are interesting applications of proof-of-stake if it can be divorced from mining reward 06:24:07 imho proof of stake should never have been tangled up in block generation or mining subsidy 09:47:41 TD_ is now known as TD 10:30:13 gmaxwell: btw much further up, about gpg noise attack, mentioned bitcoin signature is not timing resistant, yet another reason for non-address reuse; however chain-codes weaken that, exfiltrate the chain code from network computer, and timing/sound recover one public or private derived key to the point of recovery, and game over. 10:31:59 gmaxwell: at least the public & private derived HD sub-keys are probably randomized enough via HMAC that accumulative timing attack seems unlikely; also the whole thing yet another argument for Bernstien's EdDSA (aka EC Schnorr) as it has no timing attack (no private key dependent branches), though deterministic DSA also fixes that 11:19:19 about the 1:1 peg discussed yesterday, so far it seems like because btc2->btc1 flow is authorized by spv proof, that the entire alt is only good to spv security level. can this be improved to full node security? seems to imply full nodes need to be on both networks. 11:20:31 also if there is no native reward whats the motive to merge mine the btc2 - only btc2 network tx fees. isnt that vulnerable to incentive attacks as fees are 2-3% of reward. like ghash.io level pool could be paid to forge spv and succeed enough of time to make that an economically rational theft attack 12:31:05 hi 12:37:33 hi 13:24:26 TD_ is now known as TD 16:23:34 http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati 16:38:24 adam3us, iirc that requires you to do a lot of private key ops 16:46:52 the latest academic paper on bitcoin leaves a lot to be desired 16:47:02 http://eprint.iacr.org/2013/829.pdf - i sent them some corrections 16:48:36 i read the first few paragraphs and decided to ignore that one ... thanks for the vigilance 16:48:46 Muis is now known as ikbenwouter 16:49:16 ikbenwouter is now known as Guest53128 16:49:19 Guest53128 is now known as Muis 16:49:25 TD, sorry to be annoying but can you check that pm 16:50:10 i didn't see it actually, poor irc client ui my end it seems .. 17:01:15 have altcoins implemented many items from https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas ? 17:02:04 helo: For the most part altcoins don't implement ideas. They search and replace strings. 17:02:45 sometimes, for added excitement, they search and replace hash algorithms or fee schedules. 17:02:47 but that's rare 17:02:48 those are some really neat ideas... it's a shame 17:03:01 with proof of stake and prime coin being notable exceptions 17:04:01 TD: good email. ... I did learn one thing from the paper, although even in that it was wrong: They pointed out that if you send funds to a reused address it identifies your change. ... which isn't correct because some clients reuse their change addresses (doh), but igoring that its another example of how one person's reuse can thwart someone elses good practices that I hadn't considered. 17:04:02 i doubt most of the altcoin devs have the skill to implement them correctly (i doubt i do either), but it seems like they'd at least try 17:09:44 gmaxwell: speaking of, I think as a general principle we want to encourage address re-use for any application where public info allows for address linkage anyway; address re-use is a way of letting others easily know the address is *not* private 17:10:29 gmaxwell: e.g. for coinjoin you can better protect your privacy sometimes by avoiding joins with parties that have re-used addresses in some cases. 17:11:02 I dunno, public info isn't equally distributed. I'd rather be deanonymized by a forum post than data in the blockchain. 17:11:17 But I see your point. 17:11:55 Depends on the attacker - my suspicion is the type that will do detailed tx linkage analysis will also have databases of forum posts and p2pool share data. 17:12:40 with blockchain.info my grandma is an attacker, though not a terribly effective one. 17:13:04 yeah 17:13:58 Would be nice if there was a way to mark a scriptPubKey as "We've made this unique, but the info required to link it is something the could find." 17:14:44 Where TLA \in (Cyber Grandmas of America, FBI, NSA, etc.) 17:23:16 helo: IMO it'd be really frustrating to make big changes to bitcoind (though every day the devs make more progress toward modularity -- thanks guys!), so if you wanted to implement some serious ideas you'd be better off writing from scratch 17:23:27 so there's not really anything between "zero work" and "a ton of work" 17:25:00 meh, a number of those ideas would be quite selfcontained. 17:25:59 there is at least a similarly prohibitive steep gradient from "zero understanding" to "sufficient understanding" 17:26:20 andytoshi: two additional features that might be interesting in your coinjoiner. The ability to give it an input with a threshold. E.g. join this if and only if you get at least 4 other things to join with... if I'm paying a fee to join I really don't want it to be some two party thing with some address reusing fool. :P 17:27:16 gmaxwell: oh, good idea 17:27:28 andytoshi: the other is that you probably should convert submitted signatures to canonical form... as differences in signatures might be privacy reducing to participants. 17:27:28 right now i'm depending on "if you're ok using rawtx's, probably you aren't clueless" 17:28:02 yes, good call, that also gels well with my true goal of "learn rust and understand bitcoin encoding in detail" 17:28:14 In partcular the s/2 thing is enforced by bitcoin git but not 0.8.6 so their signatures are somewhat distinguishable. 17:28:59 (for now it might be wise to randomize the s/2 characteristic, but later after 0.9 is out you should conver things to the canonical form) 17:29:46 I'm not sure if anyone would submit to you padded r/s values or negative r/s values, but they might— some of the web signers in the past were broken. best to fix that. 17:30:05 is the s/2 characteristic random now? istm if i'm publishing coinjoins with inconsistent signatures 17:30:09 that screams "this is a coinjoin" 17:30:20 yes its random now. 17:31:00 bitcoin git produces signatures where S is always in the lower half. <=0.8.6 S is randomly in the upper or lower half. 17:31:23 ok, thanks 17:32:38 sadly the compressed vs uncompressed is a distinguisher but there isn't anything you can do about that. 17:33:13 normal users also end up with a mix, so you having a mix doesn't distinguish it as a CJ, but it may hurt users privacy. 17:34:44 ok, thanks 17:34:55 maybe when i get time to do this 0.9 will be out .. it'll be 3-4 weeks 17:35:09 i have been learning crypto 12 hours a day for the last week or two, but i have schoolwork to get on :} 17:36:16 Certantly not a priority. 18:25:26 very appropriate response to telegram : http://thoughtcrime.org/blog/telegram-crypto-challenge/ 18:29:18 thats really quite brillant. 18:30:27 I've suggested a thought expirement of the same ilk in the past— imagine bitcoin with the hashes replaced with md5 and the crypto replaced with 512 bit RSA. .. what is the security like? as a metric in how robust the overall system is to weak crypto. Neat to use that as a test of a test. 19:06:27 maaku, i love that 19:07:01 gmaxwell, as long as people didn't reuse addresses? still pretty secure 19:07:03 neat 19:07:31 i think the biggest issue there would be someone generating collisions with block hashes/transactions 19:07:44 So cryptocurrencies which "fail inflationary"... which is a property that things like USD has, if you print really good fake USD .. well everyone takes the cost. Not the person that accepted the fake USD, at least not if its sufficiently good. 19:08:07 phantomcircuit: yea, but that would mostly be a DOS vulnerablity and it would result in invalid data, so you could just ban peers that give it to you. 19:08:25 right 19:08:36 except now you need to have the full set of txids 19:08:45 or actually you dont 19:08:59 It would be totally plausable to make it so that if you get tricked by a recentl valid looking bitcoin fork, that both parties get paid. Thus moving the cost of such an attack to everyone holding bitcoin and not just the guy accepting it. 19:09:00 as long as it's not in the utxo right now reusing a txid wouldn't break things 19:09:02 theoretically 19:09:31 gmaxwell, heh incentivize miners to intentionally build forks though 19:09:48 incentive 19:09:54 word* 19:10:30 phantomcircuit: maybe. setting it up right might be tricky. 19:10:46 heh understatement of the year goes tooooo 21:05:11 nsh- is now known as nsh 21:15:59 ;;title http://thoughtcrime.org/blog/telegram-crypto-challenge/ 21:15:59 Error: This url is not on the whitelist. 21:16:02 nu 21:16:14 "So Telegram developers, by way of a response, I have my own crypto cracking contest for you. Below is a horrifically bad “secure” protocol that wouldn’t last a second in a real world environment, but becomes “unbreakable” when presented in the exact same framework as the Telegram challenge." 21:16:14 +1 22:20:57 phantomcircuit: what requires a lot of private key ops? 22:21:37 adam3us: importing a deterministic wallet maybe? 22:22:13 Moxie is grand 22:25:25 Moxie has an incredibly awesome name. 22:26:08 adam3us, signing 22:26:20 Diffie said at an RSA conference, not sure if last or this year, that he thought Moxies name was a joke when they first met 22:27:05 (they were talking about Convergence) 22:29:39 I'm guessing Moxies challenge is actually pretty hard because 896bit RSA is reasonably outside computable for average readers 22:30:26 HM2: his point was to make it clearly unacceptably insecure in serveral ways but still almost certant to not be broken in the context of the challenge. 22:30:41 In reality such a system would be broken if it were used for a long time on something high value. 22:31:08 right, if there's a time limit you can get away with weak crypto 22:31:19 but i'm not sure how it's a fair comparison 22:32:45 http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati 22:32:52 wtf are with the responses there? 22:32:59 ah 22:33:07 RSA is still more secure than I thought 22:33:34 you can claim $75,000 for factoring 896 bit 22:33:55 768 bit was factored in Dec 2012, so Moxie has chosen that deliberately 22:34:02 HM2: hm? the challenges were withdrawn. 22:34:28 HM2: did he use the factored key in his challenge? 22:34:33 HM2: sure he did. but at the same time we know that 896 is clearly achievable. 22:35:02 sorry, you're right. 2010 22:35:08 why did they retract the challenges? :S 22:35:42 it seems people have been factoring the keys published under the challenge without the financial incentive 22:35:55 Yes, they have been. 22:38:04 I wonder if he really did dig up an instance of Dual_EC_DRBG to compute the super_secret 22:38:17 I'd wager he didn't 22:38:31 lots of things support EC_DRBG 22:38:55 HM2, cat /dev/random on a recent but not too recent freebsd box isn't too hard 22:38:56 he probably did, given the way the "contest" is presented 22:40:29 this is something I thought of when helping somebody with their botched job of making a “paper wallet” before. they’d dropped the end off and I had to remake the hash portion for them to be able to import it. 22:40:32 most of the problems people encounter seem to be with private keys, spending from them and screwing up the keys, not writing them down with capital letters, all very preventable errors. it seems to be proposed in the mailing list that the “import” will be removed and replaced with “sweep private key” which seems to fix many of these issues. 22:40:39 could we go further, and make a paper wallet “token” system. the user selects an amount, and an address is created and the funds sent to them. the token is then presented for writing/printing/saving and not saved to the wallet. the token is armoured with a large amount of parity, enough to save the user if there is user created damage. it can only be spent from by destroying it by importing it, and the UI mak 22:40:43 it removes a lot of the danger, and gives the users something useful at the end of it. is this madness, stupid, fantastic? I can’t quite decide. 22:41:47 you should just send the keys to moonpig.com and have them sent to them on festive cards 22:41:57 i'm sure they have an API 22:42:37 HM2: a snowman with a carrot phallus, charming. 22:43:38 you obviously made snowmans differently when you were younger to how I made mine 22:44:09 it's one of the cards on the page you linked to 22:46:47 you know, it occurs to me that you could can bruteforce moxies challenge 22:46:52 feasibly 22:48:11 you can brute force lots of things, that doesn't mean it's worth the money to 22:48:23 he's not offering any money hah 22:49:01 I meant it's not worth spending my money on EC2 instances 22:50:35 HM2, bruteforce which part 22:52:21 well i was thinking his message is only 16 bytes 22:52:32 and its probably something fun 22:52:38 or seasonal 22:52:45 could just as well be /dev/random though 22:52:47 it might even contain words from his post 22:52:53 sure, but this is Moxie 22:53:33 it doesn't help anyway 22:53:48 he makes a good point 22:57:46 HM2, come up with a message 22:57:55 xor it against the cipher text 22:57:58 present as key 22:58:10 laugh as people who dont understand xor go wild 22:58:18 heh