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 ... 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 ... 263
2131
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.


2132
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!




2133
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?


2134

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.


2135
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?


2136
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).




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


2138
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?


2139
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)

2140
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?


2141
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


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


2143
I'm back here with latest testnet in MacOS.

I see this


Code: [Select]
01:10:30

listchildren


01:10:31

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

OK, and as you know, in Testnet I am running the mock API to apply debits and credits to the childs balances, but in Prod, CameroonOne will be running the API (from their own domain).

So I posted a $50.00 payment for child abaad3ec. 

Go ahead and do a listchildren now and see if you have a -10$ balance (this is because you have a debit of $40 for July orphanage charges minus a $50 payment).

Then do an execgscc and wait 6 blocks and see if the child payment is showing in your leaderboard "details".

Do you understand the 'exec dailysponsorshipcap'?  This shows the max amount we pay per child per day in the GSC contract (we use the daily BBP price quote - found in exec price - and of course the daily GSC paymentlimit - to calculate the quorums dailysponsorshipcap).

Oncoapp has 3 children, you have 1 and I have 2.  So Ill do an exec sendgscc, and we should see 6 children over 3 participants in the leaderboard we can reverse engineer. (Click Details).

OK, I sent an exec gscc, I see Oncoapp & I in there, now we need you.  Btw, the reason you are not in cameroon one as of yet today is because your child was not provisions (nor had a credit balance - until Cameroon receives the check or the paypal making your balance a credit balance!).



2144
BiblePay
1.4.5.8-Leisure Upgrade

- Merge in 1.4.4.1 prod changes -> develop
- Fix ABN create error (insufficient funds)
- Fix BiblePay Miner ABN crash-windows 64 crash issue

2145
Please check your coin control, and see if select all results in a tx size > 100K.  If so, unselect all, then select some repeatedly - and send them to yourself.
Repear until your total stash < 100K in size.

Then wait 6 confirms then do exec sendgscc.

I see we made this automatic in our prod branch, and somehow, this got borked in testnet; I will have a commit within 24 hours to fix this issue.


Pages: 1 ... 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 ... 263