| 01:09:08 | CodeShark: | How do we design a decentralized consensus protocol that is generally extensible while minimizing the need for hardforks? |
| 01:10:22 | CodeShark: | i.e. extensible headers and abstract data types seem like a good start |
| 01:29:27 | justanotheruser: | CodeShark: maybe we could allow people to transfer wealth between different blockchains with different rules where the blockchains aren't in consensus with each other, but there is consensus within each individual blockchain |
| 01:29:32 | justanotheruser: | I think thats actually being implemented |
| 01:30:48 | justanotheruser: | We can't allow people to vote on the rules or you have NaS problems. We could allow miners to decide the rules, but everyone would have SPV security. What you are left with is what I just mentioned |
| 01:36:56 | CodeShark: | sidechains can help bootstrap the development...but I think my question is less about the decision process in adding improvements - more about how to design the protocol such that deploying such improvements amounts to just flipping a switch |
| 01:40:33 | CodeShark: | well, I guess there are two issues here - one is how the implementation itself is distributed...the other is how we switch over to it with as little disruption to the existing network as possible |
| 01:41:28 | kanzure: | you mean each user/operator flips the switch, or who flips? |
| 01:41:47 | CodeShark: | that's still an open issue - assuming we had a solution to this issue |
| 01:41:59 | justanotheruser: | CodeShark: who decides what new consensus rules are valid? |
| 01:42:18 | justanotheruser: | the miners? the stake holders? A not-sybil-resistant majority of nodes? A central authority? |
| 01:42:42 | CodeShark: | well, right now it's the core developers, I suppose |
| 01:42:49 | CodeShark: | but setting that issue aside |
| 01:42:58 | justanotheruser: | no, the miners decide softforks |
| 01:43:07 | justanotheruser: | there have been no hardforks |
| 01:43:32 | CodeShark: | the miners decide on softforks that are proposed by the core developers |
| 01:43:57 | justanotheruser: | or they could decide on softforks proposed by a homeless guy |
| 01:44:08 | rusty: | justanotheruser: yes, there was, and the miners resolved that too. In the end, you need miner consensus, but you also need user consensus if your bitcoins are to be worth anything. |
| 01:44:11 | CodeShark: | but for the sake of discussion, imagine we had a procedure in place for reaching consensus on new protocol rules |
| 01:44:23 | CodeShark: | my question is more about the mechanism for its deployment |
| 01:44:27 | justanotheruser: | rusty: what hardfork |
| 01:44:50 | CodeShark: | everyone agreed "yes, I love feature X - let's add it" |
| 01:44:57 | rusty: | justanotheruser: the large block hardfork. https://bitcoin.org/en/alert/2013-03-11-chain-fork |
| 01:44:59 | CodeShark: | we have an implementation for it and it's been tested |
| 01:45:05 | CodeShark: | now how do we deploy? |
| 01:45:45 | justanotheruser: | rusty: that wasn't a hardfork to my understanding |
| 01:45:56 | CodeShark: | actually, miners didn't resolve that one - and it was a hardfork due to a bug |
| 01:46:06 | justanotheruser: | CodeShark: see above |
| 01:46:10 | rusty: | justanotheruser: not a deliberate one, no... and CodeShark, they certainly did, by downgrading. |
| 01:46:24 | CodeShark: | miners did so by STRONG encouragement from the core devs |
| 01:46:35 | justanotheruser: | afaik, that was more of a softfork if you can call it that |
| 01:46:47 | CodeShark: | many miners would have liked to just stay on the nonbuggy chain |
| 01:47:15 | CodeShark: | the majority of hashing power was on the nonbuggy chain |
| 01:47:44 | rusty: | CodeShark: in pettycoin, I had a features field in the tx and the block. Default implementation of miner set the features field corresponding to the majority of txs in the block. If a feature got a supermajority in a fortnight block, the version number was bumped 4 weeks later (ie. you got warning that a change was coming). |
| 01:48:24 | justanotheruser: | the problem was that 0.7 broke consensus with itself. There was a database bug that meant that it wasn't deterministically in consensus with itself. |
| 01:48:44 | justanotheruser: | 0.3 still can still achieve consensus with 0.9.3 |
| 01:49:05 | rusty: | justanotheruser: new clients accept and old clients don't == hardfork. I don't know what else to call it. |
| 01:49:07 | CodeShark: | or at least the rules were not really known, even if deterministic |
| 01:49:51 | CodeShark: | if everyone implements the same bug which changes consensus rules, the implemented rules become the *real* rules |
| 01:49:55 | justanotheruser: | rusty: some 0.7 clients still worked |
| 01:50:06 | justanotheruser: | rusty: 0.7 broke consensus with itself. |
| 01:51:00 | CodeShark: | anyhow, there hasn't really been a deliberate hardfork, has there? |
| 01:51:30 | justanotheruser: | no |
| 01:52:33 | rusty: | justanotheruser: true, you could configure it to break consensus, but that's hardly relevant. Your question requires analysis of the various players, and we have one real data point. Insisting any one of users/miners/devs has/hasn't power is an oversimplification. |
| 01:53:11 | justanotheruser: | here is discussion on what 0.7-0.8 was (it's pretty short) http://hastebin.com/ofuqizomuw.xml |
| 01:54:19 | e1782d11df4c9914: | that langsec video was very enlightening, to whomever had posted it up above |
| 01:54:53 | justanotheruser: | 0.8 was a non-deterministic-hardfork-softfork-non-deterministic-hardfork-deterministic-softfork-fork |
| 01:55:03 | CodeShark: | hah |
| 01:55:55 | rusty: | CodeShark: See the P2SH deployment BIP (16). That method is probably the one which would be used in future, given it worked. |
| 01:56:18 | justanotheruser: | p2sh deployment was a softfork and no one broke consensus... |
| 01:56:43 | justanotheruser: | it's completely different. You just need a majority of miners to upgrade and no one gets hurt. In a hardfork *everyone* needs to upgrade. |
| 01:58:24 | justanotheruser: | If a hardfork is completely necessary, you should make it so it is active in the amount of time that hurts the collective users the least. The way you can hurt the users is A) through the entire userbase not upgrading in time and suffering the consequences the hardfork was trying to prevent or B) users not upgrading fast enough and breaking consensus |
| 01:58:32 | justanotheruser: | really, what do you need a hardfork for though? |
| 01:59:03 | rusty: | justanotheruser: >1MB blocks will be a hardfork, AFAICT. |
| 01:59:21 | rusty: | justanotheruser: weakening SHA256 would be another, but that's more speculative. |
| 01:59:45 | justanotheruser: | rusty: I don't think a blocksize increase will happen, but I could be wrong |
| 02:00:17 | justanotheruser: | Increasing the blocksize only solves the problem until the transaction volume matches up with the blocksize once again |
| 02:01:00 | justanotheruser: | and its a controversial hardfork. |
| 02:02:29 | rusty: | justanotheruser: I disagree; I think it will happen. I think the controversy means it will be done in some minimal way (eg. ceiling increased at some set rate) with no other changes despite the temptation to break everything at once. |
| 02:03:31 | gmaxwell: | CodeShark: I think your mental model for how things work is at best outdated. We (bitcoin core people) no longer even have contact information for anywhere near a majority of the hashrate anymore. |
| 02:04:39 | CodeShark: | gmaxwell: I remember there having been first consensus amonst the core devs to downgrade during that incident...then a big effort to get all the big mining pools to downgrade |
| 02:04:53 | CodeShark: | not saying such an approach is still doable, let alone desirable |
| 02:04:53 | gmaxwell: | rusty: 0.7 was inconsistent with _itself_. Many (most?) 0.7 nodes happily also accepted the new chain, I haven't checked recently but I wouldn't be surprised if unmodified pre 0.8 would sync up the current chain now, it did for a long time into 0.8, only to sometimes fail on reorg depending on the particulars of the nodes past state. |
| 02:05:07 | moa: | if transactions rates die the ceiling will not need to be lifted arbitrarily |
| 02:05:40 | CodeShark: | gmaxwell: I also remember there being an offer extended to the mining pools who lost bitcoins to compensate them from Bitcoin Foundation funds |
| 02:05:53 | gmaxwell: | CodeShark: go look at the log :) , downgrading was proposed by one of the large mining pools (luke), on the basis of it being compatible with more of the running hosts e.g. the path that was not a hard fork. |
| 02:06:07 | CodeShark: | luke is more of a core dev than a large mining pool :P |
| 02:06:09 | gmaxwell: | At the time we didn't know the split was non-determinstic and mistook it for a plain hardfork. |
| 02:08:24 | gmaxwell: | CodeShark: and there wasn't a "big effort" slush (who'd triggered the event and elu. were already in the room; and with luke they were a supermajority of the hashrate.) The whole thing was partially as much of a shitshow as it was because miners were running software that was inconsistent with the vast majority of the network (as they updated quickly). |
| 02:09:09 | CodeShark: | gmaxwell: details aside, I think it's a scenario that most of us would like to generally avoid |
| 02:09:26 | gmaxwell: | justanotheruser: BIP16's deployment was minorly consensus breaking. A better example would be BIP34. |
| 02:09:57 | rusty: | gmaxwell: Ah, thanks for the clarification. I only read the alert and the summary, which imply it's all 0.7 vs all 0.8. |
| 02:10:21 | gmaxwell: | justanotheruser: there were some number of orphan blocks because the transactions BIP16 made invalid were IsStandard. |
| 02:10:29 | moa: | it was actually a good example of how the miners will not hardfork onto a minority branch |
| 02:11:00 | gmaxwell: | rusty: the summary was written before it was really completely misunderstood. Oh well. It's so widely misunderstood now that I'm sure that'll become the "truth" in the history books. |
| 02:11:06 | gmaxwell: | moa: I agree. |
| 02:11:32 | moa: | at least the ones that were awake |
| 02:11:35 | rusty: | gmaxwell, moa: yeah, if bitcoin fails we don't need to worry about hardforks? :) |
| 02:12:05 | rusty: | (Oh, I was responding to moa's previous comment re: tx rates dying) |
| 02:12:05 | gmaxwell: | rusty: Basically implicit BDB behavior would make it take upto 2x the number of locks depending on the layout of the records on disk, which was not a pure function of the blockchain-- depended on things like startup/shutdown history and reorgs. |
| 02:13:25 | gmaxwell: | rusty: 0.7 could happily have had this fault all on its own even if 0.8 was never released. (the triggering event wasn't 0.8 either, it was slush upping his maximum block size after being bugged by someone) |
| 02:14:23 | gmaxwell: | ( https://bitcointalk.org/index.php?topic=149668.0 ) |
| 02:17:48 | gmaxwell: | CodeShark: I think whas justanotheruser was saying was basically that if sidechains are successful they remove that issue. You make your changes to a sidechain and then move things onto it, so there is no flag day; not in terms of decision or approval, and not in terms of a technical software transistion. |
| 02:30:41 | CodeShark: | gmaxwell: what about the security model? |
| 02:31:21 | CodeShark: | gmaxwell: I suppose you'd also need to get miners to switch over to the new chain |
| 02:33:53 | BlueMatt: | ;;later tell adam3us yes, the pebble guy and I had a marginally useful discussion afterwards |
| 02:34:04 | BlueMatt: | nanotube: wtf, where's gribble? |
| 02:34:09 | BlueMatt: | didnt it used to be here |
| 02:34:10 | BlueMatt: | ? |
| 02:35:43 | gmaxwell: | no. |
| 02:35:52 | CodeShark: | gmaxwell: how's OP_SIDECHAINPROOFVERIFY coming along? |
| 02:35:54 | BlueMatt: | D= |
| 03:17:37 | CodeShark: | I take my earlier comment regarding switching miners to the new chain back - obviously the way to do it would be to merge mine the two |
| 03:18:26 | CodeShark: | (assuming the consensus model is essentially unchanged) |
| 03:33:51 | phantomcircuit: | gmaxwell, so question, a pow function that does have forward progress should be fairly trivial right? just feed a hash function back into itself x times |
| 03:34:58 | phantomcircuit: | hmm yeah that would be entirely trivial |
| 03:58:10 | tromp: | phantomcircuit: the original Momentum proposal (find a hash collision between any two nonces) is progress-full |
| 03:59:23 | tromp: | (the hash output was limited to 50 bits) |
| 03:59:38 | phantomcircuit: | for anybody wondering this is not really for a pow |
| 05:43:25 | rusty: | Is there a variant of atomic swaps which can tolerate tx malleability? |
| 05:44:34 | rusty: | (Or am I misunderstanding the proposal in Appendix C of the sidechains paper, which seems subject to refund breakage via txmal). |
| 05:47:59 | gmaxwell: | rusty: malleability will be at the senders option in bitcoin in a couple months-ish. |
| 05:49:19 | gmaxwell: | There are two things ongoing which both seperately address this (BIP62 and BIP65). |
| 05:50:09 | rusty: | gmaxwell: right, so we're assuming that's solved. Fair enough, but a footnote in the sidechains paper would have been nice. I found the https://en.bitcoin.it/wiki/Atomic_cross-chain_trading which doesn't mention this caveat either. |
| 05:52:24 | gmaxwell: | rusty: pretty sure we actually mention it in there at some point and cite bip62. |
| 05:52:55 | rusty: | gmaxwell: hmm... CHECKLOCKTIMEVERIFY does avoid the refund TX nicely and simplifies the protocol. |
| 05:55:31 | gmaxwell: | rusty: there are other dodges, at the expense of complexity. There is a BCT post from me where I describe how to partially blind the refund which makes it so an attacker has to go after _all_ transactions rather than just one. But it's enough extra to worry about that I don't normally mention it. (but you asked for variants) https://bitcointalk.org/index.php?topic=303088.0 |
| 05:55:39 | rusty: | gmaxwell: not in appendix C. The only reference I can find is in 5.1.1 talking about things that could be done in sidechain experiments. |
| 05:57:10 | gmaxwell: | rusty: ah, darn, well thats an error of the sort that creeps in from a "did we remember to point out {foo}" spotchecks. :-/ |
| 05:57:39 | gmaxwell: | I think also at the time that text was written we expected the paper to be published later relative to BIP62. |
| 05:58:06 | rusty: | gmaxwell: thanks for the confirmation, at least I'll mention in my 1-page description of atomic swaps. |
| 08:08:29 | lclc_bnc: | lclc_bnc is now known as lclc |
| 08:55:22 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
| 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 soundx NewLiberty adam3us rusty cbeams paveljanik Profreid gavink zooko` coiner wserd tacotime Dyaheon- TheSeven spinza hashtag hashtagg catlasshrugged Dr-G2 moa jgarzik CodeShark RoboTeddy MoALTz JonTitor dgenr8 jtimon justanotheruser a5m0 cluckj e1782d11df4c9914 Guest52336 bosma ryanxcharles Logicwax jaekwon_ samson_ OneFixt maaku Emcy roconnor copumpkin mortale stonecoldpat sl01 optimator atgreen [d__d] koshii rasengan adlai |
| 09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: wiz null_radix ebfull pigeons pi07r_ Fistful_of_Coins roasbeef_ SubCreative Keefe hktud0 grandmaster luny digitalmagus8 Transisto hollandais BigBitz [\\\] michagogo Muis_ mappum epscy gnusha poggy _Iriez Meeh otoburb mr_burdell s1w go1111111 bsm117532 HM2 Apocalyptic sdaftuar waxwing btcdrak CryptOprah kumavis btc__ jbenet nuke1989 nsh jcorgan wizkid057 PaulCapestany forrestv Luke-Jr tromp_ PRab c0rw1n LarsLarsen Greed lclc harrow @gmaxwell |
| 09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: gavinandresen NikolaiToryzin Cory isis iddo sadgit brand0 eric Krellan berndj @ChanServ jaromil petertodd tromp helo v3Rve midnightmagic espes__ fluffypony butters nickler lnovy ahmed_ warren fenn phantomcircuit Graet morcos kanzure MRL-Relay Graftec bobke huseby BananaLotus amiller artifexd coryfields coutts BlueMatt cfields Anduck Eliel nanotube hguux_ AdrianG gwillen wumpus dansmith_btc heath bbrittain DoctorBTC EasyAt starsoccer danneu |
| 09:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: catcow TD-Linux ryan-c smooth mmozeiko Alanius asoltys_ K1773R comboy andytoshi lechuga_ warptangent Guest38445 kinlo azariah yoleaux sneak harrigan sipa livegnik burcin Taek throughnothing crescendo so phedny BrainOverfl0w |
| 09:27:06 | Muis_: | Muis_ is now known as Muis |
| 11:15:38 | lclc: | lclc is now known as lclc_bnc |
| 11:22:09 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:47:38 | lclc: | lclc is now known as lclc_bnc |
| 14:28:12 | wallet421: | wallet421 is now known as wallet42 |
| 14:46:19 | dgenr8: | [01/04 18:17:50] "You make your changes to a sidechain and then move things onto it" |
| 14:46:49 | dgenr8: | Things? Are you envisioning large chunks of BTC value permanently moving to a sidechain (and then another...)? |
| 14:47:15 | wumpus: | doesn't have to be permanently, you, or someone else can move them back |
| 14:49:19 | heath: | hi yrashk |
| 14:50:05 | yrashk: | hi heath |
| 14:50:54 | dgenr8: | understood, doesn't have to. it depends rather critically on when and if the desirable properties of the sidechain are added to the main chain |
| 14:54:16 | wumpus: | as I understand it you could, for example, move a few bitcoins to the alternative chain, do some crazy transaction not possible on the main chain, and then move the result back |
| 14:57:29 | dgenr8: | the context here is "sidechains as smooth upgrade mechanism". I'm just wondering what happens next. |
| 15:34:58 | lclc_bnc: | lclc_bnc is now known as lclc |
| 17:08:44 | NewLiberty: | NewLiberty is now known as NewLiberty-afk |
| 17:30:55 | NewLiberty-afk: | NewLiberty-afk is now known as NewLiberty |
| 17:42:19 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 18:18:04 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 19:43:08 | roasbeef_: | re btcd: davec's formal response: https://blog.conformal.com/the-bitcoin-consensus-red-herring/ |
| 20:03:01 | gmaxwell: | roasbeef_: too bad it repeats the misinformation "if there is any doubt about this, see the March 2013 fork that already happened" example. :( |
| 20:08:00 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:46:35 | tacotime: | well, the march 2013 was a legitimate hard fork. it was just caused by software used by but not written by bitcoin core. |
| 20:47:47 | pigeons: | i think he means but it wasnt caused by a new version of bitcoin core |
| 20:49:10 | tacotime: | wasn't it 0.7.x and 0.8.0 that swapped from berkeley to leveldb? and that was what the fork was between? |
| 20:49:28 | roasbeef_: | hmm yeah it was a series of events that caused an old version to be inconsistent with itself |
| 20:49:29 | gmaxwell: | No. |
| 20:49:29 | pigeons: | i think the distinction is it was caused by mining pool changing max block size |
| 20:49:39 | gmaxwell: | tacotime: 0.7 forked with _itself_. |
| 20:50:23 | gwillen: | gmaxwell: to be fair I don't think anybody realized that at the time, did they? |
| 20:50:39 | gwillen: | I feel like the potential for 0.7 to fork against itself was realized after the fact |
| 20:50:40 | gwillen: | and it's harder to trigger than 0.7 versus 0.8 |
| 20:50:41 | gmaxwell: | (and also with 0.8, ... we'd initially thought it was pre-0.8 vs 0.8; but that wasn't so, it was some fraction of 0.7 nodes vs everything else, including other copies of the same version) |
| 20:50:58 | gwillen: | * gwillen nods |
| 20:51:01 | gmaxwell: | gwillen: no not harder to trigger it's exactly what was being triggered. |
| 20:51:24 | tacotime: | gmaxwell: ah. in that case, the running of multiple daemons would have been beneficial to any service provider then, though i guess you would have trouble figuring out what fork to continue on. i guess in the case of versioning forks you should just immediately drop all services. |
| 20:51:25 | gwillen: | the author of that article probably heard the same stuff I did, then, which was initial reports that it was about 0.8 |
| 20:51:28 | gwillen: | and then not any followups |
| 20:51:33 | gmaxwell: | Pre-0.8 would reject some valid blocks, non-determinstically based on their locally specific history. |
| 20:52:12 | gmaxwell: | gwillen: yea, I just said it was too bad, and that it was just a repeat of misinformation. |
| 20:52:17 | gwillen: | * gwillen nods |
| 20:53:24 | gmaxwell: | tacotime: as far as running multiple copies. Not a single miner does this now, at least not that I have any evidence of. Eligius used to, but I believe it doesn't anymore. It's incredibly costly and promotes centeralization of mining to the extent that it is done. It's a tool in the belt, sure, but not at all a good one. |
| 20:54:07 | tacotime: | i guess we were lucky that 0.8.0 w/ leveldb had the correct behaviour and that this never happened in the past. |
| 20:54:11 | tacotime: | why is it so costly? |
| 20:54:18 | gmaxwell: | (and it isn't just an N fold increase in cost, it's worse... e.g. right now to run all the full nodes that I'm aware of which have a chance of keeping up with the network you need on the order of a half a terrabyte of storage; as not all are equally efficient) |
| 20:55:19 | gmaxwell: | tacotime: we're already precipitiously losing full nodes; and it's very hard to get miners to run things like p2pool in part because of the cost of running a full node. And then you suggest they ought to run N of them, some of which requiring hundreds of gigs of space? |
| 20:55:33 | roasbeef_: | half a TB? guessing you're factoring in toshi with its 300GB? |
| 20:55:59 | gmaxwell: | tacotime: it never happened in the past because the event was triggered by manual reconfiguration. (Mike Hearn extolling slush change their config to up the maximum blocksize they create) |
| 20:56:10 | tacotime: | well; maybe just the last two or three versions. and the older versions i don't think need outgoing traffic even, just to verify that everyone is stuck on the same HEAD |
| 20:56:12 | gmaxwell: | roasbeef_: yup. |
| 20:56:40 | tacotime: | that's like maybe a grand worth of SSDs |
| 20:56:46 | gmaxwell: | roasbeef_: but you can get numbers just by saying e.g. all the commonly deployed bitcoin core versions. |
| 20:57:16 | tacotime: | (I'm talking about bitcoin core, not alt impl. afaik btcd isn't used anywhere for mining, at least not yer) |
| 20:57:26 | gmaxwell: | tacotime: yea, so now your extra cost to mine is an extra $1000? Who's going to do that? Already getting people to run one node has shown itself to be hard. |
| 20:57:46 | tacotime: | I mean, for the massive centralized pools. |
| 20:57:58 | lechuga_: | running multiple nodes and verifying solutions with each of them doesnt seem scalable |
| 20:58:03 | gmaxwell: | They still won't. It's $1000 they don't have to spend. |
| 20:58:05 | tacotime: | It makes no sense for them not to do that, because their loss of money if they mine wastefully on a fork may be much higher. |
| 20:58:23 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:58:27 | gmaxwell: | tacotime: except they already can, and can for years, and the only one I'm aware of who ever has is Luke. |
| 20:59:26 | tacotime: | Well... Maybe it's optimism. You'd expect security to be breathtaking at exchanges now too after mtgox. |
| 20:59:31 | gmaxwell: | You also get fun like being exposed to security vulnerabilties in old software, unless you isolate them from the network behind a new version, and if you do that, you may not see the consensus difference. :( |
| 21:00:29 | gmaxwell: | tacotime: And okay, lets assume somehow large pools are convinced that it's worth their cost to run those extra nodes; all that does is convince everyone else that they have to use these big pools. :( |
| 21:01:34 | tacotime: | No argument there, but it's always been the case that there are a few huge centralizing pools. |
| 21:02:17 | lechuga_: | what if consenesus isn't reached w/the tested set |
| 21:02:22 | lechuga_: | consensus* |
| 21:02:38 | tacotime: | lechuga_: kill the mining daemon and wait. |
| 21:02:45 | smooth: | this seems problematic if different pools use different sets |
| 21:02:50 | lechuga_: | what if people use different sets |
| 21:02:58 | lechuga_: | rigt |
| 21:03:31 | tacotime: | at that point the major players in the network need to pick the fork. |
| 21:04:24 | tacotime: | with monero we just picked the longest chain... but i guess it depends what the issue was. |
| 21:06:56 | tacotime: | is this a 'vulnerability' in nonoutsourceable work schemes? difficulty keeping network consensus between versions/binaries? |
| 21:07:04 | lechuga_: | we see you love consensus protocols so we put a consensus protocol in your consensus protocol |
| 21:07:12 | tacotime: | mm, maybe more like a small downside |
| 21:07:20 | tacotime: | hah |
| 21:07:25 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 21:09:39 | gmaxwell: | tacotime: it hasn't always been the case that; and there isn't a fundimental reason for it-- esp since we now know how to seperate pooling income and pooling the vote, which we didn't know in 2011. But saying you must run many daemons would make a stronger case for it. |
| 21:10:05 | gmaxwell: | in any case, no biggie but this is why I don't consider that approach a solution. |
| 21:11:49 | gmaxwell: | well part of it, the rest is-- what about everyone else. Say miners are running multiple versions and thus rejecting a chain that version X would reject. okay. Fine. But you're running something other than version X, and so now you're exposed to accepting a chain that many miners are going to reject, perhaps a perfectly valid one.. just because one weird old version you've never heard of has an i |
| 21:11:55 | gmaxwell: | ssue. |
| 21:15:56 | lechuga_: | may be stupid but i wonder if probabilistically relaying bad blocks could help. |
| 21:16:14 | lechuga_: | bad/rejected |
| 21:16:25 | gmaxwell: | lechuga_: it's against your own self interest though; since you're helping the network do something you reject. |
| 21:17:51 | lechuga_: | if you noticed a bad chain w/nearly the same cumm. work as the chain you accept maybe u decide to halt operations |
| 21:19:08 | lechuga_: | im sure lots of DoS cases i havent considered |
| 21:26:38 | hearn: | gmaxwell: er, was that an attempt to blame me for the fork? |
| 21:28:40 | Eliel: | gmaxwell: I don't think miners are the ones for whom this suggestion is really the most beneficial. It's big businesses that use bitcoin. It'll help them automatically detect the situations when it could be risky to accept bitcoin transactions. |
| 21:29:04 | Eliel: | and the businesses with most to lose are the ones that best can do this |
| 21:30:22 | gmaxwell: | hearn: Hm? no. It was just what tiggered the split to happen when it did and not at some other time. |
| 21:30:51 | hearn: | ok, sorry for being prickly then :) |
| 21:31:27 | Eliel: | of course, if the consensus engine was modular enough to support different consensus modules all verifying the same database, it'd reduce the resources required. |
| 21:32:14 | gmaxwell: | Eliel: as the pre-0.8 self-inconsistency showed, in current designs the database is part of the consensus. |
| 21:32:57 | Eliel: | yep, modular design would also allow for variability in databases which would give you more data. |
| 21:34:50 | Eliel: | also, it'd open up the possibility of running the consensus engines yourself but outsourcing the database. |
| 21:35:34 | wumpus: | as in, a deterministic bug in the database may become part of the consensus |
| 21:36:18 | Eliel: | that's a very good argument for having different databases used and modular consensus engine implementations. |
| 21:36:54 | Eliel: | because that means it'll be detectable |
| 21:37:16 | wumpus: | possibly, although that brings back the problem of 'who is right?' |
| 21:38:04 | Eliel: | I think the sensible choice to begin with is to run the other implementations purely for early warning purpose. |
| 21:38:21 | wumpus: | but sure, it would be interesting to run bitcoind with another database backend and periodically compare the utxo set hashes |
| 21:39:05 | Eliel: | I think the most interesting modularization would be to have them be completely separate processes and communicate with RPC calls. |
| 21:39:12 | gmaxwell: | Eliel: of course it's detectable, when the consensus is split, which is too late. :) |
| 21:39:14 | wumpus: | then again, the winner would be the behavior of the deployed database |
| 21:40:10 | wumpus: | Eliel: or a library, in our case |
| 21:41:26 | Eliel: | gmaxwell: only if significant numbers of people are actually relying on different implementations primarily. |
| 21:41:30 | wumpus: | and sure, you can always wrap a library in a RPC shim, if you want to execute the consensus code e.g. in a sandbox |
| 21:45:39 | Eliel: | For the moment, I see most use for running several different versions and comparing their results being used for automatic failsafe systems. |
| 22:09:58 | kanzure: | "With an approach such as this, a miner could detect that, say Bitcoin Core 0.9.5 and btcd 0.9.0 consider the block valid, but Bitcoin Core 0.10.0 does not, or Bitcoin Core 0.9.5 and Bitcoin Core 0.10.0 consider the block valid, but btcd 0.9.0 does not. In any case, there is an extremely high probability that the 2 of the 3 which agree are right while the other one has a bug. As the number of community-blessed implementations you check ... |
| 22:10:04 | kanzure: | ... against increases, the probability that a debilitating chain fork can occur decreases." |
| 22:10:07 | kanzure: | wow this is a very very bad idea |
| 22:10:13 | kanzure: | this is not a good way to decide which rules you would rather follow |
| 22:11:58 | kanzure: | "if most implementations get the rules wrong, then choose the fork that gets the most wrong" |
| 22:12:29 | phantomcircuit: | who... |
| 22:12:32 | phantomcircuit: | who wrote that |
| 22:12:38 | kanzure: | conformal |
| 22:12:43 | kanzure: | https://blog.conformal.com/the-bitcoin-consensus-red-herring/ |
| 22:13:33 | artifexd_: | artifexd_ is now known as artifexd |
| 22:14:58 | Pan0ram1x: | Pan0ram1x is now known as Guest51744 |
| 22:15:00 | phantomcircuit: | "Every fully-validating node on the network must follow the exact same consensus rules or a fork will occur" -- only true for the wide definition of a fork |
| 22:15:14 | phantomcircuit: | if the issue is non deterministic as the bdb fork was then it's actually not such an issue |
| 22:15:55 | phantomcircuit: | the serious risk is from forks which can be intentionally triggered by a malicious miner |
| 22:16:45 | kanzure: | you cannot make statements like "[out of your random choices of which clients to be running] there is an extremely high probability that the 2 of the 3 which agree are right while the other one has a bug" |
| 22:17:31 | kanzure: | i'm having trouble picking the best reason why, because the list is so long |
| 22:18:24 | gmaxwell: | phantomcircuit: even if something happens randomly, you can still exploit it. |
| 22:18:42 | gmaxwell: | "Oh look, foo is rejecting the chain, lets mine a couple blocks for it to rob it blind." |
| 22:18:43 | phantomcircuit: | gmaxwell, sure, but for the common case it's significantly harder |
| 22:18:52 | phantomcircuit: | for coinbase and stuff not so much |
| 22:20:46 | kanzure: | "What should be clear is that if you gracefully handle Bitcoin Core forking against itself, you also gracefully handle forking of alternative implementations" forking is absolutely necessary how does this person not swallow his own tongue? |
| 22:21:57 | kanzure: | wait, is it commonly accepted that not having the highest chain is considered a fork |
| 22:24:16 | sipa: | in march 2013 the fork was easy to resolve because reverting to an old version constituted a softfork, so could be done with just miner agreement |
| 22:24:51 | sipa: | in case of a true incompatibility between two versions, you need to ask the whole split community to agree on which version to switch to |
| 22:25:14 | phantomcircuit: | kanzure, at a very high level he's right, but in practice he's wrong |
| 22:25:21 | phantomcircuit: | which i kind of difficult to argue for |
| 23:05:52 | midnightmagic: | conformal is misrepresenting their work |
| 23:06:47 | justanot1eruser: | midnightmagic: how can you misrepresent a consensus reimplementation? |
| 23:11:24 | midnightmagic: | no, their work. btcd. for example, they shuffled a critical bus error bug under the rug, failed to report it to anybody, failed to report it correctly when called on it in public, and then davec himself demonstrated he didn't actually know what was going on that caused the critical bus error to begin with. |
| 23:12:23 | midnightmagic: | so either their own consensus-breaking bugs are tracked internally and nobody is allowed to see them, or they aren't tracked at all. either way.. same effect to the outsiders. |
| 23:12:54 | go1111111: | have any wizards evaluated the 'stablecoins' proposal by Robert Sams? the TL;DR is that a cryptocurrency system has two internal currency units, and it attempts to keep one of them stable by automatically auctioning off one for the other as necessary |
| 23:13:51 | lclc: | lclc is now known as lclc_bnc |
| 23:14:59 | tacotime: | go1111111: that's the premise of cunicula's two year old "Hop" project |
| 23:15:43 | tacotime: | and probably cunicula got it closer to correct if i had to guess, seeing as he's a professional economist |
| 23:16:38 | go1111111: | thanks, i'll check that out. |
| 23:17:28 | tacotime: | go1111111: http://www.scribd.com/doc/186071279/Hop-System-for-Store-of-USD-Value |
| 23:17:46 | tacotime: | the weird thing was |
| 23:17:52 | tacotime: | he disappeared soon after publishing this |
| 23:24:09 | gmaxwell: | tacotime: thats probably one of the more content free docs I've seen in a while. (I'd not seen that one before, I'd seen cunicula's posts on it before though. I wasn't aware that he was an economist. I suppose it reflects my low opinion of most economists in that I'm not surprised. (A lot of his posts were borderline technobabble as far as I could tell.) |
| 23:26:12 | Eliel: | tacotime: let's hope someone grabbed him and is having him develop this system. It sounds interesting :) |
| 23:26:27 | tacotime: | gmaxwell: There was a whitepaper too, but it's disappeared from the internet |
| 23:26:48 | Eliel: | although, it sounds like someone silenced him. |
| 23:28:05 | sipa: | ... |
| 23:28:17 | gmaxwell: | lol |
| 23:28:34 | tacotime: | wasn't there some guy called satoshi around once too? |
| 23:28:44 | tacotime: | :P |
| 23:28:47 | gmaxwell: | he was silenced! |
| 23:29:28 | Eliel: | does anyone know cunicula's real identity? |
| 23:29:39 | kanzure: | "real identity" is a misnomer |
| 23:29:50 | Eliel: | kanzure: I'm not intersted in debating that. |
| 23:29:59 | Eliel: | you know what I mean |
| 23:31:44 | Eliel: | ok, let me rephrase. Did cunicula take as good care of keeping who he is secret as satoshi did? |
| 23:32:00 | tacotime: | as far as i can tell |
| 23:32:16 | tacotime: | i think the nxt people are after him for the whitepaper he was supposed to write for them and never did |
| 23:33:21 | tacotime: | or perhaps he decided that cryptocurrencies were all silly, sold his coins, and wandered off :P |
| 23:43:38 | Eliel: | ok, then silencing sounds unlikely :) |
| 23:48:02 | rusty: | rusty has left #bitcoin-wizards |