They still use it at the current height:
https://github.com/dashpay/dash/blob/master/src/validation.cpp#L1164

They have a cap on the reward of 25 dash, so it could be hitting the cap and appear not to be there, but for us its a lot easier to see the effects.

Although it makes the emission a little harder to predict, it also gives us some peace & security to know that if we are ever attacked the reward goes down.  I think there is also a benefit for the bigger holders, to know there is a conservative side to the expenses.   I don't think we've achieved the broad user base yet however, to see the fruits of our labor.

I think we are finally going places.

I just bought a $5 Walmart gift card from the biblepaycore wallet, using DASH in less than 30 seconds.

The checkout flow was perfect and fluid!

- I added the $5 walmart card to the cart on bitrefill.com, and used rob@biblepay.org as my address
- I typed the command below in the wallet
- The IX tx immediately updated on my browser
- I printed out my walmart scannable gift card on my printer

The whole process took about 60 seconds.


19:38:45

dashpay XmLErbCvJ5ZLGrZL5JYjcjWabd6jnZbfNA .131850 1


19:38:49

{
  "DASH/USD_Price": 44.94753732084484,
  "BBP/USD_Price": 0.0001886863324875,
  "USD Amount Required": 5.92408541888735,
  "dashpay-txid": "bbfcc8908bd9077f8ec3aab0c2998f96ca6ca4f553b7cfc5dd3334d0e24eede9",
  "BBP Amount being spent": 31396.47
}



Now, its time for us to put this in the wallet.

May God protect BiblePay through this complete integration.


The goal is to have this feature in Alpha for Christmas!

PS - The markup on the entire process was only .70 cents!
(This will be even cheaper in prod, with higher denoms).

"Does Dark Gravity Wave (DGW) change the rewards or is that a BiblePay thing?"

-> DGW is just a 'cooler' retarget mechanism than Bitcoins.  It was created in the spirit that tried to stop the hash bully that was taking advantage of small altcoins.
Dash (and Us) change the reward subsidy based on the DGW difficulty, with the lower reward per higher diff.  The logic is if we get attacked with a successful amount of high hashpower they will receive diminishing rewards during the attack.

"Can the regular wallet mine on the NOMP pools? or is external miner still needed?"
->  The core wallet can solo mine, but it cannot connect to NOMP pools.  This is primarily because we don't have STRATUM in the core wallet (as that would violate the exchange covenant and add in the 'virus' warning).  However note that I do have a side project with a workaround, coming before the end of Q3 2020.  We will write a STRATUM connector in dotnet that won't violate the exchange convent, and I believe we will have the core call through that to nomp, to allow pool mining from biblepaycore.  We will also speed up the core wallet to make it equal to the external miner at the same time.  (Its currently at 90% speed as compared to the external miner).

Correct, the code was supposed to be compatible until the cutover height; there is no flaw in the code.
In addition it was written so to remain compatible even with the upgraded sancs.

However there is a DASH rule, where once 60% upgrade to the new governance protoversion, the old governance protoversion is no longer respected.

So, I believe this is a unique case, because we had a mandatory for the gov-protoversion to increase at the same time the wallet version increased.

If this ever comes up again, we will say:  "By the height" or "when 60% of the sancs upgrade" whichever comes sooner- and we will have to monitor the progress.

Can you please try upgrading next?  Ive already upgraded my sancs and home node, and the exchanges have upgraded, so at this point it would be counterproductive for me to downgrade just to see if they are on a fork.  We can ask others, if anyone else is running the old version if they are going on a fork?

Whats very possible is that once 51% of the sancs moved to the new version (70750), it probably became the defacto.  You can see if your 'exec health' disagrees on the old version with the new version, but I just recommend upgrading now.

Btw, I plan on enabling Kairos later today, so please watch so we can start sponsoring after that.  As I feel we will have a lot to do starting tomorrow to roll out WCG.  I plan on enabling WCG tomorrow.

Yeah, it seems like one of the exciting ones.  It sort of Trumps some of the things Ive been working on (trying to integrate with the best buy API).

Give me a little time to try to explain the IX to IX conversion.  I'm going to work on this next.

Also, I've got to share the idea about becoming a decentralized online church.

** Solid Use-Case - Dash IX through BBP IX **

So, I stumbled across this site yesterday:  https://www.bitrefill.com/
They had high reviews from Dash, from people who were buying digital gift cards (these are sent directly to your e-mail box, and then you can buy whatever you want once you have that).

So, the idea here is the Dash, with its millions of $ of integration already completed, already has a massive amount of support in almost every area, buying gift cards, physical products, delivering physical products etc.  

In light of that, our most straightforward and useful feature would be a method to instantly send a DASH instantsend transaction to a recipient from the BBP wallet (using BBP funds via instantsend).

It would work like this.  Take bitrefill for example, they sell an amazon $20 gift card that is delivered in 1 minute to your email address.  You browse, and buy it and select "Dash" as the payment method.  A screen appears asking to send DASH to the DASH receive address.  At this point you have 15 mins to get into dash and send the funds.  Once you send the funds, the e-delivery occurs within 1 minute to your inbox.

So what we want to do, is provide an rpc command, something like "dashpay receiveaddress amount".  What we will do is send the amount in DASH to the DASH receive address, via instant send.   (The command will return a DASH transactionID.  Then you can track the transactionid (If necessary) via the Dash BX).    Theoretically, this would allow any BBP user to make an instant purchase and then we would be instantly as useful as dash.  Of crouse, we will need to put an initial limit on this for safety (IE $25 per transaction).  I believe this is theoretically possible, using instantsend, by requiring a lock on the transaction from a masternode.  (IE we can safely relay the funds out to the recipient, and not worry about a double spend, as long as our advanced checks pass - etc).

Ill look into this feature next.  This sounds like it would theoretically plug most of the hole in BBP's dimension doc.  We can consider Dash our big brother.  

Ok, Childrens inbound letters have been migrated to:

https://web.biblepay.org

Orphans | Orphan Inbound Letters

As usual, you can also search by typing a phrase in the upper right search box.

Looking at the Mandatory upgrade post, the cutover height is not until 166075.

I mentioned the other day that we would be adding the orphan list and orphan collage to dsql (the post is missing on bitcointalk).

We have added the orphan list and orphan collage to DSQL.
We also added SEO to DSQL.

Therefore google can now spider DSQL.

Once we see this in the google cache, then we can test to see if our traffic increases.

** The integrity of Biblepay has always been in good standing **


We have receive 2,742 pages of inbound letters, written by our sponsored children to BIBLEPAY.

Obviously, anyone who has ever accused us of sponsoring false children is a false accuser.

In the spirit of providing transparency I will migrate all these letters over to BMS next so we can quickly leaf through them.  And of course, I don't want us to lose these precious letters that took time for each child to write.

Another way to 'provably' complete the equation that we sponsored a child for N duration is to tie the inbound letter to the hex-id code and randomly check for a childs inbound letter in the future.

Yeah, diff is still 177,000.

I don't see any signs of it.

** BIBLEPAY DIMENSIONS **

This is one area I feel we will need to spearhead a new project to dedicate ourselves to finding the 'solid use case' for BiblePay, to achieve a 100% score on the first dimension:

https://wiki.biblepay.org/Dimensions


I'm now in the process of creating a new Use cases document and an online Todo list.  The Todo list simply shows items dynamically that IT is working on - things that are happening that didn't fit the github list.  

The Use Cases list will attempt to show all of the potential paths, but of course some will be blocked due to impossible challenges, resource availability, and partner failures.  But I am confident that we will zero in on some excellent ones that will not only be possible but will be become a reality for BiblePay.  

Thanks, I also noticed those matrices were valuable in conveying complicated gospel topics, especially where they are debatable.
I made one recently for the Rapture, which I haven't posted yet:

https://wiki.biblepay.org/Rapture_Study

Notice how much clarity you can add when you balance the viewpoint either way. 


I will circle back and edit the Nutritional Guide asap with our new features, but first I promised to release information on:  BiblePay dimensions, todo list, use-cases and short-term goals (BestBuy and Direct Mail and greeting cards, direct mail letters from the rpc, etc).

Nice!  This explains a lot to the user.

Andy sent these pics and videos over (of the Christmas Party):

https://pool.biblepay.org/SAN/Mission/Kairos/Kairos1/20191218_151157.mp4
https://pool.biblepay.org/SAN/Mission/Kairos/Kairos1/20191218_152409.jpg
https://pool.biblepay.org/SAN/Mission/Kairos/Kairos1/20191218_153433.jpg

She has us on the projector at the conference!?  Thats very cool.

I'm glad to see what we're doing is not in vain.

God has a master plan....

Thanks, yeah, we need to write a tool to do this because the votes would take years.

** Nomp.biblepay.org will be down for 20 minutes for maintenance **



UP.

Thanks, this is the first compliment on DSQL, thank you.

So, in the mean time while I work on deploying the SEO link, please try this for watching a video:  If you want to see it as a stream, click the "View" link instead of the row (that theoretically opens it in a new window).  If you click the row, it opens a window.  Try hitting ctrl-f5, then view by clicking the row, then before watching another one, press <ESC>.  <ESC> kills the dialog contents and all the inner contents, on my chrome, but yes - if you find its a bug we will fix it.  But Ive tried about 25 now and they seem to work both ways on my browser (new window or dialog window).

As far as DSQL code base github, Yes, absolutely.  Im in the process of porting Microsoft SQL Server for Linux's support for DSQL now.  This will make it possible to host an 'edge node' with DSQL server in linux, and I think that will give us closer to unlimited scalability in DSQL for the future (this way, DSQL nodes will speak to each other with millions of records and lower latency, and also with powerful schemas (in contrast to Biblepay schemas), much higher scalability than plan old IPFS for our BIPFS records sync and DSQL acctg charges).  Once that is in and the Halford replication protocol is modified, I will make a github repo for DSQL.  Web.biblepay is just more code inside dsql, so any bugs could be reported in the DSQL branch.