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 ... 127 128 129 130 131 132 133 [134] 135 136 137 138 139 140 141 ... 262
1996
Archived Proposals / Dynamic Whale Staking
« on: November 08, 2019, 05:36:06 PM »
This is a concept to be considered:  Dynamic Whale Staking.

The problem statement:  We need more users and more investors to make biblepay more popular. 

Solution:  Make a feature in BBP that allows 'latent BBP' to be 'staked' for a whale-unit reward.  Part of the goal is to make this as easy as possible; no complicated smart contracts, no daily wallet unlocks, no leaderboard, just simply buy the BBP on the exchange, load the wallet and run the command that burns the coins.


________________________________________________________
PROPOSED CHANGES TO EMISSION SCHEDULE WIKI:
https://wiki.biblepay.org/Emission_Schedule_2020
** NOTE:  THERE ARE NO NET CHANGES TO THE EMISSION TOTAL AMOUNT OR TOTAL MONEY SUPPLY,
however, the changes included here are:  A) We allow room for DWS rewards - starting in 2020 - by increasing our deflation percent from 19.5 to 20.04%, and allocating an additional maximum of 10% (of our gross monthly block reward) towards DWS rewards (This does *not* decrease the gross block reward, the sanctuary reward, or the POBH reward or the GSC contract amount).  If the DWS rewards are not used, because the DWS stake is never burned, then the BBP is never actually spent from our emissions.  (In this case the actual total money supply in BBP would be less than 5.1 B at the end of the schedule depending on how much is never spent).
________________________________________________________

Why would someone want this:  A person who is seeking cryptocurrency exposure will be looking at coins to invest in with certain characteristics.  I feel our coin has a bright future because:  Its a feel good investment (we do tithe 10% to orphan charity, so the utility of our organization works for you), we are deflationary in emissions per year, we are a HODLing community with governance meaning we have a high % locked up in sancs, and finally - the investor will be comparing ways to get more coin-unit rewards through proof-of-work or mining etc. 

Our original money supply covenant:  We will need to ensure we don't break our covenant.  This would be accomplished by allocating a percent of our emitted coins per year toward this project - in a certain band of years, IE 2020 through 2030, and increasing our deflation rate to pay for the feature.  So we would have no net changes in our total supply, but we would modify our coin emission chart to include this feature over 10 years.  In laymans terms this means we would emit 10% more total coins for 10 years, but we would increase our deflation % per year to cover the change.

Emission Changes:  In this proposal we allocate 10% more than our current annual emission rate (which is currently 612MM per year), therefore we would spend up to 5,083,333 per month on 'dynamic whale staking' deflating at our standard deflation rate (of 19.5%).  However note, this is the absolute maximum, if the product is 100% allocated.  If the feature is not used, these coins would not be emitted for whale staking.   We will also decide how much we need to increase our deflation %.


Full Safeguards:  The DWS money supply ratio would be hardcoded in the wallet for full safeguards, to ensure the wallet cannot emit more than the designated existing total plus the DWS for that month.  So, if we currently emit 50MM in a given month, the wallet would not allow more than 55MM to be emitted in a given month, due to the hard rules.  Additionally, the recipients of each DWS would need to be approved by all the sancs (the sancs who create the daily superblock would evaluate every DWS record and add it to the superblock).  So there will be no chance of a miner adding a DWS that is unauthorized. 

The core wallet will be generating the coins for the investor from the coinbase, so solvency is guaranteed.  BBP cannot go bankrupt from DWS.

Provably identifiable DWS burns:  Since DWS uses a provable burn record, it will not be possible to fake a burn, and it will be provably demonstratable that the burn address does not have a corresponding private key.  Rob will attach the mathematical proof to this proposal that shows how to create a certifiably provable burn address for Biblepay with no corresponding private key.   

-=-=-=-=-=-=-=-=-=

EDIT:  I am attaching the source code that facilitates the generation of a non-spendable-bbp address for both testnet and Prod, based on the first public key derived from an unusable private key of {0x0} (See attached file: DynamicWhaleStaking.cs).

This code creates a BBP keypair using a blank private blank key - ie hexcode {0x0} - that is a provably unspendable private key. This routine generates this public address :  B4T5ciTCkWauSqVAcVKy88ofjcSasUkSYU (This is the first public address from the 0x0 private address that is a valid spending address).  So if you send BBP to this address it will be lost forever.

=-=-=-=-=-=

Mechnical operation:

We will allow a DWS duration of between 7 and 365 days.

The dynamic-whale-reward will be quoted on the screen in 'test' mode - and will match on every biblepay client until the quote is consumed.
It will be updated block to block.

To protect the system from hogs, we will use two moving averages, annual saturation and monthly saturation.
The monthly saturation will primarily drive the quoted dynamic-whale-reward.

Full example of a DWS whale stake in action:

getdwsquote
Amount staked: 1,000,000
Dynamic-whale-unit reward: 15
This means the user would potentially receive 150,000 bbp in reward one year after the coins are burned, if bbp returns them (they are 100% at risk, and we will explain this by posting a risk notice).

(Allowed stakes can be between 100 and 1,000,000 bbp):
dws 1000000 receive_address 365 authorize true
In this case, the whales stake will be sent to the burn address;
365 days later, the whale will receive the original 1mil back, plus 150,000 in additional coins.

The reward algorithm should stabilize at a point where the stake-reward emissions average out to be the allocated projection.

Note:  The shorter term rewards are penalized by 50% divided by the span. 
So a DWU reward of 100 will only be 50 if the duration is 1 month.

75 for 6 months.  100 for 12 months.

  This will encourage DWS whales to lock the coins for longer durations, and free up more of the DWS rewards for more distinct users (because those who choose short spans will receive less rewards).  This will be accomplished by storing the duration on the burn itself, so the actual DWU reward
 will be calculatable off of the base.

Example:
Current DWU-reward level is 50 for 365 days.
DWU-reward is  37.5 for 6 months.
DWU-reward is 25 for 1 month.

User A types  : exec dws 10,000 365.  They will receive receive 10,000 + 5,000 after 365 days.

User B types  : exec dws 10,000 180.  They will receive will receive 10,000 + 1,875 in 180 days.


Target Algorithm version 1.1:

"Two saturation levels are monitored.  The Annual saturation level is comprised of the total outstanding (owed and unpaid) DWS stakes over the next 365 days.

The Monthly saturation level is comprised of the total outstanding owed over the next 30 days."


Annual and Monthly Saturation Equation:
SE_Percent = Total_Outstanding_Coins_Owed / Maximum_DWS_Reward_Amount_For_The_Period


1.  If Annual Saturation is > 95%, drop DWU reward level to zero (for quotes).
2. If Annual Saturation <= 95%, offer the inverse of the monthly saturation level as a DWU reward.

Inverse of monthly saturation level:

IA = 1.0 - Monthly_Saturation_Level

ROI quote = IA * MAX_DWS_DWU

Example:

1.  Annual saturation level is at 25%.  Monthly Saturation is at 50%.  Since IA equals 50% (for 365 days), the quote would be .50 * MAX_DWS_ROI = 100 DWU.

2.  Annual saturation level is at 25%.  Monthly Saturation is at 90%.  Since IA equals 10% (for 365 days), the quote would be .10 * MAX_DWS_ROI =  10 DWU.

3.  Annual saturation level is at 96%.  Quote = 0 DWU.

4.  Annual saturation level is at 94%.  Monthly Saturation is at 1%.  Quote = .99 * MAX_DWS = 198 DWU.

5.  Annual saturation level is at 50%.  Monthly Saturation is at 99%.  Quote = .01 * MAX_DWS = 2 DWU.

Risk Rules:  (Rules to mitigate risk):

Each burn will be audited in the memory pool before accepted (meaning a burn can be turned down by all the nodes, if for example the burn is created fraudulently, or, if the burn will result in an overage condition for BBP).
Rule 1:  Each node will check the components of the burn, to ensure they match the quote available, the duration available, and the availability of the DWS ROI.   Check the bounds for each component also.  (Otherwise if any of this fails, reject the burn).
Rule 2:  No more than 5 mil in gross stakes per day.  This will limit our exposure for GSC contracts to never pay more than 5 mil back to whales in a given day.
Rule 3:  If the Annual Saturation level > 95%, reject the DWS.
Rule 4:  Each node will re-assess the 'total whale metrics' as each transaction occurs.

Burns rejected by the memory pool will automatically refund the funds back to the sender (actually, the transaction will be rejected, the same way a conflict or a double spend is handled).

Howey-test protection, to ensure biblepay stays a utility:

We will add a warning to the DWS burn method:

Your coins are 100% at risk if burned.  This is a self directed action by you.  Type authorize to acknowledge that burning the coins results in a potential entire loss with no future expectation of profit, and biblepay will be held as a harmless utility for this self directed action.  We do not promise you an increase in value for any
 of your coins!  We do not promise to pay you back for any burned coins, and coins are 100% at risk. 




1997

03:14:11

exec associate capulo nnn


03:14:12

Sorry, we found you as a researcher in WCG, but we were unable to locate you on the team.  Please join team BiblePay or team Gridcoin to proceed.  Please type 'exec rac' to see more helpful hints.  NOTE:  You may check back again once every 12 hours to see if you are on the team.  (code -1)


but i'm in biblepay team.. so? :)

I don't actually see your 'exec associate' in the chain; I assume it was the issue we had (where the wallet was not signing the tx).  Please try the exec associate again with the force true at the end?


1998
BiblePay
1.4.6.9 - Mandatory Upgrade for TestNet


- Fix key signing issue


1999
Hey All-

I see we have a very squirrely issue, its almost as if Im the only wallet that is miraculously working.

Ive been moving the wallet file to different servers and seeing a different result, so Ive come to the conclusion that we need a bug fixed.

Please stop testing until I can trace this root problem.

Thanks!



2000
I’ll wait as compiling failed....

In file included from bls/bls.cpp:5:0:
bls/bls.h:14:10: fatal error: chiabls/bls.hpp: No such file or directory
 #include <chiabls/bls.hpp>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:9965: recipe for target 'bls/libbiblepayconsensus_la-bls.lo' failed
make[1]: *** [bls/libbiblepayconsensus_la-bls.lo] Error 1
make[1]: Leaving directory '/home/bbp/biblepay-evolution/src'
Makefile:11637: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

To get by that, you have to follow the compile instructions in the area that says "cd biblepay-evolution/depends", "make...":
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt


2001
yWurZhEW51tyVGqgxMtYLmBFNHvAPcyeRu
this is my address, pls send me some coins

Sent!


2002
coool, now i have 5 connection and i'm on block 14807
seems we found rootcase :D

Oh wow, so basically let me try to guess:

You connected early on in the game with the wallet defaults, and the wallet started mining at the genesis block.
It added 10 blocks or so very easily.
Then when you got a connection to the dns nodes, they banned you because you were trying to pass on invalid headers (this is a dash rule that gives you a very huge penalty for doing that).

So you probably then switched back to gen=0 but it was too late.
We will have to remember this for the future, as in testnet its easy to solve blocks because of that not-requiring-peers rule.

That reminds me, in prod, btw, you are not allowed to mine without peers, so this all makes sense now!


2003
Linux command line
cli -version
BiblePay Core RPC client version 1.4.6.7

binaries from
https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz

Ok, I make the assumption you are also affected by the problem I pasted for Togo, so if you want to work quickly please self-compile and then retry your sanctuary revive or spend;  or alternatively please wait for 1.4.6.8.


I will work on this now for new release.


2004
Sorry, I can’t revive my sanc Nor can I spend the transaction....

cli protx update_service 3a24f0ffe9b074abd5774d1c4e0627fc39a8a029f475f629cbcd52350e1455d0 45.62.239.200:40001 579fcbc90face5e28d5312a0e0df87606f67adf62d71305701c551133d75c9d9
error code: -32603
error message:
No funds at specified address (special transaction error)

ok - I choose an address with funds
 "ye9fvYw4vgHmSrVT8cd8wVLNmSBLZh7ikV": 9.93668000,

cli protx update_service 3a24f0ffe9b074abd5774d1c4e0627fc39a8a029f475f629cbcd52350e1455d0 45.62.239.200:40001 579fcbc90face5e28d5312a0e0df87606f67adf62d71305701c551133d75c9d9 ye9fvYw4vgHmSrVT8cd8wVLNmSBLZh7ikV
error code: -32603
error message:
Signing transaction failed

cli walletpassphrase
error code: -15
error message:
Error: running with an unencrypted wallet, but walletpassphrase was called.

Could you confirm what platform version this is, is this a linux qt build?  Or windows?

Self compiled or a binary?


2005
For sure, sent you message on this forum and bitcointalk forum a little bit ago

Ok, so it looks like (I make the assumption) that all the builds are bad for 1.4.6.7 except the two windows builds.

So, let me look into releasing the thing that hung up Orbis next and incrementing to 1.4.6.8.  And we will have a rebuild.

In the mean time if you have time, you can try the windows version with your wallet.dat that you have now, and see if it succeeds?

EDIT: Actually what might be better is just build the latest from source (git pull origin develop).
Then you will know you have the latest.



2006
I performed a zapwallettxes

yQHcgNP61KhRBuSsE4SUL1iZ6DAZZ8Ab63
has 165 confirmations and 7,000,000 tBBP
I believe these are the coins you sent me yesterday

ygQv5C6vncjW9xZUC7cGkrFysswG1raMFA
has 11 confirmations and 1,000 tBBP
I'm not sure where this came from

I cant dumpprivkey for either address
"Private key for address X is not known"

Yeah, could you send them?  I guess we need to see what is really going on here!

Thanks.


2007
Linux 64 bit QT, I got a signing transaction failed message,
I did an erasechain and a rescan

Im still getting signing transaction failed,
I tested with two different inputs by themselves sending to another address

getinfo shows version: 1040607

Debug log just shows:  "Unable to calculate fee, singing failed for"

Where did you get the source funds?

And is it possible for you to dump the private key for the source address?

I recommend zapping the wallet txes and using the foundation funds only (IE funds from one of us) for this test.


2008
I noticed for the Linux 64 bits QT link it says:
https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz

But I think it should be:
https://biblepay.org/biblepay-qt-evo-testnet-x86_64-pc-linux-gnu.tar.gz

I replaced i686 with x86_64 and it worked, running QT version now!

===

Here are my old notes on using GUI on Vultr server

1. Install Lubuntu GUI and Reboot
https://www.vultr.com/docs/install-gui-environment-for-ubuntu

Code: [Select]
apt-get update
apt-get install -y lubuntu-core
reboot

2. On Vultr Server Information page click "View Console" button in top right

3. Press Ctrl - Alt + T to open a Terminal

===

Ill setup a sanctuary now

I like the notes about QT;  Ill look into changing this link next.

So on a side note, we could probably use an addl sanctuary since so many have been pose banned, and, in addition we can do some chainlocks testing toward the end of November- and we def could use healthy sancs for that (IE more than 4).  Right now we have 4 healthy and 2 unhealthy.


EDIT: Link fixed, thanks.


2009
I don't think we need a new release yet, because so far we just have the change for the one word - IE ask everyone to perform 'exec associate' instead of exec join, please let me look into this.

No wonder you are having so many issues Orbis, you are on the wrong chain, please resync with "-erasechain=1" then verify this hash:

14:57:54

getblockhash 14700


14:57:54

92c8c16680413fb1f36bd8c9b389c5ad87cbf14f377a7936509656e714c11ea0



Then, start over with the 'exec cpk your_nickname' then the 'exec associate wcg_username wcg_verification_code' command, and see if that is successful?

I will not be able to track the 5K you refer to until you are on the same chain as me.  If it happens again please re-paste.





2010
Here are my results :)
Code: [Select]
17:17:50  exec unjoin wcg
17:17:52
{
  "Command": "unjoin",
  "Results": true
}
So, it looks good.
Then, after 2 blocks, my first try:
Code: [Select]
17:22:47  exec associate orbis XXXXX true
17:22:47
Unable to find orbis.  Please type exec rac to see helpful hints to proceed.  (code -1)
So, I wasn't successful.
After 6+ blocks:
Code: [Select]
18:26:00 exec associate orbis XXXXX true
18:26:00
Sorry, we found you as a researcher in WCG, but we were unable to locate you on the team.  Please join team BiblePay or team Gridcoin to proceed.  Please type 'exec rac' to see more helpful hints.  NOTE:  You may check back again once every 12 hours to see if you are on the team.  (code -1)
Still unsuccessful :(
It looks, that I'll wait for new wallet version.
BTW: after "exec unjoin" there were -5000tBBP tx again: 875df26d46d3667f1443a5f3e13aedddad0a0142687faf28c893047e42ad6986
So, it looks, that "join" and "unjoin" tx are "paid".

I don't think we need a new release yet, because so far we just have the change for the one word - IE ask everyone to perform 'exec associate' instead of exec join, please let me look into this.


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