Regarding #1, I agree with Johnson Lau and others who have responded since then—this proposal is not appropriate and should not be adopted for the following reasons:

1. Miners will view it as way too little, delivered way too late. And as soon as you say 300kb blocks, you've lost them all.

2. "Spam" - You're very fixated on this concept of spam transactions, but the transactions that you deem as spam are legitimate, fee-paying transactions. They're not a problem for miners. It's only a problem to you as you've arbitrarily decided some transactions are legit and some are not. It's an imaginary problem and we should focus on designs that solve real problems instead.

Also, even if you changed the max size to 300kb, transactions that you (and as far as I can tell, only you) consider spam will still be in there! They'll just be paying a ridiculous fee along with everyone else.

3. 17% per year growth rate - This is making the assumption that the current 1MB limit is already at the upper limit supportable by the network. This isn't even remotely true, and starting this rate at the current limit would cause the system to lag far behind the actual capability of the network for no reason.

4. Nodes - Individuals have no incentive to run full nodes and we've already passed the time where it makes any sense for them to do so. Therefore restricting the blockchain size in an attempt to keep individuals running nodes is futile at best and likely very damaging. Miners and businesses using Bitcoin do have an incentive to run nodes and over the years we've seen a migration of nodes from weak hands (individuals) to strong hands (businesses).

Overall, this proposal would hamstring Bitcoin Core and would drive miners towards Unlimited.

- t.k.

On Thu, Jan 26, 2017 at 8:06 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I've put together three hardfork-related BIPs. This is parallel to the ongoing
research into the MMHF/SHF WIP BIP, which might still be best long-term.

1) The first is a block size limit protocol change. It also addresses three
criticisms of segwit: 1) segwit increases the block size limit which is
already considered by many to be too large; 2) segwit treats pre-segwit
transactions “unfairly” by giving the witness discount only to segwit
transactions; and 3) that spam blocks can be larger than blocks mining
legitimate transactions. This proposal may (depending on activation date)
initially reduce the block size limit to a more sustainable size in the short-
term, and gradually increase it up over the long-term to 31 MB; it will also
extend the witness discount to non-segwit transactions. Should the initial
block size limit reduction prove to be too controversial, miners can simply
wait to activate it until closer to the point where it becomes acceptable
and/or increases the limit. However, since the BIP includes a hardfork, the
eventual block size increase needs community consensus before it can be
deployed. Proponents of block size increases should note that this BIP does
not interfere with another more aggressive block size increase hardfork in the
meantime. I believe I can immediately recommend this for adoption; however,
peer and community review are welcome to suggest changes.
Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
Code: https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize
(consensus code changes only)

2) The second is a *preparatory* change, that should allow trivially
transforming certain classes of hardforks into softforks in the future. It
essentially says that full nodes should relax their rule enforcement, after
sufficient time that would virtually guarantee they have ceased to be
enforcing the full set of rules anyway. This allows these relaxed rules to be
modified or removed in a softfork, provided the proposal to do so is accepted
and implemented with enough advance notice. Attempting to implement this has
proven more complicated than I originally expected, and it may make more sense
for full nodes to simply stop functioning (with a user override) after the
cut-off date). In light of this, I do not yet recommend its adoption, but am
posting it for review and comments only.
Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki

3) Third is an anti-replay softfork which can be used to prevent replay
attacks whether induced by a hardfork-related chain split, or even in ordinary
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for the
Bitcoin scripting system that allows construction of transactions which are
valid only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev