On the BiblePay SSL project: We now support both SSL on https://pool.biblepay.org and https://pool2.biblepay.org. SSL is up: https://pool2.biblepay.orgWe will start requiring SSL in two days to make our site more secure. The core client will support mining over SSL in two days. If you would like to beta-test mining over SSL, download the linux version, and change the pool=http:// to pool=https:// in the config file, and remove the port=80 setting. |
|
|
|
one of the larger priorities now should be finding at least 2 or 3 better and bigger exchanges.. You want to succeed in having more for donations then you need people who are able to trade and to bring in new people in BBP, with the two lousy exchanges it is on now it will never find any growth.. Its unhealthy and nobody benefits from it and certainly not the project.. So I think you should set your prio's on some contact with exchanges and get that going... Way better for the project and to bring in new and enthousiast members!
Weve been working on this for 60 days, very hard, don't know why you have the idea otherwise. |
|
|
|
will there be some 'miner down notification' feature?
Could you please elaborate how you would like it to work? Maybe an e-mail when your regular miner goes down? Or... a notification on the home screen? |
|
|
|
Yeah, the last budget is now invalid and we have a new gobject id (thats very similar to a guid). So now we need to vote on the new budget, quickly, within 2 days, so that the system ingests the budget as a superblock.
Btw, all of the rows in the "Budget" section contain the same budget ID (budget=one to many->proposals). So right click on one of the budget rows, then vote for or against the budget.
You have to manually look at the stats in the wallet for budgets currently (UI doesnt work yet for that), type 'gobject list all triggers' and one will show up with a certain amount of votes.
Is the budget vote just one big yes/no? or is there a budget object for each proposal object? Its One big Yes No- this one is the same for every row in the budget list: gobject vote-many 4a1f347cd49a97d36f105b1908d33a3ed3cfb5d11485000d2908313f4c2d9490 funding yes You can see someone voted no for it, but only if you do the :gobject list all triggers Then you can see the no. |
|
|
|
bible_pay this First Prod Proposal? where i can to find current budget for voting? on pool governance -- proposal list i cant see CURRENT BUDGET
There are two ways: The hard way: gobject list all triggers Find the gobject id- copy to clipboard. Also you can see the votes on the screen from that command. The easy way: From the pool, go to Governance | Proposal List, and everything in the Budget List is in the budget.. |
|
|
|
This can be found when you right-click on any proposal and Copy Budget ID. It's kinda hard to find, so @Rob, if you don't mind the suggestion, the budget ID could be simply displayed prominently somewhere on the top, especially because it concerns all proposals, so maybe people will not search it in an individual proposal right-click. But I think it will all be good when Alex finishes BiblePay Central.  I like it the way it is - its more consistent this way with our other features. We need to do things one way, and everyone who uses the system regularly knows that we need to right click to vote on things. Ill be adding the budget voting statistics (info) to the budget rows however. |
|
|
|
So far, from what I can see the Watchman is now skipping over the deleted object and we should not be receiving errors any longer. Mouse, do you want to verify that with one of your non-patched nodes?
I didn't do anything and my sanctuary says 'ENABLED' again. Do I still have to restart my sanctuary? Whats your IP, let me see from my perspective for kicks? All credit to Jesus for our work. I think it's 208.115.99.108 Yeah, you are enabled in my list. It looks like you missed the earthquake, I just thank God we have the resources here to fix the problem, and for him giving us wisdom to fix it and helping us fix it today. So for anyone else who is not "ENABLED", just restart the sanctuary now. It looks like about half have already transitioned. Yeah, I didn't do anything, and all seems fine now Let's hope that everything goes smoothly with the first superblock. What do you mean exactly by 'voting on the new budget'? Do I have to re-vote on everything now? So instead of 'voting for proposal' we are 'voting for budget' right? Yeah, the last budget is now invalid and we have a new gobject id (thats very similar to a guid). So now we need to vote on the new budget, quickly, within 2 days, so that the system ingests the budget as a superblock. Btw, all of the rows in the "Budget" section contain the same budget ID (budget=one to many->proposals). So right click on one of the budget rows, then vote for or against the budget. You have to manually look at the stats in the wallet for budgets currently (UI doesnt work yet for that), type 'gobject list all triggers' and one will show up with a certain amount of votes. |
|
|
|
|
OK All, the devil tried to attack us today, but we prevailed yet again against the wiles of the devil.
The pool has been upgraded to use the new code.
Now the budget has been invalidated and re-instantiated.
Please, if you are Sanctuary, see the new budget and please cast your vote for the new budget.
|
|
|
|
still dont understand why any MN is still alive and receving rewards and the majority of others is dead = this doesnt look fair
Its fair, I appreciate that. Alex has tested this, please take with him. im wrote about bug in watchman again= few MN wasnt affect .. why? .. received all rewards Alex can explain in more detail, but it takes a failure of 30 hours before your masternode is revoked from the payment queue. We tested that, and it works. So for anyone trying to run a masternode from a home IP, its not going to very easy over the long term. im received 22:15 reward,and 00:30 crashed it ... for last 30hours i have only 1 reward, so where is problem ... and why talking about home IP: im using private DC The system is well tested since Sept of 2015, so what I recommend is volunteering to create a spreadsheet for us, write a program that logs all sanctuary payments, and verify the percentage of coverage. You are just a small fish in a very big pond, so please, help us move forward together. |
|
|
|
So far, from what I can see the Watchman is now skipping over the deleted object and we should not be receiving errors any longer. Mouse, do you want to verify that with one of your non-patched nodes?
I didn't do anything and my sanctuary says 'ENABLED' again. Do I still have to restart my sanctuary? Whats your IP, let me see from my perspective for kicks? All credit to Jesus for our work. I think it's 208.115.99.108 Yeah, you are enabled in my list. It looks like you missed the earthquake, I just thank God we have the resources here to fix the problem, and for him giving us wisdom to fix it and helping us fix it today. So for anyone else who is not "ENABLED", just restart the sanctuary now. It looks like about half have already transitioned. |
|
|
|
still dont understand why any MN is still alive and receving rewards and the majority of others is dead = this doesnt look fair
Its fair, I appreciate that. Alex has tested this, please take with him. im wrote about bug in watchman again= few MN wasnt affect .. why? .. received all rewards Alex can explain in more detail, but it takes a failure of 30 hours before your masternode is revoked from the payment queue. We tested that, and it works. So for anyone trying to run a masternode from a home IP, its not going to very easy over the long term. |
|
|
|
|
Pool fees lowered to 15%, hoping for the best.
|
|
|
|
Just as a very crude start, we need to make a wiki page for this soon, but for a reference as to exactly when our block numbers kick over for our next monthly deflation target:
Block AccumulatedDepreciationLevel Subsidy
06150 .0150 14775
12300 .0300 14550
18450 .0450 14325
24600 .0600 14100
30750 .0750 13875
So what this means is at block 24600, the same block as our superblock, our monthly deflation measure kicks in and lowers the subsidy from ~14325 to ~14100.
Didn't get any response on my question about info on setting up master node so I did read the readme in the latest download but the wiki link went to 404 error. When you update the wiki don't forget to update the link in the readme in the latest download. Way back I mined enough coins to masternode and have held them so I am looking forward to getting that done as soon as I can but I just can't find any info at the website or github thus far... Hopefully this link answers all your questions: http://wiki.biblepay.org/Create_Sanctuary |
|
|
|
|
Just as a very crude start, we need to make a wiki page for this soon, but for a reference as to exactly when our block numbers kick over for our next monthly deflation target:
Block AccumulatedDepreciationLevel Subsidy
06150 .0150 14775
12300 .0300 14550
18450 .0450 14325
24600 .0600 14100
30750 .0750 13875
So what this means is at block 24600, the same block as our superblock, our monthly deflation measure kicks in and lowers the subsidy from ~14325 to ~14100.
|
|
|
|
So far, from what I can see the Watchman is now skipping over the deleted object and we should not be receiving errors any longer. Mouse, do you want to verify that with one of your non-patched nodes?
I didn't do anything and my sanctuary says 'ENABLED' again. Do I still have to restart my sanctuary? Whats your IP, let me see from my perspective for kicks? All credit to Jesus for our work. |
|
|
|
|
So far, from what I can see the Watchman is now skipping over the deleted object and we should not be receiving errors any longer. Mouse, do you want to verify that with one of your non-patched nodes?
|
|
|
|
still dont understand why any MN is still alive and receving rewards and the majority of others is dead = this doesnt look fair
Its fair, I appreciate that. Alex has tested this, please take with him. |
|
|
|
is my MN alive when watchdog is expired? my voting failed   Yes, the watchdog only affects payments. Oh, it looks like we already have a supermajority and deleted the object. I re-voted to delete on one that I had received success earlier, and now receive the same error. You can vote on one of the old proposals if you want, and see it still works. Alright, we have to wait for the Pool to upgrade, and I have a lunch appointment today so please everyone be patient for 4 hours and we will take this up this afternoon. In the mean time, go ahead and issue the start-many commands to restart your sanctuaries, so we can try to get rid of the watchdog expired errors. |
|
|
|
|
So in a nutshell what mouse and I have found is the code that somehow passed in test (I have no clue how we successfully minted a superblock) has a bad character at the end of the superblock trigger, that offends Watchman, and prevents Watchman from importing the gobject, and then throws python errors.
So part of the solution was to modify BiblePay core to allow the pool to create a good superblock trigger in prod.
However, we have one bad superblock trigger in prod floating around all the sanctuaries.
Guys, help me out here, lets delete the bad superblock trigger now, and see if it is cleared out, please execute this command from all your sanctuaries:
gobject vote-many 1996fe78ce9efd7a3b6deefbcd2e120b75f850909ad8f702062a517b1cb27ae1 delete yes
After we see it is cleared, we will create a new superblock trigger this afternoon and re-vote on the budget.
(This will invalidate the current budget).
All credit goes to the most high God: Yeshua Hamashiach.
|
|
|
|
okik, ill go test it on my test server
and Masternodes is offline now? cos i see watchdogs expired
Yeah thats my post #2190, Im looking at this issue now. rpcgovernance.cpp line 114: sJson += GJE("type",sType, true,false); // Must be an Int is including a delimiter, "type\":2 ,}]]" in my case, I have changed the file "biblepaylib.py" 227 def deserialise(hexdata): 228 json = binascii.unhexlify(hexdata) .replace(",}]]", "}]]")229 obj = simplejson.loads(json, use_decimal=True) 230 return obj Yeah, good find, I found it also, but lets fix this one step at a time, I want to evaluate if its better for us to delete the bad gobject and create a new trigger next. So far, I fixed the original line of code that caused the problem (the one you noted in rpcgovernance.cpp), and Im doing a build with it. Only the Pools need to upgrade (that would allow me to emit a new superblock trigger). Please wait for directions on the watchman side, as I need to test deleting the original offending gobject trigger.... Edit: Mouse, are you interested in becoming a biblepay programmer? |
|
|
|
|
Show Posts
