--- Log opened Tue Dec 24 00:00:22 2013
00:06 < nanotube> one can never have too many :Ps. >_>
00:06 < nanotube> but i guess if you're looking for a larger audience, maybe -dev.
00:06 < nanotube> or make a forum post >_>
00:15 < andytoshi> yeah, i'll make a forum post
00:15 < andytoshi> and try to preempt all the "TL;DR" and "nobody will use it, too complicated" posts..
00:16 < maaku> or even #bitcoin
00:17 < andytoshi> well what prompted my question was, i tried it on #bitcoin, and was flooded with "too complicated, just a toy, tl;dr, nobody would ever use this"
00:17 < andytoshi> apparently if you can't do something better to bitch about it than to either learn or ignore it
00:21 <@gmaxwell> andytoshi: Bitcoin-otc might be a better venue.  People are silly, obviously its not for everyone.
00:22 <@gmaxwell> andytoshi: you should probably announce a time in advance in order to get people to expect to be there. E.g. I was thinking of organizing a weekly thing.
00:25 <@gmaxwell> andytoshi: as far as a channel with technically interested people... hell if I know. Bitcoin is a complete mystery to me in that respect.
01:19 < andytoshi> gmaxwell: well, thanks for the convo that just happened on #bitcoin then :P
01:19 < andytoshi> also, i don't have your comments on ed25519
01:19 < andytoshi> there was a power outage where my logger lives, i think it was then
03:37 < Emcy> andytoshi did you make a coinjoin bot or something
03:40 < _ingsoc> Is the code available?
10:16 < nsh> --
10:16 < nsh> Alfred Menezes, who has studied the new algorithm as a cryptographic researcher at the University of Waterloo in Ontario, Canada, calls it "a fantastic algorithm—a stunning development." He says, "If I were a company today considering the use of pairing-based cryptography, I would be terrified of using small-characteristic pairings." In one case he studied, the algorithm succeeds in
10:16 < nsh> 274 operations, vs. 2103 operations with the previous best algorithm. "While the 274 computation is certainly a formidable challenge, with an organization like the NSA, it becomes feasible."
10:16 < nsh> -- http://cacm.acm.org/news/170850-french-team-invents-faster-code-breaking-algorithm/fulltext
10:18 < nsh> i'd like to see an animation of a las vegas descent tree algorithm in operaiton
10:33 < andytoshi> Emcy, _ingsoc_: no, ;;cjs just pings my website to get the current status
10:33 < andytoshi> the website is here: https://www.wpsoftware.net/coinjoin/ , the source to the interesting stuff is here: https://www.wpsoftware.net/coinjoin/
10:34 < andytoshi> but there's a lot of surrounding code which runs the website which is not public, it's too ugly
10:35 < andytoshi> i meant, the source is here: https://github.com/apoelstra/coinjoin
10:51 < Emcy> oh god rawtxs
10:52 < Emcy> A1 for effort, needs huge red 72pt warnings though
10:54 < andytoshi> there is quite a lot of work put into making it idiotproof
10:54 < andytoshi> i'm not a very creative idiot, but i can't think of what people could do wrong here
10:55 < Emcy> spending all change as fees is quite popular with the mortals who attempt to mess with rawtxs
10:56 < andytoshi> yeah, gmaxwell had a clever idea for that ... all the fees should be sent to a magic address, and the joiner does the fee calculations itself
10:57 < andytoshi> so submitted transactions are required to have inputs == outputs
10:59 < Emcy> is that possible in bitcoin right now
10:59 < andytoshi> no, the joiner actually modifies the transactions before asking for signatures
11:04 < michagogo|cloud> ;;cjs
11:04 < gribble> Coinjoin Status: There is no currently open session.
11:12 < Emcy> its a good start, but we know this all has to be completely transparent eventually if its going to make any real impact on the system
11:12 < michagogo|cloud> Emcy: AIUI, this isn't supposed to become what everyone uses, or make any real impact on the system
11:12 < michagogo|cloud> At least not as-is
11:13 < Emcy> this or CJ in general?
11:13 < Emcy> CJ absolutely has to work wide-scale, or something like it
11:14 < michagogo|cloud> Emcy: this
11:14 < michagogo|cloud> Not CJ in general, of course
11:14 < Emcy> the alternative is having such a powerfult technology as bitcoin turned against us
11:15 < Emcy> and im kind of sick of seeing civil society forge its own chains by accident
11:23 < nsh> we are bound by no faster iron than our flocksome follies and unfounded fear
11:52 < TD> i am rather skeptical about widespread coinjoining. small scale joining gives you a small modicum of deniability .... how much privacy it gives you is rather an open question at this point
12:00 < petertodd> Emcy: in the short term my main thinking is to use coinjoin with two-party-mixes as a way to thoroughly break the idea that transactions are authored by a single person. There's a lot of work to do beyond that, but breaking that assumption is a very important first step.
12:01 < petertodd> Emcy: e.g. naive two-party-mixes leak information with regard to the values on the txins and txouts, but subsequent efforts can help plug that leak by, for instance, using value-matching techniques where one party to the transaction delibrately matches the values of the other party's txouts
12:03 < petertodd> Emcy: this also ties into merge avoidance: if txins are not always merged into a single txout to make a payment you have a lot more flexibility in making coinjoins that don't give external observers useful information. equally that people are doing merge-avoidance with coinjoin means that even when you don't use that feature, transactions have solid plausible deniability
12:08 < petertodd> Emcy: example: I want to pay you, and you've told me you'll accept up to two txouts for that payment. I do a two-party CJ mix with someone who needs a specific output value, and I use one of those txouts to match their value, the other to send you the balance of the payment, and I have a third txout with my change.
12:19 < petertodd> Hmm... and come to think of it, rather than calling it "merge avoidance", the idea is better described as "merge flexibility" - the receiver of funds is saying "here's how many txouts I'm willing to accept, use that to better optimize how you merge the txouts you are using to pay me to balance privacy and cost per transaction". Using CoinJoin in conjunction with merge flexibility is a win because it lets you get away with fewer txouts - more ...
12:19 < petertodd> ... merging - at the same privacy level. In short, it's cheaper for a given level of privacy.
12:22 < Emcy> petertodd i fear it will take much more. Youre assuming rationality about how the system works.
12:23 < petertodd> Emcy: explain?
12:23 < Emcy> consider how bad IP addresses are for identifying individuals vis a vis the war on bittorrent
12:23 < Emcy> they do it anyway, no one seems to care much that they get it wrong all the time
12:24 < petertodd> Emcy: oh sure, don't get me wrong, I'm not saying this is easy. The fact that "merge avoidance" seems to have been proposed as a way to let blacklists still function shows how hard this will be.
12:24 < petertodd> Emcy: But we can only respond by making better privacy as cheap and easy as possible and trying to get as many people using it as possible.
12:24 < Emcy> it seems like you have to stop the idea that some sort of convenient data can ID a person and what they do before people get it into thier heads, never mind that it might be completely wrong anyway
12:24 < petertodd> Emcy: even blockchain.info's centralized coinjoin implementation is a huge win in that regard
12:25 < Emcy> thats why convalidation makes me worry even as it is now
12:25 < petertodd> same, but again, sitting around and complaining won't fix things.
12:27 < Emcy> do you really think mikes merge avoidance thing was really proposed specifically to let blacklists get a foot in the door?
12:27 < Emcy> I thought it was more CJ + merge thing complementing each others weaknesses
12:28 < petertodd> Emcy: yes. from the article on medium: "Merge avoidance doesn’t interfere with coin tracing."
12:28 < petertodd> Emcy: the original proposal was merge avoidance as a complete replacement for coinjoin; fortunately it complements coinjoin very nicely
12:29 < petertodd> Emcy: notably everything that makes merge avoidance possible to use without coinjoin can be re-used to use it with coinjoin.
12:29 < Emcy> can you link? I thought i read it. maybe that went right over my head
12:29 < petertodd> Emcy: https://medium.com/p/7f95a386692f
12:29 < petertodd> Emcy: it's at the bottom of the article
12:30 < petertodd> Emcy: the article is very misleading about coinjoin as well, giving lots of reasons not to use it
12:31 < Emcy> i really want to believe hes playing devils advocate like it was a 10 pence a go street fighter arcade cabinet in 1989
12:32 < petertodd> Emcy: FWIW merge avoidance isn't new either - the first time I heard of the concept was from adam back pointing out how pervasive merge avoidance gives privacy properties very similar to zerocoin. (if coins are always fixed in size)
12:33 < petertodd> Emcy: lol!
12:36 < Emcy> it just seems like there are quite a few people confusing pragmatism with submitting fully to the usual strictures requested on disruptive new techs without a fight
12:38 < Emcy> if you cant imagine something better than the way things basically already are with a new coat of paint then why the fuck are you here frankly.....
12:39  * nsh subscribes to Emcy's newsletter
12:39 < petertodd> lol
12:39 < Emcy> yeah i completely missed that last paragraph of that article somehow
12:40 < petertodd> Emcy: heh, the interesting thing is how that paragraph was in there in the first place - nicely transparent
12:40 < petertodd> Emcy: anyway, we're lucky that good solutions appear to exist; hopefully as they are implemented we don't find show-stopping problems
12:42 < Emcy> hopefully hes wrong about mergepurge being in lieu of coinjoin, and people realise they work better together...........but he might be right
12:43 < petertodd> the laws around this stuff are certainely still in flux
12:43 < Emcy> i have a heavy suspicion there are LOTS of people in bitcoin who would betray it utterly to The Man if it means the price keeps going up, which it preatty much will as long as its not banned or somthing
12:43 < petertodd> agreed
12:44 < Emcy> right, and if that happens then the uncomfortable conclusion is that every other shitty and irrational thing in the world is the way it is because it has to be, because we suck.
12:45 < Emcy> perhaps thats my projecting though
12:45 < TD> Emcy: it works for bittorrent because basically all IPs that participate in a particular torrent are all doing the same thing (i.e. violating copyright). you can't generalise from that to bitcoin.
12:46 < andytoshi> Emcy: a lot of people here are dimly aware that "bitcoin is decentralized" but simply cannot imagine anything else .. only recently have people started talking about this stuff like it's something normal people should be doing
12:46 < TD> i don't think my article is misleading about coinjoin. it balances other things that were written about it by pointing out some obvious problems.
12:46 < andytoshi> so we'll see an improvement as awareness increases
12:46 < TD> which were not being adequately covered elsewhere
12:47 < petertodd> TD: cj will be soon implemented without centralized servers, so you can correct that, you can also correct the long waits as the plan is to combine users who want txs to go through now with ones who are willing to wait
12:47 < TD> if/when those things happen i would amend the article. however it's not misleading to describe the world as it is now.
12:47 < andytoshi> TD's article also talked about how cj is not a panacea .. i agree, this was not really mentioned elsewhere
12:48 < petertodd> TD: coinjoin isn't implemented now, so talking about a theoretical bad implementation isn't honest
12:48 < TD> somehow you don't believe what genjix or blockchain did is coinjoin?
12:48 < petertodd> TD: note how bc.i's implementation uses techniques to negate most of those concerns
12:49 < petertodd> TD: genjix is a quick prototype. anyway, it's dishonest to talk about what merge avoidance might be unless you are willing to compare it to what coinjoin just as plausibly might be
12:50 < TD> i don't think there was any dishonesty in my article at all, it correctly reflected the issues that exist with implementing both approaches. but i'm tired of arguing about this. you will continue to paint me as dishonest and somehow part of a conspiracy regardless of what i write, because that's what you do.
12:50 < petertodd> TD: if you don't want to be painted as dishonest, then don't write stuff that leads to that conclusion
12:51 < TD> see? i haven't. it's just you.
12:51 < petertodd> TD: this conversation isn't going to be very productive for either of us
12:51 < maaku> TD: genjix and blockchain.info (and andytoshi's) are not the protocol described in gmaxwell's original posting
12:51 < TD> correct
12:52 < petertodd> maaku: yup. more to the point, coinjoin is a whole family of techniques, with different tradeoffs. I'm pushing two-party-mixes because I believe that the tradeoffs are useful, but other approaches (like yours!) have tradeoffs that make more sense in different circumstances.
12:54 < petertodd> TD: anyway, please do work on merge avoidance - as I say above it'll really help make coinjoin more useful
12:55 < TD> lots of other things to do first. like actually get the payment protocol launched and used.
12:58 < petertodd> TD: seems to me that a good first step would be to define an output range in the Output message in the payment protocol: "optional <something> amount_range = 3;"
12:59 < TD> well, you can do some merge avoidance with the v1 protocol as specified
12:59 < Emcy> TD no the point is that you cant link an IP to a person to any sort of acceptable evidentiary standard, for the act of infringment. But it happens anyway.
12:59 < TD> which is no surprise because i designed it that way from the start
12:59 < petertodd> TD: sum of all outputs must == sum of all amounts
12:59 < TD> Emcy: of course you can. Find a torrent that is for a movie. Find all participants in that Torrent. They're all distributing the movie. Open/closed case, right?
12:59 < Emcy> mainly because certain people WANT to beleive you can link people. And have paid to create that narrative. Same might happen with btc addresses
12:59 < petertodd> TD: specifying ranges is more useful for both straight merge avoidance and merge+cj by giving more flexibility
13:00 < TD> yes, it could be extended in future to do better
13:00 < petertodd> TD: if the amounts are all fixed it's harder to find a useful combo
13:00 < TD> i'd like to see a bip32 extension first though, for recurring payments.
13:00 < TD> Emcy: in many cases you can. ignore big aggregating proxies and go for consumer DSL. most people are downloading from home anyway. not very complicated.
13:02 < Emcy> open wifi, kids were doing it parents had no clue, ISPS fucked up the records, stupid torrent monitoring cottage industry company fucked up the records, sueing-people-as-a-business-model law firm fucked up the records. It all happens.
13:04 < TD> yeah, but they don't need "impossible to be anything else". even for criminal penalties it's just "beyond reasonable doubt"
13:04 < TD> for civil it's "balance of probabilities" (usually)
13:04 < TD> (depends on the country)
13:04 < Emcy> usually the civil standard, which fucking sucks anyway but thats another thing
13:05 < TD> well, it's intended for lighter weight disputes with lighter weight penalties
13:05 < TD> arguably even the civil standard is much too heavyweight for copyright enforcement
13:05 < TD> hence the focus in recent times on developing "three strikes" type rules for internet access.
13:05 < TD> not sure that's the right way to go but the idea of lighter weight justice isn't a bad one
13:06 < petertodd> Ah yes, the justice standard of "Yeah, you might have done something wrong, although we don't even have to prove it's more likely than not."
13:06  * TD shrugs
13:06 < TD> look at speeding penalties
13:06 < Emcy> yeah dont worry, the UK has law on the books that puts the standard at a simple accusation by one of these vampire torrent monitoring companies
13:07 < TD> the evidence comes from cameras controlled by the police. the punishment is a fine or points on your license. it basically works.
13:07 < petertodd> Speeding penalties are on a "more likely than not" standard.
13:07 < Emcy> cameras dont reduce harm. But they make money
13:08 < TD> yes, but emcy's argument would apply to them too. all it takes is an accusation from a trusted party, basically. you could come up with excuses (not me driving the car, etc), police could screw up records, etc.
13:08 < TD> people tolerate this laxity because the punishments are not very severe unless you keep doing it, or were doing it as massive scale
13:09 < Emcy> are you going to argue in favour of every thing that seems nifty on face but doesnt actually work and has side effects which are convenient for someone or other tonight?
13:09 < TD> Emcy: speed limits absolutely reduce harm, though, that's well documented
13:09 < petertodd> Anyway, all this suggests that we'll do well to get CJ implemented as widely as possible so it's "more likely than not" that a CJ user was using a standard Bitcoin privacy feature, and it's more likely than not that a given txin isn't owned by the person requesting a given txout.
13:10 < petertodd> It'll be interesting to see how governments respond of course, but we're certainly better off by starting with those principles.
13:10 < TD> well, the unfortunate possibility is that if bitcoin is perceived to be a significant enabler of abuse, it would just end up banned a la china
13:11 < TD> politicians and the people who vote for them are rarely interested in theoretically cool uses of the technology, like micropayments. they tend to focus on the here and now, and assign more importance to threats than benefits
13:11 < TD> or it just ends up de-facto blocked by other institutions that aren't governments, like now
13:11 < Emcy> petertodd right, we need to stop the idea of txid = person/action before it even takes root. It might be too late to do so after.
13:11 < Emcy> probably will be too late
13:11 < petertodd> It's also worth remebmer how if governments make the argument that CJ indicates you are trying to hide your tracks - an activity that doesn't cost you more in fees - then if anything merge avoidance - which does cost extra fees - seems even more damning.
13:12 < petertodd> "Your honor, the defendent paid $1000 USD over the course of the past two years to avoid merging transaction outputs; doesn't that sound like soomething someone with something to hide would do?"
13:13 < petertodd> Emcy: we won't know that it's too late until we try...
13:13 < TD> i guess it wouldn't work like that. merge avoidance is not intended to "hide your tracks". it just avoids information leaks about your balances or incomes.
13:14 < petertodd> TD: something coinjoin also does, but for less money
13:14 < petertodd> Cut-thru-payments are interesting in that respect, as they both reveal less information, and save money on fees. (potentially a significant amount)
13:15 < petertodd> Cut-thru-payments also really need a payment protocol with flexibile value range support, so I should do up a pull-req soon...
13:16 < TD> there's no point adding features to the protocol when no released wallet even supports the current set yet
13:16 < TD> it would be much more effective to implement some server software that would make it easy for people who don't want to rely on bitpay etc to use it
13:16 < petertodd> TD: all the more reason to do it now before the infrastructure is built
13:16 < Emcy> petertodd were pretty fucked if it becomes acceptable to argue that being proactive about your privacy at all is evidence of mens rea
13:16 < petertodd> Emcy: agreed
13:16 < Emcy> i think that might be the case here already actually though under RIPA. wouldnt surprise me
13:17 < petertodd> Emcy: at least with bitcoin the privacy issues are such that anyone in the world can violate your privacy - ugly
13:18 < nsh> Emcy, there's a good chance we'll see a RIPA test-case next year
13:18 < TD> in the USA they deleted the mens rea requirement from money laundering laws in the patriot act, unfortunately. so attempting to avoid red tape by breaking up payments can lead to ML convictions or asset seizure. pretty messed up.
13:18 < Emcy> yeah - that tinkles my tinfoil about bitcoin being the world currency of the NWO conspiracy......
13:18 < Emcy> lol
13:18 < petertodd> TD: right, which sounds like merge avoidance is legally risky
13:19 < TD> nope, not at all
13:19 < petertodd> TD: it's all about breaking up payments
13:19 < TD> you need to go read the laws i'm talking about before spreading more FUD
13:20 < Emcy> nsh for the encryption? Already been done. Coppers harassing a paranoid schizophenic man about his truecrypt container and telling him everyone will think hes a paedo of he doesnt give up the password
13:20 < Emcy> he didnt give it up and he did 2 and half years for it
13:20 < TD> structuring only applies when making deposits to an institution. breaking your own $100 bills is not structuring, for obvious reasons.
13:21 < petertodd> TD: I have actually, not going to claim I understood the legalize as well as I would like, but the chain of logic is easy to see, and fundementally the issue is that the law is interpreted by humans who tend to read the spirit of it.
13:21 < Emcy> of course if he really was a paedo the correct course of action from his point of view is to keep his mouth shut.........but logic and the law have never played nice
13:22 < TD> Emcy: well these problems are inherent the moment you define "information crimes"
13:22 < nsh> Emcy, well, i've been informally advised by the NCA to expect RIPA orders, possibly in six weeks, and am completely incapable of imagining a scenario in which i'll be even remotely inclined to entertain them
13:22 < petertodd> TD: what it comes down to is that if coinjoin is legally risky, the reasons why it would be are identical to why merge avoidance would be legally risky, with the additional risk that merge avoidance costs more than not doing it, which just plain looks bad
13:22 < nsh> and i am only marginally crazy and far less marginally resolute and resourceful :)
13:23 < TD> petertodd: which is the opposite of what you're doing - structuring rules are intended to stop people from trivially gaming the system to avoid reporting requirements. if there are no deposits to an institution there are no reporting requirements and thus no "structuring" is possible
13:23 < Emcy> nsh good luck bro
13:23 < nsh> thanks :)
13:24 < Emcy> i know someone else who is on bail right now because someone used his tor exit to harass women on twitter
13:24 < TD> petertodd: again, no. but i explained why not in the article. not going to bother going around this again.
13:24 < Emcy> theyve had all his shit for months and months
13:24 < petertodd> TD: exactly, and coinjoin *in that interpretation* isn't structuring either. But if courts take the broader interpretation that the "institution" is the blockchain itself - quite possible - then they're both possible to consider as structuring.
13:24 < TD> ah, i didn't say coinjoin was structuring. perhaps that's the source of confusion
13:24 < TD> i merely noted that mens rea is not a requirement any longer in the USA for AML conviction
13:24 < petertodd> TD: (this is pretty much a conversation I had a few weeks ago with a lawyer specializing in this stuff FWIW)
13:24 < Emcy> thats bail with no charge too, hes not charged (mainly because he didnt bloody do it)
13:26 < TD> Emcy: what if he did?
13:26  * TD thinks harassing people on twitter should not cause legal problems, but that's a different matter
13:27 < petertodd> TD: "If people’s privacy is being protected via other means, then CoinJoin becomes a “help thieves hide their stolen money” system which reduces incentive to take part, increases legal risk even further and would make people wonder why their wallet apps were asking them to pay fees simply in order to shield people whom they most likely think are bad." <- you say multiple times that coinjoin is legally questionable. I'm pointing out why ...
13:27 < petertodd> ... they both can be considered legally questionable.
13:27 < petertodd> TD: also, that quote is implying that coinjoin requires extra fees, which isn't true, so please fix that
13:28 < TD> merge avoidance doesn't help anyone hide stolen money, though. it is just irrelevant to that.
13:28 < Emcy> TD if he did then try him
13:29 < Emcy> but theyve charged others because they had actual evidence they did it, but not him because they dont and wont
13:29 < petertodd> TD: absolutely it does: it makes it harder to link thefts together to a single person, and in general makes it harder for people to link transactions together, making the job of investigators harder
13:29 < petertodd> TD: for instance it obscures the amount of funds moved per transaction, valuable information for tracing a theft and distinguishing it form other transactions
13:30 < TD> i don't think so, but we'll see.
13:30 < petertodd> TD: and again, please fix your article, if you don't then reasonable people would certainely conclude you are being delibrately dishonest
13:30 < TD> what is your rationale for saying coinjoin does not require extra fees? that you expect people to only do joins when they want to make a payment?
13:30 < TD> i have a feeling the term "coinjoin" has become overloaded to mean different things to different people
13:31 < TD> which makes it inherently hard to write about
13:31 < petertodd> TD: yes, that's what I've been proposing for pervasive two-party-mix support. and of course it means different things to different people: it's a bag of techniques - currently simple and automatic two-party-mixes is where development effort is being focused
13:31 < TD> i already pointed out the implementation difficulties with trying to do it "just in time", but i can clarify that last sentence to say it's explicitly talking about the asynchronous form
13:32 < Emcy> actually my little story about twitter harassment is another example of how fucked up things get when people just assume *convenientdigital ID* = a person and an action
13:32 < Emcy> IP address in that case
13:32 < petertodd> TD: then fix that. better yet, leave that off: as I say, merge avoidance costs more in fees so the comparison is rather odd
13:32 < Emcy> he even told them about exoneraTOR :/
13:33 < maaku> TD: I'd *really* like to see a bip 32 extension of the payment protocol
13:33 < TD> Emcy: which is correct for the vast majority of the time that people don't run Tor. I think Tor is a good example of what can go wrong with Bitcoin, really. the abuse keeps it small, which means the people who do choose to run it have bigger problems. a new parallel onion network that re-uses tor software but which requires anonymous IDs/passports to use and made it super easy for network operators to report/tackle abuse,
13:33 < TD> useful
13:34 < TD> maaku: yeah me too but again, after v1 is done :)
13:34 < petertodd> maaku: reminds me, a generalized standard for "here's how I want you to build the scriptPubKey" that could do things like bip32+multisig or ECDH stealth addresses would be useful
13:34 < TD> petertodd: fees are dominated by the inputs/outputs and as you note yourself, you need to use similar techniques for coinjoin to really work. so i am not convinced fees required would end up much different.
13:35 < TD> as the total number of inputs/outputs would be similar
13:36 < petertodd> TD: no, like I said above you end up needing fewer inputs and outputs because you achieve privacy by matching the other parties values. (or txin combinations) CJ gives you much more flexibility with how you expand your anonymity set.
13:36 < petertodd> TD: and indeed, just using CJ with no value match avoidance at all is cheaper in terms of fees, and stll provides some privacy benefit
13:37 < midnightmagic> it's possible to get merge-avoidance-like inputs by mining in p2pool with an address randomizer; i have also written a simple perl tool which builds rawtx. it looks like a few p2pool'ers are already doing a rudimentary form of merge-avoidance right now, which I've discovered is limited mostly by how many addresses payment-accepting people are willing to give me at once.
13:37 < maaku> ... and how much hashpower you have to throw at it
13:38 < nsh> TD: "anonymous IDs/passports.... super easy.... tackle abuse"   until the abuser gets a new anonymous ID, N minutes later, right? or do we have way of anonymously banning people on some effective and enduring basis these days?
13:38 < petertodd> nsh: you fidelity bond the ids
13:38 < nsh> oh okay, right anything's possible when you have to have money to play
13:38 < nsh> :)
13:39 < petertodd> nsh: you can also tie them to real-world passports or similar things with certain cryptographic techniques
13:39 < nsh> mm
13:39 < TD> nsh: right the whole idea is to make it expensive.
13:39 < TD> nsh: which is all banning IPs does anyway
13:39 < nsh> the problem is that what is a trifling loss to most people in the "developed world" is a substantial barrier to entry for everyone else
13:40 < TD> nsh: it doesn't help for the super serious stuff where you get your door kicked down because of something your IP address did, but tor kind of sucks to use because of all the low level abuse, not so much that stuff
13:40  * nsh nods
13:40 < TD> nsh: yeah. you could combine various techniques. like, use a SNARK proof that your e-Passport is from India, and then require a sacrifice that's much smaller as a result. but all this is quite advanced.
13:41 < nsh> right, i can conceive of such a hybrid system being somewhat universally and equitably applicable, but it seems quite far on the horizon atm
13:41 < nsh> baby steps, though :)
13:41 < TD> well, maybe a few years
13:41  * nsh nods
13:41 < petertodd> nsh: good example: decentralized CJ will most likely use tx fees as the anti-spam, which ahs the nifty security property that a sybil attacker has well-defined costs that can be reasoned about
13:41 < TD> for now an onion network only usable by rich people, is still better than one that's only usable by hard-core anonymity freaks who don't mind having a half-broken internet
13:42 < nsh> right (x2)
13:42 < petertodd> nsh: e.g. if tx fees were what miners lived on, and everyone used CJ, you could get security as good as the 51% security of bitcoin itself against sybils
13:42 < nsh> interesting
13:42 < TD> petertodd: ok i need to read more/ponder more about value matching as you describe, to understand your argument about fees being lower. once i get mentally awake enough to do that i will add a comment or update the article. actually if you have a twitter account you could also comment on that part of the article directly.
13:42 < petertodd> TD: cool
13:43 < nsh> could the bitcoin foundation provide a stipend to one of the people who makes those neat visualizations on e.g. informationisbeautiful to have the patience to sit with a technically-minded person and have something like CJ dynamics explained well-enough to illustrate graphically
13:43 < nsh> i feel the comprehensive enfranchisement of the bitcoin community would benefit drastically from such an arrangement
13:43 < Emcy> i dont think they want anything to do with anything like that
13:44 < nsh> well, some nice people with deep wallets :)
13:44 < petertodd> nsh: there is a catch though: what I proposed re tx fees isn't something anyone has figured out how to do perfectly, the best I've come up with is to attach nLockTime'd transactions to your CJ-related messages that pay fees in the future, which proves that you will either pay tx fees now spending those txouts, or they will be spent by the nLockTime'd tx, but that only applies to a single output
13:44 < nsh> hmm
13:45 < nsh> that's just an efficiency problem at worst though?
13:45 < petertodd> nsh: yeah, the technique approximates perfection :)
13:45  * nsh smiles
13:45 < petertodd> nsh: fancy crypto could probably help, but I try to avoid anything I can't explain to actual wallet developers :P
13:46 < nsh> wisely, i'd say :)
13:48 < TD> sucky parental internet
13:48 < nsh> andytoshi, are you still logging here?
13:49 < petertodd> nsh: his logbot died a little while ago today I thought
13:49 < petertodd> nsh: I've got logs
13:49 < nsh> aye, can't see it
13:49 < nsh> (was just in case TD/outpingers wanted to catch up their buffers)
13:50 < andytoshi> nsh: shit, no
13:50 < TD> i should set up an irc proxy again
13:50 < andytoshi> i didn't see it die
13:50 < TD> no matter
13:50  * andytoshi-logbot is logging
13:50 < petertodd> nsh: I really gotta get around to implementing decentralized IRC... lol
13:50 < andytoshi> thx, my perl script does not notice being unhooked for some reason, it is supposed to reconnect
13:50 < nsh> petertodd, didn't you have notes on that?
13:50 < petertodd> nsh: meh, I'll just write a whitepaper on it instead...
13:50 < nsh> aye, that's the way
13:50 < nsh> implementation is for grad-students
13:51 < petertodd> nsh: hehe, "My favorite programming language is English."
13:51 < TD> secure irc (not decentralised) exists, cryptocat
13:51 < TD> though not sure there's any point encrypting irc :)
13:51 < TD> of course it's not really irc
13:51  * nsh smiles
13:51 < nsh> what's the latency on pond?
13:51 < TD> high
13:51 < petertodd> nsh: high
13:51 < nsh> ok, nm
13:51 < TD> it's meant for email like uses
13:52 < nsh> right
13:52 < maaku> nsh: there's built in delays on pond
13:52 < TD> multi-user chat OTR like chat is what cryptocat is for
13:52  * nsh nods
13:53 < petertodd> nsh: anyway, the dark wallet guys are interested in doing it, but no specific timeline - cj is much higher priority, as is openpgp stuff for payment protocol/payment protocol-like stuff
13:53 < maaku> ok wizards, I'm trying to decide if the forward-diff, reverse-diff or both should be checkpointed in the utxo validation index proposal
13:54 < maaku> in addition to the committed root hash
13:54 < TD> grrrr. this time the irc app crashed
13:54 < TD> sigh
13:54 < petertodd> maaku: explain?
13:55 <@gmaxwell> nsh: I don't think anyone is using characteristic 2 for pairing, at least not in the open world... everything is using the 254 bit BN curve, which is on a prime field.
13:56 < maaku> my diff I mean what I called an "operational proof" in the previous BIP - a list of key,value pairs to insert/update, a list to delete, and paths through the merkle structures to accomplish that
13:56 < maaku> a forward-diff would take you from prevBlock to currentBlock (e.g. summarize the effect the block has on the index structure)
13:57 < maaku> a reverse diff is an undo block : take you from the current block to the previous block
13:57 < maaku> it should be possible to turn a forward diff into a reverse diff and vice versa
13:57 < nsh> gmaxwell, right. i think it's much closer to a curiosity than a catastrophy for the foreseeable future. but i don't know the math at all, so can't guess at the likelihood of eventual generalization of the technique
13:57 < maaku> since you have both the information being added (explicitly) and the information being removed (from the path)
13:58 < petertodd> maaku: so what's the use-case for those deltas?
13:58 < maaku> petertodd: well, a reverse delta could be used to recover from a reorg during pruned operation
13:59 < maaku> but beyond that, that's why I'm asking :)
13:59 <@gmaxwell> nsh: it's only like the Nth attack on characteristic 2 things, so I don't think any engineering-cryptographers (as opposed to theoretical-cryptographers) are the least bit excited by it.
13:59 < petertodd> maaku: but why does that need to be committed?
13:59 < petertodd> maaku: having explicit committed deltas would also make proving fraud even more complex, because now the deltas themselves may be fraudulent
14:01 < nsh> gmaxwell, the paper mentions "medium" characteristic too so perhaps there's some ground being made. dunno
14:01 < maaku> petertodd: a delta would give you a listing of the inputs spent just in that block though
14:01 < maaku> i know that's something you've advocated - is it still relevant if there is a committed validation index?
14:01 < nsh> medium appears to mean "3" though
14:02 < nsh> in which case practical applications should properly be described as employing fields of "unfathomable" characteristic :)
14:02 < petertodd> maaku: ah, good point. :) of course, I advocated *just* having the deltas
14:03 < petertodd> maaku: see, for a wallet syncing txs, they want to know two things: a new txout exists relevant to them, and a txout was spent that they owned
14:03 < maaku> another point is storageless mining / validation - the delta (forward in this case) provides the information you need to update mempool proofs
14:03 < petertodd> maaku: so if you only have deltas, you want both. if you have utxo + deltas, then you only need the "was spent" delta, the "is new utxo" is provided by the utxo set commitment
14:04 < petertodd> maaku: for memoryless operation you don't need to commit the forward delta: you provide it to update the UTXO set, and the fact that the forward delta applied to the existing UTXO set results in the new set is the proof
14:06 < maaku> which is what the forward delta is - it contains the relevant portions of the utxo set
14:07 < petertodd> maaku: yes, but my point is there is no reason to commit it
14:07 <@gmaxwell> nsh: I mean, ec with highly composite fields is subject to index calculus and is known insecure forever. People use "unfathomable" characteristic now in practice (this isn't to say that there aren't commercial characteristic 2 systems, there probably are…).
14:07 < petertodd> maaku: committing it just fixes the way it's designed in stone
14:08 < petertodd> maaku: and come to think of it, the same argument applies to the reverse delta: you're better off just proving to SPV clients that the UTXO still exists in the set for every block when it comes to showing them their utxo wasn't spent
14:08  * nsh nods
14:08 < petertodd> maaku: there's some size tade-offs here, but the difference isn't much and I'm very hesitent to make things more complex for a minor decrease in bandwidth
14:10 < maaku> petertodd: what about truly storageless nodes (which just keep the current merkle root + mempool + some temporary space for proof processing)?
14:10 < maaku> my thought was that by committing the reverse delta they can work backwards
14:10 < petertodd> maaku: again, there's no need to commit the deltas
14:11 < petertodd> maaku: they know the deltas are valid by the fact that the UTXO root matches after the deltas are applied
14:12 < maaku> ah, so I can just query the network "what's the delta from A to B?" and verify what I get back
14:12 < maaku> ok
14:13 < petertodd> yup
14:13 < petertodd> which means if we figure out a better way to describe the deltas, we can change that without a fork
14:13 < maaku> ok i had some fuzzy thinking - i was thinking they would query for proofs by hash (of the delta itself)
14:13 < maaku> but that's silly
14:15 < maaku> on another note, I had a complex mechanism for structuring the final txout of the coinbase transaction, but I don't think that's necessary
14:15 < nsh> mathematically, is there likely to be a "canonical" way of describing the difference in the utxo set structure? (modulo some symmetries that are orthogonal to security/accounting)
14:15 < maaku> here's an easy rule: if last txout starts with OP_RETURN, concat the remainder of the script with the coinbase string
14:17 < maaku> nsh: it's a weird question. there are arbitrary choices and tradeoffs made in choosing/designing a Merkle structure
14:17 < maaku> but it's definately a requirement that there exist a canonical form of that structure
14:17 < nsh> well, many of those choices will be fork-constrained, i'd imagine
14:18 < maaku> fork constrained?
14:18 < petertodd> maaku: whats the op-ret rule for?
14:19 < maaku> petertodd: you start stuffing Merkle roots in the coinbase string and you quickly run out of room and/or crowd out other uses
14:19 < petertodd> maaku: right, but, how does that rule help?
14:19 < maaku> and changing the size of the coinbase string is a hard-fork ... so overflow to the last txout
14:19 < maaku> also, allows midstate compression
14:19 < nsh> nm, i gtg sociability :) merriment to ye all
14:20 < maaku> nsh: happy holidays
14:20 < petertodd> maaku: the only thing in the coinbase that's consensus right now is the height, so I'd be inclined to leave that situation the way it is rather than add even more complexity
14:20 < petertodd> nsh: later
14:21 < maaku> nsh: when you come back, there's a long debate in the UBC thread about what structure to use for the index
14:21 < maaku> prefix trees were chosen because anyone could reconstruct the canonical structure without knowing the entire spend history
14:22 < petertodd> right, but with needing to know the entire UTXO set, and with the disadvantage that adding anything to the set requires having to have the entire set
14:22 < petertodd> (though you can outsource the storage to others)
14:23 < maaku> petertodd: in a series of bips I will be proposing committing three 256-bit hashes (validation index, wallet index, arbitrary data committment)
14:23 < petertodd> maaku: what's the validation and wallet indexes exactly?
14:23 < maaku> validation is txid -> CCoins
14:24 < maaku> wallet index is what I've been calling the address index: txid:n -> unspent txout
14:25 < maaku> sory, scriptPubKey:txid:n -> unspent output
14:26 < maaku> i find it easier to explain to muggles if I call them based on what they are used for: txid keyed index for blockchain validation, scriptPubKey:txid:n index for lightweight wallet apps
14:26 < petertodd> maaku: suggestion: explain in detail how some examples of compact proofs could be made for various frauds
14:26 < maaku> petertodd: will do
14:26 < petertodd> maaku: being able to prove fraud compacting is a huge use-case for all this stuff
14:27 < petertodd> maaku: for instance you do need a merkle-sum-tree in there for txin/txout values
14:28 < maaku> petertodd: yes, both indices have nValue summation in the "extra" field
14:28 < petertodd> maaku: and while a bit less efficient, I'd be very inclined to ensure that tree must be distributed as part of some other use-case so we don't get into a situation where nodes stop passing it around
14:28 < petertodd> maaku: good
14:29 < petertodd> maaku: also, it should be easy to prove part of a transaction exists, IE, I shouldn't need the whole tx to just prove a single txout existed in it
14:30 < petertodd> maaku: now I guess  scriptPubKey:txid:n -> unspent output works for that, but there needs to be something similar for the scriptSig case too - txid -> CCoins would probably better be txid -> merkle tree of txins + merkle tree of txouts
14:30 < maaku> petertodd: can you elaborate? I'm using a modified version of sipa's CCoins data structure which is basically metadata + compressed unspent outputs
14:31 < maaku> i see
14:31 < petertodd> maaku: suppose I have a 100KB transaction, can I prove it had a txout with a specific form without providing the whole transaction?
14:32 < petertodd> maaku: that txid tree is the perfect place to sum fees too: sum all transaction inputs and outputs, sum that, then sum all tx fees
14:32 < maaku> yes you'd only be providing the compressed outputs (33 bytes * number of unspent outputs, if they are standard form, plus a few bytes metadata)
14:32 < petertodd> maaku: but that's the thing, # of unspent outputs can be very large, leading to a large proof
14:33 < petertodd> maaku: I'm also extremely reluctant to make the CCoins compression a consensus thing - it's very likely standard transaction forms will change in the future
14:34 < petertodd> maaku: much simpler is just to commit to the uncompressed forms, and do compression (if warrented) as a optimization for the on-disk format
14:34 < maaku> petertodd: I would find that compelling if it weren't for P2SH
14:34 < petertodd> maaku: and for that matter, for the on-network format too
14:34 < petertodd> maaku: P2SH may change in the future
14:35 < petertodd> maaku: like I say, if you don't commit to the exact compression format that doesn't stop you from using one anyway
14:35 < maaku> yes that is true
14:36 < maaku> i'm already considering a different hash format for gmaxwell's SNARK concerns
14:36 < phantomcircuit> SNARK
14:36 < phantomcircuit> how do you people come up with these names
14:36 < maaku> well not different, just expanded with fields having fixed width and fixed offsets
14:36 < petertodd> maaku: another interesting issue is that if this is a pure UTXO thing, then we don't have any committment to OP_RETURN data, which shuts out a lot of valid applications for it where a per block index of that data would be very useful
14:37 < maaku> phantomcircuit: the quality of your acronym determines your funding when government research dollars are at stake, alas
14:37 < petertodd> maaku: e.g. my stealth address stuff
14:37 < phantomcircuit> maaku, lol
14:38 < petertodd> maaku: suppose we find we picked the wrong hash format, what's the plan? that consideration should be documented
14:38 < phantomcircuit> tbh my donations are largely based on hilariousness of acronyms
14:38 < petertodd> phantomcircuit: PHANTOMCIRCUITISADICKHEAD
14:38 < phantomcircuit> lol
14:39 < phantomcircuit> petertodd, im going to hack you and steal all your research funding
14:39 < phantomcircuit> see whose laughing then!
14:39 < petertodd> phantomcircuit: IGTHYASAYRF <- that's not even pronouncable, lame
14:40 < maaku> petertodd: so one advantage of committing to a compressed serialization format (for network and disk at least) is the ability to distribute the UTXO set and get a validating node online quickly, then move backwards validating to genesis
14:41 < maaku> --
14:41  * maaku is thinking
14:41 < petertodd> maaku: but that's not true: you can just as equally commit to the uncompressed format and pass around compressed data
14:41 < petertodd> maaku: the only advantage is that the amount of data being hashed is less, but compressed-vs-uncompressed is a tiny difference
14:42 < maaku> petertodd: yes, but the compression may not be lossless (pruning of spent data)
14:42 < phantomcircuit> even if you're using a proper custom dictionary you're not going to get more than about 15% compression
14:42 < petertodd> maaku: huh? I'm talking about CCoins compression here
14:42 < maaku> CCoins does not contain spent outputs
14:43 < maaku> that's what I'm talking about
14:44 < petertodd> maaku: right, but then you're talking about TXO vs UTXO sets
14:46 < petertodd> maaku: if you work with a full UTXO set, there's not much of a difference between the two - the TXO version needs some extra data to fill in the missing parts of the tree, but we're talking about a log(n) difference
14:48 < petertodd> maaku: you can also get up and running faster with a TXO set, as you can grab the UTXO's that are most likely to actually get spent first, reservingthe less likely ones for later (or never bothering)
14:58 < Emcy_> http://www.bbc.co.uk/news/technology-25506020 i cant believe this is the first exposure thousands of people will have to the concept of public key crypto
18:57 <@gmaxwell> oh good, there is now a storage spam coin: http://datacoin.info/index.php?id=index
18:58 < CodeShark> haha
18:59 < nsh> cryptocurrencies: fuzztesting the fascade of economic rationality since 2008
18:59 < BlueMatt> heh
19:00 < CodeShark> we're about to see an avalanche of alt coins - it has barely even begun
19:00 < BlueMatt> seems like there is a business model in double-spending tiny coins and breaking these exchanges that allow you to trade literally anything...
19:02 < sipa> we should really release a tool to generate your own altcoin source...
19:02 < CodeShark> I've been thinking about that - an alt coin wizard
19:02 < CodeShark> :)
19:03 < CodeShark> set the chain params, set the name/datadir, set the pow hash function - and poof
19:03 < CodeShark> also, set the block reward rule and the retargetting rule
19:03 < CodeShark> I think that pretty much covers it, no?
19:03 < BlueMatt> sipa: Ive heared that from like 10 people...
19:04 < nsh> there was a coin that had all the generally-tweaked parameters pulled out into a config file
19:04 < BlueMatt> make lots of nice sliders and checkboxes so you can make your own alt that is designed to fail miserably under load
19:04 <@gmaxwell> nsh: it's not the tweaking that needs help, half the wannabe altcoin makers can't even compile it.
19:04 < nsh> well, aye
19:04 <@gmaxwell> so the thing has to do all the technical stuff for you.
19:05 < nsh> "The difficulty is already at 10 so I basically missed out on mining it already I'll probably launch another coin tomorrow" --https://bitcointalk.org/index.php?topic=380683.0
19:05 < CodeShark> well, gmaxwell, the wizard could also create a virtual machine that builds it as well as a website to promote it :p
19:06 < nsh> just monitor knowyourmeme or whatever equivalent to see the latest crazy and autotheme
19:06 < CodeShark> for full generality, the hash function as well as the block reward and retargeting rules would have to be dynamically loadable
19:06 < sipa> dynacoin
19:06 < Luke-Jr> 1nshahahaha
19:07 < sipa> launch new module -> hardfork
19:07 < sipa> Luke-Jr: 1ns hahahaha?
19:07 < sipa> that's a short laugh
19:08  * nsh smiles
19:09 < CodeShark> rather than requiring separate builds for different parameters, I prefer dynacoin :)
19:09 < CodeShark> set the chain params via config file and use dynamic linking for hash pow function
19:09 < BlueMatt> holy shit, these exchanges take literally all the diff-1 altcoins...I'd bet a ton you could double-spend them and just break the exchange software so easily...
19:10 <@gmaxwell> CodeShark: virtual machine?! wtf. You mean, "OP_JMP_TO_THIS_CODE"
19:10 < CodeShark> we don't need separate builds for each
19:10  * sipa suggests OP_X86
19:10 < CodeShark> hehe
19:10 < petertodd> sipa: ah yes, rootcoin
19:11 < sipa> also, OP_SUDO
19:11 <@gmaxwell> rootcoin can only be run as root.
19:11 <@gmaxwell> (it's to make it more fair)
19:11  * petertodd really needs to release an alt-coin that scans your hard-drive for wallet.dat files and uploads them to the P2P network
19:11 < sipa> petertodd: mines them into the blockchain, you mean
19:12 <@gmaxwell> pretty sure its been done.
19:12 < nsh> eeep
19:12 <@gmaxwell> well not the blockchain part
19:12 < petertodd> sipa: kinda obvious, but why not
19:12 < petertodd> anyway, namecoin is a perfectly good datacoin given that IsStandard() is disabled...
19:16 < CodeShark> there clearly are applications to decentralized data storage using some spinoff from bitcoin - but it feels like we're missing a second structure, besides the blockchain
19:16 <@gmaxwell> yea, but you don't have to feel bad about spamming this one.
19:16 < petertodd> gmaxwell: I thought feeling bad was a pow function to limit spam
19:16 <@gmaxwell> CodeShark: by itself some blockchain thing is not really useful for that.
19:17 < CodeShark> gmaxwell: right, we need a second decentralized structure and a mechanism that compensates people for providing storage resources on the network in the coin that is generated in the block chain
19:17 <@gmaxwell> petertodd: I mean, say you find some really _epic_ way to break namecoin with spam... you couldn't take credit for it without people being mad at you, so no sense in looking for one.  This thing, otoh, I think is free target.
19:18 < CodeShark> if only we had a reliable time-lock encryption mechanism :)
19:18 < petertodd> gmaxwell: true
19:19 <@gmaxwell> CodeShark: I think you can make POW into ticking for timelock encryption. Maybe.
19:19 < petertodd> CodeShark: gmaxwell has a coin for that
19:19 < CodeShark> petertodd: yeah? :)
19:19 < CodeShark> actually, I should be asking gmaxwell
19:20 < petertodd> CodeShark: basically you make the pow be breaking a timelock crypto problem, devils in the details though...
19:20 <@gmaxwell> CodeShark: the idea is just that you make the system generate random instances of a hard problem sutable for asymetric crypto, and POW is attacking those random instances.
19:20 <@gmaxwell> Doing it with discrete log in ec groups isn't great though because rho is not progress free.
19:21 < sipa> 01:16:41 < petertodd> gmaxwell: I thought feeling bad was a pow function to limit spam   -> if only it converged
19:21 <@gmaxwell> hahah
19:21 < petertodd> lol
19:21 <@gmaxwell> guiltcoin
19:21 < CodeShark> lol
19:22 < sipa> PoG
19:22 < petertodd> sipa: cryptographically signed court records are gonna make this one easy...
19:23 <@gmaxwell> CodeShark: in any case, I do think that timelock crypto ticking for pow is possible, though the details may make it a bit messy.
19:23 < petertodd> sipa: one murder per block
19:23 < petertodd> sipa: gives new meaning to the term "orphan"
19:23 < CodeShark> gmaxwell: do you have anything written up on the topic somewhere?
19:24 <@gmaxwell> https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas   search for timelock
19:24 < sseehh_> Occupy Bitcoin http://www.ingenesist.com/general-info/occupy-bitcoin.html What if Everyone Was a Bitcoin? http://www.ingenesist.com/general-info/what-if-everyone-was-a-bitcoin.html Curiosume: The Resume Must Die http://www.ingenesist.com/general-info/curiosume-integrating-social-innovation.html http://curiosume.org
19:25 < CodeShark> ah, I should check that page more often :)
19:25 < petertodd> gmaxwell: last update oct 18th? you been slackin'
19:25 < CodeShark> yeah, I guess so :(
19:26 <@gmaxwell> CodeShark: thats been there since the start. Actually the timelock idea might have been what inspired me to actually make a page for that stuff.
19:26 < CodeShark> haha, ok - then I guess I never really read through it all
19:27 < BlueMatt> sseehh_: spammer go away (gmaxwell...stop slacking)
19:27 <@gmaxwell> Wow, I didn't even see that.. was totally invisible to me.
19:31 < sipa> you're just dropping packets with insufficient proof of intelligence
19:32 < sipa> perfectly normal behavior
19:32  * nsh smiles
19:32 < CodeShark> so with a timelock, we can now rent storage space by giving people an encrypted data packet along with a key they can use to claim some coins
19:33 < CodeShark> yes, the devil's in the details - but in principle this should work
19:34 < petertodd> CodeShark: no, the idea is if the pow is a timelock algorithm your data is safe from pre-mature decryption on the theory that any attacker would earn more by cracking the timelock pow instead
19:35 < petertodd> CodeShark: in short, your data is safe so long as it's worth less than the total value of the timelock crypto system
19:35 < CodeShark> yes, I understand that - just pointing out another application
19:35 < petertodd> CodeShark: true, I guess you could do a timelock scheme with data storage bolted on as well
19:35 <@gmaxwell> CodeShark: hm. interesting. So I give you data, and a zero knoweldge proof that later you'll be able to decrypt the data and get coins out of it... with some large block encryption so that you can't throw away any of it.
19:36 < CodeShark> gmaxwell: exactly
19:36 < petertodd> CodeShark: see, that works well with standard timelock crypto
19:36 <@gmaxwell> I think I know how to do that without timelock crypto.
19:37 < CodeShark> how?
19:37 < petertodd> CodeShark: just put funds in a multisig spendable by the timelock cracker and the enclosed key, with a nLockTime'd refund in the future
19:37 <@gmaxwell> Take the data. Build a hashtree over it. The coins pay to the hashtree. Later, you can claim the coins if and only if you can produce a proof that looks like H(future block || data hash root) == index, and the spv proof of that index is the thing you must provide to get the coins.
19:37 <@gmaxwell> basically the network is the interactive party in proving you still have the data.
19:39 <@gmaxwell> gee imagine the amazing things these altcoins could do if they only bothered to think about the problem space for what..  10 minutes?
19:40 < CodeShark> gmaxwell: interesting!
19:40 < CodeShark> you'd also have to prove availability, though - not just that you have it at time T
19:41 < CodeShark> at least if you want random access
19:41 < nsh> (perhaps their conception of problem space occupies a different domain [e.g. how do i become important and make money and advance my position] than ours [how can we make advances in the theory and practice of various interesting and socially-beneficial problem-sets])
19:41 < petertodd> nsh: tl;dr: they're stupid
19:41  * nsh nods
19:43 < petertodd> I don't think the interesting alts out there are based on mining anyway - mining is just too insecure when you're trying to start a new alt.
19:43 < petertodd> Either your alt matters so little it hasn't been attacked, or it starts to matter and it gets killed off.
19:44 < nsh> it should be possible to create an alt with an tapered creator mining advantage, i'd think
19:44 < CodeShark> I have a slightly different view on alts - yes, the vast majority of blockchain-based alts out there are cheap imitations of bitcoin…however, I like the idea of affording some flexibility in certain coin parameters
19:44 < nsh> that way you have a more smooth / less dangerous incubation period
19:44 < petertodd> nsh: then it's centralized
19:45 < CodeShark> we might as well just do dynacoin :)
19:45 < nsh> sure, but you can taper the centralization off algorithmically, maybe?
19:45 < nsh> perhaps my intuition is being seasonally optimistic
19:45 < petertodd> nsh: sure, although to do it right it can't be algorithmically or you may find the schedule was wrong
19:45 < nsh> ah, right
19:45 < nsh> though if you define the parameters for safe coin incubation well-enough...
19:46 < nsh> you could target the decentralization
19:46 < nsh> (dynamically)
19:46 < maaku> nsh: how do you measure decentralization?
19:46 < nsh> not sure. i was wondering that recently...
19:46 < petertodd> well, you just make it that you the creator get to sign statements allowing more decentralization as a one-way rachet
19:46 < nsh> ah, yeah
19:47 < nsh> so a certain (set of) key(s) has a mining advantage, that can only decrease with some broadcast signal
19:47 < petertodd> nsh: yup
19:47 < nsh> mmm, dunno, sensing implementation difficulties the more i think about it
19:47 <@gmaxwell> CodeShark: well you could do something like prove you have it at _every_ block, and then to later spend the coin produce a snark that compresses all the proofs.
19:47 <@gmaxwell> hm. well I suppose thats not quite right, since you could have only had it at the end.
19:47 <@gmaxwell> Well in any case, it's better than doing nothing.
19:48 < CodeShark> gmaxwell: right, that's the problem
19:48 < maaku> nsh: you could lower the difficulty by the percentage of proof-of-stake signatures a block has
19:48 < petertodd> nsh: nah, no difficulties there: the signature is a substitute for PoW. you being the creator you'll use it responsibly; obviously you can play games and destroy things with that power too
19:48 < maaku> then an itsy bitsy premine gives you an advantage that slowly tapers off
19:48 < CodeShark> gmaxwell: to prove availability at a particular time, wouldn't you need to provide a challenge at that time?
19:48 < BlueMatt> CodeShark: though flexibility in researching optimal parameters is cool, a) there are more interesting things to research, but, more importantly, b) by just forking Bitcoin and creating an alt, you decrease the value of the digital scarcity that defines Bitcoin
19:48 < BlueMatt> 's value
19:49 < nsh> hmm
19:49 < sipa> meh
19:49 < sipa> i don't care
19:49 < CodeShark> BlueMatt: whether or not it decreases Bitcoin's value, it is an inevitable phenomenon - therefore, if Bitcoin cannot withstand it, we have a serious problem
19:50 < BlueMatt> I find that argument ridiculous: "its inevitable, so we shouldn't try to prevent it and should instead fully support it!"
19:50 < BlueMatt> makes no sense to me
19:50 < maaku> BlueMatt: I don't this is zero-sum. Stupid people throwing stupid money at alts aren't necessarily going to speculate on bitcoin instead
19:50 < CodeShark> the exact same features that make Bitcoin so difficult to stop applies to any of these alts
19:50 < sipa> support?
19:50 < nsh> BlueMatt, i'm not sure i follow how more (of any kind of) cryptocurrency decreases the scarcity... isn't the scarcity defined relative to the utilization of mining resources?
19:50 < petertodd> BlueMatt: well, here's an interesting thought question: if I create BTCv2 that is just transactions embedded in BTCv1 with a fancy new scripting system, what happens? BTCv2 transactions still need to pay fees in BTCv1, and I can design my scheme that both are 1:1 convertible (by allowing v1 to be destroyed to create v2)
19:50 < BlueMatt> maaku: oh, I'm not saying its zero-sum, I'm saying that its not independent, and far closer to zero-sum than independent
19:51 < nsh> so if more people mine alts that wouldn't be mining btc, then you've dilution, but if that mining power is not diverted but added...
19:51 < BlueMatt> petertodd: fuck mastercoin ;)
19:51 < BlueMatt> nsh: no, its defined as relative to the number of people interested in cryptocurrencies
19:51 < petertodd> BlueMatt: hehe, I have a lot of incentive to make such a thing work...
19:51 < sipa> petertodd: ??
19:52 < BlueMatt> nsh: mining isnt the important part to me, but it is as well
19:52 < BlueMatt> sipa: petertodd works for mastercoin.....
19:52 < sipa> heh?
19:52 < petertodd> sipa: I am mastercoin's chief scientist now...
19:52 < sipa> wtf?
19:52 < nsh> BlueMatt, hmmm. question is then how the elasticity of coin interest responds to the proliferation of alts
19:53  * Luke-Jr notes MasterCoin was offering a very low salary :P
19:53 < nsh> i suspect it's pretty nonlinear
19:53 < petertodd> sipa: I had decided I was going to quit the day job, and then by good luck they offered me a job at the same time
19:53 < petertodd> Luke-Jr: meh, salary isn't everything
19:53 < BlueMatt> petertodd: in any case, if a coin is 1:1 trade-able for bitcoin, and mined on its own chain (I agree currently merged-mined isnt very good, but I think we should work on making that more accessible instead of saying lets put shit on the chain) I fully support it as awesome fucking research
19:54 < BlueMatt> nsh: I disagree very highly
19:54 < nsh> then you're probably right :)
19:54 < petertodd> BlueMatt: well, what's interesting is how much data do you actually need in the chain? data-hiding is a serious issue, but maybe you can make the incentives to not hide data and/or recover from lost/hidden data. (see zookeyv)
19:54 < Luke-Jr> petertodd: it isn't, but does Mastercoin really offer anything more? :P
19:54 < BlueMatt> nsh: heh, I'm by no means a wizard, even if I do hang out here :p
19:54 < petertodd> BlueMatt: if everyone played nice timestamping would just be enough
19:54  * nsh smiles
19:55 < CodeShark> if everyone played nice we wouldn't need currencies :p
19:55 <@gmaxwell> CodeShark: I suppose that it just reduces to the storage throughput stuff on the altcoin page as one way of showing you have it at all times.
19:55 < Luke-Jr> CodeShark: not sure I agree
19:55 < petertodd> Luke-Jr: well, for me it's about the pay-per-hour-of-studying-cryptocurrencies, and mastercoin's offering full-time crypto-coin studying :)
19:55 <@gmaxwell> e.g. instead of paying you just make storage a byproduct of mining.
19:55 < Luke-Jr> petertodd: is that really all they expect of you?
19:55 < CodeShark> Luke-Jr: or at least, we wouldn't need currencies that are deliberately scarce
19:56 < petertodd> Luke-Jr: mastercoin is roughly speaking a blank slate, so roughly speaking yes
19:56 < maaku> BlueMatt: "merged mining isn't very good" -- because of the security risk of diluting the reward function?
19:56 < BlueMatt> petertodd: well, instead of working on fun cryptocurrencies problems like scaling, you've ended up working on how to best hide data in coins not designed for it...
19:56 < BlueMatt> instead of designing for it
19:56 < petertodd> BlueMatt: yes, but once you accept that as your model... then obviously you should work on scaling
19:57 < BlueMatt> maaku: because if you make a new researchcoin today, getting it merged-mined by enough mining power isnt a trivial problem, mostly
19:57 < petertodd> BlueMatt: see, if mastercoin is merge-mined, there's no reason to work on making bitcoin scale better, but if mastercoin isn't merge-mined and is embedded in the blockchain, then there's every reason to make bitcoin scale better
19:57 < nsh> scaling is a solved problem. we just all have to trust random people we've never spoken to in strange countries with unknown interests. cf. BGP
19:58 < nsh> , GRX, &c.
19:58 < CodeShark> I do not agree with the notion that the bitcoin protocol is a general low-level protocol - if we really want to build a network like that, we should design a low-level blockchain-based protocol (for, say, timestamping)
19:58 < CodeShark> without attaching anything else to it
19:59 < CodeShark> it should be completely agnostic as to the contents of data packets
19:59 < petertodd> CodeShark: I suspect we're going to end up with that, and specifically, the magic word is "proof-of-publication"
20:00 < maaku> CodeShark: and that's a problem?
20:00 < CodeShark> furthermore, proof-of-publication doesn't require all the data contents to be stored on the blockchain itself
20:00 < BlueMatt> petertodd: my view: ignore all non-btc-denominated cryptocurrencies: they all need to die and should be treated as shit anyway. after you do that, you have to somehow make the total throughput of btc-denominated transactions scale, that can come in the form of alts that are on their own btc-denominated chain or however you want, the whole system has to scale
20:00 < CodeShark> hashes would be sufficient
20:01 < CodeShark> we could completely separate the data storage/query mechanisms from the timestamping mechanism
20:01 < petertodd> CodeShark: no it does: if it's not in the blockchain there's no proof anything was in fact published. that siad, the existing bitcoin system is kinda weak on that respect...
20:01 < nsh> petertodd, there are different (but overlapping) use-case sets for proof-of-existence and proof-of-publication
20:01 < petertodd> CodeShark: the ideal might be some pow function that forces you to prove you have access to some data set, but that's not what we have
20:02 < BlueMatt> petertodd: if it were easier to get mastercoin merged-mined (eg to the scale of namecoin), and you can do 1:1 exchange to a secondary chain, do you not agree mastercoin /should/ be on a separate chain at that point?
20:02 < CodeShark> ok, yes, I get the distinction now between proof-of-existence and proof-of-publication
20:02 < nsh> also publication might have gradations, as not everything is published to *
20:02 < petertodd> BlueMatt: if you can wave a magic wand and get it to reasonable hashing power, lovely, but there is no such magic wand so I can't advise them to do that
20:02 < petertodd> BlueMatt: more likely I'd get there by designing a good merge-mined proof-of-publication scheme
20:03 < BlueMatt> ok, so our disagreement is how hard it is to get merged-mined a new coin
20:03 < CodeShark> besides the fact that mastercoin represents extra blockchain bloat, I'm also concerned about the unpredictable nature of block intervals…and the average length of that interval
20:04 < petertodd> BlueMatt: pretty much, and there's lots of ways forward: IE if I managed to find a way to make bitcoin tiself scale in some unspecified way, then mastercoin dumping data on the blockchain wouldn't matter
20:04 < CodeShark> 10 minutes on average doesn't seem like sufficient granularity for a lot of things
20:04 < sipa> petertodd: better != infinitely
20:04 < petertodd> CodeShark: given the selfish mining stuff I think we're going to find that 10 minutes was optimistic...
20:05 < petertodd> sipa: my suspicion is there is a fundemental security and scalability tradeoff with proof-of-publication, so you'll wind up with some scheme that lets you make choices about that tradeoff - pay more for more secure coins
20:05 < petertodd> sipa: txout storage fees based on value are nice there, but they change economics...
20:05 < sipa> very much so
20:06 < CodeShark> shouldn't the storage fee be based on size, not value?
20:07 < petertodd> CodeShark: NO, based on value because more value needs more security needs wider spread holders who actually have the data
20:07 < CodeShark> ah, ok
20:07 < andytoshi> if we used a base-1 encoding, we could make size and value be the same
20:07 < andytoshi> am i a wizard yet?
20:07 < petertodd> CodeShark: e.g. Suppose I want to destroy all (public) copies of some blockchain data, in the Bitcoin system that's going to be extremely hard, roughly a 51% attack, but if bitcoin mining was sharded such that you could mine with 1/8th of the blockchain data, you'd wind up with a system where you may be able to do a 51% * 1/8th attack instead
20:08  * petertodd gives andytoshi a robe and pointy hat
20:08 < maaku> why not put mastercoin on namecoin?
20:08 < maaku> or hey, devcoin or ixcoin
20:08 < CodeShark> right, I get it now, petertodd
20:08 < petertodd> maaku: why bother? it's not mastercoin's problem that it crowds out other uses of the blockchain
20:09 < CodeShark> the fundamental problem here, IMO, is the misplaced incentives
20:09 < petertodd> CodeShark: agreed
20:09 < CodeShark> there are no rewards in the bitcoin network for providing storage nor for relay
20:09 < maaku> petertodd: just pointing out that there are other merged mine chains with high hash rates
20:09 < petertodd> CodeShark: especially with regard to the UTXO set...
20:09 < maaku> i actually think that it is perfectly fine to put whatever you want on the block chain
20:10 < BlueMatt> petertodd: well, I find the difficulty of getting a real research coin merged-mined to be a problem that needs solving, so I'd argue that you (as someone paid to work on this) should work on fixing that problem instead of working on hiding shit in the chain so that people cant block it
20:10 < maaku> and if anyone has a problem with that ... it's your own damn fault for not coming up with and implementing a better fee system
20:11 < petertodd> BlueMatt: meh, I think I've basically solved the "hide shit in the blockchain" problem very thoroughly, something we need *someone* to have done if only to understand the risks
20:11 < sipa> without fees going to those providing the storage that is wasted, the incentives can't align
20:11 < petertodd> BlueMatt: note I also have a half-decent solution to UTXO bloat, so it's not like it's the only thing I've been working on
20:12 < maaku> sipa: and fees can't go to those providing the storage because ... ?
20:12 < andytoshi> i think there is always an incentive for people to put stuff on the blockchain, it's not their problem ... so it's up to bitcoin to figure out pruning strategies
20:12 < maaku> not saying it's easy, but also no one's shown it impossible
20:12 < CodeShark> petertodd: I'd love to see some of those implemented :)
20:12 < sipa> maaku: well, i wouldn't call it bitcoin anymore in any case
20:12 < petertodd> maaku: modulo utxo bloat, the existing fee system works just fine: really we've got people whining that they aren't getting cheap transactions because something else can afford a higher fee/byte
20:13 < petertodd> CodeShark: heh, well actually I've got an unreleased upload-files-to-the-blockchain tool that makes them into a shared consensus namespace... add timelock crypto to it and you'd have a rather frightening system
20:14 < petertodd> CodeShark: fortunately $0.1/KB is kinda pricey, and it's even higher if you want to hide in normal-looking transactions
20:15 < CodeShark> petertodd: I also wrote a tool once to upload arbitrary text (base58 encoded) to the blockchain :)
20:15 < CodeShark> I'm only guilty of using it a few times :)
20:15 < andytoshi> there is a rickroll somewhere in testnet (i have the command to play it, but not on me right now)
20:15 < petertodd> CodeShark: heh, it's not rocket surgery... although I think the trick is the retrieval side of things so people find it useful - hence my shared consensus namespace thing
20:15 < andytoshi> i think one of you guys did that
20:16  * petertodd looks guilty
20:16 < andytoshi> i thought it was petertodd, didn't want to accuse since i wasn't sure :P
20:16 < CodeShark> lol
20:18 < nsh> j'accuse!
20:18 < nsh> (best chess move)
20:19 < petertodd> andytoshi: heh
20:19 < petertodd> andytoshi: everytime someone claims bitcoin scales I edge a little closer to releasing the upload tool :P
20:19 < CodeShark> haha
20:19 < CodeShark> petertodd: someone uploaded the source code for a python tool to upload arbitrary data
20:19 < CodeShark> it's still somewhere in the block chain
20:20 < petertodd> CodeShark: yeah, they fucked that one up though because strings blk*.dat wasn't cut-n-paste-able
20:20 < petertodd> CodeShark: cute though
20:21 < CodeShark> the retrieval tool shouldn't rely on the blk*.dat files at all
20:21 < CodeShark> retrieval should be possible via p2p protocol
20:21 <@gmaxwell> petertodd: see, you don't need an upload tool.. you just need datacoin.
20:21 < petertodd> CodeShark: no, I just mean that bootstrapping it was tough because you had to decode the tx containing the tool yourself
20:22 <@gmaxwell> it has the tool built in.
20:22 < petertodd> CodeShark: well that's a fun one: you can easily design this stuff to be SPV compatible re: bloom filters
20:22 < petertodd> CodeShark: even easier if someone implements prefix filters
20:23 < CodeShark> right
20:26 < petertodd> gmaxwell: it's always a trade-off between fees and security of your data...
20:27 < CodeShark> well, wrt txout bloat, the most sensible "wizards" solution seems to be to decrement the output value as a function of age until it drops to zero, at which point it is unspendable
20:28 < petertodd> CodeShark: MMR TXO commitments shift storage to wallets (roughly speaking)
20:28 < CodeShark> MMR - not sure I'm familiar with that acronym
20:29 < petertodd> CodeShark: merkle-mountain-range
20:29 < CodeShark> how does that work?
20:30 < petertodd> CodeShark: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194
20:31 < petertodd> CodeShark: there's some ugly issues re: bandwidth storage tradeoffs however - given that miners don't actually have an incentive to broadcast their blocks to >%30 of hashing power there can be incentives to make blocks full of UTXO spends that are ancient that no-one has cached
20:32 < petertodd> CodeShark: but that's a general problem...
20:34 < CodeShark> ah yes, interesting stuff. it's too bad the forums are so cluttered with garbage…on occasion you do find good reads. I suppose I could filter by author :)
20:34 < petertodd> CodeShark: heh, well my fault for not having it writtne up as a paper yet
20:43 < CodeShark> the way things are right now, a secure signing node would have to store the complete transactions containing their outputs anyhow
20:43 < CodeShark> if for no other reason than that there's no other way for it to verify the output values
20:44 < CodeShark> so here we're also adding an O(log2) structure for proofs
20:44 < CodeShark> of existence in blocks
20:50 < CodeShark> existence of new outputs/removal of spent outputs, I should say
20:50 < petertodd> yeah, it's a fair bit of bandwidth over just the txin data
20:51 < petertodd> OTOH it is purely a tradeoff - if you have the UTXO set you don't have that cost
20:54 < CodeShark> so you would advertise whether or not you have the UTXO in the initial handshake?
20:55 < nsh> hmmm, there might be privacy implications in the negotiation
20:55 < petertodd> well, e.g. for a block being distributed if you don't have the utxo ask your peer to provide the proof
20:55 < CodeShark> asking the peer to provide the proof requires one more roundtrip…which introduces greater latency
20:56 < petertodd> CodeShark: yup, which is why you want to have as many utxo's on hand as you can store
20:56 < CodeShark> point is you could establish whether or not you have the complete utxo in the initial negotiation
20:56 < petertodd> CodeShark: but at some point you run out of space, so you drop ones that are unlikely to be spent
20:56 < petertodd> CodeShark: well you could give your peer a bloom filter of wha tyou have, for example
20:57 < CodeShark> right, something along those lines might work
20:57 < petertodd> yup, lots of options, main thing is that all those options are things that aren't forks
20:59 < nsh> perhaps it might be good to enable an ecology to these things: let various different approaches be 'right' and let natural selection on the basis of effectiveness and cost tend toward improvement
21:00 < nsh> the monocultural aspects of the bitcoin network should be whittled to a fine point of essential security and consistency
21:00 < CodeShark> problem is natural selection favors diversity (i.e. forks)
21:00 < petertodd> nsh: agreed, although people tend to complain that their wallets don't go fast :)
21:01 < nsh> mmm
21:01 < CodeShark> well, these approaches don't require block chain forks - but they do require care with protocol issues
21:02 < nsh> CodeShark, can't you look at the (hard)fork border as the boundary of an island (let's call it Coinagascar)? you can still have diversity within those confines...
21:03 < CodeShark> I suppose we could separate the core validation algorithms from the specifics of the protocol itself :)
21:03 < CodeShark> as in the specifics of networking with pees
21:03 < CodeShark> *peers
21:03  * nsh nods
21:04 < nsh> the downside is that you lose some of the shepherding function of the core dev team
21:04 < nsh> but i would anticipate that function isn't long-term sustainable if bitcoin grows into a very large ecosystem anyway
21:05 < nsh> and it's already accepted that you choosing to use one solution over another can have financial implications
21:05 < nsh> s/you //
21:18 < maaku> "In conclusion, I think that humanity should stop publishing papers about Byzantine fault tolerance. I do not blame my fellow researchers for trying to publish in this area, in the same limited sense that I do not blame crackheads for wanting to acquire and then consume cocaine."
21:19 < maaku> ah, microsoft research, how i love thee
21:19  * nsh smiles
21:21 < nsh> hah, that whole piece is great
21:21 < nsh> ( https://research.microsoft.com/en-us/people/mickens/thesaddestmoment.pdf )
21:25 <@gmaxwell> it's generally true of Byzantine fault tolerance. People who shit on Bitcoin are either in denial or unaware of the complete failure that field has been.
21:26 <@gmaxwell> An endless series of impossibly complicated protocols which can only work under highly unrealistic constraints and which generally burst into flames on contact with reality.
21:32 <@gmaxwell> it's basically a field that people have been wanking on more or less ineffectually since the late 1970s, making little useful progress, and then Bitcoin comes along and delivers a working system that is secure in the anonymous model, where like everything else required previously agreed participants, requires linear communication (as opposed to quadratic in the number of participants), and is relatively simply explained vs the charts ...
21:32 <@gmaxwell> ... in that paper. ... and did so basically as a footnote on the way to producing an entirely new kind of currency.
21:44 < nsh> reminds me of... atomic chemistry until the 1870s. decades of top scientists debating fancy models, vortex theories, all sorts of complex contrivances, and then Mendeleev comes along with the periodic table, pow!
21:49 < petertodd> gmaxwell: OTOH PoW blockchains appear to only work in conjunction with financial incentives
21:50 <@gmaxwell> petertodd: indeed, bitcoin is _not_ a fully general solution.
21:51 < petertodd> gmaxwell: though in many cases you can limit your "byzantine fault vulnerability" to a small part of software that is trusted to give an honest signature for some type of "fake work"
21:51 <@gmaxwell> it just happens to work (so far) for like ... the only application known where byzantine fault tolerance was actually a hard requirement. :P
21:51 < petertodd> gmaxwell: lol, there is that!
22:06 < nsh> serendipity
--- Log closed Wed Dec 25 00:00:25 2013