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 ... 126 127 128 129 130 131 132 [133] 134 135 136 137 138 139 140 ... 263
1981
I can help with CameroonONE and Kairos integration. Not sure how I can help. More details is appreciated. I think I got WCG registered and working now. I'll check later and report if I'm still having issues.

To help with cameroon-one and Kairos, please sponsor a few random children with:
sponsorchild cameroon-one authorize
sponsorchild kairos authorize

Then paste me the childid's and Ill send a credit in through the testnet integration, and we can verify our payment amounts.



1982
Archived Proposals / Re: Dynamic Whale Staking
« on: November 12, 2019, 04:44:23 PM »

Yes, I agree with the problem statement. Let's get more users and investors to BiblePay.


With Dynamic Whale Staking, can you explain how this scheme passes the Howey test? To me, this is an investment and there is clear expectation of profit. If you deposit 1M BBP, you will get back 150BBP in one year. Sounds like a dividend or certificate of deposit. Isn't this a risk to BiblePay leaving it open to scrutiny by the SEC?

Up to this point, I am attempting to make the DWS feature very similar to staking rewards that many wallets generate rewards from (Except as an additional feature for our POW base, instead of a base feature).   
 
   So first, by your definition, would you agree that PIVX, with a 'stake reward' of 1.5% on a balance of 1000 pivx makes pivx an SEC investment?  I dont think it fails the howey.  Because the convenant is you receive 150 pivx on a 1000 pivx stake (this is a mining reward, just like our GSC contracts are mining rewards).  Do you now also go back and say our current prod POG investments are failing the howey?  Since they offer return bbp on staked amounts of bbp?  I guess you would also think - all proof of stake coins would fail then also - correct? 

First of all, I want biblepay to remain a utility.  So we offer no expectation of profit from DWS.  This is because a DWS whale burn only gives you back more BBP.  We never promise to you that more bbp on your existing bbp equals a profit. 

Lets look at the definition of the howey test.
When Howey broke up the citrus grove into N parts, they broke the law because they sold each citrus share with the expectation that They would do the work to make it profitable (they were the 3rd party citrus growers) and therefore it was a common enterprise, with expectation of profit.

The 4 reqs of Howey:

- Must be an investment of money
- With expectation of Profit
- In a common enterprise
- With profit to be generated by the 3rd party

So we have DWS, could be argued a crypto stake is or is not money.  Ill take the conservative route and consider that BBP 'may be construed as money'.

However, we can knock out #2, by clarifying that a person is not buying a share, but making a SELF DIRECTED DECISION TO BURN BBP.  BURNING BBP RESULTS IN A LOSS, WITH NO EXPECTATION OF A FUTURE PROFIT.   Ill cover this in a minute.

Common Enterprise:  I could speculate this is not a common enterprise, as burning BBP does not mean you are receiving a special service (IE a growing groundbreaking company or farm) .  But lets veer on the conservative side and agree that someone might perceive we are so innovative that we are a common enterprise, because we offer expectation of cutting edge new releases.

Profit to be generated by 3rd party:  This means you as a whale will not be doing any work -  you are relying on us to make you a profit.  I think we can clarify here that during a burn, the user is making a self directed decision, to burn their BBP stake - and BBP should not be expected to rise in value.

In a nutshell, I propose to make the burn command issue a statement:
1) You are burning your biblepay, with no expectation of profit, and biblepay is held as a harmless utility.
2) You are not guaranteed to receive a dynamic whale stake reward in the future.
3) By typing authorize you agree that this is a self directed decision.  By typing authorize you do not expect biblepay to grow in value or perform any work to grow in value.
4) Once you type authorize, your coins will be destroyed, with no promise to receive them back in the future.

Then we make the reward side a "100% risk" that at the discretion of our wallet, we will *possibly* send you back your original BBP plus a Dynamic Whale Stake Reward.

EDIT: I propose we edit our nomenclature in the wallet, and ensure all references to rewards are  'Whale Reward Units'. 

Also we will add a disclaimer requiring authorize, that ensures this is a self directed action by the user, resulting in no expectation of profit, and no promise by us for a future profit.





1983
BiblePay
1.4.7.1-Mandatory Upgrade for TestNet

- Add Dynamic Whale Staking, added 'exec dws' and 'exec dwsquote'
- Add Kairos POOM Integration
- Modify Cameroon-One to be a generic part of POOM, and modify POOM to be more generic, modified paycameroon to become exec paysponsorship
- Added 'exec rac cpid_or_nickname'

* Windows ready, MIP is building the rest *

1984
Thanks for answers.
That question about more WCG accounts was just a curiosity.
I don't have more accounts, so I wouldn't be able even to test it. Thanks for clarification.

Yeah, PODC 1.0 was able to do it, but for the above reasons we should probably become more 'iphone' like :).


1985
And you know, on #6 in the prior post, I'm thinking its to our benefit not to support multiple CPIDs per CPK.
95% of our users are going to have one CPID and one CPK, and supporting more than one is giving them an easy way to attempt to circumvent our collateralization requirements, and adding complexity (it would mean I would not only need to iterate through CPIDs in every place, but also, where we send GSCs out for WCG, to gather the collateral requirements for each CPID) and that would be a nightmare - adding a huge amount of complexity for users who want it 'to just work' when they send their stake.

So I think I would like to take the stance:  Multiple CPIDs are not officially supported.    This keeps users from splitting CPIDs.

Im not concerned with the leaderboard, because I believe for the most part the 2nd-N CPID associated with one CPK will fail to be funded most of the time, as the collateral will not stake properly for it.


1986
Wau, I received my first wcg reward :)
So, it looks that I've made it all good :)
I have few questions :)

Thanks

Thats great Orbis!

Great questions btw.


1. Rob, what happens if my wallet will be closed during "next_podc_gsc_transmission"? Is it enough to send "sendgscc wcg" once per day?

-> So do remember, if you are unbanked (with RAC <= 250), the wallet does not need to run.  But for the banked, if you leave it off, and miss the PODC transmission, this would be a problem as you would fall out of the leaderboard for that day, and not get paid.  However, yes, you can just do the 'sendgscc wcg' once per day, and that will also keep you in (if you miss one). 

2. When the wallet is open, it's needed to have it unlocked?

->  Finally, in PODC 2.0, it does not need to be unlocked.  The funds for the GSC only come from the "Christian-Public-Key" now, which is now the external purse.  As a matter of fact, if you have 10 mil in your main wallet, and only 1000 bbp in your external purse, the GSC will fail - if you dont have enough coin age.  So we will need to ask people to fund their CPK address with enough coin-age.


3. Will setautounlockpassword and -headlesspassword works if it's needed?

->  I removed all of the places where we look at locking unlocking the wallet with the secure key.  So not anymore.  I suppose I need to remove those two commands also for sanitization/(and sanity).

4. When I send "sendgscc wcg" manually e.g. 10 blocks before "next_podc_gsc_transmission" and I forget to close wallet will the gsc tx run again?

->  Since the next_podc_gsc_transmission is at the midpoint of the contract, you can be off by up to 101 blocks in either direction, and your gsc would be "in" the leaderboard.  However if you open the wallet 1 block after the wcg height, and dont do the sendgscc, you would miss it because the wallet would not send it until the next wcg height.  We do have a key that lets you make those wallet sends more frequent; but then your coin-age would get used up faster etc - but - wcg does count cumulative coin-age, so that is a good option for some people who dont like to leave it running all the time.

5. What happens if my coinage in that second tx will be lower then expected, but in first tx it was enough?

->  This is OK.  We count the sum of the staked coin*age in the 205 block window, so, you would have enough over 2 transmissions.

6. It's possible to associate more wcg accounts into one wallet?

->  This is an interesting one.  So far, in 2.0, the rules are:  Each CPID is only counted once, and assigned to the most recent CPK->CPID association.  The exec rac command only displays data for One CPID (the first one it finds linked to your CPK).  However, there is no rule blocking you from associating your CPK with more than one CPID; however - its not been tested and Im not entirely sure if both CPIDs will be paid in the leaderboard.  This would be a good thing to test; if someone wants to raise up two cpids; then link two distinct CPIDs to one CPK, then wait and see what happens on our leaderboard.  If it works properly, I can potentially add code to allow iterating through them in 'exec rac'.  However note that exec rac does allow you type a cpid now (in the next version) and manually pull up the second rac, it just does not allow iteration automatically yet. <-- Either way this will be a good exercise to ensure there is no unintended behavior on the payment side so lets please test it.






1987
I can help with CameroonONE and Kairos integration. Not sure how I can help. More details is appreciated. I think I got WCG registered and working now. I'll check later and report if I'm still having issues.

Yes, I will start giving many more details once the next release is checked in (in about an hour or so).
For now, you can definitely join cameroon with 'exec join cameroon-one', but please wait on kairos as the sporks are not finished.


1988
** DWS update (Dynamic Whale Staking) **

So I've been programming DWS in testnet and it is ready for a release.  (I realize we havent released the thread to discuss it and or vote on it yet, so know that as we test this, there is no intention at all to release this to prod - it will just stay in testnet indefinitely until we add a proposal to vote it in.  I will move the existing discussion thread to a proposal over the next few days anyway and we can vote on it.)

However note that DWS is going to require a mandatory in testnet!  So please be aware that we will have a mandatory upgrade for this.

Another thing going on is Kairos Childrens Fund is making very fast progress with POOM on their end, and I just heard from Andy this morning that he will be calling me to train him with integration reqs.  This means I need to merge code into testnet for Kairos also.  So be aware we have a lot going into testnet.  We will be pulling individual pieces out when we move to prod (IE the Kairos piece and the PODC 2.0 piece) for the next MainNet release.


1989
I also noticed that every time the wallet is stopped and then restarted, `exec rac` initially shows that the external purse is empty and I would have to reassociate again before the external purse coins are recognized in `exec rac`. Is this intended behaviour?

No thats not intended at all, and you should only have to associate once forever, haha.
Interesting, well I cant reproduce that, I just did exec rac, and rebooted and exec rac - and Ive only associated once over the last 10 boots, thats not supposed to happen.

Are you sure you did not move the machine and delete the SAN directory?  Or the wallet.dat?  Because the SAN contains the association record, and once deleted, it will only regenerate during the next start (when prayers are re-synced) - but - without a reassociation it does regenerate. 
Also if you move wallet.dat, your external purse is not lost, but it is no longer linked.  It would take a new associate or an 'exec createpurse' to re-link it.  And that would also cause a temporary break in the CPK (wallet would recreate a new CPK, a different one, requiring a new associate).




1990
Following your advice, I am using the QT version but it is painfully slow on my weak VPS (that's why I use command line text only). However, it is much easier to see what I think is the transaction (debit and credit is 108,344 tBBP and I can see all the individual coins that add up to this in one transaction). And I also get to see Gen 25:13-19.  is there any way to read the Bible from the command line (ie biblepayd)?

the createabn coinage gives a long list of coins as expected.

What is the frequency of the automatic `sendgscc wcg` command? I know the purse does not need to be unlocked but does the wallet need to be mining for the `sendgscc wcg` transaction to occur or does the purse stake when the wallet is on but not mining? What about when the wallet is offline?


1) On reading the bible from the command line, please see the rpc commands: 'books' (This list the books of the bible), 'bookname' this is just a cross reference command to get the long bookname from the BiblePay abbreviated bookname, and the main command: exec readverse.

2) Please see my last post to Sun, its once per day at the midpoint of the GSC contract now, and wallet can be locked - Yay.

3) Yes thats depressing on the speed.  Ive been using my old $1 per month hostbrz.com nodes for testnet (the ones Sun suggested a year ago) and QT is running very fast in there.  The only other option I can recommend, is running QT side by side one of your prod nodes.  Because, testnet actually does not interfere with prod (it has its own subdirectory and ports).  If you get any errors I can help you get by them.  Yeah, or you can go back to the command line once you feel comfortable, but, I still recommend we test cameroon one and some other things (DWS) in QT if possible, as it might reveal some behavior thats hard to debug on a small window.  (IE leaderboard outputs etc).


1991
will gen=1 still be required in the biblepay.conf to submit these wcg, pog, healing, occasionally? with the external miner, I wonder if gen=0 will be okay now...

No, this is one improvement in PODC 2.0. 
Now we moved the sendgscc process over to the main thread.
So now the miner can be off.
We also changed the architecture to use a single target block per day (this is primarily to make it more efficient on coin-age usage.  Another words, if a person only has just enough, we arent trying to stake every 12 hours, etc).
To see that block # type exec rac, and look for the wcg gsc transmission height.
(Actually an easy way to remember that height is we made it at the mid-point of each gsc contract, so its 102 blocks after the last gsc payment height).

At that height, once per day, we send all the gsc transmissions - one at a time.

I've tested cameroon-one a little but we could use your help testing it more thoroughly in testnet.  Please see the 2nd post after the op post.  I have a test cameroon environment up and I can enter debits and credits for cameroon in testnet if you give me the childid and payment amount.




1992
Current block 15553 and 50 confirmations ago at 155503, I see 10 entries with the following condition ("GSC-Stake-Transmission": true,)

>listtransactions "" 100 | grep "GSC-Stake-Transmission" -A10 -B12 | grep 50, -A13 -B11

I see 10 almost identical (as far as I can tell) transactions....
I thought it looks like it is sending 10 coins of 8570 BBP as stake...  but I cannot see the corresponding consolidated amount returning. However, I do not what the expected behaviour is supposed to be in the external purse nor do I know the coin composition of the external purse....

Code: [Select]
{
    "account": "",
    "address": "yejTJcE9cSHMfC6H3ncbURt9MWPYc2kWPv",
    "category": "send",
    "amount": -8570.75104474,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 3,
    "fee": -0.05017000,
    "confirmations": 50,
    "instantlock": false,
    "instantlock_internal": false,
    "chainlock": false,
    "GSC-Stake-Transmission": true,
    "blockhash": "91eb12db434addf9cb0618ffc998b5e539c7c5a169d1b918310eafe194eb7ab7",
    "blockindex": 1,
    "blocktime": 1573474173,
    "txid": "baa77a343dd9f4bfa1348a3ebea6e1c6c54afb8722cf069a8ccdaba572f6ff6f",
    "walletconflicts": [
    ],
    "time": 1573473791,
    "timereceived": 1573473791,
    "abandoned": false
  },
  {
    "account": "",
    "address": "yejTJcE9cSHMfC6H3ncbURt9MWPYc2kWPv",
    "category": "send",
    "amount": -8570.75104474,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 2,
    "fee": -0.05017000,
    "confirmations": 50,
    "instantlock": false,
    "instantlock_internal": false,
    "chainlock": false,
    "GSC-Stake-Transmission": true,
    "blockhash": "91eb12db434addf9cb0618ffc998b5e539c7c5a169d1b918310eafe194eb7ab7",
    "blockindex": 1,
    "blocktime": 1573474173,
    "txid": "baa77a343dd9f4bfa1348a3ebea6e1c6c54afb8722cf069a8ccdaba572f6ff6f",
    "walletconflicts": [
    ],
    "time": 1573473791,
    "timereceived": 1573473791,
    "abandoned": false
  },
  {
    "account": "",
    "address": "yejTJcE9cSHMfC6H3ncbURt9MWPYc2kWPv",
    "category": "send",
    "amount": -8570.75104474,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 1,
    "fee": -0.05017000,
    "confirmations": 50,
    "instantlock": false,
    "instantlock_internal": false,
    "chainlock": false,
    "GSC-Stake-Transmission": true,
    "blockhash": "91eb12db434addf9cb0618ffc998b5e539c7c5a169d1b918310eafe194eb7ab7",
    "blockindex": 1,
    "blocktime": 1573474173,
    "txid": "baa77a343dd9f4bfa1348a3ebea6e1c6c54afb8722cf069a8ccdaba572f6ff6f",
    "walletconflicts": [
    ],
    "time": 1573473791,
    "timereceived": 1573473791,
    "abandoned": false
  },
(only pasted 3 consecutive transactions)

Those are all the same transaction, which is normal.  (See the txid, with multiple vouts).
When the wallet makes a GSC transmission, it uses up as much coin age as necessary to compose the transaction.

If you type 'exec rac' you can see the percent of coin*age required to fill with many inputs.

Is it possible to test in QT until we are stable in testnet?  As QT is a lot easier to see the single transmission.

If you want you can simulate this by getting the coin*age required from exec rac, then type 'exec createabn N 1' where N is the amount of coin*age, and you can see the individual inputs required for that amount of age.


1993

when I typed exec rac in debug console, it says to use wcg . I'll look for wiki docs, I guess?





09:01:41

exec rac




09:01:41

{
  "Command": "rac",
  "Error": "Sorry, you do not have a CPK.  First please create your CPK by typing 'exec cpk your_nickname'.  This adds your CPK to the chain.  Please wait 3 or more blocks after adding your CPK before you move on to the next step. ",
  "Step 1": "Log into your WCG account at 'worldcommunitygrid.org' with your WCG E-mail address and WCG password.",
  "Step 2": "Click Settings | My Profile.  Record your 'Username' and 'Verification Code' and your 'CPID' (Cross-Project-ID).",
  "Step 3": "From our RPC console, type, exec associate wcg your_username your_verification_code",
  "Step 4": "Wait for 5 blocks to pass.  Then type 'exec rac' again, and see if you are linked!  ",
  "Step 5": "Once you are linked you will receive daily rewards.  Please read about our minimum stake requirements per RAC here: wiki.biblepay.org/PODC"
}

Oh, sorry about that, I see we only fixed it in one place!

Fixed for the next version.

Please type:  exec associate your_username your_verification_code


1994
Code: [Select]
I have 20 x GSC transmissions at 15375 (62 confirmations ago) similar to the one below.

Wait, other than the original flakiness (which I believe is permanently fixed), did you say you had 20* 'sendgscc' transmissions at the height?
(Or do you mean, you had 20 in total).  I just want to make sure our wallet did not send your 'sendgscc wcg' transmission 20 times at the height automatically, it didnt do that right?

Looking at my last night submission, I see 1 for WCG and 1 for Cameroon at the height and looking at the code, we should only be trying once during the block passing?



1995
20:12:23 exec associate wcg sunk818 verification_code
20:12:24 Unable to find wcg.  Please type exec rac to see helpful hints to proceed.  (code -1)

Please see the help docs for the exec associate:  Please remove the word 'wcg' before sunk818.


Pages: 1 ... 126 127 128 129 130 131 132 [133] 134 135 136 137 138 139 140 ... 263