Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
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 tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com 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, I keep auto-sending from gmail when trying to delete. In theory, using the nuclear option, the block size can be increased via soft fork. Version 4 blocks would contain the hash of the a valid extended block in the coinbase. block height 32 byte extended hash To send coins to the auxiliary block, you send them to some template. OP_P2SH_EXTENDED scriptPubKey hash OP_TRUE This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block. To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig. The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash. This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain. The extended chain could use the updated script language too. This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Fri, May 29, 2015 at 5:39 PM, Raystonn . rayst...@hotmail.com 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. I don't think so. The lower security is the potential centralisation risk. If you have your money in the root chain, then you can watch it. You can probably also watch it in a 20MB chain. Full nodes would still verify the entire block (root + extended). It is a nuclear option, since you can make any changes you want to the rules for the extended chain. The only safe guard is that people have to voluntarly transfer coins to the extended block. The extended block might have 10-15% of the total bitcoins, but still be useful, since they would be the ones that move the most. If you want to store your coins long term, you move them back to the root block where you can watch them more closely. It does make things more complex though. Wallets would have to list 2 balances. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On May 28, 2015 10:42 AM, Raystonn . rayst...@hotmail.com wrote: I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. I could not agree more that developers should not be in charge of the network rules. Which is why - in my opinion - hard forks cannot be controversial things. A controversial change to the software, forced to be adopted by the public because the only alternative is a permanent chain fork, is a use of power that developers (or anyone) should not have, and an incredibly dangerous precedent for other changes that only a subset of participants would want. The block size is also not just an economic policy. It is the compromise the _network_ chooses to make between utility and various forms of centralization pressure, and we should treat it as a compromise, and not as some limit that is inferior to scaling demands. I personally think the block size should increase, by the way, but only if we can do it under a policy of doing it after technological growth has been shown to be sufficient to support it without increased risk. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I personally think the block size should increase, by the way, but only if we can do it under a policy of doing it after technological growth has been shown to be sufficient to support it without increased risk. Can you be more specific about this? What risks are you worried about? I've tried to cover all that I've heard about in my blog posts about why I think the risks of 20MB blocks are outweighed by the benefits, am I missing something? (blog posts are linked from http://gavinandresen.ninja/time-to-roll-out-bigger-blocks ) There is the a sudden jump to a 20MB max might have unforseen consequences risk that I don't address, but a dynamic increase would fix that. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. My opinion is these things are better left to a decentralized free market anyhow. From: Gavin Andresen Sent: Thursday, May 28, 2015 10:19 AM To: Mike Hearn Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Thu, May 28, 2015 at 1:05 PM, Mike Hearn m...@plan99.net wrote: Isn't that a step backwards, then? I see no reason for fee pressure to exist at the moment. All it's doing is turning away users for no purpose: mining isn't supported by fees, and the tiny fees we use right now seem to be good enough to stop penny flooding. Why not set the max size to be 20x the average size? Why 2x, given you just pointed out that'd result in blocks shrinking rather than growing. Twenty is scary. And two is a very neutral number: if 50% of hashpower want the max size to grow as fast as possible and 50% are dead-set opposed to any increase in max size, then half produce blocks 2 times as big, half produce empty blocks, and the max size doesn't change. If it was 20, then a small minority of miners could force a max size increase. (if it is less than 2, then a minority of minors can force the block size down) As for whether there should be fee pressure now or not: I have no opinion, besides we should make block propagation faster so there is no technical reason for miners to produce tiny blocks. I don't think us developers should be deciding things like whether or not fees are too high, too low, . -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
