Hello Adam First of all, thank you for inventing hashcash, which is basically what bitcoin is!
Some people have said that my proposal, subject line "Scaling Bitcoin with Subchains" is essentially the idea of blockchain extensions. Though, I think there is quite a difference between what I propose and what you propose. You want to add one optional 10 MB blockchain that synchronizes with the 1 MB blockchain, while I want to add ten 1 MB blockchains that each synchronize with the 1 MB chain (and you can continue like that). I think, as long as we want to keep using blockchains for our cryptocurrency, we will need a tree structure of blockchains in order to scale for an arbitrary number of transactions. With just one 10 MB blockchain, someone who wants to do the lower valued transactions will need to validate all 10 MB, while with ten 1 MB chains, they can choose just the chain or chains that are of interest to them. With a tree structure you get O(a^(n-1)) MB of transactions in the network while each participant only has to validate O(n) MB of transactions (a is just the number of children chains per parent divided by 2, so 5 in the case of 10 children as I described). With just one child chain, you don't get this scaling, and it is pretty much equivalent to increasing the blocksize, though with a soft-fork instead of a hard-fork. I think the actual way that the blockchains interact can be still worked out (Recently I was thinking of maybe creating a contract system or even a decentralized market between chains). But still, everyone should agree that you need this kind of tree structure. Even if you want to only run a pruned node, the CPU usage and memory scales just as bad. The tree structure also has good privacy and miner decentralization properties, as I can write about later. But another thing that I recommend is an "exit plan". What if we go with some kind of soft fork and then in the future some better idea comes along? Then we should have a way to reverse the soft fork. If people already have coins tied up in sidechains, it can be problematic. So perhaps, in case people want to later ditch the soft fork, nodes in the parent chain can allow only old transactions inside the child chains to be accepted back up, while new transactions are not recognized anymore. That way you can limit the amount of useless transaction traffic that results in case we want something else. On Sat, May 30, 2015 at 1:36 AM, Raystonn <rayst...@hotmail.com> wrote: > My fear now is too much unnecessary complexity. More complex means > brittle code, but also fewer programmers working on this, which is a risk. > > We shouldn't delay forever until every potential solution has been > explored. There's always going to be one more thing to explore. > On 29 May 2015 5:16 pm, Gavin Andresen <gavinandre...@gmail.com> wrote: > > RE: soft-forking an "extension block": > > So... go for it, code it up. Implement it in the Bitcoin Core wallet. > > Then ask the various wallet developer how long it would take them to > update their software to support something like this, and do some UI > mockups of what the experience would look like for users. > > If there are two engineering solutions to a problem, one really simple, > and one complex, why would you pick the complex one? > > Especially if the complex solution has all of the problems of the simple > one (20MB extension blocks are just as "dangerous" as 20MB main blocks, > yes? If not, why not?) > > > -- > -- > Gavin Andresen > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
