00:05:49 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
02:17:29 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
02:19:44 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
02:24:14 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
04:50:04 | OneFixt_: | OneFixt_ is now known as OneFixt |
07:08:56 | Guest84438: | Guest84438 is now known as maaku |
07:09:26 | maaku: | anyone here interested in decentralized prediction markets, send me a PM |
07:43:55 | Taek: | maaku are you talking augur or truthcoin? |
08:25:54 | lclc_bnc: | lclc_bnc is now known as lclc |
08:43:41 | lclc: | lclc is now known as lclc_bnc |
09:05:15 | kornbluth.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:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: andy-logbot cbeams_ Guyver2 RoboTeddy op_null paveljanik Emcy_ hguux_ ryanxcharles Greed` TheSeven PRab Aquent Dr-G2 warptangent Graftec gues devrandom waxwing Fistful_of_Coins rusty jgarzik phantomcircuit wumpus heath koshii luny HM2 Hunger- paperbot hashtag_ coiner wallet42 Baz__ kefkius zibbo ebfull SubCreative samson_ nuke1989 maaku epscy OneFixt Transisto go1111111 Starduster prodatalab lnovy EasyAt Shiftos c0rw|zZz jaekwon_ Cory |
09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: digitalmagus LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ Guest6066 grandmaster HaltingState null_radix Luke-Jr fenn shesek bosma tdlfbx iambernie mr_burdell adlai tacotime mkarrer nsh_ yoleaux btc__ Graet Logicwax andytoshi pi07r Meeh starsoccer PaulCape_ DoctorBTC NikolaiToryzin nsh btcdrak mappum tromp K1773R ahmed_ artifexd nanotube dansmith_btc kanzure spinza Flyer33 arowser1 Anduck Nightwolf hollandais berndj lclc_bnc |
09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: s1w Eliel_ bobke LaptopZZ isis sneak harrigan gavinandresen JonTitor sl01 Grishnakh sipa Alanius jbenet kumavis Muis MRL-Relay fluffypony BlueMatt a5m0 gazab AdrianG gwillen livegnik BananaLotus @ChanServ burcin coutts wizkid057 Dyaheon bbrittain nickler tromp_ Krellan poggy comboy mmozeiko Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away gmaxwell so [d__d] espes BigBitz jaromil helo Keefe Iriez |
09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: huseby phedny midnightmagic BrainOverfl0w warren pigeons asoltys gribble smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow lechuga_ |
10:29:46 | Greed`: | Greed` is now known as Greed |
12:19:17 | gmaxwell: | amiller: https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/ |
12:55:35 | op_null: | gmaxwell: oh that's hilarious |
12:57:17 | gmaxwell: | yea, if only someone had pointed this stuff out to them in 2013 before even any of their code was published ( https://bitcointalk.org/index.php?topic=144471.msg1551096#msg1551096 ) |
12:58:11 | op_null: | "just set a reorg limit say 100 blocks" that sounds familiar. |
13:59:46 | kanzure: | "The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), guaranteed termination or liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of one node at any point). This is a proven result. Any distributed ... |
13:59:52 | kanzure: | ... consensus system on the Internet must sacrifice one of these features." |
14:01:24 | kanzure: | "This situation has led us to believe it is no longer safe to run the existing Ripple/Stellar consensus system with more than one validating node because doing so would expose funds in the network to potential double spends and ledger forks." |
14:01:32 | kanzure: | ("Each participant in the ripple network has a list of validators. This list is also known as a unique node list UNL. Every validating node that is online will see all transactions. Periodically all nodes will try to validate or close a new ledger.") |
14:01:42 | kanzure: | so uh they have disabled consensus? |
14:01:48 | kanzure: | *disabled (broken) consensus? |
14:05:47 | gmaxwell: | at that event I was at on tuesday someone had a pretty vigorous argument with me that their consensus was provably correct, meanwhile I'm pointing out that it's not stable even absent an attacker. I didn't expect such a well timed response there. |
14:06:42 | kanzure: | insert quip here about those who are willing to wait |
14:07:36 | gmaxwell: | There certantly are designs that can get you a consensus safely, if you abandon decenteralization as a goal and don't mind losing a fair amount of fault tolerance. |
14:08:24 | kanzure: | as far as i can tell, switching to centralization is still an option for them, given the sorts of promises that the stellar people have made i think |
14:08:46 | gmaxwell: | now I wish I hadn't been pulled into an interview during the time the stellar panel was running; one of the other attendees was nagging me to give them hell on that point. Would have seemed especially predictive. |
14:08:48 | kanzure: | i mean, they have not made decentralization and distributed consensus their particular crusade, so if they don't want to bother then they should just lose all of that extra architecture fluff |
14:09:34 | kanzure: | er, by which i mean the latest marketing from stellar, not ripple i guess |
14:10:03 | op_null: | stellar might as well just be called ripple. there's no functional changes from opencoin ripple are there? |
14:10:09 | gmaxwell: | Well I don't think they ever had an actual decenteralization argument to begin with... basically the fragility of their model was so obvious I can't believe they believed it themselves. (See the BCT thread; it's easy to draw UNL topologies which are _guarenteed_ to fail by change) |
14:10:37 | kanzure: | it would be interesting to see if the trend of altcoins and poorly-implemented non-consensus consensus systems over the long-term creates a demand for developers capable of safely transitioning to centralized systems from project owners |
14:10:41 | gmaxwell: | s/change/chance/ |
14:11:15 | op_null: | kanzure: remember that a lot (if not most) altcoins are already centralised entirely. |
14:11:18 | kanzure: | has anyone actually demonstrated a competent "wind-down" of "distributed consensus" into a centralized system? |
14:11:25 | kanzure: | they are "centralized" but yet they still have all this bitcoin client nonsense |
14:11:32 | kanzure: | all of that can go away if you're doing centralization |
14:11:37 | op_null: | if they didn't people wouldn't use them |
14:11:49 | kanzure: | okay fine, offer a client but it doesn't have to be bitcoind |
14:12:24 | op_null: | you could probably release a client that looks like bitcoin core but just connects to a central database and not many people would notice. |
14:12:25 | kanzure: | there are a set of steps to migrate all the extra non-working stuff off of your network into a more efficient system |
14:12:29 | kanzure: | right |
14:12:32 | kanzure: | things like that |
14:12:33 | gmaxwell: | well the ripple software is more sutable in that capacity. |
14:13:28 | kanzure: | i wonder how to convince people with broken consensus systems that it's worth paying someone to do that sort of network migration |
14:13:47 | kanzure: | clearly they already don't care aobut security, so arguments about security benefits wont work |
14:14:06 | op_null: | I don't think there's a demand for that. systems like darkcoin are centralised but their model relies on them pretending that they're not. |
14:14:32 | kanzure: | if they want to make convoluted lies then there's much better ways to do that in software that do not require the complexity of bitcoin |
14:15:04 | kanzure: | it can just be some sort of lie machine that spits out software that connects to centralized systems that lie about stuff |
14:15:30 | op_null: | easier to modify bitcoin than build something better from scratch though. I think part of the altcoin system is that because they are all based on bitcoin core, it's easy for places like exchanges to add support. drop in a new daemon, change the version byte and you're good to go. |
14:16:42 | kanzure: | a lightweight client that connects to a central server would be much easier to modify |
14:17:43 | kanzure: | stellar foundation does not seem like their existence is predicated on distributed consensus really, so why should they maintain their particular pile of software? |
14:21:59 | kanzure: | in the case of bitcoin forks, you could maybe argue something like "An unforseen bug in your unmaintained bitcoin fork might cause you to lose your 30% premine, so you should strongly consider migrating to a centralized system" |
14:23:43 | op_null: | I still think people are sold on these systems being decentralised, rather than just accepting that they are not. |
14:28:18 | kanzure: | okay, but what does that have to do with anything? implementing a centralized system is separate from marketing. plus, they are already centralized anyway, just poorly implemented. |
14:29:29 | op_null: | my comment is just that if you designed a centralised app and presented it as "yo, try our centralisec currency", nobody would use it. people use stellar and other altcoins because they are presented and coded in such a way that they look to be decentralised. |
14:30:35 | kanzure: | people don't actually review the code though |
14:30:56 | kanzure: | so fooling them by turning their centralized system into a centralized system doesn't seem particularly harmful. actually, it seems pretty safe to me. |
14:38:52 | op_null: | * op_null shrugs |
16:29:21 | wallet421: | wallet421 is now known as wallet42 |
17:08:50 | Emcy: | hey is tls using elliptic curve crypto now and does github use it for all downloads? |
17:09:16 | Emcy: | im trying to work out why my browser refuses to dl anything from github |
17:42:35 | nsh: | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys |
17:42:44 | nsh: | is what i get with firefox |
17:43:02 | nsh: | Emcy, does your browser not support ECDHE at all? |
17:43:19 | Emcy: | apparently not |
17:43:38 | nsh: | probably want to correct that, i'd guess |
17:43:42 | Emcy: | is it elliptic curve |
17:43:47 | sipa: | yes |
17:44:03 | Emcy: | neat. That must have come in in the last year or so |
17:44:44 | nsh: | "snowden-effect" :) |
17:45:21 | kanzure: | haha, "How'd you centralize your decentralized system? It sounds like something that shouldn't be possible unless it's actually centralized to begin with." https://news.ycombinator.com/item?id=8708844 |
17:45:25 | Emcy: | yeah |
17:45:57 | Emcy: | kanzure microsoft wrt skype |
17:46:21 | fluffypony: | oh I thought that was a comment on Darkcoin |
17:46:24 | fluffypony: | :-P |
17:46:58 | kanzure: | as funny as his comment was, it is trivial to centralize any decentralized system as long as you do not care about popularity of your centralization |
17:47:27 | kanzure: | er, subject to one or two extra constraints that i am forgetting? |
17:49:24 | nsh: | that's quite general a statement, too much so for me to have any idea what it means |
17:54:55 | kanzure: | well, anyone can take a blockchain of data and convert it into some central ledger that does not run a p2p consensus node |
17:56:51 | sipa: | or run a single node of an otherwise decentralized system, and just advertize its state |
17:57:16 | op_null: | oh like proof of text? |
17:57:21 | op_null: | .. stake |
17:57:31 | op_null: | no idea how that got in there. |
17:58:56 | Emcy: | nsh im glad the technologists are stepping up where elected representatives failed |
17:59:01 | Emcy: | really glad |
17:59:29 | nsh: | it's something at least :) |
17:59:37 | Emcy: | who said a technocracy is a bad thing.. |
18:00:17 | nsh: | people who don't like the peer-selection of technological merit and prefer their own technocrats, generally |
18:00:42 | Emcy: | nsh yes its something. At the very least it pushes back against any perception that civil society consented to the hand up the skirt |
18:01:04 | nsh: | * nsh nods |
18:01:44 | kanzure: | haha "So, to illustrate a fork, color a majority of the circles one color and then simultaneously color a different majority another color. Clearly, this is impossible." |
18:01:54 | kanzure: | (from https://forum.ripple.com/viewtopic.php?f=1&t=8629&start=0#p59073 ) |
18:03:02 | op_null: | isn't that just classic sybil time? |
18:20:55 | gmaxwell: | kanzure: I can't believe Joel is still pushing that broken view. Yes, what he's saying is strictly correct but it requires every single participant to have the same list of nodes, set out in advance... Which isn't something they claim to require (because it appear incompatible with decenteralization) |
18:21:17 | kanzure: | have you ever been able to figure out where his fundamental hangups are coming from? |
18:21:26 | kanzure: | like what does his objections actually distill to |
18:23:12 | gmaxwell: | Well you can see that wtf ripple thread, I drew a number of topologies which were guaranteed to suffer irrecoverable convergence failure, even if there is no attacker... and his only answer was "just don't configure the network that way". I was unable to extract any argument about what _precisely_ was the topology requirement, and how they had any hope to achieve that requirement (at all), much less absent some central party. |
18:23:56 | gmaxwell: | One sufficient criteria is for everyone to have the same UNL at all times, which seems to suggest you need some trusted party to administer the UNL (otherwise something has to stop me from filling it with clones) |
18:25:01 | gmaxwell: | It's not necessary though, other graphs are also stable... but no clue how to achieve any admissable graph in a decenteralized manner. "Add whom you trust" seems to be almost a pessimal construction, since social graphs are very clique-heavy. |
18:27:17 | kanzure: | any speculation as to why he thought it was acceptable to suggest not configuring networks like that? |
18:29:27 | nsh: | an idiomatic understanding of robustness, i guess |
18:29:27 | gmaxwell: | Presumably stuck in centeralized thinking? I mean, I think it's completely reasonable to build centeralized systems too... |
18:31:15 | kanzure: | well, if i was designing a centralized solution, his solution is not one i would pick |
18:31:22 | kanzure: | there are many improvements i could offer for that |
21:25:57 | roidster: | roidster is now known as Guest61156 |
22:16:50 | nsh: | -- |
22:16:50 | nsh: | <tarcieri> nsh: their ledger forked, and they claim it's because their consensus algorithm is buggy |
22:16:50 | nsh: | <nsh> oh my. good thing they got rid of PoW and simplified stuff as you lauded yesterday |
22:16:50 | nsh: | <nsh> kekek |
22:16:51 | nsh: | <tarcieri> they're making a new consensus algorithm in conjunction with an academic, and it will be proven correct by formal models |
22:16:54 | nsh: | <nsh> sorry, i'm a terrible human being |
22:16:56 | nsh: | <tarcieri> lol |
22:16:59 | nsh: | -- schaudenfreude is sometimes indicated |
22:17:18 | nsh: | re: https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/ |
22:17:47 | kanzure: | i don't think the fork is the notable aspect there at all |
22:17:52 | nsh: | i doubt this proven correct by formal models thing will go exactly as envisioned either, but it'll be fun to watch in any case |
22:17:59 | nsh: | kanzure, oh? |
22:18:04 | nsh: | * nsh reads the post whynot |
22:19:21 | kanzure: | "turning off" decentralization seems more notable there... |
22:21:45 | nsh: | oh, is this what you were talking about earlier? |
22:22:43 | kanzure: | yeah |
22:23:10 | nsh: | oh right, they reduce to a single validating node |
22:23:28 | nsh: | so basically give up everything that makes it anything like progress |
22:23:50 | kanzure: | arguably a broken distributed consensus system is not progress |
22:24:18 | kanzure: | and any broken distributed consensus system that is subject to attack is basically quite similar to a centralized system in function or operation |
22:24:43 | nsh: | if can break in didactically useful ways. or at least serve as an object lesson in misinvestment of effort |
22:24:47 | nsh: | *it |
22:24:59 | nsh: | * nsh nods |
22:58:18 | kanzure: | "Each shard is uniquely encrypted. This means that malicious farmers cant pretend to have multiple redundant copies of a file when they only have one." |
22:58:25 | kanzure: | this seems pretty false (since you can ask a peer) |
22:59:08 | kanzure: | oh, if you assume a central way of distributing salts, that could work, but defeats many of the other purposes |
23:04:21 | kanzure: | wow, the section on sybil resistance doesn't respond to sybil attacks at all... |
23:04:54 | kanzure: | (i screwed up and loaded the latest storj whitepaper and i regret this) |
23:05:39 | kanzure: | haha "This way, even if one of the nodes is malicious, it cannot fully carry out this attack. Nodes would have to be colluding, and if the client selects nodes randomly, the probability of selecting colluding nodes is small." |
23:16:40 | op_null: | kanzure: I had a logical trouble with it too. they say that each shard is uniquely encrypted right. but then it says later on that the network can recover from loss by dupicating the data from the peers that still exist. |
23:17:26 | op_null: | kanzure: which they can't do, because then you'd have multiple peers all with the same encrypted version. |
23:18:13 | kanzure: | you may have just broken the universe |
23:19:06 | op_null: | I can't believe they overlooked that, but all the same it doesn't make sense. |
23:22:16 | op_null: | "If a node fails an audit or is unreachable, we initiate a network replicationprocess whereby we take one of the existing copies on the network and trans-fer it to a new node." |
23:22:30 | op_null: | "Each shard is uniquely encrypted. This means that malicious farmers cant pretend to have multiple redundant copies of a file when they only have one." |
23:23:13 | op_null: | the two statements are just completely incompatible, aren't they? |
23:26:21 | kanzure: | to be fair, they are probably taking about the file owner in the first quote |
23:27:36 | op_null: | it says "from the network" not "from the owner" though |
23:28:43 | kanzure: | true, a file owner could presumably access a network copy |
23:29:39 | kanzure: | also, there can always be multiple redundant copies of a file that are not uniquely identifiable |
23:29:47 | kanzure: | you can have truly unique copies of a file even if they have the same content |
23:30:00 | op_null: | I took "we" to be the autonomous network rather then the owner. ultimate cloud storage seems a bit silly if you have to be online all of the time to make sure it doesn't get deleted. |
23:34:28 | op_null: | I guess you're right though. |
23:44:12 | kanzure: | there's many other problems going on here :) |
23:44:34 | kanzure: | plus, i could be wrong and they really do mean network |
23:49:29 | op_null: | there's a comment about trying to choose close nodes to you for maximum speed. isn't that exactly what you don't want? |
23:50:47 | op_null: | "As with the standard functionality of a peer-to-peer network, we can connectto geographically close peers to achieve high transfer speeds." |