BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[dave_bbp]

It's a (standard) Rapsberry Pi 3 Model B. Right now it shows some crashes from time to time, but I think they hail from some overclocking-tests, apparently BBP already maxxes out the PI's capabilities. 

Regarding the "standalone": in theory this should be very well possible (although currently I have problems with my pi not connecting to wifi, but that's of course unrelated to running BBP on it). However in my location (Germany) a solar powered pi is not very practical, I think I haven't seen the sun in like 4 days. xD

In southern countries this surely would be interesting; just send a person a fully configured Pi (biggest problem there being the wifi connection...) and the recipient plugs it into his solar powered microUSB cable and is good to go.

[1715450577]

1715450577

[1715450577]

1715450577

[1715450577]

1715450577

[jaapgvk]

Biblepay Security Alert Bulletin

A vulnerability has been discovered in Instant Send that can cause an attacker who has more than 10 million BBP to double spend an instant send transaction, if they hijack the instant send attempt from their sanctuary-farm.

To mitigate this, if you are running a version prior to 1.0.7.7, please DO NOT USE INSTANT SEND to send funds.

We are patching this now in 1.0.7.7.

I updated my sanctuary to 1.0.7.7. But now I get a "Not capable masternode: Invalid protocol version" error. My controller wallet is on 1.0.7.6.

Sanctuary wallet is protocolversion 70713
Controller wallet is protocolversion 70712

What should I do?

We're going to need to make this a mandatory upgrade to finish it.  I don't see any 70713's in the sanctuary list.

Fortunately we are still down at c-cex, so we have a chance to do this.

Standby, let me build a system wide 70713 mandatory upgrade. 

I updated both wallets, restarted my sanctuary, and now all seems fine again. Thanks! And Alex, also thanks for your help

Now I'm on 1.0.7.7. just let me know if I can help you test anything.

[danielone80]

Hi,
is there any chance to run a CPU miner for BibblePay on a centos7 on PPC(powerpc) 6.4?

thank you
Daniel

almost certainly.. have you  compiled miners/wallets before on that platform?

Hi,
I'm trying with all the cpu miner but I cannot make it , some compile and install, but then never a yay !!! :-(

I asked if there was any trick or suggestion on :-)

Regards
Daniel

[x5650]

Constantly having to log in on pool page is anoying, is that a must?

[bible_pay]

Constantly having to log in on pool page is anoying, is that a must?

Ensure cookies are enabled.

[bible_pay]

Biblepay Security Alert Bulletin

A vulnerability has been discovered in Instant Send that can cause an attacker who has more than 10 million BBP to double spend an instant send transaction, if they hijack the instant send attempt from their sanctuary-farm.

To mitigate this, if you are running a version prior to 1.0.7.7, please DO NOT USE INSTANT SEND to send funds.

We are patching this now in 1.0.7.7.

I updated my sanctuary to 1.0.7.7. But now I get a "Not capable masternode: Invalid protocol version" error. My controller wallet is on 1.0.7.6.

Sanctuary wallet is protocolversion 70713
Controller wallet is protocolversion 70712

What should I do?

We're going to need to make this a mandatory upgrade to finish it.  I don't see any 70713's in the sanctuary list.

Fortunately we are still down at c-cex, so we have a chance to do this.

Standby, let me build a system wide 70713 mandatory upgrade. 

I updated both wallets, restarted my sanctuary, and now all seems fine again. Thanks! And Alex, also thanks for your help

Now I'm on 1.0.7.7. just let me know if I can help you test anything.

Yeah, 70713 1.0.7.7 didnt work, bumping up to 70714 1.0.7.8 now.
Unofficial release still compiling...

[joelles]

Hi,
is there any chance to run a CPU miner for BibblePay on a centos7 on PPC(powerpc) 6.4?

thank you
Daniel

almost certainly.. have you  compiled miners/wallets before on that platform?

Regarding the endless questions about the pool rewards, there is far less hashpower there than people think. Maybe only 1 - 2 MHs. So the total networkhashrate could be as low 5 MHs. Anyone with a bunch of powerful CPUs will be better off solo mining as 1. they won't be subsidising us little guys and 2. they won't be paying pool fees. The only way for the pool to get more blocks is to put more hash on it, and perhaps preferably in a few big chunks rather than 100s of little workers. Suggestions anyone?

Referring to the  big chunks vs little workers :  In my experience it has been untill now  still far more efficient to operate with 16 x 1 vCPU   instead of  one 16 threads CPU (e.g. Ryzen1700)

Yes, best to mine with vCores due to shares system, more boxes = more shares

Exactly. But the shares system is only on the pool, isn't it? Or does it apply to solo as well?
By the way, how much hashps does that Ryzen give with 16 threads?

yes for pool hit blocks, more shares is more part from block

[bible_pay]

BiblePay - Mandatory Upgrade
1.0.7.9

- Fix InstantSend Security Bug

[capulo]

mandatory to who? all or only sanctuaries?
and what block number to apply?

[togoshigekata]

BiblePay - Mandatory Upgrade v1.0.7.9

- Fix InstantSend Security Bug

Wallet Update Instructions: 
https://www.reddit.com/r/BiblePay/comments/7nmvm8/how_to_update_clean_wallets/

This is also a protocol version update, so Sanctuary owners will need to start Sanctuary again after updating

[zthomasz]

mandatory to who? all or only sanctuaries?
and what block number to apply?

Yes, would like to know the Mandatory Upgrade deadline block number. Also, what is the number of the next super block?

[capulo]

somebody just buy about 10 000 000 bbp for 80000$ , isnt this required amount for instant send security bug?

[616westwarmoth]

somebody just buy about 10 000 000 bbp for 80000$ , isnt this required amount for instant send security bug?

Where did you see this transaction?

[chessentric]

Oh no... I hit a manual withdrawal from the pool, and noticed that it didn't go through. I just saw this and I was running 1.0.7.6.
I suppose my coins are now lost as my client was on the old version?

[zthomasz]

Oh no... I hit a manual withdrawal from the pool, and noticed that it didn't go through. I just saw this and I was running 1.0.7.6.
I suppose my coins are now lost as my client was on the old version?

Here's what Rob posted earlier ...

Biblepay Security Alert Bulletin

A vulnerability has been discovered in Instant Send that can cause an attacker who has more than 10 million BBP to double spend an instant send transaction, if they hijack the instant send attempt from their sanctuary-farm.

To mitigate this, if you are running a version prior to 1.0.7.7, please DO NOT USE INSTANT SEND to send funds.

We are patching this now in 1.0.7.7.

Note: Once you are on 1.0.7.7 a new protocol is used in instant send.

Apparently you are OK if you don't us Instant Send to send funds.

[zthomasz]

somebody just buy about 10 000 000 bbp for 80000$ , isnt this required amount for instant send security bug?

@capulo ... be helpful and post some evidence for this supposed 10-Million BBP / $80,000 transaction.

[bible_pay]

Oh no... I hit a manual withdrawal from the pool, and noticed that it didn't go through. I just saw this and I was running 1.0.7.6.
I suppose my coins are now lost as my client was on the old version?

The only coins that can be lost are:  Coins mined on a fork, coins sent to an address you do not control, or coins in a lost wallet.

But coins sent from the wrong version to a wallet you control can be tracked.

PM me the txid.

[bible_pay]

mandatory to who? all or only sanctuaries?
and what block number to apply?

Sorry for the ambigious post and zero day deadline.

There are a lot of reasons for this, none are optimal:

- The upgrade is system wide for both core clients and sanctuaries.  Primarily because the instand send change requires a new instantsend vote algorithm, so we needed the entire network to upgrade (the sender and the facilitator and the receiver).

- There is no block number in this case, because the cutover involves a protocol change and is not driven by a block.

- Unit testing "appeared" to succeed, so I pushed 1077, and then discovered an additional bug.  That left the network partially upgraded and in a state where the only way to fix it is to force a mandatory the rest of the way.  (With 1.0.7.9).

- I want to get a supermajority of sanctuaries upgraded on 1.0.7.9 relatively soon since we only have 7 days left before c-cex reopens, and he said he might be opening early and I have a message in his inbox to compile BBP. 

As far as whats going on behind the scenes, the code wants 10 instand send Votes on 1.0.7.9 before it falls through to Sign the transactions, and 1.0.7.9 requires these votes to be placed within 60 seconds.  What Im seeing in the log is about 6 votes, but after trying 50+ times, Im still only seeing 6 votes.  Im under the impression that we just have to wait for more Sancs to upgrade to 1.0.7.9.

[chessentric]

Oh no... I hit a manual withdrawal from the pool, and noticed that it didn't go through. I just saw this and I was running 1.0.7.6.
I suppose my coins are now lost as my client was on the old version?

The only coins that can be lost are:  Coins mined on a fork, coins sent to an address you do not control, or coins in a lost wallet.

But coins sent from the wrong version to a wallet you control can be tracked.

PM me the txid.

Rob, zthomasz, thank you for the quick response. I upgraded my wallet to 1.0.7.9 and shortly after I just saw the transaction show up as pending. it's probably just a coincidence and has nothing to do with my upgrade then. I only thought something was off because I am used to the withdrawals being almost instantly picked up by the core, but in this case, I waited for a while after the withdrawal and saw nothing. Apologies for my erroneous conclusion, and again thank you for your promptness on this. I appreciate the significant work that you put into this as a dev and am grateful that you are concerned even for tiny members of the pool like myself. I have hope that faithfulness in little will translate into faithfulness in much with regards to this project.

[znffal]

mandatory to who? all or only sanctuaries?
and what block number to apply?

Sorry for the ambigious post and zero day deadline.

There are a lot of reasons for this, none are optimal:

- The upgrade is system wide for both core clients and sanctuaries.  Primarily because the instand send change requires a new instantsend vote algorithm, so we needed the entire network to upgrade (the sender and the facilitator and the receiver).

- There is no block number in this case, because the cutover involves a protocol change and is not driven by a block.

- Unit testing "appeared" to succeed, so I pushed 1077, and then discovered an additional bug.  That left the network partially upgraded and in a state where the only way to fix it is to force a mandatory the rest of the way.  (With 1.0.7.9).

- I want to get a supermajority of sanctuaries upgraded on 1.0.7.9 relatively soon since we only have 7 days left before c-cex reopens, and he said he might be opening early and I have a message in his inbox to compile BBP.  

As far as whats going on behind the scenes, the code wants 10 instand send Votes on 1.0.7.9 before it falls through to Sign the transactions, and 1.0.7.9 requires these votes to be placed within 60 seconds.  What Im seeing in the log is about 6 votes, but after trying 50+ times, Im still only seeing 6 votes.  Im under the impression that we just have to wait for more Sancs to upgrade to 1.0.7.9.

Awesome. I'm in the process of upgrading now.
For clarity, will older versions not be able to mine unless they upgrade?

Thanks

(Btw, up to 100 votes to get BBP on next.exchange! Thanks and keep it up all https://nextexchange.featureupvote.com/suggestions/3384/biblepay-bbp#comment30547 )