I agree with this general effort to maintain the 0.01 PPC/KB fee, and think you are being comprehensive about finding solutions.
1 Like
what about making the fee a function of the average number of transactions over the last x blocks
Changing the fee from 0.01 PPC/KB would be controversial, and I do not support any such efforts at this time unless we use a formula that converges to 0.01 PPC/KB in the current conditions.
Agreed. It’s best to keep the fee proportional to a fixed ppc/kb rate. This allows future use-cases to estimate the amount of ppc they’ll need for future transactions.
Yes I fully support this, as we shouldn’t be pushing users towards grouping transactions with others (like exchanges are doing)
Is this the minimum resolution? Or you want to keep a limit? I’m not sure we really need a lower limit.
The transaction size is the least of my concerns here, bitcoin tooling compatibility is a much more important reason IMO.
If we find a good reference implementation, why not.
I propose to follow Bitcoin Cash’s approach here for a while, did they fix txn malleability already?
I would keep flextrans in mind as I believe it is a very good long term goal.
Segwit will never get my support.
It’s a spam deterrent. I think 0.0001 is enough, it’s just bellow normal user threshold but will still influence the spammer.
Yes, with so called “simple malleability fix”
I agree we should do that before we have manpower to tackle flex tx.
Let’s make this limit a standardness rule (which defines whether a txn get’s relayed), not a protocol rule.
Just like the 80byte OP_RETURN limit.
1 Like
I agree.
Opening the topic for public discussion.
Good to see this dicussion being made.
Some of the proposed approaches are technical enhancements. Others are economic enhancements. It might be good to distinguish and separate these two.
This is an economic enhancement. It will be interesting to see how the decision process will evolve and be made.
What is the proposed timeline for such a change?
Clarification is required. 10k transactions by a single entity? 100? 1000? 10k? Will not the number of entities participating influence such a decision of reducing the 0.01 transaction fee?
Signature aggregation should be examined. What is the timeline?
It’s not clear that Schnorr signatures is the best option. It is still largely unknown from an implementation point of view. There are already proposed attacks that the Bitcoin people are attempting to solve. Also, there are other proposed signature aggregation techniques. Though again, the application in blockchain is still new and unexplored and should be carefully considered before adopting any particular aggregation scheme.
It might be good to wait until another blockchain has tested and deployed. Unless Peercoin has an expert in mind.
I am not fully understanding this topic, so wish to clarify it.
0.01 PPC/KB sounds to me like a flat rate charge. The KB represents the transaction, and 0.01 PPC the cost.
So, one transaction (assuming one KB) equals 0.01 PPC fee
Two transactions equals 0.02 PPC fee … but this remains 0.01 PPC on average
One million transactions equals 10,000 PPC fees - but this is still 0.01 PPC on average
So, where does the concern of rising fees come from?
So current minimum fee is 0.01 Peercoin, regardless of the transaction size.
I think this is not fair on the users, so I propose to lower the minimum fee to 0.001 or 0.0001.
So, the concern is not activated by a rise in transactions per se, but rather there is an underlying concern that what is (effectively) one per cent is simply too high?
EDIT: the 0.01 PPC charge would not be 1%, although it might be perceived as such.
This does not have to do with the 0.01 PPC/KB fee, this proposal is to change the minimum fee from 0.01 PPC to 0.001 PPC and to stop rounding the fees. The total fee would still nominally be 0.01 PPC/KB as it is now.
As an example, the standard txn is something like 300B. This currently costs a 0.01 PPC fee for 2 reasons. The first is that 0.01 PPC is the minimum fee. The second is that the 0.3KB is rounded up to 1KB for the purposes of the fee. If we make the changes proposed, a 0.3KB txn would require a 0.003 PPC fee.
1 Like
@peerchemist would we keep the 0.01 ppc dust size? Note that we pioneered this feature and ltc recently(ish) adopted a 0.001 ltc dust size.
Commenting w/o a technical background, I support any efforts to foster developer use of the block chain and support lowering the tx fees if that’s an impediment to adoption; provided, however, any modification should be rigorously tested and compatible w/ applications written for other blockchain protocols.
Accordingly, I agree w/ stopping rounding and an adding an extra zero or two for the minimum tx fee. But, I’d be more skeptical about Schnorr Sigs, Segwit, Flex Transactions, etc - unless they’ve all been thoroughly tested and universally applied elsewhere. All else equal, it should be the minimum protocol change necessary to help achieve the goal of developer adoption.
As a side note, I thought I remember hearing a criticism of ethereum that every transaction was recorded on-chain and that this was a long run scalability problem. Perhaps that’s a good problem to have and we can worry about it later. But, in any event, this criticism was made in trumpeting Peercoin’s svelte self-limiting blockchain w/ possibilities for lite mobile wallets. Is lowering the tx fees and promoting on-chain transactions not a bit of a sea change from the original mission? Even if it is, I support it - but it’s good to clarify the mission statement from time to time.
Sounds agreeable.
Agreed with change to reduce minimum fee to 0.001 or 0.0001 PPC.
If we make this change, is it also worth thinking about future minimum fee changes. What if PPC price increased 10x or 100x and what would a fair minimum fee be under these conditions?
Or should these changes be on an ad-hoc basis?
Changing of the minimum transaction fee charging 0.003 for 300 bytes instead of charging 0.01 for 300 bytes sounds more like a “bugfix” than anything else. The letter of the law is being held intact.
Originally this is what the thread sounded like. However, as explained earlier the minimum fee is different from the fixed transaction fee per KB. So the price increase is orthogonal.
Changing the fixed transaction fee per KB 0.01/KB, while an interesting discussion, it is one of more significant consequence and should be analyzed more deeply with merits. In addition, the reward scheme must be analyzed as well, which has ramifications on the incentives and ultimately security of the system.
Unless a transaction can be processed without any bytes being used, all transactions necessarily have a fee.
So the issue need not be “should we create a lower minimum fee” but rather: should the fee reflect, in a proportional way, the number of bytes used, subject to a maximum fee of 0.01kb
If so, this means the 0.01kb would become a percentage fee - 0.01 PPC for 1kb, 0.005 PPC for 0.5kb, and so on - but the percentage aspect would not apply above 1kb, because the cap of 0.01PPC would apply.
Is this an accurate understanding?