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

Pages: 1 [2] 3 4
16
TestNet Discussion Archive / Re: Amazon Storefront Integration
« on: July 09, 2021, 10:41:55 AM »
Right now our integration component is not compatible with any amazon charities, but we could definitely add on a checkbox to tithe 10% of the purchase to orphan-charity.

(We still have over 20 SAI orphans available that need sponsored, so they would be compatible with this.  I also have to look into making a few SAI orphan NFTs).
Ok, I was not sure if it would be. It's too bad that it is not; for normal browsing / purchasing the only change is the url changes from amazon.com to smile.amazon.com

17
Sanctuary Discussions / Re: Fractional sanctuary (shared masternode)
« on: July 09, 2021, 10:37:35 AM »
Hi, I'm sorry for asking here, but I'm not able to open a new thread, I'm new here. I've been trying to set my master node with the step-by-step guide with no success....The master node does not sync any blocks, can someone please illuminate me?

Blessings
Hi,

Welcome to the forums!

There is not enough information to help set it up. To start:
What version are you running?
What OS?
Does it not connect to other nodes?
Does it give any error messages?
Have you looked at the debug.log?

Blessings

18
TestNet Discussion Archive / Re: Amazon Storefront Integration
« on: July 06, 2021, 01:56:17 PM »
Is this using Amazon Smile? While it is a small %(0.5), it does not increase the price that is paid and gives a little to charity. Cameroon One is on the list, as are many top notch charities.

19
Thanks bro Joseph-

So on the sell wall.....  Here is my best explanation:
- In 2017 and 2018 up to the point where bitcoin reached $20K, we didnt have a sell wall (and we sponsored 300 orphans per month)
- After BTC crashed, I remember we started going through hard times.  We dropped from 300 orphans to 90 or so and sort of gravitated there.
At the same time, we discontinued PODC (primarily because I saw very stagnant leaderboard participation, IE hovering at less than 100 users and no growth).
So this is where we started 'alternative' ideas, like POG and things that led to UTXO.
Anyway I feel that this particular time, the end of 2018 is when we built up a 40MM sell wall (from PODC miners who left the project).  They put some coins up for sale and quit biblepay.
- We sat at 40MM sell wall for a very long time, all the way to May 2021.
I noticed in May, we actually almost got to 0, we had someone buy about 100MM bbp but they pump n dumped us and put it all back up for sale last month.
So I dont think it was this upgrade (it happened before we transitioned to POOM).
It had more to do with some big pump n dump.  Coincidentally, BTC was skyrocketing at the time; BTC was at $63K, so I feel it was a speculative buyer that bought us, thought he would influence the price to go higher; nothing happened, then he put his whole stash up for sale higher (and if I remember right, this caused the sell wall to go from 40MM up to about 140MM, then over a couple weeks to 200MM - why the excess - my hypothesis is some sellers came out of the woodwork cause they saw a huge spike in BBP that week and want to insure they get out on the next spike so now we have 205MM sell wall total which is our highest ever).  (Too bad he didnt hold on to half of it for a long term investment etc.)

No our sanc count has been between 35-45 for 9 months so no I dont believe it has anything to do with sancs.  I do know that 6 of them didnt even upgrade (we had 6 more sancs before the upgrade) and it looks to me those 6 failed to upgrade.   


8200 BBP
Ok, so it probably has nothing to do with the sanctuaries that went offline. They may not have even noticed that they are offline yet. Even if those 6 had put them up for sale, I guess that is only 25.2 MM. I am not sure I would include what is for sale above 3x the current price as a sell wall though. That's still roughly 139 MM though, which is a lot of BBP.

20
Well first of all, no I don't mind any questions as long as they don't attract hackers to some public conversation that would hurt us, but this is obviously fine;

Next let me clarify on our 7 minute block target, on the point where you asked if it was intentional that we were emitting slow; This is not intentional in any way.

Let me expound that bitcoin, is off by something like a Year on their masterclock; this is entirely normal when the chain goes through periods that are increasing in difficulty (I think in the last quarter, in our case, generally, our randomx miners doubled their mining efforts in the Fun pool- we went from a diff of 1 to a diff of 7-8 and back to 3 or so), so I think we had an increasing diff and that slowed the block rate down a little; so we are actually much less volatile than bitcoin in general since genesis;

But to your point, I am extremely concerned with fair weight and measures in biblepay (proverbs 16:11), so much that we have a dedicated masterclock command (from the rpc, you can type 'exec masterclock' and see the metric and suggestions) that gives us the guide to whether we should speed up the masterclock-- and we actually have sped it up.  When we went from POBH to RX, we had a period of slow emissions, and we sped it up from 420 seconds to 370 seconds, in accordance with the estimated adjustment in the masterclock output; so its actually running at a 13%+ tweak in speed right now to catch us up... Another words it will probably speed up naturally over the next quarter without doing anything; what we do is we can speed it up even more if we dont eventually see 6 min blocks by next quarter, for example.

This is not based on our emission target though.  Our emission target was definitely too high up to 2020 due to overspending on DWS; but we reacted vehemently with APM and that actually corrected the emission problem completely (which just finished actually); but if you type 'gettxoutsetinfo' you will see this is complete, we made up for that, thank God, and we are right on schedule now.  Our emissions perfectly match the schedule and should hit the exact number roughly in Dec this year..  Our only problem now is praying to God to remove our sell wall on SX.. I think that is our biggest hole to climb out of.  Other than that, we have no debt to anyone, and fair weights and measures here (a fair mining algorithm with double compensation and no electricity costs etc), and Im committed to speeding up the master clock over time to reach the exact block count since genesis etc.




8200 BBP
Yeah, if I had a question that I thought might do something like that I would send a PM or maybe an email, not post here.

Thank you once again for a clear detailed explanation. It definitely cleared things up for me!

In regards to the sell wall, is a lot of that from all the Sanctuaries that shutdown recently? At 4.2 million each, that is a lot of BBP. I noticed that there were quite a few less since the mandatory update.

21
Only the coinbase is reduced (the sanc reward, plus the mining reward).  The monthly budget is not affected and the daily UTXO rewards are not affected.
We deliberately did that of course to be able to have a budget (when we have enough marketcap to actually have a budget again). 
In order to pull that off we had to tweak the budget estimator to use a non-apm subsidy estimate.
Ok, thank you for the information. That is what I thought was happening from reading the code, but there is a lot of code and I am not very familiar with the biblepay code.

I hope you do not mind all the questions. I have another one:
Is the recent increase in average block time intentional? Illustration:
The last 1000 blocks (279163 - 280162) took 5 days, 23 hours, 18 minutes (8598 minutes) for an average block time of 8.598 minutes/block.
At an average of 7 min block or 24 hour * 60 min / 205 ~= 7.024 min/block there should have been 1224 blocks in that amount of time.
Which means we "lost" 224 blocks - more than a whole day.

Please note that if it is intentional, I am guessing it is due to a previous over-emission of blocks or bbp. I am curious though.

22
Bounties / Re: UTXO Stake Giveaway of 1MM BBP
« on: July 05, 2021, 05:20:16 AM »
Thank you Rob for the Giveaway!

Just a note for anyone that uses the code:

The 1,000,000 BBP Reward is split between the people who use the code, not 1,000,000 BBP each. So do not be surprised when the amount it shows for you is much less than 1,000,000 BBP.

23
I have a question about APM(Automatic Price Mooning)

What parts of the block reward are subject to this? It is clear that sanctuaries and randomx mining are subject to APM. Are portfolio builder rewards and the 5% monthly budget subject to it? Are they reduced by the same %?

24
So for one, I take security very seriously, and couldnt possibly imagine having RandomX + Chainlocks in our community and ending up with a sidechain, so I've been vehemently trying to find the root cause of this and I believe I found the root cause and it should be fixed now. 
Basically the first part of the explanation is correct; we were transitioning over to chainlocks and the chainlocks started successfully, I can see this because yesterday morning we didnt have blocks locked at the tip and now we have hundreds of blocks locked and we are locked to the tip, so that part is good, the delay was due to normal quorum formation (which takes 2 days from my experience in testnet) and it took about 2 days in prod.

Now the second part of the issue, how we were jittering in and out of the go live and having a side chain form for a few hours (which, to my knowledge is the Only side chain we ever had since randomx started) - I honestly dont remember any sidechain even forming while on randomx because its a very expensive algorithm and it clearly keeps our consensus.

So what I found when debugging my server #6 which has multiple sancs on it was all the instances of BBP went down at the same time (during that height range of the sidechain), and fortunately I was able to find the problem in the debug logs on the server and this leads to a Fix.....  The problem is in our memorize prayers function believe it or not.  Its hard to fathom how that could cause a problem like this; but here is how.  We serialize the prayers based on a filename location that works for Single nodes only.  When more than one node instance on a sanctuary tries to write to that file at the same time it can crash the node (and that can cause database corruption because its an immediate non flushed berkeley db exit). 

So the fix is now checked in, I have upgraded my sancs.  The fix is working (cause I can see the prayers file has a distinct name now per server instance etc) and they are not clashing anymore. 

Now we need to let everything run for a week and monitor chainlocks and instantsend and see if chainlocks keeps us on one main chain for long periods of time, and my feeling is that we are going to be successful this time; I think we have fixed our bugs and we have a solid chain to build on. 
Thank you for spending the time to dig into this, identify the issue, and fix it! And thank you for the detailed explanation too, I appreciate it!

25
Thanks!

Its using the BBP/BTC market on SX;  right now it only updates our price hourly and the pool takes the risk to lower volatility; Im sure there will be wild swings but the way I look at it is our price is low so the pool should be fine in the long run.
That's good that it is using the BBP/BTC so the volatility should be a lot less than with the BBP/USD.
By the pool, do you mean the foundation mining pool? Either way it should be fine in the long run. As well as great for the future of BiblePay!

26
*** Amazon Storefront Integration is ready for testing in Alpha on MainNet ***

https://forum.biblepay.org/index.php?topic=779.msg11164#msg11164
That is exciting! Nice work Rob!

Do you mind if I ask if that is using southxchange BBP->USD or BBP->BTC->USD? Or something else? I am hoping it is not the BBP->USD since that does not have much depth to it, which depending how fast prices change on the store front could cause the amount paid in BBP to not actually cover the cost of the item.

27
2. A while ago the computer I had on the Fun pool stopped getting work from it and failed over to the foundation pool. It is back on the Foundation pool again.
I wish I could edit posts. This should have said "It is back on the Fun pool again now."

28
I think that Fun realized and fixed it for a few reasons:
1. They are now showing up on the explorer as mining blocks.
2. A while ago the computer I had on the Fun pool stopped getting work from it and failed over to the foundation pool. It is back on the Foundation pool again.
3. The divergent chain appears to have gone away. Meaning my wallet now shows the same as the explorer. That block I mentioned in my last post (279822) now shows a different hash in my wallet than before. It now matches the explorer.
Code: [Select]
20:19:46
getblockhash 279822
20:19:46
1f54f8930f2335add5b5b673ab50c48b9fe55372031c31ebf19bc8214f6deb4d

29
Although I see some disturbing figures on one of my sancs that I am now looking into, Im not seeing Fun on a different chain; Their height matches foundation's height and matches my home node height and matches chainz height;  what makes you say Fun is on the wrong chain?  (Also the blocks solved count matches-- if they were on a different chain my pool would get all the blocks).
Because my wallet says Fun got blocks that the explorer says that the Foundation got. Using 279822 as an example:
block explorer 279822 show the foundation pool
My wallet shows the Fun pool (cut for size):
Code: [Select]
19:03:39
getblockhash 279822
19:03:39
dff72c4279cc4edc62f9247946bf5fdcbc7a47abe86b1ce6bcb46fcb06f0e5ba
Code: [Select]
{
  "hash": "dff72c4279cc4edc62f9247946bf5fdcbc7a47abe86b1ce6bcb46fcb06f0e5ba",
  "confirmations": 20,
  "size": 2660,
  "height": 279822,
  "version": 1342177312,
  "versionHex": "50000020",
  "merkleroot": "49566211772f64323aace1d5c6c63b80a4f0c4134cc1b6c4e4acedf0f0c87786",
  "tx": [
    {
      "txid": "a9b06485fe04205e7cf1f4a2ebc8f6bd49ee4ae98f1719a76c61401f07b3ea35",
      "version": 3,
      "type": 5,
      "size": 228,
      "locktime": 0,
      "vin": [
        {
          "coinbase": "030e450404406ce060",
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 857.17139665,
          "valueSat": 85717139665,
          "n": 0,
          "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 e6b9429962942c52702ca99f1a6734166e60b05d OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914e6b9429962942c52702ca99f1a6734166e60b05d88ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
              "BRV2xwLJnRsMRMBG6uWyhvwghHFBjKHib7"
            ]
          },
          "message": "<VER>v1.6.2.8-Harvest</VER>"
        },
        {
          "value": 1645.51881254,
          "valueSat": 164551881254,
          "n": 1,
          "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 921f7a86129adea658fd2de28ea7f2ec248c229e OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914921f7a86129adea658fd2de28ea7f2ec248c229e88ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
              "BHmhytrL8fqC7NQEfGGi828WZmcGbqN9mv"
            ]
          },
          "message": ""
        }
      ],

30
Hi Rob, The block 279802 seems to be the point where an issue has appeared. The block on bbp explorer does not match the block shown through my wallet (1.6.2.8 ). All blocks before match, all blocks after do not match.
As an addition to this:

This appears to be serious as it appears there are 2 divergent chains!

Each mining pool is on a different divergent chain.  The foundation pool is on the chain that the bbp explorer is on, but the miningpool.fun pool is on the chain that my wallet (1.6.2.8 ) is on.

Pages: 1 [2] 3 4