Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
the simple solution is a better fee priority formulae..
that way you dont have to decrease the blocksize that hurts everyone should in a fortnights time demand picks up again but hits the decreased wall.. (as thats just silly)
but if the block remained at 4mb but was 'empty' it would cost a spammer a hell of a lot more to fill it. compared to a block that decreased to under 4mb
by decreasing the blocksize means he can fill the block with less transactions. which is stupid aswell as all the complexities of trying to avoid the rescan orphan things i said before
a better fee priority mechanism ensures the spammers pay more for spamming every block while not causing issues for the normal folk
that way you dont have to decrease the blocksize that hurts everyone should in a fortnights time demand picks up again but hits the decreased wall.. (as thats just silly)
but if the block remained at 4mb but was 'empty' it would cost a spammer a hell of a lot more to fill it. compared to a block that decreased to under 4mb
by decreasing the blocksize means he can fill the block with less transactions. which is stupid aswell as all the complexities of trying to avoid the rescan orphan things i said before
a better fee priority mechanism ensures the spammers pay more for spamming every block while not causing issues for the normal folk
Well, I did ask:
Was Litecoin's spam fix ever implemented in Bitcoin? And if not, could we look at implementing that as part of this proposal?
which is related to fees making it harder to spam, and then the thread died for almost 3 days.
But yeah, let's look at the fee priority mechanism as well. Each level of security we can add makes it that bit more robust.
value of a TX is meaningless.. and 'rich' spammers got around the old fee mechanism by having a TX where one output had 10kbtc and the other outputs of the same tx had 1sat each
which allowed him to not pay a fee because the old formulae was based on value.
this ended up hurting everyone else though. especially those from 3rd world countries who were not spammers, were not able to have 10k btc to counter the fee, where they just innocently wanted to send more than a couple hours labour (only a few cents) but ended up paying more in fee's.. while malicious spammers didnt pay a fee because they simply worked around the 'value' test
all that matters is how 'fresh' the coins are and how bloated the tx is.
i see no reason at all for ANYONE to have the need for 10%-20% allocation of a block just for 1tx
so things like
4k txsigops of 20k blocksigops
or
16k txsigops of 80k blocksigops
is literally asking for trouble.(5tx fills the block)
i suggest if the block is going to be 4mb (80k blocksigops)
then make txsigops 2k... and make sure even if blocksigops rises.. txsigops does not. that way each increase makes it harder.
also
the 100kb 'larger than' tx data rule.. again who the hell deserves 10% of block space.
bring that down to 10kb or less. and keep it down even if the blocksize increases.
that way it makes it cost more to fill up