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 ... 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 ... 263
2776
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 10:43:56 AM »
Mobile wallets don't keep a full copy of the blockchain, only headers and your own wallet's tx and utxo. This makes any PoS-like schema very hard to implement. PoG is different in concept but I'm afraid it shares this limiting factor with PoS.

There is a nice article here:
https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

No actually POG could work on mobile though, they just cant be a reaper- they can only be a sower/tither.  We can make the 'Tithe to Mine' button in the mobile wallet send an aged tithe, and that would get them in the pool for a reward.  They would receive part of the 80% pool weight.

As long as you can figure out the HD-wallets coin-age, coin-value, tithe-amount, and receive-address (which I know you can!) we can do it.

This would be pretty cool to have mobile wallets in a tithe pool.

The wallet would have to ensure it respects the current difficulty level of the round in order to successfully tithe though.


2777
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 10:01:53 AM »
Fair enough,

I will say in practice the POBH rewards have been 420-480 average per block (I could give you more specific data if needed)
So it is a small piece of the pie.

Also, would it be possible to enable/disable PODC with a spork?  (leave the code in, do cutover after a certain block but have the ability to "back out" if we need/want to in the future).

Thats OK, dont need it, because the heat mining reward (POBH) can just be used for the reward in testnet.  No problem.

On #2, I know that sounds good and I also thought of maybe, but I dont think we can do that.  I think we need a hard cutover when we go from PODC to no PODC (with a height) that will disable that particular feature, superblocks for it, and change the price. 

This is because the chain needs to stay synced and after about 5000 blocks in the future we cant rely on old masternode data to be around for prior blocklevel rewards.  (Thats why all the business logic if then else still exists every time we have a reward change - ie we break from block feature F11000 to 12000 to 13000 etc).


2778
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 05, 2018, 09:20:56 AM »
My only concern with using it on the POBH side is it directly competes with PODC..

PODC combines coins into one for the updates, so only folks not working on PODC could participate in POG, this would need to be addressed somehow.

Yes, and just to clarify, I was thinking something like this could go down:

We release our testnet version in a week (or whatever), with the following:
POBH is extended to be POG(utilizing POBH), and the small miner reward (of 600~) is actually the source of what is distributed in the pool (IE 20% of 600 is 120 that goes to the reaper, the remaining 80% goes in the pool).  PODC is left in an "ON" state. 

We test for a couple months and fit this particular environment into our mandatory release.

So in Prod, POG is basically utilizing heat mining budgets.

Then when we feel safe, we do a hard cutover.  (That is Disabling PODC and diverting its entire budget back into POG).  I havent studied the possibility of doing a slow cutover.  (I think the testing results + prod POG results would dictate a potential "cutover block" to remove PODC that could be fit into one single mandatory, if lucky - but this is definitely not something that I would rush).

I plan on putting extra metrics in testnet so we can reconcile every hash and bbp in the pool; this should make it easy to ensure the whole thing is square.







2779
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 04, 2018, 10:51:53 AM »
PoG if it were to be selected (which I really feel is the wish of the Dev) one issue I see is it would require a long test period as it's a very novel solution.  The issue is we don't have very many users, and very very few participate in the test net.  So my fear is there will be loopholes and bugs that we won't catch but someone will exploit.  And my real fear is there will be many such bugs (as it's a novel system and having eight or ten people test it won't expose nearly enough issues), which could mean a series of exploits (and disproportionate gains for the exploiters) followed by hot-fixes and unplanned mandatory releases which could put our markets off line.

In short, even if PoG is the next billion dollar idea, the BBP community lacks the resources to adequately test it.


Well in general this is good as the need for testing is critical, however we don't "lack the resources to adequately test it".

We need to put it in testnet, invite more than 8 testers (like 25), we need to cover every test case - and add every possible exploit.

To address the resource issue, it is possible to test it as what database programmers do (in the case of data management companies) is they write a stress test program and theoretically stress the system to exploit what conditions we think are missing - say for example we only have 10 testers, then we need to write a program to simulate the real life transactional activity of 250 users - then we would feel a lot better about it.

I think in addition to that we can phase this in two phases.  We go live with POG in POBH only then stay with it for a quarter and fix any critical issues before we attempt to transition from PODC to POG (during the second mandatory).

2780
Archived Proposals / Re: Payment Gateway offer
« on: December 03, 2018, 10:00:22 AM »
Thanks for starting this discussion.
My gut tells me this is a little high since we have crashed.

However I want to offer an alternative path possibly, I wonder if we can find one payment gateway that is actually *in use* by some alt-coin, and has selling products (like a book for example) - and then we make an attempt to contact that gateway and become listed?

This way risk is lower that we end up with a non working gateway or unpopular gateway.

I found these people the other day:

https://support.coingate.com/

https://coingate.com/accept-altcoins



Alternatively if this doesn't pan out, someone could try to research on the heels of DOGE since they have a similar emission as us and are popular - find a doge storefront integration and we ask that company to let us integrate their gateway etc.


2781
Archived Proposals / Re: Mass Adoption for BiblePay II
« on: December 02, 2018, 04:49:28 PM »
I do not speculate, I calculate :)

The amount of BBP staked today due to PODC is well over 100M.

If PODC is gone, stake requirement will also be gone. It is only logical to assume some of the holders will sell off their BBP then. (Yes, some will bury it into masternodes, but we cannot assume all will do that.)

Any sales with today's weak buy board will push the price down (3 satoshis or less).

It is hoped that POG-2 will bring in cash (via new users), but as said, that is hope. There is not even an estimate on how many new users will bring in how much cash.

I understand and agree with the notion of a drop in the short term which would bring in growth for the long term; but we need to clarify what is short term and what is long term. This is the crypto world, and most people in this world would say one year is long term. That is a definition I tend to agree with. If we are on the same page about the term, then fine - I can hold on to my coins for a year for a rise back to 30+ satoshis (That was where I jumped on the boat)  ;)

Having said that, POG-2 may be tuned to promote staking  further, such that longer-term hodlers of coins get a bigger return when they tithe. This would reduce the sell pressure created by PODC staking gone. This however, would be real life repeating itself here: "rich gets richer". Well, I guess we cannot really escape basic principles of life even in the crypto world :)

I just wanted to quickly jump in and add a distinction to the conversation regarding "rich get richer" vs POG2:

First differences between algos:

Proof-of-stake:  Entire free balance in stake * interest_component = interest_earnings (Rich definitely get richer based on total balance)
Proof-of-stake BiblePay:  62% of our money supply is tied up in Sancs, so 38% of money supply is available to "stake" a reward
Proof-of-Giving2:  Instead of basing the pool weight on the sowers amount_in_stake (this would be considered the unlocked coin_amount*age) , we base the pool weight on :  Tithe amount given with a required Spent coin > than difficulty level.

Notice the difference here:  In Scenario A, we reward a user entirely by the proven unlocked stake balance.
In Scenario B, we base the tithe_weight on the TITHED AMOUNT, and this amount must be spent out of a coin meeting the Difficulty requirements of the round.

Yes, I admit that richer users will have more free coins to tithe with, but note that the Actual act of tithing, the actual amount tithed drives your tithe_weight (not your available stake weight).  And note that in POG2, you must stake a coin and spend your coin age (so this cannot be repeated over and over until the coin ages again).  Also note that since the coin value must be greater than the tithe amount, one who spends a large coin will give up all of its age for quite a long period giving others in our ecosystem a long chance to tithe.

I don't have a scientific study of this effect, but if I were to guess I would "assume" forcing the spending of a single required coin will cause a whale to lose at least 50% of the benefit of (having whale resources available, this is because with POS you can use as many coins necessary to achieve
 total coin*age, where in POG you need one specific aged coin > min_amount for the round - and once its spent it is out for a while).  Remember the whales only have 38% of the money supply since they have the sancs tying up their capital....  EDIT:  More of a refined thought; to demonstrate this in contrast to POS:  With an average difficulty level of 650 in POG2,  you need to spend a 6 day old coin of value > 2500 but you can only tithe up to 270 from that coin.  So coins don't go as far as POS - and ultimately weight is based on what you tithed.





2782
Archived Proposals / Mass Adoption for BiblePay II
« on: November 29, 2018, 06:02:22 PM »
When voting please consider a non-technical investor who wants to mine- remember to consider a person that has a busy lifestyle that does not want to follow more than 1-2 steps before losing patience, and has no interest in learning any new acronyms.

With PODC - we would need to pull in developer resources to shield the user from acryonyms, and find a way to concentrate new user mining power to a boinc project with fair payment without exposing the user to technical terms and requiring them to monitor RAC on disparate sites.  We also have quite a bit of infrastructure to support PODC: supporter pools, diagnostic tools, help desk answers, forum posts, etc.  Consider the total barrier of entry and ongoing maintenance per user and for the codebase.  Also consider the risks if BOINC changes the code, the interface, breaks or gets hacked.



With POG II - we would move back to our Proof-of-bible-hash style mining, on generally one machine per user (IE tither).  People would be rewarded with mining rewards in a "pool" depending on how much they tithe to the orphan foundation per day.  This solution would be more of a one-click setup, with the only decision needed by the end user to either manually tithe or set up an automatic tithe.  The maintenance should technically be lower for both user questions and the IT codebase.  There is not a chance of third party site being hacked or an oracle requirement.  The 51% risk appears to be low (the same as PODC or lower, as long as sleep capability is well designed).  One potentially large side benefit:  Being possibly the first crypto with an integrated pool - and not requiring third party pools.
(Rob recently added a proof-of-giving difficulty algorithm to address the top 2 POG problems:  Monthly tithe cap to prevent a massive monthly dump, and preventing a hacker from using a tithe script attack).  With these two improvements, voting is being re-evaluated.
Please read this wiki:
https://wiki.biblepay.org/Proof-of-Giving-II
And this wiki:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners



With POOM - we decentralize our orphan sponsorships out to the individual miners.  The miners are rewarded with an amount of biblepay that is carved out of the heat mining budget in relationship to their monthly private commitment amount.  The downside to POOM is this requires a centralized API at orphanstats.com, and biblepay has the ability to log in and audit individual user compassion accounts.  The plus is its very green, and diverts electric costs over to orphan sponsorships.




With IPFS - we require each user to make firewall rule changes, run a flavor of an IPFS server, allocate a portion of the hard drive, and we have the sanctuaries grade each miner on file hosting quality.  The downside to this is:  IPFS is still volatile, sometimes crashing on the pool server, the interface may change, the setup for a miner would be complicated, and we have no documentation for this complete yet, and we haven't finished the proof of concept.  The positive side is its futuristic.

2783
Archived Proposals / Re: Mass Adoption for BiblePay
« on: November 27, 2018, 09:02:54 AM »
My bottom line view is this.   Will changing increase our user base dramatically and be positive for the price in the moderate term?  I'll rate each of the scenarios independently in my view.

Most crypto users are somewhat computer savvy.  The entire crypto market is tough to explain to non-computer users, is somewhat frightening and is illogical to many.  Convincing Computer Jane to try crypto is far easier than than getting Joe Sixpack on board.  If we can make PoG, PoOM or IFPS one step simple, then we should be able to do that for PoDC just as well.  The fact we haven't been able to accomplish this for PoDC in the past six months gives me pause to think we'll have better results for any of the others.  I believe we're really only about two or three videos and maybe one or two re-writes away of having sufficient support documents that a competent computer user (not a nerd like myself) could follow along and PoDC.  I don't think any amount of documentation is sufficient to get the majority of people to try crypto.  The main issue I have with PoG is that there could (likely) be dramatic variability in the rewards from day to day which would put off a new user.  Even with equally well developed support documents, I see the pool of potential users to be gained by the technical gains as small and the price impact as commensurate.

Shifting to PoG/PoOM would likely benefit me personally, but it takes away an entire marketing arm (BOINC - research mining) and replaces it with an amplified Orphan/Charity support.  What users we'd be able to pick up due to this I question.  How many people have been telling themselves "I like this BBP coin, but 10-15% donation was too small, yet now 50% is enough for me to jump it".  I see the pool of potential users to be gained by marketing changes due to a change as neutral to negative, with minimal price impact.

In the end, there will be only a very small portion of users weigh in on this, and historically, unless there is near universal dissent, we follow the heart of our Developer.  Not saying that it is right, wrong or indifferent, but in the end, if our Developer wants it, that is what is going to be worked on...which has gotten us this far and will likely carry us down the road.  So ramp up it up in test net, let us try and break it, find as many issues as we can and make it as good as it can be.  But let's stop belaboring the issue.


Thanks for the positive support.

Although I think we possibly could have improved POG enough for it to work, I really didn't like the out-of-line high-tithe percentage potential it had (IE causing the monthly dump).

In light of the popular view, I'm going to shelve this technology for a while in favor of other endeavors.

I'll also add weight to prioritizing PODC easy adoption technical features.

Thanks for the exercise all, it was a net gain for our arsenal from a wisdom standpoint.



2784
Archived Proposals / Re: Mass Adoption for BiblePay
« on: November 24, 2018, 03:40:21 PM »
We are truly blessed to have so many options, you are amazing Rob

My vote is for exploring Proof of Giving (POG)

Further discussion: https://forum.biblepay.org/index.php?topic=319

As a masternode owner, I am totally okay with losing short term ROI for long term growth,

I also believe Rob's heart and mind are for POG

For the average user, mining becomes just buying some coins and donating a little every day
(time frequency dropdown and a BBP amount),
could even default these values to Daily and 10 BBP and auto start once coins are added to the wallet

Thanks!

The question is, if we take two scenarios, lets assume we actually do make PODC easier to use.  In scenario A, we have a power user running boinc, and being smart enough to check the RAC.  In scenario B, we have a grandmother who is smart enough to set up an automatic daily tithe with POG.  Will the grandmother set up and maintain the easy-to-use version of PODC?  I don't know.

Should we continue to try to cure cancer and overcome the current negative growth, or, should we free everyone up with POG and potentially spread the gospel?  Why do they seem to be mutually exclusive?  Because I feel that we are currently supporting a big infrastructure. 

What is the possibility of us adding cool new gospel features in?  I would say certainly high in either solution, because that is our job, but I lean toward POG giving us the ability to free up more resources to write those things we don't have.




2785
Archived Proposals / Re: Mass Adoption for BiblePay
« on: November 22, 2018, 08:51:35 AM »
I tend to agree with West and Talisman. Making BBP easier to mine does not solve the main issue, the lack of investors who would buy and hold BBP as an investment. Yes, miners can eventually turn into investors and become part of the community, but we still need many more non-mining investors.

BBP has the potential to be very attractive for investors, if it was marketed as "By buying BBP, you are supporting charity + helping to find cures for illnesses, while investing at the same time". The main thing that BBP lacks now is PR and marketing.

That being said, the only new Proof-of-something that would make sense to me would be some kind of Proof-of-PR.
E.g. something that would benefit miners for sending unique IPs to https://www.biblepay.org/<ANYTHING>?ref=CPID_OR_BBP_ADDRESS
or some other referral system. I can see how this could be misused, but you may get the idea :)

When I hear your perspective it makes me think of all the charity junk mail I get at home that goes in the trash.  All the charities I gave to once and now they spend more on PR than on helping others.

I think of the mileage we got through our airdrop and through our google ads (we probably kept 3 users).

Then I think of the potential of organic growth, and what potential could we have if thousands of home users ran biblepay in the background, and how many of those would become investors, as compared to a costly PR campaign? 

Also, when I think of us becoming a science coin I cringe, because I didn't intend to turn a Christian community into a science based community.


2786
Archived Proposals / Re: Mass Adoption for BiblePay
« on: November 21, 2018, 08:28:09 PM »
Why does a good samiritan want to join BiblePay when there are vehicles outside of BiblePay to give without expecting something in return? Its far simpler to put down a recurring monthly credit card or bank transfer than to deal with a crypto wallet. I guess you'd have to explain how to attract a crowd that would find joining BiblePay (even with PoG) far more difficult than just doing a recurring payment elsewhere.

@Rob - How is PoG going to work with recurring tithing? Is this going to be a superblock daily (e.g. 205 blocks?) and not actually a 24 hour day? The drift and 7 minute average blocks are not conducive to a 24 hour day y'know.

The Tithe appears to be one novel way of providing mining weight per distinctive user without revealing a users identity.  If you switch over to something that does not collect an accumulating donation, then you open the coin up to cat & mouse games again (IE exploiting multiple instances and a hashpower arms race etc).  Note that if everyone collectively only tithes a little per day, then everyone makes a large net profit.  It's only when big givers show up in every tranche where the days profit declines.

In POG, every 7 minute block would pay all miners in that tranche.  So at block 80,000 we may pay 50 miners in tranche 0.  On block 80,001 we pay 40 miners in tranche 1.  Etc...  I see no problem there.

2787
Archived Proposals / Mass Adoption for BiblePay
« on: November 21, 2018, 10:57:17 AM »
When voting please consider a non-technical investor who wants to mine- remember to consider a person that has a busy lifestyle that does not want to follow more than 1-2 steps before losing patience, and has no interest in learning any new acronyms.

With PODC - we would need to pull in developer resources to shield the user from acryonyms, and find a way to concentrate new user mining power to a boinc project with fair payment without exposing the user to technical terms and requiring them to monitor RAC on disparate sites.  We also have quite a bit of infrastructure to support PODC: supporter pools, diagnostic tools, help desk answers, forum posts, etc.  Consider the total barrier of entry and ongoing maintenance per user and for the codebase.  Also consider the risks if BOINC changes the code, the interface, breaks or gets hacked.

With POG - we would move back to our Proof-of-bible-hash style mining, on generally one machine per user (IE tither).  People would be rewarded with mining rewards in a "pool" depending on how much they tithe to the orphan foundation per day.  This solution would be more of a one-click setup, with the only decision needed by the end user to either manually tithe or set up an automatic tithe.  The maintenance should technically be lower for both user questions and the IT codebase.  There is not a chance of third party site being hacked or an oracle requirement.  The 51% risk appears to be low (the same as PODC or lower, as long as sleep capability is well designed).  One potentially large side benefit:  Being possibly the first crypto with an integrated pool - and not requiring third party pools.

With POOM - we decentralize our orphan sponsorships out to the individual miners.  The miners are rewarded with an amount of biblepay that is carved out of the heat mining budget in relationship to their monthly private commitment amount.  The downside to POOM is this requires a centralized API at orphanstats.com, and biblepay has the ability to log in and audit individual user compassion accounts.  The plus is its very green, and diverts electric costs over to orphan sponsorships.

With IPFS - we require each user to make firewall rule changes, run a flavor of an IPFS server, allocate a portion of the hard drive, and we have the sanctuaries grade each miner on file hosting quality.  The downside to this is:  IPFS is still volatile, sometimes crashing on the pool server, the interface may change, the setup for a miner would be complicated, and we have no documentation for this complete yet, and we haven't finished the proof of concept.  The positive side is its futuristic.


2788
Archived Proposals / Re: Should we remove the BOINC Team Blacklist (PODC)?
« on: November 20, 2018, 04:03:01 PM »
We still have the floodgates open for other teams, it looks as though we are just removing the blacklist (of byteball and gridcoin).

We still have the UTXO as Sun pointed out also.


2789
We are sponsoring 100 recurring orphans from compassion (@ $3800.00 per month).

This is equal to 11.8MM BBP for the month of November 2018. (3800/.000321).

Since we have a projected 5.11 month credit on our account and we have many proposals this month I am seeking 1 million bbp.



2790
Archived Proposals / November IT payroll
« on: November 19, 2018, 03:31:24 PM »

In August I worked on BiblePay for 112 hours. 
Invoice: 112*40=$4480/.000321=13.9MM bbp.

I am seeking 2 million bbp (capping the amount to allow other IT + Jaaps reimbursements this month be voted in).


Commits on Aug 21, 2018
1.1.4.5b-Leisure Upgrade  …


Commits on Aug 28, 2018
1.1.4.7b-NOOP  …

@biblepay
biblepay committed on Aug 28
 
1.1.4.7-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 28
 
Commits on Aug 26, 2018
1.1.4.6h - Leisure Upgrade  …

@biblepay
biblepay committed on Aug 26
 
1.1.4.6g-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 26
 
Commits on Aug 24, 2018
1.1.4.6f-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 24
 
Commits on Aug 23, 2018
1.1.4.6e-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 23
 
1.1.4.6d-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 23
 
1.1.4.6c-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 23
 
Commits on Aug 22, 2018
1.1.4.6b-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 22
 
1.1.4.6-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 22
 





@biblepay
biblepay committed on Aug 21
 
Commits on Aug 14, 2018
1.1.4.5-Leisure  …

@biblepay
biblepay committed on Aug 14
 
Commits on Aug 12, 2018
1.1.4.4b-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 12
 
Commits on Aug 10, 2018
1.1.4.4-Leisure Upgrade  …

@biblepay
biblepay committed on Aug 10
 
Commits on Aug 4, 2018
1.1.4.3 - Leisure Update  …

@biblepay
biblepay committed on Aug 4
 
1.1.4.2 - Leisure Update  …

@biblepay
biblepay committed on Aug 4

Pages: 1 ... 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 ... 263