Gdday.
Alright now i Think things are moving forward.
I managed to spend the tbbp only highriskstake that i made earlier.
Like you said :
It was the chain one, so i believe i was trying to spend the entire amount like you said and it didnt work for me, although i was sure i tested to just withdraw a bit of it aswell to test and it didnt work, im thinking i didnt calculate in the penalty in the transaction and therefore the transaction didnt work.
Now i set spend to just 10k and the transaction worked , high risk spend.
looks like i received : 48.71422014279157% penalty for shorting the highrisk stake.
Then i created Another highriskstake but for 31 days and spent it.
highriskbbpstake 2999999 31 1
"Commitment Days": 31,
"DWU": 183.8171421328033,
"!WARNING!": "When you promise to lock for 31 days for a high yield reward, you hereby AGREE that you may be PENALIZED by up to 50% of the value of your UTXO. If you do not fulfill your obligation, your original UTXO will have burn fees deducted from it. EXAMPLE: You have a 100,000 BBP coin. You lock it for 90 days for a 40% DWU. On the 15th day you try to spend the coin (breaking your obligation). You will be penalized 40%*2=80% (capped at 50% max) of your original UTXO. (If you do not agree please use our conservative staking feature: easybbpstake.) Thank you for using BIBLEPAY. ",
"BBP Value USD": 1468.41205292861,
This time it worked aswell.
close to 50% penalty this time aswell.
Took a screenshot of the final spend, looks solid from here.
17:02:33
listutxostakes 0 0
"DWU": 252.9650150395335
}
EDIT: These tests i did on the v1.6.1.4-Harvest
Hi Earlz,
Sweet, yes looks relatively solid, although I think I will go ahead and make a google sheet to track 10 of them over a little duration just so we can see the icons change too.
On the 48-49% penalty, thats good, sounds good, I did end up capping the penalty at 50% just to give the user an incentive to terminate it for the extra cash (rather than keep it to the end)
cause who would terminate it (while reaping from our daily kitty) if we penalized them 80%+ etc. So basically, we penalize them at double what we believe it costed us, but we cap it at 50% no matter when the fault occurs.
Yes your other highrisk stakes look good too. Im not too concerned about any risk about continually paying someone for a stake they spent (because the code is solid that detects spent utxos), although Im definitely concerned about the ability to "covertly spend a high risk stake" and not pay the fee. I thought about this extensively , and I believe we have it covered. Basically heres what would happen: If you spend a high risk stake from the UI, the transaction will not be created unless the (burn-network-fee) is included, and if someone were to forge or falsify a fake version of biblepay, and drop one hex version of the tx on the network, the other nodes would reject that tx in the memory pool. Same thing would happen if they create a binary transaction from the RPC and try to spend that coin - the tx will be rejected in the mempool. So that risk should be eliminated.
Now all I have to do is make the spreadsheet for the sake of verifying the icons and spend status.
Did you take a look at the icon state of each of your high risk stakes in coin control? You should see a DOVE for the one(s) that are Fulfilled (and free to spend), and a chain-hard-drive looking icon for the ones that are not fulfilled yet?
I feeel pretty good about referral codes also. From what I can see, there is no attack vector possible (if someone uses too many codes, they get capped at 10% of the portfolio size). If many codes are attached, they are capped. If people share codes among friends, they are capped. Just to clarify, codes are also limited to one distinct code per direction per cpk, so there is no unfair advantage among any player, either. Additionally, this reward is decreasing over 700 days at the decay factor - basically my feeling is we ramp up some referral code reward activity now for the next two years and that sort of gets phased out as the portfolios age and this is our chance to popularize biblepay. Obviously these are assessed at the sanc level so there is no risk of anyone falsifying a greater referral code than another...
So yeah I will take care of the spreadsheet next, do you have any other concerns in this version?
I also need to make that CSV wiki for us right now so we can test csv greeting cards.
Thanks.