bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 12, 2019, 03:29:27 AM |
|
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 12, 2019, 09:58:15 PM |
|
We should ask for a refund? Heres the original thread: https://forum.biblepay.org/index.php?topic=179History: - 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://bitcointalk.org/index.php?topic=2015949.0Definitely ask for a refund. Worse and likely response will be no. Their assessment is incorrect. "Minimal development" does not fit BiblePay. Minimal volume perhaps, but no one has ever accurately accused BiblePay of lacking development. 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.
|
|
|
|
MarquiseMuseum
Member
Offline
Activity: 741
Merit: 29
www.MarquiseMuseum.com
|
|
November 12, 2019, 10:36:58 PM |
|
Perhaps there will be an upswing for these orphan 2017 privacy masternodes, now that the top 100 is becoming centralized.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 13, 2019, 06:25:50 PM |
|
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.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 13, 2019, 06:39:57 PM |
|
Rob, can you explain how the KJV verses interact with bbpminer and the nomp pool? Does the miner pick the sequential verses? Would randomizing the verse selection per share submission change the block hash that the pool sees? Would this prevent/reduce duplicate share errors on the pool? I've made a few tweaks to the pool settings and got it working better. The three most common errors for me now are (in order of prominence): 1) duplicate share 2) low difficulty share 3) job not found I think error 2 & 3 are normal. 2 is a fact with vardiff. 3 is due to stale share or miner sending in share from previous block. 1 is my biggest count of errors and I don't know that I'm smart enough to figure that one out! 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.
|
|
|
|
sunk818
|
|
November 13, 2019, 10:58:51 PM Last edit: November 14, 2019, 05:38:44 AM by sunk818 |
|
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.
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.
|
|
|
|
polipoli
Newbie
Offline
Activity: 13
Merit: 0
|
|
November 14, 2019, 05:19:03 AM |
|
cpuminer 1.0.0.9 often show stratum_recv_line timed out Retry ...after 30 seconds
|
|
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 14, 2019, 02:07:56 PM |
|
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.
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. 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.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 14, 2019, 02:11:41 PM |
|
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.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 14, 2019, 04:29:46 PM Last edit: November 14, 2019, 11:31:02 PM by bible_pay |
|
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.
|
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 15, 2019, 03:56:39 AM |
|
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.
|
|
|
|
Budinga
Newbie
Offline
Activity: 19
Merit: 0
|
|
November 15, 2019, 01:34:38 PM |
|
Is the Nomp pool down at the moment?
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 15, 2019, 03:47:33 PM |
|
Is the Nomp pool down at the moment?
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.
|
|
|
|
inblue
|
|
November 15, 2019, 05:49:21 PM |
|
Found my post in the CoinsMarkets shutdown thread haha I still have a little Bitcoin stuck on CoinsMarkets...
Hope we can all learn: not your private keys, not your coins!
Is the future of trading decentralized exchanges?
Maybe not so "haha" for me, this is a screenshot from my CoinsMarkets account which I took when the website was barely working, but wouldn't allow withdrawals: And that was January 6th 2018, when BTC was around $17,000. But you're right to laugh it off and move on. By the way, I hope you all looked at the Trust summary page of the Needycoin account: https://bitcointalk.org/index.php?action=trust;u=2687874Running "charity" based project without almost no basic info and after 2 failed and abandoned previous projects. Also falsely accusing of blackmail and extortion
|
|
|
|
sunk818
|
|
November 15, 2019, 06:57:38 PM |
|
Is the Nomp pool down at the moment?
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. The pool hash rate jumped to 5MH around 10 hours ago. I take it that when your pool went down? It is not making too much of a difference with found blocks. I could be wrong, but I think someone is solo mining all the blocks recently (maybe eternalenvoy ?). I'm impressed with how much hardware this person has to use at the BiblePay network. They will be formidable contributor when PoDC 2.0 comes around as well. Hopefully, the staking algorithm will have its intended effect for people with lots of hardware.
|
|
|
|
togoshigekata
|
|
November 15, 2019, 07:28:29 PM |
|
I am sorry for your loss inblue
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
November 15, 2019, 08:00:18 PM |
|
Found my post in the CoinsMarkets shutdown thread haha I still have a little Bitcoin stuck on CoinsMarkets...
Hope we can all learn: not your private keys, not your coins!
Is the future of trading decentralized exchanges?
Maybe not so "haha" for me, this is a screenshot from my CoinsMarkets account which I took when the website was barely working, but wouldn't allow withdrawals: And that was January 6th 2018, when BTC was around $17,000. But you're right to laugh it off and move on. By the way, I hope you all looked at the Trust summary page of the Needycoin account: https://bitcointalk.org/index.php?action=trust;u=2687874Running "charity" based project without almost no basic info and after 2 failed and abandoned previous projects. Also falsely accusing of blackmail and extortion I'm sorry for your loss too. We didn't see the trust page. We have a tendency to 'accidentally' make friends with people of questionable integrity all the time. I do believe in second and third chances though. Jesus hung out with the tax collectors and the sinners. However, we have to be cautious and try to yoke ourselves with ambassadors of God.
|
|
|
|
|