[HP] Monetization discussion

[crypto_zoidberg]

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.

You right, again. Ok.

How about block without transaction value ? I guess it will be 0.

Of course.

As Johnny Mnemonic said dev got incentive to pump fee up.
By the way how fee are fixed ?

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

[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 ?

UPDATE:

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

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 ?

[crypto_zoidberg]

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

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

Just do a premine.

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.

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

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

[crypto_zoidberg]

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