Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 28. (Read 243376 times)

finally works email (received) about new version of wallet ,  good job togo  


MIP whats cmd for upgrade linux, forgot it, thanks...... good to add on main web in tutorials, missing it there

With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse?  Thanks!

Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)

My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.

This release for ( trying to ) block gpu is just a bunch of crap ...

I combined the two website newsletter subscriber email lists

and about 12 hours ago I sent out a quick email about the recent mandatory upgrade

879 total sent, and 127 opened so far

Newsletter Signup Link: https://www.biblepay.org/newsletter/

Launched 2 wallets upgrade on 2 VM, at the same time ( same VM config, same fresh Windows 10 LTSB, same previous wallet 1.4.8.5 )
The 2 wallets had the same error on loading DB.
Relaunched the 2 wallets with -erasechain=1
1 is ok after rebuild, 1 crashed after rebuild. Relaunched the crashed wallet, he's processing blocks again ...
It's my 4th 1.4.8.7 upgrade, no one has been without error
I had no problem to migrate previously ~10 wallets from 1.4.8.4 to 1.4.8.5

Maybe applying 1.4.8.6 before can help ?

EDIT
2nd wallet is finally ok after 2nd rebuild

Mine did this when upgrading. When I started rebuilding, I let it do its thing. Came back hours later and the wallet had closed itself. Launched again and it started rebuilding all over again without prompting. It seems to have worked fine after that. Just wanted to add my experience in case it is a mass thing. My wallet was properly exited using the file menu. I just ran the update over the old. This was on Windows 10 64 bit.

The new external miner seems not working. I've no share on pool with it. But with 1009 I have shares ( and lots invalid rate ... )

** DYNAMIC WHALE STAKING **

I see we have 916K of burns today (exec dwsquote).

I think this is going to be a good feature for potential new baghodlers.  Hopefully more people from the outside world will join biblepay and try this.

Ohh ok, sorry, I think I am seeing the picture now; anyone who is still live on the old fork is making a long chain of bad blocks;
Yes, if you simply restart and have a lot of bad blocks in the blockindex, the plain-vanilla block checker during boot incorrectly assumes you have a corrupt chain...
OK, yes, if that is the case, please restart like Sun mentioned:  "-erasechain=1"  at the end of biblepay-qt.

Btw, if we do crash during reindex (Would you like to rebuild block index now?  ), if that actually crashes, please enter a github issue.

I'm not killing the process, just waiting it close itself.
Still processing blocks, will see result in few minutes.

Also, if you have been, please avoid killing the biblepay-qt process from task manager, please do not do that.  That is a big no no in crypto.

If you kill the wallet without gracefully exiting, you will corrupt all of your databases - both berkeley DB and the underlying blocks and chainstate and wallet and you will be in for nothing but trouble in the future.

I've had a good 1 year run now with the same database and no corruption simply by exiting from the menu.

- Just to clarify - that is not a crash.  That is a notification that you have a corrupt database file.  (A crash is an unhandled exit in the program, this was handled).

https://whitewalr.us/2019/biblepay-erasechain-not-reindex.html

Try this. If that doesn't work, DM and I'll provide a deeper cleaning but requires you do erase some files & folders manually. I've rarely have to do it and --erasechain seems to solve it for 99.9% of people. This is actually a nice feature that no other crypto wallet has, not even DASH with their wallet repair feature.

Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7


Rebuild in progress, and after I'm pretty sure wallet will crash.

Thank you guys!

I had missed a payment or two, but the focus on fairness and the effort put into correction is much more valuable than the compensation itself.

Sun, if you can come up with a tipping bot on Discord, I will be the first to chip in - I know you will use it for a good cause

I sent you 518,640 from my wallet, please distribute it any way you want, and thank you for taking on this endeavor.

PoDC 2.0 payment issues from Dec 25, 2019 to Jan 16, 2020, I've identified 518,639 BBP (122 line items) that are candidates for reimbursement.

Option 1: Shall I submit sanctuary proposals for each CPK, detailing the payouts?
Option 2: Send me 518,639 BBP and I'll distribute it, with documentation. BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Option 3: There's 146k BBP in the bounty wallet I can use. Remainder 372,639 BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw

Full details and methodology is available to anyone wanting to review out of curiosity or validate my work.

Based on the payout each day, I created median value of BBP to RAC ratio per day. This is the multiplier I used based on the RAC of the cpid I retrieved from boincstats (same as WCG). If the CPK was overpaid overall (total payments equal more than 110% of estimated payments) then there is no reimbursement for that CPK since they received more already.

Some caveats in my analysis:
* the RAC to BBP multiplier is best effort and not always best value. If a RAC whale was underpaid, this can throw off the ratio
* GSC payments are lumped into one (PoDC, Healing, POOM, etc) making it difficult to separate out non-PODC payment without performing more analysis. I looked at leaderboard but some prominence seems to be current day not on gsc block day?
* I counted the BBP balance of the CPK when the GSC reward was transmitted. If their balance had enough stake based on the team they were on (BBP = ^1.3 and non-BBP = ^1.6), then I assumed they had enough stake. I realize balance may not reflect full coin age transmission.
* Some small incidents where the GSC transmission was not sent for the CPK automatically using RAC & BBP balance day of was the best way to be inclusive
* Since the code did not offer partial payments, I did not adjust for this and respected what the code was written to do

Thats someone elses node; I will repoint that one right now.

Just found a solo block.
Seems the new miner try sending xx times the same share.
I've replaced the params value by ... for best reading, but was the same value for each.
So it's 1 accepted and 12 rejected.
Running on 12 cores, probably a relationship.

[2020-01-20 14:27:15] DEBUG: got new work in 3 ms

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:20] accepted: 1/1 (100.00%), 159.00 khash/s (yay!!!)

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:25] accepted: 1/2 (50.00%), 151.49 khash/s (booooo)
[2020-01-20 14:27:25] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:29] accepted: 1/3 (33.33%), 141.08 khash/s (booooo)
[2020-01-20 14:27:29] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:34] accepted: 1/4 (25.00%), 144.30 khash/s (booooo)
[2020-01-20 14:27:34] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:38] accepted: 1/5 (20.00%), 158.82 khash/s (booooo)
[2020-01-20 14:27:38] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:42] accepted: 1/6 (16.67%), 157.78 khash/s (booooo)
[2020-01-20 14:27:42] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:47] accepted: 1/7 (14.29%), 157.52 khash/s (booooo)
[2020-01-20 14:27:47] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:51] accepted: 1/8 (12.50%), 158.96 khash/s (booooo)
[2020-01-20 14:27:51] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:56] accepted: 1/9 (11.11%), 157.34 khash/s (booooo)
[2020-01-20 14:27:56] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:00] accepted: 1/10 (10.00%), 159.26 khash/s (booooo)
[2020-01-20 14:28:00] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:05] accepted: 1/11 (9.09%), 153.30 khash/s (booooo)
[2020-01-20 14:28:05] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:09] accepted: 1/12 (8.33%), 144.01 khash/s (booooo)
[2020-01-20 14:28:09] DEBUG2: reject reason: duplicate

!!
 SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]

!! bbphash
 - HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]


SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:17] accepted: 1/13 (7.69%), 149.78 khash/s (booooo)
[2020-01-20 14:28:17] DEBUG2: reject reason: duplicate
[2020-01-20 14:28:17] DEBUG: got new work in 9 ms
[2020-01-20 14:29:17] DEBUG: got new work in 13 ms

Hi Rob,

dns4.biblepay.org is still on version 1.4.8.4 - Could you please upgrade that one?