@Bible_Pay
How are the outgoing letters processed again? As in the time between each outgoing queue is processed? Thanks -
Keep writing those letters all! After yesterdays Vegas tragedy, I feel ever more pressed to tell people about the Light.
Its semi-automated right now. I have to run a job and do a couple manual things. They will be processed by Friday though. Our batch job picks up any unsent approved (being 7+ upvotes) letters and marks as sent, pays the bounty, and sends it to compassion (after converting to a PDF with pictures embedded). |
|
|
|
HELP NEEDED FOR SANCTUARIES for Christmas go live:
Ive been doing a little testing over the last few days for the upcoming sanctuaries. I discovered I will need a lot of help otherwise we cant go live with sanctuaries.
We need at least 8 or so testers in the sanctuary thread (the thread does not exist yet). Im going to deprioritize the news testing thread, and create a sanctuary thread and post it here by the end of the day, and lets focus on testing in that thread otherwise, we wont have a chance of going live at Christmas.
There are a lot of variables, and here are some, that need worked out:
- Testing requires linux - because windows will not run watchman on the wall (thats the decentralized sanctuary database)
- Testing requires 500,000 bbp to be sent to the new testnet masternode (actually send more, so you have extra first) - this is not the final amount to run a sanctuary, its the testnet amount
- Testing requires an external open IP, IE you need to be able to run with the firewall port 40001 open
- Testing needs to have the latest version of BBP compiled from source
As you can see this is a complicated endeavor and therefore requires a lot of help to get this working properly by Christmas.
If you want to get started you can do the above and sync the node up in testnet and then you will be almost ready to help.
The reason I cant do this myself is there are security rules in place that hang up on other sanctuaries if certain conditions are not met, and they cant be disabled. One particular rule is dont accept inbound connections from sanctuaries unless the mnsync status is 999, and that will fragment the network. IE we need more than 4 or so synced nodes to test this properly. Also, the governance qurorum is going to require a few synced sanctuaries in order for us to test voting on the fake proposal. The fake proposal will have the orphanage budget in it, etc. Otherwise, I cant see the votes.
Quoting for exposure, need additional help on the testnet to get Sanctuaries(Masternode) running. Yeah, let me create a thread real quick and then Ill edit this. I created a masternode wiki article. The sanctuaries are coming online now in testnet. As far as the price, West, its 500,000 tBiblepay. |
|
|
|
|
HELP NEEDED FOR SANCTUARIES for Christmas go live:
Ive been doing a little testing over the last few days for the upcoming sanctuaries. I discovered I will need a lot of help otherwise we cant go live with sanctuaries.
We need at least 8 or so testers in the sanctuary thread (the thread does not exist yet). Im going to deprioritize the news testing thread, and create a sanctuary thread and post it here by the end of the day, and lets focus on testing in that thread otherwise, we wont have a chance of going live at Christmas.
There are a lot of variables, and here are some, that need worked out:
- Testing requires linux - because windows will not run watchman on the wall (thats the decentralized sanctuary database)
- Testing requires 500,000 bbp to be sent to the new testnet masternode (actually send more, so you have extra first) - this is not the final amount to run a sanctuary, its the testnet amount
- Testing requires an external open IP, IE you need to be able to run with the firewall port 40001 open
- Testing needs to have the latest version of BBP compiled from source
As you can see this is a complicated endeavor and therefore requires a lot of help to get this working properly by Christmas.
If you want to get started you can do the above and sync the node up in testnet and then you will be almost ready to help.
The reason I cant do this myself is there are security rules in place that hang up on other sanctuaries if certain conditions are not met, and they cant be disabled. One particular rule is dont accept inbound connections from sanctuaries unless the mnsync status is 999, and that will fragment the network. IE we need more than 4 or so synced nodes to test this properly. Also, the governance qurorum is going to require a few synced sanctuaries in order for us to test voting on the fake proposal. The fake proposal will have the orphanage budget in it, etc. Otherwise, I cant see the votes.
|
|
|
|
- General Cryptocoin c++ Developers
- Developer that has zeal for finding security bugs in BBP and BTC.
- Developer that wants to take Dash and BTC recent commits, and merge them into BBP. This is a highly technical position requiring BTC or crypto experience.
- Web developer to make Biblepay web presence better (The web site, Not the pool, I can handle the pool myself for now)
- PR Manager, launching PR campaigs, faucet, etc
- Twitter, Facebook / Social Media Manager
- Operations & Charity management
- Tech Support (Helps resolve users issues with mining, wallet setup, etc)
- Technical Writer for documents
I saw a post come across that someone wanted to be a technical writer but dont see it in the last 5 pages anymore. If you are still interested in joining the slack team send me an email to : rob@biblepay.org and we will send you an invite. |
|
|
|
Spreading the trading thin on multiple exchanges is not good for a small volume coin. Additionally, since the coin is so young and things change from time to time, exchanges look down on having to go offline to redo mandatory wallets. The thing that has been talked about is after Masternodes (Sanctuaries) go online in late December, the Dev (well, the DAO at that point) will look at adding more exchanges. Hopefully by then, volume/pricing will be sufficient to maintain a healthy trade on more than one exchange. Right now with the price hovering at 11 to 13 satoshi it takes a lot of volume to make it worth an exchange's time. We are getting by on C-Cex since they consider us a charity style coin and not quite subject to their normal rules. The hope is that Masternodes will be the jump start to move this coin forward to the point where it becomes reasonable to be on more than one exchange.
That seems fair enough. I don't want to trade on C-Cex (at least not yet) and I don't think I can buy on the biblepay website, so I will try to get mining set up for now so I can get some of this coin. I dont think we can offer website trading due to trading regulations per county, except, we can offer a free faucet. Im going to eventually airdrop 1 million BBP through a google campaign, as long as the user downloads the wallet, eventually when I get a chance. @bible_pay What are your thoughts on connecting Biblepay with Bitcoin/Litecoin through a lightening network. Will offer a p2p option to deposit and buy. as well as can make the coin an easy destination for charitable donations, one can setup, say 0.001 BTC to be donated every month via Biblepay and it can be ran it through the DAO. What are the technical challenges and feasibility constraints? Feel it can provide a more connected ecosystem with other established coins and also creating more value + exposure for Biblepay. I like Vertcoin's lightening network with litecoin as a means to make micro transactions, same way Biblepay can be setup for micro donations. Would like to hear the community's thoughts on this. Edit: https://github.com/lightningnetwork/lndWell its certainly an impressive API. I like how the group coded it in Go, which is a language I never used, but its certainly interesting. It looks to be well thought out, extensible and useful. I see its constantly changing - being expanded and contributed by over 10 people. It appears at the core, the bitcoin daemon runs with segwit turned on, and that participating nodes form a service over a secure channel. I think the core functionality is that a merchant can transmit an invoice on the fly in an encrypted string over the channel into the hive of daemons, and then one chosen node picks up the invoice and the corresponding payment and pays the invoice, thus facilitating payments using tokens (IE lets pay $1 to XYZ from user ABC) without either having to type 60 characters in, its a full fledged po/invoice/payment decentralized payment system. As far as modifying it and running it with BBP instead of BTC, maybe. I mean there are a lot of factors to consider and what its primary use case is. One involves if each masternode would be a lightning node, and be required to update every time lightning changes, or if we would have one lightning node run at 'biblepay central' (if we have such a place etc). Right off the bat though, these questions can be answered by solving some of our most rudimentary requirements first and then the answers will be clear. Imo, we need order depth, volume, and usefulness for biblepay. So I think after the sanctuaries go live, we still seek to be listed on a few of the big exchanges, maybe we pay them in BBP if they refuse to help us for free) and that should help half of the volume problem (as volume does not thin out when we expand exchanges like some posts claim here, it increases), that will help a lot causing volume to go from .2 btc per day to 5-6 btc a day. Then we integrate with one debit card. I think we really need to prove that you can order a roll of silver coins with BBP to have around during the great tribulation, maybe an order for some emergency food pails, just prove that biblepay is a useful currency. You can also use your BBP debit card at a restaurant. |
|
|
|
Spreading the trading thin on multiple exchanges is not good for a small volume coin. Additionally, since the coin is so young and things change from time to time, exchanges look down on having to go offline to redo mandatory wallets. The thing that has been talked about is after Masternodes (Sanctuaries) go online in late December, the Dev (well, the DAO at that point) will look at adding more exchanges. Hopefully by then, volume/pricing will be sufficient to maintain a healthy trade on more than one exchange. Right now with the price hovering at 11 to 13 satoshi it takes a lot of volume to make it worth an exchange's time. We are getting by on C-Cex since they consider us a charity style coin and not quite subject to their normal rules. The hope is that Masternodes will be the jump start to move this coin forward to the point where it becomes reasonable to be on more than one exchange.
That seems fair enough. I don't want to trade on C-Cex (at least not yet) and I don't think I can buy on the biblepay website, so I will try to get mining set up for now so I can get some of this coin. I dont think we can offer website trading due to trading regulations per county, except, we can offer a free faucet. Im going to eventually airdrop 1 million BBP through a google campaign, as long as the user downloads the wallet, eventually when I get a chance. |
|
|
|
this coin is coded very very very bad differents results with diff CPUs  Two things: 1) This algorithm is designed to prevent mining outside of CPUS. 2) This community IS NOT ABOUT MAKING YOU MONEY. We are doing exactly that, so apparently its working flawlessly. Just my 2 cents, but I think keeping the way mining works a secret will backfire and bring in the exact type of people in that you do not want mining this coin. All it will take is someone to figure out the secret to the ultimate optimization, not tell anyone else, then saturate the network hashrate. With a small coin like this you would open the possibility of a 51% attack. Inblue has already posted the anomaly of multiple daemons performing better than one. Its true the community is not about making people rich, but with the decentralized nature, anyone can be involved. Just keep in mind that without miners the blockchain becomes insecure. There are no secrets here- all the code is public on github. Inblue posted an anomaly that is less than I expected in percentage. We are Expected to be a coin that is mined from single Hosts vs CPUs, as we utilize the Node more than the processor itself. I dont buy the 51% attack even at this level, we have over 1000 miners on the pool alone. We had a fair launch, we are as distributed as you can get. We require Non asic and Non GPU hardware, so we are even more decentalized than bitcoin. Since we have full nodes, we already have more external public nodes per user. |
|
|
|
On fair use, it's unfortunately a pretty complex thing. I used to work in the media, so I do know a bit of what I'm talking about here. The issue would be at first, when the coin is small, there wouldn't be any problems. Even if copyright / fair use was violated, it wouldn't be worth the time for a company to chase it down. This would likely lead to bad habits becoming ingrained as it pertains to copyright and fair use.
The risk is lets say I word-for-word copy a news article today. It becomes part of the block chain. Five years from now, the DAO is bringing in $250,000 a year. Some lawyer looks at our block chain, has the proof we violated copyright and sues the DAO (since they cannot identify the writer with ease, and ultimately, you sue who has the money). They would likely win. To avoid this, you'd have to have all the articles vetted. This becomes a logistical nightmare.
Worse, if something untrue was reported, and it was done in a malicious way, the DAO could get sued for liable. Since there would be no way to retract the article (immutable) the damages could be significant and ongoing.
The ultimate issue becomes, the block chain is immutable. If something gets posted to a website, it can be changed, or deleted. If the article itself is the block chain, there is no easy way to fix errors.
Well said. I'm not taking anyone's side, but this seems reasonable. Yeah, I sort of agree with West's opinion on this now. I was researching DAO lawsuits earlier today, and it seemed that there is a 'potential' of a DAO being sued, if the jurisdiction could be proven. Id lean towards not providing a tool for someone to commit copyright infringement. However, it could be argued the DAO didnt submit the article but the user submitted the article. Maybe we need an attorney, a copyright or patent attorney to jump on and tell us how we could protect ourselves as a DAO from such a risk. Could it be a checkbox before an article is submitted releasing the DAO from liability? |
|
|
|
this coin is coded very very very bad differents results with diff CPUs Two things: 1) This algorithm is designed to prevent mining outside of CPUS. 2) This community IS NOT ABOUT MAKING YOU MONEY. We are doing exactly that, so apparently its working flawlessly. |
|
|
|
Regardless of what the percentage is I prefer the previous suggestion several weeks ago of a 15% "fund", with by-laws saying that a minimum of 10% goes to charity and the remainder can go to development (IT) or marketing or additional charity if the previous two items aren't needed.
Before the Masternode percentage gets set in stone, the two big things to determine are Masternode cost and how well it beta tests, and if December 25 is a reasonable target still. Then I would also include a provision in the Masternodes that grants them testcoins on the same basis. That way new Masternode features can be tested for a few months on testnet. Speaking of which, when are you expecting to start testing Masternodes?
Biblepay News has crashed the testnet both times I've tried to use it, causing us to restart the testnet blockchain. I like the utilization of the blockchain for other uses, but still don't know if news as such a temporal topic needs such immutable status.
But above all else...THANK YOU to the Dev for your tireless work with this labor of love.
Thanks for testing it out to see the bugs, as earlier stated the developer needs keen eyes for locating and snuffing out issues, I assume he also means within the testnet. I think the "Biblepay News" is an idea with it's heart in the right place but if it's causing problems then maybe just scrap it and reduce complexity. Keep in mind that the developer is a busy man and has much to attend to. "Bible Pay News has crashed the testnet blockchain"? LOL, No biblepay news isnt crashing. I dont even think its being tested. If anyone has a crash report, we need an explanation of how you reproduce the crash and the part of the log with the crash (not a paste of the whole log). Here is the forum for that thread: http://forum.biblepay.org/index.php?topic=14.msg91#newPlease test blockchain news, and post any issues there. Yes, I still want blockchain news to be part of BiblePay, and I asked a week ago for someone to start checking on Best Practices for paraphrasing current news articles and copyright laws, and havent heard anything (just strong opinions as to why we shouldnt have it), but again, let me make a couple statements on my opinion: - I would not have considered blockchain news if I thought it would be consuming too much size (the articles only consume 1k per page, thats miniscule) - I would not have created a testnet thread if I thought it was a dumb idea - I believe "old news" is still better than no-news in our blockchain - Its immutability is fine in this case, as its a use-case for the blockchain - We charge a storage fee to insert an article anyway, so thats a use case for burned coins, and benefits orphans - There is only so much creativity that can be done by one person per week- so blockchain news is more of a creative effort, its not something that spams the chain (as it takes energy and effort to create an article). Take a look at the orphan letters- we have only written half of the required letters and thats on the web- because they take effort to write. Regarding 7 minute blocks, I deliberately set up wide block spacing with the chain to save chain size and increase loading speed. I am against 1 min blocks. We will have instandsend after the sanctuaries go live, so we really dont have any downsides after they go live. You know I love this coin, but I reported in testnet thread two instances of when I submitted news articles. Couldn't ever get my miner to sync after that and low and behold the next day the testnet blockchain was restarted. Just now tried to submit an article and it crashed core (log below). Resubmitted it and it worked and is ID cd5b3dd24423241290b25e1f72563689eea2e58755f122504dca3cb299282a9c. Can read it but once again, I'm now out of sync with the network. I'll let it run all day and see if it resyncs or not. 2017-10-02 12:25:53 generated 20000.00 2017-10-02 12:25:53 ERROR: ProcessBlockFound -- generated block is stale 2017-10-02 14:56:43 Original OldImg <img <style type="text/css"> COST HTML <style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:8.25pt; font-weight:400; font-style:normal;"> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"> 2017-10-02 14:57:11 ADDING BLOCKCHAIN ARTICLE Creating TXID #0.000000, ChunkLen 920.000000, with Chunk <MT>NEWS</MT><MK>Las Vegas, NV Shooting 2017-10-02</MK><MV></MV><NEWS> <style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:8.25pt; font-weight:400; font-style:normal;"> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><h1>Breaking News October 2, 2017</h1></p> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Over 50 people killed and at least 400 wounded in a mass shooting in Las Vegas, Nevada. Reports are still incomplete and the story will unfold for days yet to come. But was is known is a gunman using multiple rifles shot thousands of rounds into a crowd gathered for a Country Music concert. The President of the United States of America is set to speak on live television about the attask. if the numbers hold true, it would become the deadliest mass shooting i 2017-10-02 14:57:11 Creating TXID #920.000000, ChunkLen 33.000000, with Chunk n U.S. history.</p></body></html></NEWS> 2017-10-02 14:57:11 GUI: Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. Hmm, just checked the testnet thread for BlockChain news and dont see any posts from you. Could you post it in that thread? http://forum.biblepay.org/index.php?topic=14.msg91#newThis forum is only for new users coming in from dash and bitcoin. The official forum is the one that handles all testnet testing now and will be equipped to handle the slack expansion. We are going to need 10-20 topics. The reason the testnet chain was restarted is because I needed 1 minute blocks for testing sanctuaries and that is completely unrelated to blockchain news. Im trying to run an end-to-end sanctuary test before releasing the wiki with instructions for testing sanctuaries. |
|
|
|
Regardless of what the percentage is I prefer the previous suggestion several weeks ago of a 15% "fund", with by-laws saying that a minimum of 10% goes to charity and the remainder can go to development (IT) or marketing or additional charity if the previous two items aren't needed.
Before the Masternode percentage gets set in stone, the two big things to determine are Masternode cost and how well it beta tests, and if December 25 is a reasonable target still. Then I would also include a provision in the Masternodes that grants them testcoins on the same basis. That way new Masternode features can be tested for a few months on testnet. Speaking of which, when are you expecting to start testing Masternodes?
Biblepay News has crashed the testnet both times I've tried to use it, causing us to restart the testnet blockchain. I like the utilization of the blockchain for other uses, but still don't know if news as such a temporal topic needs such immutable status.
But above all else...THANK YOU to the Dev for your tireless work with this labor of love.
Thanks for testing it out to see the bugs, as earlier stated the developer needs keen eyes for locating and snuffing out issues, I assume he also means within the testnet. I think the "Biblepay News" is an idea with it's heart in the right place but if it's causing problems then maybe just scrap it and reduce complexity. Keep in mind that the developer is a busy man and has much to attend to. "Bible Pay News has crashed the testnet blockchain"? LOL, No biblepay news isnt crashing. I dont even think its being tested. If anyone has a crash report, we need an explanation of how you reproduce the crash and the part of the log with the crash (not a paste of the whole log). Here is the forum for that thread: http://forum.biblepay.org/index.php?topic=14.msg91#newPlease test blockchain news, and post any issues there. Yes, I still want blockchain news to be part of BiblePay, and I asked a week ago for someone to start checking on Best Practices for paraphrasing current news articles and copyright laws, and havent heard anything (just strong opinions as to why we shouldnt have it), but again, let me make a couple statements on my opinion: - I would not have considered blockchain news if I thought it would be consuming too much size (the articles only consume 1k per page, thats miniscule) - I would not have created a testnet thread if I thought it was a dumb idea - I believe "old news" is still better than no-news in our blockchain - Its immutability is fine in this case, as its a use-case for the blockchain - We charge a storage fee to insert an article anyway, so thats a use case for burned coins, and benefits orphans - There is only so much creativity that can be done by one person per week- so blockchain news is more of a creative effort, its not something that spams the chain (as it takes energy and effort to create an article). Take a look at the orphan letters- we have only written half of the required letters and thats on the web- because they take effort to write. Regarding 7 minute blocks, I deliberately set up wide block spacing with the chain to save chain size and increase loading speed. I am against 1 min blocks. We will have instandsend after the sanctuaries go live, so we really dont have any downsides after they go live. |
|
|
|
Also, masternode holders are much more likely to be "continuous reinvest" type folk who don't particularly need the immediate recovery of their capital and are more than happy to let their supply accrue over time. These are the type of investors that will make this project thrive.
Ill check more into sliding or increasing masternode share idea, interesting, but one thing I wanted to mention on the above post: The IT budget of 5% (its not 2.5%), is to keep the entire coin growing on the technology side. Its not a budget sent to me as a reward, Im just one person on the team, its a budget that is voted on by sanctuaries for total IT expenses, such as developer payroll. To lower it to 2.5% is a pretty hilarious idea, so no, I think it needs to be the full 5% as thats extremely slim already, and imo its sort of what is creating the whole ecosytem after all this is a technological investment, not a brick and mortar location. Our particular IT dept is going to be busier than the average, with support for interfaces for orphans and a custom PobH pool, for one. Then there is another huge unerestimation with IT: Whenever bitcoin pushes a commit, or if a security patch is released for OpenSSL or any dependency, someone from the team has to spend 40 hours fixing it, testing it and deploying it- if they dont, the coin can die. So it needs to be a healthy department. EDIT: I catch your drift that we should have a PR fund. I think what we can do is take our total 15% and aim for 10% through proposals, and between the superblock cycles we will throw in some campaigns and switch between charity/IT/PR, and make it work. We wont always have a full IT full budget, etc. |
|
|
|
What is the difference between hps and hps2 on the pool?  Hps is your comp hash, hps2 is that what you report on pool. How they are connected? Bible_pay dont want to tell us;) For me hps means nothing(or it's caluclated wrong) cuz you can have 20k of hps and only 3 k hps2. Or have hps 15k and hps2 over 26k. On same rig. Again, HashPerSec is what the client reports to the pool based on actual measured hashespersecond from the client side over time across all threads, and the pool cant pay off of that because it doesnt prove you actually solved 'hard' work (work with low hash requirements). HashPerSec2 is what the pool calculates your rig at, based on actual shares solved in the current round. Yes, we could remove hashespersecond eventually! But the litmus test on that is: Going 90 days straight without any code changes, IE stamping the pool as "stable". Eventually yes, we can do that and simplify things. We could move hashespersec to your user record for debugging also. |
|
|
|
Regarding the Masternode Sanctuary Payout.
I second the opinion that masternode rewards should be a higher portion of the network reward and heres my reasoning:
Miners come and go, they mine the most profitable coin to mine as profit motive and then dump.
With masternodes, the coin becomes both a product and a service as holding the coin not only generates more into circulation while creating scarcity in supply.
An increase to 30-40% reward from the masternode would provide an incredible increase in the longevity of the network's health as you will see that as miners begin to flee after halvenings, masternode holdings will increase and reinforcing the network.
The other thing is with too many miners we don't want to put the network in a position where a great exodus of miners renders the charitable DAO inefficient. You may come to the conclusion that a pure proof of stake system may the best in the long run for this network.
Increasing masternode rewards to be equal or slightly less than miner payouts would be great, because now these miners will want to hold their coins long term instead of selling to market to repay their mining costs.
Exactly, but I like 50% even more. Your post reminded me of this post on Dash masternodes. Here's the relevant quote: Masternodes sustain and care for the Dash ecosystem like parents, while nodes are like teenagers mining for coins. When miners mine for Dash or any other coin like Bitcoin, etc., they often convert these coins into either USD, Euros or other coins. Many miners tend not to have any particular loyalty to any one coin. They’re the worker bees and they can make money by mining lots of different coins. It makes economic sense to do this. However, this is not good for the development of any one particular coin if the miners aren’t loyal and don’t act as shepherds.
In Dash, the masternodes represent the layer that is responsible for caring, cultivating and expanding the Dash digital currency as a whole. It’s also the layer that makes the governance and treasury decisions. The best part of this masternode network is the fact that people can come and go freely, so the success of this network is not too dependent on certain individuals. This makes it a more decentralized structure because a CEO is not choosing people to run the masternodes. People are deciding by themselves to join Dash or leave voluntarily. +++++ |
|
|
|
Regarding the Masternode Sanctuary Payout.
I second the opinion that masternode rewards should be a higher portion of the network reward and heres my reasoning:
Miners come and go, they mine the most profitable coin to mine as profit motive and then dump.
With masternodes, the coin becomes both a product and a service as holding the coin not only generates more into circulation while creating scarcity in supply.
An increase to 30-40% reward from the masternode would provide an incredible increase in the longevity of the network's health as you will see that as miners begin to flee after halvenings, masternode holdings will increase and reinforcing the network.
The other thing is with too many miners we don't want to put the network in a position where a great exodus of miners renders the charitable DAO inefficient. You may come to the conclusion that a pure proof of stake system may the best in the long run for this network.
Increasing masternode rewards to be equal or slightly less than miner payouts would be great, because now these miners will want to hold their coins long term instead of selling to market to repay their mining costs.
++ I like your thinking. On the POS, I dont think we want to go that route as then it would diminish our PoBh algorithm, but, I think that giving half of the block to the sanctuary is actually another 'form' of POS - as those invested in a sanctuary are similar in form to a POS holder. Besides with half going to the miner, we can still attract the excitement of mining also. And make the PoBh better until its stronger. The masternode could potentially in the future help enforce the POBH possibly by handing out some type of mining voucher to CPUs. |
|
|
|
Regarding Sanctuaries at Christmas:
Ive been thinking of the economics for the sanctuary reward, and Id like to make one final change before Christmas to the parameters so there are no surprises:
Id like to give masternodes 50% of the block reward, 10% to our sactuary DAO budget for charity items, and 5% to our DAO IT budget, leaving 35% for the miner who mined the block.
This decision was based on the spirit that we are not a mining organization we are a DAC - Decentralized Autonomous Charitable Org, seeking a place in the Top 5 on coinmarketcap, once we establish our "VAR" for the blockchain. Another words, this coin is not promoting a larger mining rat-race, its trying to place the onus on service. With a lower mining reward and higher sactuary reward, more serious partners will invest in the idea and have a true stake in the outcome of biblepay, and be more committed to running a sanctuary and keeping up with its duties (rather than be in this for profit and to jump ship when the price goes up).
I think that we can then focus on adding more features and services to our masternode codebase, that make a niche for BiblePay. Something along the lines of a built in bitcoin blockchain (in the masternodes only) that offers a payment gateway, or an exchange gateway for example, or a c# gateway (IE port Stratis into biblepay or biblepay to stratis). The payment gateway might handle debits/credits for storefronts or credit cards while the instant exchange allows in-wallet bitcoin-biblepay exchanges, or possibly in wallet trading, etc. We need something that propels biblepay to the top 50 and allows us to rise to the top 5.
I would think splitting between miners and masternodes would be equitable. 42.5% miner, 42.5% masternode, 10% Charity DAO, 5% IT DAO. Regardless of what you decide, making the decision this far in advance should be fair to everyone. It gives miners the chance to realize rewards will be reduced far more than they originally thought, give potential masternoder's time to start preparing for the larger duties and share. One other thought that I did have regards the Orphan Fund. With the Orphan Fund being such a big amount of coins sold at once, it creates tremendous waves in the market. I believe until the Charity DAO is able to fully vote on things, you cap the number of sponsored orphans and then only sell enough to cover their sponsorship and not expand until after the first of the year. Oh but one more very important thing, while we are finalizing the settings, I think we should update our deflationary setting to give it just a little more impact on the market when sactuaries go live. Lets change the deflation level to 1.5% deflation compounded monthly, instead of 10% compounded annually as it is now. That should give the investor a little more incentive to hold dollars in BBP vs native currency, and still show our commitment to be in this for the long term. And then we have to make sure after that mandatory, we are committed to service and carving out our niche. I just thought of a Huge idea today, but it will take a while to create a technical document to share it in order to explain it. |
|
|
|
Regarding Sanctuaries at Christmas:
Ive been thinking of the economics for the sanctuary reward, and Id like to make one final change before Christmas to the parameters so there are no surprises:
Id like to give masternodes 50% of the block reward, 10% to our sactuary DAO budget for charity items, and 5% to our DAO IT budget, leaving 35% for the miner who mined the block.
This decision was based on the spirit that we are not a mining organization we are a DAC - Decentralized Autonomous Charitable Org, seeking a place in the Top 5 on coinmarketcap, once we establish our "VAR" for the blockchain. Another words, this coin is not promoting a larger mining rat-race, its trying to place the onus on service. With a lower mining reward and higher sactuary reward, more serious partners will invest in the idea and have a true stake in the outcome of biblepay, and be more committed to running a sanctuary and keeping up with its duties (rather than be in this for profit and to jump ship when the price goes up).
I think that we can then focus on adding more features and services to our masternode codebase, that make a niche for BiblePay. Something along the lines of a built in bitcoin blockchain (in the masternodes only) that offers a payment gateway, or an exchange gateway for example, or a c# gateway (IE port Stratis into biblepay or biblepay to stratis). The payment gateway might handle debits/credits for storefronts or credit cards while the instant exchange allows in-wallet bitcoin-biblepay exchanges, or possibly in wallet trading, etc. We need something that propels biblepay to the top 50 and allows us to rise to the top 5.
I would think splitting between miners and masternodes would be equitable. 42.5% miner, 42.5% masternode, 10% Charity DAO, 5% IT DAO. Regardless of what you decide, making the decision this far in advance should be fair to everyone. It gives miners the chance to realize rewards will be reduced far more than they originally thought, give potential masternoder's time to start preparing for the larger duties and share. One other thought that I did have regards the Orphan Fund. With the Orphan Fund being such a big amount of coins sold at once, it creates tremendous waves in the market. I believe until the Charity DAO is able to fully vote on things, you cap the number of sponsored orphans and then only sell enough to cover their sponsorship and not expand until after the first of the year. No need to make any changes for such a short time period - we are going live towards the end of year. What we need is more buyers. Btw, we do sell the orphan wallet every week now. Lets focus on the big issues now, ideas that carve out a niche for us. Im going to start inviting members into the slack team tonight. So far, I know we need: - General Cryptocoin c++ Developers - Developer that has zeal for finding security bugs in BBP and BTC. - Developer that wants to take Dash and BTC recent commits, and merge them into BBP. This is a highly technical position requiring BTC or crypto experience. - Web developer to make Biblepay web presence better (The web site, Not the pool, I can handle the pool myself for now) - PR Manager, launching PR campaigs, faucet, etc - Twitter, Facebook / Social Media Manager - Operations & Charity management - Tech Support (Helps resolve users issues with mining, wallet setup, etc) - Technical Writer for documents |
|
|
|
|
Regarding Sanctuaries at Christmas:
Ive been thinking of the economics for the sanctuary reward, and Id like to make one final change before Christmas to the parameters so there are no surprises:
Id like to give masternodes 50% of the block reward, 10% to our sactuary DAO budget for charity items, and 5% to our DAO IT budget, leaving 35% for the miner who mined the block.
This decision was based on the spirit that we are not a mining organization we are a DAC - Decentralized Autonomous Charitable Org, seeking a place in the Top 5 on coinmarketcap, once we establish our "VAR" for the blockchain. Another words, this coin is not promoting a larger mining rat-race, its trying to place the onus on service. With a lower mining reward and higher sactuary reward, more serious partners will invest in the idea and have a true stake in the outcome of biblepay, and be more committed to running a sanctuary and keeping up with its duties (rather than be in this for profit and to jump ship when the price goes up).
I think that we can then focus on adding more features and services to our masternode codebase, that make a niche for BiblePay. Something along the lines of a built in bitcoin blockchain (in the masternodes only) that offers a payment gateway, or an exchange gateway for example, or a c# gateway (IE port Stratis into biblepay or biblepay to stratis). The payment gateway might handle debits/credits for storefronts or credit cards while the instant exchange allows in-wallet bitcoin-biblepay exchanges, or possibly in wallet trading, etc. We need something that propels biblepay to the top 50 and allows us to rise to the top 5.
|
|
|
|
|
Show Posts
