Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - T-Mike

Pages: [1] 2 3 4 5 6 7 8 ... 27
1
Announcements / November Announcement
« on: October 30, 2018, 05:25:33 pm »
Parallel Paths for BiblePay - Future IT and Roadmap

By: Rob Andrews - Founder

We learned a lot in 2018 that was not readily apparent during launch, and as in all businesses, we need to make adjustments in order to be viable. Our core vision is not changing: We still benefit orphans by giving 10% of our monthly emission, we are partially green on our mining side (our cancer miners are doing valuable work), we are CPU based - therefore anyone can mine us, we are Christian at our core - but appeal to everyone as a utility, we are deflationary and appeal to conscious investors who would like to see a more Christian investment, we have an intelligent team capable of taking us to our destination, we spread the gospel through the blockchain, and we innovate new gospel features.

However, with the rapid pace of changes in this space, it is understandable we need to make some changes unless we wish to stagnate.

One major change to our roadmap is our official position on Stratis. Although we still stand behind stratis and their core mission, and wish to remain informed and align ourselves with the potential value in the stratis codebase, many factors influence using stratis-c# as the primary production platform. The considerations being evaluated include: The latest bitcoin security commits, segwit, BLS and BLS secret-sharing, Dash's evolution commits, the lightning network, on chain storage, etc. In general, I want to first give kudos to the main devs of stratis. They are doing something almost impossible in order to get stratis to be compatible with the latest bitcoin version. Where we have to make our decision however, is weighing the benefits of the most cutting edge - to be released features in bitcoin and dash. Biblepay has discovered that it needs certain boilerplate abilities, and, pending IPFS integration, maps to IPFS, Segwit and potentially some of the latest Dash features (for reasons explained later).

Additionally, there are over 100 features that have been added to bitcoin and dash-QT, that the existing features users have become very accustomed to (for example coin control), the HD wallets supporting features, etc. In light of this, I will be recommending that we adjust our roadmap to move stratis to 'R&D (research and development)' for future consideration and integration, but we move the Dash rebase to our more short term priorities. The goal is for us to do the due diligence on rebasing biblepay to have the latest dash features, so that we can leverage some of the latest features to store our IPFS relationship in a more resilient manner (IE our business objects). In summary, this means pushing Stratis out to 2022 and considering it an R&D project, and moving Dash Rebase to June 2019. Also relying on Dash's release as our PR event to be released with any other large BBP feature that is worthy of a giant PR event.

Changes for IPFS:
IPFS allows BiblePay to store files on our own network in a decentralized way. To use IPFS efficiently, we need to become a private IPFS network. This requires two additional features to be added to our core (private swarming and leased-pinning).

NOTE: R&D test cases have proven IPFS can run in its own private network with a BiblePay swarm key, can auto-pin successfully, and IPFS mining can be made provable with range requests.

Reasons for IPFS:
There are many very useful reasons biblepay would want IPFS: Allows us to store business objects (think letters, expenses, revenue, contacts, object-votes, gospel-links, Christian-video-uploads, etc). Realize that storing business objects gives BiblePay a revenue stream. A revenue stream cements BiblePay as a utility - and that is important over the long term so that we always pass the Howey test. Passing the Howey test allows us to be listed on the largest most credible exchanges. It also shields us from legal damage, and allows us to partner with the most credible partners.

Reasons IPFS cannot be at the Sanctuary level:
There are very important reasons to first explain that Sanctuary investments are important for BiblePay's sustainability (investors buy sancs for ROI, and that allows us to fund our orphan operations). However, the harder we make biblepay to setup sancs, the harder it is for an investor to gain access to the investment. Therefore, to continue to be compatible with turnkey masternode services such as GIN and Apollon, we must not force hard requirements on sancs, such as requiring them to host IPFS files. If we do require a sanc to host a public IPFS node (with firewall requirements, public data sharing) we also risk a model that penalizes sanc payments when some 'investor' sancs do not perform. Therefore it is recommended to leave Sanctuaries as they are; not hosting IPFS files.

Reasons IPFS should be at the mining level:
So that we can offer turnkey Sanctuaries, we may offer IPFS mining.

The concept of a content economy:

The content economy is a concept Rob is considering for BiblePay. This is an environment where the user becomes more of a Christian community member. In this model, users are rewarded in BBP for doing important tasks, such as watching a Christian video upload and voting on it. (The users UTXO weight in the vote would drive the net vote weight, as the assumption is those with more weight hold more voting power). Consider that one with low weight could otherwise destroy the credibility of the poll-object.

In this model, Christians find worthy youtube videos that edify other users, and upload the video in the 'Christian Video upload page'. Most of the rewards would be paid by distinct UTXO weight to the voters. This would reward those that spend the time in evaluating items with the actual rewards.

(We will need to discuss giving the ability to cite bad votes from one community member to another, such as : Report Voter - with enough votes against a member we may consider adjusting a voters reputation score).

Outgoing orphan letters may also be voted in the same way (IE in general, any object marked as votable will have a voting list available, and apt for rewards).

Pay-to-preach sermons can be recorded by a community member and uploaded as a Christian video. The video would be voted in an identical way as other Christian video uploads. Rob is working on testing an opensource video upload tool to be integrated in that will automatically convert a youtube video into an IPFS document upload.

One of the goals of the content-economy is to make BiblePay a platform that appeals to Christians so they feel comfortable to come back and actually check it for new content.I envision making BiblePay into a useful platform, one in which Christian's feel compelled to regularly use.One of the use cases I envision is having members pick a very edifying subject, such as Rapture, and uploading Christian videos only on Rapture for the Rapture area. Then, those interested in Rapture log in every day and follow the Rapture area, etc. Other areas such as end-time-visions, can be created etc.

To have PODC or No-PODC:Realize, that IPFS mining will only affect the heat miners. IPFS mining modifies POBH to be IPFS-POBH mining, a greener blend - and PODC still exists in this scenario and plays well with IPFS.

However, one concept we will be discussing in a new dedicated forum thread is the viability of POOM (proof of orphan mining). This is only a concept, and could potentially replace PODC. The core of the concept is re-directing the electric costs used for PODC into personal monthly orphan sponsorships. And creating a sanctuary review process to individually approve each individual orphan receipt (with a governance vote good for 30 days). In this scenario, we trade the PODC electric expenses for monthly orphan sponsorships, which could be very valuable for our community - since it is estimated that we could sponsor over 1000 monthly orphans with the equiv. electric savings. (POOM is also interesting in the sense that it solves our centralized fiat-liquidation vendor payment risk issue(s)).


What are the devs working on:
  • Bhavani: Governance bar chart with totals by expense type for BiblePay-QT. An HTML map with pins displaying Christian camps.
  • MIP: Church tithing in-wallet. Evaluating the entire dash commit history and making diffs with BiblePay.
  • Rob: IPFS range-requests and an IPFS miner. Orphan outbound letter writing page in BiblePay-QT.

Additional updates:
  • MIP now has full github access as our second dev
  • Compassion letters have been mailed to the translators (59 letters this month)
  • The one prayer someone accused us of deleting was an accident (about 20~ days ago)
  • forum.biblepay.org ownership has transferred to Thesnat21, some structure changes have been implemented.



2
I will vote 'yes' for this proposal. But if we're still in the same predicament next month, I don't want to exceed the 10% budget for charity anymore.

I agree that we should be sticking to the percentages stated. Even though charity is our number 1 goal, you cannot take funding away from other areas and expect the coin to grow.

I think we should cut the number of sponsorships down to 100 and ask people to personally sponsor the 209 that did not make it on the list. We can do a manual rewards system temporarily or just record the sponsorships and work out the rewards later.

We need to take greater care in determining the number of children to sponsor. One of the considerations is to account for a 50% drop in price at any point in time, something more sophisticated then a buffer system.

3
Difficult thing is that BBP already supports 300 orphans although size and performance of the projects is way to small for this size of support. Now a miracle (strong philanthropist investor or strong crypto bull market) is needed to keep them supported.

Yes, I think we should try getting some philanthropists involved and that in turn will hopefully allow us to run marketing campaigns.

I suppose if we just allow double dipping it will be ok, doesn't seem like Gridcoin's stats are helping them in any way. The whole stat thing I believe is just for generating a want for higher RAC and making it into a competition so that you would want to rise in rank and beat others. Of course that's not the case for everyone and most of the smaller users probably don't even care about the stats.

4
Everything in the OP post.  The tests are primarily for QT.

On headless you can only test one command: exec ipfsadd documentname.

This version is a proof-of-concept to show that a user can attach a document to a transaction and the receiver (or anyone in this case can open that from IPFS).

Ah yes, sorry. I actually read it then forgot.

5
Installing now. What do you want me to test? I'm using headless by the way.




6
Getting these errors on my linux machine.

************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()       



************************
EXCEPTION: NSt8ios_base7failureB5cxx11E       
String length limit exceeded: iostream error       
biblepay in ProcessMessages()

7
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: April 11, 2018, 07:07:00 am »
You're probably right about the redundancy of accountability.biblepay.org, but if the right backups are in place, I think it should work as intended. It's a central place that is reachable by anyone.
Sure, there is no mention of how backups are done though. Even if there was, we should have regular IT audits.

About the advance payments:
What are the advantages to not paying ahead in your view?
Of course, right now we're paying some of the ahead payments from leftover budgets, but in my opinion that's just a temporary thing.
From an investment standpoint, we should probably have 2 buffers, one in BBP and one is USD, that way we can have some freedom to sell when the price is higher, etc.

In case the charity collapses, we would not be giving them more funds.


I'm actually pro burning any leftover funds (after we pay Compassion ahead for six months). We agreed upon spending a certain portion of the budget on certain things, and if we have leftover, we should burn it. This would give more confidence for investors that the value of their investment will grow in time.
I think from an investor standpoint that if the leftover funds were put into a fund for charity purposes that it would be fine. Plus, we would still be following the 10% rule.

8
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: April 10, 2018, 10:48:13 pm »
jaapgvk,

Well, I think the way this Commission will work still needs some thinking.
I think anything can be discussed and voted on, nothing is really set in stone right now. We really need to start somewhere though.

I really want to keep using accountability.biblepay.org for all accountability (not just for Compassion, but also for BLOOM and CameroonONE). It's there, it works.
Sure, but just be aware that only one person controls it. What if all the data disappears one day? We should also hire an auditor to do regular audits periodically.

I want this commission to be able to do due-diligence on existing and new charities, and I want it to have budget for this.
Yes, I think this will be one of the commission's main tasks.

I want this commission to make it easy for people to donate to the different projects we have. Right now, the 'donate to foundation' checkbox in the wallet is there or course, but for non-experienced users it's probably not clear what this 'foundation' is. I think it would be great if under the 'foundation' tab on the website, there would be donation addresses for charities (maybe even also in different denominations such as BTC or ETH).
That's a great idea, but also a big responsibility that I think should be handled by the commission. And we will prepare ourselves for this, it's not just setting up a few wallet addresses, there are many safeguards that will need to be put in place.

I was thinking about the 'buffer function' of the commission, and I actually have to say that I'm not sure anymore of this function. Right now, Compassion is building up to a six month ahead payment. I'm doing to the same for CameroonONE for a year, and BLOOM is payed three months ahead every time the create a proposal. I'm thinking this may be more the responsibility of the charities themselves. I might be good to have a small buffer still, but I'm not feeling comfortable with the commission having large reserves and the 'power' to decide where these funds will go. I think that the decentralized way in which we're doing things right now is better.
The commission was supposed to keep the funds so that we can make the payments monthly without having to pay in advance. There are many advantages to doing so. The way we are doing it right now is still exceeding the original charity budget, and the last super-block, by a lot more then usual. The commission will not have the power to decide where the funds go, everything will be governed, if necessary, by creating proposals. Like I've said, we can split the reserves among trusted brothers or sisters. And if it makes you feel better about it, I will not handle any of the funds.

9
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: April 09, 2018, 07:29:04 pm »
April gave me the idea for another function for the commission:

Manna has something called 'interactive giving', in which people can give Manna directly to charities. I think we can do a similar thing for charities.

The situation right now is that charities create proposals and receive BBP on a certain address. These addresses can change with every proposal. But what the commission can do, is have some fixed BBP address for every charity that we are partnered with, so that people can send BBP to those addresses if they want, knowing that their BBP will go to the right place.

The responsibility for the commission here, is that they have contact with the charities and the BBP addresses they use, and the commission can then send the BBP to where it's needed.

Here is the link to the Manna infographic, where it is explained:
https://www.mannabase.com/static/documents/infographic.png

That's a great idea, and we will split the addresses to different people. I hope the proposal passes though, its -3 votes so far.

10
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: April 04, 2018, 10:55:46 am »
Looks good! Too bad I don't have an Android phone on me right now.

11
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: April 02, 2018, 09:47:54 am »
True! I found this one:
https://www.southxchange.com/api/price/BBP/BTC

I couldn't find the same in C-CEX. Do you know any?

Yeah it has it also, Iquidus explorer has code built in to interface with C-CEX you might want to look at. You will also need an account for the API key.

https://github.com/iquidus/explorer

12
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: April 02, 2018, 09:35:02 am »
BTW I would like to get some price quote from biblepay.org

Rob, would it be possible to extract BBP price (in BTC)  obtained from a web service url?

Wouldn't you want to do that with the exchange API?

13
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: March 31, 2018, 11:58:07 am »
It should have been submitted through the pool UI, not from the cli commands.  As non-devs have no idea what timestamp to use or what timestamps fall between the trigger time, and it also makes the proposal miss the necessary hashes the pool needs to create the budget.

Please enter all proposals through the pool.

Understood but is there a way to send BBP to the pool? I don't have enough BBP on the pool.

14
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: March 31, 2018, 08:57:49 am »
Rob,

You just made a quote before my post, stipulating that I've placed an address on everyones wallet where we have NO ACCOUNTABILITY for funds sent to it.  You basically said "Rob handles this" but we dont even know what was sent to it.  (Which I explained is not the case - I wrote an RPC report to show every BBP that goes to it).  That insinuates that I created a system to hide money.  But in reality I had a vision for accountability.biblepay.org to be able to reconcile every bbp In, and every bbp Out so it is all tied to an expense that has a receipt.  So it felt like an attack on the system, meaning your system was going to replace my faulty one.   So I pointed out how this new system does not actually solve anything, it creates less accountability.    So I would suggest asking more questions and learning more about whats actually going on before making misleading posts and creating a system that adds complexity and attempts to work around the problem.

I have updated my post to say that there is no redundancy, sorry about that. I still stand by that the commission will be able to do more in an accountable manner. No matter how much reporting you have the fund is still handled by one person. I see a way to improve what we have now and that is all, I appreciate all the work you have done to make everything transparent and the current system will likely be sufficient for the immediate future.

Regarding Greed, you created a Good botnet that pulls in 20% of all Biblepay mining revenue for yourself, and then wrote a post in the vote for StakeRequired-Per-RAC that we shouldnt have any requirement.  Obviously this triggers the personal feeling - of course, then you could control even more of the pie.  I apologized for that, because I realize it was an ASSUMPTION on my part.   Nevertheless it does point to some potential vote bias on your end.

We all have ideas on how the world should work and I don't agree with the current amount of staking that is required. It is evident from the poll that people have their own preference whether good or bad.

Anyway, please dont insinuate that I need to repent when Im defending the Orphans System, the system created for the orphans, only because you have a warped view - and have had your feelings hurt on this flawed idea, that automatically Im an evil person.  Im also here for the children, and the system has to be designed properly, not in a fly by night manner. 

There you go again, "only because you have a warped view". I'm not going to say much more about this if this is how you will respond.

First of all there is a difference between single point of failure for funds that are handled for long periods of time vs funds that are immediately spent. 
The other issue is when you attack the compassion.com system, you are attacking one that is spent immediately.  The superblock funds come in, they are converted and spent, they are not sitting around for months like they would be in a charitable sanctuary. 

The fund will have assets that are held for a long period of time thus more redundancy would be better. If all the charities are handled through the commission by different individuals it would take load off of you. Of course if you want, you can also be on the commission and be the person to handle the Compassion funds as long as everyone agrees to it.

In my view we have been doing quite fine splitting up the load on charities by creating different people to handle each charity- BLOOM handles their own dispursement, Jaap for Cameroon, Me for compassion, etc.  Im all for splitting the load and having more accountability.  Its being doing through the proposal system naturally as it is.

The Commission will formalize all our charity efforts and create an organized system to operate on.

Thats why Im so confused as to what this Charity commission would be, I dont know what "ins and outs are".

Ins and outs (non exhaustive):
Charity fund disbursement.
Accounting and transparency.
Register as non-profit organization.
Management structure.
Charity research.
Charity Drives.
Documentation.

15
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: March 30, 2018, 10:23:55 pm »
Hmmm- what do you mean there is no accountability to that address?    Every BBP received is recorded in SQL as a reconcilable expense, and then reported on the web site, and every BBP goes to compassion.  So this "commission" is set up to make the donations go to your personal wallet instead?  Im not sure how that adds accountability. 

The thing is, we sponsor 205 children at $8000 a month, we always need more donations for compassion.  Im just not understanding how realigning the donate-to-foundation address is going to ease my workload.  The accountability web site in my opinion is a big plus for auditors who want to see the expenses in one place.  You dont have access to write records to it, so I assume I would need to get with you every month and make 2 records and then have a 2nd orphan fundraiser etc, sounds like double the work.

Yes there is a report in the wallet that shows all the amounts tithed to the foundation address also, since we started.

What are your plans on spending this on, what type of charities?  What is the projected amount you are looking to raise per month?

The proposal itself is for only 2500 bbp.  So Im confused what its for - is this just to seek approval for the idea?

Yes, just approval for the idea. The commission is supposed to handle the ins and outs of everything related to charity. I thought we could start small and first create an address for donations. Now sure, there is the foundation address also so maybe we can use that but it's tied to the Compassion fund and it's only handled by one person. There is currently no plan to spend it on another charity and it is not for me to decide anyways. Whatever goes into the fund will first support the current charities and if a large enough of a buffer is created we can consider using it for other charities.

If the fund is approved, there will be 2 people who keep each other accountable. And yes it will take load off of you because you wouldn't have to deal with storing the coins, selling coins, and transferring it to Compassion. Everything that is BBP will be accountable on the blockchain, and everything that is converted to cash will be posted on the website for transparency. All of these things take precious time off from our only dev.

Sure, it makes everything easier when there is only 1 person that handles everything but you also become the single point of failure. In fact, and I've told Togo this, I don't want to be the one that has to handle the wallet with the donation address since it is a big responsibly. How about if you and someone else keep each other accountable instead?

I have to say, you often make me sound like a bad person, saying I was greedy, now saying everything is going into my pocket. I don't know what your deal is but I hope you repent from your unloving ways. I am here for the children, if I wasn't, I would be long gone than have to stand up to your insults.

Pages: [1] 2 3 4 5 6 7 8 ... 27