TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

oh, that's strange, I got block reward without even staking (I have zero in the wallet).

should be on the same chain as I can see your 3 sancs

getblockhash 4297
7b8125733561d649d5a89694dc8e0f7509abae344e7a4da9b5a233911b04bc30

Btw, you can create a sanc if you want (you might want to wait 150 blocks to see if our next superblock passes through gracefully), but either way, its up to you.


Let me look into your block reward.

Btw you can also type 'getblock 4297' in biblepay.

Btw, you can create a sanc if you want (you might want to wait 150 blocks to see if our next superblock passes through gracefully), but either way, its up to you.


Let me look into your block reward.

Btw you can also type 'getblock 4297' in biblepay.

So just on a side note, the last superblock was @ 5350 and I believe there were 2 GSC payments in there, and they occur once every 205 blocks- so this height is just a normal height.

This 10.5k payment is just a normal mining payment.  Btw, you as the miner will get the entire reward if the sancs didnt vote more than the threshhold for another sanc (IE you claim the mining + the sanc reward in that case).

So yeah we need to get some GSC transmissions out within 100 blocks and see if we can be in the next superblock.

To manually send one type:  exec sendgscc

If it does not appear, most likely it has to do with the internal timer, I will go over that asap.

So on the failed client-side GSC transmissions, if your node didn't send one, you can look in your log and grep for
CreateGSCTransmission::Fail

Most likely the reason is:  Too many transactions for fee policy; this means that since we did all mining up to this point our wallets have so many small rewards, the gsc transmission (50% of the transactions) would be bigger than 10K (the default max size).  On this note, I will increase this to 100K for the next version.

In the mean time what you can do to get around this problem is enable coin control, go to coin control, send yourself 50-100 of the transactions back to yourself to consolidate the wallet.  Then do the 'exec gscc'.

I will also bubble the GSCC error up to the UI for the 'exec gscc' in case this happens after we raise the tx limit.

So now I just consolidated my coins and my gscc went out. 


Now we are waiting for 50 more blocks for the next superblock.

1.4.0.6b-TestNet Mandatory Upgrade

- Remove log spam
- Standardize minimum quorum level for both creating and emitting GSC
superblocks
- Require the minimum quorum in IsSuperblockTriggered for GSCs
- Change DGW for testnet to be more straightforward
- Fix bug in getchaintips where it does not show correct branch length
- Allow miner to know if ABN weight is sufficient when abn is off

It looks like things are working!

Feel free to upgrade.

I've got to head out to church but if anyone is having problems sending a gscc, in addition to the coin-age advice above (which works alone) but this is for convenience, you can optionally add this to your config file:

campaignname_coinagepercentage=.001-.999

This is the coin age percentage the client side uses to select coins.  If you have too many coins, you could for example do:
pog_coinagepercentage=.005

And it would theoretically use .005% of your coins (meaning you dont need to consolidate them in coin control) and they would eventually auto consolidate.
Then you can increase the percentage later.

This is the hash Im seeing currently guys:

15:36:49

getblockhash 6100


15:36:49

97f052dc466dbfca07b386618aea0c9d70dccd15b974890d929f0420b1c6c60d

This is the hash Im seeing currently guys:

15:36:49

getblockhash 6100


15:36:49

97f052dc466dbfca07b386618aea0c9d70dccd15b974890d929f0420b1c6c60d

I'm on it

BTW, I can create a sanctuary as well, need 1 000 000 more tBBP:

yTdd2pbWbHTnxjj8iGmRgzHFraQcMDjP2w

BTW, I can create a sanctuary as well, need 1 000 000 more tBBP:

yTdd2pbWbHTnxjj8iGmRgzHFraQcMDjP2w

Sure, that will help stabilize things.  Sent.

Ok all, we are doing really good, but we need an update.

There is a missing rule on the sanc side, and I feel that if we don't stop now we may go out of sync without the rule.  The chain is good, but please stop testing.

I have a nice punchlist of things we need to add anyway.

Please hang on for the next version.

1.4.0.7-TestNet Mandatory Upgrade

- Add 'select some' feature to coin control to help people consolidate
wallets (this selects 20% of the list)
- Add 'exec bankroll' rpc feature - this allows people to consolidate
coins into bigger notes
- Added business logic to prevent generation of bad gsc superblocks
- Added checkpoint
- Allow forcing a gsc client transmission (exec sendgscc)
- Widen Amount in Send money UI page
- Add nickname to exec prominence, Add ability to run prominence from
prior heights, future or last superblock (exec prominence last | future
| height); default is future
- Add nickname to exec getcampaigns
- Raise absurdly high fee 100* higher (this is about 1 bbp compared to
.001 bbp) as the fee was too low to send a 100 output transaction from
coin control in the past
- Increment version for prior incompatibility
- Remove Log Spam


** I believe the Sanctuaries will need to:
rm evodb -r
rm chainstate -r
rm blocks -r
resync
** 
(The regular nodes are most likely OK).  We need to ensure we are all in sync after restarting.

Hash:




23:33:59

getblockhash 6450


23:33:59

640b069e1e802d1ae8ab2a632674b9617055974bc41e21391e30f05054a0eecf

Now that things are stabilizing, does anyone have any questions about what we are actually doing with GSCs or how the transmissions or rewards are structured?

Basically, since testnet has 2 minute blocks, the daily contract zips by much quicker (IE about 3.25 hours for each day zipping by).

So the idea is, once per day, the participant of a campaign will receive a "Smart contract reward"  (You should see this in your transaction list).  (Btw, I recommend testing in QT for a while until all of our bugs are worked out, as you can see the labels and things and double click on the transaction etc).

Currently, the miner is set to send a "GSC Transmission" once an hour (this could be more like once per 12 hours in Prod, to prevent spam).
The GSC transmission contains the Stake that your node will send for the first campaign (the only active campaign: POG).

So in theory, if we hone in on one smart contract day, we should see 3 transmissions, and one payment.

We should double click on the 3 transmissions and check how much coin-age we sent, and then reconcile this to the points and the reward in the following superblock reward.


EDIT: In the next version we will have a command to audit the points per tx.

** New version coming in one hour **

1.4.0.8-TestNet Mandatory Upgrade

- Add Watchman On the Wall (BiblePay version)
- Modify Sanctuary IsSuperblockValid trigger rule to trigger when
fCachedFunding is set
- Add rpc command 'getpogpoints' (this shows the pog points for a
transaction)