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 - MIP

Pages: [1] 2 3 4 5 6 7 8 ... 19
Ok I did modify a spork that might be it, please try restarting the client and try again.

Wow!! it worked! Thank you very much!

Oh ok, yes, I see your Dash Stake is good, (4.5) and has the correct vout.

I think the problem is you are not allowed to use sanctuary collateral as a dashstake (we block both sanctuary collateral, 4.5MM, and 1000DASH).  Imagine someone trying to use 1000 DASH LOL.

This is because in theory they can double dip if we do that.  (I think we forgot to put in a specific error message for that).

Please try a different BBP UTXO and let me know if that was the problem.  Then I will add a todo item to add an error message for that case.


Hi Rob, I guessed so after writing my first post about it, thatīs why I moved one collateral utxo here: a9dc5156f59cba9261dccc92d31ea597bb9b9f877070f828f695e7d5311e4ac8-1

Which is 1 BBP less than the official collateral amount.
But the result message is the same

This is what I read in debug log:
Code: [Select]
ExtractAPM Height 221839=3.000000 GetDashStake::Using bbpaddr BG54CPavbTGBy54LdjaoSww6ZmMfhupwZe and dash addr  dash amount 0.000000
Deciding between bbpvalusd 286.810000 and dashvalueusd 0.000000 and qty of 0.000000 and 4500001.000000 = 0.000000 VerifyDashStake::REJECTED Dash amount too low.Consensus::ContextualCheckBlock::TestBlockValidityLite  (code 0)

I tried to move my BBP UTXOs to new UTXOs in case there was a problem with them, but still getting the same message as before.

To get past that, you just have to have more than .000001 Dash in the UTXO.  (Maybe you were using the wrong vout - like maybe the change).

Also, if one stakes $250 of BBP and $750 of Dash, the stake is based on the BBP amount, however if they stake $750 of BBP and $250 of Dash, the stake is based on the equiv amount of $250 of BBP.  So it always calculates the lower dollar value of the two to lock in the contract then each month is paid the same until it either expires or gets spent.

4200 BBP

I donīt think this is the case, both Dash UTXOs are ok:


Code: [Select]
dashstake 8e5d3da184bdad9823c5df0315486968e36727c8ee7c780c67ebe595ae35f899-1 cc1ce7df0095928a997ad76f7ce6b7cd5a3d4092052deb390c6d5ea3cc568bf5-0 [signature-here] I_AGREE

  "DWU": "48.0351",
  "Error (Not Sent)": "Dash amount too low. Unable to verify Dash Stake. "


Code: [Select]
dashstake c5362771138f9956c8f0fbb8ec38a2e5d5407c11733e3b9f2c37b618d3804647-1 ec38ade4cb569c2b5b13f799781b3fb44151121c70c92ffc3aa6dd56722ca955-1 [signature-here] I_AGREE

  "DWU": "48.0351",
  "Error (Not Sent)": "Dash amount too low. Unable to verify Dash Stake. "

So there seems to be something else that I canīt figure out.

I just did one for $700 (10 mil even) and it worked:

 "Monthly Earnings": 378482.1528,
  "DWU": 53.62181567996866,
  "Next Payment Height": 221670,
  "BBP Value USD": 827.46,
  "Dash Value USD": 700.87,
  "BBP Qty": 8470021.394069832,
  "BBP Amount": 10000000,
  "Dash Amount": 9.800000000000001,
  "Results": "The Dash Stake Contract was created successfully.  Thank you for using BIBLEPAY and DASH. ",
  "TXID": "bd77e2cfbb9a1ff493b23c46a898a2cda113e6ea75b832c98bfcc76e3ae10852"

Maybe try reducing your max BBP amount to 10 MM.

We can increase the limit next mandatory.  I think I put in a 10MM limit to ensure safety for the initial rollout.

4100 BBP

How do we know the right amounts for Dash and Biblepay? I am using now 1 DASH = 1M BPP which is current proportion as per SouthX price now, but it says "Dash amount too low"


BiblePay Core Upgrade

- Disable LLMQ (send it back to testnet)
- Add POOS POSE banning (to resolve Sanctuary payment slot issue)

MIP is building MAC.

Mac and Ubuntu 16.04 build also ready.

BiblePay -
Mandatory Upgrade

- Standardize LLMQ rules so that all nodes homogenize

** MIP is building Mac **

We will still keeps the exchanges in maintenance a little longer, while we test chainlocks and durability over the next 410 blocks.

We can resync the chain in 410 blocks and verify syncing from zero is robust.

Mac compile ready.
Also Ubuntu 16-04-compatible compiles ready.

I have my sancs stalled at block 220054 (I guess that would explain why they start piling up ban score).
My controller wallet is at the same chain as your sanc.

I will run reassesschain and see what happens.

Neither reassesschain nor -erasechain=1 worked for me, they are still in an apparently stalled chain:

Code: [Select]
  "version": 1050207,
  "protocolversion": 70760,
  "walletversion": 61000,
  "balance": 1896.98274919,
  "privatesend_balance": 0.00000000,
  "blocks": 220056,
  "timeoffset": 0,
  "connections": 14,
  "proxy": "",
  "difficulty": 0.001729468455635417,
  "testnet": false,
  "keypoololdest": 1572338947,
  "keypoolsize": 1000,
  "paytxfee": 0.00000000,
  "relayfee": 0.01000000,
  "errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

I am running (Leisure Update), donīt know if this has anything to do with it.

Hi again. I think there is still some kind of forking going on. I tested your command on my sanc and it worked fine.
On my controller wallet it created an error and I checked back and saw, that this was on another chain. So I restarted it with "erasechain=1".
Now I came home from work at it is synced again, but again on a completely different chain. Also the 2 explorers seem to be different/stopped.

Could anyone please confirm, that my Sanc (at least) is on the right one?
Code: [Select]
getblockhash 220161

I have my sancs stalled at block 220054 (I guess that would explain why they start piling up ban score).
My controller wallet is at the same chain as your sanc.

I will run reassesschain and see what happens.


Will you all please restart your sanctuaries with "-erasechain=1".  This will erase the LLMQ folder and resync.

Once you are done with this, 'quorum list' should return empty (in contrast to returning 3 quorums (50_60 and 2 * 5_60).

Please do this immediately, because we are trying to jumpstart the quorums before block 220,000.


My two working sancs are showing empty, but my controller wallet shows 3 entries in quorum list. Is this ok or do I have to do anything else?

General Support / Re: Wallet Export/Import Private Key
« on: September 06, 2020, 01:58:02 PM »
Biblepay mobile wallet uses BIP39 hierarchical deterministic (HD) wallet.

The way it works is: it creates a new main address for each receive transaction, and a new change address for each change output.

Both main and change addresses can be found using a tool like this:

But the official one does not support Biblepay so I prepared one version that supports it.
I can send it to you by email or even upload it to download area.

The way to proceed is:
- Run the bip39 JavaScript tool locally in a browser (should be an offline machine)
- enter the 12 word seed and select Biblepay in the coin select field.
- In Derivation Path, choose BIP32 and “Multibil HD” client field.

You should then see all private/public keys and addresses
use a block explorer to test both main and change addresses until you find several empty ones or you are sure you have rescued all your funds from the mobile wallet.

IMPORTANT WARNING: this method should be used only for emergency recovery of mobile wallet funds, before abandoning the 12 word seed for good. This is, once the above method is applied, the (Hopefully empty) 12 word mobile wallet should be wiped out and replaced by a new 12 word seed.


The Block Subsidy is broken?

Please read about APM and other novelties in the last version of September 2020

Automatic Price Mooning (APM)
If the price of BBP stays the same or goes down, then the blockchain goes into money saving mode (we pay 99% less rewards to the Sanctuaries and to the Miners). This should give a strong motivation for the community to keep the price rising.

Its partially correct but there are many more variables to consider.

As far as the payment amount, that changes according to an ordinal in LLMQ - in order to keep the amount deterministic for the round.  So after 217K, it just had to run to the next ordinal.  Looking now, the sanctuary payment amount did jump from 3500 to 4679 with the same sanc count of 125.

As far as 1 bbp payments for POOS banned sancs, that only applies to  sancs who are in 700 but not in POSE banned state yet.

One issue we have between now and 220,000 is we are trying to restart our quorums again.  And this means LLMQ and hence POSE banning doesnt go into effect til after 220K and after quorums restart.

So we also have to wait for that to occur to actually see POSE banned sancs.  The code does attempt to vote bad sancs out of quorums that are not conforming to the rules this time (in contrast to the last time we had LLMQs).  So lets reassess the "slot" situation after LLMQs and POSE banning are on again.

4200 BBP

Wow thanks for the detailed explanation, it’s hard to imagine the complexity and subtleties of LLMQ and masternode interaction.

Official Block Explorer Upgrade has been upgraded to HTTPS (will redirect if HTTP url is used)

** Welcome to POOS (Proof of Orphan Sponsorships by Sanctuaries) **
Taking a look at the gravity of the situation, I see that 44 sanctuaries have paid for Orphans!  This is a great start, but, we have some work to do.
Out of our total 125 sanctuaries that are ENABLED, we only have 44 that paid.

This means that 81 sanctuaries are starting to be POOS banned.

Please check your sanc and spend the collateral if you don't want an orphan -- or -- alternatively sponsor an orphan.  Starting in 20 blocks, you will no longer be PAID.

I see that POOS banned get a 1 BBP reward, but they still keep a slot in the block payments. Also valid sanc rewards are the same as before 217000 (were they not supposed to absorb the charity budget for themselves?).

So in the aftermath even if a sanc is sponsoring 1 child, it is getting exactly the same rewards as before, and all the emission of the POOS-banned sancs is becoming "lost".

Is this a correct assessment, or is it just a temporary situation until a whole reward cycle is finished?
Thanks for the great job!

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