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 - inblue

Pages: [1] 2 3
1
Pre-Proposal Discussion / Re: Trust level of Proof-of-orphan-mining
« on: November 29, 2018, 01:41:35 am »
@way2: I agree. I voted "I would not trust BiblePay" just because there is no other "No" option, for example "I don't like the idea".

It's because Rob wants Yes answers, so he skews the offered answers so that you must feel bad if you select "I would not trust BiblePay", or simply because nobody actually feels that way, so the thinking was that surely nobody would select that option. But I selected it intentionally, because I don't like poll manipulation.

2
Pre-Proposal Discussion / Re: Add Proof-of-Giving
« on: November 23, 2018, 02:28:33 am »
Don't get me wrong, it's a near genius system from a computer science standpoint!  But I don't see a clear positive impact from it in terms of users (it's still pretty complex for a beginner) nor price (it doesn't really add a use case).

But exactly that is what will increase the value of BiblePay in the long term! I also think it's a genius system, not just the giving part or the unique feature of an integrated pool, but the astounding decrease of power consumption by 94%. Imagine if Bitcoin needed 94% less power to be mined... I think it's revolutionary, almost on par with Satoshi's ideas, especially now that Bitcoin uses as much power as a small country. But of course, all of this stands only if the algo is exploit-free. Sunk's post above is a potential exploit, but if the algo is made to be "perfect", then I don't see why to not implement it, even if it doesn't increase users in the short term.

So the tranche (can we call this bracket or bucket?)  you belong to is the min & max of the last 205 blocks portioned in 1/16 increments? So, the tranche you belong to is a moving target?  If the recurring contribution to the orphan foundation address is automated and predictable, I could see donations made at specific block heights to place yourself in a solo tranche.

Hmm, also, what if you tithe to more than one tranche/bracket, to increase your mining potential and to not waste your server's resources? And then the power reduction would also not be 94% if someone mines in 5 tranches.

3
Pre-Proposal Discussion / Re: Add Proof-of-Giving
« on: November 21, 2018, 08:07:57 am »
First of all Miner 1 would be in trache 0 (because he only tithed 1 bbp).  Meaning these two hashpowers would not be competing.  Miner 1 can only "mine" in blocks with an interval of 0, (for example, block 80000) while miner 2 can only mine in block 80015 (interval 15).  Miner 2 would certainly be competing in Tranche 15 because of the high tithe.

Next, lets change this up to this scenario:
Miner 1: hashpower 1 MH/s, tithed 1M BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

In this case both miners would be in tranche 15 competing against one another.  Miner 1 would find the block but would be forced to pay the pool 80% of the winnings (deterministically enforced btw, by the wallet checkblock code).  The only advantage Miner 1 would be getting for all that hashpower is the 20% bonus for finding the block.

Note that in this algorithm, miners who aren't in a tranche sleep during those blocks and wake up automatically when:  Their tranche is called, the block is late, or our difficulty rises more than 100% over the historical reference point.

1. Ah, I got a little confused with tranches, I forgot that the miners in my example would be in different tranches. So if the miners sleep 15/16ths of the time, does that mean the CPU will be roughly at 0 for 94% of the time? That is certainly interesting and as the wiki says - green, but I wonder if there would be any economic or technical complexity because of that. By economic complexity I mean people who rent servers would have to pay for the entire server resource and use it for only 1.5 hours out of 24 hours in a day. By technical complexity I mean that the server providers could potentially automatically flag these spikes as something not normal and limit the server. But on the plus side, that will further improve the resilience and friendliness of the algorithm by making it harder to mine for "hashpower whales" and easier for home users, because the algo would be very friendly to their home CPU and their power bill. Now that I think of it, this seems to be a good feature, although very unique and untested so far, but I hope for the best.

2. In your example where they both tithe the same (or similar) amount and are therefore in the same tranche, if my math is correct, they would receive this many BBP per block:

Miner 1: hashpower 1 MH/s, tithed 1M BBP - 4000 + 2000 = 6000 BBP
Miner 2: hashpower    1 H/s, tithed 1M BBP - 4000 BBP

Hashpower is clearly not valued nearly as much as tithe, which I know was the goal. And yes, in a real scenario, there would be for example 100 users in a tranche, so each user would get 80 BBP when their block comes, and the block founder will get 2080, which is much more compared to others in the tranche (unlike the example above), BUT the chance is much lower, and it's not predictable how much you can earn due to the luck factor, whereas the 0 hash big tithers would have a much better predictability - the competition in a tranche would increase relatively steadily, like in sanctuaries. Also, you would only have 13 chances per day (205/16) to win the lottery of finding a block, so the luck factor is 16 times more unstable than when you have 205 chances per day.

Another thing it crossed my mind is that maybe a solution to the 0 hash big tithers would be something like having a requirement of producing a certain hashpower over the previous 24h to be able to tithe at all, and the higher amounts of tithe would be unlockable with larger hashpower.

3. If tranche levels are determined by arbitrary numbers, then I think the middle tranche levels would be the most empty. I want to explain this by the following example: let's say there is a poll named "How much do you earn per year?" and there are 5 possible answers:
a) 85k or less   b) 85-90k   c) 90-95k   d) 95-100k   e) 100k or more

The results would be something like this:
a) 87%   b) 1%   c) 1%   d) 1%   e) 10%

I put them close intentionally, but the point is that it's impossible to assess all people's salaries and evenly distribute the offered answers, or tranches. You would have to categorically know the statistical wealth of BiblePay users. Therefore I think the middle tranches would always be the most empty, even emptier than the highest one, because simply there are no further levels than 15, so all whales, big and small, would flock in that one tranche. Correspondingly, the first tranche or two will be a test bed for newcomers to try and mine, so those first few levels will always be busy. That means it will be more profitable to tithe less than level 15, to not be in the top tranche, and rather find another nearly empty tranche. So it could happen that the ones who tithe more would be rewarded less and vice versa. That doesn't seem intended. So maybe solve this by having incremental rewards per each tranche? So if we have 128k BBP for all 16 tranches (8k * 16), it could be distributed so that tranche 0 doesn't get 1/16th of 128k, but say 1/100, and tranche 15 gets like 1/5. But that also doesn't look fair somehow.

4. Could it happen that the earned BBP for a 24-hour period is less than tithed BBP? If so, that could put off many users, especially if it's very unpredictable what will happen. Or if the return could be roughly the same as the tithe. How can we ensure this doesn't happen? It looks like it would happen when the number of users increases, while the tranche levels and reward amounts stay the same.

4
Pre-Proposal Discussion / Re: Add Proof-of-Giving
« on: November 20, 2018, 01:59:41 am »
Quote
This system removes the necessity of pools, meaning that no one misses out on solo mining. This simplifies the biblepay infrastructure.

This is excellent, I love the idea of having an automatic pool of sorts, so everyone is solo mining, but at the same time they are pool mining automatically. Very unique, haven't seen something quite like this in other coins. And I hope it means it'll be simple for users to get into.

Quote
We will also make it so the wallet will have an option to automatically tithe in the future with selectable amount and frequency.

I think this is the most important part for the adoption and a must-have on day 1. That's why I think it's best to work on this wallet feature in parallel to the PoG code, so it can be ready at the same time. It would not be amazing if it'd be very complicated to setup PoG manually, and the in-wallet automatic tithing feature were months away.

Quote
The miner who found the block is given 20% of the block reward and the remaining 80% of the reward is split equally to everyone in the tranche, weighted by the tithe amount.

I like the idea of the reward system, but maybe the community can agree on exact numbers or make some other changes? Because if I understood the math correctly, we can have the following example (intentionally extreme):

Miner 1: hashpower 1 MH/s, tithed 1 BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

So basically 100% of the blocks will be found by miner 1. But they will be rewarded like this:

Miner 1: 0.01 BBP + 2000 BBP = 2000.01 BBP
Miner 2: 7999.99 BBP

Effectively "Miner" 2 doesn't spend money or energy for hashpower and gets 80% of all rewards. In a real scenario, there could be hundreds of miners with medium hashpower and medium tithe, and just dozens of whales with low hashpower and high tithe, and they could make something like 50% of the total weight.

5
Voting yes. :) I was just taking another look at the current website, and I have a suggestion to make exchange links go to BBP trading page, instead of the main page. Like this:

https://c-cex.com/ => https://c-cex.com/?p=bbp-btc

https://www.southxchange.com/ => https://www.southxchange.com/Market/Book/BBP/BTC

https://www.qiex.com/exchange => https://www.qiex.com/exchange/bbp_btc

Thanks for your work!

6
Archived Proposals / Re: Crypto Bridge Exchange Listing
« on: May 19, 2018, 03:23:34 am »
Sorry, I misunderstood.

https://coinmarketcap.com/currencies/biblepay/

Down the bottom there is a tab, "Historical Data"

Thank you! I never noticed that tab.

So our average daily volume for the past 30 days is 0.51 BTC, more than I thought. Only 0.32 BTC for the last 15 days though, but still, Crypto-Bridge is so popular, that I can't imagine we'll fall below 0.25 consistently.

I am voting yes for sure, just wanted to be certain.

Good luck! :)

7
Archived Proposals / Re: Crypto Bridge Exchange Listing
« on: May 17, 2018, 01:59:16 pm »
You can see 30 day volume here

http://www.cryptobridgestats.com/

I know that, I was talking about BiblePay volume.

8
Archived Proposals / Re: Crypto Bridge Exchange Listing
« on: May 17, 2018, 02:49:32 am »
The minimum daily volume is on the edge I think, so I'm afraid we could waste 1 BTC. Is there a way to see our average daily volume over the last 30 days? Of course, we hope that having BBP on CryptoBridge will increase the volume, but one can never be too cautious.

Also, is it worth it to try and ask them if they could list a charity coin for 0.5 BTC? That was the original listing fee they were charging a few months ago.

9
Amazing wallet theme, I voted yes. :)

I hope you will stay in the BiblePay community and do more projects in the future.

10
I like the plan, voted yes! :)

11
TestNet Discussion Archive / Re: Android mobile wallet - TEST
« on: April 26, 2018, 03:01:37 pm »
Great job on the app, MIP! I have a suggestion.

Would the app work with a lower minSdkVersion? I'm worried that Android 6.0+ is probably not what most of the unbanked population have on their phone.

Furthermore, according to https://developer.android.com/training/basics/supporting-devices/platforms , Google recommends as a good practice to support about 90% of the active devices, while targeting your app to the latest version (targetSdkVersion).

Here is a nice pie chart of the version distribution: https://developer.android.com/about/dashboards/

So 90%+ would include 4.4, but I know that's a drastic difference in OS, so if the app doesn't work on 4.4, maybe you could at least include 5.0-5.1, since the OS is basically the same as 6.0, so the app should work, and that would increase the app penetration by a whole 23%, which is around 500 million users more. :) And probably a lot of the unbanked would be in that 500 mil.

12
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: April 07, 2018, 03:43:45 pm »
True! I found these ones:
https://www.southxchange.com/api/price/BBP/BTC
https://c-cex.com/t/bbp-btc.json

I'll do an average of buy-sell spread.

CoinMarketCap does this automatically and the advantage is that they display a more accurate average price because they take into account the volume per exchange! So for example if exchange 1 has a 30 sat price at 99% of total volume, and exchange 2 has a 36 sat price at 1% of total volume, they will show 30 as average, not 33.

Here is their API for BBP: https://api.coinmarketcap.com/v1/ticker/biblepay/

Another advantage for you is that you will not have to update your code when new exchanges list BiblePay.

13
I've been talking to Cryptoshot for a while now, been verifying his accounts, and also have had a video-conference with him to make sure that he is who he says he is. And I am so sure that I will vouch for his legitimacy with my own BBP. I think that this proposal is a good PR-opportunity for Biblepay to start growing in Ghana (and Afrika in general).

I think that Afrika and Biblepay are a very nice match. First of all: Christianity is BIG is most of Afrika (Ghana included). Besides that, certain recent technologies have certain proporties that makes them able to propagate fast and wide in these countries. Two of them are mobile (smart)phones and crypto.

While a lot of people are poor, one thing is certain: it's almost essential to have a mobile phone in Afrika these days, especially when you are part of a young cohort (see also the research paper that Cryptoshot has posted in this topic). Besides that, more an more African people are beginning to see the potential of crypto, especially since cryptos are borderless protocols. So what seems like little value in the western world, can have big value in the poorer countries, and give people a chance to change their life-perspective.

All these things combined play nicely with the newest addition to our coin: earning BBP with a smartphone. With the implementation of PoBH, it has become possible to earn BBP with nothing more than a smartphone with Boinc installed and a Biblepay-address.

At the moment, we don't have a mobile wallet yet, but we've been searching for developers, and I've been in contact with Coinomi for a possible implementation of Biblepay in their wallet.

All in all, I think Cryptoshot has found us with great timing, and that this proposal is a chance for us to grow :)

If you see the same value as I do in this proposal, please vote 'yes' with the following command (which you can of course check in the pool).

Code: [Select]
gobject vote-many 045038724b047ba1908bc557777a5c5ae04703230449d1707865b69a162d8bbe funding yes

Thank you for all of your work, it's very valuable. Now after this message of yours I am also confident about this proposal. I will be voting yes. :)

14
Archived Proposals / Re: BiblePay & CameroonONE
« on: February 28, 2018, 08:01:18 am »
Rob has suggested (and I concur) that we start with the sponsorship of two orphans with CameroonOne as a 'trial', so we can find out together if we can make some good things happen :)

Now I see I forgot about this part of your post from more than a month ago, but this goes to show I was thinking the same thing. So what happened with this suggestion (and your concurrence)? :)

15
Archived Proposals / Re: BiblePay & CameroonONE
« on: February 28, 2018, 07:56:38 am »
@Rob: I'm sorry if I'm out of the loop, but are we having the recurring Compassion expense every month or not? If not, then this expense seems acceptable.

Otherwise, 1,000,000 BBP is a hefty amount for a start. Why couldn't we start a little slower for the first month, say sponsor 7 instead of 14 children or better yet sponsor the proposed 14 children, but for half a year? Then see how everything goes and if it's OK, repeat the process in the next budget.

Also, it's been said that $4,000 will cover the 14 children, but 1M BBP is around $2,950 at today's price.

By the way, thanks Jaap for all the work and communication, I think you should be compensated too.

Pages: [1] 2 3