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

Yes, I could tell by the slang!  Thanks!

If your wallet is encrypted, you can either unlock it manually with 'walletpassphrase pass 99999' and try again, or enter the pass into the dialog when the wallet boots.

Or you can send the BBP out to a dedicated node with an unencrypted wallet.

Try 'exec podcupdate' to know if your wallet is open and unlocked.  If it says true, the PODC miner will work over the long term.

Regarding the go live instructions, yes, Ill take a look at those two wikis and post them ASAP.  I think Togo has already rewritten one of them.

Yes, Togo has the information required almost ready probably.

Are you referring to the testnet or production with the problem you are having?

That wasn't you in the test forum??

as we are 2-3 days away to mandatory update, will there be some manual how to set new release? i just tryied new release but got:  "poolinfo1": "Failed to sign CPID signature (unlock wallet)? not only gui, but also cli versions...

RPM? I do only DEB

But I uploaded a new release today, as we are getting closer to the next big release
The Launchpad Ubuntu Repository now contains Biblepay 1.0.9.7
I will do every release again from now on, as it seems that we have the heavy development of PoDC now behind us.

lol as i see, i'm already on testnet forum , somebody act as me and as bonus he got ban
i never was registered there

I agree, but I think the issue was in the past the exchanges had taken more than a week to put us into maintenance modes whereas this time is was only a few hours.  So the choice becomes either keep in maintenance mode for weeks to intentionally delay PoDC, or release PoDC if it's ready and hope the exchanges are back up in a few days.

Hit me up on Slack if you need Sanctuary help, but I would hope Lichtsucher is able to trigger a new RPM once there is enough confidence that this won't end up trigger a flurry of mandatory upgrades.

I also think we should have had more time. I don't know why it matters to give the botnet less time to prepare.

Is there going to be a RPM release pretty soon? I'm using it for my sanctuary right now but if there is going to be a delay I might compile my own.

My thoughts in part echo the Dev.

First, we likely have or will have a significant botnet (50%+) without a change.

The reasons I think botnets will struggle with PoDC are:

It's tougher to setup.  The prototypical botnet operation requires smaller programs that are easy to automate.  PoBH fit that criteria.  Adding BOINC to the mix, another level of registration (which could if there was a bot net operating, lead authorities to trace them easier, or for the coin to block them easier)

Small computers don't get the same boost with PoDC as they did with PoBh.  With PoBH, you were better off running 20 wallets on 1 core, than 1 wallet on 20 cores (although that was not the intent, it was true for most of the time in practice).  I've tested with my home system (Xeon X5650) and a VPS where I was allowed to use 100% of the CPU.  The best VPS instance was about 1/15th the power of my home system, but by the CPU type it should have been about 1/8.  This leads me to believe VPS won't be very effective on PoDC.  And since a botnet is really at it's heart little different from a technical standpoint than a user with many VPS (but very different from a legal standpoint), I believe this will reduce the returns on botnets.  Coupled with the increased work to maintain them and the risk of having to register them, I would be inclined to believe the botnet threat will be greatly reduced (although not eliminated).


On the positive side, now a botnet, if it stays with us, will at least give something back to society while they use their stolen hardware.

It is unfortunate that the change is coming with so little warning, but for once the exchanges were on the ball with the maintenance requests and the other option would be to delay PoDC while the exchange wallets were on maintenance, which would mean a longer wait for them to come back out of maintenance and that would not be good for the coin.  Is it ideal?  No but it is what we're facing and we can make the best of it.

Lets debug this in the testnet thread; no more testnet posts on the main thread.

I agree that a small heads-up to the community would have been ideal, but I guess the exchanges reacted faster than expected, so let's go forward from where we are now.

For anyone that had been out-of-the-loop a bit: we've been testing PODC in testnet for a while now, and things are looking bright.
If you want more information about PODC, I recommend that you read these two pages of our wiki (and prepare accordingly if you'd like):

http://wiki.biblepay.org/Distributed_Computing
http://wiki.biblepay.org/Distributed_Computing_Start_Guide

1.3.2018 20:45 worked excellent.... when i checked today, last 3 days im without PODC PAYMENT and UTXO+TASK=0... i tried exec associate podcupate but response is FALSE  



dont understand what you think ... ive tried

exec associate email pass force
exec associate email pass force=true


im only here....dont want other forum,etc...


and tried change my admin-wallet from virtuallinux to gamePC with that force command but without chance

something is wrong with this commands, you did update and again it went wrong

user ORBIS tested it with me,and same bugs

1) Check to see when your last podc update was - in qt mode - its called "PODC UPDATE" in the tx list.  If > 24 hours, your utxo weight goes to zero.

2) Substitue the word "true" for "force=true".

3) This is not the testnet thread.

bible_pay what happened in testnet? my utxo+task is 0 and last 5days worked stable,RAC raised....  and next causion,i cant change CPID to other wallet ... exec associate email pass force or exec associate email pass force=true didnt work : answer was already in chain ... what is it? thx

I agree in the sense that the machines out there will fill the void, but I feel that if these 3 criteria are met we would no longer consider it a bad botnet:
- The supermajority upgrades within 7 days when we have a future mandatory (in 'exec versionreport')
- There is a level of accountability in the Pool reports, in the leaderboard giving us an idea of magnitude per CPID, and computer count per CPID
- 100% of the machines receiving rewards are executing cancer research

Right now, all 3 fail, because during the last mandatory, it took a month for people to upgrade (we had 50% on the new version for 30 days - impacting security as it was a little hard to reach a supermajority), We have no idea where the mining concentration is - if its a botnet - or what it is currently - 93% of the hashpower appears to be on a version 10 versions back - for all I know it could be a self compiled version - and finally not sure if people are playing some type of game - IE communicating data back and forth via private pools or nodes, etc. 

So I look forward to this shining light on the above issues and giving us a higher QOS.

I opened a ticket and gave them a 10 day notice, but they were highly responsive and took us down right away.

So now lets take advantage of this lull, and Ill get us a block number today for cutover.

I'm not optimistic about getting rid of botnet (or botnets) because they can switch to new PoDC at some moment. Anyway they will contribute to cancer research and definitely this is the way to go for BBP.

Giving meaning to the coin (charity, orphans, cancer research, banking the unbanked) means adding highest value and a will for persistence, in a world where we will see hundreds of crapcoins wiped out sooner or later.

hmm but you might announce maintenance few days before, now i had quite a big amount on c-cex without possibility to withdraw... and this could be dangerous these days as everybody fighting against c-cex due to xvg ...

I had the exchanges put us in maintenance.

If all goes well tomorrow in Testnet, we are going to go live with PODC in approximately 72 hours.

This is primarily to give the botnet as little time as possible to react.

This is called a Ninja mandatory upgrade.

 

PS - I plan on merging in the prod changes tomorrow morning, then releasing the client to testnet and testing with the testers.  If no bugs appear, then we switch over to the mandatory approximately Wednesday night, then if all goes well we ask the exchanges to re-enable after Thursday morning (that could take 1-9 days...)