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] 2 3 4 5 6 7 8 ... 152
1
Pre-Proposal Discussion / 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).   


2
Sanctuary Discussions / Re: Bug Bounty Program
« on: January 23, 2020, 09:04:54 AM »

https://github.com/marcinot/cpuminer


https://chainz.cryptoid.info/bbp/address.dws?B4uXbFxUc7mo6yyffuNda1HoyGgvqWH1yC.htm


I noticed he's been around a long time. He was mining when ABN was fluctuating from 85k 125k 250k etc.

Yeah, he did send me the link to his code, but I asked him to make a post here (with it) and comment about how it works, so we can open a line of communication with him - and facilitate the bounty.  And, I haven't heard back from him after that reply.

I didn't know he was around that long.  I'm just very happy to see 2K diff again. 

It would be nice to get his opinion on future miner consulting issues on some advanced topics, especially since he has earned some consulting fees already - apparently.


3
Sanctuary Discussions / Re: Bug Bounty Program
« on: January 21, 2020, 09:22:42 AM »
Apparently Marcino has successfully ported POBH 1.0 to a GPU.  We are just waiting for him to post his code and summary of how it works.  Then we will review and to my knowledge the bug bounty will be paid.

Then we will reinstantiate a new bug bounty for POBH 2.0 while we create our next-gen miner.


4
Production Proposals / Re: 1 MILLION BIBLEPAY PODC GIVEAWAY
« on: January 19, 2020, 09:24:46 AM »
Ive spread the giveaway here so far:

Bitcointalk Forum - Altcoin Mining - Best CPU Mineable Coins
https://bitcointalk.org/index.php?topic=2683343.msg53525535#msg53525535

World Community Grid Forum:
https://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,41236

=

Could someone else help post in the BOINC forum?
https://boinc.berkeley.edu/forum_thread.php?id=13351#94603

BOINC Reddit
(NOTE: Tried to post here previously but moderators deleted it)
https://www.reddit.com/r/BOINC/comments/ehtl2a/biblepay_bbp_rewards_coins_to_world_community/

=

I just found that theres a BOINC Stats forum
https://www.boincstats.com/forum

Which subsection is a good place to post?
BOINCstats: BOINCstats general
BOINC: BOINC
Team Talk: Chatter, Invites

=

Are there any other good places to spread PODC?
Still on my TODO list to tweet it out, will do soon

Thats awesome Togo, thanks.


5
Production Proposals / Jan 2020 POBH and Integrity update
« on: January 19, 2020, 09:04:03 AM »
This proposal seeks authorization to make the changes necessary to release an emergency update to fix POBH.  As it was recently reported that Marcino ported POBH into a GPU.

This proposal seeks to change and clarify the following items:

- We will add a nonce limit for POBH hashing to limit the hasher to 256 hashes per second per miner.  This can be enforced, because the block start time is known in a hard way, and the last block time is known in a hard way.  Additionally, we enforce that the only field the miner can change is the nonce and start timestamp, and any other field that is changed results in a new block being created (and this requires many calculations for chainlocks, llmq, transaction lists, and recalculation of the merkleroot). 
    *** NOTE :  We will not limit CPU mining to 256 HPS, however.  When the miner is faster, the miner will create more blocks per minute.   Automatically.  ***
- It is a given that recalculating the merkle root requires more work than calculating more POBH hashes.
- Therefore the conclusion is that this interim release will remove the GPU risk from our POBH algorithm.
- We will still work on the next generation miner after this release, therefore this is a temporary stopgap for POBH to keep it running in a quality fashion.
- We seek to    shore up our emission deflation rate to match the target emission as of Dec 2020 (http://wiki.biblepay.org/Emission_Schedule).  This means we will for the time being increase our deflation rate to .0216 aiming to match the year end emission target.  We will monitor the situation afterwards and if necessary put it back to .0167 when the target is met (in a future mandatory).  In summary we are increasing our deflation rate to ensure we emit the exact proper amount of coins in total from inception until Dec 2020. 
- We seek to fix DWS.  This requires two changes:  At the mandatory cutover height, installing new rules that increase the sensitivity of the DWU reward.  This first change ensures that as burns take place, the wallet decreases the DWU quicker (saving more of the kitty for the next user).  Additionally we seek to reduce the maximum DWU to 35% of the original design (making more available to each individual user).  To accomplish this we must also adjust the DWS emissions to match the target emission schedule (4mm per month deflating starting in 2020).  The good news is DWS phase 1 had too low of an emission set-up so this is not really an issue - it means correcting the parameter to the intended value.
We will monitor DWS emissions - and ensure globally, DWS does not materially change the total emission schedule picture.  The goal is to flush out DWS phase 1 payments, allow Phase 2 to be established and ensure all factors are correct at the end of this year - and if necessary adjust the final DWS emissions level in the Sept-Dec 2020 mandatory to match our global emission schedule and DWS schedule as outlined in the prior point.
- Update the investors on the total orphan portfolio along with what is available at compassion.  Since we technically still have compassion funds, we are still above 100 orphans per month; but we need to be clearer.
- Clarify our stance on what the DAC and Biblepay charity agent proposal is, and that it is not expected to effect our charity emission level.  Clarify that our charity emission level target is still, and is expected to be 10% per month.  Clarify the complete idea - to explain that we do not veer from launch params and
 how we seek to continually work in integrity.




 
      

6
Pre-Proposal Discussion / 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).




7
Production Proposals / 1 MILLION BIBLEPAY PODC GIVEAWAY
« on: January 01, 2020, 08:16:10 PM »
** 1 Million BiblePay PODC Giveaway **


Terms and conditions:

- You must be an existing PODC researcher, in the biblepay leaderboard as of January 31st, 2020
- You must be contributing to research in World Community Grid
- You must have more than 100 RAC (recent average credit)

Mechanics of picking the winner:
- At block height 173307 we will take the first 4 hex-characters of the blockhash,  equaling 1-65535 (A).  Let B = 65535 / (count of superblock researchers in the prior superblock).  Let C = A / B.  C equals the (ordinal of) the winner (by counting from left to right through the last GSC contract prior to 173307).



8
there's no need to rush into deals. if they want to offer a high pressure deal, then walk away or negotiate on your own terms. a wise decision can't be rushed.

I'm doing what I can to make up for it.  I'm speaking to a few top 30 exchanges now, and if we can list BBP for a fee in BTC Ill just pay for it out of my pocket to help balance this deal.


9
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.


10
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.


11
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.


12
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?




13
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.


14
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.


15
I will reach you tomorrow so we can do some tests with private send on testnet.

Thanks, this will help sooo much.


Pages: [1] 2 3 4 5 6 7 8 ... 152