Bitcoin Forum
July 21, 2018, 05:01:18 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 [348] 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 ... 459 »
  Print  
Author Topic: BiblePay | Masternodes | Sanctuaries | POBH - ASIC Resistant | 10% ORPHANS  (Read 86741 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
zthomasz
Member
**
Online Online

Activity: 266
Merit: 12

Thank you God for saving us!


View Profile
April 19, 2018, 03:42:55 PM
 #6941

Quote
I redeployed- will someone please confirm they have upgrade to 1.1.2.2?

Thanks!

just download and installed... its still 1.1.1.9

Alright, sorry about the inconvenience all, deployment system has been fixed.

Now you should be able to download 1.1.2.2.



Confirmed!  Cool

fyi .. anyone who tried to download windows 64 wallet earlier may have to clear their browser cache to get the updated link to work.
1532149278
Hero Member
*
Offline Offline

Posts: 1532149278

View Profile Personal Message (Offline)

Ignore
1532149278
Reply with quote  #2

1532149278
Report to moderator
1532149278
Hero Member
*
Offline Offline

Posts: 1532149278

View Profile Personal Message (Offline)

Ignore
1532149278
Reply with quote  #2

1532149278
Report to moderator
1532149278
Hero Member
*
Offline Offline

Posts: 1532149278

View Profile Personal Message (Offline)

Ignore
1532149278
Reply with quote  #2

1532149278
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1532149278
Hero Member
*
Offline Offline

Posts: 1532149278

View Profile Personal Message (Offline)

Ignore
1532149278
Reply with quote  #2

1532149278
Report to moderator
slovakia
Full Member
***
Offline Offline

Activity: 378
Merit: 100



View Profile
April 19, 2018, 03:59:03 PM
 #6942

win updated to 1122

working

🕇 BiblePay | Masternodes | CPU only | ROSETTA@HOME Curing diseases | 10% goes to charity 🕇

BiblePay (BBP) | Reddit - Twitter - Forum - Slack - Discord | C-CEX - CoinsMarkets
inblue
Full Member
***
Offline Offline

Activity: 294
Merit: 102



View Profile
April 19, 2018, 05:28:28 PM
 #6943

So far I've got 2 smaller machines that have been up for a week and are showing mid 2300 under host average credit (in BOINC), and the two identical machines to those were showing 3800 RAC.

I did fire up four identical heavier computers last night ,two on R@h and two on WCG, it will take until the end of the weekend to begin to get meaningful data from those.

Would you mind telling exactly which processors are in the "smaller" and "heavier" computers? I am wondering approximately how much RAC is obtained in regard to computing power. Thank you.

https://boinc.bakerlab.org/rosetta/cpu_list.php will give you a lot of insight on what you can do per processor in the real world.  GLOPS * 200 = RAC.

Thank you, good sir!

🕇 BiblePay 🕇
🕇  Announcement | ForumSlackDiscordRedditTwitter | SouthXchangeC-CEX  🕇
🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇
616westwarmoth
Full Member
***
Offline Offline

Activity: 322
Merit: 101


View Profile
April 19, 2018, 06:31:05 PM
 #6944

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

▄    BIBLEPAY    ▄    The Cryptocurrency for Christians    ▄     BIBLEPAY   
   Reddit      ANN Page      Biblepay Forum  
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
bible_pay
Full Member
***
Offline Offline

Activity: 378
Merit: 114



View Profile WWW
April 19, 2018, 07:29:54 PM
 #6945

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.

The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).


🕇 BiblePay 🕇
🕇  Announcement | ForumSlackDiscordRedditTwitter | C-CEXCoinsMarkets  🕇
🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇
dave_bbp
Jr. Member
*
Offline Offline

Activity: 210
Merit: 3


View Profile
April 19, 2018, 08:20:46 PM
 #6946

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).


I'm not sure you understood the problem people have with the current rules: There was a vote for how much there should be staked to get full PODC reward. The vote came down to "(at least) 20 BBP per RAC" for full reward (meaning 100%). This voting result should be the corner stone (the anchor) of every "grid" that is applied to determine the amount of payout.
Right now people can stake "only" 91% of the 20BBP/RAC and nevertheless receive the full payout (contrary to the voting result). So west tried to come up with some ways to circumvent this dilemma.

Don't get me wrong, I myself don't want it to change right now because last time I checked I also was only staking something around 93%. Smiley
616westwarmoth
Full Member
***
Offline Offline

Activity: 322
Merit: 101


View Profile
April 19, 2018, 08:22:30 PM
 #6947

I don't think it should be that way. It shouldn't be rounded up or down, and then by how much? 10%? The client is already rounding up by 10% just in case if you use the automatic update, I don't think the sanctuaries should round up anything.
The client rounds up by 10% via PoDCUpdate because in part, it's only checking your RAC one time a day.  So if you were the normal expected user, had one PC on BOINC and decided you could put your spouse's computer on it, then the first day it was up it could very well get enough RAC to push you out of 100% without the buffer.  RAC does vary day to day, I've seen swings on an individual computer by as much as 10%, so again, the 10% buffer should protect against that.

I would generally agree with your point that 20 should be 20 (even though that was not my vote).  Which I guess three ways to accomplish this:
The first would the least work, get close enough to "correct" and that would be use normal rounding, so 4.99% would be 0%, 5.0% would be 10%, 94.999% would be 90%, and 95.0% would be 100%.  Really I think this is a good solution as it would simplify the "current less than 5% special case".
The second would be to round everything down to a multiple of 10% (which would either change the 5% special case or require it to be written as en exception.
The third would be to add a 2nd special case and 90% go from 80.1%-99.9% and 100% only trigger at 100%, which doesn't seem entirely unfair, but really seems like far more work than the first idea.

I really don't understand why you wrote all this West, as it doesn't take into account the Snap-to-Grid IT requirement in the actual PODC protocol.

It's sort of confusing everyone, as it's alluding to "a possible change" in the protocol, when we already voted the protocol in.

The UTXO requirement is 20 bbp per RAC.  The UTXO breaks chart rounds up to the nearest 10%.  Lower than 5% rounds DOWN to zero %.

The only potential recommendation I have is to ask Jaap if he wants to create a 2nd chart in percentages, so people have a chart with a larger scale (maybe they understand percentages better than static BBP amounts per break, thats up to him).

I wrote to explain why the 10% round up in staking occurs.  I also agree that the current rounding seems slightly out of correspondence with the vote of 20 BBP per RAC to get 100%.  

I am not claiming the system works in any way other than round up to 10% except in the under 5% special case.  I trimmed too much of the quote I suppose to keep that part in context.  I was merely stating the three possible ways of handling this although I never stated this as a "possible change".  Merely as a way to spark discussion on if there were a sufficient number of users that felt the system was in need of a small tweak.  And really, if it were up to me (which it's not, short of making a proposal and seeing if it passes) I think rounding to the nearest 10% is easier to explain and eliminates the need for a special case for the 5% rule.  But I do think that discussion deserves some consideration if for no other reason than simplification.


▄    BIBLEPAY    ▄    The Cryptocurrency for Christians    ▄     BIBLEPAY   
   Reddit      ANN Page      Biblepay Forum  
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
seeksilence1
Jr. Member
*
Offline Offline

Activity: 77
Merit: 0


View Profile
April 19, 2018, 10:01:08 PM
 #6948

Try to update win wallet but it stucks on sync. What should I do? Delete some dat files?
zthomasz
Member
**
Online Online

Activity: 266
Merit: 12

Thank you God for saving us!


View Profile
April 19, 2018, 10:53:28 PM
 #6949

Try to update win wallet but it stucks on sync. What should I do? Delete some dat files?

Here's a simple Win wallet cleanup guide:

Windows Cleanup:
- In Windows File Explorer enter: %appdata%/BiblePayCore
- Delete blocks and chainstate folders,
- Delete these files: banlist, fee_estimates, governance, mncache, netfulfiled and peers
- Add this line to biblepay.conf: addnode=node.biblepay-explorer.org
- In Wallet do Tools >> Wallet Repair >> Rebuild index
seeksilence1
Jr. Member
*
Offline Offline

Activity: 77
Merit: 0


View Profile
April 19, 2018, 11:48:37 PM
 #6950

Thanks. Adding the node works.
noxpost
Jr. Member
*
Offline Offline

Activity: 126
Merit: 1


View Profile
April 20, 2018, 01:41:21 AM
 #6951

Strangely, after updating both of my sancs oh, 13 hours ago, I've run into a problem.

They both ran ok for quite a while, but now both have stopped getting new blocks and a getinfo call shows 41632 as the block index (my Windows, and other block explorers, show 41638).

Anybody else running into any problems? Masternode sync status is 999, nothing is throwing errors...I'm not sure what's going on.
thesnat21
Jr. Member
*
Offline Offline

Activity: 140
Merit: 0


View Profile
April 20, 2018, 02:25:36 AM
 #6952

Strangely, after updating both of my sancs oh, 13 hours ago, I've run into a problem.

They both ran ok for quite a while, but now both have stopped getting new blocks and a getinfo call shows 41632 as the block index (my Windows, and other block explorers, show 41638).

Anybody else running into any problems? Masternode sync status is 999, nothing is throwing errors...I'm not sure what's going on.

I have 2 clients reporting "no block source available"
edit: the addnode to the config fixed them.. wonder if some main node is down?
MIP
Jr. Member
*
Offline Offline

Activity: 110
Merit: 0


View Profile
April 20, 2018, 02:34:49 AM
 #6953

I also have problems with my 1.1.2.2 clients, both crashed 2 hours ago while sleeping.

Windows one is stuck at 41624 and linux one (Sanc) in 41633 after manually restarting

Another windows 1.1.1.9 one is working fine at 41643, and C-Cex one too as well as block explorers.

Edit: they are syncing but veeeeeery slowly (1 block per 5 minutes)

I also see a lot of banned peers in the list.
noxpost
Jr. Member
*
Offline Offline

Activity: 126
Merit: 1


View Profile
April 20, 2018, 03:01:57 AM
 #6954

I shut them down and did a re- index which seemed to work. Curious... wonder what the root cause is.
slovakia
Full Member
***
Offline Offline

Activity: 378
Merit: 100



View Profile
April 20, 2018, 05:26:39 AM
 #6955

VPS crashed and WIN crashed too 1122
I also see a lot of banned peers in the list.

syncing MN is misery

🕇 BiblePay | Masternodes | CPU only | ROSETTA@HOME Curing diseases | 10% goes to charity 🕇

BiblePay (BBP) | Reddit - Twitter - Forum - Slack - Discord | C-CEX - CoinsMarkets
616westwarmoth
Full Member
***
Offline Offline

Activity: 322
Merit: 101


View Profile
April 20, 2018, 06:05:11 AM
 #6956

My MN crashed, last few lines before crash were below (linux, self compiled, v1122)

Code:
2018-04-19 23:59:02 Misbehaving: 112.205.222.61:29198 (0 -> 21)
2018-04-19 23:59:02 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:02 ERROR: AcceptBlockHeader: prev block not found
2018-04-19 23:59:02 Misbehaving: 194.182.65.32:49814 (0 -> 21)
2018-04-19 23:59:02 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:02 ERROR: AcceptBlockHeader: prev block not found
2018-04-19 23:59:02 Misbehaving: 125.230.124.228:59314 (0 -> 21)
2018-04-19 23:59:02 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:02 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:02 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:02 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:02 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:02 ERROR: Block has no ancestor.

2018-04-19 23:59:02 ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-04-19 23:59:03 ERROR: Block has no ancestor.

2018-04-19 23:59:03 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:15 DSEG -- Sent 187 Masternode invs to peer 7110


▄    BIBLEPAY    ▄    The Cryptocurrency for Christians    ▄     BIBLEPAY   
   Reddit      ANN Page      Biblepay Forum  
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
proofodc
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
April 20, 2018, 06:22:47 AM
 #6957

Same here, my 1122 Linux wallet crashed with this log:

Code:
2018-04-19 23:59:02 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:15 ERROR: AcceptBlockHeader: prev block not found
2018-04-19 23:59:15 Misbehaving: 104.167.12.124:40000 (0 -> 21)
2018-04-19 23:59:15 ERROR: invalid header received 3c9d97fc314d3676f6e3d347ec2aef314764f017dc65443210148c4402e548f1
2018-04-19 23:59:37 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:37 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:42 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:42 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:44 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:44 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:44 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:44 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-19 23:59:48 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-19 23:59:48 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-20 00:02:44 ERROR: AcceptBlockHeader: prev block not found
2018-04-20 00:02:44 Misbehaving: 173.208.160.82:40000 (21 -> 42)
2018-04-20 00:02:44 ERROR: invalid header received d6f99b2641ef0de0a941e3a6c677e039101ccbe152171d2d32a833237676d12f
2018-04-20 00:02:45 ERROR: AcceptBlockHeader: prev block not found
2018-04-20 00:02:45 Misbehaving: 192.187.98.210:40000 (21 -> 42)
2018-04-20 00:02:45 ERROR: invalid header received d6f99b2641ef0de0a941e3a6c677e039101ccbe152171d2d32a833237676d12f
2018-04-20 00:02:45 ERROR: AcceptBlockHeader: prev block not found
2018-04-20 00:02:45 Misbehaving: 104.167.12.124:40000 (21 -> 42)
2018-04-20 00:02:45 ERROR: invalid header received d6f99b2641ef0de0a941e3a6c677e039101ccbe152171d2d32a833237676d12f
2018-04-20 00:02:49 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-20 00:02:49 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-20 00:02:49 ERROR: AcceptBlockHeader: block is marked invalid
2018-04-20 00:02:49 ERROR: invalid header received 3fde3a41710e3e1c730731309e577519d0318b8d306136c8017dfcde656140d4
2018-04-20 00:02:50 ERROR: Block has no ancestor.

2018-04-20 00:02:50 ERROR: ProcessNewBlock: AcceptBlock FAILED

cryptocadxyz
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
April 20, 2018, 06:28:51 AM
 #6958

One of my Windows wallets crashed and was stuck a dozen blocks behind so I rebuilt the index. Noticed the other Windows wallet was also stuck, so I also rebuilt that index as well. Works now.
jaapgvk
Full Member
***
Offline Offline

Activity: 336
Merit: 103



View Profile
April 20, 2018, 07:42:27 AM
 #6959

One of my Windows wallets crashed and was stuck a dozen blocks behind so I rebuilt the index. Noticed the other Windows wallet was also stuck, so I also rebuilt that index as well. Works now.

Same here.

🕇 BiblePay 🕇
🕇 Announcement | ForumDiscordRedditTwitter | C-CEXQIEX 🕇
🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇
jaapgvk
Full Member
***
Offline Offline

Activity: 336
Merit: 103



View Profile
April 20, 2018, 07:56:36 AM
 #6960

Got your newsletter again Mike, warning me that the update was needed.

Everyone: if you want to get notified on mandatories, go to https://bbppodc.org/ and sign up for the notification-newsletter.

But that got me wondering: I don't think that this update was explicitly a posted as a mandatory. At least, I don't remember reading that. But the current state of the network begs the question if maybe many users didn't perceive this update to be mandatory?

I'm just a bit confused here Smiley

🕇 BiblePay 🕇
🕇 Announcement | ForumDiscordRedditTwitter | C-CEXQIEX 🕇
🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇
Pages: « 1 ... 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 [348] 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 ... 459 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!