00:00:43moa:chicken and egg?
00:01:12moa:also 'much' is a comaprative term
00:01:21moa:s/comparative
00:01:55instagibbs:it's chicken/egg + tragedy of commons.
00:02:20moa:there is much more than there used to be
00:02:42moa:and much more than before that
00:16:36Luke-Jr:there's enough that I'm caught off-guard when someone says they don't take bitcoin :p
00:18:05moa:Luke-Jr: do you take bitcoin?
00:18:29instagibbs:No he only mines for Ether
00:19:32Luke-Jr:instagibbs: couldn't have put it better myself
02:03:40starsoccer:starsoccer is now known as Guest86789
03:40:08bramc:My novel proofs of work ideas can be applied to proofs of steak but they don't really work because for each block the challenge has to be met by a piece of stake, and if stake is transferable then it isn't canonical and can be ground on
03:40:16bramc:Time to switch to proofs of lamb chop
03:41:09bramc:BlueMatt, amiller's paper explaining nonoutsourcability is at http://cs.umd.edu/~amiller/nonoutsourceable.pdf
03:41:42bramc:really it should be called outsourcing resistance. Outsourcing can still be done, it relies on the ratio between the cost of storage and the cost of bandwidth for it to be impractical.
03:41:56BlueMatt:mmm
03:42:28bramc:BlueMatt, also the permacoin paper fills in some concrete numbers http://cs.umd.edu/~amiller/permacoin.pdf
03:43:08BlueMatt:mmm, i do think i read that one...mustve not had it swapped in at the time
03:43:34bramc:The nonoutsourcing is rather tangential to the permacoin paper
03:46:27bramc:I really should do a blog post on some of my signature and work stuff
03:47:10amiller:i have a new nonoutosurceable paper now, its a little better
03:59:12Dr-G3:Dr-G3 is now known as willybot
03:59:49moa:proof of slaughter should be good across multiple meaty chains
04:17:42willybot:willybot is now known as Dr-G
05:01:04bramc:Huh, I didn't know about the factor of four rule
05:01:47bramc:Not sure if I think that's a good idea
05:01:56gmaxwell:in retargeting? Hm. Pretty sure I mentioned it before, must have been confusing.
05:02:44gmaxwell:It closes off some pretty straight forward attacks, and has never been hit (nor seems to be likely to be hit) on the production network. Even with that, it still as quartic convergence, which is quite fast.
05:02:44bramc:Intuitively it seems reassuring, but I don't see a strong argument for it being necessary
05:03:16bramc:You mean logarithmic time convergence
05:03:52bramc:It's entirely possible somebody explained it to me and I missed it
05:04:47gmaxwell:Go compute the cost for creating a fantasy network for a peer you've temporarily isolated. (esp if you can keep it isolated for weeks). It also makes the variance attack where you intentionally ramp difficulty as fast as possible and then attempt to get a single lucky roll that eclipses the honest network, much less likely to be successful.
05:07:16bramc:The intuitions behind that all make sense, but I have a feeling that if one slogs through all the calculations the rule doesn't help all that much
05:07:33bramc:Then again, it does no harm, so there's no reason to change it.
05:08:24bramc:although I'm curious enough as to whether it helps that I might slog through all that crap on principle.
05:10:52gmaxwell:well you might be surprised to find out that an attacker with a constant 1% of the hashpower who continally attempts to replace the chain will be successful with probablity 1; assuming hashrate grows exponentially. The maximum increase greatly reduces the probablity of success in any finite time window for that attack though.
05:11:26gmaxwell:(1% can be any constant percentage. could be 0.001% so long as its a not a falling fraction)
05:11:51bramc:That is surprising.
05:12:27phantomcircuit:bramc, your odds of success within any reasonable finite time period remain very low
05:12:35phantomcircuit:hmm actually i haven't run the math on that
05:12:37phantomcircuit:do they?
05:12:38gmaxwell:attacker constantly ramps that difficulty in their fork as fast as they can; hoping to get lucky.
05:13:43bramc:gmaxwell, intuitively their EV should remain the same regardless of difficulty
05:14:09gmaxwell:phantomcircuit: they do, but they are _much_ higher, without limits on how fast you can ramp the difficulty.
05:14:39gmaxwell:bramc: it's not the sort of attack that has positive expectation. You'll mine less than if you mined honestly with this strategy in the expectation.
05:15:02bramc:Oh, so it's all about undoing transactions?
05:15:24bramc:Or rather, claiming transactions for yourself, in case transaction rewards are greater than mining rewards?
05:16:38gmaxwell:Yes. There can still be rewards other than just mining; e.g. from stealing coins ... Or the motiviation can be just setting things on fire, which some people do from time to time if they can.
05:19:32bramc:Did somebody say that Stellar got a spontaneous fork without even an attacker?
05:19:41sipa:yes
05:20:55bramc:Did they fix it? My impression is that Stellar is for all intents and purposes a centralized system.
05:21:32amiller:stellar hired a reputable distributed systems researcher from stanford, they're working on building a legitimate reliable system
05:21:46gmaxwell:They fixed it by centeralizing it completely, which indeed works.
05:22:27amiller:the gossip i heard is that they are going to preserve some kind of dynamic membership, where the graph of 'good' nodes has to have adequate overlap
05:22:34gmaxwell:amiller: he'd been working for them since their public announcement; which was written in weird third party tone to make it sound like he was an independant auditer.
05:23:06bramc:Well, Jed never did send me his whitepaper, probably because he didn't feel like having me shit on it.
05:23:25amiller:bramc, ripple has *a* whitepaper that i believe is true to jed's algroithm, but it sucks
05:23:49bramc:amiller, He told me this after he'd left ripple, but maybe he was talking about the same thing
05:23:56gmaxwell:I'm still a bit torked that I _specifically_ pointed out exactly this failure mode back when ripple was originally announced and even only barely described (as they didn't provide any real documentation basically for years); and they're all happily pretending that this was some huge surprise.
05:24:24gmaxwell:(Amiller also pointed this out)
05:24:27bramc:Although the first time he told me about how it worked I shat on the idea that there were going to be any other servers participating in the consensus building. That was before I knew about bitcoin's loophole in such difficulties.
05:24:38amiller:i told jed on the phone this in like jan 2013
05:25:09amiller:gmaxwell, i think what you are saying is that the stanford prof was on their roster even prior to their forkpocalypse?
05:27:09gmaxwell:amiller: Yes sir. David Mazières https://web.archive.org/web/20141110135852/https://www.stellar.org/ (archive.org is screwy and won't seem to load the snapshots on the day stellar was made public)
05:27:27moa:I think stellar has ricardian contracts, so a brighter supernova?
05:28:49gmaxwell:amiller: which is part of why I found this https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/ to be pretty dishonest sounding.
05:28:55amiller:i don't think that matters, maybe i'm just a sucker for academic social proof... i'm still giving prof mazieres the benefit of the doubt and eagerly awaiting what they come up with next... my speculation is that it's going to be technically sound but 'not-all-that-decentralized'
05:29:10bramc:The web pages which turn up when searching for 'ricardian contracts' read like they were written by marketing droids.
05:29:22gmaxwell:sure, it's not hard to make something sound; thats part of why it was so horrifying what they had before.
05:29:47amiller:circadian contracts
05:29:57moa:good one
05:30:13amiller:* amiller quits while ahead
05:30:13moa:self-signed circularity
05:31:24gmaxwell:bramc: in any case the thing where the ripple/stellar consensus model is broken is just that that it's a quourom protocol where the participants don't necessarily have identical views of the membership. If you centeralized control of the membership via an external process, it works fine. If you don't you can end up with a topology where multiple orthorgonal majorities can exist, which means doom.
05:32:19bramc:gmaxwell, Yeah that was obvious to me from the get-go but I didn't think through all the failure modes, just figured that it was a huge pain to do it in a way which worked
05:33:31bramc:It should be possible to throw in some voting about who to let into the group of voters and the like, which has obvious vulnerabilities but works if nodes mostly work and mostly evaluate each other well.
05:33:45bramc:Like, it shouldn't fall apart when all the nodes are being run by the same company :-P
05:33:46gmaxwell:it seemed like opencoin/ripplelabs heavily controlled participation; I always assumed this meant they understood the problem and were just being dishonest about the decenteralization claims (or at least using a very weak definition of decenteralized). That stellar let it break suggests that at least some of the involved people just had no clue, even after having it pointed out to them.
05:35:11gmaxwell:bramc: yea, you can't have a system like where advertised you make your systems only listen to peers _you_ trust, but you can always have the prior membership elect a new membership. Thats not very decenteralized, ... esp since the prior membership can possibly go back and fork the history if any later membership later votes them off the island or dillutes them below their level of preference.
05:35:15bramc:Well you can't let any yahoo who volunteers be part of the voting group or overriding the majority is trivial
05:36:02bramc:gmaxwell, Presumably any such system has safeguards where peers don't allow retroactive reorgs past some point
05:36:11gmaxwell:at least in debate on bitcoin talk ripple's answer there appeared to be was just that people would configure their own trust reflecting the real world(tm) and yahoos just won't be trusted enough to matter.
05:36:56gmaxwell:bramc: IIRC the software is actually completely unable to reorg at all, though it's been a while since I looked at it. You still have an issue for nodes which had been offline (or are new).
05:38:21phantomcircuit:gmaxwell, i believe it doesn't even explode if there's a reorg
05:38:24phantomcircuit:it just ignored is
05:38:26phantomcircuit:ignores*
05:38:47bramc:This is sounding profoundly busted on a number of levels
05:39:07Taek:only if your voters or trusted nodes get corrupted
05:39:42bramc:It's completely reasonable to have a 'somewhat' centralized system, but it's absolutely critical that there be a mechanism where the voting members can vote in and out new members, and the conditions in which it forks need to be well-defined.
05:39:46gmaxwell:bramc: well thats fine if you have a true consensus system where only one majority can exist... and if the majority approves, you never change your mind. Makes things much simpler too.
05:40:14gmaxwell:but not even remotely decenteralized.
05:40:26bramc:gmaxwell, You can use the consensus system to make decisions about who gets into the voting group
05:40:46bramc:Which arguably adds a little bit of potential decentralization to the whole thing
05:41:03bramc:It at least makes it so the system won't explode just because the sysadmin screwed something up
05:41:09gmaxwell:I mentioned that above, indeed. But it's not clear how much it adds. (I suppose it would be a prudent design to support none the less)
05:41:49moa:tin foil hat ... maybe stellar was Jed's death star for ripple, sure shone a bright light on the dark side of that project whatever the case
05:42:14bramc:There doesn't seem to be any point at all to supporting distributed consensus if you don't apply it to membership as well
05:42:28bramc:Without that, it's a booby trap
05:42:57gmaxwell:bramc: well the point is perhaps regulatory indirection and playing to todays favorite flavors for asset speculation mania.
05:43:21gmaxwell:At least I'd always assumed that to be the case, the poof failure of the network seems at odds with that. "I notice I am confused" ::shrugs::
05:43:49gmaxwell:kinda sad, there are plenty of legit applications for reduced risk centeralized transaction systems.
05:44:00phantomcircuit:gmaxwell, why not both?
05:44:49moa:"When the Ripple network was created, 100 billion XRP was created. The founders gave 80 billion XRP to the OpenCoin Inc. OpenCoin Inc. will develop the Ripple software."
05:45:11sipa:it seems that you really just want to admit a system is centralized, and get the best out of that
05:45:34bramc:Even a centralized 'cryptocurrency' at least has public key stuff going for it, so the centralized system can't forge transfers
05:45:39gmaxwell:sipa: we don't have good language for this stuff; centeralized or not is a binary distinction but the real risk analysis is more complex.
05:45:48sipa:agree
05:46:21sipa:it seems a 'fixed' version of ripple is a federation with consensus-approved membership changes
05:46:27gmaxwell:bramc: well the ripple stuff can forge transfers fine. It has a consensus ledger, not a consensus history. So if the voting nodes decide that you really have 2000 trillion ripples, thus it is so.
05:46:46sipa:which is definitely not centralized in a distributed systems meaning (it has no central point if failure)
05:47:08bramc:There is interesting stuff in ripple about making new 'currencies', but that doesn't need any cryptocurrency stuff to be done, arguably is better off being centralized.
05:47:31bramc:gmaxwell, Oh right, that's true
05:48:09bramc:That leaves basically none of the elements of actually being a cryptocurrency
05:48:17gmaxwell:well the original ripple stuff (ryan fluger's work) didn't need a consensus at all for the most part (there was some complexity about atomically killing a partially completed order); for the most part the transactions were all participant to participant; as it is a debt network.
05:49:58gmaxwell:E.g. If I want to pay you but you won't accept my IOUs, but you'll accept sipa ones, and sipa will accept my IOUs.. this is something we should be able to work out among ourselves without extensive participation in a global consensus network.
05:50:56bramc:gmaxwell, Yes and this all sounds fairly reasonable for talking about, say, RMB deposits
05:51:00phantomcircuit:gmaxwell, interactively it's easy
05:51:06phantomcircuit:otherwise not so much
05:51:22bramc:But having centralized auditing makes it all so much easier.
05:51:25gmaxwell:yes indeed, making transactions span offline people was one of the excuses given for adding the global consensus network.
05:52:26moa:and the 'gateways' would handle the most of the debt confusion users experienced figuring out who owed or owned what
05:52:31bramc:It seemed like ripple was a good system for setting up an RMP<->USD conversion market
05:52:40gmaxwell:though there is no reason I could come up with where you couldn't have a system that was truly person to person; but supported delegating your identity to a federation of signers (a _little_ consensus network) that acted in your stead.
05:52:40bramc:I mean RMB, not RMP
05:52:47phantomcircuit:gmaxwell, which is amusing since the only thing people use is always on trusted gateways
05:53:14sipa:what is RMB?
05:53:38bramc:gmaxwell, it being centralized allows the trusted third party to do basic auditing of how much debt everybody claims they've issued
05:53:45phantomcircuit:sipa, chinese currency
05:53:48bramc:sipa, renminbi, aka the yuan, the chinese currency
05:54:18sipa:ah
05:54:29gmaxwell:bramc: sure, though you could also do that with a potentially seperate centeralized network per user as part of that users identity. Even parts that could benefit from centeralization or consensus don't need to be global.
05:55:10bramc:sipa, If my understanding of the thing about schnorr signatures you scrawled is correct, collaborative 2-of-2 schnorr signatures are as simple as adding up our public keys to get the joint public key, and adding together our individual signatures of something to get the joint signature
05:55:35sipa:yup
05:55:40gmaxwell:You shouldn't care how much debt _I_ have issued, because it's sipa thats obligated to pay you. (you would, however, care about what his exposure is).
05:55:46sipa:but you need to agree on a public nonce first
05:56:11bramc:gmaxwell, A lot more shenanigans are possible without the trusted third party, and allowing the debts to flow freely between them requires centralized information to work well.
05:57:00bramc:sipa, Is the nonce one time or repeated? Can it be derived from the hash of the thing to be signed?
05:57:49bramc:Supposedly Stellar is doing massive business now, anybody know if that's true and if so what their business actually is?
05:57:54gmaxwell:bramc: I think you're missing the point there though. Yes, you need a TTP of some kind to help you audit sipa's activity (whom you moderately trust) ... but you don't care about me, and I could be off in china, using a different TTP for auditing of my activity.
05:58:01sipa:bramc: so typically you do ECDH simultaneously with signing
05:58:53phantomcircuit: You shouldn't care how much debt _I_ have issued, because it's sipa thats obligated to pay you. (you would, however, care about what his exposure is).
05:59:00phantomcircuit:it's not really that simple though
05:59:07sipa:so everyone picks a secret nonce (potentially deterministically from message + your own private key)
05:59:11phantomcircuit:everybody in the debt chain is potentially liable
05:59:28sipa:publishes the public point associated with thir nonce
05:59:39sipa:everyone adds all public nonces together
05:59:50sipa:including their own
05:59:58sipa:and the result is the public nonce used
06:00:14sipa:this results in people not knowing eachother's private nonces
06:00:16gmaxwell:phantomcircuit: at least how ripple was proposed, when you paid someone your IOU you were absolutely obligated to make good on it. If other people screwed you on IOUs they owed you, that was your problem.
06:00:51bramc:sipa, I think I follow well enough to get the message flows right. They're very simple.
06:01:15gmaxwell:phantomcircuit: no clue if it would work out in the real world(tm), but at least thats the idea as I understand it.
06:01:24bramc:Basically we all agree on what we want to sign, and we all make our part of the signature, and any yutz, even someone who isn't one of us, can combine them to make the signature proper
06:02:23phantomcircuit:gmaxwell, im pretty sure that wouldn't work in the "real world"
06:02:35phantomcircuit:since you're basically passing bad notes
06:03:31gmaxwell:phantomcircuit: it's not a 'passing' though. nothing flows through anyone. I recieve a object of type A, and give someone else an object of type B.
06:04:02sipa:bramc: right, but it's not "everyone signs and then adds sigs", it is "everyone publishes nonce, everyone receives everyone's nonce, everyone signs, someone adds the sigs together"
06:04:14sipa:bramc: there are necessarily 2 communication rounds
06:04:25gmaxwell:Of course, it's more relistic if the asset is bitcoin; and then you can do constant automatic settlement on the backend, along with proof of solvency, so it can never get too far out of wack for too long.
06:04:32sipa:unless you have predetermined public nonces which are usable only once
06:04:34bramc:sipa, Gotcha, thanks
06:04:48phantomcircuit:gmaxwell, eh i suspect you'd have a hard to arguing that in court
06:04:56bramc:gmaxwell, It's nice to have simultaneous transfer
06:05:08phantomcircuit:but i suspect you'd have a hard time arguing about this at all in court
06:06:28moa:^^ which goes for anything crypto rpretty much
06:07:53gmaxwell:phantomcircuit: perhaps, it's a weaker security model for sure; where I'd talked about it on bct was always in the context of vending machines and paying for songs and such.
06:23:47phantomcircuit:gavinandresen, your pr to switch to txid caching is likely broken as gmaxwell pointed out
06:26:42gmaxwell:phantomcircuit: I am not sure about that. some of the tests that it breaks are redundant ones.
06:27:22gmaxwell:but I do think it wouldn't be hard for it that to be an issue or become an issue.
07:06:05phantomcircuit:gmaxwell, sure and there's no reason it couldn't work like that (well except the dos issue which seems to be a non issue)
09:05:15wilhelm.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: andy-logbot Dr-G2 p15 rusty Guyver2 Emcy luktgf luny zwischenzug tromp__ NewLiberty Starduster_ cryptowest justanotheruser dgenr8 wallet42 cornus_ammonis ryanxcharles jtimon [7] CodeShark orik wizkid057 coiner zooko Guest86789 xabbix gonedrk DougieBot5000 comboy nsh binaryatrocity Taek moa PRab arubi adlai iddo embicoin EasyAt fanquake andytoshi Burrito irc88 spinza waxwing maaku amincd LarsLarsen Logicwax dc17523be3 Quanttek Pan0ram1x
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: melvster1 c0rw1n flower helo null_radix bosma PaulCapestany sipa btcdrak cluckj NikolaiToryzin prodatalab GAit huseby s1w bepo nuke1989 Visheate crescendo livegnik asoltys_ optimator gribble fluffypony Meeh gavinandresen cursive yoleaux dansmith_btc ebfull [d__d] berndj Luke-Jr weex morcos nickler jgarzik Fistful_of_Coins dardasaba sl01 isis gwillen stonecoldpat BlueMatt face hashtag_ MoALTz airbreather delll_ dasource espes__ GreenIsMyPepper
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: bedeho Cory tripleslash tromp_ shesek smooth phantomcircuit ajweiss sdaftuar grandmaster coryfields Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis cfields platinuum sneak Oizopower bbrittain jaromil jcorgan wumpus BrainOverfl0w roasbeef phedny so hguux__ otoburb MRL-Relay azariah HM2 btc___ throughnothing @ChanServ brand0 Alanius davout Hunger- NeatBasis mr_burdell bliljerk101 DoctorBTC nanotube
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: d9b4bef9 SubCreative a5m0 harrow fenn paperbot Anduck guruvan epscy Apocalyptic CryptOprah leakypat TD-Linux K1773R indolering warptangent amiller veox Eliel ryan-c Graet ahmed_ jessepollak kinlo dignork lechuga_ Iriez Adrian_G copumpkin gmaxwell warren gnusha heath midnightmagic grubles wiz jbenet mappum go1111111 jaekwon pigeons eric kanzure petertodd JonTitor catlasshrugged Keefe BananaLotus
09:50:52fanquake_:fanquake_ is now known as fanquake
10:43:47embicoin_:embicoin_ is now known as embicoin
11:41:14melvster1:melvster1 is now known as melvster
13:37:21hearn:good afternoon wizards
16:55:34Guest86789:Guest86789 is now known as starsoccer
17:21:56gmaxwell:How Bitcoin users treat Bitcoin developers, episode 37: "when you let devs control anything beyond where to put the commas and braces in the code it is almost never successful by any rational metric"
17:22:00intsagibbs:we were discussing payment channel implementations a bit back, here's a hub-spoke model that I didn't see discussed: http://lightning.network/lightning-network.pdf
17:25:37fluffypony:off topic, but...http://www.nytimes.com/2015/02/27/arts/television/leonard-nimoy-spock-of-star-trek-dies-at-83.html
17:26:11gmaxwell:oh thats sad. Indeed, OT but thanks.
17:35:01justanotheruser:That's fine, he can just use 0.1 or even fork it to make the spacing prettier
17:37:05fluffypony:lol gmaxwell - my favourite are the users that complain about something: "devs are useless, they haven't fixed X in 6 months!" and then when you prioritise it after much complaining you get the other lot going: "this is not important, devs are wasting their time on this when they should be doing Y"
17:38:11intsagibbs:gmaxwell: the CEO of Bitcoin wants to talk to you about your job performance
17:38:29fluffypony:and, of course, the loudest of them all haven't donated a cent or contributed a single line of anything