"Regarding the dynamics of solving blocks on prior versions I will go into detail on that after church."
So although we required a mandatory upgrade between 1.0.7.7 and 1.0.7.8+, this was intended to upgrade instantsend, but not to kick the miners off the current block algorithm. So the enforcement in this case was set for a protocol upgrade (for sanctuaries) and a soft-hangup on old versions. This means that blocks solved on prior versions are not discarded unless mined on a fork. So when we get to the point of a 50% upgrade level, those old versions are going to be wasting hashpower. I see we have 63% right now on 1.0.7.1 that has not upgraded. So this effect will come into play when the 63% solo level drops to 49%. That hash power is going to go to waste and provide more coins for the early birds who did upgrade. Now here is a Very interesting effect that is happening right now and might answer some of our network questions. I flipped the switch on the pool requiring 1.0.7.9+ to hash against the pool. There are 63% now that are either solo mining or have a private pool, as they are still solving blocks at the 63% level on the network currently right this second (and cant be in the pool as the pool refuses the connection). That explains where 63% out of our 75% is, but we still do not know if its a solo group, a botnet or a private pool. Sorry for my ignorance, but I still don't get it what is happening now after the "mandatory" upgrade to 1079. From MY understanding a "mandatory" upgrade results in a fork (at a certain block). Apparantely this is NOT what this is, since you write that all blocks solved on older versions are still valid ("unless mined on a fork"  ). Then you write "when we get to the point of a 50% upgrade level, those old versions are going to be wasting hashpower". How so? On the other mandatories you were afraid that at the key block not enough would have upgraded and therefore the blockchain would fork with the majority on the "wrong end". Isn't this exactly what this is right now? The botnet (and judging by the non-existent pool solutions about 90% of the overall hashpower....) are on a major fork and the pool (so "we all") are the minor "wrong" fork? Please explain what has happened the last 2 days and how you ever expect the botnet and all the solo miners to update, considering that the current state works just marvellous for them... Let me talk a little about the magical missing pieces. I try to be fair for everyone. Since this mandatory involved the IS vulnerability only and was not a mining algo change, I feel its a little unfair for me to hard fork the miners, so I incremented the protocol version required for sancs (since they provide the instant send service), and required a mandatory for the regular network with the punishment being that we hang up on older nodes. I did not create a fork however. So basically, if you are one of those botnet users, you cant instant send funds. Our sancs had to upgrade, since they would stop getting paid (so they all did already, I can see that). Anyone who upgraded can now send IS again. So our only problem is 1000 or so PCs on 1.0.7.1 wont upgrade and they are 60% of our network hash power. The reason they still exist, is someone is acting as a bridge between the old version and the new version. I could potentially kick them off... but should we? BTW, to answer your question, our version 1080 will hang up on those nodes and not service them. You are correct, since we are newer, they will not hang up on us. Someone out there is acting as a bridge, and forwarding their blocks to our chain, could be a fraudulent client with a fake protocol version compiled in. Should we kick them off? |
|
|
|
Hey Rob, SEO_Account was attempting to create a Proposal on the Pool website but he noticed this message:
"** Note: Each new Proposal costs 2500 BBP. Please do not Save the proposal unless you agree to pay 2500 BBP **"
Does the proposal fee come out of the pool account? How does this work?
(If it does come out of the pool account, is there a way to send funds to ones pool account?)
If BBP price is about $0.01 per BBP, thats about ~$25?
My understanding is that proposal fee is to help reduce spamming of proposals?
Thanks!, Togo
Yeah, someone tried to create a proposal pointed to a web site that had a virus on the page. I think theyve tried pretty much everything now. (That almost beats the one where they uploaded a virus into an orphans letter). So I had to raise the bar a little bit to enter proposals. You know, in Dash, its 5 dash to create a proposal, and since that is like $5000, over there the proposer usually asks for reimbursement inside the proposal. So I recommend doing the same thing here, pad the 2500 bbp on top of your proposal amount. The amount is deducted from the users pool balance. Its also there to help reduce proposals down to serious proposals only, the least I would expect is someone to spend $25 up front to ask us to evaluate the proposal (as it takes all of our time to vote on it and read it and discuss it) etc. I could deposit BBP into ones pool account if a person sends me BBP, Ill credit the pool account if need be. |
|
|
|
Hi,
Regarding minning on the pool it looks like many users went solo, so the pool does not have powerful machines any more and it is missing most of the blocks. If this goes on for a while, some others might leave too.
What should we do? I am giving it all in a pool, but it looks pointless for now - yes I know, if we all think like that, than we can leave and pool can close till block difficulty it too high to solve in a reasonable time and most come back to pool.
Any thoughts?
Best regards,
Simon
The thing is, the pool solves enough blocks per day to make it a pool, IE more than One, so in my eyes we dont have an issue. You get compensated in the pool based on how much HPS you bring to the table. Once this botnet gets hit below 50%, things are going to get interesting for them. How sure are you it is botnet? When is expected to be network upgraded from more then 51%? Im not sure of anything. I make the assumption that for the last 3 mandatory upgrades, I saw 30, 40, now 60% of our nodes on a version that is 10 versions back. Leading me to believe that someone somewhere sets up 750 computers in a botnet (not calling it a malicious botnet, calling it a botnet of PCs), that they have trouble upgrading. The reason I think they have trouble, is because they are always 10 version back and all of a sudden they all upgrade at once, every time. The reason I "think" they might be in China is because the last time they upgraded, I got 5 or so mad emails in Chinese, something about why you make me upgrade so fast, and when I replied, they were blocked by the Chinese government. |
|
|
|
Hi,
Regarding minning on the pool it looks like many users went solo, so the pool does not have powerful machines any more and it is missing most of the blocks. If this goes on for a while, some others might leave too.
What should we do? I am giving it all in a pool, but it looks pointless for now - yes I know, if we all think like that, than we can leave and pool can close till block difficulty it too high to solve in a reasonable time and most come back to pool.
Any thoughts?
Best regards,
Simon
The thing is, the pool solves enough blocks per day to make it a pool, IE more than One, so in my eyes we dont have an issue. You get compensated in the pool based on how much HPS you bring to the table. Once this botnet gets hit below 50%, things are going to get interesting for them. |
|
|
|
I was just listening to Joel Richardson, The Messiah is about to appear, https://www.youtube.com/watch?v=cTPEeptb3jY , and he makes a very interesting point about what the mark of the beast is: He says that the mark of the beast is the opposite of the mark of God. The mark of God is what happens when you accept Jesus as your savior, you are written in the Lambs book of Life, and you are virtually marked- maybe in the spirit realm as if a mark was written on your forehead - you are Gods. In the spirit realm Ive heard that beings just simply "know" things about each other anyway. Moving on, the mark of the beast would be the act of renouncing your allegiance to God, and saying some sort of prayer that you hand over your loyalty to Satan. So it could be a situation you are put in where you are asked to renounce Jesus, and promise allegiance to the beast. At that point you are marked as the "beasts". It is interesting if the mark is never anything with source code in it, but since the bible says : He causeth both small & great, rich & poor to receive a mark on the right hand or forehead... meaning that this particular physical mark is *after* you renounce your religion, another words the device may be used for buying/selling but in itself it would have nothing to do with your soul, its simply a way to interact with society once you renounce your religion. |
|
|
|
Well, I'm not sure how it happened, but it appears due to the update, my weakest PC just mined more coins over the weekend than I have mined total over 3 - 4 months.
The wallet has a bird next to the transaction and the the "type" of transaction is "mined." Does this mean it somehow solo mined?
Sounds like you veered off onto your own fork. Be careful moving your coins until you figure it out. I have no idea. I just tried sending 100 BBP to another wallet, and it is at 3/6 confirmations at the moment so I think I might have just gotten lucky. Please keep in mind I am not talking about a huge amount of coins by any means. Yeah, the client reverts to solo mining when it cant get new work from the pool. The older version blocks are compatible right now with the newest version, so you probably solo mined one. The pool is requiring 1079+ right now to hash, but only 17% of the network has upgraded. |
|
|
|
Biblepay - Mandatory Upgrade
1.0.8.0b
- Final fix for instantsend security vulnerability
- Fix crash we introduced today
** This version does fix the crash issue, and I confirm I can finally send instantsends successfully. All credit to God. **
(I mentioned earlier that you can continue on 1.0.7.9 for a while if need be, but Sanctuaries should upgrade asap.
Please upgrade if possible).
I just ran the usual Linux upgrade process with git pull origin master && sudo make ... getinfo shows " "wallet_fullversion": "1.0.8.0"," ... I thought it was supposed to be upgrading to 1.0.8.0 b. The 'b' is just for github, client full version only supports 4 numbers. |
|
|
|
|
So I wanted to put this on record as one of our future missions.
I was in slack discussing third world bitcoin usage with Alex and we stumbled on the subject of the unbanked: the third world poor who have no bank accounts and who deal with inflation. Alex was talking from the perspective of being able to receive biblepay in a mobile wallet. I was thinking of being the person with no bank account in Venezuela and not being able to buy a loaf of bread with the high inflation rate.
This really struck a nerve for me as I was thinking, this is so very aligned with our mission, this should honestly be one of our highest priorities, finding a way to bridge the unbanked poor with mobile liquid deflationary spending on real world groceries/goods.
The problem is of course extremely complicated, and can be broken down into things such as: mobile access to currency (IE BBP + Electrum wallet), high inflation - living paycheck to paycheck (storing the native currency temporarily in a deflationary asset like BBP), unbanked - no checking account (storing the value in BBPs mobile wallet), Native currency deposits (ability to trade fiat for BBP), Native currency withdrawals (trade BBP or BTC for fiat), spending from a debit card (Visa/Mastercard/Amex relationship with local vendors PLUS reloadable debit card from BBP), regional issues (vendor acceptance of visa/mc/amex), government currency pegging (IE in Venezuela the currency exchange rate is 900% higher on the official exchange, 900% less on the black market), banking regulations (IE illegal to buy or sell fiat for BTC from a centralized web site etc), Due diligence (creating records of the environment and the roadblocks per region) etc.
As you can see, this is a huge undertaking, but even one partnership in one area could make the entire process worthwhile, and this would give BBP a very strong and worthwhile reason for long-term success.
I personally think the shortest route to get started in parallel is first be listed on a major exchange, then make a partnership with a debit provider such as uquid.com who offers virtual or physical debit cards:
-https://uquid.com/fees
However in the mean time, we should start entertaining this problem and thinking of how we can help the unbanked with biblepay.
One thing we can do is have a volunteer do the due diligence for the top 10 poorest areas of the world, create a spreadsheet and save the key problems, by going through the simulated process of purchasing things, see if visa/mc/amex are accepted, exchange rates, blackmarket, etc.
|
|
|
|
Anyone who has trouble logging in to the pool with chrome or received an HTTP 500 Error: https://pool.biblepay.orgPlease press:
CTRL-F5
from the login page - then Log In. for the faucet it says verify your mail adress. after verification it says again verify your mail  Oh wow, your right.... Fixed, please try now. |
|
|
|
I'm on board two days from now, but last few hours (may be 3 or 4).. blocks are passing, i am hashing... with "0" in "Coins mined in last hour" and no move in Total Balance.
Check out reports | block history, we havent solved a block since 1:59 pm (4:30H ago). The second problem : it appears aldis is not in the leaderboard, please ensure you are running 1080, and your miner is not listed in Home | Missing Miners.... |
|
|
|
Anyone who has trouble logging in to the pool with chrome or received an HTTP 500 Error: https://pool.biblepay.orgPlease press:
CTRL-F5
from the login page - then Log In. |
|
|
|
I'm running 1.0.8.0b. Everything is looking "fine". I can see my hash rate in pool, my shares are moving, but... not a single coin was mined. At least....not for me. 02:09:16  getmininginfo 02:09:16  { "blocks": 25743, "currentblocksize": 6005, "currentblocktx": 22, "difficulty": 621.3203482366829, "errors": "", "genproclimit": 3, "networkhashps": 90407777371.21313, "hashps": 2267.96281673131, "minerstarttime": "01-14-2018 23:40:34", "hashcounter": 3906067, "competetive_mining": true, "competetivemining_hash_counter": 3758955, "global_competetive_mining_tithe": 80, "competetive_mining_ratio": 0, "pooledtx": 22, "testnet": false, "chain": "main", "biblepay-generate": true, "poolinfo1": "BLpu2s9FFs1PPjfovGgtfTD2aB43Efybuf; BF72gCHawYN19uhNU6tCGmmZynVczKjtkt; BF72gCHawYN19uhNU6tCGmmZynVczKjtkt; ", "poolinfo2": "Submitting Solution 01-15-2018 00:08:45; Submitting Solution 01-15-2018 00:07:47; Submitting Solution 01-15-2018 00:07:59; ", "poolinfo3": "", "miningpulse": 674, "poolmining": true, "pool_url": " https://pool.biblepay.org", "poolmining_use_ssl": true } Total Balance is frozen. P.S. Please, excuse my bad English. Your mining_credit comes in a bigger batch once we solve a block with you on board , so you should be fine... |
|
|
|
I just found out that the monthly budget decreases every time by exactly 1.5%: getsuperblockbudget 24600
5789219.786313
getsuperblockbudget 30750
5702381.489514
getsuperblockbudget 36900
5616845.767143
getsuperblockbudget 43050
5532593.08065
... This is an excellent deflationary feature, I like it. @Rob: I noticed that on the Proposals list page there is a fixed amount from the previous budget, so I guess it should be a dynamic value. I was thinking: because we have 150 blocks/day, instead of 205, our monthly budget is actually every 41 days (6150 / 150) instead of every 30 days (6150 / 205) like it was meant to be. Since the block time issue seems to be non-trivial, maybe we could consider lowering the interval between superblocks from 6150 to 4500? (4500 / 150 = 30) On the positive side of things, in the current situation where both exchanges are down, it's good that we still have about 33 days left until the next superblock, because right now it's difficult to determine BBP price for making proposals. Great points you make about 41 physical days. My main point of consternation is being able to pay Compassion with a constrained and lagging budget. Let's see what kind of price we open at on c-cex, and we can try to formulate a game plan between now and March. I dont want to plan on any mandatories until the end of the 1st quarter, but if need be we can evaluate ideas that fix it around the end of March unless our price is so high that we don't need on-time budgets. |
|
|
|
"Regarding the dynamics of solving blocks on prior versions I will go into detail on that after church."
So although we required a mandatory upgrade between 1.0.7.7 and 1.0.7.8+, this was intended to upgrade instantsend, but not to kick the miners off the current block algorithm. So the enforcement in this case was set for a protocol upgrade (for sanctuaries) and a soft-hangup on old versions. This means that blocks solved on prior versions are not discarded unless mined on a fork. So when we get to the point of a 50% upgrade level, those old versions are going to be wasting hashpower. I see we have 63% right now on 1.0.7.1 that has not upgraded. So this effect will come into play when the 63% solo level drops to 49%. That hash power is going to go to waste and provide more coins for the early birds who did upgrade. Now here is a Very interesting effect that is happening right now and might answer some of our network questions. I flipped the switch on the pool requiring 1.0.7.9+ to hash against the pool. There are 63% now that are either solo mining or have a private pool, as they are still solving blocks at the 63% level on the network currently right this second (and cant be in the pool as the pool refuses the connection). That explains where 63% out of our 75% is, but we still do not know if its a solo group, a botnet or a private pool. So, you think, that those last 25 block without pool hit, is because the pool has "small" hashpower? Well the pool dropped from 4000 miners to 1900 miners, and the 24hr percent solved dropped from 25% to 19%. But part of what I believe is right now those 63% that are mining outside of the main pool are still solving those other blocks... But once 1.0.8.0b becomes exactly 50% of the network, we will have two live chains and only one is going to win (the official one). exec versionreport |
|
|
|
Hi again everybody.
I hate to sound like a bother, but could anybody explain if the pool is down or if I just cannot get into the pool at this point to mine?
I hope everyone's having a fine Sunday.
Jazz
I can't log on to the pool via Google Chrome. Works for me with Firefox though Same here, I usually use Vivaldi (chromium based) but cannot click on any button on the login page. FF works well. Btw: My Pi is running 1.0.8.0 (without b) now, no problems so far (except that it took quite a long time to sync...); HPS2 almost 25k (but right now with fewer miners every worker has higher HPS2 obviously).  Oh wait, I just realized at noon the pool needed a new .js file... For the pool in chrome, please go to the home page, click ctrl-f5 for a complete refresh, then login and you should be good. |
|
|
|
"Regarding the dynamics of solving blocks on prior versions I will go into detail on that after church."
So although we required a mandatory upgrade between 1.0.7.7 and 1.0.7.8+, this was intended to upgrade instantsend, but not to kick the miners off the current block algorithm. So the enforcement in this case was set for a protocol upgrade (for sanctuaries) and a soft-hangup on old versions. This means that blocks solved on prior versions are not discarded unless mined on a fork. So when we get to the point of a 50% upgrade level, those old versions are going to be wasting hashpower. I see we have 63% right now on 1.0.7.1 that has not upgraded. So this effect will come into play when the 63% solo level drops to 49%. That hash power is going to go to waste and provide more coins for the early birds who did upgrade. Now here is a Very interesting effect that is happening right now and might answer some of our network questions. I flipped the switch on the pool requiring 1.0.7.9+ to hash against the pool. There are 63% now that are either solo mining or have a private pool, as they are still solving blocks at the 63% level on the network currently right this second (and cant be in the pool as the pool refuses the connection). That explains where 63% out of our 75% is, but we still do not know if its a solo group, a botnet or a private pool. |
|
|
|
Hi again everybody.
I hate to sound like a bother, but could anybody explain if the pool is down or if I just cannot get into the pool at this point to mine?
I hope everyone's having a fine Sunday.
Jazz
I can't log on to the pool via Google Chrome. Works for me with Firefox though Alright Ill check into it now. I have a backlog of pool issues to look at next. Thanks... |
|
|
|
|
Biblepay - Mandatory Upgrade
1.0.8.0b
- Final fix for instantsend security vulnerability
- Fix crash we introduced today
** This version does fix the crash issue, and I confirm I can finally send instantsends successfully. All credit to God. **
(I mentioned earlier that you can continue on 1.0.7.9 for a while if need be, but Sanctuaries should upgrade asap.
Please upgrade if possible).
|
|
|
|
I rolled back to 1.0.7.9 on the official web site. Please try now. As far as the bug, I found the issue- we will have this final release out in a few hours. Linux is ready now if anyone wants the unofficial version for testing (1.0.8.0b). |
|
|
|
|
Show Posts
