Quote from: DooMAD on May 21, 2017, 11:08:27 PM

Quote from: d5000 on May 20, 2017, 12:56:41 AM

Regarding the problem to "decrease" the maximum block size eventually: I have thought a bit about it, I'm not an expert but I think also it would be desirable to decrease the maximum block size in the case blocks are far from being full, to dis-incentive spam attacks. It would however not be a show-stopper because the proposal is really so conservative that a spam attack would be very, very expensive anyway.

Regarding franky1's orphan risk because of rescanning nodes: I think there is no other way than what aklan said, to store the maxblocksize changes in the blockchain, so the nodes are aware of the changes when they rescan. There would be perhaps another possibility - to make a conditional decision ("if CheckedBlockSize > ActualMaxBlockSize and CheckedBlockHeight < (ActualBlockHeight - 2016) then AcceptBlock") so nodes can accept larger blocks when they rescan and are more than one difficulty period under the actual block height, but I don't know if this introduces new attack vectors like nodes passing a fake ActualBlockHeight value.

There must be a simple fix, since (at least as far as I remember seeing) no one raised the issue when BIP106 was originally proposed, or, more particularly, when lukejr proposed reducing the blocksize. I'm sure a dev wouldn't have made a proposal with a gaping hole in it. Someone would have voiced concerns well before this point if it were a showstopper. Obviously this wouldn't work as a soft fork, so if all nodes are upgraded, it stands to reason we can tell them not to reject blocks that were valid at the time.

As for blocks being newly appended to the chain at the moment of a reduction, miners could voluntarily operate a soft cap of .01 base and .03 witness under the current threshold if they wanted to play it safe. Effectively they could operate a week in lieu of the actual limit. Plus that's only an issue if the blocks are full to the brim at the time.

there is a simple fix.. without all the cludgy code to drop the blocksize and ensure resyncing doesnt cause issues of orphaning when blocksize drops

afterall decreasing the blocksize hurts everyone, should in a fortnights time demand picks up again but hits the decreased wall.. (so thats just silly) as all the complexities of trying to avoid the rescan orphan things i said before

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..

the solution is simple.. a new fee priority formulae
a better fee priority mechanism ensures the spammers pay more for spamming every block while not causing issues for the normal folk.

Quote from: franky1 on March 03, 2017, 06:33:29 AM

here is one example - not perfect. but think about it
imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. (reasonable expectation)
where
if they want to spend more often costs rise,
if they want bloated tx, costs rise..
to which, things Like LN would become a viable option for those that are innocent but need to spend regularly.

which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding/day trading every 1-10 minutes)

so lets think about a priority fee thats not about rich vs poor(like the old one was) but about reducing respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.(thats what CLTV does)

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx

as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain ($0.01).
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more ($0.44)
if you want to be a spammer spending every block. you pay the price($1.44)
and if you want to be a total ass-hat and be both bloated and respending EVERY BLOCK you pay the ultimate price($63.72)

note this is not perfect. but think about it

in short dcreasing the blocksize consensus can cause more issues for everyone, requires more coding and more cludge
where as a fee priority makes frequent spammers pay more.
the fee priority also makes sure that people, innocent or guilty of spamming DONT pay the same penalty. thus being fair to the innocent that care about the transactions they make and penalise the ones that dont care and just wanna respend as fast as possible but refuse to use LN