Quote from: Ayers on April 05, 2017, 10:04:40 AM

Quote from: franky1 on April 01, 2017, 03:58:06 PM

Quote from: Ayers on April 01, 2017, 03:53:35 PM

this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count longest

?? your quoting about transaction FEE's but responding about longest chains??

you didn't understand, i was making a comparison between your argument, and what it look like with an example of the longest chain, their look like they are based on the same principle, isn't it?

in tests it works. the fee gets expensive for spammers with large bloat spending every block...
but in reality of bitcoin mainnet..

if BTCC for instance, inject their own bloated tx every 10minutes into their own mempool. although it appears they are paying say $60 for their own spam tx, when their block gets added to the chain.. they are actually paying $60 to themselves, so BTCC created spam costs are zero.

so it can help reduce outsider malicious spammers from spamming per block. but would require other node rules such as not allowing tx's of 20% of a whole block to even exist, to reduce the chance of self-paying pools from internally spamming their own block

the fee priority mechanism isnt the end solution by itself, but with other things like
maxTXsigops of 2000 when a maxBLOCKsigops is 80,000.... instead of
maxTXsigops of 16000 when a maxBLOCKsigops is 80,000

and some other tweaks. does a hell of alot better job than cores highschool economics of 'just pay more' even for lean tx's that only spend once a month/year