am i mining now?  [2019-10-16 08:05:21] thread 11: 861255 hashes, 14.35 khash/s [2019-10-16 08:05:21] thread 0: 811334 hashes, 13.72 khash/s [2019-10-16 08:05:21] thread 26: 846296 hashes, 14.11 khash/s [2019-10-16 08:05:21] thread 22: 840738 hashes, 14.05 khash/s [2019-10-16 08:05:21] thread 27: 14089 hashes, 14.09 khash/s [2019-10-16 08:05:21] thread 14: 864796 hashes, 14.41 khash/s [2019-10-16 08:05:21] thread 34: 864798 hashes, 14.41 khash/s [2019-10-16 08:05:21] thread 35: 864685 hashes, 14.41 khash/s [2019-10-16 08:05:21] thread 9: 847776 hashes, 14.13 khash/s [2019-10-16 08:05:21] thread 15: 864694 hashes, 14.41 khash/s [2019-10-16 08:05:21] thread 39: 864101 hashes, 14.40 khash/s [2019-10-16 08:05:21] thread 19: 864101 hashes, 14.40 khash/s [2019-10-16 08:05:21] thread 6: 14097 hashes, 14.10 khash/s [2019-10-16 08:05:21] thread 12: 863514 hashes, 14.39 khash/s [2019-10-16 08:05:21] thread 32: 863383 hashes, 14.39 khash/s [2019-10-16 08:05:21] thread 29: 847857 hashes, 14.05 khash/s [2019-10-16 08:05:21] thread 3: 842599 hashes, 14.00 khash/s [2019-10-16 08:05:21] thread 7: 14059 hashes, 14.09 khash/s [2019-10-16 08:05:21] thread 1: 14068 hashes, 14.08 khash/s [2019-10-16 08:05:21] thread 2: 14098 hashes, 14.10 khash/s [2019-10-16 08:05:22] thread 20: 840877 hashes, 13.95 khash/s [2019-10-16 08:05:22] thread 4: 847901 hashes, 14.01 khash/s why some miners have only ~ 14000 hashes? and other 860000? Yes, good job. It evens out over time - when it first starts it takes more time to get JSON replies but after a while all the threads get pretty equal. You are probably mining on 40 threads @ 14.4 KHS each. |
|
|
|
Glad to hear p2pool splits payment that way. It does provide a nice decentralized feel to it and makes truly p2p. Well, from what Ive learned from the history of the minerd code, it fully supports multiple types of mining : solo, getblock, and stratum/pool. The usage is still up to the user. Bitcoin/Dash removed getblock a while back in favor of 'getblocktemplate', allowing the core wallet to work with stratum/long polling.
Yes, solo, getblock, getblocktemplate, and stratum+tcp are all supported by minerd. I just meant that for workerid, I usually see implemented via user and/or password. I don't think I've ever seen workerid included for coinbase-addr. I suppose it is possible but you would need to custom code that in. Seems counterproductive though if pool miners understand your put workerid inside user or password though. You're doing an awesome job -- thanks for all your efforts! Yeah, I don't plan on doing anything unconventional for p2pool (other than our abn reqs); I meant I would fix coinbase-addr for the sake of solo mining - and for the sake of passing it into stratum for the payout address. We can still leave it work the same way with the pool user and password as it does for dash. The only difference in biblepay, will be the code we need to add to handle funded vs non funded abns. I have to investigate that further - as Id like to simplify it - to not require the user to do so much and if they make a mistake it should still work etc. |
|
|
|
also remember to comment out the setting in biblepay.conf that refer to the pool if you want to run the external miner.
Another thing: I mined a block with the external in Production but the .biblepayevolution/debug.log and the output of bbpminer -D never acknowledged that it found a block or that the wallet being used to mine with was the recipient of the mined block.
We could use a message saying: "You found block block_number"
Stratum pools often use the miner identifier on the end of the payout address as an argument for --coinbase-addr= and that could be useful for us too.
payout_address/minerid
This would be helpful to see which miner got it and how you are doing.
So far only my non-mining Windows 10 wallet acknowledged the mined block (871.x bbp) but non of the linux miners did.
However, the linux wallet did immediately dock me the abnweight as normal.
minerid is usually for pool and it is not supported for solo mining since your pay to address is not valid. coinbase sig could used in place if it was supported. I think you set custom receive to address and that'll be how you measure which miner won the block. Rob said coinbase addr may be supported in a future version. I've also seen a few pools split the mined block transaction immediately based on the split algorithm and pay out in the same block that it was mined at. This way, the pool never keeps a positive balance. Well, from what Ive learned from the history of the minerd code, it fully supports multiple types of mining : solo, getblock, and stratum/pool. The usage is still up to the user. Bitcoin/Dash removed getblock a while back in favor of 'getblocktemplate', allowing the core wallet to work with stratum/long polling. We have solo mining now, but the only slight issue we have is we read the coinbase address from biblepay cores new block that is created (and ignore the --coinbase-addr) switch - but I plan on fixing that for both solo/pool mining while looking at the pool. The p2pool does always split the entire block reward among the participants in the sharechain for every block (it never stores a balance). I believe I will be working on p2pool first, just to be mostly dash compatible for the future. Then I will attempt to store some p2pool metrics on the server and report on them in pool.biblepay.org as long as its up for orphan letter writing. |
|
|
|
I know the botnet is not back, because we have a 125K abn requirement.
One other nice hack the external miner relieves us of is the issue where we copy the wallet.dat out to many machines - with one bbp running node you can mine on multiple miners without copying wallet.dat.
Do you think a higher difficulty warrants high ABN? It sounded like you want to reduce ABN so the mining would not need much BBP to stake. Can you explain a little more about not needing to copy the wallet.dat ? We still need to run a node (biblepay-qt or biblepayd) but a blank wallet.dat is okay as long as one BiblePay wallet is running with the required ABN stake? That is news to me and sounds like a more secure way to mine. If mining is easier, I'm thinking it'll be easier for botnets to be set up too... if you set ABN to 5k, it wouldn't take much to mine continuously. Is there some way to keep botnets away without needing to stake BBP for ABN? 1) On the one biblepay node, multiple miners, like Nipar explained you can do that - the key is in the biblepay.conf on the single running node to do the :rpcallowip=ipv4 - one entry row per mining machine. On the ABN question, yes that single node would need to have a high enough balance to cover all the ABN activity (IE 10 mining machines might need 1.25MM etc). That particular wallet still needs unlocked, so that it can generate ABN's for the miners. Its the same as required now, except concentrated against one node. The nice thing about it though is we dont tell people to copy wallet.dat out to mining machines, and, its a little more efficient as you dont run multiple biblepays just to mine (I suppose thats better for our governance data and bandwidth consumption also). 2) " Do you think a higher difficulty warrants high ABN? It sounded like you want to reduce ABN so the mining would not need much BBP to stake. " -> Well, this is a definite conundrum. On one hand, higher difficulty would dictate a higher ABN requirement if we go the "common sense route", but, the 'cryptocurrency economy model' is starting to explain to us that in order to attract many new users/miners, we have to lower the barrier. This means we have to choose between these dimensions: Less users/low diff/lower investor buying activity/more profit for a few - and risk of a collapse of the coin, or b: more users/higher diff/higher buying activity/less profit per mined block/a more stable community. So, I also realize, we are trying to protect our miners interests by blocking the botnet also - so it sounds as if a zero ABN is not good either. Maybe we keep thinking about it - and ideas where we block the botnet - but increase user count. All I have so far is the idea it might be good to lower the ABN req. to 10,000 or whatever, something that is a low barrier but would still afford some protection against a person who might install biblepay in a school system etc. |
|
|
|
also remember to comment out the setting in biblepay.conf that refer to the pool if you want to run the external miner.
Another thing: I mined a block with the external in Production but the .biblepayevolution/debug.log and the output of bbpminer -D never acknowledged that it found a block or that the wallet being used to mine with was the recipient of the mined block.
We could use a message saying: "You found block block_number"
Stratum pools often use the miner identifier on the end of the payout address as an argument for --coinbase-addr= and that could be useful for us too.
payout_address/minerid
This would be helpful to see which miner got it and how you are doing.
So far only my non-mining Windows 10 wallet acknowledged the mined block (871.x bbp) but non of the linux miners did.
However, the linux wallet did immediately dock me the abnweight as normal.
Ok, yes, I can make sure we have that in the biblepaycore wallet. I know the external miner prints a line (a Yay/Boo and a tally) when it finds a block - but - its lost after the page clears, but you can pipe the output of the miner to the debug log optionally; but yes, good idea, I will make sure we do this during the pool set up. |
|
|
|
also remember to comment out the setting in biblepay.conf that refer to the pool if you want to run the external miner.
Another thing: I mined a block with the external in Production but the .biblepayevolution/debug.log and the output of bbpminer -D never acknowledged that it found a block or that the wallet being used to mine with was the recipient of the mined block.
We could use a message saying: "You found block block_number"
Stratum pools often use the miner identifier on the end of the payout address as an argument for --coinbase-addr= and that could be useful for us too.
payout_address/minerid
This would be helpful to see which miner got it and how you are doing.
So far only my non-mining Windows 10 wallet acknowledged the mined block (871.x bbp) but non of the linux miners did.
However, the linux wallet did immediately dock me the abnweight as normal.
Interesting.. I am testing on Linux and wondered if anyone had found a block on linux at all.. Anyone?? I found a lot on linux against testnet, so I believe its working, but Ill let others comment for sure. |
|
|
|
diff was before between 2k-max 5k now?  Diff is also not linear. |
|
|
|
BOTNET is back guys!!!!
extern miner is a evil
diff was 90k
ROBERTKO stop talking about me and my mining, OK? stop to lie a daj si 50 zdravasov a 20 otcenasov pre Tvoj smrtelny hriech= ZAVIST!!!!!
a ked toto vymazes, postihne Ta ukrutna pomsta za vsetko co robis ludom na tomto webe,ze im mazes texty
I know the botnet is not back, because we have a 125K abn requirement. One other nice hack the external miner relieves us of is the issue where we copy the wallet.dat out to many machines - with one bbp running node you can mine on multiple miners without copying wallet.dat. |
|
|
|
|
I'm writing a program to model the cryptocurrency economy.
I can already see its going to be fascinating and worth the time - as just doing the mental gymnastics on this has already started to reveal some of the "secrets" of success in other cryptoprojects. This I think will be invaluable in helping us re-evaluate where we are and future decision making.
"Secrets being discovered" in the cryptoworld:
Imagine a double component in each emission type (whether spent on governance, charity, mining, electric) for propensity for liquidation.
- Miner emissions : A certain % of the electric paid by miners to mine a currency are paid for already - by the household. Imagine basement hackers who cant afford the electric bill running a miner in the basement. Let us assume 50% of the basement hackers running ASIC/GPU's - the parents are paying the electric bill.
- Locked coins in sanctuary investments: Those who hold sanctuaries are reluctant to cash out the investment, unless its already profitable (by a large %).
- Coins rewarded for governance projects or charity: These coins are immediately sold on the exchange, driving down the price. We must mark elements of the project causing downward pressure, and identify every place or decision that causes a faster deceleration. (IE maintain our original goal of 10% to orphan charity).
- Miners and relationship to electric cost. The mined coins will not be sold at a loss. The low barrier is the cost of mining the coin as related to electric costs - so it is to our benefit to make it as hard/expensive as possible to mine a coin, but as user friendly as possible.
- QT and its effect on user count. This project is revealing the true nature of QT. QT tightens our emissions, and therefore controls our expenses in the short term, but it also drives away miners. As seen in #1 and 4, driving away miners is not a good thing, if the miners are doing the PR, the investing, and the word of mouth. And in #4, it is starting to reveal that coins spent for mining are not a bad thing (because miners wont sell unless they can make a profit).
This is just the beginning, and the model isn't 15% complete yet, so don't take this post with any sort of value yet.
But what I believe this project is going to reveal is something like this:
- QT could be reduced or eliminated to drive more miners in
- ABN could be reduced to drive more miners in
- PODC-GSC could be added and re-enacted, to raise the cost of mining each BBP coin (and allow us to have cancer mining)
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
- Our orphan emissions should be completely decentralized by relying on sancs - make the sancs work for their pay
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
- We should be motivated to ensure the currency is still friendly for anonymous users - and anonymous sancs who have to pay charity bills (they can make biblepay branch office PO Box etc for their share of compassion). We should have a github page to allow anon users to complain of anything we did and honor their wishes also.
Now to finish writing the model and test these theories and rank them, and come up with more for the list.
|
|
|
|
|
This is just an idea, but in the vein of completely decentralizing biblepay, where we create a true DAC (decentralized autonomous orphan charity), (as we currently give 10% of our blockchain emissions to orphan charities who are > 75% efficient), it would be an interesting idea if we held each individual sanctuary to be responsible for liquidating their "share percentage" of our monthly emissions and maintaining a compassion account and paying their own share of the compassion bill.
For example, we could require a sanctuary to handle the receipt of 50,000 bbp each, so a person who owns 3 sancs would be responsible for receiving 150,000 bbp per month in orphan emissions, liquidating these on SX, and paying for that number of orphans. Since the sanctuary is technically Biblepay property (in some respects) we could require the ability to audit the account and require the sanc to upload the PDF each month (of the payment to compassion) along with the orphan IDs.
A sanctuary who does not comply gets POSE banned.
Just wondering if this idea would help decentralize biblepay to the point where our operations would be fully decentralized.
EDIT: For sanctuaries who live in countries where they cant pay the compassion bill in USD, they could sponsor the required number of orphans through Cameroon-One and pay the monthly fee in BBP. We could be flexible in filling compassion, then cameroon, and Kairos with Sancs who would rather deal with BBP. Kairos also accepts BBP as a form of payment. We may even be able to use the sanctuary keypair to allow access to store the DSQL record (signed by the sanc) - that would give a really nice touch to the authenticity of the expense per month in DSQL.
(It would also allow us to control the permissions to upload the record).
EDIT2: Thinking about theft of the BBP by the sanctuary (say they set up a sanc just to steal the orphan funds), I think we can control that by establishing a sanctuary start date, and requiring the 'number of sancs owned' by CPK - IE the monthly commitment controlled by that party - to first establish the orphans and upload the *first* PDF of the payment before starting to pay the sanc rewards. IE, we would modify the core wallet to know if a sanc is "in good standing" or not by linking the sanc to its DSQL payment screen. Sancs in good standing start receiving rewards and they continue as long as the orphan expenses are in good standing. If this ceases to be - the sanc stops being paid - and we are always remunerating the sancs monthly orphan expenses in arrears (another words, they cant steal that months budget because they paid that months orphans commitments first - perpetually) til the last month. When the sanc terminates, we allow the last payment to be paid from governance to the terminated sanc.
|
|
|
|
Wow what a project this looks so fascinating. I think people have forgotten religion because of money and cryptocurrencies but I think this project will definitely increase the contributions done by people in Charity and religious programs. I am surely going to invest in this project can someone help me with the procedure?
We have a lot of coins for sale on: https://www.southxchange.com/Market/Book/BBP/BTCSome liquidity algo over there has really built up a lot to sell (by being our biggest buyer and taking advantage of the monthly orphan liquidation). Hopefully they will cease to do this eventually, or may God strengthen this project to overcome the bot. Anyway, "theoretically" in the long run, as long as we increase our user base, with our deflation we will overcome our low price and rise. We have a 19.5% annual deflation rate. =-=-=-=-=-=-=-= On a side note all, now that our POBH external miner appears to be working (I ran all night, yay), I'm going to start making a model of a cryptocurrency economy, where we can plug in different values for theoretical effects, and try to reverse engineer Dash's success in the model. Then we can see the pros and cons of our decisions (theoretically). And this might lead us to tweak/adjust something we did to grow Biblepay. |
|
|
|
diff is pretty high last days, what happens? new miners? I think maybe Slovakia has plugged the rack back in... |
|
|
|
BBPMiner
1.0.0.4-Leisure Upgrade
- Added -x to display current version (added version at start also) - Handle JSON nowork condition - Expand buffer size of Work to attempt to prevent crash - Remove --coinbase-sig (incompatible option with Evo) - Remove dead variables - Ensure nonces are separated ** I'm still not 100% sure if we got it, but we got the bug Orbis reported (invalid json), and we handled the new stack trace, please re-test ** Binaries: https://github.com/biblepay/cpuminer/tree/master/binariesEDIT: We will get the coinbase address working when we start working on the pool side. First lets address the crash.
|
|
|
|
|
** POOM UPDATE **
Todd from Cameroon did more exhaustive checking on both Chinese and Israeli children (and lost tribes of Israel), and primarily due to incompatibilities with governments (and the cost of living in Israel), both are currently not available for POOM.
I thanked him for the research.
|
|
|
|
120€/monthly is price for bilboard in our county city
Still better off dressing in a giant rabbit suit and walking down the highway with a BBP sign... |
|
|
|
Bitcointalk Thread for CPUMiner https://bitcointalk.org/index.php?topic=55038.0"cpuminer help – Usage, Flags and Command Examples" https://rehmann.co/blog/cpuminer-help/=== I havent been able to help test the miner, b/c my ubuntu machine freezes when it goes over 40-50% CPU, Its issue Ive been having for many months, too lazy to fix it hahaha, ughh, LOL I just found this --threads=N flag for cpuminer, so I can try testing again I have debug=1 in config === Should I setup valgrind? Old notes I found: "please compile the source code version of biblepay, and run biblepay in valgrind like this: sudo apt get install valgrind
cd ~/biblepay-evolution/src/qt
valgrind ./biblepay-qt If you just leave it run til it crashes again, you can then give us the line # and module filename. Btw, you can't run valgrind on a binary (you can but it is useless to us). It must be run on a compiled source." Reference: https://github.com/biblepay/biblepay/issues/76=== QUESTION: Should we run valgrind on the miner and the wallet?=== Valgrind https://wiki.ubuntu.com/Valgrindhttp://valgrind.org/http://valgrind.org/docs/manual/quick-start.html=== Build BBP Miner from Source: https://github.com/biblepay/cpuminer/blob/master/BuildingBBPMiner.txtThanks for starting to debug; well, valgrind is very useful (for some of the cases), for example, cases where we can reproduce a crash within 30 minutes or so. But in this case valgrind is not going to help us because one hour of mining in valgrind takes approximately 30 days (due to the overhead). So it looks like we will need to finish debugging it in GDB (or xcode etc). So dont worry about valgrind for now as it will just waste your time . I do have some more traces now (I had them running all night). Im reacting to these next and then Ill make a new release. One case addresses Orbis' JSON issue (I have that one), and another case addresses the mining crash (I believe). Orbis as far as rebooting the wallet after a crash, no that should not be necessary. It could be that you found a block and your ABN was out for a while, but I confirm biblepay continues to run properly at that point. |
|
|
|
It seems I am stucked mining since 8 of October, as no new transactions arise. However, CPUs are working. I was on 1.4.9 version since it was delivered, and I have updated this morning to 1.5.0, but I am still in the same situation. Getinfo and getmininginfo show correct data. What could be happening?
PS. Traditional wallet/miner, I am not talking about the new miner.
Most likely governance data is corrupt, and the wallet then decides to go on the wrong chain; please restart with: ./biblepay-qt -erasechain=1 Let it resync and then see if you are at the same hash/block as one of the block explorers - explorer.biblepay.org or chainz ? Thanks. EDIT: Btw, we do have the 'exec reassesschains' option for people with low bandwidth who want to try it first. But erasechain is better if you can walk away from it for a while. |
|
|
|
Ok 1.0.0.3 didnt last much longer, but now Im running one in debug mode in gdb and another one in valgrind.
Ill keep debugging until we find the cause of the crash.
One Windows 10 computer I didn't do all the security updates (it has been off for several months) mined for 12+ hours (on 1.0.0.1 bbpminer version) with no issue. I want to speculate that crashes seem to occur when a GSC using up all the coinage inputs (ABN starved) or when the contents fo the UTXOs change, the miner gets confused? If ABN is off on testnet, this would be an easy thing to test in TestNet for me. Ill try that idea of starving the miner, that might be the problem. I wont have time to release the testnet version til tomorrow but we will release it asap. That might explain why I never crashed during development - I ran it against testnet with no abn. |
|
|
|
I just checked in 1.0.0.3, lets run it with the "-D" switch at the end of the command line, and see if it reveals the problem.
(Or if its fixed now).
Nothing change after upgrade 1.0.0.3 and command line with "-D" still crashing after a few moment. When the bbpminer crashed(IE: Abort , Bus error , core dumped etc), I found that this also caused some system structure problems(UBUNTU 16), need to shut down and then restart to access via ssh. Otherwise, you can not enter the system via ssh before shutting down. Shouldnt be possible in linux - miner cant take down the server. Please try again. |
|
|
|
|
Show Posts
