> Is there a reason such a validation check is a bad idea? We already have
> OP_RETURN to store arbitrary data that is limited to 80kb.
A reason to not ban storing arbitrary/non-functional data is that people will
still want to store things, so will start (ab)using useful data to do so, which
I think the fundamental disagreement here that's causing the controversy and
impasse is this:
Those in favour of Full RBF see trusting and relying on predictable mempool
policy as a fundamentally flawed bad idea. Node policy is not a consensus rule
- a miner has always been allowed to
Core adding full RBF is a change of node policy that may be highly inconvenient
for zero-conf users, but there has always been and will always be a risk of a
double-spend for anyone that treats zero-confirmation transactions as settled.
It's literally in the name - this transaction has zero
> Let's allow a miner to include transactions until the block is filled, let's
> call this structure (coining a new term 'Brick'), B0. [brick=block that
> doesn't meet the difficulty rule and is filled of tx to its full capacity]
> Since PoW hashing is continuously active, Brick B0 would have
