Is it have a backup plan if BOINC status down a few days/weeks/months  BOINC seems to be working for me.. And yes there are disaster recovery plans |
|
|
|
I've been using pool2 no ssl
will try pool
pool.biblepay seems to be reporting less errors but still has several. It seems over 114k fails |
|
|
|
Could you please go into coin control and consolidate your wallet down to less outstanding balances, and see if it goes away? Pool header is already 1 megabyte.
Just so we know if that is the problem....
You would probably need to do this and ensure the wallet.dat is re-copied out to each miner *after* the consolidation is complete.
Did the consolidation, still reporting the same error on that client I exported the headers, and the file is only 76kb, way under the 1mb limit and it is still reporting the error The ones that succeed are ~64kb It seems to cycle between the two, works for a while then doesn't for a while Which pool url are you using btw (we have 2), also do me a favor while Im at church, can you try non https? Change to: http://pool.biblepay.orgpoolport=80 Just let me know if it fixes it so I can hone in on the header change tonight, thanks! (Maybe we never extended the size for https 443). I've been using pool2 no ssl will try pool |
|
|
|
Could you please go into coin control and consolidate your wallet down to less outstanding balances, and see if it goes away? Pool header is already 1 megabyte.
Just so we know if that is the problem....
You would probably need to do this and ensure the wallet.dat is re-copied out to each miner *after* the consolidation is complete.
Did the consolidation, still reporting the same error on that client I exported the headers, and the file is only 76kb, way under the 1mb limit and it is still reporting the error The ones that succeed are ~64kb It seems to cycle between the two, works for a while then doesn't for a while |
|
|
|
The main pool keeps returning an error: <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Bad Request - Header Field Too Long</h2> <hr><p>HTTP Error 400. A request header field is too long.</p> </BODY></HTML> Rob can you look at this, several shares appear to be rejected due to this error Could you please go into coin control and consolidate your wallet down to less outstanding balances, and see if it goes away? Pool header is already 1 megabyte. Just so we know if that is the problem.... You would probably need to do this and ensure the wallet.dat is re-copied out to each miner *after* the consolidation is complete. I'll give it a go.. where is the "coin control" in the wallet? edit: just sent everything to 1 of my addresses. will let you know |
|
|
|
The main pool keeps returning an error: <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Bad Request - Header Field Too Long</h2> <hr><p>HTTP Error 400. A request header field is too long.</p> </BODY></HTML> Rob can you look at this, several shares appear to be rejected due to this error |
|
|
|
The main pool keeps returning an error: <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Bad Request - Header Field Too Long</h2> <hr><p>HTTP Error 400. A request header field is too long.</p> </BODY></HTML> |
|
|
|
|
Rob,
What does "HIGH_HASH" error mean on the biblepay pool?
|
|
|
|
I'm very aware that this coin needs more exposure, but I don't think that it needs a fixed 20BBP/RAC staking requirement in order to grow. It could very well become a reason why the coin can fail. As far as I'm concerned, it's a way to fight botnets, but it shouldn't prevent people from joining us because they just can't afford it.
I agree completely. The minimum required stake hurts things as well. There are a few whales owning the heat mining, probably the same owning PODC |
|
|
|
BBP is a professional miner. He might keep some, right now he has to stake for rewards, but he sure is going to sell some and introduce supply.
I asked a few weeks back if some one wanted to help me put together a Biblepay faucet with a paper wallet generator and we could go to churches and hand out 5 free bbp per person as paper wallets to try to get people who normally might not be interested in crypto but are interested in the idea of supporting orphans and the needy to participate. I didn't get any responses, though.
Depending on what he makes, and sells either of these large miners could easily devalue the currency... Considering they are making 600$ + per day. (approx 1/3 our daily volume according to CMC.. lol) |
|
|
|
58 Million Biblepay coins tied up in mining, just by the top 3 Biblepay whales!
BBP
Onii-Chan
Mike
I never expected Onii to drop to #2 to be overtaken by a bigger whale...
Its even more fascinating that User #1 is at 90% UTXO because his RAC is rising faster than his 26.4 Million stake requirement.
Wow! That's crazy to see. If I look at the superblock view, there's something like 160M in PODC staking total. and then there are around 189 masternodes configured, so let's call that another 292M in masternode staking. That makes 160+292 = 452M total reserved for staking, out of a total supply of 600M. >75% of our total supply is reserved. Does that seem high to anyone? I don't know that it is a PROBLEM or anything, but it seems like a big percentage to me. I do agree that something needs to change here, I'm trying to get my Biblepay mining working correctly and just with my main desktop and a small older HP workstation server, my RAC is so high (11K), I would need over 300K coins to get the full rewards, which right now, costs about $1000usd. I understand trying to eliminate the botnet, etc., but this seems a little over the top. You basically have to have a mini-masternode just to be able to mine the coin. This was my concern with the 20BBP/Rac. The system is weighted heavily for those big fish... the barrier to entry is still very high, and the rewards at the bottom are hard to come by. The current situation is, you can make money if you buy your way in, but even that has diminishing returns.. |
|
|
|
|
Is there an issue with purepool? I was mining all yesterday and have not received payout for any block after 43053
It seems all shares after the last payout have been stalled (checked several of the top miners, they show the same)
|
|
|
|
Actually if you watch closely, after the heat mined block is 15.01 minutes of age (IE no one found the block), the pool CPIDs who are mining at that time have the errors cleared. Those miners are then marked as "eligible". The miner who finds the heat mined block that is > 15 mins old gets 100% of the block in the pool. No, the pool does not make any profits except the about page %. Please see the pool block distribution for who is getting the payments today  . Thanks for the clarification, I forgot about the 15 minute rule! |
|
|
|
|
Since nobody was in the last superblock, and we have this requirement for heatmining....
Does this mean the exchange (purepool/pool.biblepay etc) keep all profits for the day?
|
|
|
|
No, we have more than one addnode domain in there, and anyone can volunteer to add more addnodes, and the wallet supports dns seeds, etc, you should really read up on DNS seeds in bitcoin.
But I guess the main point I want to make is: if cloudflare goes down and the biblepay.org domain is hijacked, no one is stuck, because the peers.dat would be populated - most of the time a new node will just ask the network for *any* peer in IRC, we just need 1 working node;
Anyway to make it even more resilient ill add a few of my Sancs IPs in the core wallet. This only affects a brand new node who has never contacted a peer.
I was referring specifically to using the biblepay.org subdomains for all the default nodes... Yes technically there are many, but if the newbie seeds are controlled by a single master, or if one of the key nodes gets hijacked (chain forked) or some other issue it could cause an issue.. I'm not trying to nit pick, I just think it would be better to have more options so it is more secure in the long-run. As for the "only time", this happened a lot the past week when there were sync issues, and people had to basically restart their clients... Honestly I am trying to help, if you would prefer I keep quiet then I can do that. |
|
|
|
Trying to compile the wallet on linux and getting this error: CXX libbitcoin_wallet_a-keepass.o
CXX wallet/libbitcoin_wallet_a-crypter.o
wallet/crypter.cpp: In function 'void PrintStratisKeyDebugInfo()':
wallet/crypter.cpp:176:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (int i = 0; i < sKey1.length(); i++)
^
wallet/crypter.cpp:182:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (int i = 0; i < sIV1.length(); i++)
^
wallet/crypter.cpp: In function 'bool BibleEncrypt(std::vector<unsigned char>, std::vector<unsigned char>&)':
wallet/crypter.cpp:196:17: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
EVP_CIPHER_CTX ctx;
^
wallet/crypter.cpp: In function 'bool BibleDecrypt(const std::vector<unsigned char>&, std::vector<unsigned char>&)':
wallet/crypter.cpp:214:20: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
EVP_CIPHER_CTX ctx;
^
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-self-assign'
Makefile:6506: recipe for target 'wallet/libbitcoin_wallet_a-crypter.o' failed
make[2]: *** [wallet/libbitcoin_wallet_a-crypter.o] Error 1
make[2]: Leaving directory '/home/biblepay/biblepay/src'
Makefile:9289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/biblepay/biblepay/src'
Makefile:652: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
Can anyone help me? Thank you! Fixed this on mine, tried asking Rob about it... This is related to the openssl dependency the 1.10+ has a change in how the object is referenced. i'm not sure why but this block was half implemented (partial code exists to fix the error, but is incomplete) open file: src/wallet/crypter.cpp change bool BibleEncrypt(std::vector<unsigned char> vchPlaintext, std::vector<unsigned char> &vchCiphertext)
{
if (!fKeySetBiblePay) LoadBibleKey("biblepay","eb5a781ea9da2ef36");
int nLen = vchPlaintext.size();
int nCLen = nLen + AES_BLOCK_SIZE, nFLen = 0;
vchCiphertext = std::vector<unsigned char> (nCLen);
EVP_CIPHER_CTX ctx;
// EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
bool fOk = true;
EVP_CIPHER_CTX_init(&ctx);
if (fOk) fOk = EVP_EncryptInit_ex(&ctx, EVP_aes_256_cbc(), NULL, chKeyBiblePay, chIVBiblePay);
if (fOk) fOk = EVP_EncryptUpdate(&ctx, &vchCiphertext[0], &nCLen, &vchPlaintext[0], nLen);
if (fOk) fOk = EVP_EncryptFinal_ex(&ctx, (&vchCiphertext[0])+nCLen, &nFLen);
EVP_CIPHER_CTX_cleanup(&ctx);
if (!fOk) return false;
vchCiphertext.resize(nCLen + nFLen);
return true;
}
bool BibleDecrypt(const std::vector<unsigned char>& vchCiphertext,std::vector<unsigned char>& vchPlaintext)
{
LoadBibleKey("biblepay","eb5a781ea9da2ef36");
int nLen = vchCiphertext.size();
int nPLen = nLen, nFLen = 0;
EVP_CIPHER_CTX ctx;
// EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
bool fOk = true;
EVP_CIPHER_CTX_init(&ctx);
if (fOk) fOk = EVP_DecryptInit_ex(&ctx, EVP_aes_256_cbc(), NULL, chKeyBiblePay, chIVBiblePay);
if (fOk) fOk = EVP_DecryptUpdate(&ctx, &vchPlaintext[0], &nPLen, &vchCiphertext[0], nLen);
if (fOk) fOk = EVP_DecryptFinal_ex(&ctx, (&vchPlaintext[0])+nPLen, &nFLen);
EVP_CIPHER_CTX_cleanup(&ctx);
if (!fOk) return false;
vchPlaintext.resize(nPLen + nFLen);
return true;
} to: bool BibleEncrypt(std::vector<unsigned char> vchPlaintext, std::vector<unsigned char> &vchCiphertext)
{
if (!fKeySetBiblePay) LoadBibleKey("biblepay","eb5a781ea9da2ef36");
int nLen = vchPlaintext.size();
int nCLen = nLen + AES_BLOCK_SIZE, nFLen = 0;
vchCiphertext = std::vector<unsigned char> (nCLen);
// EVP_CIPHER_CTX ctx;
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
bool fOk = true;
EVP_CIPHER_CTX_init(ctx);
if (fOk) fOk = EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, chKeyBiblePay, chIVBiblePay);
if (fOk) fOk = EVP_EncryptUpdate(ctx, &vchCiphertext[0], &nCLen, &vchPlaintext[0], nLen);
if (fOk) fOk = EVP_EncryptFinal_ex(ctx, (&vchCiphertext[0])+nCLen, &nFLen);
EVP_CIPHER_CTX_cleanup(ctx);
if (!fOk) return false;
vchCiphertext.resize(nCLen + nFLen);
return true;
}
bool BibleDecrypt(const std::vector<unsigned char>& vchCiphertext,std::vector<unsigned char>& vchPlaintext)
{
LoadBibleKey("biblepay","eb5a781ea9da2ef36");
int nLen = vchCiphertext.size();
int nPLen = nLen, nFLen = 0;
//EVP_CIPHER_CTX ctx;
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
bool fOk = true;
EVP_CIPHER_CTX_init(ctx);
if (fOk) fOk = EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, chKeyBiblePay, chIVBiblePay);
if (fOk) fOk = EVP_DecryptUpdate(ctx, &vchPlaintext[0], &nPLen, &vchCiphertext[0], nLen);
if (fOk) fOk = EVP_DecryptFinal_ex(ctx, (&vchPlaintext[0])+nPLen, &nFLen);
EVP_CIPHER_CTX_cleanup(ctx);
if (!fOk) return false;
vchPlaintext.resize(nPLen + nFLen);
return true;
}
|
|
|
|
Rob, how about creating Subdomains on biblepay.org and you set it to ips of stable servers. This way, if a server goes away, you only need to change the dns, but not the client.
Like:
node.biblepay.org
node2.biblepay.org
node3.biblepay.org
node4.biblepay.org
node5.biblepay.org
...
Nice idea, but still points to centralization. If the biblepay.org domain gets hijacked everyone is stuck. The probability of that may be low, but better safe than sorry. |
|
|
|
I see all of our old addnodes hardcoded in the wallet are dead, so that explains why new users couldnt get on while node.biblepay.org was down yesterday.
So I added these two so far:
WriteKey("addnode","node.biblepay.org");
WriteKey("addnode","node.biblepay-explorer.org");
Does anyone else have any that will be up 24-7 on a solid dns external address?
does it have to be a sanctuary or just a node that's online? I appreciate you looking into this, it will definitely help the issues we've been seeing the past few days |
|
|
|
Hi everybody, I added a new feature to the PoDC part of Biblepay-Central: https://www.biblepay-central.org/en/podc/user/1992969/There is now a Tab "Podc Updates", which calls "exec utxoreport" in the background and shows the last updates of for the CPID. It might make it easier to debug problems when users can access these data in a nice frontend. Nice feature. Could you also have it refresh the username from rosetta? mine had more detail then i wanted so I updated on rosetta a while ago but biblepay-central still shows it |
|
|
|
|
Show Posts
