Author

Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 600. (Read 243376 times)

newbie
Activity: 180
Merit: 0
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?
jr. member
Activity: 36
Merit: 10
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)
newbie
Activity: 180
Merit: 0
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.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

jr. member
Activity: 36
Merit: 10
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.



newbie
Activity: 12
Merit: 0
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
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 Smiley. 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?
jr. member
Activity: 219
Merit: 3
lightsucker thanks that you used my screens of my wallet iny your tutorial Grin Grin Grin Grin

My own Wallet was in german and I didn't wanted to restart Wink 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...).
newbie
Activity: 180
Merit: 0
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.
member
Activity: 157
Merit: 10
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
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
full member
Activity: 770
Merit: 100
lightsucker thanks that you used my screens of my wallet iny your tutorial Grin Grin Grin Grin
newbie
Activity: 12
Merit: 0
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
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..
newbie
Activity: 180
Merit: 0
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.  
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.


full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.

full member
Activity: 770
Merit: 100
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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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





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.



Rob you got true with that exponencial btw..... but why you set only 20 000BBP max?   all ppl in slovak chat room told that we can vote for more high 50 000bbp for 1MAG ..... better for ... but you have to implement immediately this SYSTEM STAKE-BBP/MAG cos botnet in these days mined mooooore BBP ... you know it


Ok, I added another poll option for 50,000 BBP, and extended the poll a couple days.

But note that you are all losing the vote to 10,000 right now so you will need to step it up.


member
Activity: 157
Merit: 10
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
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.
newbie
Activity: 12
Merit: 0
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
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?
Jump to: