3 ms·
>No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-
by pmorici 11y ago
>No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time.
If that is such a huge concern then why is core proposing a hard-fork to change the way the difficulty is adjusted? [0] If they are for adjusting the difficulty computation why not raise the block size at the same time?
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016...
- nadaviv 11y ago"Core" is not proposing anything, that difficulty adjustment hard-fork proposal was brought up on the mailing list by a member of the community and is in early discussion stages. There's no consensus that this change is necessary, and there hasn't been an in-depth discussion about how and when it should be incorporated (if accepted) and whether it should be alongside the block-size hard-fork or separately.
- pmorici 11y agoThat was made by Luke-jr one of the more influential and out spoken developers who is strongly opposed to a block size increase. He's also associated with Blockstream.
- makomk 11y ago"Core" isn't proposing a hard-fork to change the way difficulty is adjusted, one developer was and he changed his mind after realising this wasn't practical: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012494.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016... (Also, that's Luke-Jr who I guess technically counts as a Bitcoin Core developer, but uses his own heavily modified client.)