BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[bible_pay]

Do I need to unlock my Sanctuary wallet to start the POW mining before run "exec associate rosetta_email_address rosetta_password true"? Is it safe to keep the wallet unlocked in the Sanctuary server while mining? Or it is better to turn off the mining in sanctury server?

1) You should only run the exec associate command once, not each time you mine.
2) Sanctuaries usually dont have the funds in them anyways, but you need 51K per day UTXO in order for the PODC update to work, so you could either send the 51K there to the sanc, or leave it in the controller wallet and mine from the controller wallet.
3) The feature to unlock the wallet during cpid signing should be ready tonight, but till then you have to do the 'walletpassphrase pass 99999999' to mine from the headless sanc.

[bible_pay]

bible_pay but this is bad when you added laterz that 50 000 bbp ... you have to start your voting at begin  .. thanks for it

I left all current votes and allowed votes to be changed, so anyone can still change their vote.

[bible_pay]

Hi, I am not sure if I have the same problem but I have not received today payment for Rosetta. I received payment for last two days (Friday and Saturday) without any issues. I did not change anything in configuration.
I am using 1.1.1.0 wallet. This is what I get from exec getboincinfo. Is there something I do incorrectly? Thanks for you help.


17:44:11

exec getboincinfo


17:44:13

{

Code:

  "Command": "getboincinfo",
  "CPID": "a9420a038e44750c69ca4497fe08c2a9",
  "Address": "BKDezDVAwB8vYvaEWcgxLpuuYqbSaDqmVp",
  "CPIDS": "a9420a038e44750c69ca4497fe08c2a9;",
  "CPID-Age (hours)": 422440,
  "NextSuperblockHeight": 34235,
  "NextSuperblockBudget": 2660579,
  "a9420a038e44750c69ca4497fe08c2a9_ADDRESS": "BKDezDVAwB8vYvaEWcgxLpuuYqbSaDqmVp",
  "a9420a038e44750c69ca4497fe08c2a9_RAC": 3761.99,
  "a9420a038e44750c69ca4497fe08c2a9_TEAM": 15044,
  "a9420a038e44750c69ca4497fe08c2a9_TaskWeight": 100,
  "a9420a038e44750c69ca4497fe08c2a9_UTXOWeight": 50001,
  "Total_RAC": 3761.99,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 11895,
  "Total Budget (One Day)": 2660579,
  "Total Budget (One Week)": 7981737,
  "Superblock Count (One Week)": 3,
  "Superblock Hit Count (One Week)": 3,
  "Superblock List": "34030,33825,33620",
  "Last Superblock Height": 34030,
  "Last Superblock Budget": 2660579,
  "Last Superblock Payment": 0,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 1.490277116372038

}

I just ran the next contract on my sanc and you seem to be in the next upcoming contract:
BKDezDVAwB8vYvaEWcgxLpuuYqbSaDqmVp,a9420a038e44750c69ca4497fe08c2a9,3.254,1984116,15044,50001,100,976594,0,100.00,3178,3178


Your mag will be about 3.25


Btw anyone pasting long rows of snippets please surround them with [ code ] and  [ / code ] to keep the board clean, thanks.

[aikida3k]

lasencja exchanges is stopped and we got botnet,whales and different idiots like this https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  dumping prices


VOTING FOR BAN/KICK this user https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  thats insane, i remember Robs first words,that BBP will be for poor ppl in Venezuela,Africa etc 6-7 months ago.. loooool


who is for? for me yes ...



AND WE NEED NO LINEAR MAG,UTXO system but EXPONENCIAL

example:

MAG1= 1000 BBP
MAG2= 2000 BBP
MAG3= 5000 BBP
MAG4= 9000 BBP
etc

Please vote:
http://forum.biblepay.org/index.php?topic=127.0


The problem with exponential increases is it persuades users to split the CPID into multiple CPIDs.
Its still a cat & mouse game if we do that.

I think the #1 line of defense is vote as high as possible for UTXO per magnitude first.

The first thing the user would do is split CPIDs if we had a rule that said: Require double the UTXO if Mag > 100, then they would create two cpids....  Im not a fan of squirrely program logic that we will have trouble supporting- and be frowned upon by the peer review panel for questionable logic.

I think the issue with staking via RAC is imagine a year from now when we have 49M RAC on Team Biblepay.  Yes, the circulation will have grown substantially by then, but the daily rewards will be about 80% of what they are now.  So today, 70K RAC is 63 Mag granting 90K coins a day (roughly under the corrected distribution), whereas in the above it is 1.5 Mag granting (roughly) 1800 coins a day.  Having to stake 10 BBP/RAC would be 700K BBP which today is probably reasonable, but a year from now, quite the impediment to the low power crowd.

In the end I see the stake/Mag being optimal, I would even say it should be higher to level the playing field which is I think the goal as much as anti-bots and coin stability.

I like another idea.  I like the idea of decreasing the amount of stake per RAC with the lower distribution.  A nice benefit of staking based on RAC is that the amount staked based on RAC will keep growing instead of being static at say 10 million.  The benefit of a growing stake is that it would bring in a new element to the coin - traders, people not necessarily looking to crunch or mine and instead hold for appreciation.  A drawback of the coin now is that it is full of miners and crunchers-- miners and crunchers are natural sellers.  They have expenses to cover.  This coin needs a way to bring in buyers, people who just want to own the coin without having to crunch or mine.  Staking based on RAC would help to do that because traders could come in to "front run" the growth in the network.  So then buying and holding BBP becomes a bet that the network will grow and the coin will appreciate based on an increasing amount staked.  Staking based on RAC gives the more value:  you need to get BBP in order to increase the number of computers you are using to crunch.  With staking based on MAG, the amount required to stake per user will shrink as the network grows even though the amount staked will stay static at say 10 million.  Staking per MAG doesn't give us a consistent supply sponge- just a 10M lockup- a fraction of the amount that the sanctuaries lock up, whereas staking per RAC will sop up supply and drive price higher.  

[Bitconee]

Thanks for clearing it up.

Can you clarify this for me? I am mining last 2 days and this is the results I get. I am staking 3500 BBP and have my RAC seen over last 3 blocks but 0 magnitude and 0 payouts...

 "Command": "getboincinfo",
  "CPID": "328ae544f566cd3ec2191b0e825b38c3",
  "Address": "ADRESS",
  "CPIDS": "328ae544f566cd3ec2191b0e825b38c3;",
  "CPID-Age (hours)": 422439,
  "NextSuperblockHeight": 34235,
  "NextSuperblockBudget": 2660579,
  "328ae544f566cd3ec2191b0e825b38c3_ADDRESS": "ADRESS",
  "328ae544f566cd3ec2191b0e825b38c3_RAC": 387.43,
  "328ae544f566cd3ec2191b0e825b38c3_TEAM": 15044,
  "328ae544f566cd3ec2191b0e825b38c3_TaskWeight": 100,
  "328ae544f566cd3ec2191b0e825b38c3_UTXOWeight": 3650,
  "Total_RAC": 387.43,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 2660579,
  "Total Budget (One Week)": 7981737,
  "Superblock Count (One Week)": 3,
  "Superblock Hit Count (One Week)": 3,
  "Superblock List": "34030,33825,33620",
  "Last Superblock Height": 34030,
  "Last Superblock Budget": 2660579,
  "Last Superblock Payment": 0,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

I think you are on the network now but the current contract doesn't have you in there yet.

cat magnitude | grep 328a
<ROW>BRYo1mSUS9NB79RokuDF3N1NbFWdUvTBMK,328ae544f566cd3ec2191b0e825b38c3,0.201,1987605,15044,3650,100,977248,0,100.00,197,197

So atleast you see it somewhere, that's good. How did you find it? And will my CPID get into the contract automatically over time or?

Run:
exec dcc
go into ~/.biblepaycpre/SAN
cat magnitude | grep 328a

I think a contract is created for every super-block but I'm not sure if new CPIDs get inserted into the current contract.

So it is not certain I will recieve any of the mining rewards? This is so confusing.. I am mining for 2 days and I am not even certain I will mine anything. Can anyone check this info to be sure? I think a lot of new people will be wondering the same thing..

[slovakia]

lightsucker thanks that you used my screens of my wallet iny your tutorial

[tmike]

Thanks for clearing it up.

Can you clarify this for me? I am mining last 2 days and this is the results I get. I am staking 3500 BBP and have my RAC seen over last 3 blocks but 0 magnitude and 0 payouts...

 "Command": "getboincinfo",
  "CPID": "328ae544f566cd3ec2191b0e825b38c3",
  "Address": "ADRESS",
  "CPIDS": "328ae544f566cd3ec2191b0e825b38c3;",
  "CPID-Age (hours)": 422439,
  "NextSuperblockHeight": 34235,
  "NextSuperblockBudget": 2660579,
  "328ae544f566cd3ec2191b0e825b38c3_ADDRESS": "ADRESS",
  "328ae544f566cd3ec2191b0e825b38c3_RAC": 387.43,
  "328ae544f566cd3ec2191b0e825b38c3_TEAM": 15044,
  "328ae544f566cd3ec2191b0e825b38c3_TaskWeight": 100,
  "328ae544f566cd3ec2191b0e825b38c3_UTXOWeight": 3650,
  "Total_RAC": 387.43,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 2660579,
  "Total Budget (One Week)": 7981737,
  "Superblock Count (One Week)": 3,
  "Superblock Hit Count (One Week)": 3,
  "Superblock List": "34030,33825,33620",
  "Last Superblock Height": 34030,
  "Last Superblock Budget": 2660579,
  "Last Superblock Payment": 0,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

I think you are on the network now but the current contract doesn't have you in there yet.

cat magnitude | grep 328a
<ROW>BRYo1mSUS9NB79RokuDF3N1NbFWdUvTBMK,328ae544f566cd3ec2191b0e825b38c3,0.201,1987605,15044,3650,100,977248,0,100.00,197,197

So atleast you see it somewhere, that's good. How did you find it? And will my CPID get into the contract automatically over time or?

Run:
exec dcc
go into ~/.biblepaycpre/SAN
cat magnitude | grep 328a

I think a contract is created for every super-block but I'm not sure if new CPIDs get inserted into the current contract.

So it is not certain I will recieve any of the mining rewards? This is so confusing.. I am mining for 2 days and I am not even certain I will mine anything. Can anyone check this info to be sure? I think a lot of new people will be wondering the same thing..

Your in the contract now! Wait for the superblock payment.

exec testvote

[aikida3k]

lasencja exchanges is stopped and we got botnet,whales and different idiots like this https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  dumping prices


VOTING FOR BAN/KICK this user https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  thats insane, i remember Robs first words,that BBP will be for poor ppl in Venezuela,Africa etc 6-7 months ago.. loooool


who is for? for me yes ...



AND WE NEED NO LINEAR MAG,UTXO system but EXPONENCIAL

example:

MAG1= 1000 BBP
MAG2= 2000 BBP
MAG3= 5000 BBP
MAG4= 9000 BBP
etc

Please vote:
http://forum.biblepay.org/index.php?topic=127.0


The problem with exponential increases is it persuades users to split the CPID into multiple CPIDs.
Its still a cat & mouse game if we do that.

I think the #1 line of defense is vote as high as possible for UTXO per magnitude first.

The first thing the user would do is split CPIDs if we had a rule that said: Require double the UTXO if Mag > 100, then they would create two cpids....  Im not a fan of squirrely program logic that we will have trouble supporting- and be frowned upon by the peer review panel for questionable logic.

I think the issue with staking via RAC is imagine a year from now when we have 49M RAC on Team Biblepay.  Yes, the circulation will have grown substantially by then, but the daily rewards will be about 80% of what they are now.  So today, 70K RAC is 63 Mag granting 90K coins a day (roughly under the corrected distribution), whereas in the above it is 1.5 Mag granting (roughly) 1800 coins a day.  Having to stake 10 BBP/RAC would be 700K BBP which today is probably reasonable, but a year from now, quite the impediment to the low power crowd.

In the end I see the stake/Mag being optimal, I would even say it should be higher to level the playing field which is I think the goal as much as anti-bots and coin stability.

I like another idea.  I like the idea of decreasing the amount of stake per RAC with the lower distribution.  A nice benefit of staking based on RAC is that the amount staked based on RAC will keep growing instead of being static at say 10 million.  The benefit of a growing stake is that it would bring in a new element to the coin - traders, people not necessarily looking to crunch or mine and instead hold for appreciation.  A drawback of the coin now is that it is full of miners and crunchers-- miners and crunchers are natural sellers.  They have expenses to cover.  This coin needs a way to bring in buyers, people who just want to own the coin without having to crunch or mine.  Staking based on RAC would help to do that because traders could come in to "front run" the growth in the network.  So then buying and holding BBP becomes a bet that the network will grow and the coin will appreciate based on an increasing amount staked.  Staking based on RAC gives the more value:  you need to get BBP in order to increase the number of computers you are using to crunch.  With staking based on MAG, the amount required to stake per user will shrink as the network grows even though the amount staked will stay static at say 10 million.  Staking per MAG doesn't give us a consistent supply sponge- just a 10M lockup- a fraction of the amount that the sanctuaries lock up, whereas staking per RAC will sop up supply and drive price higher.  

The way mining and crunching is right now is a race to the bottom:  Anyone will add computers to the point of becoming even with breakevens.  Adding computers adds expenses to the miner and adds to the amount that they must sell, thus lowering prices.  Staking per MAG has only a fractional lockup compared to sanctuaries, it won't make much of a price difference.  Staking based on RAC introduces a VIRTUOUS cycle and cures the race to the bottom.  Increasing network size has to be met with increasing aggregate stake.  Increasing aggregate stake amount should lead to increasing prices.  Increasing prices leads to higher breakevens.  Higher breakevens lead to a growing network.  A growing network leads to increasing aggregate stakes, which leads to higher prices....  A virtuous cycle.

Then we can support more orphans and do more work.

[Lichtsucher]

lightsucker thanks that you used my screens of my wallet iny your tutorial

My own Wallet was in german and I didn't wanted to restart They are placeholders for now, as they are not really "clean" (the lines are messy as  I needed to change some positions, some text is cut...).

[Bitconee]

Thanks for clearing it up.

Can you clarify this for me? I am mining last 2 days and this is the results I get. I am staking 3500 BBP and have my RAC seen over last 3 blocks but 0 magnitude and 0 payouts...

 "Command": "getboincinfo",
  "CPID": "328ae544f566cd3ec2191b0e825b38c3",
  "Address": "ADRESS",
  "CPIDS": "328ae544f566cd3ec2191b0e825b38c3;",
  "CPID-Age (hours)": 422439,
  "NextSuperblockHeight": 34235,
  "NextSuperblockBudget": 2660579,
  "328ae544f566cd3ec2191b0e825b38c3_ADDRESS": "ADRESS",
  "328ae544f566cd3ec2191b0e825b38c3_RAC": 387.43,
  "328ae544f566cd3ec2191b0e825b38c3_TEAM": 15044,
  "328ae544f566cd3ec2191b0e825b38c3_TaskWeight": 100,
  "328ae544f566cd3ec2191b0e825b38c3_UTXOWeight": 3650,
  "Total_RAC": 387.43,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 2660579,
  "Total Budget (One Week)": 7981737,
  "Superblock Count (One Week)": 3,
  "Superblock Hit Count (One Week)": 3,
  "Superblock List": "34030,33825,33620",
  "Last Superblock Height": 34030,
  "Last Superblock Budget": 2660579,
  "Last Superblock Payment": 0,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

I think you are on the network now but the current contract doesn't have you in there yet.

cat magnitude | grep 328a
<ROW>BRYo1mSUS9NB79RokuDF3N1NbFWdUvTBMK,328ae544f566cd3ec2191b0e825b38c3,0.201,1987605,15044,3650,100,977248,0,100.00,197,197

So atleast you see it somewhere, that's good. How did you find it? And will my CPID get into the contract automatically over time or?

Run:
exec dcc
go into ~/.biblepaycpre/SAN
cat magnitude | grep 328a

I think a contract is created for every super-block but I'm not sure if new CPIDs get inserted into the current contract.

So it is not certain I will recieve any of the mining rewards? This is so confusing.. I am mining for 2 days and I am not even certain I will mine anything. Can anyone check this info to be sure? I think a lot of new people will be wondering the same thing..

Your in the contract now! Wait for the superblock payment.

exec testvote

Ok I just checked and I see my wallet yay . What are the numbers below the included wallets? The amount to be payed? Also when I type exec unbanked I get this.

Code:

  "Command": "unbanked",
  "c852da1a620ad630b70c8ec1ccdee366": 1985966,
  "ee9a05fbab37c2a99dc9a67d65501477": 1988117,
  "8791a036b545f35e9ebd9333922738ac": 1986929,
  "b7d0b2a040ce2d739a70439b621d0f89": 1987934,
  "CPID_NOT_ON_FILE": 1986408,
  "300a9405117b43488cd8ea7eff438f39": 1987838,
  "4b7d2d64c88b32927a21ad20a57868e4": 1985935

Only b7d0b2a040ce2d739a70439b621d0f89 is a CPID I registered on the Biblepay pool site. Why are other CPID's there? And does this mean that all passed well and I should see the payments from that CPID as well?

[bible_pay]

lasencja exchanges is stopped and we got botnet,whales and different idiots like this https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  dumping prices


VOTING FOR BAN/KICK this user https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  thats insane, i remember Robs first words,that BBP will be for poor ppl in Venezuela,Africa etc 6-7 months ago.. loooool


who is for? for me yes ...



AND WE NEED NO LINEAR MAG,UTXO system but EXPONENCIAL

example:

MAG1= 1000 BBP
MAG2= 2000 BBP
MAG3= 5000 BBP
MAG4= 9000 BBP
etc

Please vote:
http://forum.biblepay.org/index.php?topic=127.0


The problem with exponential increases is it persuades users to split the CPID into multiple CPIDs.
Its still a cat & mouse game if we do that.

I think the #1 line of defense is vote as high as possible for UTXO per magnitude first.

The first thing the user would do is split CPIDs if we had a rule that said: Require double the UTXO if Mag > 100, then they would create two cpids....  Im not a fan of squirrely program logic that we will have trouble supporting- and be frowned upon by the peer review panel for questionable logic.

I think the issue with staking via RAC is imagine a year from now when we have 49M RAC on Team Biblepay.  Yes, the circulation will have grown substantially by then, but the daily rewards will be about 80% of what they are now.  So today, 70K RAC is 63 Mag granting 90K coins a day (roughly under the corrected distribution), whereas in the above it is 1.5 Mag granting (roughly) 1800 coins a day.  Having to stake 10 BBP/RAC would be 700K BBP which today is probably reasonable, but a year from now, quite the impediment to the low power crowd.

In the end I see the stake/Mag being optimal, I would even say it should be higher to level the playing field which is I think the goal as much as anti-bots and coin stability.

I like another idea.  I like the idea of decreasing the amount of stake per RAC with the lower distribution.  A nice benefit of staking based on RAC is that the amount staked based on RAC will keep growing instead of being static at say 10 million.  The benefit of a growing stake is that it would bring in a new element to the coin - traders, people not necessarily looking to crunch or mine and instead hold for appreciation.  A drawback of the coin now is that it is full of miners and crunchers-- miners and crunchers are natural sellers.  They have expenses to cover.  This coin needs a way to bring in buyers, people who just want to own the coin without having to crunch or mine.  Staking based on RAC would help to do that because traders could come in to "front run" the growth in the network.  So then buying and holding BBP becomes a bet that the network will grow and the coin will appreciate based on an increasing amount staked.  Staking based on RAC gives the more value:  you need to get BBP in order to increase the number of computers you are using to crunch.  With staking based on MAG, the amount required to stake per user will shrink as the network grows even though the amount staked will stay static at say 10 million.  Staking per MAG doesn't give us a consistent supply sponge- just a 10M lockup- a fraction of the amount that the sanctuaries lock up, whereas staking per RAC will sop up supply and drive price higher.  

I believe that most of this is inaccurate-   staking per RAC would have less and less benefit as we grow, in contrast to Mag which is a function of the total team, money supply as compared to Mag is more closely related than Rac/money supply, a low money supply factor is only a function of what the vote outcome is, its nonsense about the current miner expenses - as bbp has forward growth value, the lockup is low only because people are voting for the lower SPM, and there is no guarantee staking per RAC would affect the price at all.

[v1.0]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

[bible_pay]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

You can cancel the password prompt, its just for PODC (Cancer mining). 
See this for cancer mining:
http://wiki.biblepay.org/Distributed_Computing_2

So, first please ensure your system time and timezone is correct.  A lot of people cant sync if the time is off by more than 2 minutes....

Then resync.

[aikida3k]

lasencja exchanges is stopped and we got botnet,whales and different idiots like this https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  dumping prices


VOTING FOR BAN/KICK this user https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=1987853  thats insane, i remember Robs first words,that BBP will be for poor ppl in Venezuela,Africa etc 6-7 months ago.. loooool


who is for? for me yes ...



AND WE NEED NO LINEAR MAG,UTXO system but EXPONENCIAL

example:

MAG1= 1000 BBP
MAG2= 2000 BBP
MAG3= 5000 BBP
MAG4= 9000 BBP
etc

Please vote:
http://forum.biblepay.org/index.php?topic=127.0


The problem with exponential increases is it persuades users to split the CPID into multiple CPIDs.
Its still a cat & mouse game if we do that.

I think the #1 line of defense is vote as high as possible for UTXO per magnitude first.

The first thing the user would do is split CPIDs if we had a rule that said: Require double the UTXO if Mag > 100, then they would create two cpids....  Im not a fan of squirrely program logic that we will have trouble supporting- and be frowned upon by the peer review panel for questionable logic.

I think the issue with staking via RAC is imagine a year from now when we have 49M RAC on Team Biblepay.  Yes, the circulation will have grown substantially by then, but the daily rewards will be about 80% of what they are now.  So today, 70K RAC is 63 Mag granting 90K coins a day (roughly under the corrected distribution), whereas in the above it is 1.5 Mag granting (roughly) 1800 coins a day.  Having to stake 10 BBP/RAC would be 700K BBP which today is probably reasonable, but a year from now, quite the impediment to the low power crowd.

In the end I see the stake/Mag being optimal, I would even say it should be higher to level the playing field which is I think the goal as much as anti-bots and coin stability.

I like another idea.  I like the idea of decreasing the amount of stake per RAC with the lower distribution.  A nice benefit of staking based on RAC is that the amount staked based on RAC will keep growing instead of being static at say 10 million.  The benefit of a growing stake is that it would bring in a new element to the coin - traders, people not necessarily looking to crunch or mine and instead hold for appreciation.  A drawback of the coin now is that it is full of miners and crunchers-- miners and crunchers are natural sellers.  They have expenses to cover.  This coin needs a way to bring in buyers, people who just want to own the coin without having to crunch or mine.  Staking based on RAC would help to do that because traders could come in to "front run" the growth in the network.  So then buying and holding BBP becomes a bet that the network will grow and the coin will appreciate based on an increasing amount staked.  Staking based on RAC gives the more value:  you need to get BBP in order to increase the number of computers you are using to crunch.  With staking based on MAG, the amount required to stake per user will shrink as the network grows even though the amount staked will stay static at say 10 million.  Staking per MAG doesn't give us a consistent supply sponge- just a 10M lockup- a fraction of the amount that the sanctuaries lock up, whereas staking per RAC will sop up supply and drive price higher.  

I believe that most of this is inaccurate-   staking per RAC would have less and less benefit as we grow, in contrast to Mag which is a function of the total team, money supply as compared to Mag is more closely related than Rac/money supply, a low money supply factor is only a function of what the vote outcome is, its nonsense about the current miner expenses - as bbp has forward growth value, the lockup is low only because people are voting for the lower SPM, and there is no guarantee staking per RAC would affect the price at all.

Staking per MAG keeps the race to the bottom in.  Right now a rational player will introduce as many computers to crunch as capital will allow because breakevens are so high.  Therefore introduce as many computers as capital allows until your breakeven is reached.  Sell your biblepay on the market.  In the process biblepay has no natural buyers, only natural sellers- the miners and the crunchers.  Buyers, not miners are the ones who are really supporting the orphans.  Miners and crunchers introduce supply while buyers sop up supply.  It works the same way in all commodities:  If the price of oil is above your expected breakeven, you go out and explore for more oil until you reach your breakevens.  In the process you introduce more supply on the market which eventually makes prices come down again.  If you are a cattle rancher and prices are above your breakeven, you increase your herd size and your production until you reach your breakevens.  Selling your calves on the market with greater supply eventually brings prices back down.  The difference between BBP and oil and cattle?  There are natural buyers:  people have to buy oil to make gasoline and diesel.  People have to buy fat cattle to make beef.  People don't have to keep buying BBP once the static stake amount to magnitude is reached, however, staking to RAC, miners then become natural buyers as they seek to increase the amount of BBP they can generate.  Traders and investors see this and are encouraged and buy.  

My argument is far from nonsense.
We don't do enough to encourage buyers.  Staking to RAC would help that.

[v1.0]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

You can cancel the password prompt, its just for PODC (Cancer mining).  
See this for cancer mining:
http://wiki.biblepay.org/Distributed_Computing_2

So, first please ensure your system time and timezone is correct.  A lot of people cant sync if the time is off by more than 2 minutes....

Then resync.

Yes, validated the system timezone and time is correct. Not resyncing or showing progress. Did I have to change something in my wallet configuration file to go along with the update? Currently it looks like:

addnode=dnsseed.biblepay-explorer.org
addnode=dnsseed.biblepay-explorer.org
gen=1
genproclimit=2
poolport=80
pool=https://pool2.biblepay.org
workerid=****(hidden)

[aikida3k]

Ok so I changed my vote to 50,000 per Magnitude.

Reason is this: When rewards drop to around 1.3 million BBP total, 1mag = 1(/1000)*1.3 million = 1300 BBP.
This means that it will take ~39 days to pay back your stake which I think is reasonable.

In fact, it is bad for myself personally because it is a lot of stake, but I think it is best for the coin overall.


EDIT: For comparison:

BBP/magnitude      days to pay back stake

250                               0.2 days
500                               0.38 days
1000                             0.77 days
2500                             1.92 days
5000                              3.85 days
10000                            7.7 days
20000                             15.4 days
50000                             38.5 days

50000 still becomes a static 50 million lockup.  For comparison we have 169 masternodes which gives a lockup of nearly 262 million.  Right now total supply is 459 million.  So that lockup of 262 million increased price from a consistent 10-20 satoshi to a consistent 25-35 satoshi with some higher peaks.  I like staking to RAC because it will sop up supply, and it should still be affordable if bitcoin takes off whereas masternodes will become unaffordable while we still have a lot of supply to come.  I can imagine a scenario where the annual returns are attractive on masternodes, but the price because of bitcoin makes them expensive and out of reach for most people, but they could still afford to either buy and hold, or buy, stake and crunch.

Can we introduce a vote to vote on stake based on MAG or stake based on RAC?

[tmike]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

You can cancel the password prompt, its just for PODC (Cancer mining).  
See this for cancer mining:
http://wiki.biblepay.org/Distributed_Computing_2

So, first please ensure your system time and timezone is correct.  A lot of people cant sync if the time is off by more than 2 minutes....

Then resync.

Yes, validated the system timezone and time is correct. Not resyncing or showing progress. Did I have to change something in my wallet configuration file to go along with the update? Currently it looks like:

addnode=dnsseed.biblepay-explorer.org
addnode=dnsseed.biblepay-explorer.org
gen=1
genproclimit=2
poolport=80
pool=https://pool2.biblepay.org
workerid=****(hidden)

Can you delete the chain and re-sync.

And try these instead:
addnode=node.biblepay.org
addnode=biblepay.inspect.network

[aikida3k]

Let's look at this a different way.  Let's say I go to Prestonwood Baptist church, and I say to people, "Hey why don't ya'll buy some biblepay that I'm mining.  It will help support orphans."  They might ask,"Are you buying it?" I'd have to say, "No, I'm just mining the pea-wodding out of it.  It has a limited supply, but so do the other 1550 and increasing other coins available."  They would feel like suckers being taken advantage of.

But! If we have stake based on RAC, and I say to people, "Hey why don't ya'll buy some biblepay that I'm mining.  It will help support orphans."  And they ask,"Are you buying it?"  I have to say, "Yes! For every computer I add that does crunching, I have to either hold or buy biblepay."  (With magnitude based staking, the amount I have to stake should decrease as the network grows: MAGSHARE=MAG/USERBASE as user base expands, my share of the MAG becomes smaller.)  Then they might say, "Oh, it sounds like a good idea if you are buying and holding right alongside me, even though I'm not that interested in crunching."  And I could say, "Yep, go for it!"

[v1.0]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

You can cancel the password prompt, its just for PODC (Cancer mining).  
See this for cancer mining:
http://wiki.biblepay.org/Distributed_Computing_2

So, first please ensure your system time and timezone is correct.  A lot of people cant sync if the time is off by more than 2 minutes....

Then resync.

Yes, validated the system timezone and time is correct. Not resyncing or showing progress. Did I have to change something in my wallet configuration file to go along with the update? Currently it looks like:

addnode=dnsseed.biblepay-explorer.org
addnode=dnsseed.biblepay-explorer.org
gen=1
genproclimit=2
poolport=80
pool=https://pool2.biblepay.org
workerid=****(hidden)

Can you delete the chain and re-sync.

And try these instead:
addnode=node.biblepay.org
addnode=biblepay.inspect.network

Delete the chain?? Do I have to rebuild the entire chain now just because of an upgrade, or is it because of the node change you suggested? Or is it to maintain integrity because of the node change? I'm not sure how to delete the chain, I suppose I just dive into my Biblepay folder and find it there?

Thanks again- just want to make sure I'm following this correctly before I go deleting stuff!

[tmike]

Biblepay - 1.1.0.9b
Mandatory Upgrade - for Entire Network (including Sanctuaries)
Before block 35110

- Avert mining crash and relay error messages in miner to getmininginfo
- Fix PODC association error (unable to sign cpid)
- Remove logging
- Fix getnetworkhashps
- Add unbanked CPID support
- Add configurable SPM (stake-per-magnitude) UTXO requirement (pending outcome of poll)
- Remove CompetetiveMining Tithe
- Added exec search key filter (Ability to search for DCC elements by CPID - IE exec search UTXOWEIGHT ca89)
- 7 Minute block targets as of block 35110
- Fix DC Superblock Budget as of height 35110

Hi- wondering if you can help. I've been using Biblepay with its GUI program through Linux Ubuntu, and mining through an account at pool2.biblepay.org. All has been going seamlessly, until today. I upgraded my Biblepay version because last time I logged into my pool2 account it said we have to upgrade to version 1.1.0.1+ in order to keep mining. But now after the upgrade, it no longer syncs, says "no block source available". It also keeps asking me for my wallet password when I load it for "PODC updates" which I have no clue what this means.

Can you please help me resolve this, or point me to a tutorial of sorts?

Thankyou

You can cancel the password prompt, its just for PODC (Cancer mining). 
See this for cancer mining:
http://wiki.biblepay.org/Distributed_Computing_2

So, first please ensure your system time and timezone is correct.  A lot of people cant sync if the time is off by more than 2 minutes....

Then resync.

Yes, validated the system timezone and time is correct. Not resyncing or showing progress. Did I have to change something in my wallet configuration file to go along with the update? Currently it looks like:

addnode=dnsseed.biblepay-explorer.org
addnode=dnsseed.biblepay-explorer.org
gen=1
genproclimit=2
poolport=80
pool=https://pool2.biblepay.org
workerid=****(hidden)

Can you delete the chain and re-sync.

And try these instead:
addnode=node.biblepay.org
addnode=biblepay.inspect.network

Delete the chain?? Do I have to rebuild the entire chain now just because of an upgrade, or is it because of the node change you suggested? Or is it to maintain integrity because of the node change? I'm not sure how to delete the chain, I suppose I just dive into my Biblepay folder and find it there?

Thanks again.

I'm just saying if your in a hurry, it only takes 5 minutes. IF you don't want to try the nodes I posted.