Re: [bitcoin-dev] Three hardfork-related BIPs

["t. khan" <teekhan42@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5169 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6418 bytes --]