Quote from: solex on June 17, 2015, 09:18:19 PM

Quote from: _mr_e on June 17, 2015, 06:56:09 PM

Quote from: cypherdoc on June 17, 2015, 06:53:45 PM

Quote from: _mr_e on June 17, 2015, 06:51:44 PM

Quote from: cypherdoc on June 17, 2015, 06:42:36 PM

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o

If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 2 week grace period after 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU

Gavin's solution is very good, and the 2-week grace period a smart move. The reason for this is that it gets the most people on-board with the >1MB change in a controlled manner. It is axiomatic that 100% of miners cannot be in the first 75% to upgrade even if they all wanted to. The 2-week period focuses minds on a known deadline and will likely see a "hockey-stick" uptick in the adoption curve. I would expect 85-90% mining power behind the change before the first >1MB block is mined. If 90% was the original target then Bitcoin's ecosystem growth, supported by the majority, could be stymied by a mere 11% of hold-out miners. The grace period also allows for non-mining nodes to upgrade who are not paying close attention to the whole process.

I like Jeff's BIP 100 with the miner voting, but not sure about the 90% he mentions because of the concern above.
Also, I really don't like a fixed date for everyone to upgrade (although this is far better than no change planned at all). Not using block versioning to change the 1MB means applying a sub-standard software solution for politically correct reasons, i.e. just so people can say "Aha, the users control Bitcoin and are telling the miners what to do." We already know the user consensus on a dozen btc and reddit polls, ecosystem business feedback, and now at least 50% of mining power opinion. So the change should be done as safely as possible. Gavin is perusing this path.

Probably the biggest reason that Core Dev is prepared to let the 1MB limit be constantly hit is that they think they can manage the situation. Perhaps they need to look up the word "hubris" in the dictionary.

A big bazooka in Core Dev's (fairly small) armory needed to "manage" a blocks-limit-full situation is prior roll-out of a change to purge unconfirmed tx from node mempools. This would in theory blunt some of the nasty effects in Mike's Crash Landing scenario.

So, no surprise that a pull request exists to do this:
https://github.com/bitcoin/bitcoin/pull/6281

Quote

Restrict the maximum memory pool size to avoid potential DoS issues.
The mechanism is simply to recursively remove the transactions which have the lowest priority until the memory pool is below the maximum size.

(my emphasis)
Hmm, DoS issues like ordinary users legitimately trying to use Bitcoin after tx are backing up when free block-space has vanished?

However, what appears to be a bed of roses rapidly turns into a bed of thorns...

Quote

@sipa ah so if a wallet transaction is evicted from the mempool the conflict tracking stuff will all break? that's nasty
the rabbit's hole of things to fix gets ever deeper

Their bazooka has a barrel bent into a U-shape.

Another big concern about mempool limiting is the implications for IBLT, which is Bitcoin's best hope for challenging the likes of Visa and MC in the medium, not long-term.
Randomly ejecting unconfirmed tx, or allowing a user-configurable max-mempool-size, creates non-uniform mempools. This seriously degrades the potential for IBLT, especially when miners want to clear most of the unconfirmed tx, to maximize revenue when the block reward is lower.

The is no mempool limit right?