So I started to run a few basic calculations last night regarding scripting attack vectors (in relation to potentially needing a guard in the program to charge exponentially increasing tithe fees when under attack) (as I was considering adding a fee to each donation transaction vout > qty(10), increasing from 1bbp per 1bbp per vout and rewarding this to the reaper) and I quickly came to the conclusion that we dont need it - because the number of transactions taken in the pool causing the diff to govern the problem is very small. If a whale tithes just 100 times in a block, the legal tithes (approx 280,000bbp) would raise the diff by almost 50% on the very next block - mitigating the problem immediately. The other issue is, we dont want to hurt newbies. A legal tithe is a legal tithe if it fits within the difficulty params. So I feel simplier is better, just leave it out. (On a side note, the size of a transaction for small donations IE attacking us with 1 bbp tithes can be mitigated with increasing tx-relay fees - which we definitely need and will definitely implement as of next mandatory).

Besides this we have our normal transaction fee (which btw I found a bug in last night) - it is approx 100* too low - I made some notes in the code about a 130 input transaction having a fee of only .003 that should have been .300 bbp. If we "fix" our minimum relay fee, this should also discourage tithe attacks, as the size taken up by the transactions will quickly increase the cost of each transaction with normal BBP fees of 2bbp, 3bbp, 5bbp etc as the block size grows.

So I feel we have our bases covered regarding tithe attack vectors related to scripting.

1.1.6.8 - Mandatory Upgrade (TestNet)** Note: This mandatory will only disconnect old versions, but will not hard fork so as to keep the chain running smoother** Forensically we now have more specific logging with the version in the POG message

1.1.6.8 - Mandatory Upgrade (TestNet)** Note: This mandatory will only disconnect old versions, but will not hard fork so as to keep the chain running smoother** Forensically we now have more specific logging with the version in the POG message

Thanks for the example. On a side note we have a feature in the next version that will allow you to type exec pogpool height, and diagnose some of this , although that feature is broken right now in your version. But anyway looking at your wallet and its rewards, you received the first POG reward on block 91097 for 97.09 bbp.

So here is what happened: Those two pog rewards are incorrectly listed as POG reward on the UI. They are actually mining rewards. If you look at the actual transaction, the 97.09 was the reaper reward for solving the block .

So I see the bug, and its being fixed now (as far as the display issue). Please double check in the next version that we killed it - those two should change to Mining rewards when you boot the next version.

So here is what happened: Those two pog rewards are incorrectly listed as POG reward on the UI. They are actually mining rewards. If you look at the actual transaction, the 97.09 was the reaper reward for solving the block .

This same thing happens when the miner wins the PODC superblock, maybe an easy fix?