00:27:48petertodd: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:25petertodd: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:16nsh:hashing pools could provide "incubation" services
00:29:33petertodd:nsh: sure, and those hashing pools aren't exactly decentralized
00:30:01petertodd: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:32petertodd: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:32:15petertodd: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:36nsh:blocking the 51% attacks?
00:33:13nsh: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:14petertodd:nsh: no, blocking people using the blockchain for arbitrary proof-of-publication
00:33:15nsh:in principle
00:33:22nsh:ah, right
00:33:52petertodd: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:15nsh:* nsh nods
00:35:19petertodd: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:11petertodd: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:22petertodd:nsh: and there's a lot of potential applications like that
00:36:48nsh:i think it would be sensible to collaborate on reaching optimal ecological relationships
00:37:03nsh:but convincing and facilitating that is harder
00:37:04petertodd: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:33nsh:* nsh nods
00:37:52petertodd:nsh: yes indeed - when the other side wants to see your baby die people tend to be less than civil
00:38:12nsh:you're always going to run into human nature :)
00:40:06maaku:petertodd: I'd love to see you attack namecoin
00:40:41petertodd:maaku: namecoin is trivially attackable by ghash.io last I checked - they have a majority of hashing power
01:56:16phantomcircuit:petertodd, ghash.io isn't >50% of namecoin hashing power
01:56:48phantomcircuit:eligius/btc guild/cloudhashing are about equal
02:37:26just[dead]:just[dead] is now known as justanotheruser
02:55:13Guest73297:Guest73297 is now known as ageis
03:19:21justanotheruser:What are the faults in bitmessage other than proof of work?
03:55:15sipa:justanotheruser: no incentive to mine
03:55:37justanotheruser:sipa: there is no mining?
03:56:04sipa:oh, sorry, confusing with twister
03:56:40justanotheruser:Is twister something like BM, with a block chain?
04:03:27phantomcircuit:sipa, so im looking at wallet load times again, d2i_ECPrivateKey seems to be taking 0.4ms
04:03:37phantomcircuit:ssValue >> pkey is taking the difference
04:03:58Ursium:gmaxwell: you mentionned vbuterin messed up in some place of his articles - care to comment?
04:04:16Ursium:then again i undertand if someone fucks up it's not your problem
04:04:36jgarzik:justanotheruser, bitmessage is a rough draft
04:05:08jgarzik: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:43jgarzik: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:55justanotheruser: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:07justanotheruser:jgarzik: yes, their original paper mentions streams
04:06:29justanotheruser:Perhaps they will implement it when it when they start growing
04:07:13jgarzik: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:28jgarzik:justanotheruser, it does provide some measure of hiding its users, unless I'm missing something
04:07:28phantomcircuit:justanotheruser, yes it is fundamentally not scalable to use a flood network without some sort of global restriction
04:07:36phantomcircuit:in bitcoin that restriction is the block size
04:08:27justanotheruser:jgarzik: what would the Sybil hurt exactly? Being able to identify someone?
04:08:42sipa:phantomcircuit: that's crazy slow
04:09:01phantomcircuit:sipa, yeah it seems off
04:09:03sipa:phantomcircuit: it probably verifies that the public and private key match
04:09:03jgarzik:justanotheruser, being able to craft what your target sees or does not see
04:09:16phantomcircuit:sipa, hmm maybe
04:09:29phantomcircuit:in that case my patch to improve load times has been broken by an openssl change
04:09:35justanotheruser:jgarzik: really? Does it not use the same connectivity as bitcoin? I assumed it did
04:09:53sipa:only what they do not see
04:09:58jgarzik:justanotheruser, no, it does not use the same connectivity as bitcoin
04:10:17phantomcircuit:sipa, ssValue >> pkey;
04:10:22phantomcircuit:that takes even longer
04:10:33sipa:phantomcircuit: fun
04:10:35justanotheruser:I guess that's what I get for trusting #bitmessage instead of reading the source :/
04:10:45jgarzik: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:58sipa:phantomcircuit: let's get rid of openssl
04:11:03petertodd:justanotheruser: what do you mean by connectivity?
04:11:06jgarzik:sipa, +1
04:11:09sipa:jgarzik: yeah, that's what i meant
04:11:24sipa:petertodd: connection graph, i guess
04:11:32justanotheruser:petertodd: node discovery and network topology
04:11:38phantomcircuit:sipa, it's really annoying to do this stuff, i have to add a bunch of performance counters everywhere
04:11:44petertodd:justanotheruser: right, that part is basically identical to bitcoin
04:12:01jgarzik: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:02justanotheruser:What is different making it jammable?
04:12:03phantomcircuit:sipa, agreed
04:12:08jgarzik:drop that, but still need gmp or whatnot
04:12:10phantomcircuit:i had this down to like 2usec per key
04:12:10petertodd:justanotheruser: the problem is that without pow you have no way of detecting if you've been jammed
04:12:19sipa:phantomcircuit, jgarzik: #bitcoin-dev
04:12:47justanotheruser:petertodd: you mean without pow and a block chain?
04:13:01petertodd:justanotheruser: right, sorry, pow proof-of-publication and all that
04:13:11petertodd:justanotheruser: bitmessage does of course have pow! just not consensus
04:13:35justanotheruser:petertodd: so is it fundamentally flawed w/o a block chain?
04:14:04petertodd:justanotheruser: well, it's fundementally less secure, whether or not that means "flawed" is up to you
04:14:36justanotheruser:petertodd: would a block chain that gets pruned after 2 weeks of blocks be better?
04:14:53sipa:petertodd: bitmessage has pow?
04:15:14justanotheruser:sipa: hashcash preventing spam and DoS
04:15:26sipa:non transferrable proof of work
04:15:27petertodd:justanotheruser: maybe, but you need incentives - twister tried something like that and failed badly
04:16:35justanotheruser:petertodd: hmm... so the only options are an altcoin or many small bitcoin tx? Or a 1-1 pegged altcoin?
04:16:42petertodd: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:09petertodd:justanotheruser: not necessarily - those options don't inherently have security
04:17:36petertodd:justanotheruser: or, sorry, the altcoin no - making use of bitcoin is likely to work, but for a price
04:18:21justanotheruser:petertodd: somehow you have to incentivize miners.
04:19:09justanotheruser:petertodd: are you saying its insecure because of the low hashrate of the altcoin?
04:19:13petertodd: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:55petertodd: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:14petertodd:justanotheruser: adding a blockchain to that just helps everyone agree what has been published so everyone's work builds upon each other
04:20:25justanotheruser: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:30petertodd:justanotheruser: turning that all into a tree makes it easy to have multiple tiers of security
04:20:45petertodd:justanotheruser: no, it assures you that if your message is blocked *you can find out*
04:21:22justanotheruser:Yeah, that's what I mean. It let's you know if it isn't out there
04:21:54justanotheruser:Therefore, you could solve that with just a response message of "I got this", right?
04:21:55petertodd:Ah, yeah, that's absolutely correct
04:22:27petertodd: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:43petertodd:secondly, with bitmessage, responding to messages has privacy problems...
04:22:49justanotheruser:Good point.
04:23:41justanotheruser:So is there a way to either make jamming impossible, or to know you're being jammed without a block chain?
04:25:20petertodd:Sure, invoke centralized authority
04:25:50justanotheruser:Hah, is there another way
04:26:21Luke-Jr:see if you get an answer
04:27:05petertodd: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:41petertodd: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:21justanotheruser:petertodd: how does stake ensure everyone got it?
04:31:56justanotheruser:They could just jam the stake tokens, right?
04:32:06petertodd:justanotheruser: again, if you don't hear from them saying "I got it!" you know the jam free network has failed
04:32:09petertodd:that's it
04:37:44justanotheruser:How are "I got it" messages different for stake than the message themselves?
04:38:51petertodd:justanotheruser: because "I got it" can be a signature on a new block in the blockchain of all messages
04:41:07justanotheruser:petertodd: oh, so we are using a block chain for the messages? I though we were talking proof of bitcoin stake
04:41:48petertodd:oh, no, I was talking about a hypothetical proof-of-publication system via proof-of-stake
04:42:21justanotheruser:And the stake is in the message block chain?
04:42:33petertodd:who knows? could be anything
04:42:58petertodd:"stake" in this example is just "I have a private key that the system defines as being a stakeholder"
04:44:10justanotheruser: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:31petertodd:justanotheruser: I think you're confusing things; again I'm talking about hypothetical systems here
04:46:30justanotheruser:petertodd: would this hypothetical systems PoS involve bitcoin stake, or stake in its own block chain?
04:46:53petertodd:justanotheruser: who knows? like I say, it's a thought experiment
04:48:26justanotheruser: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:59wyager:Is namecoin.org legit? They have more binaries than namecoin.info.
04:49:09petertodd:justanotheruser: potentially it could, but then you have to ask yourself if signing for the same stake multiple times is malicious
04:50:24justanotheruser:petertodd: not if you can somehow have all your messages proven in the block chain in a regular tx
04:50:39petertodd:justanotheruser: that's ugly - data hiding problem
04:51:15justanotheruser:petertodd: no, I mean in an actual tx meant to transfer valur
04:51:16petertodd:justanotheruser: on the list somewhere I worked out the issues involved for a potential zerocoin alt last summer using that design
04:53:14justanotheruser:petertodd: do you have a post or paper about it?
04:54:38petertodd:justanotheruser: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
04:55:29petertodd:justanotheruser: remember though that it's dependent on a very advanced form of scorched-earth to respond to attackers
04:56:30justanotheruser:petertodd: so does it scale to a large number of messages?
04:56:57petertodd:justanotheruser: same scalability problem as bitcoin, but using trees can potentially fix that
05:04:02justanotheruser:Thanks for your help petertodd. I'll probably have to read that a few more times before I can understand that
07:20:16ageis:ageis is now known as Guest67535
07:36:17c0rw1n:c0rw1n is now known as c0rw|sleep
11:57:15lnovy:lnovy is now known as gammer
11:57:45gammer:gammer is now known as lnovy
11:57:51justanotheruser:justanotheruser is now known as just[dead]
11:59:53just[dead]:just[dead] is now known as justanotheruser
12:01:41justanotheruser:justanotheruser is now known as just[dead]
12:19:18just[dead]:just[dead] is now known as justanotheruser
13:29:18justanotheruser:justanotheruser is now known as just[dead]
13:29:37just[dead]:just[dead] is now known as justanotheruser
13:34:36justanotheruser:justanotheruser is now known as just[dead]
13:48:36sl01:anyone have suggestions on multi party OTR chat for desktop ?
14:44:52bobke_:bobke_ is now known as bobke
15:00:03just[dead]:just[dead] is now known as justanotheruser
15:32:21justanotheruser:justanotheruser is now known as just[dead]
15:40:18just[dead]:just[dead] is now known as justanotheruser
15:58:57justanotheruser:justanotheruser is now known as just[dead]
16:13:05just[dead]:just[dead] is now known as justanotheruser
16:30:46justanotheruser:justanotheruser is now known as just[dead]
16:37:48rdponticelli_:rdponticelli_ is now known as rdponticelli
17:32:11Guest67535:Guest67535 is now known as ageis
18:32:17maaku:maaku is now known as Guest53469
18:35:28Guest53469:Guest53469 is now known as maaku
18:35:57maaku:maaku is now known as Guest82878
18:38:03maaku_:maaku_ is now known as maaku
18:55:43phantomcircuit:gmaxwell, is it just me or is the kraken thing failing to prove they have any assets
19:01:32shesek:phantomcircuit, I didn't get why an auditor is needed...
19:01:46phantomcircuit:shesek, because it's a scam of course
19:01:58phantomcircuit:(i wont even try to hid my contempt for jesse powell)
19:02:41shesek: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:48hearn:i think the idea is that they don't want to reveal their addresses/UTXOs
19:05:55hearn:which is reasonable, because that would compromise the privacy of all their users
19:06:05hearn:it's sort of a halfway house
19:08:21shesek:their users would be in a pretty huge anonymity set
19:08:31shesek:I'm not sure how much of a problem that is
19:09:15shesek: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:18maaku:hearn: how would it compromise the privacy of their users?
19:09:28shesek:which could compromise the users privacy in a way
19:09:42hearn: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:21maaku:hearn: there are zero-knowledge constructions just for this purpose
19:10:51shesek:I don't think there's something that's practical and usable right now though, is there?
19:12:36hearn:yes yes of course. kraken wanted something they could actually implement and use in a reasonable timeframe
19:12:43hearn:not wizardry
19:14:09maaku:shesek: it wouldn't be terribly difficult to put together. probably cost less than paying these auditors :\
19:15:32phantomcircuit: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:43phantomcircuit:i would put forth that their statements amount to fraud
19:17:03maaku: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:08maaku: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:00maaku:the zerocash prove-I-have-a-coin circuit is nearly identical to the exchange's prove-I-have-an-output
19:19:02phantomcircuit:maaku, their auditor was an employee
19:19:05phantomcircuit:not an actual audit
19:19:25maaku:hah! wow, not an audit at all
19:19:42phantomcircuit:maaku, they got stephen thomas of ripple labs to do it
19:19:47maaku:"You keep using this word, but I don't think it means what you think it means..."
19:19:48phantomcircuit:technically they are separate companies
19:19:54phantomcircuit:but that is a meaningless difference
19:20:10hearn:stefan is not an employee of kraken
19:20:13phantomcircuit:jesse and jed are best friends forever
19:20:46hearn:jed isn't involved with ripple anymore, iiuc
19:20:50phantomcircuit:hearn, as far as im concerned they are engaged in a racketeering operation together
19:21:06phantomcircuit:but again
19:21:09phantomcircuit: (i wont even try to hid my contempt for jesse powell)
19:23:20sipa:hearn: oh really?
19:24:12phantomcircuit:sipa, he was pushed out in February
19:24:20phantomcircuit:probably something about him being a criminal or something
19:24:41hearn:he hadn't really been involved for a while, i believe. regardless this is irrelevant.
19:25:16hearn: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:36hearn: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:56phantomcircuit:hearn, that's nice, if you give them the benefit of the doubt
19:25:59phantomcircuit:i personally do not
19:26:06hearn: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:17hearn:well, ok then. just accept that it's useful for some people and not for others
19:26:17phantomcircuit:so i assume that this is smoke and mirrors in which they know their measures are not adequate
19:28:20phantomcircuit:hearn, er... their stated process does not prove anything about reserves regardless of whether you trust stephen thomas or not
19:28:23helo:it is just as good proof that the self-regulation isn't viable if it isn't bulletproof
19:28:45hearn:not stephen
19:28:53phantomcircuit:yeah i cant speel
19:32:10phantomcircuit:hearn, indeed i would posit that their audit protocol is designed specifically to be deceptive
19:33:11hearn:what would you change about it
19:33:41maaku:hearn: it needs to be continuous and on-going
19:33:51maaku:as well as independently verifiable
19:34:08hearn:i said *do* differently. not a wishlist
19:34:16hearn:as in, assuming you have the same amount of time and resources stefan did
19:35:34phantomcircuit:hearn, substantially increase the number of independent auditors from 0 to something greater than 0
19:36:02hearn: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:04maaku:meaningless question. they need to be doing publicly distributed zkp audits. period.
19:36:18hearn:and they already said they wanted to do more audits with other auditors in future.
19:36:22hearn:so,you may get your wish anyway
19:56:09LarsLarsen: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:11maaku:LarsLarsen: would be enough if there was a publicly available snarks implementation :)
20:01:35jrmithdobbs:[[isX,isXX],[isY,isYY]] & each any
20:01:39jrmithdobbs:wrong channel ;p
20:05:27LarsLarsen:maaku: there is
20:05:31LarsLarsen:maaku: there are 3
20:05:40LarsLarsen:1 is not available
20:05:43maaku:LarsLarsen: ?
20:06:13maaku:I know of only Pinoccio, which is non-commercial and at the level of arithmetic circuits
20:06:32maaku:both SNARKs for C and the Zerocash stuff is proprietary
20:07:30LarsLarsen:oooh, damn... those bastards
20:07:47maaku:the ideas are open and out there, but practical implementations ...
20:09:03LarsLarsen:yeah.... well its hard to wrap your head around that
20:12:11maaku:The basic idea is really simple
20:12:46maaku:at some point I'll get around to writing a libsnark, and an LLVM-to-circuit compiler
20:13:41LarsLarsen:please do
20:13:51LarsLarsen:why are these academic snarks proprietary?
20:14:05maaku:* maaku shrugs
20:14:29hearn:they intend to open source it
20:14:33hearn:just not yet
20:14:51maaku:for Pinoccio, it's out of microsoft research, hence the non-commercial license
20:15:18hearn:the zerocash guys said they'd open source in MAy
20:15:23hearn:and they're zk-SNARK based
20:15:42hearn: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:52hearn:they don't want to be supporting code that's still changing very much
20:15:52maaku: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:06LarsLarsen:yeah thats why I thought it was available
20:16:09LarsLarsen:but not the "new" one
20:16:30LarsLarsen:I thought I could find a link for tinyram :(
20:16:37maaku:the zerocash stuff ... i don't know. I think those guys are understandably concerned about the legal ramifications of releasing zerocash code
20:16:39hearn:there is a web page and a mailing list, that they did not use so far
20:17:01hearn:*shrug* well they said they'd do it. they didn't seem to care much about the legal side
20:17:30LarsLarsen:the snarks part is no big deal
20:17:34LarsLarsen:the money part is on them
20:18:21maaku:They may have said that originally, but I believe they've gotten feedback from regulators since.
20:18:36hearn:evidence for that?
20:18:43maaku:Personal conversations
20:18:51hearn:with them?
20:19:39maaku:My understanding is that they still want to open source it in some form
20:19:49maaku:There's just more uncertainty about what that means now
20:20:13maaku:Originally they were going to do a zerocoin/zerocash alt themselves, but that seems less likely now
20:20:53LarsLarsen:baby steps
20:22:01hearn: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:42maaku:hearn: all you need for SPV mode is hash tree commitments
20:25:11maaku: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:34maaku:but imho the bigger issue is gateway counter-party risk
20:25:42maaku:it's not really viable as an alt until you have two-way pegging
20:25:53hearn:well their proofs require at least 120mb of data to create, iirc. or something like that.
20:26:12hearn:and several minutes to calculate. pretty painful on a phone. probably ok on a laptop
20:26:14hearn:if you're patient :)
20:26:27maaku:oh yeah that problem :) i thought you meant something else
20:26:42maaku:there are zkp constructions which let you delegate that
20:26:51maaku:although zerocash as-is doesn't have that property
20:27:58LarsLarsen: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:21maaku: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:50LarsLarsen:maaku: you're just in another anonymity-set called "all zerocoins outstanding"
20:33:48maaku:LarsLarsen: Zero*cash* -- it's more than that, as values are hidden too
20:34:03LarsLarsen:I understand zerocash
20:34:31maaku:so you anonymity set is "a user of zerocash"
20:34:54maaku: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:05LarsLarsen:if EVERY transaction is zero cash sure
20:35:59LarsLarsen: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:39LarsLarsen:I agree there is a difference, and I agree there is a market for that kind of level of security
20:36:49LarsLarsen:but.... shouldnt we walk first
20:37:17maaku:meh, I don't think they're that expensive
20:37:23LarsLarsen:we'll find out
20:37:27LarsLarsen:maybe magic happens
20:37:29maaku:1sec proving time, 1ms validation time
20:38:50LarsLarsen:Well I'll be thrilled when I can time it :)
20:39:51maaku:well the bigger issue imho is the CRS trapdoor
20:40:11maaku:unlimited, undetectable inflation makes it a non-starter :(
20:40:36maaku:but this is all new crypto, maybe there are constructions yet to be discovered
20:40:49hearn:1 sec? i thought it was much higher
20:41:35maaku:hearn: well it'd certainly be higher on an ARM cpu. i think that was timed on a server-grade CPU
20:42:25maaku:* maaku goes to check the paper
20:43:33maaku:yes, you're right : 50s for SPLIT and 102s for JOIN
20:43:55maaku:on a core i7-2630M (laptop, not server)
20:44:20maaku:and 9.5s validation
20:44:46gmaxwell:huh? sounds like a typo on the validation. (the proving speeds sound fine)
20:44:55gmaxwell:sure thats not 9.5ms?
20:45:51maaku:correct i meant 9.5ms
20:53:49hearn:maaku: that's more like what i remembered
20:54:02maaku:then you have a better memory than me :)
21:25:20lnovy:lnovy is now known as RogerVer
21:25:52RogerVer:RogerVer is now known as lnovy
21:59:46zooko:zooko has left #bitcoin-wizards
23:04:46copumpkin:have y'all already discussed kraken's audit?
23:20:21comboy: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:14maaku:comboy: yes, check the logs for earlier today
23:31:09comboy:maaku: thx I didnt see it
23:32:27copumpkin:hmm, so it seems that the last word was phantomcircuit saying that it didn't prove much of anything
23:32:35copumpkin:it certainly didn't seem ideal to me
23:34:13maaku:it doesn't really prove anything at all
23:34:13phantomcircuit:copumpkin, there was a point at which stefan thomas' word would have been enough for me, that time was before ripple labs
23:34:34copumpkin:yeah, of all the people, he doesn't seem like a particularly desirable auditor
23:34:37phantomcircuit:as it stands today kraken and ripple are far too closely related for him to mean anything as an auditor
23:34:48maaku:eh, that's a side issue.
23:34:54copumpkin:well, new Ripple seems independently sketchy, regardless of kraken
23:34:57phantomcircuit:it's like claiming your CTO's cousin is an acceptable auditor
23:35:03maaku:we shouldn't be taking *anybody*'s word for it
23:35:08copumpkin:but I'm more concerned about the system
23:35:41phantomcircuit:maaku, i can understand why they dont want to publish a list of all of their utxo
23:35:45maaku: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:46phantomcircuit:that's not unreasonable
23:35:49copumpkin: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:50maaku:phantomcircuit: they don't have to
23:36:04phantomcircuit:however using a single auditor who isn't independent is ridiculous
23:36:51comboy:phantomcircuit: any reading related to your contempt to jesse? he seemed to be talking with sense
23:37:41phantomcircuit:comboy, the best that i can tell he is part of a comical criminal enterprise that spans charlie/roger/himself/jed
23:37:49phantomcircuit:i said this about 2 years ago
23:37:54phantomcircuit:charlie is going to federal prison
23:38:04phantomcircuit:roger has fled to the carribean and renounced his us citizenship
23:38:09phantomcircuit:you decide if im wrong
23:38:42phantomcircuit:oh and jed was just forced out of ripple labs
23:38:55phantomcircuit:im assuming by google ventures because he's such a massive liability
23:39:00maaku: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:02comboy: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:28phantomcircuit:comboy, this isn't merely interaction, they were all deeply in bed with each other on nearly everything
23:40:38phantomcircuit:im sure roger is the principle investor behind kraken
23:41:01maaku:"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:02phantomcircuit:he was the principle behind bitinstant until he scammed the winklevoss twins
23:41:09comboy:maaku: yeah, I like they are trying but the news tites are funny, bitquick did that even more
23:42:34comboy: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:30comboy: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:33maaku: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:33phantomcircuit:comboy, hypothetically there is not, in practice the way more exchanges operate it would be
23:44:55phantomcircuit:the issue is that users almost universally reuse addresses
23:45:04rastapopuloto:rastapopuloto has left #bitcoin-wizards
23:45:08maaku:if people didn't reuse addresses, used coinjoin, etc. it wouldn't be a problem
23:47:54comboy: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:20phantomcircuit:maaku, coinjoin isn't likely to be used widely until the tools for it are easily and readily available
23:48:58phantomcircuit: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:08comboy: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:18phantomcircuit:uh what
23:51:26phantomcircuit:comboy, that should prove 100% of the funds
23:51:52phantomcircuit:any shared wallet service operating with less than 100% of liabilities in cold storage is crazy as fuck
23:52:17comboy: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