Bible Pay

Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Dip0008 is now enabled in TestNet and Spork_17 (DKG's for LLMQs) are now enabled.

This means the 3 existing sancs will now start making hourly (and daily) quorums.  They should technically cause quorum info to be written in the coinbase transaction.

We will be able to see the effects of this by monitoring POSE scores per sanctuary.  Technically, the sancs who are offline should start receiving POSE bans.

We may be able to barely make a quorum with 3 nodes in testnet as testnet requires > 50% participation of 5 (so that means 2.5 = 50%) and that means the hourly quorums would succeed, but I would still like to see a couple more sancs online in testnet for LLMQs and Chainlocks for quality testing.

Now we just need to verify the quorum data is written, the non participating nodes are banned (for a few days) then we can enable chainlocks.


From the Dash TestNet thread, testing chainlocks:

https://www.dash.org/forum/threads/dash-core-v0-14-on-mainnet.45821/

EDIT:  After reading all that I must say I feel a breath of fresh air here in our community as we have less infighting :), I'm glad Camosoul hasn't been posting here in testnet!


52
One thing that is very dissapointing in testnet, is I see exec health shows '3' votes.  (I have 3 sancs).

Do we have anyone testing other than me?

We need at least 4 to test LLMQs.

54
Production Proposals / Hosting Expenses May/June/July
« Last post by thesnat21 on July 22, 2019, 12:53:00 pm »
I have not submitted a proposal since April, so catching up on some expenses (no room the last 2 months :)
Last proposal: https://forum.biblepay.org/index.php?topic=402.0


I'm requesting 3 months hosting expenses.   30/mo * 3 = 90$
90 * .000393 = 229000 +2500 proposal fee = 231500bbp


55
Ok understood. Tell us if you need to check anything else in testnet.

Lets check:
1) Have you received a regular single cameroon payment per superblock cycle (not more than one payment per cycle), and at least 1 (as long as you send at least 1 gsc per cycle)?

2) Send me a new child ID and an amount you want to pay and lets ensure you can kick another one in?
3) Lets ensure you get kicked out when you fail to pay also.

EDIT:  After church Ill check into the LLMQ punchlist.


56
Production Proposals / [MIP] July 2019 compensation
« Last post by MIP on July 21, 2019, 02:37:18 am »
Hi all

I would like to kindly ask some compensation for Jul 2019 support/development tasks

Evo binary compiles for Linux x64 & ARM and MacOS, mainnet and testnet: 8h
Dash 0.14.0.1 code merge and keeping up with master hotfixes in develop: 8h
Help testing 1.4.5.x in testnet: 4h
User support in discord/email/other channels: 4h

In all 960€ (2,525,000 BBP), capped to 1,500,000 (1,5M) BBP

Thank you very much
57

So lets go back to Testnet for a while, and once we enable the dip3 sancs in mainnet, Ill jump in testnet and try to mine for a day or two and join you guys and see if we stay on track.

As you both might know, 1.4.5.9 has no sancs to load gov data from either (from mainnet), so its probably banning sancs too.

Ok understood. Tell us if you need to check anything else in testnet.
58
These two 1.4.5.9 miners:

1. Tried exec reassesschains 5 times to no avail.

2. Re-Started wallet with -erasechain=1

3. Currently on main chain at height of other machines running 1.4.4.3

4. Will put them on the pool using workerids “sam2” and “proteus” with “_funded” for funded workerids respectively. They have the same wallet as other miners running 1.4.4.3

I assume it will drift off, but Im not sure at what point.  Probably at the point of the next superblock if I were to make a wild guess.

One thing that might work is running 1.4.5.9 in 'litemode=1', if you really want to, but I think its probably futile until we lock in dip 3 in prod.

Can you please check on cameroon 1 in testnet again also?

59
Dear Rob,

Please be aware that both my 1.4.5.9 miners appear to constantly drift off by themselves.

The following machines are running 1.4.5.9 on mainnet

XXX.XXX.098.201
XXX.XXX.108.063

cli -version
BiblePay Core RPC client version 1.4.5.9
block
132761
hash
20d6e3054e7b0c6d957e0884e02141e9e70d8c54758c02b95fc87e2b289a7238


All my other machines are on

BiblePay Core RPC client version 1.4.4.3
getblockhash 132761
960755cefc3ded480ac454ea03a264c8279c9f68b8fada228cd8147046e3f1b5

This can be verified in real time from my monitoring web page
https://oncoapop.sdf.org/biblepaymain/biblepay_chainstate.shtml

getblockhash 132778
02e667e874569ed6000160a6e05bafe7f3a09379da6d529c2d403a1cd32bf6af


Well, thanks for trying.  Yeah, lets hold off on testing 1.4.5.9 against mainnet for a little while.

I make the assumption that we are banning other nodes in prod.

60
I reindexed and everything seems fine. I am with funded mining. I will leave it for a while then try unfunded (unless you instruct me otherwise)

Ok, I just realized something.
First let me clarify - so in TESTNET against Develop branch (1.4.5.9), I just checked my 3 sancs and my dev node and they are all in sync.  So I think we can all agree, we didnt go off the rails in TESTNET.

I asked MIP and Oncoapop to test POOL mining in PROD (Mainnet) against 1.4.5.9.  So MIP uses an existing blockchain, and goes off the rails, and so does Oncoapop.

So, heres what I think we need to do.  I think we need to wait on testing Mainnet until Mainnet enables dip3.  Because there are 2 places in the code in 1.4.5.9 that make deterministic calls, assuming DIP3 is always on - for example, if it sees a non-fin-tx, it will handle that differently than mainnet currently does.

So lets go back to Testnet for a while, and once we enable the dip3 sancs in mainnet, Ill jump in testnet and try to mine for a day or two and join you guys and see if we stay on track.

As you both might know, 1.4.5.9 has no sancs to load gov data from either (from mainnet), so its probably banning sancs too.

Pages: 1 2 3 4 5 [6] 7 8 9 10