Quote from: Lauda on May 06, 2017, 10:46:17 AM

Quote from: franky1 on May 06, 2017, 10:43:03 AM

certain multisig.. pfft. and why do they deserve to have 20% of a block, without paying 20% of the price

It looks like someone hasn't been reading the Bitcoin Core code again.

This PR also negates any concern of your "easy to spam via 5 max sigops TXs" nonsense:

Quote

Treat high-sigop transactions as larger rather than rejecting them
When a transaction's sigops * bytespersigop exceeds its size size, use that value as its size instead (for fee purposes and mempool sorting). This means that high-sigop transactions are no longer prevented, but they need to pay a fee corresponding to the maximally-used resource.

All currently acceptable transactions should remain acceptable and there should be no effect on their fee/sorting/prioritization.

https://github.com/bitcoin/bitcoin/pull/8365

yor not understanding it
1. the 5x is about the blocksigoplimit/5=txsigop limit.. (consensus+policy)

2. the 'larger than rather than reject' is more about exceeding 100kb of data that SOME tx's would accumulate while trying to make 4k sigops.

which is where i knew you would knitpick.. so i pre-empted your obvious crap.

Quote from: franky1 on May 04, 2017, 11:22:46 PM

screw it. i know there are many knitpickers
c) 1input:2856output=97252bytes~(2.857k sigops)
7tx of (c)=680764bytes(20k sigops)

with a TX that stays below the:
bloat of 1mb block
bloat of 100k 'larger than' limit (of REAL BYTES)

while filling the blocksigop limits to prevent any other transactions getting in.

PS the cludgy maths that core has in the 'pull/8365' is just about trying to assume a fee for the tx. but.. ultimately if a pool was not using that cludgy maths/core implementation for the FEE. a pool would add the TX with a cheaper rate that doesnt have the cludgy maths.

this is why REAL rules. real code, should be used.. not bait and switch hope and faith cludgy maths crap.