| 00:00:12 | andytoshi: | catcow: it's a perlscript i found online which does crappy text dumps. then i use python to translate to HTML, and some sh baling wire to publish it every few minutes |
| 00:01:16 | andytoshi: | says for documentation run 'perldoc logger'. it's GPL, (C) 2000-2008 Dave Beckett, http://www.dajobe.org/, (C) 2000-2001 University of Bristol , and has modifications from Ralph Swick (which it came with) and myself |
| 00:03:18 | catcow: | ah okay |
| 00:21:55 | andytoshi: | (it was not supposed to be an 'official' logger, but freenode says that if they aren't private, they have to be in the /topic, so i was sorta forced into it..) |
| 00:29:41 | gwillen: | andytoshi: in my social channel we solve this by making the logs "private" by putting them behind HTTP Basic auth with a well-known password |
| 00:30:05 | gwillen: | (I don't know how many nits freenode would pick with that, but freenode also has nowhere near the resources to care about that) |
| 00:50:23 | amiller: | maaku, you said that ECDSA is trivially malelable |
| 00:50:25 | amiller: | i thought so too, at one point... |
| 00:50:27 | amiller: | i know there's the (r,s) and (r,-s) equal signatures |
| 00:50:29 | amiller: | i thought there was a way you could give someone some auxiliary information, and they could generate arbitrary number of new signatures (for a message you've already signed) without leaking the secret key |
| 00:50:32 | amiller: | but then i tried to show that and didn't come up with anything |
| 00:52:14 | gmaxwell: | amiller: if you have the secret key you can generate endless signatures, however. |
| 00:52:31 | gmaxwell: | though I did point out above how that can be prevented. |
| 00:52:36 | amiller: | yeah but that doesn't change too much, that's what you're supposed to do in his scheme |
| 00:52:50 | gmaxwell: | amiller: then its not progress free, you can grind one then grind the other. |
| 00:53:00 | amiller: | i'm almost certain it's not progress free |
| 00:53:06 | amiller: | not meant to be progress free |
| 00:53:13 | gmaxwell: | you can make it progress free by derandomizing the signature. |
| 00:53:48 | maaku: | amiller: no, they are assuming non-malleable signatures because they are expecting the work unit to go back to the miners if H(sig) isn't <= threshold |
| 00:53:49 | gmaxwell: | e.g. in the coinbase you include the r for the signature you intend to create. You then can't change the r without changing all the hashes. |
| 00:53:58 | amiller: | ohhh |
| 00:54:06 | amiller: | okay then my comments to him are a smattering of confusion. |
| 00:54:09 | gmaxwell: | they don't propose this |
| 00:54:20 | gmaxwell: | but its the trivial and obvious fix that I observed. |
| 00:55:04 | amiller: | that's definitely different than their proposal |
| 00:55:06 | maaku: | amiller: what is written in the blog post is broken, but as gmaxwell points out it is fixable |
| 00:55:13 | amiller: | because a key feature of their proposal is that there's a gradual tuneable parameter |
| 00:55:21 | amiller: | where Y of the effort is spent doing signatures, X of the effort is spent doing hashes... |
| 00:55:34 | amiller: | er hm maybe the idea is that there's still an early abort kind of thing that tunes it that way |
| 00:55:55 | maaku: | amiller: that was my first read as well, but I think he intended that the work be fully done mining SHA256d |
| 00:56:02 | gmaxwell: | yes, you can still early abort but I don't think that harms progress freeness. |
| 00:57:12 | gmaxwell: | the goal of twostaging it is that it lets you use existing hardware. |
| 00:57:23 | phantomcircuit: | amiller, let me help you both, that idiot doesn't even understand what progress free means |
| 00:57:25 | phantomcircuit: | >.> |
| 00:57:26 | phantomcircuit: | <.< |
| 00:57:35 | gmaxwell: | He is not an idiot. |
| 00:57:37 | amiller: | hrm. maybe it's a good idea then |
| 00:57:46 | gmaxwell: | He is an asshole. There is a difference. :) |
| 00:58:01 | phantomcircuit: | gmaxwell, he has an exceptional talent for saying things that sound smart, but which are retarded |
| 00:58:26 | phantomcircuit: | the combo of his "BITCOIN NEEDS A HARD FORK NOW!!!" post with this latest one is a one two pr punch |
| 00:58:51 | gmaxwell: | amiller: It's trivial to bond your way out of misbehavior, so I don't agree that its good. |
| 00:59:04 | amiller: | it could be easily combined with snark |
| 00:59:08 | maaku: | he writes great database software. i'm just not sure how that makes him an authority on consensus systems |
| 00:59:16 | amiller: | i mean, you could take my puzzle and add this two-stage feature and get the benefit of miner-compatibility |
| 00:59:16 | gmaxwell: | phantomcircuit: yes, the approach he uses undermines having a good technical discussion abou it. |
| 00:59:24 | maaku: | amiller: everything can be easily combined with snark ;) |
| 00:59:29 | gwillen: | phantomcircuit: fortunately, if you're talking about hackingdistributed, you can always point to his last paper |
| 00:59:31 | amiller: | maaku, that is NOT the case!!! lol |
| 00:59:40 | gwillen: | phantomcircuit: which made specific predictions about the downfall of bitcoin which didn't happen |
| 00:59:50 | amiller: | maaku, "easy" = O(poly lambda) :p |
| 00:59:54 | phantomcircuit: | gwillen, yup |
| 01:00:19 | maaku: | snark is like bacon. you can add it to anything and improve the result |
| 01:00:23 | gmaxwell: | gwillen: you mean "now is a good time to sell bitcoin" on twitter, shortly before the price increase 5 fold? :) |
| 01:00:32 | gwillen: | my go-to dismissal is to pull that out, followed with a list of exactly what a 50+%er can do (which is not much) |
| 01:00:36 | gwillen: | gmaxwell: hahaha, I didn't even see that |
| 01:00:46 | phantomcircuit: | gmaxwell, hmm... well smart idiot is indistinguishable from malicious smart-ish |
| 01:01:10 | phantomcircuit: | i was giving him the benefit of the doubt |
| 01:01:14 | gwillen: | maaku: it's like bacon under the CRS model |
| 01:01:21 | gwillen: | which is slightly less delicious than general bacon |
| 01:01:48 | gmaxwell: | pretty enormously less delicious in fact. |
| 01:01:50 | gwillen: | (I don't actually know enough enough about snarks to know if the CRS-model issue is a problem with all of them or only some) |
| 01:02:10 | gmaxwell: | just some in theory, but importantly the only currently remotely pratical one. |
| 01:02:11 | amiller: | ugh, damn it's a good idea, i think a two-stage puzzle is even compatible with my non-outsourceable definitions. there's a tradeoff where the harder the puzzle is, the less you'd have to interact with the client |
| 01:02:23 | maaku: | gwillen: just the practical ones :\ |
| 01:02:27 | gwillen: | :-\ |
| 01:02:37 | gmaxwell: | amiller: if you think it's a good idea why didn't you pick it up previously? it's not a new one. |
| 01:03:00 | maaku: | amiller: is it a good idea? all the 2-stage thing seems to do is cause centralization |
| 01:03:00 | amiller: | i never thought about integrating the two-stage thing with the snark approach |
| 01:03:07 | gmaxwell: | In fact NXT actually deployed this, though they missed that ECDSA is trivally rerandomizable and what they initially deployed was quite exploitable. |
| 01:03:20 | gmaxwell: | ah. Why would you integrate it with the snark approach? |
| 01:03:48 | amiller: | so you prevent bonding and get the (arguable) deterrent against hosted mining |
| 01:04:23 | gmaxwell: | (and, incidentally, nxt extensively uses pooling…) |
| 01:04:59 | gmaxwell: | amiller: I mean what does adding the two stage do to your snark alone? |
| 01:05:07 | gmaxwell: | I realize how the snark side is better. |
| 01:05:21 | amiller: | gmaxwell, existing mining investment isn't tossed aside |
| 01:05:24 | gmaxwell: | (also, you'd have to put a signature validation inside your snark) |
| 01:05:31 | amiller: | gmaxwell, you could still use my merkle tree signature |
| 01:05:45 | amiller: | it's deterministic and provably (random oracle lol) requires knowledge of sufficient bits of the private key |
| 01:06:19 | gmaxwell: | the argument as to why this is desirable requires the same private key to be used in the block as the coinbase, so you do have to support txn using the lamport signatures. |
| 01:06:55 | amiller: | gmaxwell, not really |
| 01:07:04 | amiller: | gmaxwell, in my scheme, you have to append a signature at the end of the block |
| 01:07:09 | amiller: | that public key is then your real coinbase |
| 01:07:25 | gmaxwell: | hm? if not then the pool just gives you the private key. |
| 01:07:48 | amiller: | you need to make just one signature with it |
| 01:07:51 | amiller: | and you can have to do it right away |
| 01:07:58 | gmaxwell: | it counts on them being the same so that knoweldge lets you steal the block. |
| 01:08:02 | amiller: | i mean it doesn't matter, equivalently just say that only coinsbases can make lamport signatures, it doesn't really matter |
| 01:08:39 | gmaxwell: | I don't see why your snark thing broke the existing mining power (except for your implementation need to use sha1) in any case, now that we mention it. |
| 01:09:00 | amiller: | each *attempt* requires hashing a big chunk of merkle tree |
| 01:09:15 | amiller: | it's still just sha hashes, but it's a different configuration than what miners already do |
| 01:09:34 | amiller: | i'm assuming miner asics are too rigid to adapt to do merkle branch hashes |
| 01:09:54 | gmaxwell: | refresh me why each attempt requires that? |
| 01:10:59 | amiller: | gmaxwell, because of the "cheap plaintext option" |
| 01:11:13 | amiller: | my final ultiamte power scheme is not just a zero knowledge proof about a preimage |
| 01:12:57 | gmaxwell: | amiller: so why can't your scheme do the unmodified bitcoin blocks like today, but also accept a zkp which only makes public the prev and the fact that you know a new block? |
| 01:13:30 | nairb: | gmaxwell: do you agree with phantom that having another hard fork, ever, even to overcome the 7 tps limit, is highly unlikely? |
| 01:14:24 | gmaxwell: | nairb: another? You can syncup bitcoin 0.2.10 against the network unmodified, or the first release with a minor gateway.. then it's unreliable. |
| 01:14:34 | amiller: | gmaxwell, because then all the "unmodified" blocks are stealable. If you publish an unmodified block, .then *everyone* "knows" a new block |
| 01:15:19 | nairb: | gmaxwell: so there's never been a hard fork? and the 7 tps limit is likely to exist forever? |
| 01:15:35 | andytoshi: | lol amiller, i can't believe i never thought about that |
| 01:15:42 | kazcw: | nairb, there are many possible solutions that don't require a hard fork |
| 01:16:22 | nairb: | kazcw: I haven't heard of any yet that I really liked |
| 01:16:34 | kazcw: | well, there's your problem |
| 01:17:16 | gmaxwell: | nairb: I am quite confident that there will be good solutions to increase scalablity. What exact mixture of them gets used is unclear. |
| 01:20:20 | nairb: | gmaxwell: my thoughts are, even if everyone moved to web wallets so that the vast majority of transactions were off-blockchain, ... and the majority of internet users were using bitcoin... only 100MM users moving money in/out of a web wallet once a month would be 38 tps. Similarly if we had side chains, I'd think I'd want my coin to make it back to the main chain at least somewhat periodically... what options are there, even in c |
| 01:20:20 | nairb: | ombination, that could potentially scale to real wide-spread heavy usage? |
| 01:20:52 | gmaxwell: | nairb: just increasing the block size is not a free move, it might make reasonable sense for some level of increase at some particular point in time, but it requires a thoughtful tradeoff with decenteralization. We're having a hard time keeping the network decenteralized at the current scale. |
| 01:21:24 | gmaxwell: | nairb: yea, okay, if the target is 38 tps or whatever thats probably reasonable without a horiffic decenteralization tradeoff. |
| 01:22:05 | nairb: | gmaxwell: well, my 38 figure was assuming everyone used web wallets, and I was using a number of users that's still well below the number of twitter/facebook/whatsapp etc users |
| 01:22:34 | nairb: | gmaxwell: I mean I understand things like web wallets would help, that sidechains could help.... but 20 years from now, I don't see how a limit of only 7 on the main chain would be tenable. |
| 01:23:04 | moneycat: | gmaxwell how do you have enough time and patience to answer questions in here what seems to be 24/7 :p |
| 01:23:04 | nairb: | gmaxwell: but, even if "38 tps or whatever is probably reasonable," ... if we're highly unlikely to ever have a hard fork.... how do we get there? |
| 01:23:38 | andytoshi: | nairb: anything you can do in a hardfork you can do with a sidechain |
| 01:23:52 | gmaxwell: | nairb: I dunno why you're putting words into my mouth there... |
| 01:23:57 | nairb: | gmaxwell: I'm assuming if the change did get made, it would be something where the tps increased every so many blocks or something |
| 01:24:07 | gmaxwell: | (but as andytoshi said, there isn't really a hardfork requirement there in any case) |
| 01:24:46 | nairb: | gmaxwell: sorry, not trying to put words in your mouth, phantom had said earlier in #bitcoin and everyone seemed to agree with me that a hard fork would likely never happen... and you seemed to be agreeing a bit ago when I first asked here. |
| 01:24:57 | gmaxwell: | nairb: no, I wasn't trying to agree. |
| 01:25:13 | gmaxwell: | I think a controversial hard fork will never happen, but a no brainer one would as required. |
| 01:26:09 | nairb: | gmaxwell: I know sidechains in theory could solve the problem.... but I feel like I'd still rather have my coin on the main line than one of potentially hundreds of sidechains with different levels of merge-mining happening on each... and if many think the same way as me, we won't all be able to move our coin back to the main line whenever we want, because we'd exceed the 7 tps |
| 01:27:41 | gmaxwell: | nairb: You can always soft-fork bitcoin to require a sidechain... which then gives the same security properties as the hardfork. |
| 01:27:45 | nairb: | gmaxwell: people keep saying "we're not even at 1 tps," but I"m kinda thinking longer term than just like next year or whatever... wondering how this works out in the end. a few years from now it might be really difficult to coordinate a hard fork even if really really necessary for something like being unable to handle transaction volume any more |
| 01:27:47 | gmaxwell: | But it has a better introduction model. |
| 01:28:12 | nairb: | gmaxwell: so then the side chain essentially becomes the main line and everyone uses it? |
| 01:28:25 | andytoshi: | nairb: in the next 5 years it is not unthinkable that we could actually prove transactions in zero-knowledge. then you can jack up the tx rate without needing bigger blocks |
| 01:28:30 | kazcw: | nairb: we don't need immediate solutions to long-term problems |
| 01:29:33 | nairb: | andytoshi: not sure what you mean.... if the tx never gets added to the blockchain, how do you stop someone from double spending? |
| 01:30:10 | andytoshi: | nairb: you maintain a data structure which describes which coins are spendable (and how, if your system is complex enough to support some sort of script) |
| 01:30:56 | andytoshi: | nairb: and you can have such data structures where everyone only needs to explicitly store the parts that contain their own coins. check out the logs here for the last 48 hours |
| 01:32:54 | nairb: | andytoshi: i don't see how that helps me verify that a coin I'm receiving hasn't already been spent? |
| 01:33:14 | kazcw: | nairb: you don't need to verify it; you just need to verify that it has been verified |
| 01:33:26 | kazcw: | that's where the zkp comes in |
| 01:33:52 | nairb: | that it has been verified? verified by who? |
| 01:33:58 | gwillen: | I admit I'm also curious about the details... how many hours ago was this discussed, roughly, in the logs? |
| 01:34:49 | andytoshi: | gwillen: what was discussed over the last couple days are just data structures to reduce storage requirements for all parties.. i don't know when last the zkp stuff was discussed |
| 01:34:56 | gwillen: | ahh, *nod* |
| 01:34:58 | andytoshi: | nairb: verified by miners, who would have to do the hard work of producing a proof |
| 01:35:54 | gwillen: | ohh, I se |
| 01:35:56 | gwillen: | see* |
| 01:36:04 | gwillen: | it still gets verified, but that doesn't take up space in the block |
| 01:36:19 | gwillen: | because it gets hashed into something, or something, in a way that someone can prove later, without needing to have it written out |
| 01:36:20 | nairb: | andytoshi: do you have a link on this? just because a miner "verifies" that I haven't spent it (against what??), I still don't see what prevents me from double spending it |
| 01:37:18 | andytoshi: | nairb: verifies against the list of unspent coins. you can't double-spend it because after the first time the coins wouldn't be in the list anymore |
| 01:37:47 | gwillen: | oh interesting |
| 01:37:52 | andytoshi: | nairb: what the miner provides is a zk proof that he updated the list of unspent coins faithfully |
| 01:38:03 | gwillen: | so the list itself goes in the blocks? |
| 01:38:22 | gwillen: | (I remember something like this being described as "inverting the blockchain", IIRC?) |
| 01:38:53 | nairb: | andytoshi: that sounds like the miner maintaining an offline blockchain |
| 01:40:08 | andytoshi: | nairb: that is not required |
| 01:40:40 | andytoshi: | nairb: i'll try to do a writeup about this in the next few days, it's by far the most exciting -wizards story i tell.. |
| 01:43:02 | nairb: | andytoshi: cool, i'd be very interested to see |
| 02:00:52 | vfor: | can we have an altcoin which calculates bitcoin priv keys as POW? |
| 02:01:00 | vfor: | :D |
| 02:02:16 | vfor: | as a side chain would be neat |
| 02:03:19 | nairb: | vfor: "calculate" ? |
| 02:04:12 | vfor: | changing zeros and ones |
| 02:04:36 | nairb: | does the private key have to be associated with a non-zero balance to count as "work"? |
| 02:04:39 | nairb: | if not, that's easy :-P |
| 02:05:00 | nairb: | if so, it costs a satoshi and a transaction fee :-P |
| 02:05:05 | vfor: | the higher the balance, the higher the reward of course :D |
| 02:05:10 | nairb: | heh |
| 02:09:36 | andytoshi: | vfor: something vaguely like this does actually occur on https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas as 'timelock encryption' |
| 02:14:49 | vfor: | timelocking messages in the blockchain? POW consists of brute-forcing them? |
| 02:15:30 | vfor: | this could also work as a reward for people who find security wholes in random number generators |
| 02:15:59 | vfor: | holes |
| 02:16:00 | andytoshi: | well, actually breaking the cryptosystems would be totally not progress-free.. |
| 02:16:26 | vfor: | what is not progress-free? |
| 02:16:30 | andytoshi: | but just inverting hashes or key-derivation functions could possibly be made so |
| 02:17:15 | andytoshi: | vfor: https://download.wpsoftware.net/bitcoin/asic-faq.pdf q2.5 explains what progress-freeness is |
| 02:17:32 | andytoshi: | basically, a miner who just shows up has no advantage over a miner who's been going for a long time |
| 02:17:52 | andytoshi: | that way it's not "the fastest guy always gets the block", the blocks are distributed according to hashpower |
| 02:22:01 | vfor: | yep |
| 02:22:48 | vfor: | gmaxwell: why did you not do an altcoin yet? so many ideas... |
| 02:23:30 | phantomcircuit: | he's too busy writing slow video decoders for firefox |
| 02:23:31 | phantomcircuit: | :P |
| 02:23:51 | vfor: | [maybe somebody gave i a bunch of bitcoins not to do so :D] |
| 02:24:01 | amiller: | hey half the ideas on there (well some, i dont' know how many) are collections of other people's ideas |
| 02:24:05 | amiller: | mostly well cited |
| 02:24:13 | amiller: | same question stands for all of us though |
| 02:24:45 | amiller: | the answer "why not an altcoin" in my opinion has to do with something along the lines of respect for the risk taken on by early bitcoin adopters and miners |
| 02:25:39 | vfor: | eternal respect for participating…? |
| 02:25:42 | amiller: | and a belief that stability is good, unless there's a really good reason against it |
| 02:25:48 | amiller: | it's not eternal and it's not unconditinoal |
| 02:26:28 | amiller: | they overstep the line (an uncertain line) of good behavior, or fail to support an important update or something like that, and to hell with their value.. we'll start over again |
| 02:26:31 | vfor: | bitcoin got boring. bigger and bigger corporations are moving into it |
| 02:26:54 | amiller: | and do the same thing to "wealthy in bitcoin" folks that we've done to "wealthy in USD" folks.... stop believing in them! |
| 02:27:43 | vfor: | hmmm i like |
| 02:28:16 | vfor: | i bet there is no decentralized consensus on that line |
| 02:28:44 | amiller: | i have no idea what you mean by that, but, sure, maybe not |
| 02:29:22 | vfor: | it was a joke |
| 02:30:22 | amiller: | oh, i get it now then :) |
| 02:30:53 | vfor: | so why not have a bettter coin and leave bitcoin stabilize on this current level? early adopters should be happy enough |
| 02:31:57 | amiller: | an altcoin takes a lot of marketing |
| 02:32:03 | amiller: | i'm on the verge of thinking it's a good idea though |
| 02:32:22 | amiller: | i'm afraid of finding myself in a position where i'm hesistant to explain why i think an idea sucks, because i've already invested too hard in a particular idea |
| 02:32:45 | Armstrong: | Armstrong is now known as diablito |
| 02:33:21 | amiller: | i'm increasingly fond of research and academia because i get to maintain this buddhistic "detachment" and can change my mind as often as i please |
| 02:33:28 | amiller: | maybe you can get that elsewhere |
| 02:35:35 | vfor: | for marketing: i have met the guy who did the PR for maidsafe, mastercoin, kryptokit… it is not too difficult to create the initial buzz. to build the community is a longer process. i have followed the process with ethereum |
| 02:35:40 | andytoshi: | amiller: there is a big appreciation of buddhism in the programming world for the reasons you cite, e.g. 'the tao of programming' |
| 02:36:27 | amiller: | there's a saying in mdoern security engineering, "don't roll your own crypto" |
| 02:36:55 | amiller: | there's a similar saying in bitcoin.... "in cryptography we trust" or "in math we trust" or in latin "vertias numeris" or something to that efect |
| 02:37:08 | NikolaiToryzin: | vfor, Mind spoiling his secrets? We've got the community, a good buzz, but the buzz isn't enough. Distributed application |
| 02:37:09 | vfor: | vires in numeris |
| 02:38:07 | amiller: | the significance of that is that there's some value in mathematics and formalism... it's a good (but expensive) way of avoiding a lot of common pitfalls... the math behind bitcoin isn't just about cryptography, it's also about incentive mechanisms, which are things we are barely beginning to understand |
| 02:38:27 | vfor: | i do not know any secrets. but i am sure you can find out who it is and hire him to do a press release :D |
| 02:38:56 | amiller: | vfor, uh, fascinating to hear it's the same person who did all of that |
| 02:39:28 | lechuga_: | so when is ethereum going to be released? :) |
| 02:39:38 | vfor: | in two weeks |
| 02:39:40 | lechuga_: | nice |
| 02:39:57 | amiller: | so i'm vaguely pissed at maidsafe, ethereum, ripple inc..... actually basically everything, that i perceive as not making any effort to provide formalizable security guarantees |
| 02:40:06 | lechuga_: | i wonder if that's part of the reason why gavin decided it was time to open up the rest of the op codes |
| 02:41:06 | NikolaiToryzin: | amiller, What do you mean? |
| 02:41:07 | mappum: | are they opening the other opcodes? or just nonstandard txs? |
| 02:41:10 | andytoshi: | lechuga_: vfor is being facetious, ethereum is always going to be released "soon" even though they constantly change what they're planning |
| 02:41:15 | andytoshi: | mappum: just the standard rules |
| 02:41:27 | amiller: | there was a big dark age of cryptography, both before cryptography became a science at the end of WWII, and afterwards when there weren't a lot of practical schemes you could subject to the mathematics, where basically everyone and their brother had an ad hoc "cipher" and the best you could say about it is "here's a ciphertext, bet you can't crack it!" and for the most part no one cared enough to bother, even though the schemes are |
| 02:41:27 | amiller: | all flawed |
| 02:41:35 | mappum: | and only p2sh, right? why is that? |
| 02:41:35 | vfor: | 'two weeks' was a joke as well… for all who know BFL and MtGox :D |
| 02:41:50 | amiller: | the same thing is basically happening now with the trial and error approach to inventing an altcoin and marketing it and after all that finding out if it's secure! |
| 02:42:19 | andytoshi: | amiller: i agree with everything you're saying but my feeling is that you can find more freedom outside of academia.. |
| 02:42:28 | NikolaiToryzin: | amiller, I like where you're going with this |
| 02:42:40 | lechuga_: | vofr: g1 |
| 02:42:46 | lechuga_: | s/vofr/vfor |
| 02:42:50 | andytoshi: | well, you can find more money anyway, then you can research in your spare time |
| 02:43:21 | NikolaiToryzin: | NikolaiToryzin is now known as stqism |
| 02:43:27 | lechuga_: | mappum: there's no impact to UTXO set size if it's p2sh only |
| 02:43:40 | mappum: | ah, i see |
| 02:44:00 | lechuga_: | and yes |
| 02:44:45 | stqism: | stqism is now known as NikolaiToryzin |
| 02:48:04 | amiller: | well, it's a lot of effort, possibly misplaced, but my hunch is not... no one else does definitions and proofs outside academia and corporo-academic research joints, the return on investment isn't high enough (or apparent in the slightest) |
| 02:49:25 | amiller: | it's *marginally* easier to argue over a specification than over a whole program. if there's a practical advantage to math, then that's it |
| 02:49:28 | andytoshi: | hmm. i do a lot of definitions and proofs but it's not at all related to my academic "work"...right now for example i am screwing around with some ramsey theory hypotheses with some old profs at SFU |
| 02:49:36 | andytoshi: | yeah, i love mathematics for these reasons |
| 02:49:52 | andytoshi: | it just seems like i get more mathematics done when i'm ignoring school than when i'm not |
| 02:50:26 | lechuga_: | i wish i were better with the maths but my tiny brain can barely contain all the programming esoterica stuffed in it already |
| 03:17:45 | zooko: | vfor: who's the guy who did PR for maidsafe, mastercoin, kryptokit? |
| 03:20:36 | vfor: | i have his card somewhere… |
| 03:22:27 | Luke-Jr: | zooko: was it ripper234? |
| 03:22:49 | zooko: | Luke-Jr: I don't know. |
| 03:49:04 | pigeons: | yeah ripper234 is ron gross |
| 03:56:43 | zooko: | Thanks. |
| 05:04:38 | shesek: | zooko, I don't think he did the PR himself |
| 05:06:39 | maaku: | amiller: bah, "why not an altcoin" has more to do with the fact that this is all a house of cards |
| 05:06:56 | maaku: | if something of the same economic model replaces bitcoin, then how long until something replaces that thing? |
| 05:07:22 | maaku: | since bitcoin has no intrinsic value, all value is in the standardization of bitcoin as the unit of digital scarcity |
| 05:07:34 | maaku: | destroy bitcoin and you destroy all alts as well |
| 05:09:19 | gmaxwell: | ^ this is generally my view. It's also my view that we cannot afford to split our limited network effect, it's hard enough to use this stuff already without a confusion of trying to value and handle a dozen different kinds of subtly different currency assets. |
| 05:10:10 | gmaxwell: | Beyond that— most of the alt ideas (including ones I think are interesting) are fairly half baked, the serious research needed to make them understood to the point that we could really say confidently that they're an improvement hasn't happened, and may not be justified. |
| 05:10:51 | gmaxwell: | Bitcoin itself is sort of the simplest viable thing in its space, and already it challanges the publics' engineering ability, much less analysis ability. |
| 05:12:05 | gmaxwell: | I (re)invented the sidechain idea space because I want people to be able to expirement and innovate with transaction processing technology without completely disrupting our network-effect progress every time a new technology comes along. |
| 05:13:56 | gmaxwell: | maybe there is a stronger argument for new currencies if you're going to talk about things with wildly different economic properties... but almost none of the altcoins do that, they just do something that is almost just like bitcoin with some thing tweaked and same kind of geometric distribution (if not just handing most/all the coins to the system's creators)... boring. |
| 05:16:23 | gmaxwell: | someone is on the fence about accepting bitcoin and then there is litecoin and dogecoin and feathercoin and fantomcoin and ripple and ... and they all have wildly varring exchange rates, incompatible software, skechy exchange services run by anonymous people or out of random tax havens. Even today people do rightfully say, "this stuff sounds interesting, but I'm not qualified to pick winners here— I think I'll sit this out until ... |
| 05:16:29 | gmaxwell: | ... someone I trust tells me what I'm not going to get stuck with." |
| 05:17:26 | gmaxwell: | And so in a world where anyone can just copy and start a new thing, they don't even have to know how to program, they can promote their stuff with dishonest marketing hype, etc.. it may well be that being _first_ is the only persistant advantage. |
| 05:19:23 | gmaxwell: | And I couldn't care less about which decenteralized digital currency wins, what matters to me is that what we get is stable enough and widely used enough that all the trustless possibilities it makes possible are pratically useful to ordinary people... and I think pumping out altcoins mostly harms that probablity of success, with the benefit of enriching a few people around them— mostly currency speculators (you can see how fast ... |
| 05:19:29 | gmaxwell: | ... BCN was forked off and how fast the forks were forked). |
| 05:21:06 | gmaxwell: | people have already commited to forking off ethereum and replacing it with a version where the initial coins are owned buy the current holders of bitcoins. |
| 05:22:43 | shesek: | if they're using a different way of representing pubkeys (unhashed or hashed differently), how would you do that for addresses that were never spent from? |
| 05:24:29 | gmaxwell: | shesek: if you're making a fork you can change the code freely, so there would be no reason to not support regular 1-type hash160s... even just as a special case. |
| 05:26:13 | gmaxwell: | (I don't think that doing so is meaninglyfully different from other altcoins— but it may be powerful marketing, e.g. giving yourself a large base of users who already have your coins.. otoh they're consider those coins as almost worthless...) |
| 05:26:18 | shesek: | right, of course. not sure how I didn't think about that... nvm me |
| 05:27:00 | shesek: | many of them are probably going to dump them on exchanges the moment they have some value... making the value crash |
| 05:28:13 | gmaxwell: | yea, that looked to be the case with nmc merged mining... but it did stabalize eventually. |
| 05:31:27 | shesek: | I think that most pools still sell them for BTC immediately and distribute profits to miners only in BTC, don't they? |
| 05:32:01 | Apocalyptic: | eligius doesn't |
| 06:01:50 | gwillen: | gmaxwell: I can see a few stable endgames for altcoins |
| 06:02:09 | gwillen: | one is that someone writes multi-coin client code, and we end up with a meta-coin standard or standards |
| 06:02:54 | gwillen: | and then there's a bazillion coins, most of which are ignored, but a few of which are used in applications for which they have features that make them more suitable than bitcoin |
| 06:03:10 | gwillen: | and those ones get some actual value, and are traded seamlessly behind the scenes against bitcoin as needed |
| 06:04:12 | gmaxwell: | perhaps, but if the features aren't economically significant they're probably not stable attractors. e.g. you can add coin X's magic feature to coin Y. |
| 06:04:51 | gmaxwell: | I'm not aware of any that should be significant to users that are mutually exclusive, though I suppose it's possible (esp since the absense of a feature can be a feature) |
| 06:05:52 | gwillen: | yeah, that's true |
| 06:05:58 | gwillen: | you get interesting results in the presence of open source |
| 06:06:02 | gwillen: | where any coin can clone any other coin |
| 06:06:29 | gwillen: | I suspect / wonder if we'll end up in a situation where it becomes the norm for a new coin to clone the coin distribution from another coin / from bitcoin |
| 06:06:43 | gwillen: | rather than starting from zero with mining |
| 06:06:56 | gwillen: | (and that any coin that doesn't do this will be called 'premined' or some new slur) |
| 06:08:30 | gmaxwell: | Hm. I'm doubtful... at least my mental model for creating an altcoin has short term profit motives elevated pretty highly, and the expirence with NMC suggests to me that that kind of thing will not be very short term profit conducive. |
| 06:08:58 | gwillen: | well, right... but premining is very short-term-profit conducive, but the community has developed a reaction against it |
| 06:09:19 | gwillen: | (how effective the reaction is, I'm not clear on, but it seems pretty strong.) |
| 06:09:29 | gmaxwell: | okay, fair, it might be protective against the "got instantly forked" effect. |
| 06:09:35 | gwillen: | * gwillen nods |
| 06:10:08 | gwillen: | the next step from instant manual forking is clearly automatic forking |
| 06:12:02 | sl01: | realistically do you think sidechains will quell the altcoin madness? |
| 06:12:18 | gmaxwell: | hard to say. |
| 06:12:41 | sl01: | i mean more technically, are they going to work? |
| 06:12:43 | gmaxwell: | I mean a lot of the altcoin madness is because its easy has has some random prospect of omg uberprofit. |
| 06:13:06 | gmaxwell: | oh sure, I'm completely confident that it'll work for some defintion of work that may be more or less useful for some applications. |
| 06:13:27 | sl01: | gmaxwell: yes but they must generally start with some legitimate-ish argument for why what theyre doing is good, sidechains an take that away |
| 06:13:38 | gmaxwell: | Maybe we discover without the prospect of a lottery windfall no one really cares about innovation in this space. |
| 06:13:56 | gwillen: | I think it will winnow it a lot |
| 06:14:10 | gwillen: | but I don't think it will stop |
| 06:14:15 | gmaxwell: | e.g. the technology claims are probably pretext in some cases, and sidechains will diminish the pretext. |
| 06:14:26 | gwillen: | right |
| 06:14:54 | sl01: | yea I think that will go a long way to reducing the general crappiness of the ecosystem |
| 06:15:08 | gmaxwell: | but they'll market on claimed— even if untrue— advantages over sidechains.. perhaps sidechains never get widely adopted due to well funded marketing attacks by people planning to profit on altcoins, who knows? |
| 06:15:13 | sl01: | so why are you so pessimistic? :P since a/your solution is on the horizon |
| 06:15:25 | gwillen: | I don't feel like 'well funded' marketing attacks are likely |
| 06:15:32 | gwillen: | I suspect the average altcoin is not well-funded |
| 06:15:37 | gwillen: | and probably doesn't yield much |
| 06:15:42 | gmaxwell: | I am cynical, less than pessimistic. |
| 06:15:48 | gmaxwell: | But also hopeful. |
| 06:15:52 | sl01: | yea I think people aren't quite as stupid as you think they are |
| 06:15:54 | gwillen: | it's probably a lot easier to put together a trojan altcoin than an actual one |
| 06:15:56 | gwillen: | and a lot more profitable |
| 06:16:34 | gmaxwell: | well I think that people are not so stupid, but they have finite time and attention. It only takes moderate funding to create FUD that is 10x more costly to counter. |
| 06:16:43 | sl01: | when the new alts devolve into much more obvious pump n dump much fewer ppl will get invovled |
| 06:17:14 | gmaxwell: | yea, indeed, one of the reasons that I think sidechains are important is that I believe altcoin-model is a throughly non-sustainable funding model. |
| 06:18:02 | sl01: | yea... i personally think alts will go away by themselves eventually, sidechains will just speed it up |
| 06:18:10 | gmaxwell: | eventually people will wise up and become jaded and even interesting development won't be used. (this is the corollary to the above 'if one replaces bitcoin then what will replace it'— it applies even if no altcoin replaces bitcoin, just each other) |
| 06:18:13 | sl01: | the market just takes a long time to act sometimes |
| 06:18:39 | gmaxwell: | I think there is a real prospect of ltc being replaced, for example... by something that does something more clearly of value than being not-bitcoin. |
| 06:18:48 | gmaxwell: | (I mean in the near term) |
| 06:18:50 | sl01: | right |
| 06:19:10 | gwillen: | gmaxwell: I feel like dogecoin has already replaced litecoin |
| 06:19:14 | gwillen: | with the main value being 'doge' |
| 06:19:26 | Apocalyptic: | ... |
| 06:19:27 | gmaxwell: | right. |
| 06:19:53 | gwillen: | apparently dogecoin's market cap is down though, huh |
| 06:19:56 | gwillen: | ltc still #2 |
| 06:22:00 | gwillen: | bitcoin's market cap still 92.4% of the total market cap of all cryptocurrency |
| 06:22:15 | gwillen: | honestly I was expecting altcoins to do better than they ultimately did, as an asset class |
| 06:22:28 | gwillen: | I think it's going to take actual innovation for any of them to get real value |
| 06:25:46 | gmaxwell: | careful with market caps, they're not all terribly liquid. :) |
| 06:39:17 | gwillen: | gmaxwell: that just means they're lower than they look |
| 06:39:19 | gwillen: | and they already look pretty low |
| 07:28:17 | nkuttler_: | nkuttler_ is now known as nkuttler |
| 09:02:47 | dsnrk: | did anybody ever archive a copy of the "cryptonote" website? I never got to see it but the links to it from the wiki are all dead. |
| 09:03:21 | dsnrk: | the hidden service one, not the .org one |
| 10:07:25 | adam3us: | does anyone have a link to gmaxwell's QR code with embedded photo thing? (visual watermark that is still QR scanable) |
| 10:12:31 | dsnrk: | adam3us: the chinese one? |
| 10:12:59 | adam3us: | dsnrk: he had like a photo of his face that was low res visible in the QR code, but still scanned as a btc address |
| 10:13:24 | dsnrk: | it's somewhere in my bookmarks, I'll gid it out |
| 10:13:29 | dsnrk: | *dig |
| 10:13:32 | adam3us: | dsnrk: thank you thank you |
| 10:13:58 | dsnrk: | I would run the executable in a VM though. |
| 10:16:42 | dsnrk: | adam3us: http://cgv.cs.nthu.edu.tw/Projects/Recreational_Graphics/Halftone_QRCodes/ |
| 10:17:02 | dsnrk: | taiwanese not chinese, but close enough. |
| 10:17:29 | dsnrk: | is that what you where looking for? |
| 10:49:55 | Emcy: | dat error correction |
| 13:11:58 | dsnrk: | https://pay.reddit.com/r/Bitcoin/comments/28jp0y/why_is_peter_todd_wrecking_zeroconf_security/ |
| 13:12:02 | dsnrk: | :C |
| 13:18:10 | epscy: | hah Big Bitcoin |
| 13:18:18 | epscy: | that's a new one on me |
| 13:18:22 | epscy: | only took 5 years |
| 13:18:32 | zooko: | Heh heh. |
| 13:19:16 | hearn: | pay.reddit.com? |
| 13:21:36 | hearn: | hm, new account. i wonder who alicebtcmayes is |
| 13:23:23 | hearn: | and yeah "big bitcoin" is pretty funny. |
| 13:25:37 | dsnrk: | hearn: it's their SSL domain. reddit only supports ssl with a hack. |
| 13:25:44 | helo_: | helo_ is now known as helo |
| 13:25:58 | dsnrk: | (well, not a hack, just rewriting everything to their payment gateway's domain which does have ssl) |
| 13:28:08 | nsh: | cheapskate condë naste tbh |
| 13:28:13 | nsh: | *nast |
| 13:28:44 | hearn: | haha, that's weird |
| 13:28:57 | hearn: | someone needs to tell them that SSL got a lot cheaper in the past few years |
| 13:30:00 | nsh: | they seem very begrudging to spend any more than the minimum money on reddit, despite it arguably making them more relevant than most of their print publications combined |
| 13:30:24 | hearn: | it doesn't seem to have much advertising, at least not in the bitcoin area. perhaps it's not really that profitable |
| 13:30:32 | Emcy: | >he pays for reddit |
| 13:30:44 | dsnrk: | I don't. it's just the SSL domain. |
| 13:30:53 | Emcy: | odd |
| 13:30:55 | dsnrk: | hearn: last I heard they were pulling a loss. |
| 13:31:28 | hearn: | not a surprise. i noticed that slashdot stopped respecting the "don't show me ads" checkbox |
| 13:31:58 | Emcy: | donottrack? that was stillborn anyway |
| 13:32:15 | hearn: | no, slashdot for a long time has had a feature where if you comment and get high scores a lot, they consider you a contributor to the site and let you disable ads |
| 13:32:26 | Emcy: | oh |
| 13:32:33 | hearn: | it's still there, except now it only disables some of them, not all of them |
| 13:32:36 | Emcy: | well how about "ha ha time for adblock" |
| 13:32:43 | hearn: | nah, i'm not going to freeload |
| 13:32:57 | dsnrk: | even for youtube? |
| 13:33:01 | Emcy: | youre not, youre a contributor |
| 13:33:15 | dsnrk: | youtube is unusable without blocking their preroll advertising. |
| 13:33:29 | hearn: | i have never used any kind of adblocker. i use youtube, it works ok |
| 13:33:37 | hearn: | all the ads i'm shown are skippable after 5 seconds |
| 13:33:41 | Emcy: | i adblock except plenty of sites that i find useful and who are not dicks about it |
| 13:34:08 | Emcy: | hearn its about tracking and stuff too |
| 13:34:14 | hearn: | the web is an expensive thing to run. i figure not messing with ads is the least i can do. |
| 13:35:12 | hearn: | i don't care much about being "tracked", i find that terminology over-dramatic. somewhere there's a long random number associated with some vector of statistics about what sort of ads i've loaded, that are fed into an ML model which exists to ensure i see ads for video games instead of baby products |
| 13:35:27 | Emcy: | i figure helping speed the death of intrusive ass targetted advertising (which the likes of the NSA are freeriding on for their own purposes) as the main means of funding the web, to be replaced with ???, is the least i can do |
| 13:35:28 | hearn: | i can change my number at any time and they don't know who sits behind it |
| 13:35:35 | hearn: | so .... ultimately, there are scarier things to worry about |
| 13:35:46 | hearn: | well exactly. the ??? is the big problem |
| 13:35:54 | Emcy: | not my problem |
| 13:35:56 | hearn: | 1. Throw away existing business model |
| 13:35:57 | hearn: | 2. ??? |
| 13:35:58 | hearn: | 3. Profit! |
| 13:36:26 | Emcy: | i use flattr, does that redeem me |
| 13:36:29 | hearn: | well, it's your problem if there's no ??? to be found. then the web gets suckier. reddit announces it's being shut down because it's not profitable, etc. |
| 13:37:16 | Emcy: | hearn i dont beleive the only value people can find in stuff on the internet is if its commercially driven |
| 13:37:20 | hearn: | i used to think maybe there was some solution like micropayments or whatever, that if only we could move money around efficiently enough, the web wouldn't need advertising any more |
| 13:37:33 | Emcy: | perhaps i long for the days of geocities and shit, idk |
| 13:37:52 | hearn: | then one day i saw an internal google report on how much advertisers had paid to show me ads around the web, *just* on google's own ad network. which is not even most ads on the web by far. |
| 13:38:02 | dsnrk: | hearn: looking at the donate addresses in various open source bitcoin software, I don't think that really works too much. |
| 13:38:18 | hearn: | and it was huge. like $20-$30 per month huge. if i had been able to pay all ad networks to show me no ads, i'd probably have been looking at ~$100 per month |
| 13:38:47 | Emcy: | ads must be overvalued then |
| 13:38:52 | dsnrk: | you must use an awful number of free services, hearn. |
| 13:39:02 | hearn: | i don't believe most people are going to pay that much to not see ads. it's just not going to happen. i still want to see ways to set the scale, so i could pay to see *fewer* ads, and then maybe as technology gets better and the web gets cheaper to run the number of ads will slowly decline. |
| 13:39:06 | Emcy: | or people really do buy a lot of shit based on being told to by the computer, i certainly dont |
| 13:39:07 | hearn: | but it's not a full solution |
| 13:39:12 | hearn: | nope, i just browse the web like a regular guy |
| 13:39:21 | hearn: | people just underestimate how much advertisers pay for things |
| 13:39:26 | hearn: | yep, they really do |
| 13:39:33 | Emcy: | welp |
| 13:39:34 | hearn: | or at least advertisers think they do. and i doubt they're all stupid. |
| 13:39:55 | dsnrk: | having been a person with some very popular youtube videos, I can assure you youtube advertising isn't really that profitable for the publisher. |
| 13:40:09 | Emcy: | its a shame webgl miners couldnt stay a thing forever |
| 13:40:18 | Emcy: | that might hav ekilled google dead |
| 13:40:32 | hearn: | yes, it depends a lot on content, time and place. some types of content monetise with ads better than others. |
| 13:40:36 | hearn: | that's one reason there's a lot of advertising .... |
| 13:40:40 | Emcy: | (google as an example, not particular beef) |
| 13:40:51 | hearn: | one individual ad doesn't make much. unless you are a search engine and can put text ads next to commercial queries. |
| 13:41:14 | dsnrk: | as an odd comparison most of the services I use don't have advertising and have never had advertising. |
| 13:41:22 | hearn: | effectively ads *are* micropayments, except between advertiser and publisher. |
| 13:41:55 | hearn: | lucky you! |
| 13:42:10 | hearn: | i read a lot of news. news doesn't monetise well, and journalism is expensive, so they end up needing a lot of advertising |
| 13:42:13 | hearn: | and still often make a loss |
| 13:42:28 | dsnrk: | not lucky so much, just pointing out that the whole internet isn't advertising |
| 13:42:40 | Emcy: | well, as we know free services are anything but |
| 13:42:42 | dsnrk: | the best communities I've been a part of have no advertising at all. |
| 13:43:01 | Emcy: | the price has been higher than simple monetary cost, but more abstract |
| 13:43:40 | hearn: | * hearn shrug |
| 13:43:45 | Emcy: | and people have in their millions paid the cost without even knowing it, pretty shady |
| 13:43:51 | hearn: | monetary cost is pretty damn non-abstract. hence the lack of for-pay youtube killers. |
| 13:43:59 | hearn: | people value "free" very highly indeed, vs being shown adverts |
| 13:44:00 | epscy: | i really like the guardian android app, content aside it's really slick, but apparently they are losing £40 million a year |
| 13:44:22 | hearn: | epscy: guardian has always been funded by other businesses. it's never been run for a profit. mostly they're subsidised by Auto Trader magazine, iirc |
| 13:44:37 | Emcy: | meanwhile at the daily mail........ |
| 13:44:50 | epscy: | hearn: it's not a good state of affairs though is it? |
| 13:45:11 | Emcy: | turns out relentless bigotry against absolutely everything sells like water in the desert |
| 13:45:37 | hearn: | daily mail is a force of nature. it has international readership, quite unusual. |
| 13:45:44 | dsnrk: | email addresses are a worse loss to the modern internet. everybody feels they are allowed to sign me up for "newsletters". to me at least email is no longer personal, it's a place for advertisers to take a dump in the hope of profit. |
| 13:45:48 | hearn: | most people read it for the gossip, i think, rather than the bigotry ...... at least i hope so :) |
| 13:45:57 | hearn: | dsnrk: report them as spam |
| 13:46:02 | Emcy: | theres no real difference |
| 13:46:03 | hearn: | that's what keeps them in check. |
| 13:46:41 | hearn: | epscy: no. the question of how to make news pay has vexed people for years. a big chunk of google's story in the last 10 years or so can be traced back to a cold war between newspapers and google news. |
| 13:46:43 | dsnrk: | hearn: I use unique email addresses for services. you'll never guess who sells my details to spammers. |
| 13:46:51 | Emcy: | theyve got the sidebar of shame, and the rest of it is a daily dose of confirmation of every bone headed belief and prejudice every pub thicko in the land has ever had |
| 13:47:19 | Emcy: | people really like being told everything they beleive is true and correct on a daily basis, they will pay for it |
| 13:47:27 | hearn: | dsnrk: ok that's different. what i meant was, if a company is too aggressive about sending you newsletters and stuff, just report their newsletters as spam. lots of people do it and when the companies complain to say their deliverability has gone down, they get told "people don't want your mail and we have data to prove it". then they usually wise up. |
| 13:48:12 | hearn: | Emcy: well DM has a circulation of 2-3 million i think, but online readership of 100 million. although that's comparing daily vs monthly so it's distorted, still, most DM readers don't pay |
| 13:48:42 | Emcy: | true |
| 13:48:44 | dsnrk: | hearn: I don't use a central mail service so there's nowhere really to report them to. it's also pretty hard to tell people like my cell company to stop selling my email address to other people. |
| 13:49:02 | epscy: | hearn: the online site isn't exactly the same as the paper, they even have a different editor and online publishes stuff the paper wouldn't |
| 13:49:09 | epscy: | not that i am a fan of either |
| 13:49:10 | Emcy: | last i heard they pull like 500mmpa on ad revenue etc worldwide |
| 13:49:22 | Emcy: | seems obscene tbh |
| 13:49:41 | hearn: | dsnrk: yes in that case you can't do much. you just have to hope the bigger fish force them to change. it does happen, i saw it many times when i worked anti-spam at gmail |
| 13:49:55 | Emcy: | how many fucking geriatric prodcuts does the DM really help sell |
| 13:50:06 | hearn: | http://www.theguardian.com/media/2013/nov/21/dmgt-print-ad-daily-mail-online |
| 13:50:23 | hearn: | Mail Online only made 41 mill in *Revenue* |
| 13:50:35 | coke0: | anyone familiar with the CoA paper? |
| 13:50:52 | hearn: | CoA? |
| 13:51:04 | coke0: | chains of activity |
| 13:51:13 | Emcy: | hhuh whee did i hear 10 figures then |
| 13:51:28 | dsnrk: | hearn: I piped all of the spam a company sent to me to all of the management addresses I could find. don't know if it didn't anything, but made me feel a heap better. |
| 13:51:48 | coke0: | www.cs.technion.ac.il/~iddlo/CoA.pdf |
| 13:52:07 | hearn: | probably they never saw it ... |
| 13:53:07 | dsnrk: | I realise. feel good measures only. |
| 13:56:20 | Emcy: | why not take them to court |
| 13:56:47 | dsnrk: | court is expensive and a waste of time. |
| 13:57:18 | dsnrk: | what would I be suing them for? the 15 seconds it takes me to clear their crap out of my inbox. |
| 13:57:23 | Emcy: | i dont know what amerilaw is like on this but the boss of my ISP takes spammers to small claims court as a hobby and blogs about it |
| 13:57:53 | Emcy: | sometimes they will settle for a tenner in the first instance |
| 13:59:40 | epscy: | Emcy: Andrews&Arnolds? |
| 13:59:51 | dsnrk: | maybe if I lived in the US, not everywhere has such a court focused culture |
| 13:59:53 | Emcy: | uhuh |
| 14:00:10 | epscy: | I like reading his blogs |
| 14:00:51 | Emcy: | yes you could feel his glowing red butthurt coming off the screen reading the one about the ADR |
| 14:01:07 | Emcy: | dsnrk where you? |
| 14:01:34 | epscy: | yeah, he is clearly a man of principle |
| 14:01:54 | Emcy: | thats partly why i pay them |
| 14:53:10 | tromp__: | hmmm, xeon-fpga hybrid... http://www.theregister.co.uk/2014/06/18/intel_fpga_custom_chip/ |
| 14:54:25 | tromp__: | sounds like a miner's dream |
| 14:54:50 | dsnrk: | bet the price of those wouldn't be. |
| 15:04:36 | dsnrk: | petertodd: got any ideas on who "alicebtcmayes" is and why they're spreading nonsense? |
| 15:17:02 | andytoshi: | this just popped up on iacr: http://eprint.iacr.org/2013/308 |
| 15:17:29 | andytoshi: | are most ring signature schemes logarithmic in the anonymity set size? |
| 15:21:55 | tromp__: | you mean non-lattice based ones? |
| 15:25:24 | andytoshi: | yeah |
| 15:27:55 | tromp__: | the paper cites "compact group signatures" [12,27] so I'd check those |
| 15:28:31 | tromp__: | those are based on bilinear groups |
| 15:29:38 | tromp__: | hmm, i know one of the authors of [12], Oded Regev, is a colleague's husband |
| 15:30:12 | tromp__: | sorry, was looking at [13] not [12] |
| 15:30:15 | andytoshi: | hey, cool |
| 15:32:39 | gmaxwell: | I'd pointed out here that ZK-SNARKS give you a constant size ring signature. |
| 15:33:21 | gmaxwell: | (or a log sized one, depending on how you use the construction) |
| 15:33:35 | andytoshi: | constant, but with a fixed maximum size of anonymity set right? |
| 15:35:12 | gmaxwell: | only because of the fixed circuit size in the parameters, but even there, it's log scaling. |
| 15:35:47 | andytoshi: | cool, that's what i guessed |
| 15:36:58 | gmaxwell: | For example, you and verifier construct a hashtree over all the public keys in your anonymity set. Then you pick your actual pubkey, and prove its membership under zk-snark. Then you do the pubkey blinding I've proposed (key + nonce*G) == blind_key under the same zkp. Then outside of the zkp you sign using the blind_key, proving knoweldge of key and nonce. |
| 15:37:42 | gmaxwell: | so in that construction the ring signature is just a few hundred bytes regardless of the anonymity set size. |
| 15:37:42 | andytoshi: | gotcha. that's much more concrete than my guess ;} |
| 15:38:13 | gmaxwell: | (you could also verify a signtature with the selected pubkey directly under the zkp but the addition approach should be much computationally cheaper) |
| 15:39:12 | gmaxwell: | (or alternatively, pick a signature scheme which is cheap to verify inside your choice of zkp) |
| 15:39:24 | andytoshi: | yeah, that's clever. similar in spirit to the "division by verifying aux input" trick in the snarks paper |
| 15:40:22 | andytoshi: | i thinkk with key-image ring signatures (i'll go learn the traceability notions to mkae this more precise) we can get most of the privacy and storage-scaling we've been envisioning from snarks, without trusted setup.. but not cheap verification. i wonder if we can get that too |
| 15:43:38 | andytoshi: | by having miners aggregate signatures whose anonymity sets overlap or something |
| 15:45:09 | andytoshi: | i guess that's a weird notion of 'aggregate', i mean combining several sigs with (different message, same keyset) rather than several sigs with (same message, different keys) |
| 16:52:27 | andytoshi: | oh, i didn't realize that a 'group signature' is different than a 'ring signature' in that a group signature has some trusted party who can deanonymize people |
| 17:16:12 | adam3us: | i think conventional crypto ring sigs end up being typically linear in the set size |
| 17:31:58 | andytoshi: | a couple (possibly) doable improvements to cryptonote's ringsigs, which are from "Traceable ring signature" by Fujisaki/Suzuki with modifications to weaken traceability but keep double-spend detection, are (a) allow multiple key images so you can spend several coins with the same sig, (b) do this interactively with parties who own only one of the corresponding keys for "cryptonote coinjoin" |
| 17:40:12 | gmaxwell: | one simple improvement I've recommended to monero is that they make it so that you can include coins of any value in a mixin set and the value you treat the input as is simply the minimum. |
| 17:42:13 | gmaxwell: | This gives everyone slightly better privacy in so far as it lets people burn coins to increase their anonymity set size... this also makes it plusable to impose a minimum mixin set size — e.g. of 3 to reduce the pretty nasty problem where you make an anonymous transaction and then weeks or months later the inputs you joined with are spent in single input transactions, completely deanonymizing you after the fact... and people save ... |
| 17:42:14 | andytoshi: | i wonder if there is a risk that miners deanonymize people by forcing a large difference between the (unique) min and the other mixins? |
| 17:42:19 | gmaxwell: | ... on tx fees by doing that... |
| 17:42:39 | andytoshi: | ah, i see, you can't force a min set size without it |
| 17:43:34 | andytoshi: | and without a min size, miners could just as easily demand mixin set size 1 :) |
| 17:44:15 | gmaxwell: | yea, a min size is a soft-forking change, but it's not viable unless you can combine with inputs of different value, since there may not be enough of your particular value. |
| 17:44:43 | andytoshi: | (much more easily actually since there is a clear win for the de-anonymizer by forcing set 1; with differently-valued inputs, someone who really wants to hide can pay to do so) |
| 17:44:43 | gmaxwell: | I suppose you could require a min if and only if there are enough, but thats an expensive test. |
| 17:45:51 | gmaxwell: | indeed, thats a point.. miners soft forking the anonymity out.. though I don't know that a min size really solves that, e.g. I could just force you to always combine with a set of canonical dummy values as a soft forking change. |
| 17:46:50 | gmaxwell: | allowing multiple images is a trivial improvement. Indeed, it makes sense. The stuff I'm playing with for anonymous credentals does that. |
| 17:47:10 | andytoshi: | is it trivial? i have the paper in front of me but i'm posting here instead of reading it ;) |
| 17:48:08 | gmaxwell: | well it's trivial if you don't mind a size bloat. I haven't worked through if there is way to do it with small size since it wasn't relevant for my usage. |
| 17:48:10 | andytoshi: | note that soft-forking out txes that don't use specific dummy inputs would require a lot of collusion between mining power. to contrast, requiring value differences or mixin setsize 1 would simply require similar motivations, no collusion |
| 17:49:24 | andytoshi: | i was thinking for it to increase like O(n_images) + O(n_mixins) .... not O(n_images * n_mixins) |
| 17:49:56 | gmaxwell: | I don't think it requires any more collusion that someone posting some private keys for already spent transactions... which allows everyone to see that they're spent. |
| 17:51:47 | andytoshi: | oh, yeah, i see |
| 17:52:02 | gmaxwell: | (another point of these systems is that they need good key management to avoid the problem of someone trying to demand you release your watching private keys so they can deanonymize transactions (not just yours, but any joined with yours). |
| 17:53:12 | gmaxwell: | (all the bytecoin wallets today use a single set of keys, and the addresses don't encode a good-until, so its hard to have good key management practices) |
| 17:55:29 | andytoshi: | i wonder if there is a way to push dummy TXOs into the TXOset without them being identifiable as dummies? like i spend 1btc and put five 1btc outputs on my tx. somehow it's provable that only one is real (that is, all but one are produced by forcing a random-looking # to satisfy the curve eqn rather than being derived from a privkey) but not which one |
| 17:55:48 | andytoshi: | i'd guess not without some sort of general ZKP system, and then we're into trusted-setup land.. |
| 17:55:56 | gmaxwell: | hm. no that might be possible. |
| 17:56:03 | hearn: | maybe. eli keeps mentioning some solution for trusted setup |
| 17:56:07 | hearn: | some fancy new PCP |
| 17:56:29 | gmaxwell: | Yea, in theory it's possible though the size of the proofs looks like it will be greater. Not as close to pratical yet. |
| 17:56:59 | hearn: | gmaxwell: do you know any good tutorials on PCPs? i think i understand most of the snarks papers, but the core PCP stuff has always been beyond me. |
| 17:57:05 | hearn: | the only lecture notes i found didn't help |
| 17:57:20 | nshlike: | +1 |
| 17:58:36 | gmaxwell: | hearn: well pcp theorem itself is quite simple to understand (the proof of it is not). First you have to be comfortable with the idea of a linear error correcting code. (e.g. http://www.ioremap.net/projects/ldpc/ for a visualization) |
| 17:58:37 | andytoshi: | ditto |
| 17:59:19 | gmaxwell: | The idea there is that you can take a message, and expand it into a larger encoded message using a graph that tells you what bits in the inital message to xor to produce extra parity check bits. |
| 17:59:48 | gmaxwell: | Then there are efficient algorithims to recover the original message even if some bits are corrupted, by enforcing the linear constraints given by the parity graph. |
| 18:00:51 | gmaxwell: | Given such a system you can also do a related trick where you sample a couple bits of the message and can answer a question "Do these bits likely come from an uncorrupted message encoded with this code?" |
| 18:01:12 | adam3us: | andytoshi: the idea of a (single) homomorphically encrypted value + a ring sig could in theory allow you to mix across more tx, because the values dont have to match. |
| 18:02:11 | adam3us: | i was pipedreaming while playing with HE encrypted value ring sig that there maybe a application specific optimized ring sig that could mix with the entire coin set in fixed compact size. (without SNARKs). needless to say so far I failed. |
| 18:02:31 | adam3us: | (ie it works because you prove you own the coin or the value you subtract is 0 specifically in the encrypted value case) |
| 18:03:10 | hearn: | right, i remember that PCPs involve random sampling of some very large string |
| 18:03:36 | hearn: | where the full string is an execution trace or something? |
| 18:03:37 | gmaxwell: | It turns out that if the parity check graph has some special properties (that its a particular kind of expander graph) then you can make some very strong promises about that trick— such that if you expand the graph enough a single randomly placed test gives you a 50/50 chance of detecting a corrupted message. This is possible because the graph is sufficiently dense that an attacker can't flip one bit to make one test pass without ... |
| 18:03:43 | gmaxwell: | ... making some other test fail. Once you've got this you can just add a couple more queries to get whatever security level you want. |
| 18:04:06 | andytoshi: | adam3us: i wonder if you could HE the actual coin value, and on spend you prove a valid re-encryption without revealing this value. then no coins have any publically-visible values on them |
| 18:04:30 | gmaxwell: | Now, so this should be enough to give you a handwave understanding that there are these error correcting codes where you can tell if a really large codeword is a valid codeword probablistically. |
| 18:04:31 | andytoshi: | that uses the same words as the popular renditions of gentry's FHE-from-bootstrapping-HE, so in my mind they're similarly possible ;) |
| 18:05:04 | gmaxwell: | The next idea is that people came up with a series of graph transformations that convert _any_ partity check matrix into a larger partity check matrix that meets the required expander property. |
| 18:05:24 | gmaxwell: | so you can take any preexisting erorr correcting code and boost it into one that is probablistically testable. |
| 18:05:54 | adam3us: | andytoshi: "could HE the actual coin value, and on spend you prove a valid re-encryption without revealing this value. then no coins have any publically-visible values on them" definitely thats exactly what happens. i got that bit working |
| 18:06:07 | andytoshi: | adam3us: woah |
| 18:06:20 | adam3us: | andytoshi: full value privacy for 1kB coins +- |
| 18:06:38 | gmaxwell: | Then the final point is that these error correcting codes are themselves representations of solutions to a binary biparte constraint satistfaction problem. Which is NP complete, so you can convert verifying your transacript into one of them, then apply the graphy transformations to boost it.. then sample it. The tricky part is that if you do this the naieve way you end up with things like the interior string being 2^500 bits in size. |
| 18:06:53 | gmaxwell: | (for a reasonable size program) |
| 18:07:13 | andytoshi: | adam3us: 1kb is not too bad if we can get a sensible sharding mechanism to work (where everyone stores only their own coins + a small subset of the rest) |
| 18:07:27 | gmaxwell: | So all the work in making this stuff actually usable is finding improved constructions for the error correcting codes that have useful algebraic properties that let you avoid actually concretely materializing the interior steps. |
| 18:07:39 | andytoshi: | which i think we did figure out yesterday, just use prefix filters on a hash-ordered merkle trie.. |
| 18:08:02 | adam3us: | andytoshi: well you do claw some space back, because you no longer have to mess with standarized denomination coins (ala cryptonote). so its one coin vs what log(2)… so it probably comes out even |
| 18:09:12 | adam3us: | andytoshi: oh yeah, and its backward compatible with unencrypted values so you can eg take a E(x)+y+c=E(z) where y = spent value (disclosed) and c = change (also disclosed) |
| 18:09:13 | hearn: | right. so the constraints that result from solving the circuit are converted into an instance of one of these error correcting codes, and then sampled, yielding the proof. |
| 18:09:39 | adam3us: | andytoshi: so you can convert between encrypted & unencrypted values freely and mix them. |
| 18:09:55 | hearn: | and because this probabilistic sampling is so strong, you don't need many to be virtually guaranteed, hence the small and fixed number of field elements |
| 18:10:07 | andytoshi: | adam3us: could you force use of encrypted values, if you were worried that miners would soft-fork them away otherwise? |
| 18:10:13 | adam3us: | #bitcoin-snarks :) |
| 18:11:18 | adam3us: | adam3us: you could. also it has different privacy tradeoffs. eg maybe some people less care about identity privacy and network anonymity if they're not broadcasting their tx size or btc networth / investment grade stored coin value |
| 18:14:23 | andytoshi: | yeah, what you don't want to see is that only criminals/political dissidents are using encrypted coins, then you can pick them off by ISP monitoring to see who is originating spends from encrypted coins |
| 18:14:59 | nkuttler_: | nkuttler_ is now known as nkuttler |
| 18:17:04 | gmaxwell: | andytoshi: in any case that stuff is all reasons to enforce a baseline level of usage. |
| 18:17:45 | zooko: | I'm skeptical about any opt-in privacy measures. |
| 18:17:59 | zooko: | It seems like privacy has to be generally default-on for users for it to work. |
| 18:18:30 | gmaxwell: | zooko: there are four levels that I think are interesting to consider, unavailable, opt-in, default, mandatory. |
| 18:18:42 | zooko: | * zooko nods. |
| 18:19:04 | zooko: | The highest level gets into weird stuff where the user is trying to collude with someone else to prove facts about themselves. |
| 18:19:20 | gmaxwell: | For what the bytecoin ring signature (BRS), I think there is a reasonable argument for mandatory... since people who don't behave privately may retroactively undo the privacy of third parties long after the fact. |
| 18:19:21 | zooko: | Like in voting protocols, where you want the system to prevent the user from proving how they voted, to someone else. |
| 18:19:36 | zooko: | So, maybe what I was talking about was a 5th level. |
| 18:19:44 | zooko: | I'm interested in mandatory-within-this-protocol. |
| 18:20:04 | gmaxwell: | yea, strong resistance to vote buying is hard, I don't think privacy systems can really hope to deny users deanonymizing themselves actively— and probably they shouldn't want to since opt-in transparency is very useful. |
| 18:20:07 | zooko: | So, you can circumvent it by, you know, sending a selfie video of yourself using the GUI, to your confederate, |
| 18:20:15 | zooko: | but there's no simple, available way to |
| 18:20:18 | zooko: | "turn it off |
| 18:20:31 | zooko: | " in the reference client or in the protocol. |
| 18:20:45 | gmaxwell: | For example in BRS (or bitcoin stealth addresses) you can just publish your watching private key, and then everyone with that key can identify all your transactions. |
| 18:21:02 | zooko: | So, I'm currently intending to have mandatory privacy in my "zookoin". |
| 18:21:34 | andytoshi: | adam3us: have you written anything publishable about your HE-valued coins? |
| 18:22:31 | andytoshi: | zooko: for something like this where you aren't touching consensus mechanisms and aren't concerned about scarcity properties, a sidechain is definitely appropriate |
| 18:23:39 | tromp__: | will zookoin have a hard-cap on #coins? |
| 18:31:42 | zooko: | Oh great! We have an explanation. We were successfully spear-phished. |
| 18:31:57 | zooko: | andytoshi: disagree. |
| 18:32:25 | zooko: | andytoshi: because I intend to have different consensus mechanisms and am concerned about scarcity properties. :-) |
| 18:33:03 | zooko: | andytoshi: basically, side-chains seem perfect for something that wants to experiment with the means-of-payment use of money while relying on Bitcoin for the store-of-value use of money, and that doesn't describe my project. |
| 18:33:14 | zooko: | tromp: not entirely sure. |
| 18:33:49 | zooko: | tromp: nowadays, I try to always think in terms of percentage of total. So giving 100 units to a miner as a reward, I don't think of as increasing the monetary base; |
| 18:34:10 | gmaxwell: | zooko: care to share what form the spear-phishing took? I get a lot of attempts, but none are ones I'd be likely to fall for (poorly targeted) |
| 18:34:12 | zooko: | I think of it as increasing that miner's %-ownership, and decrementing everyone else's by a % amount that sums to the % that miner gained. |
| 18:34:33 | zooko: | gmaxwell: so, kind of embarassing to fall for this, and I'm redacting details. |
| 18:34:57 | zooko: | But, I can say that it was actually sent from one member of our company's email account to another member who had higher privs. |
| 18:35:27 | zooko: | Another identical attempt was made to a third member, apparently coming from a trusted partner organization, but that one failed. |
| 18:36:04 | gmaxwell: | (e.g. sending me exe files is /never/ going to work; considering I can't even run them without significant effort) |
| 18:37:04 | zooko: | The payload was a web site named google-doc-delivery-something-something that asked for your google password. |
| 18:37:10 | zooko: | So, that's the embarassing part. :-) |
| 18:37:45 | midnightmagic: | zooko: Did you have two-factor turned on? |
| 18:38:09 | zooko: | I believe that person didn't at that time. |
| 18:38:14 | zooko: | That would have helped. |
| 18:38:34 | midnightmagic: | Understood; thanks for the candour. |
| 18:40:35 | zooko: | midnightmagic: glad you appreciate it. ;-) |
| 18:40:50 | zooko: | It is awfully tempting to stay close-lipped about this kind of stuff, but I'm trying to practice transparency. |
| 18:41:10 | zooko: | Reminder: no customer data has been exposed to eavesdropping or tampering, thanks to end-to-end encryption and integrity-checking. |
| 18:41:58 | midnightmagic: | It's extremely helpful. Reading about the details of some random goof-off getting phished because he clicked on a nigerian prince scam mail is a waste; reading how relatively educated, intelligent people got caught is basically the most interesting and educational thing I'll likely be doing today. |
| 18:45:50 | zooko: | Well, we'll try to write it all up properly for our corporate blog. |
| 18:45:57 | zooko: | We're still following-up right now ... |
| 18:46:03 | zooko: | midnightmagic: thanks for the encouragement! |
| 18:46:54 | midnightmagic: | thanks zooko. |
| 18:53:55 | nshsome: | zooko, commiserations. glad you got clarity though |
| 18:54:27 | nshsome: | it's what you learn that matters :) |
| 19:10:10 | adam3us: | andytoshi: "have you written anything publishable about your HE-valued coins?" pfff i wrote a bitcointalk post, my job is done :) |
| 19:11:05 | adam3us: | andytoshi: you might notice it took me 5 years to getting around to writing a hashcash paper, ideas always more exciting than papers. |
| 19:19:03 | andytoshi: | adam3us: awesome, i'll track down the bct post and play with implementing it one of these days |
| 19:22:13 | andytoshi: | adam3us: i guess you mean https://bitcointalk.org/index.php?topic=305791.0 ? |
| 19:23:47 | gmaxwell: | andytoshi: I think you were onto something with the cover outputs.. I think it would increase the BRS anonymity pretty substantially if possible. |
| 19:24:08 | gmaxwell: | Since a cover output would never be honestly spent, someone who joined against it would never get deanonymized. |
| 19:26:36 | andytoshi: | gmaxwell: cool, i'll think about it. obvs if you have a snark you can do it..but there should be a simpler way. perhaps somehow the x-values of your outputs are in a circle, like { x, H(x), H(H(x)), H(H(H(x)), ..., x } where somehow after applying enough H's you get your original x back |
| 19:27:26 | andytoshi: | then once you compute one of them (with an actual privkey), the other points are determined but you can't get their privkeys if H is "secure" |
| 19:27:37 | adam3us: | andytoshi: yes. also https://bitcointalk.org/index.php?topic=509674.0 |
| 19:30:27 | andytoshi: | (and for someone who doesn't know which one is "real", he can verify that the circle actually is correct and be indifferent to his starting point) |
| 19:30:34 | gmaxwell: | well for example, the last block hash coerced to a point: B = to_point(H(blockid) .. then I publish X and Y such that X-Y==B or Y-X==B. one of X or Y is a pubkey for which no one knows the private key, but you don't know which. Or am I on drugs? slow day today. |
| 19:32:19 | andytoshi: | nice. looks good to me. tho i don't see that it generalizes readily to more than 2 points |
| 19:34:09 | gmaxwell: | I don't think it needs to, really. |
| 19:34:20 | gmaxwell: | creating 2x the number of outputs is already huge coverage. :) |
| 19:35:20 | andytoshi: | yeah, a good point. and i like this because assuming the blockhash is random the security (defined as somebody somehow learning both keys) actually reduces to DL |
| 19:35:31 | andytoshi: | and i bet that'd be really hard for more creative schemes |
| 19:36:19 | gmaxwell: | I think I can see how to do it to four keys with a bilinear group. |
| 19:36:38 | gmaxwell: | but in any case, two I think is fine, and I think my scheme is secure. |
| 19:38:14 | andytoshi: | i think so. it doesn't reduce to DL the simple way i thought it did unless the adversary is forced to choose his pubkey before knowing the blockhash. but obvs that is unrealistic |
| 19:42:04 | andytoshi: | oh, derp, it does reduce to DL. i thought you were saying x(X) - x(Y) = B. if X - Y = B, and an attacker knows privkeys x, y, then the DL of B is just x - y. |
| 19:43:14 | andytoshi: | oh, though i think you want X + Y = B to make sure X, Y are symmetric to a "find out the real pubkey" attacker |
| 19:55:51 | andytoshi: | btw i think "a single addition" sets a record for simplest thing we have ever initially thought to do with a SNARK here.. |
| 19:57:46 | nshsome: | hmm |
| 19:57:50 | gmaxwell: | oh well I thought it was possible via an addition the moment you mentioned it. :) |
| 19:58:18 | andytoshi: | fine, then a personal record for me :) |
| 19:58:20 | gmaxwell: | just took me a minute to think about if it mattered with the nothing up my sleeve number was. I don't think it does, it can be a constant. |
| 19:58:27 | gmaxwell: | except then its a trusted initilization. :) |
| 19:59:07 | andytoshi: | it could be a SHA2 hash of some other part of the transaction. or you can refer to a block # and use the hash |
| 20:01:13 | andytoshi: | a constant SHA2() would be a nice homage to satoshi :) |
| 20:02:49 | nshsome: | there's always leah goodman's newsweek article |
| 20:05:07 | gmaxwell: | andytoshi: hm. Does this actually help. Say TX_1 spends TX_0.x and TX_2 spends TX_0.y isn't this just isomorphic to both spending TX_0.x and there being no y? a bit ago it seemed like no to me, but I've forgotten what case it matters in. |
| 20:06:17 | andytoshi: | gmaxwell: it matters in the case that keys (or their mapping to key images) are leaked |
| 20:07:29 | gmaxwell: | hm. If the keys are leaked then you can tell which pubkeys are actually the ECDH products and so you can tell which are real and which are fake. |
| 20:07:51 | andytoshi: | ohh, hmm, crap |
| 20:08:04 | gmaxwell: | I think it matters if we can do a 2 of 3. |
| 20:08:33 | andytoshi: | yeah. but that's easy, have X + Y + Z = B |
| 20:09:00 | gmaxwell: | yea, the addition gives you one degree of freedom. |
| 20:09:10 | gmaxwell: | so lets see, how does it matter in that case? |
| 20:09:41 | andytoshi: | well, if X or Y is leaked it reduces to the 1-of-2 case, if both are leaked then we lose |
| 20:09:58 | andytoshi: | what if we had 2 degrees of freedom somehow? would that help? |
| 20:10:37 | gmaxwell: | Well I'm mostly thinking now in terms of the kinds of graphs that it allows you to create. |
| 20:11:03 | gmaxwell: | The problem is that even with the minimum mixin constraint it's very easy to form cliques where knowing a few values resolved the entire mapping. |
| 20:13:04 | gmaxwell: | graph expansion on the txout side is cheaper than on the mixin side, since the mixin side requires r,s per input. |
| 20:13:14 | gmaxwell: | and a txout is forever. |
| 20:17:17 | gmaxwell: | andytoshi: so here is a use for 1 of 2. |
| 20:17:55 | gmaxwell: | oh hm breaks images one sec. |
| 20:18:00 | gmaxwell: | here is a use for 2 of 3. |
| 20:18:13 | gmaxwell: | crap no |
| 20:18:15 | andytoshi: | re txouts are cheap, yeah. but i can't think of a way to add dummy txouts so that (a) you can verify that there aren't extra real txouts but (b) you can't expose which ones are fake |
| 20:18:37 | gmaxwell: | okay, what I'm trying to do is say that Either value 2 output A is valid or the two value 1 outputs B and C are valid, but not both. |
| 20:19:07 | gmaxwell: | 1 of 2 doesn't work because the images prevent you from creating two outputs with the same key. |
| 20:19:53 | gmaxwell: | so how do we get a X || Y&&Z |
| 20:20:08 | andytoshi: | ok, i gotcha. but it's not clear that this improves the situation, if any of A, B, C are real you know whether the others are real |
| 20:20:30 | phantomcircuit: | https://github.com/pstratem/bitcoin/compare/poweroftwooutputs?expand=1 |
| 20:20:33 | phantomcircuit: | it's hideous |
| 20:20:35 | gmaxwell: | it doesn't improve your key leak stuff, but it prevents the graphs for different values from being disjoint (ignoring people burning coins, which we can assume is rare) |
| 20:20:36 | phantomcircuit: | but i think it works |
| 20:20:48 | phantomcircuit: | maybe.... |
| 20:21:23 | gmaxwell: | andytoshi: I think the only way to improve key leaks is to add expiration dates to addresses and get people destroying old keys. |
| 20:21:26 | andytoshi: | oh, i see what you're going for gmaxwell. ok, this feels like a classic algebraic geometry problem where you can combine addition and multiplication to get arbitrary relations.. |
| 20:21:38 | andytoshi: | e.g. xy = 0 means x or y is 0, but x^2 + y^2 = 0 means that both x and y are 0 |
| 20:22:16 | andytoshi: | (well, that works in the field of reals, not in any finite field) |
| 20:22:27 | gmaxwell: | yea, well, we get one group operator. :P |
| 20:23:17 | andytoshi: | hopefully yeah. i'm not ruling out doing math on the x-coordinates but i really don't want to because you are basically exposing all of algebraic geometry as an attack vector |
| 20:23:31 | andytoshi: | and you aren't group-agnostic |
| 20:24:53 | gmaxwell: | okay I think I've got it. |
| 20:28:18 | gmaxwell: | you do a X || Y is valid. The resulting spendable coins are X with value 2, or Y and Y+C with value 1. C is just another public point revealed in the output (random if Y is the random point), where C!=B. |
| 20:28:54 | andytoshi: | yup, i was just getting there |
| 20:29:00 | andytoshi: | :P one day i'll be faster than you.. |
| 20:32:04 | gmaxwell: | Y and Y+C can have any value that sums to X, too. which is handy. |
| 20:32:21 | andytoshi: | because then C is implicit? |
| 20:33:37 | gmaxwell: | no no I mean, C is just some nonce where the discrete log is known to the reciever. I even think it can just be G. |
| 20:33:59 | andytoshi: | oh, my bad, you mean the values sum to X, not the points |
| 20:34:03 | gmaxwell: | yea yea |
| 20:34:45 | gmaxwell: | I just mean the values are positional, e.g. the first one is the total value, then there is one other key and two values that sum to the total. |
| 20:35:25 | gmaxwell: | I'm pretty sure that I convinced myself previously that adding points to keys didn't change any of the properties. |
| 20:35:28 | andytoshi: | yeah, G is fine, there is no privacy loss since the outputs are already in the same transaction |
| 20:36:01 | andytoshi: | tho, maybe Y and C are known to different people..can't do that if C = G :) |
| 20:49:47 | gmaxwell: | andytoshi: now the fun question is can we do a 1 of N while only communicating one or two points explicitly? because if we can the tx out could really be a commitment to all possible mixtures (well perhaps just log2(values) in octave splits or whatever) compactly. |
| 20:50:57 | gmaxwell: | I feel like it should be possible, one point because we only need one degree of freedom to control a single point of interpoation.. and another point to blind the operation. |
| 20:55:54 | gmaxwell: | andytoshi: oh an odd thought too— so the sender has to control which of the groups (e.g. X or Y) is the pubkey, but the mapping of value to group can be controlled by someone else. This means that you could use e.g. block hashes to select the mapping so that people couldn't choose to always get the bigger coin. |
| 20:57:45 | gmaxwell: | if we can get the efficient 1 of N working, then we end up with a structure where when you get paid X coin, you get paid really N=1..finite number of coins summing to X coin where the network can choose the probablity distribution. |
| 20:57:50 | andytoshi: | weeeird |
| 20:58:02 | gmaxwell: | and you cannot. but the network doesn't know which coins it actually gave you. |
| 20:58:06 | gmaxwell: | just that they sum to X. |
| 20:58:58 | andytoshi: | yeah, this seems worth it for the bizarro factor alone. but also it should do a great job of mixing up the value-indexed taint graphs |
| 21:00:47 | andytoshi: | i think we want to do log2 octave splits, and enforce outputs of size 2^n to make the number of buckets small |
| 21:04:21 | gmaxwell: | yea log2 octave splits, though I don't think there is any particular need to make the values in each group equal. |
| 21:05:17 | gmaxwell: | The super bonus point challenge is can the 1 of N scheme have the _sender_ not know which of the N is the valid one, without interaction with the reciever (with intereaction its easy to acheive that, have the reciever provide the keys). |
| 21:06:20 | gmaxwell: | e.g. you prepare values such that when the sender does the encoding position 3 will always be the valid one, but the sender doesn't know this. |
| 21:10:10 | gmaxwell: | probably what you'd have is mapping where there are 8 positions and the network picks split counts like 1,1,1,2,2,2,4,8 or if your value is too small, 1,1,1,1,1,1,2,2 or if its too big, 1,2,2,4,4,4,4,8 etc. |
| 21:10:28 | gmaxwell: | and can just be a determinstic process based on the sum and the set of avaliable coins. |
| 21:12:14 | andytoshi: | yeah, the exact splits (or even numbers of outputs) probably won't affect the group math.. |
| 21:12:29 | gmaxwell: | yea, the money is irrelevant to the group math. |
| 21:12:48 | gmaxwell: | it's just lables after the fact and the number of outputs for a given group is increase just by successive addition of G. |
| 21:12:54 | gmaxwell: | (or any other constant) |
| 21:13:02 | gmaxwell: | (with known discrete log) |
| 21:13:34 | andytoshi: | right. |
| 21:24:22 | gmaxwell: | andytoshi: going off this path of fun for a moment, there are a couple of other complementary privacy things that could be done— perhaps less realistically. |
| 21:24:58 | gmaxwell: | One is that these ring signatures are not incomaptible with also using the one way aggregate signatures. |
| 21:25:25 | andytoshi: | ah, i was gonna ask about that, but it wasn't obvious what the logistics would be |
| 21:26:02 | gmaxwell: | For example you make your transaction which ringsigns a one time OWAS public key with the BRS ring signature. and also provides outputs summing to the total value (minus fees) each with their own pubkey.. and a merged signature. |
| 21:26:11 | gmaxwell: | then miners can merge up independant transactions. |
| 21:26:45 | gmaxwell: | e.g. the fact that the cryptosystems work is seperate groups is irrelevant, the OWAS stuff is all completely ephemeral, just allowing anonymity with a block. |
| 21:27:08 | andytoshi: | what is "total value", the value of all outputs in the block? |
| 21:27:27 | andytoshi: | doesn't that change as new transactions come in? |
| 21:28:57 | gmaxwell: | well at at time you will have a OWAS signature which is a tuple of sets: {input mixines_0..n, outputs_0..m, signature). The OWAS is valid only if the sum of all the output values <= the sum of all the mixins values, and the signature is a valid signature for all mixins and all outputs |
| 21:30:23 | andytoshi: | oh, i didn't know OWAS was that aware of values, i thought it just counted signatures for one-sig-one-vote systems |
| 21:32:11 | gmaxwell: | OWAS isn't value aware It's just a system where you can take {pubkey_1, message_1, signature_1} + {pubkey_2, message_2, signature_2} + ... = {[pubkey_1,pubkey_2,...],[message_1, message_2,...],signature} and cannot disaggregate them |
| 21:32:18 | gmaxwell: | to use it for anonymous transactions to do a clever hack |
| 21:33:20 | gmaxwell: | where to make a transaction you make two signatures {randompubkey, "empty message", signature} and {randompubkey2, "output", signature} you sign randompubkey with your inputs .. then aggregate the two puppies. |
| 21:33:39 | gmaxwell: | then send them to someone else, who can add more inputs and outputs to the group but can't take your outputs out. |
| 21:34:02 | gmaxwell: | and a third party you recieves the results can't tell what the mapping was. |
| 21:34:04 | andytoshi: | ah, i got it now |
| 21:35:01 | NikolaiToryzin: | NikolaiToryzin is now known as stqism |
| 21:35:07 | stqism: | stqism is now known as NikolaiToryzin |
| 21:37:10 | andytoshi: | oh, that's tricky. iirc the last time i thought about it i didn't see how to merge txes like that |
| 21:37:20 | andytoshi: | did you come up with that? |
| 21:38:31 | gmaxwell: | No. Some anonymous poster to bitcoin talk. I wish I were that smart. :) I might have come up with it if I knew that the OWAS existed before his post! :) |
| 21:41:46 | andytoshi: | hahaha, if i'm ever time-travelling i guess i know where to go to post future knowledge.. |
| 21:42:07 | andytoshi: | that's really cool that ideas can show up in this space without names attached |
| 21:42:20 | gmaxwell: | so the other crazy thing that could be done with BRS which is complementary that comes to mind is this: a miner can at random select a bunch of existing coins, (say 128), and then for each txout they generate a nonce N. They add N*G to the block for each one, they select a random permutation, and commit to a hashtree of the raw N values and permutation position for each coin. Then for each of their selected txouts they compute ... |
| 21:42:26 | gmaxwell: | ... pubkey*A = X and a new pubkey as pubkey+X. Then the mine the block. The block hash then selects some random fraction (e.g. half) based on the winning block hash, where they reveal the new position and the nonce. |
| 21:43:01 | gmaxwell: | (this idea is related to one Sergio has had but I believe has never published. It's especially attractive where the txouts are all pubkeys in a complete cyclic group) |
| 21:43:33 | gmaxwell: | So the notion here is that the miners are constantly remixing the txout set, and using a cut and choose proof to show they did it correctly. |
| 21:43:52 | gmaxwell: | Of course the mix operation could be done inside a more efficient ZKP too, but ideas that need less fancy crypto are fun. |
| 21:45:57 | gmaxwell: | hmm well 128 and half is not a great security level, but some parameters can be picked that are interesting, but the overhead kinda stinks. |
| 21:47:09 | gmaxwell: | in any case that kind of continuious stirring would have a useful property in that it jams up graph analysis over time. |
| 21:47:22 | andytoshi: | where does the mixing happen? i see some nonces and commitments to them.. |
| 21:48:10 | gmaxwell: | " Then for each of their selected txouts they compute pubkey*A = X and a new pubkey as pubkey+X" e.g. every selected txout gets replaced with a new one and the whole list is permuted. |
| 21:48:28 | gmaxwell: | then the commitment is used so that part of the permutation can be revealed without revealing the rest. |
| 21:48:53 | andytoshi: | right, sure, but how are these outputs spent if their pubkeys have changed? |
| 21:49:05 | gmaxwell: | the new key is communicated to the owner via ecdh. |
| 21:49:13 | gmaxwell: | oh crap actually nevermind haha, it breaks the ring signature property. |
| 21:49:26 | gmaxwell: | since you'd lose track of spendedness when the key is rerandomized. |
| 21:49:28 | andytoshi: | ah, i see what you're saying |
| 21:49:42 | andytoshi: | but yeah, we have a STXO set that can't be mapped back to TXO |
| 21:49:52 | gmaxwell: | okay, so scratch that, that one is not actually BRS compatible. The OWAS is. |
| 21:50:51 | gmaxwell: | space oveheard of the OWAS is nice, ... better than RS for similar global privacy, but the computational overhead is less so. |
| 21:51:08 | gmaxwell: | though the RS actually makes the OWAS more efficient. |
| 21:51:25 | andytoshi: | i think it gives better privacy too since there'll be inputs that aren't even used |
| 21:51:37 | gmaxwell: | Yes. |
| 21:51:38 | andytoshi: | and the miner who does the aggregation doesn't have enough input to fully deanonymize people |
| 21:51:43 | andytoshi: | info* |
| 21:52:15 | gmaxwell: | well OWAS doesn't only have to have miners aggregate, the aggregates can be aggergated. So any relay node can aggregate things and the miner has to take or leave the whole aggregate. |
| 21:52:28 | gmaxwell: | (or learn about its parts via another channel) |
| 21:52:46 | gmaxwell: | but right _no_ party has data to fully deanonymize people, which was something OWAS couldn't do by itself. |
| 21:53:12 | andytoshi: | suppose my node sees an aggregation with inputs {A, B, C}, and another aggregation with inputs {B, C, D} |
| 21:53:22 | andytoshi: | because all of its peers are aggregating willy-nilly |
| 21:53:34 | andytoshi: | can my node combine them cleanly? would we need to support repeated inputs? |
| 21:53:51 | gmaxwell: | yea, they can't be combined cleanly. |
| 21:54:11 | gmaxwell: | well I think perhaps they can with redundancy but thats ugly. |
| 21:54:36 | andytoshi: | hmm, so there is a potential DoS vector by pushing overlapping aggregates to many poinst in the network |
| 21:54:44 | andytoshi: | just to bloat blocks |
| 21:54:52 | gmaxwell: | The verification takes inputs + outputs + 1 pairing operations. |
| 21:55:11 | gmaxwell: | I'd just assume forbidding the overlaps, so then indeed, you'd probably assume it was mostly the miners doing it. |
| 21:55:41 | andytoshi: | yeah, i think that's the way to go. maybe you can even deanonymize the aggregate by pushing carefully chosen overlaps and counting redundancy.. |
| 21:55:55 | andytoshi: | so it'd be best to make it miner-only, no redundancy |
| 21:56:39 | gmaxwell: | So the point I was making about performance is that the RS lets you add additional inputs (which aren't really being spent) for much cheaper, probably the cpu costs of 100 extra RS inputs == OWAS input. |
| 21:57:38 | andytoshi: | oh, nice |
| 21:58:17 | andytoshi: | i worry then if we make miners OWAS everything into one, they won't want to include transactions because it's too costly |
| 21:58:30 | gmaxwell: | why? it's linear. |
| 21:58:45 | gmaxwell: | e.g. one verify for the whole block. |
| 21:59:01 | andytoshi: | oh, derp, i was thinking that adding a tx correctly would take compute time away from hashing |
| 21:59:08 | gmaxwell: | one of the side benefits of OWAS is that it gives you a degree of anti-censorship. |
| 21:59:10 | andytoshi: | but ofc there is different hardware being used |
| 21:59:13 | andytoshi: | for like 3 years now |
| 21:59:15 | gmaxwell: | yea. |
| 21:59:48 | gmaxwell: | e.g. if some aggregator gives a miner a bunch of txn it wants to mine and a few it doesn't— for whatever reason— it has to take or leave the whole group. |
| 22:00:24 | andytoshi: | ah, yeah, that's cool. so if there was fear of censorship maybe someone like EFF would stand up an aggregation node just for this purpose |
| 22:00:28 | gmaxwell: | also, since the miner takes fees by just adding an additional output, a competing miner that hasn't heard the same transactions can't snipe the miner to steal fees. |
| 22:00:59 | gmaxwell: | (he can only steal fees for transactions he's heard independantly of via the other miner's block) |
| 22:01:09 | andytoshi: | hey, and the aggregator could give himself fees too |
| 22:01:35 | zooko: | zooko has left #bitcoin-wizards |
| 22:02:16 | andytoshi: | and you could do receiver-chooses-outputs-(except-change) transactions |
| 22:02:50 | gmaxwell: | yes thats one of the things this does. |
| 22:03:51 | gmaxwell: | which is nice because it means that in an interactive payment, the sender won't even know what outputs were created. |
| 22:04:27 | andytoshi: | yup. and with fee-sniping blocked the sender might even give different outputs to different miners |
| 22:06:48 | andytoshi: | how does OWAS interact with our dummy-output schemes? |
| 22:07:19 | andytoshi: | it seems like you wouldn't be able to group outputs so ensuring that the correct proportion were dummies wolud be hard |
| 22:07:21 | gmaxwell: | doesn't— the OWAS is only used to bind outputs and inputs, e.g. just proves a block was constructed fairly. |
| 22:07:48 | gmaxwell: | e.g. an output would be a ((X or Y) total value =2 )--owas |
| 22:08:12 | andytoshi: | oh, gotcha, that's fine then |
| 22:08:34 | andytoshi: | i was hoping that if the 2 was split across several keys these could somehow appear independent |
| 22:09:02 | maaku: | maaku is now known as Guest3152 |
| 22:09:04 | andytoshi: | but it doesn't hurt anything that they're not, compared to the no-splitting case |
| 22:09:09 | andytoshi: | no-dummies case, i mean |
| 22:09:35 | Guest3152: | Guest3152 has left #bitcoin-wizards |
| 22:09:51 | gmaxwell: | so interesting— I think 3mixin + owas + 1 of 2 output looks like it's still less bandwidth overhead than zerocash. |
| 22:10:13 | gmaxwell: | and the owas is faster to verify too. |
| 22:10:58 | gmaxwell: | privacy is still less good, but harder to compare with our enhancements... though no CRS assumption still, though the OWAS adds a pairing crypto security assumption. |
| 22:12:07 | andytoshi: | do you know what assumption? i've made my peace with BDH.. |
| 22:12:50 | gmaxwell: | It's just BDH. The security proof for the OWAS shows how to turn a OWAS deaggregator or signature forger into a black box discrete log solver. |
| 22:13:55 | andytoshi: | when you do the OWAS does it combine all the mixins? |
| 22:13:58 | gmaxwell: | The other nice thing about OWAS is that you can still have some privacy for fancy scripts that can't be ringsigned. |
| 22:14:09 | andytoshi: | or do you have this "clumpy anonymity set" which is hard to think about? |
| 22:14:39 | gmaxwell: | It's clumpy. It's a random permutation of one of n. inputs. |
| 22:15:30 | andytoshi: | hmm, i wonder if you could improve that |
| 22:15:39 | gmaxwell: | If we figure out if its easy to do an /efficient/ 2 of N BRS, (e.g. the value of the mixin is the two lowest inputs) then it gets even weirder. |
| 22:16:32 | andytoshi: | yeah, i'll spend some time thinking about that as well as 1-of-N outputs |
| 22:17:47 | gmaxwell: | damn, I wish there were a useful way to also add in the remixing thing. :P |
| 22:18:43 | andytoshi: | yeah, i think the key image completely kills that |
| 22:21:14 | gmaxwell: | well, there may be some way to do break apart the BRS where you the signatures shows that you know one of N discrete logs, and that the image is not of the pubkey but of the pubkey without the nonce. But think not. There may be a way to do this in a bilinear group that works. |
| 22:21:45 | gmaxwell: | I think perhaps at that point the complexity is getting high enough that zerocash starts looking attractive. :P |
| 22:22:34 | andytoshi: | yeah, even at a high level i'm having trouble keeping all this machinery in my head at once :P |
| 22:23:06 | andytoshi: | and trying to think about how anonymous am i to various parties, how does this change as my coins move, as other coins in the ringsig set move, as other coins in the OWAS move, etc, etc |
| 22:25:00 | andytoshi: | plus i'm thinking about prefix filter privacy and minimizing my TXO+STXO storage.. |
| 23:21:38 | skinnkavaj: | warren: Both Litecoin and Bitcoin development team too chicken to do anything about centralization? |