Modifying the economics of Peercoin in anticipation of increased blockchain usage


Again, none of this is about lowering the fee per kb. Lowering the overall fee is not on the table at all. This is about changing the rounding and the minimum requirement. The total fee would remain at 0.01 ppc/kb.

If you want to argue about the overall fee, please make another thread, as it only adds to the confusion talking about it here.


This just means, that buying a coffee with Peercoin would be affordable again. As a transaction is only 300 Bytes in size (as stated by Peerchemist).

That means that a transaction for buying a coffee costs 300/1000×0.01 = 0.003 PPC transaction fee (which is still much more than the proposed minimum transaction fee of 0.0001 PPC.

Well, is any type of transaction lower than 300 Bytes long? Which? If not: Why bother and lower the minimum fee to 0.0001 if this is never used? (I am tired, maybe my question is silly or I mixed some numbers)


reduce minimum tx fee to 0.001 ppc
I hope


There are ways to make tiny transactions. 10 bytes is doubtful, but 100 is doable. Maybe at the 1 mPPC level it doesn’t really matter, but the 10 mPPC level does.


I was confused on if this were a lowering of the 0.01 ppc fee per kb, and/or allowing tx fees below 0.01

Part of the confusion is that both values are represented by the same constant in the peercoin source code: MIN_TX_FEE

src/main.cpp:int64 nTransactionFee = MIN_TX_FEE;

this is where the tx fee is rounded up to 0.01
src/rpcblockchain.cpp: nTransactionFee = (nTransactionFee / CENT) * CENT; // round to cent

this sets the tx fee per 1000 bytes x 0.01
src/wallet.cpp: int64 nPayFee = nTransactionFee * (1 + (int64)nBytes / 1000);

It would seem to keep the 0.01 fee per kb and also allow lower tx fees than 0.01, there needs to be a new constant (TX_FEE_PER_KB or TX_FEE_PER_K) at 0.01, then set MIN_TX_FEE = 0.001 or 0.0001.


why not have a transaction fee per byte, instead of kb?


This is essentially what is being proposed.

The comment @skull made was that having a lower minimum of 10 bytes is pointless because there is no txn that is 10 bytes. My point was that there are ways of forging a txn that is <100 bytes, though 10 bytes is indeed smaller than any txn could ever be.