Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 63. (Read 243376 times)

Yeah it was down during the night; its back up now.  I'm trying to find out why BBP was killed (because it is a high end box with plenty of RAM and swap space). 

Anyway its all up now.

Is the Nomp pool down at the moment?

I just thought of an interesting idea on the PR front slightly different than the airdrop idea (and the CPID faucet idea).

We could potentially dump the public keys out of the Dash BX, and make a reclamation system to give away BBP faucet rewards to existing public keys, that exist in the public BX as of a certain date (this is so people dont start manipulating them after).

It could potentially be a way to :  attract an existing crypto user, with knowledge, and verify semi unique new users all at once....

Something like :

1000 bbp is offered to new bbp-dash users who are found by public key with a DASH balance > .25 dash as of this date etc.

We can make a DASH-BBP faucet and a PODC faucet next.  Ill work on the PODC faucet asap.

I hope needyex does well too, its tough starting out

=

Found my post in the CoinsMarkets shutdown thread haha

I would TOTALLY support true decentralized trading!

=

Here is feedback from a technical user trying to use BISQ:
https://www.reddit.com/r/bisq/comments/dw6736/so_frustrated_with_bisq_no_wonder_its_not_going/
https://www.reddit.com/r/bisq/comments/dqh4rw/why_bsq/

John Mcafee recently launched a DEX:
https://cointelegraph.com/news/john-mcafees-decentralized-crypto-exchange-launches-in-beta
https://en.cryptonomist.ch/2019/10/08/mcafeedex-guide-to-john-mcafees-crypto-exchange/
Its only Ethereum tokens right now though

Thanks, I read that one, and now I think we may have enough information to move to the next step.

So out of all these algorithms they all boil down to requiring a large memory footprint, since GPU ram access is slow, trying to require as much overhead as possible (IE requiring the full node for a lot of startup data), and trying to thwart parallelization, and use functions that are fast in the CPU and slow in the GPU.  The RandomX algo is one of the more interesting ones; it requires a virtual machine to be compiled and seems to be executing dynamically created code in the VM, keeping the code theoretically running in a cpu only.

There are certain traps and truths however we can use for pobh 2.0.  It is definitely possible to create an environment that can be proven to be faster on the CPU and either impossible or guaranteed to be slower on the GPU.  So far, I have an idea of making the bible into a dynamically expanding piece of code in c++11 that uses lambda functions and recursive calls, to generate a non-deterministic diagram for each block, that uses a large scratchpad for each mining thread, with heavy string manipulation for the verses (say 65,000 string manipulations recursively called from a self generating bible for that block hash).  This is so far, one that appears to be impossible to port to a GPU, because of the C++11 requirements for one.  Second, if someone did port it, the string functions should theoretically be slower in a gpu (based on the CUDA research papers for certain string functions).  And finally, if we make it a dynamically recursive self creating program, it cant be ported to asic or gpu without porting all of c++11 in.  In addition, the performance of one CPU thread should theoretically enforce and guarantee it must be run on one GPU core thread in serial - because we will dynamically call the hash function in a serial fashion 65,000 times and rely on the prior result of each recursive call branch area (in its own recursive nature) therefore breaking the possibility of parallelization.  I sent this idea to MIP and he is reviewing.


So far this seems the most promising.  I like it because its simpler than RandomX to support (we would have one c++11 hashing class for POBH, not an entire virtual machine).  Then the exchanges, and the core wallet, and the external miner could still use it.

The goal would be to keep the external miner and nomp, add this in to the external miner, and also support solo mining.  If the testing outcome is as expected solo mining would be the same speed in the core client as the external miner after its released.  Then we could raise our bounty for cracking it to 10 mil or so (however, cracking it would mean that it is proven to run *faster* outside of a cpu).

I am still looking at dotnetcore, for valuable Part B functions, but Im thinking to keep us in good standing with the world and with exchanges, we must put that project into DSQL instead and not into the miner.  As then we can theoretically lower the hash reward in the future, guarantee all of our miners are CPU-only (for 10 years!, not forever), and put the impetus on PODC 2.0 rewards (useful work) etc.

Good for them, I hope they make it.
They remind me of our roots.  When we started, we had coinsmarket.com, remember how small they were? 

These exchanges are a hard business.  I think they need to come up with a model that allows key->key trading without custody.
I really liked that idea where we could force all tiny coins to add a github API that we write that is opensource, to facilitate chain to chain trading without custody risk.

Any hacker that gets into their cold wallet - or any bad employee that goes in at night to the cold wallet takes down the entire binance, etc.

What a redicules risk these centralized exchanges have.

Thanks, and Im glad we have successfully started to decentralize, this is very good for resilience and community strength.

Ill try to explain more about the technicalities in the extraNonce and the nTime on the header.

Thats great you have increased efficiency for the time being.

First let me do a little more research on these living CPU algos that are left, like you mentioned above.  I did check into the entire list from cpucoinlist.com last night and their inner workings (btw I asked them to add us to the list), and I didn't see anything new (that we didn't know about), but thanks for mentioning Gulden.  Ill check them out today.

Needyex Exchange Listed on CoinMarketCap!
https://coinmarketcap.com/exchanges/needyex/

Trade BBP on NeedyEx:
https://needyex.com/trade/index/market/bbp_btc

Learn More:
https://www.reddit.com/r/BiblePay/comments/dkbyvs/biblepay_has_partnered_with_needycoin_and_is_now/

https://whitewalr.us/2019/biblepay-nomp-pool-mining.html
Look under: Common messages on the external cpu miner

Also just wrote the following which may be of interest to you:

What does “Stratum requested work restart” mean?
https://whitewalr.us/2019/stratum-requested-work-restart.html

cpuminer 1.0.0.9  often show     stratum_recv_line timed out Retry ...after 30 seconds

Thank for all the work you've put into the external miner and NOMP pool. I along with everyone else I'm sure really appreciate all the work you put in. We now have 4 mining pools distributed all around the world (China, USA, Canada, France). I have miners from France, Russia, USA, and China according to their IP address.

I got the pool with better efficiency now. It probably helps that I upgraded to latest 1.4.5.2 instead of using an older version. I see what you mean now in the deploy notes about the new block after every share accepted. Thanks for bearing with my numpty persistence. 

That's great you plan on improving PoBH. Look forward to your enhancements. Monero has had a difficult time with cryptonote and keeping it away from ASICs. I think some CPU based coins specifically require large amounts of RAM. Gulden went to CPU only recently and they want 1GB of RAM for each mining thread along with other non-ASIC friendly properties.

So let me try to explain the way the KJV bible interacts with the hash algo.

Bitcoin uses Sha256 to hash the transactions.  Dash also uses Sha256 to hash the transactions.  We use Sha256 to hash the transactions.
However the blockheader is hashed with X11 in Dash and in BiblePay.
However what is different about BBP, is we use POBH to hash each X11 potential solution (we have a layer on top of X11).
The POBH hash dictates which starting verse (out of the 32,000 bible verses) the winning hash refers to.
Verses N-N+7 are just sequential pointers from the winning hash.
So basically, the miner already knows the sha256 hash of the transactions s/he is mining.  They then pick an X11 hash for the blockheader.
Then they call POBH repeatedly with this new changing X11 hash, and POBH returns a hash (with no verses).

Mining is simply repeating these steps until a POBH hash is found lower than the target.

The verses only come into play when you go to Look at them.  We basically say, what verse is pointed to from this POBH hash?
Then we can display verses 1-7 (using the sequential pointer) from the solved hash from pointer #0.
EDIT:  I forgot to explain something.  We have two levels of verses:  mining verses and display verses.  The Display verses are only accessed when you go to look at them.
The Mining verses however *do* come into play when POBH is trying to calculate its hash.  Depending on the bits inside the X11, the hash function will call certain algos inside the POBH class to calculate a POBH hash based on the text of the verses in play that are referenced by the X11 bits (So yes POBH does use verses, but they are invisible and never seen during the calculation of the POBH hash).


I wish I could look into the server for more root causes of the errors you show, but I am still of the opinion that if the error rate is < 10% we don't really have a problem.
You could potentially ask MIP to look at that but thats if he is free.

I feel my next endeavor has to do with shoring up Two things I don't like to the full extent about POBH (I like POBH from a CPU mining perspective, but Im referring to POBH 2.0):

1) I would like POBH to be absolutely impossible to port to a GPU.  This is something I'm working on in the background, as I feel we need to break any potential white hat hackers who try to crack POBH 1.0.  (Another words, I don't ever want any hackers to be able to earn BBP from a GPU while the rest of us are running on a cpu.  This is a proactive step Id like to take now.)  This is also something I believe every CPU coin went through - and to my knowledge they all eventually failed as cpu algos - if the coin itself became successful (IE successful monetarily speaking) - Im not sure about the status of cryptonote.  Do we have any solid statuses on surviving cpu algos that stood the test of time and still remain cpu algos to this day?
2) I would still like the core client to mine by itself without an external cpuminer, and at the same exact speed as the external miner.  I did like the ability to have a 'full node' with everything in it - the way we had it before.  But we had to go through this current pain to add stratum/nomp to our infrastructure first, to get stratum in the mix.

Note:  I see the SSL cert expired on pool.biblepay.org.  It has been updated today.

Could everyone please withdraw their funds from pool.biblepay.org?  I'd like to start locking it down so we dont have the liability.

We can still have letter writing and rewards, but Im going to disable unecessary features and refactor the site so it is more secure.

Perhaps there will be an upswing for these orphan 2017 privacy masternodes, now that the top 100 is becoming centralized.

I agree with you Togo and Sun, they started making centralized decisions when they should have built an algorithm for that de-listing and listing operation internally.

Also, they should have honored our 1 btc payment for a longer period.  For $9,000 all we got was one year of service.  (And for half of those months, they were down -- because they would not upgrade our software unless we paid a $4,500 fee).  So we told them to keep us down til the cooloff period is over and give us the free upgrade.  So we basically got junk service for $9K and then delisted.

Also, this KYC was sprung on everyone out of the blue- If they are decentralized they should place the servers in areas of the world that do not require KYCs.

The biggest punch in the gut though is we didn't even get our 2 month notice before de-listing.  That's a breach of the original covenant.  People can see that from the original listing thread that Togo posted.

I took a look at how hard we worked to raise the 1btc.  This was when Jaap was saving our New Exchange funds.  We should not be treated like a red headed stepchild as a charity coin.  InBlue made the comment : Can they list us for half, because we are a charity coin, but it appears we paid the full rate.  No discount!  Anyway, this $9K could have been spent on 200 orphans!  

So at the very least I think we should be given a 6 month notice, and given a chance for volume to increase.

I agree with you Togo, this is very, very bad.

Yeah, I think we should get a full refund.  For breach of contract. 

** Inbound letters from Kairos **


http://pool.biblepay.org/SAN/Mission/Kairos/k10.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k11.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k12.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k13.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k14.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k15.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k16.jpg
http://pool.biblepay.org/SAN/Mission/Kairos/k17.jpg

If they will cooperate with a refund, why not. That amount of BTC can provide big help for BBP. Or, you can use that amount to get listed to other exchanges that are reputable (though the amount of exchanges nowadays dwindled down so fast). In a sense, we can see it as a silver lining because you will no more get connected with that exchange that is turning into a shit-exchange because of their dumb decisions regarding their policies.

Good find MIP!

CryptoBridge Discord:
https://discordapp.com/invite/H6Qt2dQ

We should ask for a refund?

Heres the original thread:
https://forum.biblepay.org/index.php?topic=179

History:
- They went back on their word on their update policy, and asked us for 0.5 BTC to update
- They admitted that they're not actually decentralized
- They surprised everyone with mandatory KYC (Know Your Customer)
- They said they would give us warning for low volume but to my knowledge they didnt
and we are now on their list for delisting in 2 weeks

=

Their Bitcointalk account got flagged:
https://bitcointalksearch.org/topic/anncryptobridgebcogateway-to-bitshares-released-now-beta-2015949

From CryptoBridge

Be rest assured that the normal mining pool won't even be able to check our hash solution without the KJV bible, but nevertheless I would not mind talking to them.

If Togo or Dimarzio finds someone that appears to list a lot of coins in a multipool feel free to forward them and Ill at least have a few chats with them to see where the stumbling blocks are.

Im not personally as worried about sell pressure because I think anything that expands our relationship has both a pro and con side.  Basically from the DSS model, I feel that mining rewards are positive, because a certain amount of latent bbp sits on peoples computers, but, it is good for PR.  And a certain % of users always end up becoming investors naturally, etc.