Add Proof-Of-Orphan-Mining

Let's all discuss the implications of proof-of-orphan-mining if added to BiblePay.

From a high level, this would allow a new user to set up the wallet for mining in a much simpler way, and reward the masses for sponsoring personal orphans.


Please see this information first:

https://wiki.biblepay.org/Concept_POOM

A few questions/Concerns:
1. privacy (I wouldn't want someone else having the password to my account, or personal information it provides)
2. Tax implications,  if you sponsor directly you can deduct.. but if you are being reimbursed for it,  are there tax implications outside of just the crypto-related ones?
3. orphanstats site, who runs/maintains it.. How is privacy ensured etc etc...

A few questions/Concerns:
1. privacy (I wouldn't want someone else having the password to my account, or personal information it provides)
2. Tax implications,  if you sponsor directly you can deduct.. but if you are being reimbursed for it,  are there tax implications outside of just the crypto-related ones?
3. orphanstats site, who runs/maintains it.. How is privacy ensured etc etc...

On #2, I know the fiat payment to compassion is tax deductible for the end user (as compassion is a 501c3), and then the mining revenue from bbp -> the end user is mining revenue.  You would have to consult your local tax laws for how the mining revenue impacts you.

On #1, and #3, I will have to answer this later in detail as Im traveling  now.

Current PoDC mining has a staking side. I agree that make the whole process greener is good and the cost of energy can be put to a better use. But what would happen if all the incentives for staking dissapear?

Another concern I have, in fact I think it also applies today, is to know how safe is PoDC or PoOM in terms of 51% PoW attacks. If most of the energy is saved, then less energy is devoted to protect the network against those attacks. So even if it would require an attacker to have RAC or POOM magnitude, after passing this hurdle, it would be relatively easy to attemp a 51% attack on a "green" low PoW network.

Or maybe I'm having an incorrect view on the mechanisms, in that case I would appreciate your corrections.

Current PoDC mining has a staking side. I agree that make the whole process greener is good and the cost of energy can be put to a better use. But what would happen if all the incentives for staking dissapear?

Another concern I have, in fact I think it also applies today, is to know how safe is PoDC or PoOM in terms of 51% PoW attacks. If most of the energy is saved, then less energy is devoted to protect the network against those attacks. So even if it would require an attacker to have RAC or POOM magnitude, after passing this hurdle, it would be relatively easy to attemp a 51% attack on a "green" low PoW network.

Or maybe I'm having an incorrect view on the mechanisms, in that case I would appreciate your corrections.

In the non PODC environment (IE when we launched with pure CPU POW), we were more subject to 51% attack as all we had to protect us was DGW diff regauging.  At that time we also had 2000 random PCs hashing.

When we moved to PODC, since we knew we would be greener on the POW side (because our model changed to allow controller wallet hashing only), we added a rule to make it hard for a 51% attack:  The last 4 blocks must have distinct signed CPIDs, (that are registered), so it breaks the possibility of one distinct attacker ramping up consecutive hashpower.

In this next model, with POOM+PODC, we would treat the OrphanStats public key the exact same as a Boinc CPID.  You could heat mine with a boinc cpid Or an orphanstats PK.  The lookback rule would still apply, making it hard for a 51% attack (as you would need a distinct POOM cpid per block solved over T-4).  Note that we still have DGW on top of this, so if someone does try something funny, the diff starts skyrocketing after N steps (IE each time one solves a block in half the time the diff increases exponentially).

As far as removing the UTXO stake, I envisioned in this proposal that the POOM miner would not require a UTXO - this is to make onramping very easy for new users.  So yes we would have the effect of those leaving PODC to potentially sell some of their stake, causing short term drop in price  - but since its a free market we cant really predict the effect of this, so I consider it neutral.  I'm looking more at the long term effects of growing the community - hoping for  10,000 active users - I think that is something we should shoot for, as if we have 3,000 of those who stick around for the very long term we would be a vibrant and flourishing long term community, but of course this requires a true valuable service on our part.

On #2, I know the fiat payment to compassion is tax deductible for the end user (as compassion is a 501c3), and then the mining revenue from bbp -> the end user is mining revenue.  You would have to consult your local tax laws for how the mining revenue impacts you.

On #1, and #3, I will have to answer this later in detail as Im traveling  now.

On #1, the necessity for us to log in is driven because the current compassion api does not allow us to access the gid list (the global sponsored orphan id list by sponsorid) without being logged in - however we might be able to change that if we keep lobbying for a future api feature (I started by reaching out to director of security and President, but no progress yet), however in the mean time, this method described in the POOM wiki is our only way to start now.  Regarding the actual question about security, we can only promise the user that we wont attempt to pull Anything other than the GID list and sponsorID.  (That should be all we need forever in this model - just those orphan ID ints, the list, and the sponsorID int).  However additionally, I believe if the user is concerned about privacy, one could set up a PO BOX locally (as compassion accepts those), and use the Organization name "BIBLE PAY" as the account name.  I think we could come up with a Branch Office mechanism, to allow our users who are helping us decentralize be 'volunteer branches of our DAO', in this way, everyone can help us and still maintain their own privacy. 

On #3, this endeavor would start out where I run the initial orphanstats.com (hopefully until the day comes where Compassion exposes a richer API for us and then this site would not be necessary).  As far as trust I could add a 'trust and promise' pledge page, explaining that we promise to only pull the datapoints in #1.  Also that we will not use or sell any data stored in the sql data (and I think its clear that that sql data will be clean).  On a side note, I didnt plan on storing the user private key either - I was going to create a symmetric algorithm (similar to RSA) that the code could use to derive the privatekey at the time of log in (in case the table is ever stolen, they wouldnt gain anything but the public key and the GID lists of public data).

What's the reasoning behind moving ahead with the "extremely easy to setup" POOM before first making PODC/Boinc extremely easy to setup?

What's the reasoning behind moving ahead with the "extremely easy to setup" POOM before first making PODC/Boinc extremely easy to setup?

No moving ahead yet.. this is just a discussion phase.

Though the simplicity factor does weigh in..   Someone on BCT mentioned the vocabulary/acronym/learning curve to get familiar with this coin...   Perhaps this is something we should be looking at first.

The risk is if/as BTC price falls further it will be harder to keep up with our current obligations (even at a diminished capacity)

What's the reasoning behind moving ahead with the "extremely easy to setup" POOM before first making PODC/Boinc extremely easy to setup?

In addition to what thesnat said, the proposal does not actually propose to remove PODC, please understand that POOM competes against the PODC budget.

Next, as far as making PODC easier to use, you can see from the latest releases - that we are trying to do that - with the buttons and the new rpc commands - but its not an easy infrastructure to slim down to one click mining - as there are many moving parts.  Compiling boinc, compiling [email protected], overtaking boincs cpid total credit delta mechanism, handling 20 years of intercommunication RPC call codes, dealing with states of partially installed miners in any state possible, so, explaining this in a non-programming way:  one could investigate due diligence for the hours to simplify it - it could take a lot of labor - maybe it could be done - maybe not - it depends on what resources we allocate to it, etc.

Otoh, I think it truly would be an asset to have the potential to launch a PR campaign against some ability of one-click mining.  We almost had it with our initial launch - simple CPU mining - but unfortunately the botnet in Japan took that infrastructure over.  Now we know a lot more info about mining, and with things like CPIDs or POOM public keys, we can limit a botnets effectiveness by at least requiring miners to have a key (to mine in our current state).

Another way to put it is:  If we want a campaign to grow biblepay - it appears BOINC is currently causing stagnation - maybe its too hard - maybe its the high UTXO requirement - I dont know.  The question is will something like POOM result in 1 new net user per day, or not. 

I wanted to re-clarify something MIP asked the other day:  In a nutshell this proposal does not decrease POW security.  This is because the "lessened electricity expense" we aim to divert to Orphan Sponsorships is at the expense of the PODC budget, not at the expense of the POW heat miners - IE the same controller wallets keep hashing.  (It could be argued that each added POOM miner adds security, but thats speculative so I won't say that for now).

The other thing I thought of this morning regarding account security:  If we do some due diligence we could potentially set this feature up as our Orphan DAC- another words, instead of viewing the home user as being reimbursed, maybe we recommend the home users be 'branch offices' of our DAO.  We tell them to setup dedicated accounts as "BiblePay DAO - Director Slovakia", IE using your BBP contact name and a personal PO Box, then for tax purposes you keep a copy of your billpay expenses to compassion to that account number, and of course the mining income - and optionally create a home based S corp.  In this type of setup Biblepay partially owns each home account (although we wont do anything with it or log in as we promised above) but it makes the set-up much more professional in the sense that the account is a specific branch of biblepay giving us the known right to scan the GID List from our asset list of branch offices. 

The other thing I thought of this morning regarding account security:  If we do some due diligence we could potentially set this feature up as our Orphan DAC- another words, instead of viewing the home user as being reimbursed, maybe we recommend the home users be 'branch offices' of our DAO.  We tell them to setup dedicated accounts as "BiblePay DAO - Director Slovakia", IE using your BBP contact name and a personal PO Box, then for tax purposes you keep a copy of your billpay expenses to compassion to that account number, and of course the mining income - and optionally create a home based S corp.  In this type of setup Biblepay partially owns each home account (although we wont do anything with it or log in as we promised above) but it makes the set-up much more professional in the sense that the account is a specific branch of biblepay giving us the known right to scan the GID List from our asset list of branch offices.

Interesting thought,  I would say though if it gets to the point of creating corp's that would be a whole new level of complexity that makes today's efforts seem simple.. 

Still mulling this idea over,   there are some other thoughts in my mind I just cannot access them clearly yet.. i need some sleep haha

Interesting thought,  I would say though if it gets to the point of creating corp's that would be a whole new level of complexity that makes today's efforts seem simple.. 

Still mulling this idea over,   there are some other thoughts in my mind I just cannot access them clearly yet.. i need some sleep haha

Right, branch offices sound way more complicated than plug n play.  But we can check this for accuracy, but a home user with a contact name of "Biblepay - Username" and a simple po box without a 'corporation' will probably also work fine (since the bill payments to the account number are legal deductible personal expenses).

Is there any way to add in defined Forests, so when it recreate the Texture image it add in some nice Forests that you can see  - is that possible ?

Or is that down to Photoshop after ?

_____
XRumer 16.0 + XEvil 4.0: NEW best software complex for CAPTCHA's automatic solution