Topic: [HP] Monetization discussion (Read 1751 times)

Finally we go with donations, 1% of emission, voting by miners.

IT SEEMS THAT ANY DONATIONS MODEL DOESN'T WORK AT ALL.
It always have a way to cheat.
Probably pozmu was right:


May be we should make some hybrid model(transactions&miners):
Each tx can vote or be neutral.
Miners should vote in coinbase flag, but if miner vote for donation, block can include only tx which voted for donation or neutral. And vice versa, if block voted against donation - it must include only tx voted against or neutral. Pretty weak relation with tx, but it is.

Once a day count blocks that voted for donations and if say 80% is voted than devs gets their fixed percent for this day. Or use this approach without tx voting at all(back to miners power).

Even if this model would be unsuitable may be it is better to go without voting at all - just a pure smoothly emitted premine.

Yes, 2 minutes. I think it's good balance with confirmation speed and blockchain data overhead.

Ok you have removed the averaging in the block, and now are adding the transaction fee.

This mean that my previous attack will be always successful whatever the foreign transaction are.
Let's just say you forgot to add my /2 requirement and think with it included.
I will use fee=1 for easiness.

Now if only 40% block tx voted for a donation, you will just have to add 10% tx to get the donation.
So you will pay 72 to win 720/2=360, net result : 360-72=288.
So basically you just need one vote so that your cheating will be worth it :
you pay 359 you win 360, net result : 1

By the way did you chose a 2 min block time ?

You right, again. Ok.

Of course.

As for network rules - fee can't be zero, this is only restriction set.
But, block reward actually depends of block cumulative size (size of coinbase blob + transactions blob sizes).
If block cumulative  size bigger than median of last 400 blocks than reward calculated as:
reward =  (base_reward * current_block_size * (2 * median_size - current_block_size) ))/median_size
and if block cumulative size bigger than 2*median_size than block is not allowed.

This self-addapting approach used to avoid (or make expensive) tx flood.
Console wallet in all CryptoNote-based projects have default fee defined as DEFAULT_FEE = DEFAULT_DUST_THRESHOLD = 1000000. (skipped in transfer command options just to avoid overhead with syntax).

So dev is not able to force fee up, it designed as self-regulated model.
The only way i can see is to enable big fee by default in wallet software, but i guess at the same time another wallet will be announced as more profitable

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 ?

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

Can you give us the formula and an example calculation ?

Why do you thing without?

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.

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


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 ?

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

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.

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

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


I've already explained a possible process with bounty distribution, if you are willing to implement it, I will elaborate more. (https://bitcointalksearch.org/topic/m.6440772)

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 !

Agree, updated topic.
It the same as if they just have an option to send part of their own money to dev. Won't work.
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.

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

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

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)

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.

Premine is not an option.