--- Log opened Mon May 20 00:00:06 2013
01:42 < warren> sipa: would you be interested in an affected wallet.dat?
02:09 < warren> the keys are all compressed.  I'm digging through code.
07:50 < warren> petertodd: where is your site about the 1MB block limit again?
13:42 < gmaxwell> eek how did I forget to rejoin.
13:44 < gmaxwell> For those who weren't at the Bitcoin conference—  Eli Ben-Sasson presented on his computational integrity work. This is that stuff we'd talked a little about in here that converts arbitrary programs (in ansi C) into zero knoweldge proofs, allowing you to run them on secret data and produce compact and quickly validated 'signatures' over the output that proves the program was executed faithfully.
13:46 < gmaxwell> Importantly, I got some more performance details from him. ... sounds like the proving (signing) cost is on the order of  n * 900 * log(n) where n is operations in the computation.
13:47 < gmaxwell> The validation is some constant times the length of the compiled program. Right now their compiler has a n*poly log n cost like proving however, but they know how to fix that.
13:48 < realazthat> gmaxwell: mmm reminds me of this https://hcrypt.com/
13:48 < gmaxwell> Sounds like the scalablity ends up memory limited in their actual implementation right now.. To get an idea, each asm opcode produces something like 1500 constraints, and they've used their system successfully on programs of 30 million constraints or so on 'desktop hardware'.
13:48 < realazthat> related I mean
13:48 < realazthat> but cool
13:49 < realazthat> is there a link to this stuff online somewhere?
13:49 < gmaxwell> realazthat: it's in that same general family of techniques... but whats important is that the cost is polynomal. This is actually (nearly-) pratical  for a lot more stuff.
13:49 < gmaxwell> realazthat: Their paper should be published in a few days.
13:49 < realazthat> cool
13:49 < gmaxwell> There is, however, a video— https://www.youtube.com/watch?v=CjUNj8ow6UE
13:49 < realazthat> ah nice
13:50 < gmaxwell> The thing I'd like to use it for is this: https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked
13:53 < realazthat> mm that is cool; I wonder how applicable these use cases actually are though
13:53 < realazthat> what greater application I mean
13:54 < gmaxwell> There are more powerful ideas for it... for example, you could use these techniques to produce checkpoints that can't cheat.  If you replaced script validation with the validator for it, you could make transactions depend on complex C code… but these things are currently infeasable just because of the computational cost. But because the techniques are poly cost, we can hope that even if they only get a bit better, that computers getting
13:55 < gmaxwell> realazthat: Well, I can give some examples for why hash locked, but I don't like them much. The problem is that things like constests for beautiful pictures or whatever can normally just be solved via escrow, we don't really need zero trust in most pratical cases.
13:55 < realazthat> well I can imagine something like crazy financial instruments can come out based on bitcoin using all these hard-to-apply features
13:56 < gmaxwell> The best example I can give you is:  "We anonymous parties will pay 100 BTC for some anonymous party to leak Foo DRM's uber-secret master key" — can't use escrow because thats a point of attack.
13:56 < realazthat> haha
13:56 < HM_> and then the proof would be some C code that validated the DRM key
13:57 < realazthat> I was thinking/dreaming of putting a bounty on satoshi signing something
13:57 < gmaxwell> yes, you could create some fancy contracts ... but I think the interesting applications of that require the validation _inside_ the bitcoin protocol. Wherease the DRM example works with my wiki page above: totally external to bitcoin.
13:57 < gmaxwell> (And so the fact that the proof is @#$@# expensive is irrelevant, so long as you can compute them on conventional hardware in a few hours)
13:57 < realazthat> does satoshi have a public gpg key or something?
13:57 < realazthat> (so my dream would make sense)
13:58 < gmaxwell> realazthat: kinda. He has a gpg key that many people will vouch for, but there is actually very little public evidence that it's actually his.
13:58 < realazthat> ah ok
13:58 < gmaxwell> he could, however, signmessage with the genesis key.
13:58 < realazthat> haha great idea
13:58 < gmaxwell> (if he still has it)
13:59 < realazthat> I imagine one day ppl will try to track bitcoins through the chain to identify him :P
13:59 < gmaxwell> HM_: yea, I'd like to think of some examples that don't involve breaking the law. But I don't know that there really are any: if your trade is not likely to bring fire, you can use a trust public mediator for an escrow.
13:59 < HM_> if it's expensive to verify it has to be expensive to generate as well though
13:59 < HM_> otherwise you can flood the network with candidate solutions and DDoS the whole thing?
14:00 < gmaxwell> HM_: you can use hashcash to solve that. (or make candidates pay you a small amount of bitcoin) no problem.
14:00 < HM_> hmm yeah
14:01 < HM_> so it's a C subset?
14:01 < gmaxwell> The validation is actually cheap for this kind of thing... but still slower than ecdsa in practice.. which would keep us from putting the validator directly in bitcoin, … for now.
14:02 < gmaxwell> they invented a mips like register based machine language, and made GCC (dragonegg/llvm) able to compile to it. It doesn't have floating point IIRC.
14:02 < realazthat> mmm
14:02 < realazthat> fp can be done on top
14:02 < gmaxwell> sure.
14:02 < realazthat> thats really cool hehe
14:03 < realazthat> mmm I'd want to play with that
14:03 < gmaxwell> Or you just write fixed point code. No biggie.  The bigger problems is that it's not fast and needs lots of ram on the prover side.
14:03 < gmaxwell> But it sounds efficient enough to be actually usable for _something_ now.
14:03 < gmaxwell> And they've actually implemented it.
14:04 < realazthat> yeah, I just wanna play with it external to bitcoin
14:04 < realazthat> are they to release the codes?
14:04 < realazthat> I hope so
14:11 < gmaxwell> Yes. They were talking about setting up a github page and such.
14:11 < gmaxwell> and, it sounded like they were willing to make it available in advance to bitcoin wizard types interested in working with it.
14:12 < gmaxwell> I haven't asked for it yet simply because I do not have enough bandwidth to do something with it in the next few days....
14:12 < gmaxwell> But I'd really like to actually execute that protocol I described, and make a zero knoweldge contingent payment. Just need to figure out something to buy thats sexier than a cracked password.
14:13 < gmaxwell> (I wish the xkcd thing were ongoing, I could buy a solution to that! :P )
14:15 < realazthat> lol
14:18 < gmaxwell> Ah. Perhaps I could buy the infinitely good solution from Randall Munroe. (and get him to reopen submissions, so that 'Bitcoin' could be the top of the list)
14:19 < realazthat> mmm
14:19 < realazthat> can you explain the xkcd reference?
14:22 < gmaxwell> http://www.explainxkcd.com/wiki/index.php?title=1193:_Externalities
14:26 < gmaxwell> http://almamater.xkcd.com/  (I'm xiph.org with the 392 score)
14:27 < gmaxwell> Only tied with stanford :(
14:27 < realazthat> oh the hashing competition :D
14:28 < gmaxwell> Randall actually knows the preimage. (or at least, he indicated that he did in IRC)
14:29 < realazthat> haha
14:29 < realazthat> do you need that to use it as a challenge?
14:30 < gmaxwell> 'that'?
14:30 < realazthat> the preimage
14:31 < gmaxwell> No, he could have made a challenge with a random target (or a target of all zeros). The fact that the target had 'high entropy' suggests that he knows the preimage... and as I said, he said that he did.
15:17 < BlueMatt> gmaxwell: or...just make it so no one has to download the chain ever again...
15:17 < BlueMatt> "but the chain is 100GB" go fuck yourself, just use computational integrity
15:19 < gmaxwell> I said that " for example, you could use these techniques to produce checkpoints that can't cheat."
15:19 < BlueMatt> well, you dont expect me to read the whole scrollback, do you?
15:20 < gmaxwell> BlueMatt: it's not realastic yet... well, I joked that if we got all of google's computing power for a week perhaps we could compute a CI signature. :P
15:20 < gmaxwell> er realistic.
15:20 < BlueMatt> yea, I know, I just keep hoping
15:20 < gmaxwell> At least the naive way of doing it... really the biggest problem is all the state needed in validation to track unspent coins.
15:25 < BlueMatt> yea, maybe when we all have 512GB ram in every machine...
15:25 < gmaxwell> BlueMatt: not even 'every' ... the validation side doesn't sound terrible.
15:26 < BlueMatt> ahh, well then we just need to find a computer to do the original signing...
15:26 < BlueMatt> lets get TD/sipa to do it...
15:29 < BlueMatt> I wonder how much it has to go back over the data during the signing (or if swapping it out to an ssd would actually work)
15:30 < gmaxwell> Right. TD had mentioned some unrelated work on garbled circuits was intractable until some software engineers had a go at it and reorged the algorithim to work in a streaming-from-disk manner.
15:31 < gmaxwell> The other problem with this stuff is that getting people convinced that the process is sound might be hard. Apparently their work has something like 400 pages of dense mathmatical proofs behind it.
15:31 < BlueMatt> ahhhh
15:32 < BlueMatt> well, I dont know that I would really trust it immediately (or for the next few years) anyway...
15:32 < gmaxwell> But of course, actually _using_ it for something would make good incentives to attack it!
15:32 < BlueMatt> still, the idea that it will clearly be possible in the immediate future means the argument that the chain is growing too fast (and not the utxo set) is invalid
15:33 < sipa> gmaxwell: but will verifying the proof be cheaper than just verifying the chain?
15:34 < gmaxwell> For some size of the chain it should be. The complexity is polynomial on the size of the program (the rules) you're validating.
15:34 < gmaxwell> (complexity of validating)
15:34 < sipa> ic
15:34 < sipa> magic :S
15:34 < BlueMatt> as long as its similar and you can throw out the chain data itself instead of still having to distribute the chain in the form of input data
15:35 < gmaxwell> BlueMatt: I don't agree. You're streaching. You still need the bandwidth to recieve blocks to actually use the network in real time. It just means the history bloat will be less of an issue perhaps.
15:35 < gmaxwell> stretching*.
15:35 < BlueMatt> yes, thats my point
15:35 < BlueMatt> its just blocks/time instead of total blocks
15:35 < BlueMatt> (in data)
15:35 < gmaxwell> I don't think anyone has argued that the history is an issue. Mostly people are willing to ignore the bootstrap time/cost. (maybe thats unwise too)
15:36 < BlueMatt> Ive heard it once or twice
15:37 < gmaxwell> well you've heard me say it wrt pruning and needing to be really careful about how we handle it (e.g. that I want to have addr message signal that nodes have random subsets of the chain in addition to just the most recent few thousand blocks).. but thats still true, since this stuff probably won't be pratical for bootstrap for a couple years at best.
15:37 < gmaxwell> But thats not a scaling concern... it's a pruning concern specifically.
15:38 < BlueMatt> meh
15:39 < gmaxwell> I don't want the network to depend on having archive nodes to bootstrap. Esp when there will be plenty of users happy to donate more disk space but not as much as a full archive.  Archive nodes, if thats all we have, will be quite costly to operate... and I can reliably predict people will start saying "more people should use SPV nodes" as an answer to archive nodes being totally saturated.
15:40 < gmaxwell> People should be able to pick the disk space they donate to the network continuously from utxo only all the way up to archive.
15:41 < BlueMatt> not sure we need /that/ much flexibility, but chunks of tens of thousands of blocks yea
15:42 < BlueMatt> would be interesting to split that off into a separate bootstrap network
15:44 < gmaxwell> yea, I just want node to be able to signal a single range in addition to a range from top.
15:44 < gmaxwell> More ranges would be nice but I don't think they're important.
15:46 < gmaxwell> e.g. a service flag that says it keeps the last 2016, and a range that it has 120000-160000.
15:47 < petertodd> warren: keepbitcoinfree.org
15:48  * BlueMatt :(
15:48  * BlueMatt isnt opposed to making most bootstrap on some 3rd party network
15:48 < petertodd> BlueMatt: btw you may want to argue over email with me - I won't be on irc much in the next week
15:49 < BlueMatt> meh, we clearly fundamentally disagree
15:49 < BlueMatt> not sure arguing helps any there
15:49 < petertodd> not surprising
15:49 < petertodd> after all, it's not a technical decision, it's about what you value in bitcoin
15:49 < BlueMatt> not really
15:49 < BlueMatt> well, at least not the way that video presented it
15:49 < BlueMatt> in the extreme, sure
15:50 < gmaxwell> BlueMatt: just be really careful that you're not treating "other network" as magic. There are reasons why you can do this better with integration with our network, as well as by knowing about the data you're working with.
15:50 < BlueMatt> gmaxwell: meh, its easier to treat it as magic...
15:50 < petertodd> it was really interesting being at the developer round table, talking about scalability stuff, and when it was over a half dozen argentinian investors surrounded me with questions - they were extremely concerned about centralization and anonymity
15:50 < BlueMatt> but, no, yea it makes more sense on our network, but it would have to be half-separated
15:51 < BlueMatt> petertodd: I have no doubt that scare-videos scare people...
15:51 < gmaxwell> BlueMatt: our trackerless torrent hardly works— requires a weakly trusted party to give you the torrent ID (and wastes your time/bandwidth if its wrong). External network doesn't make it trivial for bitcoin participants to turn a knob to control their contribution level, unless we bundled the third party network software and increase our attack surface.  File trading protocols get people banned from some networks for reasons unrelated t
15:52 < BlueMatt> gmaxwell: yes, this is why it does actually make more sense to put it on a standard bitcoin p2p network
15:52 < BlueMatt> but make the connection logic such that you only connect to "that" network if you are bootstrapping
15:53 < petertodd> BlueMatt: I don't think any of them had heard of me before actually, they were just listening to the tradeoffs between bandwidth and decentralization and anonymity, like it or not, you can't mine large blocks anonymously, that's just life
15:53 < BlueMatt> um...no?
15:53 < BlueMatt> thats just not true
15:53 < gmaxwell> BlueMatt: yea, thats not crazy I suppose.. but really that can just be the same p2p network and differentiation with service bits.
15:53 < petertodd> BlueMatt: so how are you going to do that?
15:53 < BlueMatt> you cant mine at all without serious cash, and with that you can mine anonymously...
15:54 < petertodd> BlueMatt: that's completely wrong and you know it, the cheapest ASIC miners are just a few hundred dollars of investment
15:54 < BlueMatt> gmaxwell: well getting connected would be tricky...
15:54 < petertodd> BlueMatt: and $/GH scales linearly, with slightly better MH for lower $'s
15:55 < BlueMatt> petertodd: and the cheapest of asics will do absolutely nothing within a year
15:55 < petertodd> BlueMatt: and after a year, the cheapest asics will still be cheap!
15:55 < petertodd> BlueMatt: that's just how silicon mfg works
15:55 < BlueMatt> and do nothing...
15:55 < BlueMatt> yes, as long as it is cheap and available it will be worthless for reasonable mining
15:56 < gmaxwell> BlueMatt: whats reasonable mean? I mean, my office is full of people who gpu mine... quite profitably now at the moment.
15:56 < petertodd> BlueMatt: individually they do nothing, thousands of them together make for a huge and extremely difficult to censor chunk of hashing power
15:56 < BlueMatt> gmaxwell: yes, because supply is...impoxxible
15:56 < BlueMatt> oh, you said gpu
15:56 < gmaxwell> Of GPUS?!?!?!
15:56 < BlueMatt> meh, whatever
15:56 < gmaxwell> right!
15:57 < gmaxwell> Your discussion feels like a tangent in any case. I think you'd disagree less if you had a nice conversation instead of a debate. :)
15:57 < petertodd> ASIC supply *will* be reasonable in the future, it's just IC mfg, you might as well assume Intel CPU's will be impossible to get because they're hard to make
15:57 < gmaxwell> petertodd: bluematt argues that so long as mining is very proftably supply will tend to zero because people will snaft them up.
15:57 < BlueMatt> petertodd: and even if it is, bandwidth continues to increase
15:58 < BlueMatt> petertodd: I do not argue that we shouldn't increase block size to 10GB/10 minutes
15:58 < BlueMatt> petertodd: but that video drastically overstates the consequences
15:58 < petertodd> Huh? That's crazy. So what if "supply" tends to zero, the question is what is the barrier to entry to buy.
15:59 < petertodd> The barrier to entry is one ASIC chip, and $/GH scales very nicely
15:59 < gmaxwell> I think debating supply is silly however... because very distributed small scale mining is still fine. It doesn't really matter how much each person earns so long as they do it.
15:59 < gmaxwell> so forget that argument.
15:59 < petertodd> gmaxwell: +1
15:59 < gmaxwell> and realize that BlueMatt and you actually argree. (see his last comment)
15:59 < gmaxwell> you just perhaps disagree on the number and how you determine it.
15:59 < petertodd> Right, but small scale *hashing* is useless, only small scale *mining* matters.
16:00 < gmaxwell> Fortunately we have a plan of attack to convert more small scale hashing into small scale mining.
16:00 < gmaxwell> (one which sounds very viable, and now has a bunch of people basically on board for it)
16:01 < petertodd> Yup, but the plan fails if you raise the blocksize above what people can process, which is all the more reason to do it as fast as possible.
16:01 < BlueMatt> petertodd: me being upset with that page has nothing to do with your fundamental argument, Im just incredibly pissed that you would do such a video that so far overstates the consequences of a few mb increase
16:02 < zooko> gmaxwell: quick pointer to that plan for small-scale-mining?
16:02 < petertodd> Well, that you assume the video was talking about a few mb increase is a big problem. It was talking about what happens to Bitcoin if we go the on-chain route for everything, and in the long run as Bitcoin scales to the whole world.
16:02 < BlueMatt> its clearly designed as a simple scare video
16:03 < zooko> Hey, do you folks mind if I invite Adam Back to this channel?
16:03 < petertodd> zooko: yes, he's smarter than me :P
16:03  * zooko laughs.
16:03 < zooko> me too
16:03 < BlueMatt> petertodd: then you are very confused about how that video actually came across
16:04 < gmaxwell> The channel is not technical a secret. Just not promoted to keep the noise down. Invite anyone who would find the conversation interesting.
16:04 < zooko> gmaxwell: cool
16:04 < BlueMatt> petertodd: also, the idea that you want people to start standing up and emailing pools and everything to get them to publicly post that they "disagree with any blockchain increase" is just not cool
16:05 < petertodd> BlueMatt: Alright, look at it this way, if Bitcoin gets to the point where we need 1GB blocks soon, do you think what the video says makes sense?
16:05 < warren> petertodd: curious, the text doesn't mention spam or dust at all?
16:05 < petertodd> BlueMatt: In the next few years disagreeing with any blockchain increase makes sense because tech just won't have changed much.
16:05 < gmaxwell> zooko: The plan is to integrate modern mining support with bitcoind... provide some good UI that makes it interesting.. AND provide a mode where user configured pools provide only the coinbase transaction, but the local node provides everything else. This way the pool pools only the payouts, not the network consensus. (there are a bunch of details, but this is the high level goal)
16:05 < BlueMatt> petertodd: wait, WAT?
16:05 < petertodd> warren: Oh in the site? Yeah, I need to add that stuff.
16:06 < zooko> gmaxwell: huh, interesting!
16:06 < BlueMatt> petertodd: the tech is chaining (as in power to process stuff and bandwidth availability)
16:06 < zooko> gmaxwell: I very much value decentralizing mining.
16:06 < petertodd> BlueMatt: My train of thought it mining must be possible anonymously and on a small scale, and I know damn well that it'd take at least 5 more years until anonymous bandwidth availability is even close to improving enough to consider an increase.
16:06 < BlueMatt> petertodd: and there is no question that by the point we have /that/ many txn something will have to go off-chain
16:06 < gmaxwell> BlueMatt: The answer you should make to petertodd is to _demonstrate_ the tech can handle whatever block sizes you think it should.. keep in mind that until a few months ago we couldn't handle >500k safely and didn't even know it. :( So regardless of your views, doing that will be super useful.
16:07 < petertodd> BlueMatt: Anonymous bandwidth availability has *very* little to do with tech and everything to do with politics.
16:07 < BlueMatt> gmaxwell: because I have time for that?
16:07 < BlueMatt> oh god
16:07 < gmaxwell> BlueMatt: I didn't mean you personally at least not right now.
16:07 < sipa> i'm getting complaimts from a pool operator that GBT is taking 10s since very recently
16:07 < BlueMatt> petertodd: its not a question of being able to mine over tor
16:07 < BlueMatt> you wont ever be able to do that reasonably
16:08 < gmaxwell> sipa: yea, its due to correct horse stapler battery spatular nunchuck
16:08 < BlueMatt> sipa: Ive hear that a lot
16:08 < gmaxwell> sipa: the workaround is to run 0.8.2 for obvious reasons.
16:08 < petertodd> BlueMatt: And not being able to do that is unacceptable.
16:08 < BlueMatt> petertodd: no, its the ability to mine from wherever over your connection in $RANDOM_COUNTRY
16:08 < BlueMatt> you cant mine over tor now
16:08 < gmaxwell> petertodd: you guys should stop arguing and look at the points you agree over. There is substantial agreement.
16:08 < BlueMatt> and you wont ever be able to
16:08 < BlueMatt> get over it
16:08 < gmaxwell> BlueMatt: I have mined many blocks over tor in the last month.
16:08 < gmaxwell> I have, in fact, yet to have an orphan.
16:08 < petertodd> sipa: Another correct horse tx got mined.
16:09 < BlueMatt> if I /need/ to mine anonymously, Ill go to uganda and set up shop there
16:09 < petertodd> gmaxwell: You gotta add "mined over tor" to your coinbase...
16:09 < gmaxwell> petertodd: convince someone else to first. :(
16:09 < petertodd> BlueMatt: I've told people about those options, and they see that as unacceptable.
16:09 < BlueMatt> the ability to mine over tor is /definately/ not something we need to protect
16:09 < petertodd> gmaxwell: lol, true
16:09 < gmaxwell> In any case, I think that the tor argument is kinda a tangent — or at least it's not my own priority.
16:10 < BlueMatt> the ability of any random user to mine /is/
16:10 < gmaxwell> I agree with bluematt there mostly, besides that difference is probably just some small constant factor in scale.
16:10 < BlueMatt> if we want to make sure users can mine over tor, why are we not working to ensure users can mine over dial up?
16:10 < petertodd> BlueMatt: Look, fundementally you are happy with a less secure to censorship Bitcoin than I am. That's why it's a political, not technical, argument. We both agree on the technical aspects here, just on what the political implictions are.
16:10 < BlueMatt> because there are a lot of people in repressive gov'ts who only have that
16:11 < BlueMatt> btw, tor isnt secure against censorship...
16:11 < gmaxwell> BlueMatt: because dialup is not a necessary condition of a repressive government, forcing people to dialup has a lot of coolateral damage.
16:11 < BlueMatt> its been done quite a bit...
16:11 < gmaxwell> collateral*
16:12 < gmaxwell> BlueMatt: kinda, tor is where the whole open world is currently focusing their anti-censorship efforts... and they seem to be winning the cat and mouse game mostly.
16:12 < BlueMatt> if you think we need tor for an internet with speech where you can do whatever the fuck you want, you have to look no further than tpb
16:12 < BlueMatt> gmaxwell: not afaict, at least in china getting tor access means having someone else set up a bridge for you to use
16:12 < petertodd> BlueMatt: Tor over consumer connections is *currently* widespread, so I want to scale the network with that we have a pretty good chance of having available to us for the next few years. In 10 years *maybe* we'll decide making it possible to mine over dial-up *is* a good idea and reduce the blocksize. I sure hope not, but it may be a reasonable thing to do.
16:12 < BlueMatt> and that means most people just use vpns
16:13 < BlueMatt> wait, wtf?
16:13 < BlueMatt> really?
16:13 < gmaxwell> petertodd: technically mining works over dialup okay now, so long as you use a p2p protocol that looks like p2pool's.
16:13 < petertodd> gmaxwell: yup, and you can always just mine zero-tx blocks too.
16:13 < gmaxwell> (one where you only need to send the hashes when you find a block, as you've preforwarded the txn)
16:14 < BlueMatt> anyway, its clear we fundamentally disagree on what we need to protect (and what is actually useful and possible, even if we try to protect it)
16:14 < BlueMatt> so I dont think arguing helps anything
16:14 < gmaxwell> s/zero/few/
16:14 < BlueMatt> you are free to work on solutions that allow mining over tor, and the rest of us will just work on something else
16:14 < petertodd> BlueMatt: Exactly. We *do* agree on the technology side of things, we do not agree on what is important beyond tech.
16:15 < BlueMatt> I certainly dont think its a bad idea that someone allows one to mine over tor, just that it shouldnt impact big-picture decisions for the actual network
16:15 < zooko> Good to realize that so you can productively collaborate on understanding what is possible.
16:15 < gmaxwell> BlueMatt: funny, I see you both largely argreeing. That there is actually a tradeoff between decenteralization and scale. And that compromising the former for the latter completely is unacceptable.  You're arguing over approaches, boundaries, and silly details.
16:15 < petertodd> gmaxwell: Exactly! It's a political decision end of story.
16:16 < gmaxwell> petertodd: I think you should do a writeup on bitcoin primarily as a reserve currency.  Thats sort of an implicit premise of what you talk about wrt off chain txn, but I don't know that it's clear that you're thinking of it that way.
16:16 < petertodd> gmaxwell: Though of course having real world off-chain tech with auditing and fraud protection, rather than purely examples like easywallet without those protections, needs to be implemented to show people.
16:16 < petertodd> gmaxwell: Yeah, that's a good idea.
16:17 < BlueMatt> no, Im arguing that the "dystopian" future presented in that video is not only ridiculous, but significantly harmful to the ability of people to have reasonable discussions about the political and/or technical parts of this
16:17 < sipa> i think you should present thigs in a different way
16:17 < sipa> presenting it as a dystopian future putsany people off
16:18 < sipa> thinking you are talking about some potential worst case situation
16:18 < sipa> i like to look at it this way:
16:18 < sipa> bitcoin is an experiment in creating a decentralized currency
16:18 < sipa> the experiment is more useful the less it requires trust
16:19 < sipa> a system that is able to function in the presence of worst-case conditions is strictly more interesting
16:19 < warren> sipa: hi.  Would you be interested in an affected wallet.dat plus patches to load the alternate address schema, would that be helpful?
16:19 < petertodd> sipa: Good idea. Having a system that can function in the dystopian future makes it a lot less attractive to force us to that distopian future anyway, why try regulating what you know can't be?
16:20 < zooko> I haven't seen the video and haven't read all this irc log carefully, but it kind of sounds like the video was exciting or polarizing and some residual energy for that is still bouncing around in this conversation...
16:20 < BlueMatt> petertodd: and then we can have a discussion of increased block sizes for purely technical reasons and not political "the sky is falling" arguments :P
16:21 < BlueMatt> petertodd: but I certainly think it would be awesome to have something that could mine successfully over dial-up or some other ridiculously low-bw connection
16:21 < petertodd> BlueMatt: It still doesn't work that way. The technical tradeoffs are there, but what tradeoffs are important will always be political.
16:21 < sipa> warren: not now
16:21 < gmaxwell> One of the reasons I don't share BlueMatt's view (and I suppose could be said to have tacitly encouraged petertodd because I didn't say "NO STOP!" when he posted the initial script) is because we are very rapidly racing towards increasing the size, and both Gavin and Mike have argued for _unlimited_ and argued that it was actually uncontroversial and that concerns were unreasonable. I don't think thats fair. And I think that having the ot
16:21 < warren> sipa: ok.  i'll debug more, maybe I can figure it out on my own.
16:21 < sipa> gmaxwell: the ot[...]
16:22 < BlueMatt> gmaxwell: yes, I would agree there that infinite size is just not ok
16:22 < gmaxwell> And I think that having the other extreme making their argument makes it _easier_ to have a discussion about tradeoffs instead of wasting our time arguing if there is no concern at all or not.  But maybe I'm stupid. It happens.
16:22 < petertodd> gmaxwell: Indeed. I sure wouldn't have made the video if they had been more resonable there - I did propose that we have a strict "wait a year" period regardless. The worst that can happen is growth is slowed temporarily.
16:23 < BlueMatt> ahhhh, this google reader -> feedly switch is insane, do you want to share this, what about with facebook, no linkedin? no G+, no? twitter, no, you WANT TO SHARE!!!!111one
16:23 < zooko> Haha, so you're responsible for the video that I just implicitly criticized.
16:23 < petertodd> zooko: lol, yup.
16:24 < zooko> By the way, I unfortunately didn't speak to you at the conference, but I listened with great interest to your contribution to the "core dev meetup crowd" thing.
16:24 < petertodd> zooko: Thanks! I thought that discussion wound up happening in a pretty reasonable fashion.
16:24 < zooko> Yeah, not too bad.
16:24 < petertodd> Nice to see the payment protocol is uncontroversial too. :P
16:25 < zooko> Hee hee.
16:25 < zooko> Ah, so I was all hot under the collar about having PKI in the payment protocol
16:25 < zooko> (note:
16:25 < zooko> *not* about x.509 being a bad PKI, about PKI being a bad thing to have in the payment protocol)
16:25 < gmaxwell> petertodd: one of the problems we'll face here is that the deployment of any change will have a huge leadtime. And so it means that if we have to suffer to trigger making the change it means we'll suffer for a huge time. I really do not have a solution for that, and help thinking of one (beyond "never change") would be really productive.
16:25 < zooko> and I got to talk Gavin's ear off about it with Brian Warner, and much to my astonishment Gavin convinced Brian and me that it was better than the alternatives in there.
16:26 < zooko> And I should emphasize, Brian and I are the last two people who would ever agree to that...
16:26 < petertodd> Ha, yeah, I don't like PKI either, but it's a nice easy first step for sure.
16:26 < zooko> I even have a basic geometric shape named after my dislike of PKI.
16:26 < gmaxwell> zooko: we believe we need non-repudiation in it, and the ability to identify who you're paying. (of course the identity could be a pseudonomymous one if you like)
16:26 < zooko> gmaxwell: that isn't what convinced me.
16:26 < petertodd> gmaxwell: Heh, I've been arguing that deploying a blocksize change can happen relatively quickly...
16:27 < petertodd> zooko: basic geometric shape?
16:27 < gmaxwell> petertodd: it's a hardfork though... Though, I suppose the may 15 thing actually proved it could be done.
16:27 < petertodd> gmaxwell: Exactly. *If* there is consensus, changing it is not such a big deal.
16:27 < gmaxwell> And we don't mind if it's some other kind of things like namecoin+gpg or whatever. The protocol itself doesn't have to care really. .. it's just that there is little in actually workable alternatives right now.
16:28  * BlueMatt -> gone, and really dont want to discuss politics further, its too...political
16:28 < petertodd> gmaxwell: Hasn't proved it yet...
16:28 < gmaxwell> petertodd: I'll have to think about that some. I think I was taking it as fact that the actual change had to take forever. But perhaps just the software validation does.
16:29 < petertodd> gmaxwell: People can upgrade relatively quickly. The real issue is we can't change it very much quickly; doubling the blocksize can probably be done and tested in six months.
16:31 < petertodd> gmaxwell: An order of magnitude increase, or worse, unlimited, will break stuff that we can't even think of, let alone test for.
16:34 < zooko> petertodd: there's this thing named "Zooko's Triangle" which could be used in an argument that PKI is inherently unsuitable for the payment protocol.
16:34 < petertodd> zooko: oh, that's you! cool
16:35 < petertodd> I love talking to non-tech people about that triangle.
16:35 < zooko> ☺
16:35 < zooko> Thanks.
16:40 < petertodd> alright guys later
16:41 < zooko> cheers
16:43 < gmaxwell> uh. I'm just realizing that debating the scalablity stuff probably shouldn't be done in a not very public IRC channel, and we should probably avoid doing that in the future. (not sure it should be done in bitcoin-dev either, as it wasn't a near-term technical discussion)
16:45 < BlueMatt> gmaxwell: political discussions over irc are impossible, over email they are significantly worse...
16:45 < zooko> Maybe post logs of this channel? Few would read them. I wouldn't.
16:45 < zooko> But at least they'd be out there.
16:45 < gmaxwell> zooko: doesn't really solve my concern. I'm not the sort to believe that a log no one would read addresses transparency.
16:46 < BlueMatt> having them in bitcoin-dev makes sense
16:46 < gmaxwell> (I mean, fine to do that too as far as I'm concerned)
16:46 < BlueMatt> and its not like we're gonna do anything tomorrow
16:46 < BlueMatt> things will happen on the ml long before anything real happens
16:46 < gmaxwell> BlueMatt: yea, I think bitcoin-dev is okay so long as we can stop the discussion when something currently important comes up.
16:47 < BlueMatt> well, at least get community input for important topics long before merge
16:47 < BlueMatt> though, again, anything non-technical is impossible over irc and significantly more impossible on a ml
16:47 < BlueMatt> it would be ideal to do face-to-face, like...at a conference
16:47 < gmaxwell> Sure sure. I just generally don't want to be in the habbit of having multi-party discussions of things with real impact in private.
16:48 < BlueMatt> bitcoin-dev is probably fine, the people going there to ask noob questions shut up when real discussions happen
16:48 < gmaxwell> (it's really seductive to create your little private channels and only invite in the people you agree with ...)
16:48 < BlueMatt> obviously, hence bitcoin-dev
19:45 < sipa> hmm, even my 0.8.2rc1 instance needs several seconds for a getblocktemplate
19:45 < gmaxwell> sweet.
19:46 < sipa> ~ 2400 transactions in mempool
19:46 < warren> sipa: p2pool folks are increasing mintxfee up a bit to reduce GBT latency
19:51 < gmaxwell> fast here but I keep restarting my node for testing.
19:53 < sipa> right after restart it's 0.04s
21:27 < sipa> ok, removed free relay policy and dust check, and made my node send mempool command to peers at connect time
21:27 < sipa> instantly mempool size > 4000
21:28 < sipa> made a few improvements to CreateNewBlock too... still GBT latency is 0.4s
21:29 < sipa> but not 5s as it was before restart (though that may have been a more complex mempool)
21:29 < gmaxwell> seems very weird.
21:30 < gmaxwell> Very deep unconfirmed chains now?
21:31 < sipa> no idea
21:31 < sipa> what is weird?
21:31 < gmaxwell> 0.4 seconds is high compared to what I thought it had previously been.
21:32 < sipa> well, given my dust and free relay policy are turned off, i may have a pathological mempool now
21:32 < gmaxwell> I seem to remember times like 0.08 seconds but it's been a few months since I was watching it.
21:32 < sipa> i should check without the optimizations i just did
21:32 < gmaxwell> okay. true.
21:32 < warren> p2pool users on 0.8.2rc1 were reporting GBT latency as high as 11 seconds
21:32 < warren> until they bumped up mintxfee
21:33 < gmaxwell> well I _know_ it wasn't that slow last week. Because I often run it from the commandline to answer questions about txn delays.. and I would have noticed 11 seconds.
21:34 < warren> perhaps it was at a particular time during the battery horse staple protest
21:34 < warren> I'm just repeating what I read.  I wasn't using bitcoin at that time.
21:36 < sipa> retrying now without the improvements i did
21:36 < sipa> (there were some unnecessary CCoins copies, and an unnecessary cache layer)
21:43 < sipa> 11s !
21:46 < sipa> 21s !
21:47 < sipa> poolsz 5000
21:52 < sipa> again on the improved version: 0.6s with poolsz > 5000
--- Log closed Tue May 21 00:00:09 2013