[HP] Monetization discussion

[crypto_zoidberg]

Hello friends.
We'we decided to move monetization discussion of our project to this separate topic.

Befor talk about subject i let to myself a little intruduction.
As i could see here, at this forum, profit of developers is very sensitive point. And to get success with some another new currency it is very important to find good approach to be received by community.
With all this chaos of bitcoin forks creating a new cryptocurrency is not associated with some real work. It's even more associated  with a joke now
CryptoNote is not a final product yet, it's just a bright technology in which we believe, and want to improve, but there a lot of work ahead (UI, services integration, cloud wallet etc).
Now take a look to altcoins: there are no success projects where the founders does not have a stake. Or you just don't know about  stake yet, don't be a naive.
If project starts without earning model - it started to be abandoned.
So, finally, our monetization model will be transparent and clear for all, but to be "fair" doesn't mean to be "moneyless".
In other words: we going to earn with this project.
Now let's back to subject.

Our announcement says that this is a donations-based project, but we met some arguments from community and it puts us on the thought to make it better.
As it pointed by SlyWax miners already have big power in PoW coins, on the other hand using announced approach make theoretically possible for developers to build own pools that have more profit unlike others, it is unfair and leads to centralization.

We've tried to move focus from miners to common users of network, whith actually use it currency.
Each transaction is vote for donation of size equals to a fee of this transaction.
For each block, we calculate the summary value of donations (summing only those transaction's fees in which the donation flag is voted for donation).
Every 720th block we take the median of the average values of prev 720 blocks​​, and use this as a size/2 for donation amount to transfer the developers.

This means that developers will get their earning only if net will be success(will have transaction flow), you know that most abandoned forks had no significant transaction flow.
And it seems to impossible to manipulate with this votes - to make vote for some amount you have to spend this amount - no profit. Even mining own tx with huge fee will not move median until devs don't have about 50%.

Long term monetization for long term project.

Please comment if you agree or not.

[1714179703]

1714179703

[1714179703]

1714179703

[1714179703]

1714179703

[1714179703]

1714179703

[1714179703]

1714179703

[digicoin]

My suggestion:

+ The fee that is paid by transactions (as in Bitcoin) can be broken into 2 parts:

 = Amount that is paid to the miner who solves the block
 = Amount that is paid to certain addresses that devs own

However, to make people happy, the transaction fee that is paid to devs can be limited in time. E.x: for the first 12 months only

What are your thoughts?

[pozmu]

There are 2 options:

1. Just do a premine. Bonus - you can use some of the premine for bounties and giveaways which can help coin to succeed.

2. If you really, really believe in your coin just invest some $$$ in mining early on.

I personally would go with premine, there is no infrastructure for BCN/Cryptonote based coins right now so having some incentive for people to work on it would be good idea...

[cocoakrispies]

A premine is a little different for these coins. Assuming they're keeping the emission curve similar to the other coins using this . . even a 1% premine will be a massive overhang to this.

MRO has been around for about two weeks now, and 1% of the currency is 184k. Of the roughly 300k or so in circulation . . I hope you can see the major difference here.

Generally with bitcoin protocol, your premine is offset with a corresponding instamine, so within a week or two the people using the coin have around as much as the premine.

That's not the case here, because even taking a 5% premine would mean that it would take about a month and a half before people hold as much as that premine.

I still think it's an interesting idea to keep the devs with long term income because it sets the precedent that people can work for the coin and make a legitimate living, but don't really see a great way to make it happen.

The tx donation idea is probably your best possibility, so as to not centralize all the miners into a 0% donation pool.

[crypto_zoidberg]

Premine is not an option.

[SlyWax]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.

Basically they can double their money each time they mine a block.

An alternative, without money creation, could be that the people making a transaction can chose the % of the fee that should go to miner or Dev.

But there is still a problem of centralisation if people can't chose any other developer than the creator of coin.

[emontmon]

I still do not see the need to incentivize the developer. The developer has deep knowledge of the system. early participation guarantees early accumulation of coins. the best example is MRO. TFT has many thousands of coins because of early participation. what that coin has for it is no premine, no instamine, and no tax. This will be very difficult to beat. It can be seen by its adoption and what appears to be successful despite not having an exchange. people see real value in that coin. In a sea of clones and gimmicks, MRO stands out. bytecoin has first mover, but people are galvanizing around MRO because it has the same technology, but most importantly what the community deems fair. No premine, no instamine, and no tax.

it is the adoption of the coin, and success that will bring about the developers early coins the value they deserve.
For the future developmental needs, perhaps current developers may not be the best. May need alternative developers, and miners choosing the direction by choosing the developer is very important. No insult intended here. But this project may go beyond your vision. ability to chose the direction is important. unfortunately (and fortunately) power does belong and should to miners. this is the point of cryptocurrencies.

Looking at any major cooperation: early founders are not always at the helm. If they are, it is for a short time. Often the shareholders or board of directors move a company in what is in the best interest of the company not the founders. (apple is not an example of this)

[iopq]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.

Basically they can double their money each time they mine a block.

An alternative, without money creation, could be that the people making a transaction can chose the % of the fee that should go to miner or Dev.

But there is still a problem of centralisation if people can't chose any other developer than the creator of coin.

No, because they lose the money from the address that the transaction was from and the transaction to address wouldn't get it.

So they own addresses A, B, C

Address B sends to C with a fee going to the dev address A.

Case 1: the fee is normal, so they send 100, pay 1 to the miner (address D of the dev) and 1 to the dev (address C)
address A: -100
address B: 98
address C: 1
address D: 1

total: 0

Case 2: they overpay the fee, so they send 100, pay 1 to the miner, pay 99 to the dev

address A: -100
address B: 0
address C: 99
address D: 1


the key is to really subtract the dev fee from the transaction, not just create it out of thin air

[SlyWax]

the key is to really subtract the dev fee from the transaction, not just create it out of thin air

Yes that is what I was proposing, but I didn't think that's what the OP was about !

[crypto_zoidberg]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.

Basically they can double their money each time they mine a block.

Agree, updated topic.

An alternative, without money creation, could be that the people making a transaction can chose the % of the fee that should go to miner or Dev.

It the same as if they just have an option to send part of their own money to dev. Won't work.

But there is still a problem of centralisation if people can't chose any other developer than the creator of coin.

I feel what you mean, but can't even imagine practical process of project management with such approach.
It is decentralized by nature since you can publish and promote your own sources for this net, and if most of people trust you than they will use your stuff.

[SlyWax]

An alternative, without money creation, could be that the people making a transaction can chose the % of the fee that should go to miner or Dev.

It the same as if they just have an option to send part of their own money to dev. Won't work.

Not if the fee is mandatory for anti-spam purpose.

But there is still a problem of centralisation if people can't chose any other developer than the creator of coin.

I feel what you mean, but can't even imagine practical process of project management with such approach.
It is decentralized by nature since you can publish and promote your own sources for this net, and if most of people trust you than they will use your stuff.

I've already explained a possible process with bounty distribution, if you are willing to implement it, I will elaborate more. (https://bitcointalk.org/index.php?topic=577267.msg6440772#msg6440772)

Basically in crypto I see 3 ways of voting :

- Miner vote (each time a miner mint a block he have a vote)
- Shareholder vote (you have one vote for each coin you own)
- Transaction vote (you vote when you make a transaction (but you have to pay a fee to avoid spam))

By choosing one or making a combination of those vote, you can designate people to have certain function in the coin community. Those function could be of all sort, but you should always try to divide the power amongst lots of people, even to the point that a certain person can just do a tiny thing in a whole process.

This will allow you to do things that a machine can't do (ie : check for the work to be done, evaluate market, decide something...)

There is a 4th solution, but that involve web of trust, and it's very hard to make it work in a greedy world !

[crypto_zoidberg]

the key is to really subtract the dev fee from the transaction, not just create it out of thin air

it is not from the air. Part of emission reserved for devs. We talk about the way of how this reservation goes to devs.

[Johnny Mnemonic]

I suggest an initial 1% per block reward for the first 6 months. As mining becomes more and more competitive, miners will be less able or willing to donate voluntarily, so you can't count on them to support development over the long term. I do believe, however, that 6 months is enough time for a coin to gain traction, at which case it can survive on direct developer donations via the website.

The long term fairness of this approach would be more appealing with some form of perpetual debasement built into the coin's emission curve. I'm sure people are sick and tired of me bringing this up, but it will solve several issues:

1) The developer's early stake in the block reward will not be a permanent percentage of the money supply
2) The market cannot be easily centralized or manipulated from the inside by the super rich, as wealth will constantly be redistributed to the miners.
3) Transaction fees will never have to increase to support mining costs.

A 5% total annual debasement will not necessarily cause inflation.  Inflation only occurs when the circulating money supply significantly increases relative to demand.  A 5% total increase would have a negligible effect on the circulating supply. In comparison, bitcoin is currently debasing at around 11%, and more than 80% of the total supply remains out of circulation.

What I'm proposing would not effect the emission curve until very late in the coin's distribution. When debasement eventually drops to 5%, simply maintain a 5% debasement going forward. This can be calculated as:

If BlockReward / CurrentSupply = 2E-7
All future block rewards will be CurrentSupply*2E-7, calculated after each block, of course.

So block reward will decrease as usual during initial distribution phase, then very, very gradually increase to maintain a 5% annual debasement. This (in theory) would keep the coin's value almost perfectly flat, while simultaneously solving the problems with escalating transaction fees and inner centralization.

[crypto_zoidberg]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.
Basically they can double their money each time they mine a block.

Think we have a solution of the problem that you pointed, please take a look in updated topic.
What do you think?

[SlyWax]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.
Basically they can double their money each time they mine a block.

Think we have a solution of the problem that you pointed, please take a look in updated topic.
What do you think?

I suppose you are talking about (it's better to post the modification you are making) :

We've tried to move focus from miners to common users of network, whith actually use it currency.
Each transaction is vote for donation of size equals to a fee of this transaction.
For each block, we calculate the average value of donations (based on transaction's fee and donations flag).
Every 10th block we take the median of the average values of prev 10 blocks​​, and use this as a size of donation to transfer the developers.

This might work but not in the beginning an not with 10 blocks.
I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more.

How would you account for the transaction without donation flag in your calculation ?

[Johnny Mnemonic]

Creating donation in proportion to transaction fee is a good idea.

However it can still be cheated in it's actual proposed form :

Dev will mine a block and include inside it a transaction to themselves with a huge fee.
As they mined the block they get the fee back, and as they are the Dev, they get the same amount of fee created as donation.
Basically they can double their money each time they mine a block.

Think we have a solution of the problem that you pointed, please take a look in updated topic.
What do you think?

I suppose you are talking about (it's better to post the modification you are making) :

We've tried to move focus from miners to common users of network, whith actually use it currency.
Each transaction is vote for donation of size equals to a fee of this transaction.
For each block, we calculate the average value of donations (based on transaction's fee and donations flag).
Every 10th block we take the median of the average values of prev 10 blocks​​, and use this as a size of donation to transfer the developers.

This might work but not in the beginning an not with 10 blocks.
I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more.

How would you account for the transaction without donation flag in your calculation ?

Bad move. With this solution, the developer has no motivation to curb long-term transaction fee escalation. This would only work if there was a hard cap on tx fees (which can be done with a perpetual debasement, as I suggested above). Otherwise the masses lose.

[crypto_zoidberg]

This might work but not in the beginning an not with 10 blocks.
I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more.

How would you account for the transaction without donation flag in your calculation ?

Why do you thing without?

[SlyWax]

This might work but not in the beginning an not with 10 blocks.
I would suggest waiting 15 days after launch before making donation, and calculating the median on 1440 blocks (1 day) or more.

How would you account for the transaction without donation flag in your calculation ?

Why do you thing without?

Can you give us the formula and an example calculation ?

[crypto_zoidberg]

For each tx donation value is defined as:
donation(tx) = (if (donation_flag_set) fee; else 0);

For each block average donations value is:
avr_donations(block) = sum_of_all_tx_donatons/tx_count


For example:
block1 have following transactions in txs[]:
txs[0]: fee=100, donation flag=0;
txs[1]: fee=200, donation flag=0;
txs[2]: fee=100, donation flag=1;
txs[3]: fee=150, donation flag=0;
txs[4]: fee=100, donation flag=1;
txs[5]: fee=100, donation flag=0;

avr_donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)/6 = 33


Finally, once a day(each 720th block) donation value to transfer to devs calculated as a median(avr_donations(block0), avr_donations(block1)....avr_donations(block719)) * 720

Does it make sense ?

UPDATE:

donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)  = 200

[SlyWax]

For each tx donation value is defined as:
donation(tx) = (if (donation_flag_set) fee; else 0);

For each block average donations value is:
avr_donations(block) = sum_of_all_tx_donatons/tx_count


For example:
block1 have following transactions in txs[]:
txs[0]: fee=100, donation flag=0;
txs[1]: fee=200, donation flag=0;
txs[2]: fee=100, donation flag=1;
txs[3]: fee=150, donation flag=0;
txs[4]: fee=100, donation flag=1;
txs[5]: fee=100, donation flag=0;

avr_donations(block1) = (0 + 0 + 100 + 0 + 100 + 0)/6 = 33


Finally, once a day(each 720th block) donation value to transfer to devs calculated as a median(avr_donations(block0), avr_donations(block1)....avr_donations(block719)) * 720

Does it make sense ?

Yes, it seems fair, however still could be cheated :
Dev send 361 transactions in 361 blocks with donation fee=1,OOO he then gets 720,000 as donation, net benefice = 359,000.
This will work straight if half+1 block don't have transaction (361 block containing only the dev transaction).
This will also work if there is only one foreign transaction in B-1 block, one with 0 tx and all other with one or more transaction. Dev will only send a 2OOO fee tx for each B block ( with B<360 ).
Let's say A="number of blocks with 0 foreign tx", B="numbers of blocks with 1 foreign tx"
and A+B =361 then dev will win 720,000 - B*2000 -A*1000 .

So I guess you should divide by 2 the donation to avoid that.

How about block without transaction value ? I guess it will be 0.
As Johnny Mnemonic said dev got incentive to pump fee up.
By the way how fee are fixed ?