Testnet - Test Proof of Giving

[Rob Andrews]

Anyone with a chain height higher than 87000, please erase and resync.

The problem is if your height was higher than us when you upgraded, you let more blocks in on 1.1.6.5 (that will be rejected by 1.1.6.6) so its preventing us from syncing.

[Rob Andrews]

Ok, Testnet seems stuck at block 87697

Im surprised so few are testing - I believe we should be able to recover because the rule was our normal rejection rule for old versions; however on a side note Im starting to dislike that rule as it really shakes up the whole system - its as if its worse to require a mandatory that way than for me to add a block version field on my logging - anyway



getblockhash 87915
f042dfcb5d9265ef681ffbe1bf3577274bcdcd13411d340a37d179ca10616810

This morning looks like we got past that does yours agree?  I have two nodes running that agree.  My 3rd is not even synced halfway let me see if I can get a third up to 87915.

[sunk818]

getblockhash is correct for me.

Keep getting this:

2018-12-15 18:03:55
Illegal tithe @height 87725.000000, max amount 296.500000  amount 296.710000 vout 1
Illegal tithe @height 87835.000000, max amount 296.490000  amount 296.710000 vout 2
Illegal tithe @height 87883.000000, max amount 296.930000  amount 297.150000 vout 1 ProcessNewBlock : ACCEPTED

If a tithe is illegal, maybe one can be resent as a test and if it works send it along.

Or illegal tithe should be abandoned? It keeps showing up in the logs... is that right?  I assume it'll keep showing up because the transactions can't be abandoned currently or resent?

[Rob Andrews]

getblockhash is correct for me.

Keep getting this:

2018-12-15 18:03:55
Illegal tithe @height 87725.000000, max amount 296.500000  amount 296.710000 vout 1
Illegal tithe @height 87835.000000, max amount 296.490000  amount 296.710000 vout 2
Illegal tithe @height 87883.000000, max amount 296.930000  amount 297.150000 vout 1 ProcessNewBlock : ACCEPTED

If a tithe is illegal, maybe one can be resent as a test and if it works send it along.

Or illegal tithe should be abandoned? It keeps showing up in the logs... is that right?  I assume it'll keep showing up because the transactions can't be abandoned currently or resent?

So on the illegal tithe, I can say with relative certainty what I "think" is happening.  (Note that Illegal Tithe and POG Pool Recipients Invalid are mostly for logging, for us to ensure we have prevented those problems in test, and then they become very rare cases of things that arent supposed to happen in prod).

I believe due to people upgrading and being on forks, the difficulty level is not exactly the same on 3 forks.  Once we all agree on the block hash, we should re-tithe, and then watch the log for one day and see that the error has dissapeared.

To answer your question though the pool will not induct an illegal tithe.  But those will be forced on their own chain anyway, so this error should dissapear once we are synced together.

(The givers actual tithe was legal on his own chain) - just illegal on our chain.

[sunk818]

The POG reward is a coinbase, so it takes 120 confirms to become spendable (just like mining revenue).

On a side note, all the pool rewards for one block are contained in one transaction.

I'm seeing PoG reward available after 6 confirmations.

[sunk818]

the above command isn't working for me in the debug console.

12:52:24 exec tithe
12:52:24 You must specify amount, min_coin_age (days), min_coin_amount.  IE: exec tithe 200 1 1000. (code -1)

12:52:27 exec tithe 250
12:52:27 JSON value is not a string as expected (code -1)

[sunk818]

So on the illegal tithe, I can say with relative certainty what I "think" is happening.  (Note that Illegal Tithe and POG Pool Recipients Invalid are mostly for logging, for us to ensure we have prevented those problems in test, and then they become very rare cases of things that arent supposed to happen in prod).

I believe due to people upgrading and being on forks, the difficulty level is not exactly the same on 3 forks.  Once we all agree on the block hash, we should re-tithe, and then watch the log for one day and see that the error has dissapeared.

To answer your question though the pool will not induct an illegal tithe.  But those will be forced on their own chain anyway, so this error should dissapear once we are synced together.

(The givers actual tithe was legal on his own chain) - just illegal on our chain.

Is there a frequency that is observed for "tithing"? TestNet seems to be about once an hour. If I were to tithe 30 minutes after an automated send, that is considered an illegal tithe?  If the transaction is not created, it wouldn't be in the "unconfirmed" stage. Unconfirmed seems like it would encourage more confusion to new users.

[Rob Andrews]

I'm seeing PoG reward available after 6 confirmations.

Oh you are relying on the checkmark on the UI, that is just a display bug.

Coinbases are not spendable until 102 confirms.  You can look in your "unconfirmed" balance to see all your POGs arent available.

Ill look at the checkmark bug.

[Rob Andrews]

Is there a frequency that is observed for "tithing"? TestNet seems to be about once an hour. If I were to tithe 30 minutes after an automated send, that is considered an illegal tithe?  If the transaction is not created, it wouldn't be in the "unconfirmed" stage. Unconfirmed seems like it would encourage more confusion to new users.

No you can manually tithe as often as you want and it wont be illegal - as long as its a legal tithe.  Legal means it fits the difficulty parameters.

If it were any other way people would try to game the system by writing scripts to tithe.

The frequency is once per hour in testnet.

Im making it so you can override that in the settings next.

[Rob Andrews]

the above command isn't working for me in the debug console.

12:52:24 exec tithe
12:52:24 You must specify amount, min_coin_age (days), min_coin_amount.  IE: exec tithe 200 1 1000. (code -1)

12:52:27 exec tithe 250
12:52:27 JSON value is not a string as expected (code -1)

Good find, I just added this to the bug list.  Working on it.

[mint]

Question to the user who crashed, did you crash with 0 blocks in the chain?  If so I reproduced and fixed that in 1164, if not let us know how to reproduce.

I had crashes with 1163, but now I have not been able reproduce them.

[Rob Andrews]

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

- Fixed 'exec tithe' to allow just amount
- Added low and high estimated ROI to 'exec titheinfo'.  Note:  The ROI is based on: Daily_POW_Rewards / TitheCap, divided by 2.  The divided by 2 is assuming the miner spends half of the profit on electricity.
- Removed non-biblepay-team warning in exec getboincinfo
- Fixed the PODC Reward and POG Reward "clock" symbol to require 120 confirms in the UI transaction list
- NEW USER SETTINGS:  Made the wallet Not tithe automatically by default, unless the 'tithe=1' setting is set (or user uses the one-click mining configuration setup).
Possible settings:
Missing = Wallet will not auto tithe
tithe=0 or -1 Wallet will not auto tithe
tithe=1 : Wallet will tithe automatically according to default network SPORK (once per 4 hours in prod, once per hour in testnet)
tithe=NN : Enter any number in minutes above 2, and the wallet will tithe this often

- Added POG Difficulty to overview page

[MIP]

1.1.6.7 - Mandatory Upgrade (TestNet)

Also available in Linux PPA repository
sudo add-apt-repository ppa:biblepay-official/testnet

and MacOS
http://www.biblepay.org/biblepaycore-testnet.dmg

[Rob Andrews]

Also available in Linux PPA repository
sudo add-apt-repository ppa:biblepay-official/testnet

and MacOS
http://www.biblepay.org/biblepaycore-testnet.dmg

Thanks for building this.

Note everyone, I found a bug in 1167 that will crash the node during mining.

1.1.6.8 is building for windows now.

[Rob Andrews]

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.