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 ... 116 117 118 119 120 121 122 [123] 124 125 126 127 128 129 130 ... 263
1831
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: February 05, 2020, 09:24:23 AM »
One other very interesting possibility I have discovered, that is being programmed in, is the ability to also pair with other randomx coins (in addition to XMR).

Although I admit this is waaay to complicated to do on the initial rollout, Im making sure that it is possible in the future.  It also complicates how we drive for charity, complicates the pool and many other things.  But the pro would work something like this:
Let us assume we are operating as a pair with XMR for 1 year (BBP+XMR) is received for hashing.  Let us assume the program is a success and we generate more XMR in charity rewards than 10% of our charity budget would have allowed (from governance) and it successfully removes the sell pressure off of BBP (and part of the mining reward pressure too!).  Let us assume our price rises to 10 satoshi.

What we could actually potentially do is partner with another randomx coin, and most likely I would ask one of our eager community members, to take on starting a separate pool with that pair.  It would work the same way as XMR, but provide a separate revenue stream for charity.  Yes, it would impact the XMR relationship, but I don't think in a negative way.  What would happen is it would get harder to mine BBP (which theoretically results in higher priced units).  So it would not necessarily be a bad thing to have more than one type of pool.

But again, this is far in the future.  The main concept here is the core wallet will be written in a generic way, allowing the solving equation to solve not only XMR but for other randomx solutions as well.  The security would still pass also - due to the same pool integration requirements.


1832
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 31, 2020, 08:53:16 AM »
Why don't we simply launch dual mining with our own RandomX pool? If a lot of RandomX miners can be attracted to this first pool offering merged mining, then the pool fees may create a revenue stream for charity even without dipping into the BBP budget.

If you were for example, to start up a pool now with both RandomX and BBP, you would force your user to switch algos (meaning every hash would only count once), so its not very enticing.

If you mean, make a custom pool that supports merged mining using this new randomx-bbp-dual-mining-algo, then yes, that is exactly what Im proposing above already - a custom pool that supports dual mining and a new hashing algo in BBP.  And the pool collects revenue for charity from *XMR* hashes (not from BBP hashes).  The goal is to see if enough XMR can be collected so as to completely remove sell pressure off bbp permanently.  Later, poom could be phased out and percentages of the xmr liquidation directed to legacy charities by % etc.

In a nutshell another way to look at this is miners are donating electricity (because their household is already paying for it probably) to the pool, we convert the electricity dollars back to XMR and then further into charity dollars.  And the miners incentive in this scenario is that we give them *double* the hashpower that they would get alone (they get 5000 HPS from XMR alone, but from the BBP miner they get 9,500 hashpower).    ( I don't mean to create an argument here with anyone about basement miners :), what I am simply pointing out is yes, there are some hobby miners out there with 50K of equipment and who can afford $3K per month electric bills, but lets face it, there are probably 50,000 single machine teens out there with a nice fast machine, where the mom is paying the electric bill and the kid says, hey I can mine xmr and make $30 a month in my own personal savings account - sort of like their allowance - this I think is the source of at least half of the hashpower ).

It appears to be a win-win for everyone.  And of course that includes changing the miners hearts into more compassionate people.

EDIT:  And I just realized you might have mean, what if we use the plain-vanilla randomx algo, and start a randomx pool and accept solutions from either our miners or the randomx miners.  That would require two pool daemons, one on the height of the monero coin and one on the height of the bbp randomx chain.  Again, it would result in either miner making one hash for one coin (not two).  I think the heavenly difference above is the dual-hash algorithm that has to be added. 

1833
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 30, 2020, 04:02:17 PM »

Rob, all great points. Just some follow up questions...


1) Since Monero is anonymous digital cash, how does transparency work for donation to charity?


2) I'm confused by 10% charity aspect with XMR. Would the pools be able to mine enough XMR to equal 10% of the current BBP emission schedule?


3) xmrig and xmr-stak both have a dev fee where the miner hashes under the the dev address on a recurring schedule. Is this what you had in mind as well?


4) A pool could decline donation of XMR to charity?


5) Would the wallet or external miner be able to solo mine Monero & BBP as well?


1) Since Monero is anonymous digital cash, how does transparency work for donation to charity?

->  Yeah, this is a good point, but fortunately it doesn't look like it will be a showstopper.  Although I was hoping we could make this entire process a little easier (than running Monero full nodes and a dedicated accountability web site), but it is what it is.  If this ecosystem proves to be valuable then we can add Monero monitoring nodes.  Anyway, to answer the question, it appears to be possible in this way:  We would need to ensure each Pool owner adheres to a set of controls for each BBP transaction.  One, they would create a Monero keypair for their pool.  All *inbound* rewards would go the public address.  They would dump the public viewing key (viewkey public) for the pool and have it on the website, and our accountability report would track *revenue* from that key.  It says in Moneros docs, all inbound transactions can be monitored this way (but no outbound tx can be monitored).  Then we would need them to create a liquidation record (similar to how I do now for all compassion liquidations), which means we would see the Expense side as well.  It appears we would not lose any visibility by doing this. 

2) I'm confused by 10% charity aspect with XMR. Would the pools be able to mine enough XMR to equal 10% of the current BBP emission schedule?
->  There are different ways to measure the 10%.  If we are very specific, and say we currently spend 10% of all of our emitted coins for orphan-charity (meaning we raise 6 mil BBP coins per month worth $1,200 per month at current rates), or our mantra says We spend 10% of all heat-mined hashes on orphan-charity, yes on the surface a very keen accountant would realize that the latter could mean one of two different things.  One, if the heat reward in BBP only goes up to 50%, then obviously only 5% is going to charity (from the gross).  But thats not true if a dual-hash partnership increases mining activity from 100 miners (who spend a net total of $3K per month on electric) - if this program drives an increase in hashpower to 1000 miners, that spend a net total of $30,000 (1000 miners) per month, driving in a net charity benefit of $3,000 from hashpower alone (a 250% charity increase).  So, this I think is the impetus that opens up BBP to unlimited growth; basically we create the ecosystem, watch it first, and if this is the answer we can tweak our boilerplate message to something catchy.  I'm hoping that this equation, double the revenue for miners, a minimal loss in hashpower efficiency drives free PR in, and creates a scaling environment.  If we had more than 1,000 miners tithing 10% to orphan charity the program would be a success.  And although that isnt 10% of every emitted coin, thats still 10% to orphan charity from *two* heat mining sides (XMR + BBP).  So we also have the benefit of two communities hashing for a common cause.

3) xmrig and xmr-stak both have a dev fee where the miner hashes under the the dev address on a recurring schedule. Is this what you had in mind as well?
->  Id rather cover this offline.  I think we would want to raise bounties for the xmrig dev, and remove the donation in part to divert as much as possible to the orphan charity.  The miner should only lose the orphan charity hashes, and get everything else (100 dual hashes to bbp  and XMR, and 10 hashes goes to orphan-charity of those, and community tithes to xmrig with independent gifts).

4) A pool could decline donation of XMR to charity?
->  This has been my big concern today, and there is an answer.  In prod, if difficulty is < 512, or the block is late, any pool can mine the block (or solo).  If otoh, the block is not late and the diff > 512, we check our spork list of registered pools.  If the pool receive address is not in the sporks, that pool is not allowed to be hashed to.  I think we need to do this in order to install the trust score system for the pools.  As long as the pool stays in good standing (over a 90+ rating), meaning they have liquidated all the funds , and received all the funds according to our monthly report, they stay in the spork list.  They can be revoked if they fall below 90.  And if they are a homegrown self compiled pool they wont get listed, unless the community votes them in (through a sanc vote).


5) Would the wallet or external miner be able to solo mine Monero & BBP as well?
->  Yes sort of.  I think during the first 6 months, you will be able to solo mine,  and, I already thought of the issue where we must make it the same difficulty to dual-mine or solo-mine and that is solved.  There is absolutely no way to solo mine BBP faster than dual mining both XMR-BBP.  So that would be pointless.  And in order to implement #4, we need to add the spork-controls for pools.  So I think the answer is we leave solo mining open, until we need to enforce the sporks.  Once the sporks start going in then you cant solo mine a block in prod unless the diff is low (or the block is late).    I think we have to do this to prevent corruption.  Otoh, with the control enabled, we will certainly be able to track all revenue (as the address will be public, as to the income levels) and obviously we will see if it is spent on orphan-charity from the PDF receipts.  So this entire end-to-end appears solid so far.


1834
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 30, 2020, 03:04:58 PM »
And I was just thinking of one other side benefit of a Monero + BBP pair mining partnership:
We would probably end up being listed on a bigger Monero exchange, either for free or relatively easily due to the demand of the pair.

I'm liking this concept ...  Right now I'm still creating a proof of concept in a (solution project) in testnet to ensure everything works as expected.  So far so good.  There are a lot of humps, big humps, but nothing extremely bad or impossible.

For example, RandomX uses a lot of ram to review blocks.  Yes, there is a 256Meg mode, which is what Im using in biblepaycore right now.  So I'm solo mining with 4 threads and its taking up 2 gig of ram on my VM (a lot) and Im only mining at 150 HPS.  There is also a thread safety issue, which we have resolved.  There was also the problem of solving for an equation in BBP (vs the diff):  Solved.  Adding Blake256 to BBP: Solved.   Its a huge undertaking.  I still need to make my testnet pool, for the proof of concept and test out of client mining against the pool, and the dual hash.  So my goal is to make this work end-to-end by around the time the poll finishes, then if we have strong support Ill continue to make a release for testnet.

I'll answer the questions asap.


1835
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 29, 2020, 08:25:24 AM »
** RandomX - Potential - Solving most of BiblePays problems at once **

I was thinking of ideas involving RandomX revenue solving some of BBPs problems last night, all credit to Jesus of course.

It came to mind that being a decentralized charity, removing the sell pressure would be absolutely huge for us, and we might be able to accomplish this (and some other things all at once). 

Let us assume that we moved to a new model (phased in over a year, not at once).  Let us assume that all sell pressure for orphan-charity is placed on the XMR side (IE decentralized accounts exist that receive XMR donations from mining activity).  Our pools have trust levels, and are hired to liquidate the XMR once per month, and for example, spend the XMR on designated charities voted in by the sancs (IE, lets say Compassion, Cameroon One and Kairos for example).

Let us assume we : Remove the monthly charity budget (10%) and we give it back to the miners (to the POW side), we phase out POOM, and we give it back to the *POW HEAT MINING SIDE*  (which is also about 10% of our coin emissions).

Now that the POW reward has increased by more than 20%, we do the following:
We create a hybrid pool for XMR + BBP, and miners have an equal chance of solving both blocks independently at 95% efficiency.  However here is where it gets interesting.  The pool automatically places about 10% of the mining rewards on the XMR side into one XMR charity account address as people mine.

Then at the end of the month, the pool operator liquidates it, spend it on compassion, and possibly keeps the accountability info on the pool web site under a subdomain (and over time I will work on aggregating it to accountability.biblepay.org also for a more centralized report).

Also, we tackle decentralization:  The pool is opensource.  The operator is decentralized.  We install a trust monitor in BBP, so we can reconcile total XMR received vs spent, and verify 100% was spent on charity (per pool), and we apply this global seal of trust to each pool IE :  pool1 : 100% trust, pool 2: etc, and this level can fluctuate if the owner of the pool fails to :  Spend it on voted charity vendor, or Fails to collect it or liquidate it.  We can place the pool list and trust level somewhere on our main web site etc.

Now what we have theoretically done is removed *all* sell pressure from BBP.  At this point we would be free floating again (and without the 10% burden per month!).  And our governing mantra can stay the same:  10% spent on orphan-charity, without pulling in the budget.

We also tackle the decentralization of the DAC at the same time.  (On a side note, Ive been buying 3 character domain names, to potentially use in our future, for second and third branches of BBP that are rebranded- Im not talking about forking in any way, Im talking about having more than one coin with the same chain and two names; one name for a non-Christian and one name for a Christian;   IE   DEC.nnn and BIBLEPAY.org point to the same ticker on the exchange, BBP).

And this idea appears to support scalability as well.  If our core price rises, we would have more miners; more miners would mean more flowing over to the liquidation addresses...  Its interesting. 

And of course, with more miners, more investors would appear also (giving us the free PR we need).

As far as mining is concerned, the miner would just connect to the pool and have a chance at earning double.  The client software would automatically divert 10% of the heat-mined  hashes toward orphan-charity by hashing it on the XMR side (each pool would have a unique XMR address to care for).



1836
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 29, 2020, 08:03:06 AM »
It is hard for me to vote because I feel like I have incomplete information. I'm leaning toward option 3.


For now, Option 1 is not clear on how GPU & ASIC would be mitigated.


Option 2 while a cool endeavor, not sure how you secure the blockchain and work on this particular problem. If there's a numerical figure you can market periodically, then that becomes newsworthy. I also worry if GPUs can already do this and CPU crunching ends up being less useful?


Option 4 like talisman alluded too... I'm worried about not enough hashing power to really make a dent and any mined Monero will not be a meaningful sum for the amount of work you put in. Then there's the time you spend with maintenance (hard forks, keeping up with Monero tech updates, updating miner, updating pool) which may or may not be a huge timesuck.


Option 3, if I understand it correctly will have some useful work like BOINC (although its not clear what it is). The part that attracts me to it is the auto-upgrade. Is this something that self evolves in the algorithm? Or introduces some sort of randomness in each new block making it difficult for GPU to replicate in real-time but easier for CPUs? A self evolving and always changing algorithm would seem like a good way to mitigate GPU/ASIC and a set-it-and-forget-it type of algo. If the hash rate goes down with each iteration of the algo, then miner rewards can go up while still maintaining network security.


I'm open to voting on any 4 -- I just would like more thoughts on each option.
So on #1, POBH 3.0, from a succinct level, citing the work of others (for example, Frank Gennari - Univ of California), and all of the research I have done so far, points to only three overarching ways to control GPUs exec speed, from overtaking CPUs:  Random branching (like randomx), Memory bottlenecks (again randomx), and IO bottlenecks (most other attempts).  The reason POBH 1.0 failed was primarily due to the shared KJV bible (allowing the gpu lanes to refer to shared pointers).  And we hashed the verses verbatim.  So the first line of defense would be to create a version of the bible, for the miner, for the hash operation, sequentially with checkpoints.  The second would be to force the miner to write also to the bible (not just read).  These two things would knock out shared pointers.  Then adding the IO bottleneck would ensure the code stays on the CPU.  The IO bottleneck means we create a streaming operation first, containing a lot of non-deterministic data up front - that would require more work to move the stream of data to the gpu and calculate it and move it back for that single hash - than to calculate it on the fly in the cpu.

On #2, all I can say is we would have worked until we found one, and ran it until the wheels fell off.  Then worked to find another one.  Yes, its possible someone else solves the prize within a couple years and then we would be back at square 1 again.

On #3, This was actually my favorite before the randomx idea.  I planned on doing #1 anyway inside #3 as a PART A.  Part B would have been something like CFD, but with an auto upgrade.  And a way to keep this fork proof (a fork virtualizer), meaning our algo could change over time.  In this case, what would prevent it from gpu and cpu would be the reliance on .netcore, which is way too big to run on a gpu, and using random branching (and since part a would contain the io bottlneck, that too). 

On #4, Im of a completely different opinion on this I believe.  Although I am worried about Monero making frequent changes, the positive thing is they would be tested by their devs (this is sort of an expansion of developer abilities, which we do need since we have a small IT dept), and they would be checked in a way where we can pull them in.  Also, we would have our own branch (we have to for stability), so we could theoretically choose to stay on the old algo.   So yes its a growing pain, but it might not be a net time-hog compared to #1,2,3 - especially since we would be *expanding* our total dev contribution (lets say with 1-3 we have 2 devs, with #4, we have 14 devs, etc).  On the dent in hashpower, I actually think the hashpower influx would be large, increasing security- its a bonus to have 1000 or so miners adding to our security level, I believe.




1837
Archived Proposals / Re: BiblePay Future Hash Algorithm for CPUs
« on: January 28, 2020, 09:53:07 AM »
Options 2 and 4 are both very appealing; but I am leaning towards Option 4 (hence my current vote).

Science is good, I love it. Yet we currently are covering enough of that with PODC, I believe.

RandomX will definitely provide us with a lot of exposure at this stage. Monero network hash rate soared from 800 MH/s to 1.2 GH/s in a month - this corresponds to several hundred thousand cpus running RandomX, even if some of them are latest Ryzen 9s. In most parts of the world, a typical 5-year-old cpu is barely breaking even at current network hashrate. Those miners would simply jump over a side benefit such as merged mining of BBP, once they are made aware.

If I am right in the sentence above, then we would see a huge spike in difficulty of BBP POW - old timers or hobby miners may kiss their BBP rewards good bye. This needs to be prevented, imho.

Another concern I have is the flippers: many of those RandomX miners that start mining BBP will prefer to liquidate BBP first, to cover some of their expenses. Remember when we could earn Obyte, Neumannium and a couple others on the side last year with PODC? I doubt anyone kept, say, their Neumanniums :)

I believe this possibility has to be taken into account (better ready than sorry, right?). The only precaution I can think of is incentivising hodling of BBP (or soft-penalising of liquidation). Coin*age requirement as in the ABN times, or proportional PODC RAC requirement for POW rewards, or even fiat donations to charity required for POW rewards, you name it. People that have to pay up front for a reward will be less likely to sell it at any cost (which kills the market).

These are all great points.  However I even question my own logic (about the degree we should try to control the general public and free influx of mining activity) after working on the DSS model.  Although, your good point (about losing the ability to hobby mine BBP, and diff going through the roof) etc.  I think when we did have the problem of popularity in the beginning, we didn't take into account the value of the popularity - we only made the assumption the miners were selling 'golden bbp coins'.  Now of course with more experience, I see that we must regard the PR side (popularity, spreading the word) as equally important to prevent our project from dying and give us word of mouth to grow.

So that part of the equation would be:  Do we value a high difficulty and massive influx of miners and popularity more than losing the hobbyist?  I would say mostly yes, because as the total miner count rises, the net total reward of "BBP+XRP" must be able to support the mining activity. Another words there must be a reverse arb here, where a skyrocketing diff and massive influx of miners actually draws the price of BBP higher (because of the ability to sell XRP and hold BBP also).  Anyway, Im leaning towards the belief that we want the highest difficulty possible, and the most miners possible, to receive the most free PR possible.  This would simply mean a higher price for BBP equals the same reward per miner (with more miners). 

But I am not against installing some type of softer 'botnet' prevention mechanism to protect BBP, although what I am trying to avoid is anything that pollutes the ability to mine bbp without adding squirrely rules or fork risk.  Another words, ABN requires a massive amount of custom code in every pool and makes us a one off again.  Since the only possible way to mine dual bbp+xrp is through the pool, what we may be able to do is require miners to have N balance in order to mine.  The pool could potentially check the miners BBP balance.  For example if < 100,000 (on the public key) the pool disconnects.  That would require them to solo mine.  Since the new dual miner will only dual mine with an XRP+BBP pool, it would make it harder to get around that rule. 

So at this point lets try to assume what would happen.  If the word got out that you could dual mine, as you say, 10,000 miners would try to heat mine, driving up our diff.  If our price does not rise some will leave.  It will end at an equilibrium that covers the cost of mining.  If we require a balance in the mining key of 100,000 we would limit the influx, but potentially drive up our price as they come on board.

Im not completely sure which pair would be sold, I agree however that if the project has no future, and the price is > XRP per KWH, BBP would be sold.  But we are the ones with the Sancs, so I feel that it is enticing to hold the BBP side and sell XRP.  But as we know this is unpredictable.  We just need to make our project more enticing, with real features and service on top of RandomX.  (To make the sell side less appealing etc).


1838
Archived Proposals / BiblePay Future Hash Algorithm for CPUs
« on: January 26, 2020, 10:09:36 AM »
Option 1 - POBH 3.0:  This means we would rewrite POBH (which has the 31,000 verses of the bible) in a way that would run slower in a GPU (than on a CPU) and be very unlikely to work on an ASIC in the future.  This appears to be possible by using .netcore's polymorphism, branching, and large initial required data streams.  In a nutshell it would take more work to move the inital calculated stream to a GPU than to perform the operation on the CPU.  The CPU is also the only way to execute the dotnetcore commands.

Option 2 - Math Prize:  Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example.  One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th).  https://www.claymath.org/millennium-problems/riemann-hypothesis

Option 3 - Useful Work:  This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades.  And the code would perform some type of useful work; similar to what is done in boinc projects.  We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended). 

Option 4 - RandomX and dual revenue streams for the miner:  The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner.  We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. )  This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance.  However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also.  This would provide a dual revenue stream for the miner.  Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue.  This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP.  The theoretical algorithm we would use is :  X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock).  Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX.  It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).   


1839
Archived Proposals / BiblePay as a Global Charity Agent
« on: January 14, 2020, 05:52:10 PM »
This is an idea for a real world use-case for BiblePay.  Continuing the discussion on 'dimensions of a crypto' we have established that (https://wiki.biblepay.org/Dimensions) (if given 3 dimensions: Mining,  Innovation, real-world-use-cases), we score high on Mining (PODC), high on Innovation (Dashpay etc), and low on real-world use cases.

This idea involves either being a charity broker, or a charity agent.  Similar to the way a transistor works, we would 'enable' a charitable transaction - also by providing a reward back to the donor.  This would be the reason a donor would choose BBP over going directly to the charity.

Why would BBP be favorable?  We could constantly aggregate charities providing the 'best deal' in a web resource constantly updated.  For instance, lets say Korean orphans are in desperate need, and the orphanage offers a 30% discount.  Or, if we have matching funds available.  And, with corporate matches, and partnerships we may create a partnership discount.  Also we have platform fees charged by the big leagues (9%) plus transaction fees (3%), and all of this adds up to a huge amount of overhead.  The big leagues pay serious money to vet charities.  We can leverage this by downloading charity research for vetted orgs, and keep this in the folder for the org, and only partner with vetted orgs.  This will also save BBP all of the expenses (in vetting) - if we require pre-vetted orgs vetted by third parties with recent reports.

Looking at Charity, this is a huge untapped market in global finance.  We are obviously not tapped in any way, as the American charity donations are $390 billion annually, and global cause is over a trillion $.    Therefore this is a real world endeavor, so lets set our sights higher.

Let us create use cases for this feature.

In the current scenario (POOM), we match a miner with a charity.  Currently, we spend 10% of our blockchain emissions on charity.  But, we don't attempt to negotiate any discount with our charities, we spend the retail amount ($40 per child).  And this is technically not what I'm suggesting (I do not want to slim down the profit), I simply want to create a competitive market.  What we can do is ask each new charity partner as they are vetted, to offer us a  5-10% networking fee to be approved for the account - this would end up resulting in pooled rewards for the donor  (see below) - let us call this "Discount appeal A".

Next, there are many, many examples in the corporate world of companies that match employee donations.  Sometimes 2, 3, 4 or 5* the match is available.  We need to reach out for a pilot company, and design a flow that would allow an employee to sponsor a child, and facilitate the match. 

Next, there are real world examples - constant examples of 'matched funds' available at companies such as globalgiving.  I myself have sponsored over 10 kids last year with a match (that helped 20 kids), and, once through CARE, utilized the match of a NYC donor to double my CARE contribution.  We need to locate and partner with the match.  We can use the Match funds to offer a discount on the 'available charity for donation list' page - and this will be very enticing when a user is deciding to give through us (to see a 50% match, or 50% discount on the list).

Next, there is a platform fee of roughly 8%-9% charged by companies like GlobalGiving (and also a 3% network processing fee), for every donation!  This is huge.  (https://www.globalgiving.org/aboutus/fee/) .  This means $1000 given through globalgiving actually is reduced by 12% ($120) for a net receipt to the charity of 880$!  This point is one of the biggest points here.  This means, we can appeal directly to a vetted charity, receive a network-fee discount in our negotiation of new partnership (from point A above) - to broker the transaction.

This 5-10% total discount would entice the user to give through us (instead of going through globalgiving).  Because when we list each row, we will list the BBP reward available.  Then, we give the donor a refund in BBP, at the applicable % negotiated (creating a competetitive environment for new givers).
This gives the user 3 reasons to choose us :  Donating to causes with matches, donating with programs with discounts, bbp-reward back.

Real World Example:

We partner with Cameroon-One, Compassion, and Korean-Children Institute.  Cameroon-One negotiates a 5% discount with us, Compassion 5%, and Korean 10%.  This means right off the bat, Cameroon-One drops to $38 per child (because they are looking for partnershps and quantity), while if you go directly through cameroon, you pay $40. 

Next, we locate a charitable match partner (IE the same one globalgiving uses in NY).  They usually offer a match to the 501c3 for proof of a donation.  Then we apply this to our advertising page:

Cameroon-one     $38        With Match $19.00     
Compassion           $36         With Match $18.00

Note that what would happen is an inbound donor would choose an amount of the donation, say $380, and pick Cameroon-One.
We would automatically apply the match, and donate $760 to cameroon-one.  However, cameroon-one would pay a network fee of 5% (or $38) and this would go back to the donor in the form of BBP (not fiat).  Additionally, we could also pay a percentage of our charity budget for this transaction as an additional reward (of between 1-10% see chart based on price), however this additional reward would be capped at no more than 1% per donation of our total budget (IE if we have $2000 available, only a max of $20 could be paid in this additional bonus).  So lets say the BBP price is still on the chart level where 2% is being paid for rewards, then $15.60 additional in BBP would be added.   So this donor would receive $15.60+$39=$54.60 reward in the form of BBP (our coin would not keep the profit).  A random sanctuary would facilitate the transaction (IE document it and enter it in and execute it).  This would also be tax deductible, as the payments would go directly from the donor to the charity, and BBP would extract proof-of-transaction, and save the data so we can give real world credit for this on our web site etc.


Proposed Price breaks table :
BBP Price                   Charitable Expense Amount (And Governance emission amount)
.01+                             10% to charity (100% from superblock)
.005                              7% to charity (70% of superblock)
.001                             5% to charity (50% of superblock)
.0005                           2.5% charity (25% of superblock)
.0001                           1% to charity (10% of our superblock is emitted)

This table can be refined later, but it shows that we start to limit our payroll, IT expenses, superblock payments, and charity payments down to the governed table emission level while our price is low.  So only 2.5% goes to charity while our price is .0005.  However, we give the full 10% after our price exceeds .01.

So, as a bridge for POOM if we did this, we would sign up partners well in advance, negotiate deals, test in testnet, then we would want to convert POOM back over to donor->charity individual transactions; IE children would be removed from POOM, but left in the hands of the current sponsors for individual transitioning.  The hope would be during the go live we would have at least one match available to make this transition easier (as then the price would be lower to continue those children).

Note that I feel that if we did all this we would also need a 'legacy' page for classic type orphan charity, like we had in the beginning.  For example suppose we have half of our budget available.  We could by default, allow a user to sponsor an ongoing child for N months with no hassle.  So we would have both transaction lists of agent assisted transactions and lists of sponsored orphans sourced from our overflow funds.

Im thinking we would break out the fiat / crypto into two distinct services and offer both.
Fiat transactions would work like stated above.

But we should have a "donate" process for Crypto also.
We could pilot that with our orgs that already accept crypto (as it would get very tricky to make a crypto gateway available and force a sanctuary to liquidate funds, or lose their santuary if they did not perform).

Let me show an example:

Lets assume out of 10 charities, 5 will accept BBP+BTC.  We mark these 5 as crypto enabled.
We would want the transaction to be sent from the donor directly to the charity in crypto.
Then the charity would as usual send the network fee later back to us to disperse to our user.

What I'm wondering is, will this be used by the world if we make a brand new dedicated web site for this?

I'm a little more optimistic about this than some of our previous ideas.

Additionally, this entire idea seems to completely remove sell pressure from us as a coin.
All donor payments go directly to our charities in gross dollars, they receive a fat discount back for doing it.

The donations are tax deductible because they send To 501c3 enable charities.

One interesting thing that might happen in the case of a rich donor who has $1 billion to spend, lets say Trump decides to give $1 million to Cameroon-One.
This would cause Cameroon-One to send $50,000 in BBP back to Trump.  This is interesting because they would need to buy the bbp to send it.  Our governance emission would be $20 for this tx. 



Edit:  Another element I want to add, is ensuring our emission schedule completely matches our
target schedule here:
https://wiki.biblepay.org/Emission_Schedule
So what this means is I propose we tweak our internal deflation rate target to exactly match the Dec 2020
 target emission amount.  This is not a lot, or a major change to the deflation % level, but we have emitted about 100 million extra coins as of the current date and I feel we should shore this up for our Q3 2020 mandatory - we would end up increasing the deflation from 20.04% to something like 21% for example (after running the calculation).


And finally on an unrelated note, I will need to add a different thread for this subject:  Slightly modifying the POBH internal miner.  Things are pretty good right now.  But I believe God wants it perfect (the issue I have with this is "fair weights and balances").  I dont like how we ended up with a 75% mining speed for the solo miners in the core wallet and an increase in speed in the external miner.  So, I will open a separate thread to discuss this.  I mention it because it could be hampering our heavenly backing.  So that makes it important...

And finally one more point I forgot to mention: Globalgiving.  According to their financials they are bringing in $400 million per year of donations (and charging 8% fees on those, to handle those).  What we would do is analyze the top 100 charities, create folders and vet them, and then go to make deals with them, for discounts (this is the amount in BBP the reward will be for).  Then we expose them on a new web site ranked by the deal.  Then we make Donate buttons for our donors.  Then we add the sanc facilitation process.  And the refund process.  And the matching donor partnership and deal and flow.  And in the end the hopes would be browsers from the real world would flow over to us because they stand to gain a rebate of 6% if they give through BBP, and they get to accumulate BBP (crypto exposure).




1840
Archived Proposals / Nov 2019 payroll
« on: December 20, 2019, 07:02:46 PM »
Program PODC 2.0.
Program Kairos integration.
Fix bugs in new development in testnet branch.

Commits on Dec 8, 2019
BiblePay …

@biblepay
biblepay committed 12 days ago
 
Commits on Nov 30, 2019
BiblePay …

@biblepay
biblepay committed 20 days ago
 
Commits on Nov 27, 2019
1.4.8.2 - BiblePay …

@biblepay
biblepay committed 23 days ago
 
Commits on Nov 24, 2019
BiblePay - TestNet …

@biblepay
biblepay committed 26 days ago


Commits on Nov 23, 2019
BiblePay …

@biblepay
biblepay committed 27 days ago
 
Commits on Nov 21, 2019
1.4.7.8c-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed 29 days ago
 
1.4.7.8b-Mandatory Upgrade for Entire TestNet …

@biblepay
biblepay committed 29 days ago
 
BiblePay …

@biblepay
biblepay committed 29 days ago
 
[v0.14.0.x] Update release notes with change log (dashpay#3213)

 
Merge pull request dashpay#3202 from codablock/pr_v14_backports …
 
Commits on Nov 20, 2019
1.4.7.7 - Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on Nov 20
 
BiblePay - TestNet …

@biblepay
biblepay committed on Nov 20
 


Capping @ 3mil due to our low price.


1841
Alright guys, thank you all for testing!

On behalf of BiblePay, and myself, we really appreciate all the help.

We're going to wrap this phase up.  From what I can see, everything is working OK.  Hopefully we won't have many surprises in prod-- and if we do, may they be cosmetic or very small issues that can be fixed with a leisure release.

At this point, I will start preparing a production release.

May Jesus be with us going forward!  And all Praise to Jesus for the knowledge and wisdom we have received up to this point in our project.

May you all have Jesus as your Lord and Savior.


1842
Yes leave it down until it is pose_banned and then revive it.

Aha!  You are getting Pose'd now :).


So its working, yay.  Btw, I revived mine an hour ago and Im back to 0, so that is working pretty good.


1843
I have my VPS on but not in sanc mode (collateral still not spent)

Code: [Select]
ifconfig -a ens160 | grep inet
       inet 45.62.239.200  netmask 255.255.255.0  broadcast 45.62.239.255

sanc status
error code: -32603
error message:
This is not a masternode

I had this Condition since yesterday but it is still ENABLED on the sanc list

Code: [Select]
>sanc list full
(Last line is this particular sanc)

{
 "a46074dac98333269341fee5b712f795fdeaa615b276fee12175e1c537ce8a43-1": "           ENABLED yVfoZ676zm9bjmU5qXbNe9TkGsHAxFYrDg 1576191507  21620 155.138.228.109:8003",
 "efbe80743321967f9d94b124b6670e3d87492e711f34acbe6fdada608007e055-0": "       POSE_BANNED yMFgidsw7EgVRfTwFU1hPWLmrPYcT1Bq7s 1576145873  21513 155.138.228.109:8002",
 "24ba631e105c9f1d1923fe32d9c534e51556cddb15f625a5c42d5c902c868583-1": "           ENABLED yTwJA2VCYQWpWXH8HS7UvEpqRE3Aj5ciUV 1576191075  21618 104.167.116.179:8080",
 "7570652f63502f29b610c4bf134f3d1d589c970c383b20a88545cd683c802130-1": "           ENABLED yXhRHuA2YsV44K5VZJyQSxZurQ8s7diKbq 1576191197  21619 45.62.240.90:40001",
 "7c30c4cf73a81ce8ebb90b3cd6bcda3c279d86fb044605b3f95f75a1657cd19e-1": "       POSE_BANNED yZ6pvVMxJ8qXE15J6sPssG83FE5wkSik3N 1575350464  19686 155.138.220.139:40001",
 "c49f6f1e8fc8829b048abc37e790f4d6fc6364e05b9c433b77838ba575c15477-0": "           ENABLED yQQyE4Wv7hTvxQxCYAJQHJ3RYqp7p8ZM1U 1576192130  21621 155.138.228.109:40001",
 "05a42edd711c8225b6febc0a422a0c8308dbd700d5ebd3b8af00571c7c5870d3-1": "           ENABLED yXVCXKxDAwV6QVD1aQG1BZbh6uTCTSJBHw 1576191014  21617 45.62.239.200:40001"
}

Is that a problem?

Luckily Ive had my dev testnet node running for a couple days and I have you in my log;  It looks from my perspective we didnt see 239.200 as violating the rules for chainlocks or quorums until the last 4 hours ago:
2019-12-11 18:59:37 ERROR: AcceptBlockHeader: prev block ad556b39a713420cc879b19957c5080d19e4bed18d2fc3bdda2eca778c9617a1 conflicts with chainlock
2019-12-11 18:59:37 Misbehaving: 45.62.239.200:40001 peer=498 (70 -> 80)

I'm pretty confident your node will get POSE banned over the next 24 hours now that it is not in the quorums.  My sanc 228.109 is pose banned right now.  Ill go and try to revive it.

From what I know you have to violate the longer quorum (24 hours) before you start getting banned (or violate a chainlocks rule), then each of our sancs will vote you to 33% banned, then more and more etc.

But I believe its set up to pose ban with pretty solid decisions as no sanc can fake an LLMQ round.

Do you want to leave it down a little longer?




1844
All,

Since we need a full 14 day notice for the go live we are going to need to wrap up testing really really soon!

I have been testing prod successfully and last night I made it through the superblock (GSC height) without forking.

Can anyone think of anything mission critical that needs to be added to this branch?  Please, asap if you can think of anything.

I think we only have time for max one more test release, if that, and hopefully, we won't need that either, as things appear to be working.

We do need to add the Kairos sporks to mainnet, but we can do that at cutover time so that Cameroon one works with the legacy sancs up til Dec 24th.


1845
Is this supposed to mean 99% of coin age? Would it be difficult to include a comparison?


Currently, you will approximately receive xx% of your PoDC reward.


For 100% PoDC reward, you will need:
Team BiblePay: xxx BBP
Non-Team BiblePay: xxx BBP




07:07:48 sendgscc wcg
07:07:48
{
  "Warning!": "WARNING!  PODC is using 0.99% of your coin age.  This means your RAC may be reduced, resulting in a lower PODC reward. ",
  "Results": true
}


Yeah, that would be pretty nice to show the user.

Ill look at this now.


Pages: 1 ... 116 117 118 119 120 121 122 [123] 124 125 126 127 128 129 130 ... 263