I can’t recommend your first 2 proposals. But I only have the time to talk about the first one for now.
There are 2 different views on this topic: 1. “The block size is too small and people can’t buy a coffee with an on-chain transaction. Let’s just remove the limit” 2. “The block size is too big and people can’t run full nodes or do initial blockchain download (IBD). Let’s just reduce the limit” For me, both approaches just show the lack of creativity, and lack of responsibility. Both just try to solve one problem, disregarding all the other consequences. The 1MB is here, no matter you like it or not, it’s the current consensus. Any attempts to change this limit (up or down) require wide consensus of the whole community, which might be difficult. Yes, I agree with you that the current 1MB block size is already too big for many people to run a full node. That’s bad, but it doesn’t mean we have no options other than reducing the block size. Just to cite some: 1. Blockchain pruning is already available, so the storage of blockchain is already an O(1) problem. The block size is not that important for this part 2. UTXO size is an O(n) problem, but we could limit its growth without limit the block size, by charging more for UTXO creation, and offer incentive for UTXO spending ** 3. For non-mining full node, latency is not critical. 1MB per 10 minutes is not a problem unless with mobile network. But I don’t think mobile network is ever considered as a suitable way for running a full node 4. For mining nodes, we already have compact block and xthin block, and FIBRE 5. For IBD, reducing the size won’t help much as it is already too big for many people. The right way to solve the IBD issue is to implement long latency UTXO commitment. Nodes will calculate a UTXO commitment every 1000 block, and commit to the UTXO status of the previous 1000 block (e.g. block 11000 will commit to the UTXO of block 10000). This is a background process and the overhead is negligible. When such commitments are confirmed for sufficiently long (e.g. 1 year), people will assume it is correct, and start IBD from that point by downloading UTXO from some untrusted sources. That will drastically reduce the time for IBD 6. No matter we change the block size limit or not, we need to implement a fraud-proof system to allow probabilistic validation by SPV nodes. So even a smartphone may validate 0.1% of the blockchain, and with many people using phone wallet, it will only be a net gain to the network security For points 2 and 6 above, I have some idea implemented in my experimental hardfork. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html> > On 27 Jan 2017, at 09:06, 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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
