ppcoin transaction fees

[Sunny King]

• Cost of transaction processing may be too low to be any incentive for rational minters to exclude transactions (network consists of altruistic, rational, malicious participants).

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

The tragedy of the commons only refers to the unreliability of altruistic component of the network. What I am saying is that even rational nodes would not try to sabotage the protocol because the gain is too little. Not many people are going to modify code, rebuild or download risky builds just to save a few pennies.

If you don't believe me, then please explain to me why after 4 years bitcoin network still processes fee-free transactions happily? All my fee-free bitcoin transactions are processed without a hiccup.

[1714043663]

1714043663

[1714043663]

1714043663

[1714043663]

1714043663

[1714043663]

1714043663

[Etlase2]

The tragedy of the commons only refers to the unreliability of altruistic component of the network.

Uh the word rational is in the first sentence.

What I am saying is that even rational nodes would not try to sabotage the protocol because the gain is too little. Not many people are going to modify code, rebuild or download risky builds just to save a few pennies.

It's not sabotage when it is a perfectly legitimate use of the protocol. Wishful thinking. As I've said, you can't predict the future and you don't know how big or how little the gain may be. It's very unlikely that all nodes will do this, but even when some do it causes delayed transactions and puts added pressure on altruistic nodes.

If you don't believe me, then please explain to me why after 4 years bitcoin network still processes fee-free transactions happily? All my fee-free bitcoin transactions are processed without a hiccup.

Do I really need to explain this to you? Because this question is just begging to get a witty retort that may or may not involve senior software developers and how much they make and if money has a direct correlation with the Dunning-Kruger effect.

[Sunny King]

The tragedy of the commons only refers to the unreliability of altruistic component of the network.

Uh the word rational is in the first sentence.

What I am saying is that even rational nodes would not try to sabotage the protocol because the gain is too little. Not many people are going to modify code, rebuild or download risky builds just to save a few pennies.

It's not sabotage when it is a perfectly legitimate use of the protocol. Wishful thinking. As I've said, you can't predict the future and you don't know how big or how little the gain may be. It's very unlikely that all nodes will do this, but even when some do it causes delayed transactions and puts added pressure on altruistic nodes.

If you don't believe me, then please explain to me why after 4 years bitcoin network still processes fee-free transactions happily? All my fee-free bitcoin transactions are processed without a hiccup.

Do I really need to explain this to you? Because this question is just begging to get a witty retort that may or may not involve senior software developers and how much they make and if money has a direct correlation with the Dunning-Kruger effect.

lol how cute and witty. I don't know who is doing the wishful thinking or having dunning-kruger effect problem. Fine if you are so superior my suggestion is that why don't you go take care of your own matters and release working prototype and stop wasting both your time and my time?

Thank you very much

[Etlase2]

I am not trying to waste your time, I am imploring you take these types of things seriously rather than dismissing them and waiting until something becomes a problem. Having the primary developer being only worried about the here and now with no regard to the future reeks of a pump and dump, and oh yeah, loses my respect*. I agree with you to some extent that the bitcoin devs are too strict on the hardfork because NOW is the time to do such things, not when there are embedded applications that will have to be replaced.

* - I'm sure you don't care, but you are pretty easy to bait

[cunicula]

This has the same problem of directly giving transaction fees to minters. Minters would have strong incentive to not acknowledge other minters blocks and force reorganization, just to grab all transaction fee/reward for himself.

Can you overcome this by making txn fee revenue (100/n)% of txn fees in the minters block and (100/n)% of txn fees in the previous (n-1) blocks? I think If you do this, there would now be an incentive to include txns, but stealing txns from prior blocks would no longer be advantageous.

Yes spreading transaction fee to n-blocks would definitely lessen the negative incentive quite a bit. That would be one possible solution if this proves to be a problem in the future.

Here is a thought experiment.

1) Each block has a time stamp T. All txns also have time stamps t. Blocks cannot contain txns from the future, e.g. all txns up to block T satisfy t<T
2) For the purpose of calculating fees, each block contains all txns over the past 2 hours.
3) Minters get a constant share of each txn fee, i.e. each minter gets to keep 1/12 of all the txn fees from txns for which T-t< 2 hours. (of course there is a random element to aggregate fee distribution now, but that is not a problem)

Under this design, only the txn time stamp and the block time stamp matter for fee revenue. You cannot affect your txn fee revenue through reorganization in any way. There is still a strong incentive to include newly broadcast txns. Including these txns allows you to capture a share of their fee revenue, which would otherwise go to future minters.  

Comments?

[Edit: Another thing about this is that it weakly incentivizes txn broadcasting. Keeping knowledge of a txn private cannot benefit you at all because you cannot affect the time stamp of the txn. Assuming that blocks are all full of txns or sometimes full of txns, you actually lose expected fee revenue if you fail to broadcast high fee txns that you are aware of.]

[AndyRossy]

Liking this constructive discussion, good

[Sunny King]

Here is a thought experiment.

1) Each block has a time stamp T. All txns also have time stamps t. Blocks cannot contain txns from the future, e.g. all txns up to block T satisfy t<T
2) For the purpose of calculating fees, each block contains all txns over the past 2 hours.
3) Minters get a constant share of each txn fee, i.e. each minter gets to keep 1/12 of all the txn fees from txns for which T-t< 2 hours. (of course there is a random element to aggregate fee distribution now, but that is not a problem)

Under this design, only the txn time stamp and the block time stamp matter for fee revenue. You cannot affect your txn fee revenue through reorganization in any way. There is still a strong incentive to include newly broadcast txns. Including these txns allows you to capture a share of their fee revenue, which would otherwise go to future minters.  

Comments?

[Edit: Another thing about this is that it weakly incentivizes txn broadcasting. Keeping knowledge of a txn private cannot benefit you at all because you cannot affect the time stamp of the txn. Assuming that blocks are all full of txns or sometimes full of txns, you actually lose expected fee revenue if you fail to broadcast high fee txns that you are aware of.]

This is a good variation of spreading transaction fees. Some points below:

• Fee distributing transactions need to be both within 2 hours and 12 blocks
• Maybe still allow portions of fees to be destroyed, for example destroy portion of protocol-required fees, another example is to destroy the overpaid fees (further discourage grabbing of high fee transactions)
• The timestamp rule t<T is already in ppcoin protocol

[Jutarul]

Here is a thought experiment.

1) Each block has a time stamp T. All txns also have time stamps t. Blocks cannot contain txns from the future, e.g. all txns up to block T satisfy t<T
2) For the purpose of calculating fees, each block contains all txns over the past 2 hours.

Just to be sure... you're not suggesting that the new block actually contains the data. Just that previous blocks are evaluated when the fee is calculated, correct?

3) Minters get a constant share of each txn fee, i.e. each minter gets to keep 1/12 of all the txn fees from txns for which T-t< 2 hours. (of course there is a random element to aggregate fee distribution now, but that is not a problem)

Can you explain what you mean by "fee aggregation"?

The "constant share" is a direct monetary incentive again. Thus solving the QOS for the user (the user has the ability to raise the priority of the transaction).
I am a bit unclear on how the transaction fee is split. Are you proposing that 100% of the TXN fee gets redistributed across 12 blocks? Then we're missing the deflationary force again, as pointed out by Sunny. A simple solution would be to take the MIN_TX_FEE off the amount for redistribution. MIN_TX_FEE gets destroyed, the rest gets redistributed to the 12 owners of the block series.

Under this design, only the txn time stamp and the block time stamp matter for fee revenue. You cannot affect your txn fee revenue through reorganization in any way. There is still a strong incentive to include newly broadcast txns. Including these txns allows you to capture a share of their fee revenue, which would otherwise go to future minters.  

Comments?

[Edit: Another thing about this is that it weakly incentivizes txn broadcasting. Keeping knowledge of a txn private cannot benefit you at all because you cannot affect the time stamp of the txn. Assuming that blocks are all full of txns or sometimes full of txns, you actually lose expected fee revenue if you fail to broadcast high fee txns that you are aware of.]

I think this is the most constructive proposal so far. Good work!

[Jutarul]

This is a good variation of spreading transaction fees. Some points below:

• Fee distributing transactions need to be both within 2 hours and 12 blocks

That rule would add another non-predicatable deflationary force though. Because suddenly an UNKNOWN portion of the TX fee MAY be destroyed... people are already complaining about the non-predicatablity of the money supply....

[cunicula]

• Fee distributing transactions need to be both within 2 hours and 12 blocks

If you add in the within 12 block rule, then you reintroduce incentives for reorganization. I can now capture more fees if I displace the last mined block (in some cases).

If you make it a 40 or 100 block rule, then only the time limit will be binding and it should be fine. (i.e. the block limit would only matter if the time stamps break down.)

With a 12 block rule, the block limit is frequently binding and therefore reorganizations are often beneficial to the minter.

Just to be sure... you're not suggesting that the new block actually contains the data. Just that previous blocks are evaluated when the fee is calculated, correct?

Yes, no point in duplicating the data.

Can you explain what you mean by "fee aggregation"?

The number of blocks per 2 hours is random. Therefore, the number of blocks that are eligible for the txn fee/12 is random. On average, however there are 12 blocks every 2 hours, so it would approximately balance out over a long time span.

Are you proposing that 100% of the TXN fee

Any fixed% is fine. If you want a deflationary force, then make the % less than 100. I don't think the amount which can be collected as a fee should be capped.

gets redistributed across 12 blocks?

I don't mean 12 blocks. If you base it on the number of blocks you will have incentives for reorganization. I mean a 2-hour validity window determined purely by the timestamp on the txns and the timestamp on the block. Any block that makes it into the window gets txn fee/12. Sometimes you pay out more in fees then the txn fees included in the blocks (i.e. fees have to be minted). Sometimes you pay out less in fees than the txn fees included in blocks (i.e. fees have to be destroyed). It depends on how many blocks are generated in that two hours.

There might be some subtle gaming of the block timestamp involved which would prevent it from balancing out over the long-run. Not sure about this. In any case, you can leave a safety margin by destroying a fraction of the txn fees.

[Sunny King]

If fee collected is allowed to exceed fee paid I would reinterpret the proposal to be 'minting based on transaction fee'. So the expected minting is a percentage of total transaction fee paid. A consideration of a max minting limit might be necessary.

If the base transaction fee (1 cent per kilobyte) is always destroyed, I don't know if this satisfies most QoS concerns. Presumably if a QoS issue develops, users can raise their paytxfee to get confirmation faster.

Another consideration is paying part of transaction fees to minters might encourage minters to delay the announcement of proof-of-stake blocks. Although this might be an easy fix by enforcing that block timestamp must equal coinstake timestamp.

[cunicula]

If fee collected is allowed to exceed fee paid I would reinterpret the proposal to be 'minting based on transaction fee'. So the expected minting is a percentage of total transaction fee paid. A consideration of a max minting limit might be necessary.

I wouldn't worry about this. For example, you could just destroy 75% of txn fees. In this case you would need to see more than 48 blocks in two hours to have any possibility of running up against the minting limit.  Probability of this occurring is 3*10^-15. (e.g. it would happen once every 76 million millenia on average). Say we destroy 50% of txn fees, then you need to see more than 24 blocks to hit the limit. It would happen once every two months. You would need to allow an exception to the 2 billion limit for transitory minting of txn fees. These are later destroyed, resolving the problem. The total volume of currency issued could temporarily jump above 2 billion by a tiny amount.

[Note: I am assuming that the blocks have a poisson arrival rate, but if the block timestamp can be chosen arbitrarily by the minter (within two hours advance notice), then this will not hold.]

If the base transaction fee (1 cent per kilobyte) is always destroyed, I don't know if this satisfies most QoS concerns. Presumably if a QoS issue develops, users can raise their paytxfee to get confirmation faster.

Just destroy a fraction of the base txn fee, not the whole thing.

Another consideration is paying part of transaction fees to minters might encourage minters to delay the announcement of proof-of-stake blocks. Although this might be an easy fix by enforcing that block timestamp must equal coinstake timestamp.

I think this could be an issue. If there is an easy fix that is good.

[tacotime]

Are the transaction fees calculated from the size of the transaction in bytes, like for BTC and LTC?

Another potential problem with PPC is that PoS generate a huge amount of tiny fractions of coins over time that add up to large amounts in blockchain fees when they are actually spent.  Given a small amount of PPC, I imagine it is actually be a disincentive to hoard and get stake blocks for years on end because you'd just get swamped in transaction fees for the many kilobytes of inputs that you'd have to spend from.

What I really worry about in PPC's proof of stake system is the general disincentive not to save coins -- I think the maximum return for hoarding stake coins is 1% for year, while the currency inflates wildly according to the quantity of miners.  Without a strong incentive to hoard coins and avoid spending them, the PoS system falls apart.

[Sunny King]

Are the transaction fees calculated from the size of the transaction in bytes, like for BTC and LTC?

Another potential problem with PPC is that PoS generate a huge amount of tiny fractions of coins over time that add up to large amounts in blockchain fees when they are actually spent.  Given a small amount of PPC, I imagine it is actually be a disincentive to hoard and get stake blocks for years on end because you'd just get swamped in transaction fees for the many kilobytes of inputs that you'd have to spend from.

What I really worry about in PPC's proof of stake system is the general disincentive not to save coins -- I think the maximum return for hoarding stake coins is 1% for year, while the currency inflates wildly according to the quantity of miners.  Without a strong incentive to hoard coins and avoid spending them, the PoS system falls apart.

Yes transaction fee is charged on per kilobyte basis like in bitcoin. Fee rate is 1 cent per KB. And to simplify things and avoid user confusion, no fee-free transaction.

Over long term the level of proof-of-stake protection should be alright, it is not expected that a majority of coins to be constantly participating in the proof-of-stake generation such that it interferes with the coin's medium of exchange functions. Think about long term with bitcoin, the cost of proof-of-work protection is shrinking as a percentage of the total money supply as the block subsidy reduces. So to reach a comparable level of security, even just a few percent of the money supply are participating in proof-of-stake generation that could have been enough to deter double spending.

[Francesco]

Are the transaction fees calculated from the size of the transaction in bytes, like for BTC and LTC?

Another potential problem with PPC is that PoS generate a huge amount of tiny fractions of coins over time that add up to large amounts in blockchain fees when they are actually spent.  Given a small amount of PPC, I imagine it is actually be a disincentive to hoard and get stake blocks for years on end because you'd just get swamped in transaction fees for the many kilobytes of inputs that you'd have to spend from.

What I really worry about in PPC's proof of stake system is the general disincentive not to save coins -- I think the maximum return for hoarding stake coins is 1% for year, while the currency inflates wildly according to the quantity of miners.  Without a strong incentive to hoard coins and avoid spending them, the PoS system falls apart.

Yes transaction fee is charged on per kilobyte basis like in bitcoin. Fee rate is 1 cent per KB. And to simplify things and avoid user confusion, no fee-free transaction.

Over long term the level of proof-of-stake protection should be alright, it is not expected that a majority of coins to be constantly participating in the proof-of-stake generation such that it interferes with the coin's medium of exchange functions. Think about long term with bitcoin, the cost of proof-of-work protection is shrinking as a percentage of the total money supply as the block subsidy reduces. So to reach a comparable level of security, even just a few percent of the money supply are participating in proof-of-stake generation that could have been enough to deter double spending.

I am trying to understand, but it's quite complex... so, the advantage over bitcoin is that proof of stake is less expensive; and this should reflect in lower fees.
But will they still be lower if a significant amount must be destroyed?

And could you explain why it would be so bad to give fees to miners?

[Sunny King]

I am trying to understand, but it's quite complex... so, the advantage over bitcoin is that proof of stake is less expensive; and this should reflect in lower fees.
But will they still be lower if a significant amount must be destroyed?

And could you explain why it would be so bad to give fees to miners?

This is already explained in the design paper. Transaction fees would be an incentive for minters to try to 'grab' from each other. If this happens network would lose a significant portion of proof-of-stake protection.