Hello,
On 7/13/2017 9:17 AM, Hampus Sjöberg wrote: > In softforks, I would argue that 100% of all nodes and miners need to > upgrade to the new rules. > This makes sure that trying to incorrectly spend an "AnyOneCanSpend" > will result in a hardfork, instead of a temporary (or permanent) > chainsplit. > > With drivechains, it seems like the current plan is to only let the > nodes that are interested in the drivechain validate the other chain, > and not necessarily 100% of the network. Correct. > I guess this could be any percentage of the network, which could lead > to a temporary/permanent chainsplit depending on how many percentage > of the miners are also validating the other chain (am I missing > something here?). > I have no way to evaluate if this is an okay trade-off. > It seems like major disruption could very likely happen if say only 5% > of all fullnodes validate the drivechain. You are correct that some % of the network would be validating both chains. However, if miners improperly withdraw from a sidechain, it --by design-- does not lead to any chainsplit of any kind. Instead, the sidechain in question just dies a painful death (notice that, if any withdrawals are improper, it is quite as bad as if all of the sidechain funds were withdrawn improperly -- this is because the sidechain would instantly have a bunch of problems, including that it would be something-like 'fractional reserve' which would lead to an immediate bank run of withdrawals [none of which could have any real expectation of success, in my view]). In practice, a concern of mine is that people *would* try to turn a sidechain-theft even into some kind of grand UASF-style campaign. I would prefer for people not to do this. Then again, I do not hold this preference unconditionally -- I see it as comparable to Bitcoin's commitment to "the code is the spec". Which is to say that this commitment is overwhelmingly held, but not dogmatically as in exceptional cases such as theValue overflow incident [1]. I think that in such ambiguous cases, we must rely on [a] the miner's desire to maximize the purchasing power of each Bitcoin, and [b] the technical wisdom of Bitcoin's future leaders in helping miners to achieve this goal. [1] https://en.bitcoin.it/wiki/Value_overflow_incident > To be fully secure, it seems like 100% of all nodes should also have a > fullnode for the drivechain as well... Perhaps, but this is exactly what I am trying to avoid. The design goal, in some sense, is to have "half security", ie <100%. This is because the only way to achieve "full" 100% security is with full enforcement of all rules. Full enforcement of the rules, in turn, means either that we are exactly where we are right now (where we only add compatible rules, aka the traditional "soft fork") or we are [also] exactly where we are right now (in that if we add an incompatible rule, it results in a "hard fork"). I would like to build something new, which trades off on the qualities of each, and therefore lies (intentionally) somewhere in between. > This is one of the reasons I don't advocate sidechains/drivechains as > a scaling solution, it looks like it would have to the same outcome as > a blocksize increase on the mainchain, but with more complexity. Keep in mind that, if some people leave the small chain (what you might call the "Core" chain, although some disagree with summarizing it this way) for some other chain, it does free up more space on this chain. I'm not really sure the extent to which that "counts" as increasing capacity. Also, I agree that sc/dc do not help with "scalability", if that problem is defined as "better technology" or as "how to do more with less". Actually my full view is a little nuanced and it is here: http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with-scaling > Thanks for all your work so far Paul. You're welcome! Paul _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev