Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
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 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 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
Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
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 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
Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
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
[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an extension block (say 10MB) and the existing 1MB block. The extension block is committed to in the 1MB chain. Users can transfer bitcoin into the extension block, and they can transfer them out. The interesting thing is this makes block sizes changes opt-in and gives users choice. Choice is good. Bitcoin has a one-size-fits-all blocksize at present hence the block size debate. If a bigger block-size were an opt-in choice, and some people wanted 10MB or even 100MB blocks for low value transactions I expect it would be far easier a discussion - people who think 100MB blocks are dangerously centralising, would not opt to use them (or would put only small values they can afford to lose in them). There are some security implications though, so this also is nuanced, and more on that in a bit. Fee pressure still exists for blocks of difference size as the security assurances are not the same. It is plausible that some people would pay more for transactions in the 1MB block. Now there are three choices of validation level, rather than the normal 2-levels of SPV or full-node, with extension blocks we get a choice: A) a user could run a full node for both 1MB and 10MB blocks, and get full security for both 1MB and 10MB block transactions (but at higher bandwidth cost), or B) a user could run a full node on the 1MB block, but operate as an SPV node for the 10MB block, or C) run in SPV mode for both 1MB and 10MB blocks. Similarly for mining - miners could validate 1MB and 10MB transactions (solo mine or GBT-style), or they could self-validate 1MB transactions and pool mine 10MB transactions (have a pool validate those). 1MB full node users who do not upgrade to software that understands extension blocks, could run in SPV mode with respect to 10MB blocks. Here lies the risk - this imposes a security downgrade on the 1MB non-upgraded users, and also on users who upgrade but dont have the bandwidth to validate 10MB blocks. We could defend non-upgrade users by making receiving funds that came via the extension block opt-in also, eg an optional to use new address version and construct the extension block so that payments out of it can only go to new version addresses. We could harden 1MB block SPV security (when receiving weaker extension block transactions) in a number of ways: UTXO commitments, fraud proofs (and fraud bounties) for moving from the extension block to the 1MB block. We could optionally require coins moving via the extension block to the 1MB block to be matured (eg 100 blocks delay) Anyway something else to evaluate. Not as simple to code as a hard-fork, but way safer transition than a hard-fork, and opt-in - if you prefer the higher decentralisation of 1MB blocks, keep using them; if you prefer 10MB blocks you can opt-in to them. Adam On 29 May 2015 at 17:39, Raystonn . wrote: > Regarding Tier’s proposal: The lower security you mention for extended > blocks would delay, possibly forever, the larger blocks maximum block size > that we want for the entire network. That doesn’t sound like an optimal > solution. > > Regarding consensus for larger maximum block size, what we are seeing on > this list is typical of what we see in the U.S. Congress. Support for > changes by the stakeholders (support for bills by the citizens as a whole) > has become irrelevant to the probability of these changes being adopted. > Lobbyists have all the sway in getting their policies enacted. In our case, > I would bet on some lobbying of core developers by wealthy miners. > > Someone recently proposed that secret ballots could help eliminate the power > of lobbyists in Congress. Nobody invests in that which cannot be confirmed. > Secret ballots mean the vote you are buying cannot be confirmed. Perhaps > this will work for Bitcoin Core as well. > > > From: Tier Nolan > Sent: Friday, May 29, 2015 7:22 AM > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB > stepfunction > > On Fri, May 29, 2015 at 3:09 PM, Tier Nolan wrote: >> >> >> >> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen >> wrote: >>> >>> But if there is still no consensus among developers but the "bigger >>> blocks now" movement is successful, I'll ask for help getting big miners to >>> do the same, and use the soft-fork block version voting mechanism to >>> (hopefully) get a majority and then a super-majority willing to produce >>> bigger blocks. The purpose of that process is to prove to any doubters that >>> they'd better start supporting bigger blocks or they'll be left behind, and >>> to give them a chance to upgrade before that happens. >> >> >> How do you define that the movement is successful? > > > Sorry again,
