--- Log opened Sun Nov 17 00:00:01 2013
02:35 < skinnkavaj> are we still going to have centralized security exchanges or do you think coloured coins will help with that? everyone is working on coloured coin decentralized exchanges right now but i don't understand how it will not be centralized in some parts.
02:39 < warren> skinnkavaj: they are all centralized in some way.
02:52 < Guest12085> warren: not true there are fully decentralized colored coin proposals (e.g. freimarkets)
02:52 < Guest12085> skinnkavaj: concensus by block chain will always be expensive, period.
02:53 < maaku> but decentralized exchanges will exist for the rare cases in which they are needed
02:53 < maaku> such as ripple-like settlement
02:54 < maaku> but high volume exchange will always be centralized in some way
03:01 < Luke-Jr> there's already a decentralised bitcoin exchange, for like a year + now..
03:02 < Luke-Jr> coloured coins don't really have a viable use case
03:04 < skinnkavaj> (09:01:35) (Luke-Jr) there's already a decentralised bitcoin exchange, for like a year + now..
03:04 < skinnkavaj> are you talking about Localbitcoins?
03:05 < maaku> Luke-Jr: you see no use for user-issued assets?
03:11 < Luke-Jr> skinnkavaj: #bitcoin-otc
03:11 < Luke-Jr> maaku: I see no need for a decentralised blockchain for centralised assets.
03:13 < Luke-Jr> nor any benefit from it
03:13 < gmaxwell> Any of you feel like buying $800k in coins? that all it'll take to get mtgox usd to $500/btc.
03:14 < Luke-Jr> I don't have that much in MtGox
03:14 < maaku> Luke-Jr: freimarkets allows issuance from a multi-sig address, for example. useful perhaps for settlement at the highest level of a cartel
03:14 < maaku> which wouldn't trust any of its members individually to run the accounting server
03:15 < Luke-Jr> maaku: someone is going to be giving the shares value.
03:15 < gmaxwell> but why does it need a global decenteralized blockchain instead of some closed distributed system?
03:15 < gmaxwell> (closed as in predefined members)
03:16 < maaku> gmaxwell: i never said "global" ;)
03:17 < gmaxwell> okay I could but that, but such a system probably wouldn't be ideally constructed a a POW blockchain.
03:19 < maaku> true, this is probably a good application for (a modified version of) OpenCoin's concensus mechanism
03:20 < maaku> which i shouldn't be giving them credit for since it's basically two-phase-commit
04:58 < warren> anyone know adam3us's bitcointalk name?
05:40 < warren> adam3us: ping
05:40 < adam3us> warren: 'hello
07:35 < adam3us> btw it seems to me the limitation with CoinJoin is that it takes active participation of the participants; hence if CoinValidation virality takes hold people will have an economic incentive to stop using CoinJoin because it is not part of the protocol
07:35 < adam3us> CoinJoin as is, is a fantastic idea and the best we have deployable now.
07:37 < adam3us> my stab towards doing one more is RingCoin.  a ZKP that allows you to mix your coins with other people's coins without their participation, its like CoinJoin but whre you can chose other peoples coins to mix with, but without their participation... very cool IMO, the limitation is the mix is like 3kB per mixed value
07:39 < adam3us> if that was part of the protocol, it would be game over; taint tracing ramps up, someone takes it upon themselves to taint the lot, evenly for a modest fee; and repeat - that is in their economic interest because it protects their bitcoin holdings (and everyone else's) from a viral run on bitcoin fungibility increasing transacton costs and maybe crashing bitcoins price as everyone has a race to buy clean coin insurance - no one wants to be l
07:40 < adam3us> i believe there is hope of finding a much better than 3kB per mixed value.. gotta figure out another unpublished Schoenmakers footnote (what is it with the guy- has genius ideas and doesnt bother to publish them!)
07:44 < adam3us> i guess we know a number of other people like that here - its "done" once they've convinced themselves that it works, and finding energy to write in a digestable, never mind peer-reviewable form is like work its hard to find energy for, but schoenmakers is an associate prof at tue.nl and publishes lots a fair bit of other stuff.
07:45 < adam3us> btw i saw in jdillon's hacked email dump of various private IMs that gmaxwell also thought of the same direction - ring signatures are an interesting direction
12:47 < maaku> adam3us: you don't need complex crypto. just let people create composable components of transactions
12:47 < TD> warren: where's that?
12:56 < TD> i see
15:15 < warren> TD: where's what?
15:15 < TD> the jdillon thing, but i saw the thread
15:15 < warren> what about it?
15:16 < warren> https://twitter.com/matthew_d_green/status/401797786347114496 Zerocoin claims to have reduced the proof size by "98%", is this the "it is still 10KB" thing people were talking about earlier?
15:17 < warren> oh, they claim transactions are down to 240 bytes now, while the first version was 25KB
15:25 < Emcy> didnt say anything about how long it takes to verify the proofs though
15:25 < Emcy> i think gregory mention it was like 2 per second on current hardware
15:25 < gmaxwell> Emcy: no point in speculating about it without their paper out.
15:25 < Emcy> or mayby that was the lamport stuff
15:25 < gmaxwell> Emcy: the new stuff works in an entirely different way.
15:26 < Emcy> so its not zerocoin its something new
15:26 < gmaxwell> (I know what they're doing now, but would prefer to comment after the paper is out)
15:26 < Emcy> righto, be interesting to see if its the real deal
15:26 < TD> ditto
15:26 < gmaxwell> Emcy: they'll probably keep calling it zerocoin, but indeed, it will achieve somewhat different things and its done using a different mathmatical basis.
15:26 < TD> it's SCIP based, i guess we can say that.
15:27 < TD> but for anything more wait for the paper
15:27 < TD> i'm sure it'll be out soon
15:27 < Emcy> who is matthew green?
15:27 < TD> a top class guy
15:27 < TD> (one of the zerocoin researchers)
15:28 < gmaxwell> ;;lmgtfy matthew green
15:28 < Emcy> http://spar.isi.jhu.edu/~mgreen/ this one i assume
15:31 < Emcy> well he got hos doctorate in 3 years with a thesis on a privacy thing
15:31 < Emcy> so we will see
16:19 < adam3us> so i guess people eg amiller were thinking that you could do things with scip - eg you could compact a committed coin with a scip (zkp it adds up and relates to a previous payment)
16:20 < adam3us> probably other variants also scip-coin, so they seemingly have put something together
16:20 < adam3us> but another question is if you could  (and the are probably multiple configurations, scip is very general and flexible) would you want to
16:21 < adam3us> meaning its based on weil pairing and lots of cutting edge stuff
16:22 < adam3us> whats to say shamir or someone isnt going to break some of the assumptions or techniques - so we'd need to know the implications from the security unraveling partly - eg can they then attack individual coins which is maybe too expensive or can they attack the whole system.  hard t say without further details
17:29 < amiller> i doubt matt green is using anything with generic zk
17:30 < amiller> i have no idea what's actually in the new zerocoin thouhg
17:30 < Emcy> pixie dust
17:31 < adam3us> amiller: "TD: it's SCIP based, i guess we can say that."
17:31 < Emcy> if ti works it could be pixie dust for all i care
17:31 < amiller> i think td is just guessing
17:32 < adam3us> amiller: it seems to me if you allowed scip there should be multiple ways to build a scip-coin with privacy
17:32 < gmaxwell> No, td isn't guessing. It's zk-SNARK based.
17:32 < amiller> oh
17:32 < amiller> well... cool then
17:32 < adam3us> do we know a publication timeline?
17:33 < adam3us> fc2014?
17:33 < amiller> oakland
17:33 < gmaxwell> I dunno, I was told their paper was done and just being edited
17:33 < amiller> he'll put it on arxiv wthin weeks
17:33 < gmaxwell> well "done" and that they'd send it to me soon.
17:33 < gmaxwell> ah there you go.
17:34 < amiller> it can be zk-snark and still not use the generic tools like pinocchio or scip
17:34 < amiller> in other words i would still guess he'd construct it himself out of bilinear groups rather than compiling a circuit
17:35 < adam3us> amiller: yeah ok terms backwrds
17:35 < gmaxwell> there is also compiling a circuit but not using something fully generic like tinyram (e.g. more like pinocchio)
17:35 < gmaxwell> or mixing.
17:36 < amiller> pinocchio is identically as generic as tinyram!
17:36 < gmaxwell> you get pretty different circuits out of it though.
17:37 < amiller> yeah that changes
17:37 < amiller> i think the right question is whether it uses GGPR
17:38 < amiller> which all of the three generic snark projects do so far (scip, pinocchio, pantry)
17:38 < amiller> that's the particular way of using bilinear group primitives to do zk over arbitrary circuits
17:39 < gmaxwell> amiller: eli's group also has a backend that is not GGPR based apparently.
17:39 < amiller> well hm, i'm not aware of that
17:40 < gmaxwell> (IIRC their other one is a fiat shamir on some RS locally testable codes for 'more efficient' pcp)
17:41 < gmaxwell> amiller: IIRC it eliminates the trusted randomness that all the GGPR stuff needs for the construction of the proving key (which if violated allows the construction of false proofs)
17:41 < gmaxwell> but I have no @#$@ clue what the performance is really like, because ... theoreticians.
17:42  * amiller isn't sure about the trusted randomness needed for ggpr
17:43 < amiller> it's public coin to build the verification key, you could do it pseudorandomly like fiat-shamir too
17:45 < gmaxwell> amiller: it's annoying because I think most of the papers have really not been clear about this requirement.
17:45 < gmaxwell> It was my understanding that if you knew the original randomness then you could trivially produce false proofs, but I could be incorrect.
17:46  * warren is greatly amused.  Feathercoin has been trying and failing for 2 months to copy Litecoin 0.8.x and make it network compatible with their old 0.6 client.
17:50 < Luke-Jr> lol
17:52 < amiller> unrelated to zerocoin, the whole team at best people at microsoft research have published a workshop paper that no one heard about despite being presented at a workshop a week ago....
17:52 < amiller> http://forsyte.at/petshop-2013/
17:52 < amiller> called, unimaginatively, "Pinocchio Coin"
17:54 < gmaxwell> The coin is (telling) a lie.
17:54 < gmaxwell> hm. so it inflates when you lie about it?
17:56 < Luke-Jr> lol
17:58 < amiller> no, it just uses pinocchio's generic zksnark to do what zerocoin does apparently. it's also a 1 page paper and they give very little analysis.
17:59 < gmaxwell> do these people not feel any pain that their work never gets used in anything?
18:01 < TD> well i guess matthew does, hence the focus on building an actual alt coin
18:03 < gmaxwell> yea it was a general complaint about crypto folks. (well not just crypto, same thing exists in dsp / coding tech)
18:03  * amiller wonders what satisfaction can be had having people use your altcoin...
18:04 < gmaxwell> ;;ticker
18:04 < gmaxwell> oh gribble isn't here.
18:04 < gmaxwell> Well. there is at least <what gribble would have said>.  Kinda boring though. :P
18:04 < TD> in fairness, if every crypto paper had to create a useful real world app before they could do the next one, there'd be much less crypto research
18:04 < TD> btw does anyone want to connect with me on Pond?
18:05 < TD> (talking of crypto that needs usage)
18:05 < gmaxwell> a lot of stuff has applications, but it does seem that a lot of things get proven possible and then forgotten.
18:05 < Luke-Jr> amiller: you get to pump & dump?
18:06 < Luke-Jr> TD: wtf is Pond?
18:06 < maaku> TD: is pond stable enough to use for real stuff?
18:06 < maaku> Luke-Jr: email done right, from a crypto nerd's perspective
18:06 < maaku> https://pond.imperialviolet.org/
18:07 < Luke-Jr> something wrong with PGP+SMTP?
18:07 < amiller> metadata?
18:07 < maaku> yes, lots
18:07 < maaku> metadata, reliance in relays, etc.
18:08 < TD> maaku: it sort of sucks on MacOS X thanks to GTK and Go being rather 1990's, imo, but yes, it works and I've been using it to communicate a bit. a guy from the foundation forums set it up with me and we used it to have some back and forth discussions
18:08 < TD> Luke-Jr: the big one (other than it being a pain to use) is that PGP+SMTP leaks who you are talking to
18:08 < TD> Luke-Jr: and it turns out that often you can sort of guess what is being said, if you can see who is communicating
18:08 < Luke-Jr> this doesn't?
18:09 < TD> it's also got no forward secrecy. private key compromise == all sniffed/obtained comms owned
18:09 < TD> nope, pond runs exclusively over tor and all clients/servers communicate at randomized intervals, sending garbage if there's no real comms to do
18:09 < Luke-Jr> you can see who is communicating with each other over tor
18:09 < maaku> TD: I'll see if I can get it setup and reach out to you
18:10 < TD> maaku: there are binaries these days. if you send me a shared secret then that's all we need
18:10 < TD> Luke-Jr: not really. all you see is a bunch of hidden service connections that send traffic at random intervals. even if you can strip tor, the messages themselves are all encrypted using some very fancy crypto. even the server doesn't know who is sending a message to an account, and of course, accounts are all anonymous anyway
18:11 < TD> basically it's about the most extreme form of secure email imaginable. i'm tempted to call it massive overkill, but ...... maybe these days it's not
18:11 < TD> also the linux version supports using a TPM to implement secure delete, even if you have an SSD that wouldn't normally be able to delete data properly
18:11  * sipa invokes XKCD 538
18:11 < Luke-Jr> I just lost TPM in my upgrade :P
18:11 < Luke-Jr> new mobo just has a header
18:12 < TD> the downside of pond is there's no concept of an email address
18:12 < TD> before someone can send you messages, you have to do a key exchange with them
18:12 < Luke-Jr> and in any case, that's assuming the TPM vendor is trustable
18:12 < TD> well all the TPM is used for is the NVRAM really
18:13 < Luke-Jr> which the TPM *could* be making secret backups of..
18:13 < TD> nah. they're too limited.
18:13 < Luke-Jr> I wasn't aware of TPMs having open source designs
18:13 < Luke-Jr> or did someone do an X-ray audit or something?
18:14 < TD> their design and features are limited by the spec + cost pressure. there's nowhere for a secret backup to go. these things have storage measured in kilobytes
18:14 < TD> but sure if you go full tinfoil hat, then your computer has no way to delete stuff.
18:14 < Luke-Jr> TD: NSA-subsidised additional NVRAM never exposed to the outside
18:14 < TD> the TPM wasn't designed to be used in this way, so that'd require the NSA to be clairvoyant
18:14 < TD> which even I don't believe
18:14 < Luke-Jr> XD
18:15  * Luke-Jr wonders if TPMs from >1 year ago would work on his motherboard's header
18:15 < gmaxwell> Luke-Jr: they should.
18:16 < Luke-Jr> what would they be called? TPM "boards"?
18:16 < Luke-Jr> maybe I could wire my old motherboard's onboard TPM up to it somehow?
18:17 < TD> TPM chips
18:17 < Luke-Jr> chips plug direct into the header? ;)
18:17 < TD> probably. TPM runs on the LPC bus, traditionally.
18:18 < TD> though you may already have a TPM without knowing?
18:18 < Luke-Jr> I guess I should look at the header..
18:18 < TD> did you actually check?
18:18 < Luke-Jr> yes
18:18 < Luke-Jr> it was on my "list of things I lose in this upgrade"
18:18 < TD> i mean, there might be one integrated into some other chip
18:18 < TD> did you check if the kernel can see one?
18:18 < Luke-Jr> ASRock Z87 Extreme4
18:19 < Luke-Jr> not sure what I'd be looking for there
18:22 < TD> i think on some systems there is a /proc/tpm
18:22 < TD> but i dunno if that's always true
18:22 < TD> it might require a modprobe tpm first
18:22 < TD> not that it really matters if you have a hard disk
18:23 < TD> it's only an issue for people with log-structured file systems or SSDs
18:25 < maaku> TD: so long as it remains computable on consumer hardware, no such thing as overkill
18:25 < Luke-Jr> maaku: but you'll slow down my compiles!
18:25 < Luke-Jr> <.<
18:26 < Luke-Jr> TCSD TDDL ERROR: Could not find a device to open!
18:26 < Luke-Jr> guess I have none
18:29 < Luke-Jr> Newegg has no TPM stuff it seems
18:34 < gmaxwell> ebay.
18:39 < Emcy> pond reads similar to bitmessage
18:42 < maaku> Emcy: similar, but better imho
18:43 < Emcy> that means its less likely to catch on
18:44 < maaku> Emcy: ? I don't think bitmessage has any significant mindshare to speak of
18:44 < TD> it's not very similar
18:44 < maaku> if anything Pond is probably more well known (outside of bitcoin community)
18:45 < Emcy> just a joke. the good stuff gets passed up for the first thing that sort of works all the time
18:46 < Emcy> http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon decent overview
18:46 < Emcy> "weaponised" is a fair way to put it
19:09 < adam3us> jgarzik said on the zc thread "would rather see automatic mixing and privacy built into every client." you know actually that would be quite a reasonable fungibility fix in the face of coin validation fungibility risks - if its generally default and non-opt-in feature.  then the default reaction of biz will be to reject coin validation or they lose sales
19:11 < Emcy> if its not ubiquitous then using such measures automatically makes you the target you never wanted to be
19:11 < Emcy> so better that it is
19:17 < warren> I might have set a trap in the Litecoin code months ago that breaks in an obscure way if used with feathercoin's parameters...
19:18 < warren> but they are having trouble getting the ordinary functionality to work
19:18 < Emcy> heh
19:18 < Emcy> what does feathercoin do anyway
19:19 < warren> Emcy: copy > rename > add new logo > pump with lots of videos
19:19 < Emcy> also why dont you play with scrypt until gpu mining is actually infeasible, as claimed at the beginning
19:20 < sipa> i don't think many litecoin users still value that idea
19:20 < warren> or rather, it isn't broken with feathercoin's parameters, just becomes exploitable
19:20 < warren> I might have done this.
19:22 < Emcy> that was litcoins whole conceit though
19:22 < Emcy> to run on all those shitty semprons in bitcoin mining rigs
19:22 < warren> Emcy: Litecoin - sponsored by AMD
19:23 < Emcy> a-are you joking
19:24 < warren> maybe
19:24 < sipa> after AMD bought ATI, suddenly litecoin became viable on GPUs
19:24 < sipa> it all makes sense!
19:26 < Emcy> shiiiiiiiiiit
19:26 < Emcy> wonder how it goes on those APUs
19:26 < warren> not too well.  relies on memory bandwidth
19:27 < Emcy> so with ddr3 2500 or whatever then
19:27 < warren> might be decent on a PS4, if it were hackable
19:27 < Emcy> thats still well below gddr i suppose
19:32 < Emcy> i wonder what hardware security the new consoles will have
19:32 < Emcy> might make decent miner as you say if someone can break it
19:33 < Emcy> or a nice little PC
19:36 < warren> I was joking earlier, and a lot of this isn't wizards material.
21:52 < Luke-Jr> [00:24:48] <sipa> after AMD bought ATI, suddenly litecoin became viable on GPUs <-- hahahahaa
23:41 < warren> https://bitcointalk.org/index.php?topic=337294
23:41 < warren> anything to edit/add?
--- Log closed Mon Nov 18 00:00:00 2013