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 ... 132
1
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?


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


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


4
On a side note, the next wallet version is going to have a new procotol that will allow faster transition and more accurate and quicker comm, but for now, I believe the pool will take this into account after a 1-7 minute lag.

Can you confirm if the HPS settles down properly after 5 mins?

If not, what discrepency remains?

Whoops, Im not giving enough info.

The pool can only handle One miner funding type per USER at a time for the time being (Funded or non funded).
It does allow switching however, but not a conflict per miner (all must be either non funded or funded at the same time).
You can accomplish this by copying the same wallet.dat out to the miners.

This limitation will be removed after people upgrade to the new protocol version - but its not released yet.


5
I am on 1.4.5.9 against mainnet
The wallet was locked but I unlocked and this message was there for several hours after unlocking.
However I repeated the same steps now and I can't reproduce the same message, it behaves as normal.

So maybe it was a glitch on my end.

About unlocking the wallet, I think it would be user friendly to detect that user has setgenerate=true and then, if wallet is locked, show some red message on the Overview screen to unlock it.

Ok great, glad it could not be reproduced again; as I have an encrypted mainnet wallet also, and I am aware of it going to Low ABN weight 0 when it switches, and then the miner being stuck until the ABN expires; but just for ease of use sake, I went ahead and added a line of code to handle this-   so in the next version, when the wallet is locked then unlocked and the miner is in the "0 abn state", it will recover within 15 secs.  That should help cut down the complaints too.

Great idea on the setgenerate=true and the locked wallet.  Ill check this:
If miner is Not funded, and locked, and generating, then we will make a warning appear on the overview page And in the getmininginfo.  Ill do that right now, thanks for the advice!




6
1. cli -version
BiblePay Core RPC client version 1.4.5.9 (downloaded binaries)

2. both wallets are fresh unencrypted and empty wallets (deleted whole .biblepayevolution dir)

3. both wallets sync to the top - block height 132570
449c1b5de627362f8369836ab8497720ff36aab9ba45e3bc93d3f65a9c654566

4. They appear to mine on the pool (mainnet) as
a. proteus_funded (Ubuntu 16.04 kernel 4.4.0-154-generic)
b. sam2_funded (Ubuntu 18.04 kernel 4.15.0-54-generic)

5. sanc list of both miners are empty
{
}

6. cli exec health
Code: [Select]
{
 "
 "votes": 0,
 "required_votes": 10,
 "last_superblock": 132450,
 "next_superblock": 132655,
 "next_superblock_triggered": false,
 "Healthy": false,
 "GSC_Voted_In": false
}

Can you kindly provide me a list of DIP3 sancs so that I can just add them into my conf file, please?

Thank you.
1) I just wanted to test mining on mainnet, just to ensure syncing and mining worked, but I wanted us to revert back to Testnet for testing cameroon one and GSCs.  Sorry for the confusion. 
  1b) So, yes, This 1.4.5.9 Testnet branch is called our 0.14 develop branch, and its protocol version is not at all compatible with non deterministic sancs.  Prod (mainnet) is running in non-deterministic (IE non dip 3 mode).  So correct, you will not be able to see any prod sancs in Prod mode on 1.4.5.9.  However, when Prod starts upgrading to dip3 (deterministic), you Will start seeing them on this version.  As a matter of fact, that is something of dire importance we need to test in about a week, once we start pushing that in prod (we are waiting in prod for a Bit to flip over called Dip3-Active, I believe it will flip in about 7 days).
1c)  You can not manually add sancs to the config, (except your own), but in dip3 mode (IE 0.14 branch mode) you cannot manually add any - they all must be sent with ProReg Tx's.  So for all intents and purposes, you cant add them.
2) In Testnet mode however, you should see about 6 sancs right now.  I just booted up in testnet mode and I do see the 6 sancs.  I see exec health has 3 votes.  Does yours agree with the votes count?
3) The other info you posted looks good, on the mining info.
4) Now it would be cool for us to test cameroon again in Testnet mode - just to verify you are no longer seeing the compounded rewards?


7

1.It is a bit hard to capture all the scenarios, as on mainnet, i am limited by ABN. But it starts ok. Using a common wallet, i cannot confirm which machine and hence
  client solved the block.
   It works initially and sometimes i get this error of a stale block. Don’t know if it specific to 1459. But the wallet is empty and not encrypted.

2) Can you please send a GSC and verify the Cameroon is no longer compounding?  For me they are no longer compounding.

I cannot see any sancs? Is GSC testing DIP3 sanc dependent?


So on #1, I do know about the stale block error; that is expected; its the pool sometimes has trouble finding an ABN to give to you (but it usually finds one within 15 secs, so thats OK) it just keeps trying and eventually gets one.

On the sancs, my machine is tied up, but I have not had that problem.  We dont have to wait til LLMQ is turned on in 1.4.5.9 - sancs should already be up and running and in deterministics mode now-  we have about 6 sancs running.

It might be your data is corrupted;  When you boot, ensure litemode is Off (litemode=0 or not in the config).
Then ensure your mnsync 'mnsync status' has reached 999.
You should see 6 sancs in the Sancs list then.

If not, try deleting your mncache*, mnp*, and gov*.dat, and retry again with a cold boot (you might have a bad sanc cache).

Then let me know if 'exec health' shows votes > 4, etc.

Then we can test cameroon again.


8
Getmininginfo dev 1.4.5.9 on mainnet

Code: [Select]
{
 "blocks": 132361,
 "currentblocksize": 1000,
 "currentblocktx": 0,
 "difficulty": 10360.99487125054,
 "errors": "",
 "pooledtx": 0,
 "chain": "main",
 "genproclimit": 1,
 "networkhashps": 619612.9706705563,
 "hashps": 7892.611994219653,
 "minerstarttime": "07-17-2019 20:13:41",
 "hashcounter": 2097288,
 "pooledtx": 0,
 "chain": "main",
 "biblepay-generate": true,
 "poolinfo1": "Pool mining with sam2_funded; ",
 "poolinfo2": "Submitting Solution 07-17-2019 20:17:23; ",
 "poolinfo3": "",
 "abninfo": "Mining with funded Valid ABN 36ad1fbdb62e2c7775e3000c29f4f87d59a4aa660277bef2271cdf94e96e4137; ",
 "poolinfo5": "Internal ABN: Invalid 1563394642; ",
 "gsc_errors": "",
 "poolmining": true,
 "pool_url": "https://pool.biblepay.org",
 "required_abn_weight": 125000
}
cli -version
BiblePay Core RPC client version 1.4.5.9

So just to confirm:

1) You tested solo mining, I tested solo mining, MIP tested solo mining and that worked with internal ABNs fine.

2) You tested both funded and non funded mining against pool.biblepay.org with pleaides, and a non-funded miner.

3) Can you please send a GSC and verify the Cameroon is no longer compounding?  For me they are no longer compounding.

4) We are waiting to turn on LLMQ's before checking the POSE banned states.

5) Did I miss anything?


9
I came back a couple of hours later and it said "Internal ABN: OK"
So maybe it was a matter of waiting a while for this to fix by itself.

Sorry for the headaches.

Now I am solo mining fine.


Can you try it all over again, and see what the total lag is?  Also could you check the log and see what the timestamp difference is and how long it took to recover?

This way we can modify the code to remove that situation.

Also, you didn't explain if it was a locked wallet; was it because the wallet was locked and then you unlocked it and the problem goes away after a certain amount of time?  (The error in the log would be telling).

I wonder if we should design the wallet to be able to mine without being unlocked.  Maybe this is a hurdle for newbies.

Again, is this 1.4.5.9 that is being tested (cause I think 1.2 in prod was a few months ago).




10
Code: [Select]
08:34:12

exec getabnweight 125000 1


08:34:12

{
  "Command": "getabnweight",
  "version": 2.6,
  "weight": 1265474159.938079,
  "total_required": 28859592,
  "coin_age_data_pre_select": "1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(14.38)=[14.38] depth=3042,  <ROW>12.4022(14.38)=[172.58] depth=3042,  <ROW>50.0000(15.94)=[796.95] depth=3367,  <ROW>2301.8849(0.51)=[1178.22] depth=111,  <ROW>2342.2185(0.53)=[1229.74] depth=114,  <ROW>2305.9676(0.73)=[1683.32] depth=159,  <ROW>2341.7357(0.88)=[2055.09] depth=191,  <ROW>2314.7290(1.07)=[2472.63] depth=231,  <ROW>127.1195(21.61)=[2743.90] depth=4532,  <ROW>1387.3182(2.15)=[2977.43] depth=459,  <ROW>2385.4458(1.28)=[3052.97] depth=276,  <ROW>2364.4107(1.32)=[3114.93] depth=287,  <ROW>2391.2520(1.41)=[3374.94] depth=305,  <ROW>2392.9768(1.54)=[3677.12] depth=330,  <ROW>2224.1720(1.77)=[3937.28] depth=381,  <ROW>2374.1741(1.77)=[4202.83] depth=381,  <ROW>2391.4955(1.89)=[4507.67] depth=405,  <ROW>2290.6961(1.97)=[4510.56] depth=422,  <ROW>2415.3781(1.88)=[4549.62] depth=404,  <ROW>2933.1573(1.61)=[4712.42] depth=344,  <ROW>2743.5920(1.85)=[5086.68] depth=397,  <ROW>2385.0204(2.15)=[5119.80] depth=459,  <ROW>2416.9292(2.18)=[5272.22] depth=465,  <ROW>2378.6192(2.22)=[5289.95] depth=475,  <ROW>2360.2759(2.25)=[5309.21] depth=480,  <ROW>2427.7336(2.36)=[5728.31] depth=503,  <ROW>2394.7174(2.69)=[6432.30] depth=573,  <ROW>2375.3487(2.85)=[6780.52] depth=610,  <ROW>2472.8851(2.99)=[7388.68] depth=642,  <ROW>2436.6841(3.12)=[7594.74] depth=667,  <ROW>2447.7713(3.12)=[7625.80] depth=666,  <ROW>2476.7250(3.13)=[7754.55] depth=671,  <ROW><TOTALREQ>66665.84</TOTALREQ><TOTALAGE>130375</TOTALAGE>",
  "weight 125000.00": 130375.0482986111,
  "total_required 125000.00": 66665
}


08:35:52

exec createabn 125000


08:35:52

{
  "Command": "createabn",
  "xml": "<MT>ABN</MT><abnmsg><nonce>a99f03a42c8637771177f773abbdb341303b51a28770440f5a67d68c640071de</nonce><ppk>ppk</ppk></abnmsg><abnsig>HxDfcaodxc9tiR0D+WUOy4j9SCZH8jWfmAkS7mTHQ70kPDwfH/Ca+7p69ynN7oI33Y17jqDGsbz9oDDkW7tytLU=</abnsig><abncpk>B7o7cD5otiaNeqnMyV5khw2CFNJLTeqh6L</abncpk><abnwgt>125000</abnwgt>",
  "err": "",
  "coin_age_data_selected": "1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(14.38)=[14.38] depth=3042,  <ROW>12.4022(14.38)=[172.58] depth=3042,  <ROW>50.0000(15.94)=[796.95] depth=3367,  <ROW>2301.8849(0.51)=[1178.22] depth=111,  <ROW>2342.2185(0.53)=[1229.74] depth=114,  <ROW>2305.9676(0.73)=[1683.32] depth=159,  <ROW>2341.7357(0.88)=[2055.09] depth=191,  <ROW>2314.7290(1.07)=[2472.63] depth=231,  <ROW>127.1195(21.61)=[2743.90] depth=4532,  <ROW>1387.3182(2.15)=[2977.43] depth=459,  <ROW>2385.4458(1.28)=[3052.97] depth=276,  <ROW>2364.4107(1.32)=[3114.93] depth=287,  <ROW>2391.2520(1.41)=[3374.94] depth=305,  <ROW>2392.9768(1.54)=[3677.12] depth=330,  <ROW>2224.1720(1.77)=[3937.28] depth=381,  <ROW>2374.1741(1.77)=[4202.83] depth=381,  <ROW>2391.4955(1.89)=[4507.67] depth=405,  <ROW>2290.6961(1.97)=[4510.56] depth=422,  <ROW>2415.3781(1.88)=[4549.62] depth=404,  <ROW>2933.1573(1.61)=[4712.42] depth=344,  <ROW>2743.5920(1.85)=[5086.68] depth=397,  <ROW>2385.0204(2.15)=[5119.80] depth=459,  <ROW>2416.9292(2.18)=[5272.22] depth=465,  <ROW>2378.6192(2.22)=[5289.95] depth=475,  <ROW>2360.2759(2.25)=[5309.21] depth=480,  <ROW>2427.7336(2.36)=[5728.31] depth=503,  <ROW>2394.7174(2.69)=[6432.30] depth=573,  <ROW>2375.3487(2.85)=[6780.52] depth=610,  <ROW>2472.8851(2.99)=[7388.68] depth=642,  <ROW>2436.6841(3.12)=[7594.74] depth=667,  <ROW>2447.7713(3.12)=[7625.80] depth=666,  <ROW>2476.7250(3.13)=[7754.55] depth=671,  <ROW><TOTALREQ>66665.84</TOTALREQ><TOTALAGE>130375</TOTALAGE>",
  "success": "83b818755bec72d8113a38882ec029c7efa9edc64bd944f58560dce74b92f3cd",
  "coin_age_data_pre_select": "1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(13.86)=[13.86] depth=2931,  <ROW>1.0000(14.38)=[14.38] depth=3042,  <ROW>12.4022(14.38)=[172.58] depth=3042,  <ROW>50.0000(15.94)=[796.95] depth=3367,  <ROW>2301.8849(0.51)=[1178.22] depth=111,  <ROW>2342.2185(0.53)=[1229.74] depth=114,  <ROW>2305.9676(0.73)=[1683.32] depth=159,  <ROW>2341.7357(0.88)=[2055.09] depth=191,  <ROW>2314.7290(1.07)=[2472.63] depth=231,  <ROW>127.1195(21.61)=[2743.90] depth=4532,  <ROW>1387.3182(2.15)=[2977.43] depth=459,  <ROW>2385.4458(1.28)=[3052.97] depth=276,  <ROW>2364.4107(1.32)=[3114.93] depth=287,  <ROW>2391.2520(1.41)=[3374.94] depth=305,  <ROW>2392.9768(1.54)=[3677.12] depth=330,  <ROW>2224.1720(1.77)=[3937.28] depth=381,  <ROW>2374.1741(1.77)=[4202.83] depth=381,  <ROW>2391.4955(1.89)=[4507.67] depth=405,  <ROW>2290.6961(1.97)=[4510.56] depth=422,  <ROW>2415.3781(1.88)=[4549.62] depth=404,  <ROW>2933.1573(1.61)=[4712.42] depth=344,  <ROW>2743.5920(1.85)=[5086.68] depth=397,  <ROW>2385.0204(2.15)=[5119.80] depth=459,  <ROW>2416.9292(2.18)=[5272.22] depth=465,  <ROW>2378.6192(2.22)=[5289.95] depth=475,  <ROW>2360.2759(2.25)=[5309.21] depth=480,  <ROW>2427.7336(2.36)=[5728.31] depth=503,  <ROW>2394.7174(2.69)=[6432.30] depth=573,  <ROW>2375.3487(2.85)=[6780.52] depth=610,  <ROW>2472.8851(2.99)=[7388.68] depth=642,  <ROW>2436.6841(3.12)=[7594.74] depth=667,  <ROW>2447.7713(3.12)=[7625.80] depth=666,  <ROW>2476.7250(3.13)=[7754.55] depth=671,  <ROW><TOTALREQ>66665.84</TOTALREQ><TOTALAGE>130375</TOTALAGE>",
  "audited_weight": 130866.3395988033,
  "vin_coin_age_data": "\nGetVINCoinAge: Output #0, Weight: 1247.01, Age: 0.53, Amount: 2342.00, TxTime: 1563385137...Output #1, Weight: 3953.67, Age: 1.78, Amount: 2224.00, TxTime: 1563277545...Output #2, Weight: 3694.75, Age: 1.54, Amount: 2392.00, TxTime: 1563297685...Output #3, Weight: 5326.61, Age: 2.26, Amount: 2360.00, TxTime: 1563236133...Output #4, Weight: 1700.31, Age: 0.74, Amount: 2305.00, TxTime: 1563367407...Output #5, Weight: 4220.33, Age: 1.78, Amount: 2374.00, TxTime: 1563277545...Output #6, Weight: 2072.35, Age: 0.89, Amount: 2341.00, TxTime: 1563354656...Output #7, Weight: 7643.84, Age: 3.12, Amount: 2447.00, TxTime: 1563161248...Output #8, Weight: 7772.81, Age: 3.14, Amount: 2476.00, TxTime: 1563159909...Output #9, Weight: 5290.03, Age: 2.19, Amount: 2416.00, TxTime: 1563241961...Output #10, Weight: 5746.20, Age: 2.37, Amount: 2427.00, TxTime: 1563226579...Output #11, Weight: 13.87, Age: 13.87, Amount: 1.00, TxTime: 1562232591...Output #12, Weight: 4734.04, Age: 1.61, Amount: 2933.00, TxTime: 1563291686...Output #13, Weight: 2489.69, Age: 1.08, Amount: 2314.00, TxTime: 1563338181...Output #14, Weight: 172.67, Age: 14.39, Amount: 12.00, TxTime: 1562187897...Output #15, Weight: 4525.30, Age: 1.89, Amount: 2391.00, TxTime: 1563267617...Output #16, Weight: 3070.55, Age: 1.29, Amount: 2385.00, TxTime: 1563319906...Output #17, Weight: 2987.65, Age: 2.15, Amount: 1387.00, TxTime: 1563245032...Output #18, Weight: 2744.83, Age: 21.61, Amount: 127.00, TxTime: 1561563790...Output #19, Weight: 6449.95, Age: 2.69, Amount: 2394.00, TxTime: 1563198361...Output #20, Weight: 3392.48, Age: 1.42, Amount: 2391.00, TxTime: 1563308552...Output #21, Weight: 13.87, Age: 13.87, Amount: 1.00, TxTime: 1562232591...Output #22, Weight: 5106.90, Age: 1.86, Amount: 2743.00, TxTime: 1563270282...Output #23, Weight: 6798.02, Age: 2.86, Amount: 2375.00, TxTime: 1563183836...Output #24, Weight: 4567.42, Age: 1.89, Amount: 2415.00, TxTime: 1563267735...Output #25, Weight: 3132.35, Age: 1.33, Amount: 2364.00, TxTime: 1563316659...Output #26, Weight: 4527.44, Age: 1.98, Amount: 2290.00, TxTime: 1563260324...Output #27, Weight: 5137.38, Age: 2.15, Amount: 2385.00, TxTime: 1563245032...Output #28, Weight: 5307.48, Age: 2.23, Amount: 2378.00, TxTime: 1563238304...Output #29, Weight: 797.32, Age: 15.95, Amount: 50.00, TxTime: 1562053371...Output #30, Weight: 7612.70, Age: 3.13, Amount: 2436.00, TxTime: 1563161134...Output #31, Weight: 14.39, Age: 14.39, Amount: 1.00, TxTime: 1562187897...Output #32, Weight: 1195.19, Age: 0.52, Amount: 2301.00, TxTime: 1563386263...Output #33, Weight: 7406.90, Age: 3.00, Amount: 2472.00, TxTime: 1563172259..."
}


exec createabn 10000000 also succeeds.

But getmininginfo still returns

  "abninfo": "No block to mine... Please wait... 1563388615; ",
  "poolinfo5": "Internal ABN: Invalid 1563388480; ",
  "gsc_errors": "low abn weight 0",

And I haven't  created any GSC tx lately in prod. Also I tried to restart but I get the same.


So, Im trying to reproduce this - and so far I cant break 1.4.5.9.
First, are you running 1.4.5.9 (this is the last one you built for develop)?

Ive tried ABN mining in testnet and Prod, both successfully.
Btw, do you have pool mining credentials in, or are you running solo?  (I assumed we are running solo in this first set of tests).

Finally, could you please try abn mining solo in testnet, and see if there is a difference?

(Im solo mining in testnet with a 1000 abn, and solo mining in prod with a 1000 abn).

I forgot to ask, btw did you ensure your wallet was unlocked and you waited over 10 minutes for mining to start If you locked it?
Try unlocking it, then do a new 'setgenerate true N" *after* that.  See if it clears the errors?

(You can look in the log and see if you had any testblockvaliditylite errors; if so paste them here).

Please erase the log before starting all this - that way we can hone in on the problem quickly.


11
as pleiades2 on pool.biblepay.org with own abnweight

cli -version
BiblePay Core RPC client version 1.4.5.9

Code: [Select]
{
 "blocks": 132394,
 "currentblocksize": 1675,
 "currentblocktx": 1,
 "difficulty": 2117.634585042601,
 "errors": "",
 "pooledtx": 0,
 "chain": "main",
 "genproclimit": 240,
 "networkhashps": 645828.9771104221,
 "hashps": 26917.51935300097,
 "minerstarttime": "07-18-2019 00:04:48",
 "hashcounter": 19277466,
 "pooledtx": 0,
 "chain": "main",
 "biblepay-generate": true,
 "poolinfo1": "",
 "poolinfo2": "",
 "poolinfo3": "",
 "abninfo": "ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN:  OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ABN: OK; ",
 "poolinfo5": "",
 "gsc_errors": "",
 "poolmining": true,
 "pool_url": "https://pool.biblepay.org",
 "required_abn_weight": 125000
}

cli exec getabnweight
{
 "Command": "getabnweight",
 "version": 2.6,
 "weight": 240718.600324074,
 "total_required": 1212742
}

cli exec createabn 125000

{
 "Command": "createabn",
 "xml": "<MT>ABN</MT><abnmsg><nonce>801c96dc35b4b9921a9369190810b604a9666f6e839c2a981b2fdb28d515fcc4</nonce><ppk>ppk</ppk></abnmsg><abnsig>IJCU2Sb5KlNsigrnJhP+W/JMt/mTx0KN65JV2zm4e8fDbQX1n3CznlyiL4dKI/MA2b9YjjRS/9W57RTRnr/ALAw=</abnsig><abncpk>BLpAqYhjuxJAfTC9yJBUxzUyNfDFfiduip</abncpk><abnwgt>125000</abnwgt>",
 "err": "",
 "coin_age_data_selected": "2341.7357(0.63)=[1468.27] depth=136,  <ROW>1210401.1106(0.20)=[239250.33] depth=42,  <ROW><TOTALREQ>1212742.85</TOTALREQ><TOTALAGE>240719</TOTALAGE>",
 "success": "d148d565157bb7fecee7e3f14698f0431114293d2de7c489de6295cf30d128ef",
 "coin_age_data_pre_select": "2341.7357(0.63)=[1468.27] depth=136,  <ROW>1210401.1106(0.20)=[239250.33] depth=42,  <ROW><TOTALREQ>1212742.85</TOTALREQ><TOTALAGE>240719</TOTALAGE>",
 "audited_weight": 241855.5179565373,
 "vin_coin_age_data": "\nGetVINCoinAge: Output #0, Weight: 1470.47, Age: 0.63, Amount: 2341.00, TxTime: 1563354656...Output #1, Weight: 240385.05, Age: 0.20, Amount: 1210401.00, TxTime: 1563391768..."
}


Thats great to know we didnt break compatibility in prod.
It tests pool mining, ABNs, Funded ABNs, syncing to the top, etc.

Thanks!

MIP can you please confirm you had insufficient funds the first try because you had recently sent a GSC in prod, or something?


12
Code: [Select]

22:56:00

exec getabnweight 125000


22:56:00

{
  "Command": "getabnweight",
  "version": 2.6,
  "weight": 1253818517.638646,
  "total_required": 28852642,
  "weight 125000.00": 132255.1786689815,
  "total_required 125000.00": 67455
}


I'm using my "normal" mainnet mining wallet but this is different to what I see using 1.4.4.3

Code: [Select]
22:56:24

exec getabnweight 125000


22:56:24

{
  "Command": "getabnweight",
  "version": 1.2,
  "weight": 23305003.67273147,
  "total_required": 1861636,
  "weight 125000.00": 146982.5912037037,
  "total_required 125000.00": 23121
}

v1.2 didnt have the 500 tx limit, but 2.6 does; 2.6 sorts by coin-age.

Lets see if these two things shed light on it:

exec getabnweight 125000 1

And

exec createabn 125000


See if they use the coins as expected.  If no error occurs in exec createabn, you should be able to abn mine.


If you really want to see if 2.6 is accurate, try this:

exec createabn 10000000
See if it makes an ABN with a weight of 10 million?

(audited_weight: 10mm)

13
mining in prod... I see weird stuff in abninfo and poolinfo5:

Code: [Select]
20:37:10

getmininginfo


20:37:10

{
  "blocks": 132344,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 5764.798569706667,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 554920.0413722472,
  "hashps": 0,
  "minerstarttime": "07-17-2019 18:19:34",
  "hashcounter": 0,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
[b]  "abninfo": "No block to mine... Please wait... 1563388615; ",
  "poolinfo5": "Internal ABN: Invalid 1563388480; ",
[/b]  "gsc_errors": "low abn weight 0",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 125000
}

While 1.4.4.3 says "Unable to create ABN..."

So if you send a big GSC out, sometimes you have to wait 5 confirms to get your ABN weight back.
Could you please paste your exec getabnweight 125000?


14
BiblePay
1.4.5.9 - Leisure Upgrade

- Commit 1441-1442 prod changes to Develop
- Miner now has all the abn/turnkey features prod does - please test mining against Prod


15
Code: [Select]
23:05:00

listchildren


23:05:01

{
  "List Of": "Cameroon-One Children",
  "Child ID": "abaad3ec",
  "CPK": "yWK9ckFhU1ihDSDLAZggNFTwypg6Bi3C23",
  "Biography": "https://cameroonone.org/biblepay/abaad3ec.htm",
  "Balance": -10,
  "Nickname": "MIP",
  "Child ID": "0f83ef0c",
  "CPK": "yWK9ckFhU1ihDSDLAZggNFTwypg6Bi3C23",
  "Biography": "https://cameroonone.org/biblepay/0f83ef0c.htm",
  "Balance": -999,
  "Notes": "This child is not provisioned yet.",
  "Nickname": "MIP"
}

Executed the sendgscc
And I see myself in the leaderboard

Are you happy with the amount you are receiving per day (for Cameroon), and non Cameroon POG rewards?

Next, we need to test non abn and abn and pool and non-pool mining (I think it would be prudent to test all the combinations).

Can we please sync to prod in .14, and have a few of us test against the pool in PROD (as testnet doesn't have a pool setup currently).

We have develop version 1.4.5.9 coming out now; lets build this version first, release it, then continue testing the mining.


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