00:06:43 | [\\\]: | [\\\] is now known as imsaguy |
00:06:51 | imsaguy: | imsaguy is now known as [\\\] |
00:09:11 | [\\\]: | [\\\] is now known as [\\\\\\\\\\\\\\] |
00:09:32 | [\\\\\\\\\\\\\\]: | [\\\\\\\\\\\\\\] is now known as pirateat40 |
00:13:12 | pirateat40: | pirateat40 is now known as [\\\] |
02:08:39 | wallet421: | wallet421 is now known as wallet42 |
05:09:54 | justanotheruser: | Thoughts on NTRU sigs? |
05:11:29 | tacotime: | they came up a while ago for mc2 |
05:12:00 | tacotime: | but iirc either the pubkeys or the sigs or both were much much larger than for ecdsa so i'd dismissed them |
05:12:22 | justanotheruser: | tacotime: how big? |
05:12:22 | tacotime: | (at comparable levels of security) |
05:12:53 | justanotheruser: | Yes, how big for 128 bits of security? |
05:13:06 | tacotime: | https://bitcointalk.org/index.php?topic=169204.msg1988041#msg1988041 |
05:14:19 | tacotime: | which i saved the reference for that, sigh |
05:15:10 | tacotime: | and i didn't include sig size, maybe it's small but i don't remember, it was a year ago |
05:16:09 | tacotime: | also it's patented. but in theory you could use it for a blockchain signature scheme, i'm sure. |
05:16:39 | justanotheruser: | tacotime: yeah, it is big but not massive like some post quantum keys. |
05:17:01 | justanotheruser: | When its needed I'm sure it will be used. |
05:17:09 | tacotime: | yeah, i would say it's probably the most usable. |
07:08:56 | gmaxwell: | NTRU scheme has kind of some sketchy security assumptions classically, and the size IIRC wasn't really compelling compared to a state of the art Winternitz compressed hash signature. |
07:09:22 | gmaxwell: | (plus the hash signatures, even with winternitz compression, are very fast and can be implemented by anyone easily) |
07:09:36 | gmaxwell: | so I didn't really see a selling point for NTRU for bitcoin applications. |
07:11:09 | ghtdak: | ghtdak has left #bitcoin-wizards |
07:59:37 | warren: | http://cryptome.org/2014/05/bitcoin-suicide.pdf |
07:59:39 | warren: | read section 7.2 |
07:59:42 | warren: | lots of bullshit |
07:59:55 | warren: | "It surprising to discover that Satoshi did NOT introduce a transaction |
07:59:55 | warren: | timestamp in bitcoin software. It is NOT known WHY neither the original |
07:59:56 | warren: | creator of bitcoin nor later bitcoin developers did not mandate one." |
08:01:24 | gmaxwell: | the author of the paper was the one of the authors of the XLS attacks on AES which were super highly overhypted (but at least good research) |
08:01:48 | gmaxwell: | Bytecoin made a pretty cutting remark about the paper being crap on bitcointalk. |
08:02:12 | warren: | 7.2 in particular suggests the author really doesn't understand Bitcoin |
08:09:29 | warren: | oh |
08:09:33 | warren: | I see the bitcointalk thread |
08:32:24 | Eliel_: | whoah, the writer of that paper seems to miss the point of blockchain entirely while on the other hand kind of getting it and claiming it doesn't work (the arguments didn't convince me though). Very strange way to misunderstand. |
08:36:26 | gmaxwell: | er XSL above. dyslexia night, so much easier to spot when I'm reading it back and think someone else wrote it. :) |
08:36:57 | Eliel_: | although, I just realized that what bitcoin uses blockchain for isn't actually purely timestamping. If it was, you wouldn't have transactions waiting hours before being included and getting a "timestamp". |
08:40:38 | Eliel_: | * Eliel_ wonders if there could be some benefit in separating the timestamp service and the ledger functionalities of blockchain. Timestamp service wouldn't need to include the transaction itself. |
08:41:36 | jtimon: | irreversible serialization takes some time to be irreversible |
08:42:56 | jtimon: | you could use the same sand/hole analogy I used for merged mining the other day |
08:44:02 | jtimon: | bury transactions |
09:17:11 | jtimon: | for timestamping, anyone can do it, instantly, private chains, no real need for p2p if you can always fallback to public chains when you suddenly stop trusting the private timestamper |
09:18:15 | jtimon: | two phase commit's (old ripple) registries were basically blind timestampers |
12:38:12 | fanquake: | fanquake has left #bitcoin-wizards |
14:14:04 | kanzure: | not quite done with my math, but i'm contemplating the cost-effectiveness of homebrewing my own asic http://diyhpl.us/wiki/homecmos/bitcoin |
16:44:32 | OneFixt_: | OneFixt_ is now known as OneFixt |
17:18:06 | jables: | jables has left #bitcoin-wizards |
17:33:04 | Emcy_: | Emcy_ is now known as Emcy |
18:05:00 | amiller: | jgarzik, i'll be giving my talk about Permacoin at the IEEE S&P security conference right at that time, I'm trying to figure out how to work dakami's bet into my presentation somehow. |
18:08:19 | michagogo|cloud: | Btw, did you actually find someone and put the 20BTC in escrow? |
18:15:39 | amiller: | uh no, not in this case, i don't think it's necessary because the bet concerns two fairly public figures and i have lots of twitter evidence, their reputations are in escrow :p |
18:17:36 | wallet42: | wallet42 is now known as Guest59629 |
18:17:36 | wallet421: | wallet421 is now known as wallet42 |
18:18:43 | michagogo|cloud: | amiller: didn't one of them mention finding someone to hold the BTC? |
18:19:04 | michagogo|cloud: | (Or wanting to?) |
18:19:08 | amiller: | not that i know of? if so then i might not have been paying close enough attention |
18:19:20 | wallet421: | wallet421 is now known as wallet42 |
18:26:10 | michagogo|cloud: | amiller: https://mobile.twitter.com/jgarzik/status/336210942717214720 |
20:03:34 | Anduck: | Anduck is now known as NyanDuck |
21:32:20 | NyanDuck: | NyanDuck is now known as Anduck |
21:33:07 | Anduck: | Anduck is now known as NyanDuck |
21:53:11 | NyanDuck: | NyanDuck is now known as Anduck |
22:00:16 | wallet421: | wallet421 is now known as wallet42 |
22:33:37 | amiller: | ugh using pinocchio is such a pain in the ass |
22:34:00 | amiller: | hardly any of C is supported so i can't use nested structs to organize code and maintain sanity, everything has to be flat arrays |
22:34:30 | amiller: | i can't compute more than 10 sha1's at once without generating such a big circuit that it crashes any machine i try to run it on |
22:44:55 | amiller: | maybe tinyram will be more robust ;o |
22:54:33 | gmaxwell: | well at least the circuit size doesn't really increase much with the program size! |