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 - Rob Andrews

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 134
91
Ok all, it appears 'relatively safe' to start a round of testing.

Last night I unit tested most of the normal features in Evo and they appear to be working now (and we are syncing), so lets test this on a bigger scale.

The version is now 1.4.5.2.

Please see the OP post for download info.


93
I think I have problems, I am in block 65397 and mining alone. I see these 2 peers
dns1.biblepay.org
dns3.biblepay.org

Both BiblePay Core:1.4.5.1/

I compiled using the latest changes you committed to origin/develop
How would I reach the right chain?

I committed again a couple hours ago, its been a volatile day trying to get this last issue working.

I cant guarantee we are ready for a compile, but please try now - I am synced on 3 nodes and syncing from 0 works now.

Still need to test the actual sanctuary GSC voter though.

For now you have to : Delete evodb, blocks, chainstate, and the gov* and mnc* and mnp* files before resyncing (Important to delete those .dat files as the evodb caches must be clean).


94
I tried to restart with reindex and then I get a fatal error after startup, then it shuts down.

debug.log
Code: [Select]
2019-06-21 12:50:23 Biblepay Core version 1.4.5.1
2019-06-21 12:50:23 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#yellow'
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-06-21 12:50:24 ***************************************** BIBLEPAY  ***************************************************
2019-06-21 12:50:24 ProdMode: Prod 0.000000BiblePayVersion 1.4.5.1 (BiblePay Core)
2019-06-21 12:50:24 Using OpenSSL version OpenSSL 1.0.1k 8 Jan 2015
2019-06-21 12:50:24 Assuming ancestors of block 0000000005ae4db9746d6cad8e0ccebdef1e05afec9c40809f31457fdaf7d843 have valid signatures.
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#yellow'
2019-06-21 12:50:24 GUI: QCssParser::parseHexColor: Unknown color name '#grey'
2019-06-21 12:50:24 Default data directory /Users/mippl/Library/Application Support/BiblepayEvolution
2019-06-21 12:50:24 Using data directory /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3
2019-06-21 12:50:24 Using config file /Users/mippl/Library/Application Support/BiblepayEvolution/biblepay.conf
2019-06-21 12:50:24 Using at most 125 automatic connections (2560 file descriptors available)
2019-06-21 12:50:24 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2019-06-21 12:50:24 Using 2 threads for script verification
2019-06-21 12:50:24 scheduler thread start
2019-06-21 12:50:24 Creating backup of /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/wallet.dat -> /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/backups/wallet.dat.2019-06-21-12-50
2019-06-21 12:50:24 init message: Verifying wallet...
2019-06-21 12:50:24 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-06-21 12:50:24 Using wallet wallet.dat
2019-06-21 12:50:24 CDBEnv::Open: LogDir=/Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/database ErrorFile=/Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/db.log
2019-06-21 12:50:24 Bound to [::]:40001
2019-06-21 12:50:24 Bound to 0.0.0.0:40001
2019-06-21 12:50:24 init message: Loading KJV Bible...
2019-06-21 12:50:24 fLiteMode 0
2019-06-21 12:50:24 init message: Loading sporks cache...
2019-06-21 12:50:24 Reading info from sporks.dat...
2019-06-21 12:50:24 Loaded info from sporks.dat  1ms
2019-06-21 12:50:24      Sporks: 6
2019-06-21 12:50:24 Read: Cleaning....
2019-06-21 12:50:24      Sporks: 6
2019-06-21 12:50:24 Cache configuration:
2019-06-21 12:50:24 * Using 37.5MiB for block index database
2019-06-21 12:50:24 * Using 8.0MiB for chain state database
2019-06-21 12:50:24 * Using 254.5MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2019-06-21 12:50:24 init message: Loading block index...
2019-06-21 12:50:24 Opening LevelDB in /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/evodb
2019-06-21 12:50:24 Opened LevelDB successfully
2019-06-21 12:50:24 Using obfuscation key for /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/evodb: 0000000000000000
2019-06-21 12:50:24 Opening LevelDB in /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/blocks/index
2019-06-21 12:50:25 Opened LevelDB successfully
2019-06-21 12:50:25 Using obfuscation key for /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/blocks/index: 0000000000000000
2019-06-21 12:50:25 Opening LevelDB in /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/chainstate
2019-06-21 12:50:25 Opened LevelDB successfully
2019-06-21 12:50:25 Using obfuscation key for /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/chainstate: aeb0dfd04bd0e95c
2019-06-21 12:50:25 Opening LevelDB in /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/llmq
2019-06-21 12:50:25 Opened LevelDB successfully
2019-06-21 12:50:25 Using obfuscation key for /Users/mippl/Library/Application Support/BiblepayEvolution/testnet3/llmq: 0000000000000000
2019-06-21 12:50:25  Last Checkpoint Height 60000 LoadBlockIndexDB: last block file = 0
2019-06-21 12:50:26 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=56456, size=95047122, heights=0...56450, time=2017-06-01...2019-06-21)
2019-06-21 12:50:26 Checking all blk files are present...
2019-06-21 12:50:26 LoadBlockIndexDB: transaction index enabled
2019-06-21 12:50:26 LoadBlockIndexDB: address index disabled
2019-06-21 12:50:26 LoadBlockIndexDB: timestamp index disabled
2019-06-21 12:50:26 LoadBlockIndexDB: spent index disabled
2019-06-21 12:50:26 LoadBlockIndexDB: hashBestChain=3cce38b13a313242f075275416e6ec300a6692dc7e25a64bff6d8e51c25e6a7b height=97 date=2019-03-30 16:47:51 progress=0.001010
2019-06-21 12:50:26 init message: Verifying blocks...
2019-06-21 12:50:26 Verifying last 6 blocks at level 3
2019-06-21 12:50:26 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2019-06-21 12:50:26 No coin database inconsistencies in last 7 blocks (7 transactions)
2019-06-21 12:50:26  block index            1214ms
2019-06-21 12:50:26 init message: Loading wallet...
2019-06-21 12:50:26 nKeysLeftSinceAutoBackup: 999
2019-06-21 12:50:26 nFileVersion = 1040501
2019-06-21 12:50:26 Keys: 1003 plaintext, 0 encrypted, 1003 w/ metadata, 1003 total
2019-06-21 12:50:26  wallet                   68ms
2019-06-21 12:50:26 setExternalKeyPool.size() = 999
2019-06-21 12:50:26 setInternalKeyPool.size() = 0
2019-06-21 12:50:26 mapWallet.size() = 20
2019-06-21 12:50:26 mapAddressBook.size() = 1
2019-06-21 12:50:26 PrivateSend liquidityprovider: 0
2019-06-21 12:50:26 PrivateSend rounds: 2
2019-06-21 12:50:26 PrivateSend amount: 25000
2019-06-21 12:50:26 PrivateSend denoms: 3000
2019-06-21 12:50:26 sigshares thread start
2019-06-21 12:50:26 mapBlockIndex.size() = 56456
2019-06-21 12:50:26 chainActive.Height() = 97
2019-06-21 12:50:26 instantsend thread start
2019-06-21 12:50:26 Reindexing block file blk00000.dat...
2019-06-21 12:50:26 init message: Memorizing Prayers...
2019-06-21 12:50:26 torcontrol thread start
2019-06-21 12:50:26
Deserializing prayers from file 1561121426 Processed 67 prayer rows - 1561121426
2019-06-21 12:50:26  Chain Height 97, Loading entire prayer index
2019-06-21 12:50:26 Memorizing prayers tip height 97 @ time 1561121426 deserialized height 0 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: unspecified iostream_category error at CBlockDiskPos(nFile=0, nPos=20577)
2019-06-21 12:50:26 *** Failed to read block
2019-06-21 12:50:26 ...Finished MemorizeBlockChainPrayers @ 1561121426 init message: Discovering Peers...
2019-06-21 12:50:26 init message: Loading P2P addresses...
2019-06-21 12:50:26 Loaded 47 addresses from peers.dat  1ms
2019-06-21 12:50:26 init message: Loading banlist...
2019-06-21 12:50:26 init message: Starting network threads...
2019-06-21 12:50:26 net thread start
2019-06-21 12:50:26 dnsseed thread start
2019-06-21 12:50:26 opencon thread start
2019-06-21 12:50:26 addcon thread start
2019-06-21 12:50:26 mncon thread start
2019-06-21 12:50:26 msghand thread start
2019-06-21 12:50:26 init message: Starting Miner...
2019-06-21 12:50:26 BibleMiner -- started thread 0.000000
2019-06-21 12:50:26  MinerSleep 325.000000
2019-06-21 12:50:26  ** Started 1.000000 BibleMiner threads. **
2019-06-21 12:50:26 init message: Done loading
2019-06-21 12:50:26 keypool added key 1004, size=1000, internal=0
2019-06-21 12:50:26 init message: Loading wallet... (100.30 %)
2019-06-21 12:50:26 keypool reserve 5
2019-06-21 12:50:28 Reindexing finished
2019-06-21 12:50:28
CreateNewBlock::Unable to add ABN because Sorry, your coin-age is too low to create an anti-botnet transaction.{PNB}: ACC  Imported mempool transactions from disk: 0 successes, 0 failed, 0 expired
2019-06-21 12:50:28 tor: Thread interrupt
2019-06-21 12:50:28 torcontrol thread exit
2019-06-21 12:50:28 sigshares thread exit
2019-06-21 12:50:28 dnsseed thread exit
2019-06-21 12:50:28 mncon thread exit
2019-06-21 12:50:28 addcon thread exit
2019-06-21 12:50:28 opencon thread exit
2019-06-21 12:50:28 instantsend thread exit
2019-06-21 12:50:28 scheduler thread interrupt
2019-06-21 12:50:28 PrepareShutdown: In progress...
2019-06-21 12:50:28 keypool return 5
2019-06-21 12:50:28 net thread exit
2019-06-21 12:50:28 msghand thread exit
2019-06-21 12:50:28 Verifying mncache.dat format...
2019-06-21 12:50:28 Loaded info from mncache.dat  1ms
2019-06-21 12:50:28      Masternodes: meta infos object count: 0, deterministic masternode count: 0, nDsqCount: 0
2019-06-21 12:50:28 Writing info to mncache.dat...
2019-06-21 12:50:28 Written info to mncache.dat  1ms
2019-06-21 12:50:28      Masternodes: meta infos object count: 0, deterministic masternode count: 0, nDsqCount: 0
2019-06-21 12:50:28 mncache.dat dump finished  2ms
2019-06-21 12:50:28 Verifying governance.dat format...
2019-06-21 12:50:28 Loaded info from governance.dat  1ms
2019-06-21 12:50:28      Governance Objects: 0 (Proposals: 0, Triggers: 0, Other: 0; Erased: 0), Votes: 0
2019-06-21 12:50:28 Writing info to governance.dat...
2019-06-21 12:50:28 Written info to governance.dat  0ms
2019-06-21 12:50:28      Governance Objects: 0 (Proposals: 0, Triggers: 0, Other: 0; Erased: 0), Votes: 0
2019-06-21 12:50:28 governance.dat dump finished  2ms
2019-06-21 12:50:28 Verifying netfulfilled.dat format...
2019-06-21 12:50:28 Loaded info from netfulfilled.dat  0ms
2019-06-21 12:50:28      Nodes with fulfilled requests: 2
2019-06-21 12:50:28 Writing info to netfulfilled.dat...
2019-06-21 12:50:28 Written info to netfulfilled.dat  1ms
2019-06-21 12:50:28      Nodes with fulfilled requests: 0
2019-06-21 12:50:28 netfulfilled.dat dump finished  1ms
2019-06-21 12:50:28 Verifying instantsend.dat format...
2019-06-21 12:50:28 Loaded info from instantsend.dat  0ms
2019-06-21 12:50:28      Lock Candidates: 0, Votes 0
2019-06-21 12:50:28 Writing info to instantsend.dat...
2019-06-21 12:50:28 Written info to instantsend.dat  0ms
2019-06-21 12:50:28      Lock Candidates: 0, Votes 0
2019-06-21 12:50:28 instantsend.dat dump finished  1ms
2019-06-21 12:50:28 Verifying sporks.dat format...
2019-06-21 12:50:28 Loaded info from sporks.dat  0ms
2019-06-21 12:50:28      Sporks: 6
2019-06-21 12:50:28 Writing info to sporks.dat...
2019-06-21 12:50:28 Written info to sporks.dat  0ms
2019-06-21 12:50:28      Sporks: 6
2019-06-21 12:50:28 sporks.dat dump finished  0ms
2019-06-21 12:50:28 Shutdown: done



-reindex does not work on any version of Evo properly.  Lets see if we can debug that root cause. 

(I have been deleting the chain files in contrast to reindexing).


95
Good, I will create a new sanc from scratch then. I will ask for tBBP coins when itís ready.

Let me know if you can sync to 108174 on the latest and Ill send you tbbp, what address?

96
Well the fact is that I dismantled the VPS so I will try starting all over again.
Yeah, that would do it!

97
Good, I will create a new sanc from scratch then. I will ask for tBBP coins when itís ready.

I believe you can just upgrade the sancs software, because remember during the last phase of testnet, we all ran the 'upgradesanc' command, so your sanc is probably already a deterministic sanc (if it was in the determistic dip3 list).


98
Just a question: are we testing first the activation of DIP0003 testnet sancs with current version (1.4.3.5) , then upgrade them to 1.4.5.1 ?
Or are we directly starting from brand new testnet sancs using 1.4.5.1 ?

Although our sancs are dip3 deterministic already in testnet as of our last leg of testing, we definitely need to upgrade our sancs to 1.4.5.1 and our home controller to 1.4.5.1 first; this way we will have coverage of all the code.  (As even our old code is being a hit a completely different way in 1.4.5.1 :).

Thanks....

HEY ALL:  Please don't upgrade yet - I have some news coming in from Cameroon One, and I believe we will need to release a GSC feature today into testnet, so lets hold off and get 1.4.5.2 out so we can test all this at the same time.




99
Hello all, welcome baaack!

We are ready to test 1.4.5.1-develop.  This release primarily adds all of the things Dash added in the 0.14.0 branch recently (IE March 2019 through June 2019), things including ChainLocks and LLMQs.

We need to regression test everything we tested in BiblePay-Evo, such as GSCs and ABNs, since a lot has changed under the hood.

Lets also test watchman on the wall.

The Windows download link has changed; please see the OP post.

MIP, can you build us a Mac and please tell me if I need a new updated link?

Github source:
https://github.com/biblepay/biblepay-evolution
branch: develop

PS  -  Please verify you are testing v1.4.5.1+


100
Things to test in 1.4.3.5+ (0.14.0 branch features):

- Ability to Mine
- ABN
- ChainLocks
- Sanctuary Payments
- GSC quorums
- LLMQs
- Instant Send




101
Pre-Proposal Discussion / Re: POOM Concept (Proof-of-Orphan-Mining)
« on: June 17, 2019, 12:58:52 pm »

I'll vote for 70% so there is capacity for growth, but will only pay out the fiat equivalent (according to QT), so I don't see any 70%. Whereas if you have 30% or 50%, you may need to recode (or is it a spork?) in the future.

Its a spork, so we could change it if we had a future vote to change it - without coding.

I was kind of leaning toward 30% since this is such a new technology, maybe with a future vote to change it if its stellar.

But Ill probably get behind whatever the general consensus is in the sanc polls.


102
Pre-Proposal Discussion / Re: POOM Concept (Proof-of-Orphan-Mining)
« on: June 15, 2019, 08:41:07 am »
And here is a very encouraging piece of math:
Even at our current low price, if POOM has a 450K budget, we could sponsor 135 new orphans per day (450K * .0004 / 1.33 = 135).

That's really encouraging, to think that 135 new miners (or for example less miners with more children each) could make this much of a positive impact - and that would bring our global impact back up to 215 orphans in that bleak scenario alone.

But I think the picture would be much rosier if our price rose (due to the pass-through expenses/reimbursements).  The reason a person would want to donate through BiblePay is they also gain cryptocurrency exposure.




103
Pre-Proposal Discussion / Re: POOM Concept (Proof-of-Orphan-Mining)
« on: June 15, 2019, 08:16:35 am »
First of all, PoOM is a great concept and glad to see some concerns with v1 and v2 being addressed. v3 sounds really promising especially with Kairos being onboard. I'm inspired to start sponsoring one child,

Charitable Giving & Crypto Income?
If we contribute to Kairos, they give contribution summary at the end of the year (maybe as an encrypted PoDS?) When we "mine" BBP, we know the fiat price, so we generate "income" on the day the BBP is put in our wallets? One is charitable contribution, and the other is crypto income?
Pay out exact BBP or less?
Giving BBP to sponsors in exact amount (instead of fixed pot) will allow other projects to be sponsored. Having a fixed pot may encourage sponsorship early on, but s/he could drop the "orphan" as soon as PoOM was unprofitable. Remove the greed motivation by paying only exact or less (as sponsorship numbers grow).
Other charity integration?
Is there a plan to help other charities like BLOOM to join PoOM as well? Perhaps something simple as a Google Sheets or Airtable to use a database? This way other charities can be involved in PoOM without a backend developer to make the integration? Will the details of what's needed for integration be published at a later time?

Thank you for your compliments, and hopefully from a community perspective we can agree together that this could be a positive enhancement for biblepay, and thank you for the additional questions.

First, this is an endeavor with Cameroon One (not Kairos).  I was happy to hear when I spoke to Todd from Cameroon that he had a flexible vision of parternship with us and was more than flexible in the IT department so this sparked the conversation of integration POOM with their organization since Compassion was reluctant to hear about the idea.

As far as Tax deductions from a Cryptocurrency perspective, I cant speak to that exact answer because Im not a tax attorney for one but more importantly these tax laws are governed by each users local area/taxable situation and entity type, so I wont go into that, but what I will say is what the relationship looks like and most people will easily understand how to file it.  It looks like this:  A home biblepay user (a home miner), with a home CPK, decides to sponsor an orphan from Cameroon one at Home (but through the biblepay wallet command - to provision the new orphan).    We then ask this home miner to make payments for this orphan directly to Cameroon One - These payments are made in local currency (IE USD for example)  and go directly to Cameroon and those are tax deductible payments using your own personal SSN or company Tax ID number.  The payments you receive back from BiblePay are treated as mining income since they originate from our GSC smart contract reward.  To the end user, they get to sponsor a child, and get rewarded possibly all of the expense back in the form of BBP, exciting.  This is also exciting from a Bitcoin perspective, as I read there is a tax law that if you have unsettlled bitcoin mining income you may be allowed to use that bitcoin for a charitable expense (such as a donation to cameroon) but Im not sure if Cameroon accepts BTC, but I believe they will (I will double check) - but again this is yet another extended use case that has potential. 

Regarding the mechanics of capping the reward (IE pay the BBP amount or less):
I like that idea, and Id like to take the time to clarify something so the sanctuaries who vote on this proposal know exactly what this proposal is proposing.  To make this very simple for everyone to understand, Im going to remove the verbiage above about "homogenized POG reward", and lets make the assumption that we will be :
- Creating a new Campaign called POOM
- If the vote is for 50% of the GSC budget, then this campaign would pay out 0-450K per day in POOM rewards
- Each participant will be capped to only receive Up to the maximum exact amount in BBP that the orphan expense was for (IE if its $1.33 per day, the max reward per orphan-cpk per day is $1.33 in BBP) - Note 2: Our rewards are only paid to people who have credit balances with Cameroon (thanks to our integration) , so someone with a new orphan that didnt actually pay for the orphan will get zero in the days GSC row for their CPK :)
- If we have so many sponsorships that we exceed the entire budget, then they start getting split by user equally (IE if we had 250 orphans, and this resulted in a .65 cent payment per day per person, then this campaign would still be capped at 450K per day and each participant would receive .65 cents each)

So when voting, please vote the above scenario (not the homogenized scenario as that will be deleted).

One piece of info I received yesterday, which is really awesome, is Cameroon One accepts global payments through Paypal (they take credit cards or checks), and Paypal does the auto-conversion of country currency to currency.  So this first phase rollout will be available in the UK, Europe, etc.  We believe it will not work in China due to the firewall rules. 

The user will be instructed to paste the Biblepay Hex orphan ID into the Paypal transaction.  Whats nice is anonymity is preserved as BiblePay will never know who paid for the child, but Cameroon will keep the Paypal records private, etc.

Regarding other company integration:
Yes, it is definitely possible to integrate all the companies in, as long as they meet security requirements.
First, right off the bat - we can't have a google sheets public transaction register - as that would not meet the security requirements.
We must have a full integration with the company itself, so the API is hosted on their computers, and can only be accessed by them, and the RESTful queries are served from their top level domain.  This is to prevent collusion with any representative from biblepay (or from any other domain).
We overcome oracle/collusion/provability risk by asking the company to provide something similar to compassion - a way for a third party to provably check the history of the child, and at the minimum to know at a point in time the child is sponsored by "BIBLEPAY".
So, basically the requirements would be:
- They own a professional top level domain (like Bloomcharity.org for example).
- Their IT dept follows the spec in the OP post to implement the api
- They expose the API on their top level domain (IE bloomcharity.org/biblepay/api)
- They provide a method to prove an orphan ID is sponsored by biblepay when asked by third party
- They honor the rule that we create the Hex orphan ID code when the orphan is provisioned (initiated by our wallet command)
- They create a BIO for the orphan using their URL from their top level domain, using our naming convention (which has our hex child id in it)

Kairos and Bloom are possibilities, as long as Kairos can use their mother companies domain (or buy the kairos.org domain etc), and Bloom could be possible but they currently cost twice the amount per month per orphan that cameroon does (cameroon is $40, I believe bloom is $80 per child) so we would need to build in our interface the ability to store the default commitment amount (Ill take care of that in case we get more than one api started).




104
Archived Proposals / Kairos Childrens Fund PR Event
« on: June 13, 2019, 11:31:48 am »
Pastor Andrew from Kairos Childrens fund is asking if we would like to have a banner at his 3 day national conference in the Philipines:

These are the packages that we are offering. Check out our website at vismin.winnegor.org
$100 : We will have 2 banners outside the hotel during the 3 day event. One more banner inside.
          The logo and tagline will be at the bottom, small, but readable from the back of the room or across the road

$50 : We will distribute small brochure about your company or product along with the packet that we give them at the beginning of the event.

$50 : We will also post a logo under 'sponsored by' on the website, with a link to the Biblepay website.

$50 : We will have your company or product mentioned at the beginning of the 1st session every day. (as a great cryptocurrency for christians.)
         + $25 : Your business / product will be announced as a major sponsor of the event

* If time permits, I will discuss biblepay with interesting people and pastors.

* We are thinking of
 - http://www.facebook.com/wimdgte
 - http://www.winnegor.org


=-=-=-=-=-=-=-=-=-=-=-=-=-


The event is being held Oct 22 through Oct 25th.

Pastor Andrew will design the pamphlet and the banner for us.


Total charge $250.00 or 625,000 bbp.



105
Pre-Proposal Discussion / Re: POOM Concept (Proof-of-Orphan-Mining)
« on: June 13, 2019, 09:27:11 am »
So could you now elaborate on this? How will the budget work in each case?
Sure, and it will probably be good to elaborate more on and end-to-end example of the whole process.

So we have two choices with GSC.  GSC is robust enough to handle a dedicated campaign for POOM, a completely separate campaign from POG and HEALING, maybe called POOM for example.

The benefit of doing it this way is its cleaner and makes more sense to outsiders.  If we, for example set up this new campaign to be 50% of the GSC rewards, this would immediately decrease the budget of POG by 50% (and impact healing as well).  But the question is, even if with the stringent safeguards of rewarding the POOM members with rewards for 'paid orphans', in the initial early stages, lets say we only have 2 users sponsoring 2 orphans.  The payment allocation of 450K would be split among 2 users (225K each) and this would obviously not last very long as people would jump in and sponsor some new orphans and this excess would dissipate quickly as people come on board.  The upside would be this confined environment and math would be very easy to calculate, as it would be a free running financial system in that the total budget (450K would simply be split by the number of orphans) - and yes it is possible for one CPK to host multiple orphans.  So over time, if we had 20 in there, each person would receive 22.5K.  If our price went up we could have 200 or 2000 in there.

The other option is to award POG points for POOM, thereby making POG a homogenized campaign (POG would be staking + giving + orphans). 
I'm starting to talk myself out of this already.  I think maybe we should ignore the initial effects and make POOM have a dedicated campaign and budget.

I'm neutral on this right now.  I think we need a few additional sanc polls in the end, with half voting for dedicated POOM campaign, the other half for POG hybrid (IE the ones I just entered last night).


Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 134