Recently there have been a lot of discussions regarding the transaction fee on peercointalk.org and in the greater cryptocommunity at large. Of course, this is due to the recent spamming of the bitcoin network.
We here at Nu are about to do something extraordinarily innovative: we are about to implement a solution to a network problem that bitcoin is having that is intrinsically dependent upon conscious shareholder consensus. At the same time, this is not the first time we have done this; we performed the same momentous task when we fixed the volatility problem of bitcoin.
This measure is powerful, and a wonderful implementation of a catch-all for ddos-type situations. However, in my opinion, it is by no means the most graceful solution. A spammer can hijack the fees by forcing the network to respond in a particular way via manipulation. If they want to send something, they can just stop spamming, and keep spamming at all other times to keep the fee high, depending on the nature and motivation for their attack.
Basically, all I’m trying to say is that I urge the community to seriously consider implementing automation of the variable fees following peercoin, if that is where the discussions end up. We could always vote for an additional fee for nubits, or a volume-dependent fee, on top of the default variable fee if peercoin or bitcoin implements a graceful and thorough fix. The fix should be applied to both NSR and NBT fees, scaling any fee by 100x for NSR.
too many links, could you summarize the conclusion of bitcoin community? I think bitcoin blockchain is fullfilled with stupid tiny transactions, very bad design.
I do not get what is the issue with voter-controlled fee.
Can you clarify?
Also, the problem with bitcoin is that basically you can spam the network for cheap because the fee per tx is very low.
But why aren’t raising the fees then?
You’re asking me to summarize an ongoing discussion with no current solution from the perspective of bitcoin, litecoin, peercoin, and Nu. I cannot do it full justice, so I will stick to my opinion. Raising fees is a temporary solution and is against the nature of bitcoin’s ‘choose your own fees’. Peer forks don’t obey that philosophy. We implement a minimum output (anti-dust like litecoin recently implemented) and a fixed fee. A fully automated variable fee that seeks to adjust the fee to keep transaction volume near a target value would be ideal.
The issue with voter-controlled fee is that people can take the network hostage by spamming and forcing voters to reach consensus on a large fee. If the voters let the fee drop below a certain value, ddos becomes imminent, and since it takes the voters time to respond this can have a negative impact on our image if it happens frequently. Tthis is the kind of thing that needs to change within a block (<1 minute response) rather than via slow processes like voting.
If the plan is to just keep the fee high so that the ddos is not practical, then why even have variable fees? Why not just have a high fixed fee? And then we’re right back to where we started, that solution is not eloquent or efficient.
Voter-controlled fees will definately work better than anything the crypto community has come up with yet, and Nu should be applauded for providing a solution in such a timely manner to a problem that has yet to occur on our network. However, I have faith that there are better solutions out there.
We vote to maintain relative high transaction fee, today PPC is 0.5$ value, and 0.01PPC/KB, if PPC rises to 5$ in 2016, we vote for 0.001PPC/KB or something else.
This is pretty much my opinion as well.
Without a variable adjustment a fee might be too high for regular use while still being to low to make spam expensive enough.
A variable fee that adjusts to the utilization is what could help fix that.
I have made a topic in bitcointalk that is relevant to this topic as well. It includes a couple of references to other topics that discuss potential solutions to the core problem: https://bitcointalk.org/index.php?topic=1116996.0
Voting requires conscious attention. You’ll find that the proposed solution is simiilar to voting, but without requiring conscious thought on the part of the minter.
Can anyone explain how the voter-controlled fee works with reference to the users? Are the users expected to know what the fee will be when the minter receives their Tx?
That’s what makes dealing with voting controlled fees more tricky in my eyes: for the voters and for the users.
If fees can be derived from protocol enforced rules they can be read from the network.
But I think even with “unpredictable” outcomes regarding fees of future blocks, an estimation can be made based on the mempool.
Example: based on the mempool size a client can roughly calculate to what level the next block is about to be filled (at minimum).
Based on that information the transaction fee can be estimated by the wallet (that might beat the fees of transactions already residing in mempool).
If the next block is already oversubscribed, the proposed transaction fee for a newly created transaction could be even higher (to “assure” a place for the transaction in the next block - until other transactions follow that even beat that fee…). A wiser move might be to withhold the transaction.
Now we see a basic difference of Nu and Peercoin.
Nu needs to protect the blockchain from spam to make processing transactions reliable, because NBT are meant for transactions. I don’t see a reason not to include a mechanism like Litecoin did: to require a fee for each output of a transaction.
All transactions that meet this criteria are “proper” use of the blockchain c even if intended to spam it.
I don’t see a sound way to limit that execpt for automatically adjusting variable fees.
I’d rather see the voting limit the floor level of the fees (within boundaries set by protocol) and the threshold when to start raising the fees.
In my view for Nu everything is fine as long as blocks are at average below 100% fill level (given some anti spam like fee for each output is in place).
Peercoin on the other hand should try to protect the blockchain from being bloated cheaply. Other, much less frequent use of the blockchain, is intended by the design of Peercoin. Its blockchain needs to be protected from a regular block fill level of more than x% (far, far below 100%!); but that is only my opinion
Litecoin hasn’t done anything we haven’t done. Our protections are better in every way than ltc or btc.
I really think a smoothed step based on verifiable previous blocks is responsive enough. I cannot think of any way to seriously exploit the smoothed step formula. The limitation to response time is getting the word out to the clients. We don’t need a fee estimated like btc just implemented, we can simply define an unexploitable declared minimum fee, as I outlined in the wiki.
Keeping the block chain small is useful for any cryptocoin. With Nu’s 1 minute blocks, a smoothed step method would be even more effective at responding to type 1 attacks.
The mempool is specific to the node. The client doesn’t know the mempool of its minter beforehand. Any fee based on an individual node’s mempool is untranslatable to the client.
Exploiting the smoothed step would look like this:
An attacker with money to burn has 3 options each block:
Fill the block
Don’t send anything
Fill the block to target
The first thing they’ll do to get the fee to respond is fill the block, paying just over 10.24 PPC to do so at a slightly higher fee than the minimum fee (say 0.01001). As the fee still doesn’t respond because of window averaging, they’ll fill the next block or two as well, spending another 10 or 20 PPC. Now they have pushed the fee up and set the process in motion.
If they keep filling the blocks, the fee will keep rising and it will become extremely costly to do so, increasing at a rate of something like ~20 PPC/block (so it would cost 30, then 50, then 70, then 90, etc. to keep filling blocks). Therefore, they will eventually either lower the attack to filling at target, or not putting funds in the block. At that point, the attack has successfully been repelled. The window average will keep increasing the fee for a couple blocks and then begin lowering, more slowly than it shot up (we’re assuming a TFF of ~0.35 here) by about 4x or so. If the attacker comes back before it fully relaxes, the process will start over with the increased minimum fee and the attacker will waste a good bit of resources. The relaxation may take a while, 100 blocks or so. All these numbers are dependent upon a fair number of assumptions about how the network behaves and what the TFF and x voters are doing.
The end result is that the attacker spends a couple hundred PPC spiking the fee up to like 0.1 PPC/KB for a day or so, with very little blockchain bloat. At that point, I am of the opinion of “go ahead and try”, which is where we should be with this. We are essentially profiting off of pointless spam attempts, and it’s excellent.
Shouldn’t mempools of different minters have contents very close to each other?
Don’t they contain the broadcast transactions that are not yet in a block?
Apart from the transfer delay from the sender to different minters, there shouldn’t be much difference - or do I get the mempool concept completely wrong?
Sure, kind of, but if all the mempools are the same, then why even have a blockchain? Tx written on the blockchain are the only Tx that are verified and accepted as being part of the network officially. Also, some nodes may never see a Tx in their mempool before it is written on the blockchain (if the sender is halfway around the world from the node of interest). We could do a kind of “best efforts” to determine a fee based on an individual node’s mempool, but I fear it will be susceptible to attacks. It gets really tricky if the fee is unverifiable.
All this talk of mempools aside, can you think of any possible exploit or flaw in my proposed solution? The fee would be completely verifiable and would respond in a fairly rapid manner to DDoS attempts. As for the long range problem of blockchain bloat, I think it pretty efficiently solves that problem as well by creating a target filling for blocks that is vote-able by the stakeholders and adjusting the fee until the network equilibrates at that target (or lower).
