Topic: BiblePay - New Coin Launch - Official Thread - page 150. (Read 119833 times)

so sad, only CPU mining

Block source not available


node.biblepay.org  is added
have 8 active connection...


What can i do?

1 hour and is sinhronised =))

tnx )

Happy,
Btw, I wanted to say you are definitely on the right track and what you explained is a good idea, and would almost work - that is to pull the core miner out of biblepay, and extend the X11 miner standalone EXE program to generate biblehashes, and modify the Web side of the Pool to accept biblehash as a solution, but there is one thing that I am trying to accomplish in BBP to keep it from growing into the run of the mill rat-race type greed system, where everyone just wants to spend money on hardware instead of running a full node: that is early on, I attempted to make the biblehash algo itself reference a historical tx in the chain, so that to run the biblepay miner, you had to run a full node (giving us network stability) by the hash algo itself exercising the ability to find historical chain info when reqd.  More recently I settled on passing in things about the current and previous block into the miner, meaning that, the X11 standalone EXE would only be able to run a miner if we pass it those things - or if it is a fullnode it already knows those things.  Thats good however, as it adds value to our full node network.  (The question is do we want to add something in to make it impossible to run a standalone X11 miner?  Im mostly against the standalone miner and Pro-full node hashing). 

So I hope that explains why it would be more of a preferred choice for me to make the "standalone X11 bible miner" an extension of the qt clients capabilities (so as to future proof the algo cemented inside the wallet) - and then just write a web pool interface (OR, pull the X11 pool
 web code first, that is sort of a 50-50). 

Hi Plain,
So most of the features Dash has (anonymous tx, instantsend, masternodes) are in the wallet but shut off right now until Christmas when we enable Sanctuaries (these are similar to masternodes but are going to have some Humanitarian features added), so without one Sanctuary running, the alerts just hang there.  You should not have to worry about it as it should not affect standard slow sending/receiving of funds, just ignore for now.

=-=-=-=-=-=-=
To all others mining:

My two AMD nodes finally exploited the 'mining thread dying' bug (you can see when this happens when the node stays running but the getmininginfo shows the same khps with no updates).  So I have a list of things to fix in our next non-mandatory and I am trying to tackle this problem now, and I will also make the khps update a little slower, so the miner is more similar to our first as far as performance goes (I think that is only 1% however) - with any luck I might have a release tonight to at least test the stability throughout the next few days.  I want to put that bug to bed, before we go to the exchange as I want a rock solid client for the exchanges to run. 

=-=-=-=-=-=-=-=

As far as a pool:
Yes, on the X11 hash wrapped inside a BibleHash with both being checked that is correct,  but the problem I think we run into with traditional pools is the client mining software reqd to interoperate at the HTTP level with the pool is not compatible with BiblePay hashes (another words CGMiner or SgMiner or any of those wont be smart enough to generate the biblehash and send the solution to the pool) so we need some custom software written.  I was thinking we could build the mining software into BiblePay (no additional dependencies, just c++ changes to enhance the existing miners capabilities) in a way that would allow biblepayd or biblepay-qt to connect to a pool, but only if the pool option was enabled, if the pool is down, it would shut off the setting and revert back to solo mining.  Then we could make an opensource web pool and let people run those sites (pools) and expose the URL to us.  The setting in biblepay would be something like pool=http://poolurl.biblepay.url .  Basically you could sign up on the pool web site with your BBP receiving address as a username and create an account and hopefully the client could be smart enough to do the rest. 

Hello -

Curious if anyone has come across this (Win7 Pro x64 Wallet v. 1.0.1.6)

After I transfer coins to another wallet, leaving an Available balance 0.49.  When it finds another block I get an error in Amount and Rounds (in red text) ~ 0 Biblepay / 2 Rounds: Error: Not enough compatible inputs to anonymize 1000.00000000 Biblepay, will anonymize 0.49995020 instead.

I have seen this on two different wallets after transferring funds to a 3rd.

Thank you for any suggestions.

Do you mean to build Biblepay wallet in Linux?

I have tried to build biblepay in Ubuntu 14.04 but failed with openssl version issue. Then I built again in Ubuntu 16.04 without problem. Just follow the instructions of a file named something like "build biblepayforlinux.txt" in the git will do.

What failure message do you get? It is not a stock standard traditional compile. Post your error message that you get.

Getting one every 12 hours. Still good to mine

I'm not really an expert on this sort of thing, but looking through the source code BiblePay basically wraps Dash in a BibleHash? It looks like a normal x11 hash which is fed into the BibleHash algo and if both the x11 hash and BibleHash hash satisfy the target for the current difficulty then it's a solution? If that's the case, I don't think it'd be terribly difficult to extend existing x11 cpu miners and pool frameworks to work with BBP. Probably a little bit too advanced for me currently, or I'd give it a shot myself.

Been trying to build this on a VPS but the build always fails on the make step. Is it possible to build just 'biblepayd' only?
For context, I've been building other wallet daemons with a 'make -f makefile.unix' without problem.

Getockhash 570 is the same as yours.

Yeah we probably have a remnant of a fork out there from block 500s mandatory change.

Try doing a showblock 570 and see if this hatch matches:

0000002f2664560053e01cfc0aea95a92b833d2b5363771423adf1e7497b95a7

Otherwise try deleting your blocks folder and chainstate folder, and rebooting.

Regarding the crash issue I will have a look at that later today if possible.

Regarding the pool, I am thinking of writing one, but if someone else is already considering doing that please let us know.
We can still solo mine for a while even if it takes a month to find a block.

I'm currently on Block 571. I was mining all morning and the client did a hard crash and came back up with a syncing issue. Cleared the blockchain files and rebuilt and then reloaded my wallet. Got me onto the right chain. So I lost about 5 hours of mining. I was finding to many blocks for it to be realistic anyways 8+.

i mining on 2 pcs,but the block height is diffrent.
one is 544 and another is 570.

the pc which block height is 544 found 9 serial blocks from 535 to 544.
and these blocks CAN NOT find on the http://biblepay.inspect.network.

did i mine alone in a wrong blockchain?

i've reboot the pc and wallet but noting changed.
should i keep mining on it?

19 hours in, no blocks.

"networkhashps": 1670.96146212608,
"hashps": 13644.09384447202,

anyone working on a pool?

where can i buy this coin? wanna invest much btc

Yeah I was sleeping from block 500-510 but it looks like we recovered- diff is back up and on the external node, and everyone but a few upgraded (I see over 90% on the new version).  I was not too worried about it, because the old client is mostly backward compatible with the rule (IE, if we had only 51% upgraded, the old wallet would actually accept the tithe blocks, but could only not mine the Tithe block properly) so I figured we would recover at the worst once 51% reject the questionable tithe block and gain the advantage.

On that 2bbp transaction, we do have the anonymizer from dash, for a later discussion, but in this case I wanted to say, the wallet has to break large bills almost like a cash register clerk, when you have an input that is 20000 and you want to spend 2, you actually spend the 20000 and receive 19998 in change, so that is why those type of initially spent mined tx look confusing.

Looks like we forked the difficulty is way down and I've found 9 blocks within a two and a half period time. Running 1.0.1.6. On a separate note it looks like disabling the monitor power save function allowed me to mine all night.

That was me sending 2 BBP to myself (Don't ask why) 

It's kind of hard to read on the block explorer, but it's not two rewards. The list shows all transactions, not just blocks mined (mining a block is itself a transaction since coins are issued to a receiving address).

Using block 495 as an example, it contains two transaction hashes, 71ce1908f47e8c8a301ffdc98a1b72c0cdc72a59343a613011b38ef2e0c1a599 and 2ec6f92d60ab3a5118c2e2c614908faab37e80f4287f3d435a39829317009d45. This first is the mining event, showing 19979.00004980 new BBP being issued to the receiving address BQBxjH7oeFWesSj8YHRNBbibseEXxaTnqj.

The second is a normal transaction, someone sent 2 BBP from the sending address B6XrHp2QS4k9qmZuQL3tQY3922wZ3QbX3i to the receiving address B9Y2GuK68WruvMSjX8PqmAiobdTXWmqQ3C. This is the part where it gets weird. Personally I'm not really sure what's going on myself (maybe the dev has an idea?), but it seems like when a payment is sent from an address, the specified amount is sent to the designated payment recipient, and the remaining balance associated with the sending address is sent to a new receiving address linked to the same wallet as the sending address. I think it might be some kind of payment anonymizing feature?

To try to clarify, say I have

with 100 BBP linked to it.
I send 2 BBP to

.
The blockchain will record this as single transaction with two receiving address where 100 BBP were sent from

, 2 BBP were received by

, and 98 BBP were received by

, with

being a newly generated receiving address linked to the same wallet as

.

Sorry if it's not very clear, I'm not 100% clear on this myself, but that was the gist that I got from experimenting.

No extra BBP is being generated. You can confirm this by dividing the total coin supply (10017274.0028612 as of now) by the number of blocks (501 currently) and getting 19,994.5 BBP which is the average block reward.