Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 ... 137 138 139 140 141 142 143 [144] 145 146 147 148 149 150 151 ... 277
2146
I got my DWS rewards last night, but there is no whale icon.  So if you are looking for yours look for smart-contract-reward.

Ill look into this issue.

2147
Will someone please test unbanked, to ensure you get auto payments each day and dont need to post a stake?

Im going to start a 2nd cpid soon but havent got around to it.

You just need to lower your rac down to below 250 and above 1.

I started an unbanked CPID; waiting for RAC to increase.

I noticed that on brand new WCG CPIDs, we cant associate them right away because there is a delay on the WCG side.  Ill see if I can detect the condition and maybe we can add one more result code - something at least explaining the expected amount of time to wait between a new account and the time the 'associate' will actually work.   I emailed IBM about it - from the boinc side I can see the CPID, from the WCG side - their XML api returns 'name does not exist' but from the WCG web page the name does exist.  I also will re-clarify what we need to do about the data export reqs.  Im still not 100% sure if we need to demand the radio button be set to export stats or not.


2148
What happens if we send funds to DWS but don't get it back? For example, in this last situation we lost all the test tBBP. Is there a way to recover in case of catastrophe?

1) Yes we lost the tBBP, but thats because the test format changed; in prod that would never happen.  Obviously, we would not release the change without a smooth cutover between ended payments and new payments in prod.
2) As far as the question though, if there is a technical glitch or for some reason, the payment is not paid back, it would be lost.  There is no mechanism in BBP for it to re-send it if the sancs don't send it to you on the due date.  To clarify though, I originally planned on making the algo detect 'unpaid items that need paid today' and then I realized that adds risk.  Right now the sancs are forced to pay things that are due from a certain block range; and the only risk would be the GSC contract fails that day.  BBP only risks sending out a max of 5mil per day.  If I started adding in the "possibility" of missing a day and sending 2* the amount that opens us up to way too much capital risk.  I think 5mil deflating is manageable, since our great deflation lowers this continually.  And allowing 5 mil per day in burns is good enough for most of us etc.  So at this point I feel the simplicity is safer than the riskiness of adding complexity and capital risk.  I will continue to explore other options for prod, such as 'longer term maturing coinbases and timed transactions', but those are not guaranteed to work for this use case.

  Its currently a use-at-your-own-risk feature, and this way it passes the Howey test also.


2149
Will someone please test unbanked, to ensure you get auto payments each day and dont need to post a stake?

Im going to start a 2nd cpid soon but havent got around to it.

You just need to lower your rac down to below 250 and above 1.


2150
BiblePay TestNet
1.4.7.4 - Leisure Upgrade

- Ensure all GSC transactions use the external purse only, and all change comes back to the external purse.
- Add 'exec auditabntx txid', to allow us to see the VIN source, amount, and coin*age, and the VOUT destination and change addresses.



2151
not sure where you see yi* because i cant see it

but here are somescreenshots



Code: [Select]
14:17:51

{
  "Command": "rac",
  "cpid": "e7c056024cd3b781edd5af37965c652c",
  "CPK": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 16502,
  "team_name": "Biblepay",
  "researcher_nickname": "capulo",
  "researcher_country": "SLOVAKIA",
  "total_wcg_boinc_credit": 69376573.58,
  "total_wcg_points": 485636015.06,
  "external_purse_total_coin_age": 963515.4535069445,
  "coin_age_percent_required": 0.4039957165891909,
  "coin_age_required": 379620.9615492278,
  "wcg_id": 1066130,
  "rac": 19579.781208
}


14:21:40

sendgscc wcg


14:21:40

{
  "Results": true
}


14:21:47

exec rac


14:21:47

{
  "Command": "rac",
  "cpid": "e7c056024cd3b781edd5af37965c652c",
  "CPK": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 16502,
  "team_name": "Biblepay",
  "researcher_nickname": "capulo",
  "researcher_country": "SLOVAKIA",
  "total_wcg_boinc_credit": 69376573.58,
  "total_wcg_points": 485636015.06,
  "external_purse_total_coin_age": 727273.1985069445,
  "coin_age_percent_required": 0.5319784839157702,
  "coin_age_required": 379620.9615492278,
  "wcg_id": 1066130,
  "rac": 19579.781208
}

txid 6ca683c024cf65a0d1c69ce9d6ca198a1ee1b3a7259cecddc8becb6426fcd71f

as you can see, some coins was taken from cpk and some from normal address. and before i had 509k in cpk, and after 491k and 18k was moved to normal address

i think that if i moved 1m to cpk, then only these coins will be used as source for coin age and will not be mixed with other coins in any direction

Ok, I believe you do have a point, while looking at that txid you pasted, it does appear we were able to pull some coins out of the internal purse (probably because your wallet was not locked etc).  But that does bring up some interesting questions.

I wrote a utility for the next version that will make it easy to analyze the GSC transmission:


Code: [Select]


10:10:28

exec auditabntx 6ca683c024cf65a0d1c69ce9d6ca198a1ee1b3a7259cecddc8becb6426fcd71f


10:10:28

{
  "Command": "auditabntx",
  "audited_weight": 0,
  "Vin # 0": "3840.55bbp - yguukBLQKCVgxKAATEQUt4eND2pKWaJzKk",
  "Vin # 1": "3840.36bbp - yguukBLQKCVgxKAATEQUt4eND2pKWaJzKk",
  "Vin # 2": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 3": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 4": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 5": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 6": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 7": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 8": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 9": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 10": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 11": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 12": "1439.27bbp - yiQfq1B9fFTsXwtLsQcvumFGdmM81SFbTf",
  "Vin # 13": "3840.17bbp - yguukBLQKCVgxKAATEQUt4eND2pKWaJzKk",
  "Vin # 14": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 15": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 16": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 17": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 18": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 19": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 20": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 21": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 22": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 23": "2.96bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 24": "22.30bbp - ycdi7xhDayyuASRFMrqiqGXyn3LmGGZ41Z",
  "Vin # 25": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 26": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 27": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 28": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 29": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 30": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 31": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 32": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 33": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 34": "22311.59bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "Vin # 35": "187231.71bbp - yP64vX6kzBz1EFHP8Urmkzdd3jJDj4QszM",
  "VOUT #0": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #1": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #2": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #3": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #4": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #5": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #6": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #7": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #8": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #9": "20532.77bbp - yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "VOUT #10": "218061.74bbp - yV7ogWWfjCLMot2mmiKckfKk67MtrVTuwY"
}




So looking at the transmission it has the following issues:

Vin # 0, 1, 13 were not taken from the CPK?  (Interesting).

Output #10 was sent back to you in the form of a new address, and it really should have gone to your CPK (to keep it recycling).


Ill look at these two issues next.


Thanks for pointing this out.


2152

i did exec associate sunk818 vccode


{
[/size]  "Command": "associate",
[/size]  "wcg_member_id": 1067915,
[/size]  "wcg_points": 146514500,
[/size]  "cpid": "c3939b61e69c6bde1eddb06708e0f96e",
[/size]  "rac": 6422.256021,
[/size]  "researcher_nickname": "sunk818",
[/size]  "Error": "ALREADY_IN_CHAIN"
[/size]}
[/size]
[/size]

Please add true to the end and it should force it in.


2153
Yes that’s the verse! Is your wife Chinese?

Yes - from Qingdao.

2154
Eventually, where does Kairos fit into this?


PoG will disappear, but healing stays...

https://wiki.biblepay.org/Economic_Changes_Dec_2019


By Jan 2020, it says the following:



   GSC Suballocations:
 
   25% for POOM-Cameroon One (this is 10% of our monthly emission for charity)
   5% for Healing
   70% for PODC

And know that this reply from me isn't driven by me making this decision; I took a look at the code, and found it would be very difficult to keep One POOM campaign, and iterate through children.  For the sake of elegance, our code currently only supports POOM vendors by requiring us to break POOM into multiple projects (which should be fine) - Im just pointing out it was more of an IT decision in this case.

So what we have to do is take a look at the 25% we have for POOMs budget and break it between cameroon-one and kairos.  I havent run the numbers yet, but it probably means carving out a split between the two, like for example, 19% to cameroon one and 6% to kairos (whatever % works the best).  Later as they expand we can vote sanctuary polls to change the percentages.  So POOM would have two campaigns:  Kairos and Cameroon-One.  With %s that add up to the grand total %.  So as soon as we deploy Kairos to prod, which will be the same date we roll out PODC 2.0 (probably Dec 15th), we would at the same time add the Kairos campaign, and adjust the total campaign %s to reflect the proper total POOM %.


2155
i'm still not sure if only coins from external purse was used, because i pasted here that i had 286k coins a day ago, now i still have 286k in cpk with 358 confirms and 10x 22311 bbp with 69 confirms

and in this tx e3b4dcc778bb7676fac56af17b2ff47c3053e2f8892093e199263ef8c9f99a9c i can see that debit/credit was 223k (10x 22311)
and i can see that outside cpk there are 3 addresses with 69 confirms (3x gsc = kairos, cameron, wcg)
if you check last credit of tx above, there is 187k to yP6... address and debits like -69k and -307k (how if i had only 286k in cpk)
it really seems that it was taken from normal address

now i have 509230 in cpk
will see tomorrow :)

Yes, external purse was used.  (Yi*).  (Also Im very confident its working that way because all GSC's in this new code branch all come from the purse, its coded that way and cant be working any other way).  This way, cameroon, kairos and wcg can be sent out silently in the night with the wallet locked, yay.  This is another test for you guys - encrypt the wallet, lock it and let it sit over night and we should see the 3 go out.

Let me give you an example of how you can see you spent it from your purse.  You typed in a txid above.  Type 'getrawtransaction txid 1'.  From the vin's, pick a random source of funds in the transaction (you used like 20 or so).  I picked the second one.  Then type 'getrawtransaction that_vin_txid 1'.  Then look and see if it was funded *to* your cpk.  It was funded to yi* its one of your exec bankrolls.  So its fine.

Next, the reason your CPK still has funds growing is because every sendgsc sends it back *to your external wallet* so yes, it always grows bigger.

Ive verified earlier today, when I type exec rac and write down the coin-age - then you send the sendgscc wcg, and then type exec rac, and look at it again you can clearly see the coin age has been deducted.  Please try that........ then you will know, please confirm .

2156
I pasted the Chinese script from a bible verse into the diary entry and it appears to work with only one malformed  character.
Yes thats interesting, because we do support the storage of unicode in BiblePay, and, QT can display the characters.

My wife said the sentence was probably missing this word : 没有   (Which I believe is NO).  That makes the entry Ephesians 5:3 right?
There should be no mention of sin, impurity of any kind or greed even mentioned among us - as we become saints?  Ill have to try to reproduce; maybe when you get a chance try to expiriment by breaking it up into two sentence etc.



2157
i think I did exec join wcg before I did exec associate sunk818 verify_code .


now, i can't seem to get my account linked.


I must have done something wrong or out of order.

That should be OK.  The primary change is now you have to be upgraded to the latest to send an associate (as the latest version is different than the one 2 versions ago); have you sent the exec associate on this latest version?


(Otherwise it will be rejected in the mempool on the *foreign* nodes).

EDIT:  please fill me in on the history of the cpid; is it new, or has it been linked , etc?


2158
BiblePay - TestNet
1.4.7.3-Leisure Upgrade


- Ensure Coin selection, tx creation and tx commit for GSC all use coins with > 0 depth

** Windows available; MIP is building the rest **

2159
1) Could you please put long pastes inside code tags - thanks.
2) The reason you see a 1457 bbp debit, is because we broke the 1457 bbp bill from your external purse, and made the debits.  The credit back is your change.
(This happens in all tx's).

3)  I agree that it looks like you had coin-age on that day, but the wallet only saw 1457 bbp available to spend.  It thought you had "8 total" in coin-age at that exact time, from looking at the transaction I can see, that for WCG, we thought you had 8 total coin age available.


So, I believe the only problem we have is finding out why you had 8 in its view (instead of 335,000).

I have a hypothesis, how many minutes earlier was your transmission before WCG?

I have a feeling we don't detect the correct coin-age for 5 confirms *after* any gsc transmission.
I say this because I sent one manually, and then my 'exec rac' was wrong for 5 blocks.

So, I think you found a nice bug we can fix!

Anyone want to confirm that is the case for one manually?  Just sent a cameroon one then look at exec rac.

Ok, dont bother confirming that, I was able to reproduce it, although its not severely easy to reproduce as it does not happen in most circumstances.

The main issue is, we were allowing coins to be spent with any confirm level in Phase II, but only gathering coins (fully mature > 5) in Phase 1, and what we ended up doing is making this LESS depth required, but equal.  So in the future version we will only require 1 confirm per coin to be in a GSC, but we will also ensure this matches with what actually gets committed in the GSC.

This next version will not require a sanctuary update, just an end user update - it will be a leisure.

So Capulo you are correct, we skipped by your WCG that day because we did not assess the age correctly, we assesed it at 8 coinage because we skiped by most of your coins.

In the new version, I think in the most complicated scenario, we will spend one coin for Cameroon and a 2nd coin for Kairos, leaving the rest with > 1 confirm for the WCG, and, we reflect this properly now in 'exec rac' also.  So I believe we fixed the bug.

We will have a leisure release in an hour.



2160
i had 286k bbp in external purse

now
07:53:53
Code: [Select]
{
  "Command": "rac",
  "cpid": "e7c056024cd3b781edd5af37965c652c",
  "CPK": "yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k",
  "wcg_teamid": 35006,
  "next_podc_gsc_transmission": 16297,
  "team_name": "Biblepay",
  "researcher_nickname": "capulo",
  "researcher_country": "SLOVAKIA",
  "total_wcg_boinc_credit": 69294160.40000001,
  "total_wcg_points": 485059122.8000001,
  "external_purse_total_coin_age": 363319.7254050925,
  "coin_age_percent_required": 0.7400380137787291,
  "coin_age_required": 265237.210701367,
  "wcg_id": 1066130,
  "rac": 14860.263202
}
so yesterday there must been about 100k coin age at wcg-gsc transmission time
but only 59bbp was taken

b88b8b5480f1ff6311c2fed1bc26052739b5aa19848f981501af0d5a00046580
Status: 167 confirmations, broadcast through 5 nodes
Date: 14. 11. 2019 11:21
Source: GSC-Transmission
Total debit: -59.27710240 tBBP
Total credit: 59.27710240 tBBP
Transaction fee: -0.03533000 tBBP
Net amount: -0.03533000 tBBP
Code: [Select]
Transaction ID: b88b8b5480f1ff6311c2fed1bc26052739b5aa19848f981501af0d5a00046580
Output index: 0
Transaction total size: 3526 bytes

Height: 16094
Difficulty: 34.61
Time: 11-14-2019 10:24:56
Subsidy: 3839.5479

Debit: -1457.48153815 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Debit: -3.27032000 tBBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 5.92771024 tBBP
To: yi74isEFVicF8wkXHrC1jaoMRWuX2tkU1k 5.0000 BBP
Credit: 1457.03486575 tBBP
To: ycPcPQ9bh45xUvMeBSHprdhvbKjTVxqTQX 1457.0000 BBP
btw why total credit debit is only 59 when there is credit/debit of 1457bbp also?

i'll see today in 3 hrs what happens...

1) Could you please put long pastes inside code tags - thanks.
2) The reason you see a 1457 bbp debit, is because we broke the 1457 bbp bill from your external purse, and made the debits.  The credit back is your change.
(This happens in all tx's).

3)  I agree that it looks like you had coin-age on that day, but the wallet only saw 1457 bbp available to spend.  It thought you had "8 total" in coin-age at that exact time, from looking at the transaction I can see, that for WCG, we thought you had 8 total coin age available.


So, I believe the only problem we have is finding out why you had 8 in its view (instead of 335,000).

I have a hypothesis, how many minutes earlier was your transmission before WCG?

I have a feeling we don't detect the correct coin-age for 5 confirms *after* any gsc transmission.
I say this because I sent one manually, and then my 'exec rac' was wrong for 5 blocks.

So, I think you found a nice bug we can fix!

Anyone want to confirm that is the case for one manually?  Just sent a cameroon one then look at exec rac.



Pages: 1 ... 137 138 139 140 141 142 143 [144] 145 146 147 148 149 150 151 ... 277