| 00:27:48 | petertodd: | pigeons: small PoW consensus systems, merge-mined or otherwise, are highly vulnerable to 51% attack. (e.g. coiledcoin) This means that if you need proof-of-publication - which Mastercoin and Counterparty do, as do secure decentralized exchange systems, among others - you're have no choice but to go the embedded route. |
| 00:28:25 | petertodd: | pigeons: of course, much of the controversy here is that people argue that economicly rational attackers wouldn't attack a valuable merge-mined system; I argue assuming attackers are economically rational is foolhardy |
| 00:29:16 | nsh: | hashing pools could provide "incubation" services |
| 00:29:33 | petertodd: | nsh: sure, and those hashing pools aren't exactly decentralized |
| 00:29:43 | nsh: | true |
| 00:30:01 | petertodd: | nsh: basically the process there is a) write code, b) ask for permission, c) hope you grow big enough that permission isn't needed anymore |
| 00:30:32 | petertodd: | nsh: on top of that, the existance of those hashing pools incentivizes pools to be bigger, because only large pools can aford the overhead of dealing with a zillion little merge-mined experiments/small projects |
| 00:30:43 | nsh: | mmm |
| 00:32:15 | petertodd: | nsh: besides, all this is missing the bigger issue, which is that blocking this stuff isn't really possible anyway in the short to medium term |
| 00:32:36 | nsh: | blocking the 51% attacks? |
| 00:33:13 | nsh: | i think you could clad an altchain seedling in a "traditional" architectural scaffolding until it has a viable hashrate or fails for other reasons |
| 00:33:14 | petertodd: | nsh: no, blocking people using the blockchain for arbitrary proof-of-publication |
| 00:33:15 | nsh: | in principle |
| 00:33:22 | nsh: | ah, right |
| 00:33:52 | petertodd: | nsh: who cares? again, from the perspective of these projects, why build a cludgy insecure system requiring you to ask permission and start centralized, when you can start decentralized for an acceptable cost |
| 00:34:15 | nsh: | * nsh nods |
| 00:35:19 | petertodd: | nsh: the real question, is does the rest of the bitcoin community sit around and whine about it, at cost to the size of the utxo set, or are they interested in engaging and letting experiments happen? |
| 00:36:11 | petertodd: | nsh: remember this isn't just embedded consensus systems, this is also issues like "do we allow people to use the blockchain for multiparty computation transactions?" because they require the exact same arbitrary proof-of-publication that embedded consensus does |
| 00:36:22 | petertodd: | nsh: and there's a lot of potential applications like that |
| 00:36:26 | nsh: | indeed |
| 00:36:48 | nsh: | i think it would be sensible to collaborate on reaching optimal ecological relationships |
| 00:37:03 | nsh: | but convincing and facilitating that is harder |
| 00:37:04 | petertodd: | nsh: heck, speaking of: fidelity bonded banking absolutely needs it so the fraud proofs can be reliably propagated - without proof-of-publication it the whole thing doesn't work. same with all kinds of reputation systems. |
| 00:37:33 | nsh: | * nsh nods |
| 00:37:52 | petertodd: | nsh: yes indeed - when the other side wants to see your baby die people tend to be less than civil |
| 00:38:12 | nsh: | you're always going to run into human nature :) |
| 00:38:22 | petertodd: | yup! |
| 00:40:06 | maaku: | petertodd: I'd love to see you attack namecoin |
| 00:40:41 | petertodd: | maaku: namecoin is trivially attackable by ghash.io last I checked - they have a majority of hashing power |
| 01:33:04 | thedarkconcept: | gyea |
| 01:56:16 | phantomcircuit: | petertodd, ghash.io isn't >50% of namecoin hashing power |
| 01:56:48 | phantomcircuit: | eligius/btc guild/cloudhashing are about equal |
| 02:37:26 | just[dead]: | just[dead] is now known as justanotheruser |
| 02:55:13 | Guest73297: | Guest73297 is now known as ageis |
| 03:19:21 | justanotheruser: | What are the faults in bitmessage other than proof of work? |
| 03:55:15 | sipa: | justanotheruser: no incentive to mine |
| 03:55:37 | justanotheruser: | sipa: there is no mining? |
| 03:56:04 | sipa: | oh, sorry, confusing with twister |
| 03:56:40 | justanotheruser: | Is twister something like BM, with a block chain? |
| 04:03:27 | phantomcircuit: | sipa, so im looking at wallet load times again, d2i_ECPrivateKey seems to be taking 0.4ms |
| 04:03:37 | phantomcircuit: | ssValue >> pkey is taking the difference |
| 04:03:58 | Ursium: | gmaxwell: you mentionned vbuterin messed up in some place of his articles - care to comment? |
| 04:04:16 | Ursium: | then again i undertand if someone fucks up it's not your problem |
| 04:04:36 | jgarzik: | justanotheruser, bitmessage is a rough draft |
| 04:05:08 | jgarzik: | justanotheruser, it solves the problem of being easy to identify based on your activity, by shrouding all your activity in with the noise |
| 04:05:43 | jgarzik: | justanotheruser, flood-messaging is IMO never the best design, though. "send everything to everybody" quickly becomes difficult to scale. bitmessage had some plans for that, but no real progress AFAIK |
| 04:05:55 | justanotheruser: | jgarzik: Yes, but is there anything fundamentally wrong with it they don't plan to fix? A bitcoin dev implied that to me |
| 04:06:07 | justanotheruser: | jgarzik: yes, their original paper mentions streams |
| 04:06:29 | justanotheruser: | Perhaps they will implement it when it when they start growing |
| 04:07:13 | jgarzik: | justanotheruser, I'm aware of the broad design, but don't know it well enough to claim any obvious flaws. There are a lot of rough edges, incomplete areas, looked easy to sybil, ... |
| 04:07:28 | jgarzik: | justanotheruser, it does provide some measure of hiding its users, unless I'm missing something |
| 04:07:28 | phantomcircuit: | justanotheruser, yes it is fundamentally not scalable to use a flood network without some sort of global restriction |
| 04:07:36 | phantomcircuit: | in bitcoin that restriction is the block size |
| 04:08:27 | justanotheruser: | jgarzik: what would the Sybil hurt exactly? Being able to identify someone? |
| 04:08:42 | sipa: | phantomcircuit: that's crazy slow |
| 04:09:01 | phantomcircuit: | sipa, yeah it seems off |
| 04:09:03 | sipa: | phantomcircuit: it probably verifies that the public and private key match |
| 04:09:03 | jgarzik: | justanotheruser, being able to craft what your target sees or does not see |
| 04:09:16 | phantomcircuit: | sipa, hmm maybe |
| 04:09:29 | phantomcircuit: | in that case my patch to improve load times has been broken by an openssl change |
| 04:09:30 | phantomcircuit: | :( |
| 04:09:35 | justanotheruser: | jgarzik: really? Does it not use the same connectivity as bitcoin? I assumed it did |
| 04:09:53 | sipa: | only what they do not see |
| 04:09:58 | jgarzik: | justanotheruser, no, it does not use the same connectivity as bitcoin |
| 04:10:17 | phantomcircuit: | sipa, ssValue >> pkey; |
| 04:10:22 | phantomcircuit: | that takes even longer |
| 04:10:33 | sipa: | phantomcircuit: fun |
| 04:10:35 | justanotheruser: | I guess that's what I get for trusting #bitmessage instead of reading the source :/ |
| 04:10:45 | jgarzik: | sipa, semantics. If I control what you cannot see, I also control what you can see. I just cannot forge new messages, probably. |
| 04:10:58 | sipa: | phantomcircuit: let's get rid of openssl |
| 04:11:03 | petertodd: | justanotheruser: what do you mean by connectivity? |
| 04:11:06 | jgarzik: | sipa, +1 |
| 04:11:09 | sipa: | jgarzik: yeah, that's what i meant |
| 04:11:24 | sipa: | petertodd: connection graph, i guess |
| 04:11:32 | justanotheruser: | petertodd: node discovery and network topology |
| 04:11:38 | phantomcircuit: | sipa, it's really annoying to do this stuff, i have to add a bunch of performance counters everywhere |
| 04:11:44 | petertodd: | justanotheruser: right, that part is basically identical to bitcoin |
| 04:12:01 | jgarzik: | the annoying thing about dropping openssl (or any crypto lib) is that a bignum implementation remains a requirement, of script and ecdsa both |
| 04:12:02 | justanotheruser: | What is different making it jammable? |
| 04:12:03 | phantomcircuit: | sipa, agreed |
| 04:12:08 | jgarzik: | drop that, but still need gmp or whatnot |
| 04:12:10 | phantomcircuit: | i had this down to like 2usec per key |
| 04:12:10 | petertodd: | justanotheruser: the problem is that without pow you have no way of detecting if you've been jammed |
| 04:12:12 | phantomcircuit: | :/ |
| 04:12:19 | sipa: | phantomcircuit, jgarzik: #bitcoin-dev |
| 04:12:47 | justanotheruser: | petertodd: you mean without pow and a block chain? |
| 04:13:01 | petertodd: | justanotheruser: right, sorry, pow proof-of-publication and all that |
| 04:13:11 | petertodd: | justanotheruser: bitmessage does of course have pow! just not consensus |
| 04:13:35 | justanotheruser: | petertodd: so is it fundamentally flawed w/o a block chain? |
| 04:14:04 | petertodd: | justanotheruser: well, it's fundementally less secure, whether or not that means "flawed" is up to you |
| 04:14:36 | justanotheruser: | petertodd: would a block chain that gets pruned after 2 weeks of blocks be better? |
| 04:14:53 | sipa: | petertodd: bitmessage has pow? |
| 04:15:14 | justanotheruser: | sipa: hashcash preventing spam and DoS |
| 04:15:18 | sipa: | oh |
| 04:15:26 | sipa: | non transferrable proof of work |
| 04:15:27 | petertodd: | justanotheruser: maybe, but you need incentives - twister tried something like that and failed badly |
| 04:16:35 | justanotheruser: | petertodd: hmm... so the only options are an altcoin or many small bitcoin tx? Or a 1-1 pegged altcoin? |
| 04:16:42 | petertodd: | justanotheruser: see, one potentially good incentive is "I want to be sure this isn't broken" - which gives you hybrid systems where you don't always use the cost of proof-of-publication |
| 04:17:09 | petertodd: | justanotheruser: not necessarily - those options don't inherently have security |
| 04:17:36 | petertodd: | justanotheruser: or, sorry, the altcoin no - making use of bitcoin is likely to work, but for a price |
| 04:18:21 | justanotheruser: | petertodd: somehow you have to incentivize miners. |
| 04:19:09 | justanotheruser: | petertodd: are you saying its insecure because of the low hashrate of the altcoin? |
| 04:19:13 | petertodd: | justanotheruser: well, here's another way of looking at this stuff: Can you have a censorproof publication platform? Obviously it can't be "totally" censorship proof because the world is not infinite, so at some point someone's message are going to be dropped. |
| 04:19:55 | petertodd: | justanotheruser: Thus, you make a platform where you expend a (variable) work-per-byte cost, where cost is in terms of proof-of-work, and everyone participating agrees that more work means more important. |
| 04:20:14 | petertodd: | justanotheruser: adding a blockchain to that just helps everyone agree what has been published so everyone's work builds upon each other |
| 04:20:25 | justanotheruser: | petertodd the block chain doesn't guarantee your message won't be blocked, it just assures you that your message is out there right? |
| 04:20:30 | petertodd: | justanotheruser: turning that all into a tree makes it easy to have multiple tiers of security |
| 04:20:45 | petertodd: | justanotheruser: no, it assures you that if your message is blocked *you can find out* |
| 04:21:22 | justanotheruser: | Yeah, that's what I mean. It let's you know if it isn't out there |
| 04:21:54 | justanotheruser: | Therefore, you could solve that with just a response message of "I got this", right? |
| 04:21:55 | petertodd: | Ah, yeah, that's absolutely correct |
| 04:22:27 | petertodd: | Sure, but the response is from whome? In the bitmessage case, we're talking 1:1 often, so that's doable. But for publication, that doesn't work. |
| 04:22:43 | petertodd: | secondly, with bitmessage, responding to messages has privacy problems... |
| 04:22:49 | justanotheruser: | Good point. |
| 04:23:41 | justanotheruser: | So is there a way to either make jamming impossible, or to know you're being jammed without a block chain? |
| 04:25:20 | petertodd: | Sure, invoke centralized authority |
| 04:25:50 | justanotheruser: | Hah, is there another way |
| 04:26:21 | Luke-Jr: | see if you get an answer |
| 04:27:05 | petertodd: | now, interestingly, proof-of-stake *does* work for this... kinda. Like your 1:1 example, PoS is basically a way for a large set of participants to reply "hey I got it!" in a bandwidth efficient way. But the incentives are all screwed up, and determining who has "stake" is very non-trivial. |
| 04:27:41 | petertodd: | In an ideal situation where all your recipients are honest and co-operative, it'd work... but if some are malicious you've got problems. |
| 04:31:21 | justanotheruser: | petertodd: how does stake ensure everyone got it? |
| 04:31:56 | justanotheruser: | They could just jam the stake tokens, right? |
| 04:32:06 | petertodd: | justanotheruser: again, if you don't hear from them saying "I got it!" you know the jam free network has failed |
| 04:32:09 | petertodd: | that's it |
| 04:37:44 | justanotheruser: | How are "I got it" messages different for stake than the message themselves? |
| 04:38:51 | petertodd: | justanotheruser: because "I got it" can be a signature on a new block in the blockchain of all messages |
| 04:41:07 | justanotheruser: | petertodd: oh, so we are using a block chain for the messages? I though we were talking proof of bitcoin stake |
| 04:41:48 | petertodd: | oh, no, I was talking about a hypothetical proof-of-publication system via proof-of-stake |
| 04:42:21 | justanotheruser: | And the stake is in the message block chain? |
| 04:42:33 | petertodd: | who knows? could be anything |
| 04:42:58 | petertodd: | "stake" in this example is just "I have a private key that the system defines as being a stakeholder" |
| 04:44:10 | justanotheruser: | petertodd: yes, but you said they would sign a message in the block chain. This isn't possible (or at least ideal) with the bitcoin block chain. |
| 04:44:31 | petertodd: | justanotheruser: I think you're confusing things; again I'm talking about hypothetical systems here |
| 04:46:30 | justanotheruser: | petertodd: would this hypothetical systems PoS involve bitcoin stake, or stake in its own block chain? |
| 04:46:53 | petertodd: | justanotheruser: who knows? like I say, it's a thought experiment |
| 04:48:26 | justanotheruser: | petertodd: could it involve stake in bitcoin? that would be ideal because you wouldn't need to have your own miners. The problem is signing a message in the block chain because its better to not have confirmation messages in the bitcoin block chain. |
| 04:48:59 | wyager: | Is namecoin.org legit? They have more binaries than namecoin.info. |
| 04:49:09 | petertodd: | justanotheruser: potentially it could, but then you have to ask yourself if signing for the same stake multiple times is malicious |
| 04:50:24 | justanotheruser: | petertodd: not if you can somehow have all your messages proven in the block chain in a regular tx |
| 04:50:33 | petertodd: | justanotheruser |
| 04:50:39 | petertodd: | justanotheruser: that's ugly - data hiding problem |
| 04:51:15 | justanotheruser: | petertodd: no, I mean in an actual tx meant to transfer valur |
| 04:51:16 | petertodd: | justanotheruser: on the list somewhere I worked out the issues involved for a potential zerocoin alt last summer using that design |
| 04:53:14 | justanotheruser: | petertodd: do you have a post or paper about it? |
| 04:54:38 | petertodd: | justanotheruser: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html |
| 04:54:53 | justanotheruser: | Thanks |
| 04:55:29 | petertodd: | justanotheruser: remember though that it's dependent on a very advanced form of scorched-earth to respond to attackers |
| 04:56:30 | justanotheruser: | petertodd: so does it scale to a large number of messages? |
| 04:56:57 | petertodd: | justanotheruser: same scalability problem as bitcoin, but using trees can potentially fix that |
| 05:04:02 | justanotheruser: | Thanks for your help petertodd. I'll probably have to read that a few more times before I can understand that |
| 05:04:29 | petertodd: | np |
| 07:20:16 | ageis: | ageis is now known as Guest67535 |
| 07:36:17 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 11:57:15 | lnovy: | lnovy is now known as gammer |
| 11:57:45 | gammer: | gammer is now known as lnovy |
| 11:57:51 | justanotheruser: | justanotheruser is now known as just[dead] |
| 11:59:53 | just[dead]: | just[dead] is now known as justanotheruser |
| 12:01:41 | justanotheruser: | justanotheruser is now known as just[dead] |
| 12:19:18 | just[dead]: | just[dead] is now known as justanotheruser |
| 13:29:18 | justanotheruser: | justanotheruser is now known as just[dead] |
| 13:29:37 | just[dead]: | just[dead] is now known as justanotheruser |
| 13:34:36 | justanotheruser: | justanotheruser is now known as just[dead] |
| 13:48:36 | sl01: | anyone have suggestions on multi party OTR chat for desktop ? |
| 13:49:59 | hearn: | crypto.cat |
| 14:44:52 | bobke_: | bobke_ is now known as bobke |
| 15:00:03 | just[dead]: | just[dead] is now known as justanotheruser |
| 15:32:21 | justanotheruser: | justanotheruser is now known as just[dead] |
| 15:40:18 | just[dead]: | just[dead] is now known as justanotheruser |
| 15:58:57 | justanotheruser: | justanotheruser is now known as just[dead] |
| 16:13:05 | just[dead]: | just[dead] is now known as justanotheruser |
| 16:30:46 | justanotheruser: | justanotheruser is now known as just[dead] |
| 16:37:48 | rdponticelli_: | rdponticelli_ is now known as rdponticelli |
| 17:32:11 | Guest67535: | Guest67535 is now known as ageis |
| 18:32:17 | maaku: | maaku is now known as Guest53469 |
| 18:35:28 | Guest53469: | Guest53469 is now known as maaku |
| 18:35:57 | maaku: | maaku is now known as Guest82878 |
| 18:38:03 | maaku_: | maaku_ is now known as maaku |
| 18:55:43 | phantomcircuit: | gmaxwell, is it just me or is the kraken thing failing to prove they have any assets |
| 19:01:32 | shesek: | phantomcircuit, I didn't get why an auditor is needed... |
| 19:01:46 | phantomcircuit: | shesek, because it's a scam of course |
| 19:01:58 | phantomcircuit: | (i wont even try to hid my contempt for jesse powell) |
| 19:02:41 | shesek: | they can prove it in a trustless manner, the way they did this is both unnecessary and provides much less of an assurance |
| 19:05:48 | hearn: | i think the idea is that they don't want to reveal their addresses/UTXOs |
| 19:05:55 | hearn: | which is reasonable, because that would compromise the privacy of all their users |
| 19:06:05 | hearn: | it's sort of a halfway house |
| 19:08:21 | shesek: | their users would be in a pretty huge anonymity set |
| 19:08:31 | shesek: | I'm not sure how much of a problem that is |
| 19:09:15 | shesek: | though, if someone needs to backtrace a transaction, having their list of addresses could be a useful way to figure out who you need to send the court order |
| 19:09:18 | maaku: | hearn: how would it compromise the privacy of their users? |
| 19:09:28 | shesek: | which could compromise the users privacy in a way |
| 19:09:42 | hearn: | it means you could find out if someone you sent money to then traded it on kraken, or if someone you received money from bought it from kraken |
| 19:10:21 | maaku: | hearn: there are zero-knowledge constructions just for this purpose |
| 19:10:51 | shesek: | I don't think there's something that's practical and usable right now though, is there? |
| 19:12:36 | hearn: | yes yes of course. kraken wanted something they could actually implement and use in a reasonable timeframe |
| 19:12:43 | hearn: | not wizardry |
| 19:14:09 | maaku: | shesek: it wouldn't be terribly difficult to put together. probably cost less than paying these auditors :\ |
| 19:15:32 | phantomcircuit: | hearn, this is actually worse than a half measure, it's a zero measure in practice and yet they can run around telling people it's cryptographically proven |
| 19:15:43 | phantomcircuit: | i would put forth that their statements amount to fraud |
| 19:17:03 | maaku: | shesek: in terms of zkp, validation of a merkle tree isn't too complicated of a construction (once you've built the circuit for the hash function at least) |
| 19:18:08 | maaku: | basically all the pieces are already there with zerocash - which I know is not public, but I'm sure matt green would give exchange X access to that code for the PR value if nothing else |
| 19:19:00 | maaku: | the zerocash prove-I-have-a-coin circuit is nearly identical to the exchange's prove-I-have-an-output |
| 19:19:02 | phantomcircuit: | maaku, their auditor was an employee |
| 19:19:05 | phantomcircuit: | not an actual audit |
| 19:19:25 | maaku: | hah! wow, not an audit at all |
| 19:19:42 | phantomcircuit: | maaku, they got stephen thomas of ripple labs to do it |
| 19:19:47 | maaku: | "You keep using this word, but I don't think it means what you think it means..." |
| 19:19:48 | phantomcircuit: | technically they are separate companies |
| 19:19:54 | phantomcircuit: | but that is a meaningless difference |
| 19:19:58 | hearn: | er |
| 19:20:10 | hearn: | stefan is not an employee of kraken |
| 19:20:13 | phantomcircuit: | jesse and jed are best friends forever |
| 19:20:46 | hearn: | jed isn't involved with ripple anymore, iiuc |
| 19:20:50 | phantomcircuit: | hearn, as far as im concerned they are engaged in a racketeering operation together |
| 19:21:06 | phantomcircuit: | but again |
| 19:21:09 | phantomcircuit: | (i wont even try to hid my contempt for jesse powell) |
| 19:23:20 | sipa: | hearn: oh really? |
| 19:24:12 | phantomcircuit: | sipa, he was pushed out in February |
| 19:24:20 | phantomcircuit: | probably something about him being a criminal or something |
| 19:24:23 | phantomcircuit: | >.> |
| 19:24:25 | phantomcircuit: | <.< |
| 19:24:41 | hearn: | he hadn't really been involved for a while, i believe. regardless this is irrelevant. |
| 19:25:16 | hearn: | kraken's method doesn't need to be perfect or bulletproof to be useful. it stands as evidence for governments that the community is finding ways to "regulate itself" with ideas they themselves could not have come up with. |
| 19:25:36 | hearn: | in that sense it's a good stepping stone to some full blown wizardry that's got ZKPs and all the magical stuff we all want |
| 19:25:56 | phantomcircuit: | hearn, that's nice, if you give them the benefit of the doubt |
| 19:25:59 | phantomcircuit: | i personally do not |
| 19:26:06 | hearn: | and if you trust stefan to be independent and know what he's doing (which I do), then it's useful as an audit too |
| 19:26:17 | hearn: | well, ok then. just accept that it's useful for some people and not for others |
| 19:26:17 | phantomcircuit: | so i assume that this is smoke and mirrors in which they know their measures are not adequate |
| 19:28:20 | phantomcircuit: | hearn, er... their stated process does not prove anything about reserves regardless of whether you trust stephen thomas or not |
| 19:28:23 | helo: | it is just as good proof that the self-regulation isn't viable if it isn't bulletproof |
| 19:28:43 | hearn: | stefan |
| 19:28:45 | hearn: | not stephen |
| 19:28:53 | phantomcircuit: | yeah i cant speel |
| 19:32:10 | phantomcircuit: | hearn, indeed i would posit that their audit protocol is designed specifically to be deceptive |
| 19:33:11 | hearn: | what would you change about it |
| 19:33:41 | maaku: | hearn: it needs to be continuous and on-going |
| 19:33:51 | maaku: | as well as independently verifiable |
| 19:34:08 | hearn: | i said *do* differently. not a wishlist |
| 19:34:16 | hearn: | as in, assuming you have the same amount of time and resources stefan did |
| 19:35:34 | phantomcircuit: | hearn, substantially increase the number of independent auditors from 0 to something greater than 0 |
| 19:36:02 | hearn: | so it boils down to you don't like jed or jesse, even though the actual audit was done by michael and stefan. |
| 19:36:04 | maaku: | meaningless question. they need to be doing publicly distributed zkp audits. period. |
| 19:36:18 | hearn: | and they already said they wanted to do more audits with other auditors in future. |
| 19:36:22 | hearn: | so,you may get your wish anyway |
| 19:56:09 | LarsLarsen: | Even snarks as it exists today would be enough, because an exchange can afford to have servers just generating proofs all day for paying customers |
| 19:59:11 | maaku: | LarsLarsen: would be enough if there was a publicly available snarks implementation :) |
| 20:01:35 | jrmithdobbs: | [[isX,isXX],[isY,isYY]] & each any |
| 20:01:39 | jrmithdobbs: | wrong channel ;p |
| 20:05:27 | LarsLarsen: | maaku: there is |
| 20:05:31 | LarsLarsen: | maaku: there are 3 |
| 20:05:40 | LarsLarsen: | 1 is not available |
| 20:05:43 | maaku: | LarsLarsen: ? |
| 20:05:45 | maaku: | link? |
| 20:06:13 | maaku: | I know of only Pinoccio, which is non-commercial and at the level of arithmetic circuits |
| 20:06:32 | maaku: | both SNARKs for C and the Zerocash stuff is proprietary |
| 20:07:30 | LarsLarsen: | oooh, damn... those bastards |
| 20:07:47 | maaku: | the ideas are open and out there, but practical implementations ... |
| 20:09:03 | LarsLarsen: | yeah.... well its hard to wrap your head around that |
| 20:12:11 | maaku: | The basic idea is really simple |
| 20:12:46 | maaku: | at some point I'll get around to writing a libsnark, and an LLVM-to-circuit compiler |
| 20:13:41 | LarsLarsen: | please do |
| 20:13:51 | LarsLarsen: | why are these academic snarks proprietary? |
| 20:14:05 | maaku: | * maaku shrugs |
| 20:14:29 | hearn: | they intend to open source it |
| 20:14:33 | hearn: | just not yet |
| 20:14:49 | LarsLarsen: | cool |
| 20:14:51 | maaku: | for Pinoccio, it's out of microsoft research, hence the non-commercial license |
| 20:15:18 | hearn: | the zerocash guys said they'd open source in MAy |
| 20:15:23 | hearn: | and they're zk-SNARK based |
| 20:15:29 | LarsLarsen: | cool |
| 20:15:42 | hearn: | given that Eli et al changed the system quite dramatically as recently as December I can see why they're keeping the source close to their chest for now |
| 20:15:52 | hearn: | they don't want to be supporting code that's still changing very much |
| 20:15:52 | maaku: | SNARKs for C is based on GPL code, but they just haven't distributed it yet. they gave a deadline for open sourcing it which was last summer... |
| 20:16:06 | LarsLarsen: | yeah thats why I thought it was available |
| 20:16:09 | LarsLarsen: | but not the "new" one |
| 20:16:30 | LarsLarsen: | I thought I could find a link for tinyram :( |
| 20:16:37 | maaku: | the zerocash stuff ... i don't know. I think those guys are understandably concerned about the legal ramifications of releasing zerocash code |
| 20:16:39 | hearn: | there is a web page and a mailing list, that they did not use so far |
| 20:17:01 | hearn: | *shrug* well they said they'd do it. they didn't seem to care much about the legal side |
| 20:17:30 | LarsLarsen: | the snarks part is no big deal |
| 20:17:34 | LarsLarsen: | the money part is on them |
| 20:18:21 | maaku: | They may have said that originally, but I believe they've gotten feedback from regulators since. |
| 20:18:36 | hearn: | evidence for that? |
| 20:18:43 | maaku: | Personal conversations |
| 20:18:46 | hearn: | ok |
| 20:18:51 | hearn: | with them? |
| 20:19:05 | maaku: | Yes |
| 20:19:39 | maaku: | My understanding is that they still want to open source it in some form |
| 20:19:49 | maaku: | There's just more uncertainty about what that means now |
| 20:20:13 | maaku: | Originally they were going to do a zerocoin/zerocash alt themselves, but that seems less likely now |
| 20:20:53 | LarsLarsen: | baby steps |
| 20:22:01 | hearn: | it would have not been very successful anyway. no way to do a light mode. annoying if regulators are interfering with academic research like that |
| 20:24:42 | maaku: | hearn: all you need for SPV mode is hash tree commitments |
| 20:25:11 | maaku: | i'd have to review the papers to say exactly how to do it, but I remember working that out the first time I read them |
| 20:25:34 | maaku: | but imho the bigger issue is gateway counter-party risk |
| 20:25:42 | maaku: | it's not really viable as an alt until you have two-way pegging |
| 20:25:53 | hearn: | well their proofs require at least 120mb of data to create, iirc. or something like that. |
| 20:26:12 | hearn: | and several minutes to calculate. pretty painful on a phone. probably ok on a laptop |
| 20:26:14 | hearn: | if you're patient :) |
| 20:26:27 | maaku: | oh yeah that problem :) i thought you meant something else |
| 20:26:42 | maaku: | there are zkp constructions which let you delegate that |
| 20:26:51 | maaku: | although zerocash as-is doesn't have that property |
| 20:27:58 | LarsLarsen: | We dont even need snarks, we can coinjoin with automated matching, and if that isnt sneaky enough use some less-exotic ZKP for signing process |
| 20:30:21 | maaku: | LarsLarsen: I'm obviously an advocate of CJ. But there is definately a real difference between CJ anonymity-set increasing and truly anonymous Zerocash |
| 20:32:50 | LarsLarsen: | maaku: you're just in another anonymity-set called "all zerocoins outstanding" |
| 20:33:48 | maaku: | LarsLarsen: Zero*cash* -- it's more than that, as values are hidden too |
| 20:34:03 | LarsLarsen: | I understand zerocash |
| 20:34:31 | maaku: | so you anonymity set is "a user of zerocash" |
| 20:34:54 | maaku: | which is really as big as it possibly could be - presumably they know you're using zerocash anyway through packet analysis or something |
| 20:35:05 | LarsLarsen: | if EVERY transaction is zero cash sure |
| 20:35:59 | LarsLarsen: | but they're expensive and would be just used for things much like coin joins where they become transparent again on the other side. |
| 20:36:39 | LarsLarsen: | I agree there is a difference, and I agree there is a market for that kind of level of security |
| 20:36:49 | LarsLarsen: | but.... shouldnt we walk first |
| 20:37:17 | maaku: | meh, I don't think they're that expensive |
| 20:37:23 | LarsLarsen: | we'll find out |
| 20:37:27 | LarsLarsen: | maybe magic happens |
| 20:37:29 | maaku: | 1sec proving time, 1ms validation time |
| 20:38:50 | LarsLarsen: | Well I'll be thrilled when I can time it :) |
| 20:39:51 | maaku: | well the bigger issue imho is the CRS trapdoor |
| 20:40:11 | maaku: | unlimited, undetectable inflation makes it a non-starter :( |
| 20:40:36 | maaku: | but this is all new crypto, maybe there are constructions yet to be discovered |
| 20:40:49 | hearn: | 1 sec? i thought it was much higher |
| 20:41:35 | maaku: | hearn: well it'd certainly be higher on an ARM cpu. i think that was timed on a server-grade CPU |
| 20:42:25 | maaku: | * maaku goes to check the paper |
| 20:43:33 | maaku: | yes, you're right : 50s for SPLIT and 102s for JOIN |
| 20:43:55 | maaku: | on a core i7-2630M (laptop, not server) |
| 20:44:20 | maaku: | and 9.5s validation |
| 20:44:46 | gmaxwell: | huh? sounds like a typo on the validation. (the proving speeds sound fine) |
| 20:44:55 | gmaxwell: | sure thats not 9.5ms? |
| 20:45:51 | maaku: | correct i meant 9.5ms |
| 20:53:49 | hearn: | maaku: that's more like what i remembered |
| 20:54:02 | maaku: | then you have a better memory than me :) |
| 21:25:20 | lnovy: | lnovy is now known as RogerVer |
| 21:25:52 | RogerVer: | RogerVer is now known as lnovy |
| 21:59:46 | zooko: | zooko has left #bitcoin-wizards |
| 23:04:46 | copumpkin: | have y'all already discussed kraken's audit? |
| 23:20:21 | comboy: | I'm happy there's some movement, but so far it still seems to be a lot like "Bob says it's OK" |
| 23:27:14 | maaku: | comboy: yes, check the logs for earlier today |
| 23:31:09 | comboy: | maaku: thx I didnt see it |
| 23:32:04 | copumpkin: | ah |
| 23:32:27 | copumpkin: | hmm, so it seems that the last word was phantomcircuit saying that it didn't prove much of anything |
| 23:32:35 | copumpkin: | it certainly didn't seem ideal to me |
| 23:34:13 | maaku: | it doesn't really prove anything at all |
| 23:34:13 | phantomcircuit: | copumpkin, there was a point at which stefan thomas' word would have been enough for me, that time was before ripple labs |
| 23:34:34 | copumpkin: | yeah, of all the people, he doesn't seem like a particularly desirable auditor |
| 23:34:37 | phantomcircuit: | as it stands today kraken and ripple are far too closely related for him to mean anything as an auditor |
| 23:34:48 | maaku: | eh, that's a side issue. |
| 23:34:54 | copumpkin: | well, new Ripple seems independently sketchy, regardless of kraken |
| 23:34:57 | phantomcircuit: | it's like claiming your CTO's cousin is an acceptable auditor |
| 23:35:03 | maaku: | we shouldn't be taking *anybody*'s word for it |
| 23:35:08 | copumpkin: | but I'm more concerned about the system |
| 23:35:08 | copumpkin: | yeah |
| 23:35:41 | phantomcircuit: | maaku, i can understand why they dont want to publish a list of all of their utxo |
| 23:35:45 | maaku: | and when there exist solutions that allow anyone to act as auditor, then chosing a one-time audit with a specific auditor should automatically be suspect |
| 23:35:46 | phantomcircuit: | that's not unreasonable |
| 23:35:49 | copumpkin: | what bugs me is that they seem to be riding the community's respect for gmaxwell by claiming they're doing something that's mostly gmaxwell's design, except more privacy preserving |
| 23:35:50 | maaku: | phantomcircuit: they don't have to |
| 23:36:04 | phantomcircuit: | however using a single auditor who isn't independent is ridiculous |
| 23:36:51 | comboy: | phantomcircuit: any reading related to your contempt to jesse? he seemed to be talking with sense |
| 23:37:41 | phantomcircuit: | comboy, the best that i can tell he is part of a comical criminal enterprise that spans charlie/roger/himself/jed |
| 23:37:49 | phantomcircuit: | i said this about 2 years ago |
| 23:37:54 | phantomcircuit: | charlie is going to federal prison |
| 23:38:04 | phantomcircuit: | roger has fled to the carribean and renounced his us citizenship |
| 23:38:09 | phantomcircuit: | you decide if im wrong |
| 23:38:42 | phantomcircuit: | oh and jed was just forced out of ripple labs |
| 23:38:55 | phantomcircuit: | im assuming by google ventures because he's such a massive liability |
| 23:39:00 | maaku: | comboy: what bugs me is that this is lipstick on a pig - it has nothing whatsoever to do with the zero-knowledge auditable proofs gmaxwell and others described |
| 23:40:02 | comboy: | well, I don't know much, but in the beginning bitcoin world was so small that it would be hard to judge people based just on who they interacted with |
| 23:40:28 | phantomcircuit: | comboy, this isn't merely interaction, they were all deeply in bed with each other on nearly everything |
| 23:40:38 | phantomcircuit: | im sure roger is the principle investor behind kraken |
| 23:41:01 | maaku: | "Greg: I have this zkp setup which lets anyone prove that this auditing program ran correctly! Kraken: Awesome. How about instead we just pay Stefan to say he ran it?" |
| 23:41:02 | phantomcircuit: | he was the principle behind bitinstant until he scammed the winklevoss twins |
| 23:41:09 | comboy: | maaku: yeah, I like they are trying but the news tites are funny, bitquick did that even more |
| 23:42:34 | comboy: | phantomcircuit: ok, I'm not diving in, enough interesting crypto stuff not to explore people connections, but I do hope it will at least start some competition between exchanges to provide better proof than others |
| 23:43:30 | comboy: | and regarding discussion earlier of users privacy vs publishing list of addresses, if no deposit addresses would be included, is there any privacy issue? |
| 23:44:33 | maaku: | comboy: my opinion is no. but the counter-argument is that you could then identify the deposit addresses, and identify how much someone is using a service, etc. |
| 23:44:33 | phantomcircuit: | comboy, hypothetically there is not, in practice the way more exchanges operate it would be |
| 23:44:55 | phantomcircuit: | the issue is that users almost universally reuse addresses |
| 23:45:04 | rastapopuloto: | rastapopuloto has left #bitcoin-wizards |
| 23:45:08 | maaku: | if people didn't reuse addresses, used coinjoin, etc. it wouldn't be a problem |
| 23:47:54 | comboy: | well I guess the issue is that if they want to make it clever, I mean backend moving coins around a bit so that's it's not really possible to identify deposit addresses, then you have to spend some on tx fees |
| 23:48:20 | phantomcircuit: | maaku, coinjoin isn't likely to be used widely until the tools for it are easily and readily available |
| 23:48:58 | phantomcircuit: | comboy, well no you just need to have patience and a large enough reserve that having a bunch of coins tied up doesn't cause liquidity issues |
| 23:50:08 | comboy: | phantomcircuit: hmm yeah, but in general I would be happy if they would be proving just cold storage, which should prove like 90% of the funds |
| 23:51:18 | phantomcircuit: | uh what |
| 23:51:26 | phantomcircuit: | comboy, that should prove 100% of the funds |
| 23:51:52 | phantomcircuit: | any shared wallet service operating with less than 100% of liabilities in cold storage is crazy as fuck |
| 23:52:17 | comboy: | phantomcircuit: that would be perfect yes, but proving just cold storage is much easier in implementation, and personally I choose exchange proving 90% correct way than 100% audit |