01:09:08CodeShark:How do we design a decentralized consensus protocol that is generally extensible while minimizing the need for hardforks?
01:10:22CodeShark:i.e. extensible headers and abstract data types seem like a good start
01:29:27justanotheruser: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:32justanotheruser:I think thats actually being implemented
01:30:48justanotheruser: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:56CodeShark: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:33CodeShark: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:28kanzure:you mean each user/operator flips the switch, or who flips?
01:41:47CodeShark:that's still an open issue - assuming we had a solution to this issue
01:41:59justanotheruser:CodeShark: who decides what new consensus rules are valid?
01:42:18justanotheruser:the miners? the stake holders? A not-sybil-resistant majority of nodes? A central authority?
01:42:42CodeShark:well, right now it's the core developers, I suppose
01:42:49CodeShark:but setting that issue aside
01:42:58justanotheruser:no, the miners decide softforks
01:43:07justanotheruser:there have been no hardforks
01:43:32CodeShark:the miners decide on softforks that are proposed by the core developers
01:43:57justanotheruser:or they could decide on softforks proposed by a homeless guy
01:44:08rusty: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:11CodeShark:but for the sake of discussion, imagine we had a procedure in place for reaching consensus on new protocol rules
01:44:23CodeShark:my question is more about the mechanism for its deployment
01:44:27justanotheruser:rusty: what hardfork
01:44:50CodeShark:everyone agreed "yes, I love feature X - let's add it"
01:44:57rusty:justanotheruser: the large block hardfork. https://bitcoin.org/en/alert/2013-03-11-chain-fork
01:44:59CodeShark:we have an implementation for it and it's been tested
01:45:05CodeShark:now how do we deploy?
01:45:45justanotheruser:rusty: that wasn't a hardfork to my understanding
01:45:56CodeShark:actually, miners didn't resolve that one - and it was a hardfork due to a bug
01:46:06justanotheruser:CodeShark: see above
01:46:10rusty:justanotheruser: not a deliberate one, no... and CodeShark, they certainly did, by downgrading.
01:46:24CodeShark:miners did so by STRONG encouragement from the core devs
01:46:35justanotheruser:afaik, that was more of a softfork if you can call it that
01:46:47CodeShark:many miners would have liked to just stay on the nonbuggy chain
01:47:15CodeShark:the majority of hashing power was on the nonbuggy chain
01:47:44rusty: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:24justanotheruser: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:44justanotheruser:0.3 still can still achieve consensus with 0.9.3
01:49:05rusty:justanotheruser: new clients accept and old clients don't == hardfork. I don't know what else to call it.
01:49:07CodeShark:or at least the rules were not really known, even if deterministic
01:49:51CodeShark:if everyone implements the same bug which changes consensus rules, the implemented rules become the *real* rules
01:49:55justanotheruser:rusty: some 0.7 clients still worked
01:50:06justanotheruser:rusty: 0.7 broke consensus with itself.
01:51:00CodeShark:anyhow, there hasn't really been a deliberate hardfork, has there?
01:52:33rusty: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:11justanotheruser:here is discussion on what 0.7-0.8 was (it's pretty short) http://hastebin.com/ofuqizomuw.xml
01:54:19e1782d11df4c9914:that langsec video was very enlightening, to whomever had posted it up above
01:54:53justanotheruser:0.8 was a non-deterministic-hardfork-softfork-non-deterministic-hardfork-deterministic-softfork-fork
01:55:55rusty:CodeShark: See the P2SH deployment BIP (16). That method is probably the one which would be used in future, given it worked.
01:56:18justanotheruser:p2sh deployment was a softfork and no one broke consensus...
01:56:43justanotheruser: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:24justanotheruser: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:32justanotheruser:really, what do you need a hardfork for though?
01:59:03rusty:justanotheruser: >1MB blocks will be a hardfork, AFAICT.
01:59:21rusty:justanotheruser: weakening SHA256 would be another, but that's more speculative.
01:59:45justanotheruser:rusty: I don't think a blocksize increase will happen, but I could be wrong
02:00:17justanotheruser:Increasing the blocksize only solves the problem until the transaction volume matches up with the blocksize once again
02:01:00justanotheruser:and its a controversial hardfork.
02:02:29rusty: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:31gmaxwell: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:39CodeShark: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:53CodeShark:not saying such an approach is still doable, let alone desirable
02:04:53gmaxwell: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:07moa:if transactions rates die the ceiling will not need to be lifted arbitrarily
02:05:40CodeShark: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:53gmaxwell: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:07CodeShark:luke is more of a core dev than a large mining pool :P
02:06:09gmaxwell:At the time we didn't know the split was non-determinstic and mistook it for a plain hardfork.
02:08:24gmaxwell: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:09CodeShark:gmaxwell: details aside, I think it's a scenario that most of us would like to generally avoid
02:09:26gmaxwell:justanotheruser: BIP16's deployment was minorly consensus breaking. A better example would be BIP34.
02:09:57rusty: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:21gmaxwell:justanotheruser: there were some number of orphan blocks because the transactions BIP16 made invalid were IsStandard.
02:10:29moa:it was actually a good example of how the miners will not hardfork onto a minority branch
02:11:00gmaxwell: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:06gmaxwell:moa: I agree.
02:11:32moa:at least the ones that were awake
02:11:35rusty:gmaxwell, moa: yeah, if bitcoin fails we don't need to worry about hardforks? :)
02:12:05rusty:(Oh, I was responding to moa's previous comment re: tx rates dying)
02:12:05gmaxwell: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:25gmaxwell: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:23gmaxwell:( https://bitcointalk.org/index.php?topic=149668.0 )
02:17:48gmaxwell: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:41CodeShark:gmaxwell: what about the security model?
02:31:21CodeShark:gmaxwell: I suppose you'd also need to get miners to switch over to the new chain
02:33:53BlueMatt:;;later tell adam3us yes, the pebble guy and I had a marginally useful discussion afterwards
02:34:04BlueMatt:nanotube: wtf, where's gribble?
02:34:09BlueMatt:didnt it used to be here
02:35:52CodeShark:gmaxwell: how's OP_SIDECHAINPROOFVERIFY coming along?
03:17:37CodeShark: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:26CodeShark:(assuming the consensus model is essentially unchanged)
03:33:51phantomcircuit: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:58phantomcircuit:hmm yeah that would be entirely trivial
03:58:10tromp:phantomcircuit: the original Momentum proposal (find a hash collision between any two nonces) is progress-full
03:59:23tromp:(the hash output was limited to 50 bits)
03:59:38phantomcircuit:for anybody wondering this is not really for a pow
05:43:25rusty:Is there a variant of atomic swaps which can tolerate tx malleability?
05:44:34rusty:(Or am I misunderstanding the proposal in Appendix C of the sidechains paper, which seems subject to refund breakage via txmal).
05:47:59gmaxwell:rusty: malleability will be at the senders option in bitcoin in a couple months-ish.
05:49:19gmaxwell:There are two things ongoing which both seperately address this (BIP62 and BIP65).
05:50:09rusty: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:24gmaxwell:rusty: pretty sure we actually mention it in there at some point and cite bip62.
05:52:55rusty:gmaxwell: hmm... CHECKLOCKTIMEVERIFY does avoid the refund TX nicely and simplifies the protocol.
05:55:31gmaxwell: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:39rusty: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:10gmaxwell: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:39gmaxwell:I think also at the time that text was written we expected the paper to be published later relative to BIP62.
05:58:06rusty:gmaxwell: thanks for the confirmation, at least I'll mention in my 1-page description of atomic swaps.
08:08:29lclc_bnc:lclc_bnc is now known as lclc
08:55:22NewLiberty_:NewLiberty_ is now known as NewLiberty
09:05:15kornbluth.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:15kornbluth.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:15kornbluth.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:15kornbluth.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:15kornbluth.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:06Muis_:Muis_ is now known as Muis
11:15:38lclc:lclc is now known as lclc_bnc
11:22:09lclc_bnc:lclc_bnc is now known as lclc
12:47:38lclc:lclc is now known as lclc_bnc
14:28:12wallet421:wallet421 is now known as wallet42
14:46:19dgenr8:[01/04 18:17:50] "You make your changes to a sidechain and then move things onto it"
14:46:49dgenr8:Things? Are you envisioning large chunks of BTC value permanently moving to a sidechain (and then another...)?
14:47:15wumpus:doesn't have to be permanently, you, or someone else can move them back
14:49:19heath:hi yrashk
14:50:05yrashk:hi heath
14:50:54dgenr8: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:16wumpus: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:29dgenr8:the context here is "sidechains as smooth upgrade mechanism". I'm just wondering what happens next.
15:34:58lclc_bnc:lclc_bnc is now known as lclc
17:08:44NewLiberty:NewLiberty is now known as NewLiberty-afk
17:30:55NewLiberty-afk:NewLiberty-afk is now known as NewLiberty
17:42:19Dizzle__:Dizzle__ is now known as Dizzle
18:18:04zz_lnovy:zz_lnovy is now known as lnovy
19:43:08roasbeef_:re btcd: davec's formal response: https://blog.conformal.com/the-bitcoin-consensus-red-herring/
20:03:01gmaxwell: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:00Dizzle__:Dizzle__ is now known as Dizzle
20:46:35tacotime: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:47pigeons:i think he means but it wasnt caused by a new version of bitcoin core
20:49:10tacotime: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:28roasbeef_:hmm yeah it was a series of events that caused an old version to be inconsistent with itself
20:49:29pigeons:i think the distinction is it was caused by mining pool changing max block size
20:49:39gmaxwell:tacotime: 0.7 forked with _itself_.
20:50:23gwillen:gmaxwell: to be fair I don't think anybody realized that at the time, did they?
20:50:39gwillen:I feel like the potential for 0.7 to fork against itself was realized after the fact
20:50:40gwillen:and it's harder to trigger than 0.7 versus 0.8
20:50:41gmaxwell:(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:58gwillen:* gwillen nods
20:51:01gmaxwell:gwillen: no not harder to trigger it's exactly what was being triggered.
20:51:24tacotime: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:25gwillen: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:28gwillen:and then not any followups
20:51:33gmaxwell:Pre-0.8 would reject some valid blocks, non-determinstically based on their locally specific history.
20:52:12gmaxwell:gwillen: yea, I just said it was too bad, and that it was just a repeat of misinformation.
20:52:17gwillen:* gwillen nods
20:53:24gmaxwell: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:07tacotime: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:11tacotime:why is it so costly?
20:54:18gmaxwell:(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:19gmaxwell: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:33roasbeef_:half a TB? guessing you're factoring in toshi with its 300GB?
20:55:59gmaxwell: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:10tacotime: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:12gmaxwell:roasbeef_: yup.
20:56:40tacotime:that's like maybe a grand worth of SSDs
20:56:46gmaxwell:roasbeef_: but you can get numbers just by saying e.g. all the commonly deployed bitcoin core versions.
20:57:16tacotime:(I'm talking about bitcoin core, not alt impl. afaik btcd isn't used anywhere for mining, at least not yer)
20:57:26gmaxwell: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:46tacotime:I mean, for the massive centralized pools.
20:57:58lechuga_:running multiple nodes and verifying solutions with each of them doesnt seem scalable
20:58:03gmaxwell:They still won't. It's $1000 they don't have to spend.
20:58:05tacotime: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:23Dizzle__:Dizzle__ is now known as Dizzle
20:58:27gmaxwell:tacotime: except they already can, and can for years, and the only one I'm aware of who ever has is Luke.
20:59:26tacotime:Well... Maybe it's optimism. You'd expect security to be breathtaking at exchanges now too after mtgox.
20:59:31gmaxwell: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:29gmaxwell: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:34tacotime:No argument there, but it's always been the case that there are a few huge centralizing pools.
21:02:17lechuga_:what if consenesus isn't reached w/the tested set
21:02:38tacotime:lechuga_: kill the mining daemon and wait.
21:02:45smooth:this seems problematic if different pools use different sets
21:02:50lechuga_:what if people use different sets
21:03:31tacotime:at that point the major players in the network need to pick the fork.
21:04:24tacotime:with monero we just picked the longest chain... but i guess it depends what the issue was.
21:06:56tacotime:is this a 'vulnerability' in nonoutsourceable work schemes? difficulty keeping network consensus between versions/binaries?
21:07:04lechuga_:we see you love consensus protocols so we put a consensus protocol in your consensus protocol
21:07:12tacotime:mm, maybe more like a small downside
21:07:25Quanttek_:Quanttek_ is now known as Quanttek
21:09:39gmaxwell: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:05gmaxwell:in any case, no biggie but this is why I don't consider that approach a solution.
21:11:49gmaxwell: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:15:56lechuga_:may be stupid but i wonder if probabilistically relaying bad blocks could help.
21:16:25gmaxwell:lechuga_: it's against your own self interest though; since you're helping the network do something you reject.
21:17:51lechuga_: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:08lechuga_:im sure lots of DoS cases i havent considered
21:26:38hearn:gmaxwell: er, was that an attempt to blame me for the fork?
21:28:40Eliel: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:04Eliel:and the businesses with most to lose are the ones that best can do this
21:30:22gmaxwell:hearn: Hm? no. It was just what tiggered the split to happen when it did and not at some other time.
21:30:51hearn:ok, sorry for being prickly then :)
21:31:27Eliel: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:14gmaxwell:Eliel: as the pre-0.8 self-inconsistency showed, in current designs the database is part of the consensus.
21:32:57Eliel:yep, modular design would also allow for variability in databases which would give you more data.
21:34:50Eliel:also, it'd open up the possibility of running the consensus engines yourself but outsourcing the database.
21:35:34wumpus:as in, a deterministic bug in the database may become part of the consensus
21:36:18Eliel:that's a very good argument for having different databases used and modular consensus engine implementations.
21:36:54Eliel:because that means it'll be detectable
21:37:16wumpus:possibly, although that brings back the problem of 'who is right?'
21:38:04Eliel:I think the sensible choice to begin with is to run the other implementations purely for early warning purpose.
21:38:21wumpus:but sure, it would be interesting to run bitcoind with another database backend and periodically compare the utxo set hashes
21:39:05Eliel:I think the most interesting modularization would be to have them be completely separate processes and communicate with RPC calls.
21:39:12gmaxwell:Eliel: of course it's detectable, when the consensus is split, which is too late. :)
21:39:14wumpus:then again, the winner would be the behavior of the deployed database
21:40:10wumpus:Eliel: or a library, in our case
21:41:26Eliel:gmaxwell: only if significant numbers of people are actually relying on different implementations primarily.
21:41:30wumpus: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:39Eliel:For the moment, I see most use for running several different versions and comparing their results being used for automatic failsafe systems.
22:09:58kanzure:"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:04kanzure:... against increases, the probability that a debilitating chain fork can occur decreases."
22:10:07kanzure:wow this is a very very bad idea
22:10:13kanzure:this is not a good way to decide which rules you would rather follow
22:11:58kanzure:"if most implementations get the rules wrong, then choose the fork that gets the most wrong"
22:12:32phantomcircuit:who wrote that
22:13:33artifexd_:artifexd_ is now known as artifexd
22:14:58Pan0ram1x:Pan0ram1x is now known as Guest51744
22:15:00phantomcircuit:"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:14phantomcircuit:if the issue is non deterministic as the bdb fork was then it's actually not such an issue
22:15:55phantomcircuit:the serious risk is from forks which can be intentionally triggered by a malicious miner
22:16:45kanzure: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:31kanzure:i'm having trouble picking the best reason why, because the list is so long
22:18:24gmaxwell:phantomcircuit: even if something happens randomly, you can still exploit it.
22:18:42gmaxwell:"Oh look, foo is rejecting the chain, lets mine a couple blocks for it to rob it blind."
22:18:43phantomcircuit:gmaxwell, sure, but for the common case it's significantly harder
22:18:52phantomcircuit:for coinbase and stuff not so much
22:20:46kanzure:"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:57kanzure:wait, is it commonly accepted that not having the highest chain is considered a fork
22:24:16sipa: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:51sipa: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:14phantomcircuit:kanzure, at a very high level he's right, but in practice he's wrong
22:25:21phantomcircuit:which i kind of difficult to argue for
23:05:52midnightmagic:conformal is misrepresenting their work
23:06:47justanot1eruser:midnightmagic: how can you misrepresent a consensus reimplementation?
23:11:24midnightmagic: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:23midnightmagic: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:54go1111111: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:51lclc:lclc is now known as lclc_bnc
23:14:59tacotime:go1111111: that's the premise of cunicula's two year old "Hop" project
23:15:43tacotime:and probably cunicula got it closer to correct if i had to guess, seeing as he's a professional economist
23:16:38go1111111:thanks, i'll check that out.
23:17:28tacotime:go1111111: http://www.scribd.com/doc/186071279/Hop-System-for-Store-of-USD-Value
23:17:46tacotime:the weird thing was
23:17:52tacotime:he disappeared soon after publishing this
23:24:09gmaxwell: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:12Eliel:tacotime: let's hope someone grabbed him and is having him develop this system. It sounds interesting :)
23:26:27tacotime:gmaxwell: There was a whitepaper too, but it's disappeared from the internet
23:26:48Eliel:although, it sounds like someone silenced him.
23:28:34tacotime:wasn't there some guy called satoshi around once too?
23:28:47gmaxwell:he was silenced!
23:29:28Eliel:does anyone know cunicula's real identity?
23:29:39kanzure:"real identity" is a misnomer
23:29:50Eliel:kanzure: I'm not intersted in debating that.
23:29:59Eliel:you know what I mean
23:31:44Eliel:ok, let me rephrase. Did cunicula take as good care of keeping who he is secret as satoshi did?
23:32:00tacotime:as far as i can tell
23:32:16tacotime:i think the nxt people are after him for the whitepaper he was supposed to write for them and never did
23:33:21tacotime:or perhaps he decided that cryptocurrencies were all silly, sold his coins, and wandered off :P
23:43:38Eliel:ok, then silencing sounds unlikely :)
23:48:02rusty:rusty has left #bitcoin-wizards