Bitcoin Forum
November 21, 2017, 08:24:48 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Dynamic minimum transaction fees and negative transaction fees  (Read 480 times)
krzysiekj
Jr. Member
*
Offline Offline

Activity: 50

Founder of Ercoin and Paspagon


View Profile WWW
February 24, 2016, 09:50:15 PM
 #1

Abstract

This paper presents transaction fee related threats to cryptocurrencies with high block frequency and low transaction volume (relative to market capitalization), taking BlackCoin as an example. It then presents a possible solution: dynamic block sizes, which would allow for market adjustment of transaction throughput. Disadvantages of dynamic block sizes are then presented and dynamic minimum transaction fees are introduced. Possible collusion of miners with users is then discussed and partial fee destruction is proposed as a remedy. Finally, negative transaction fees are discussed.

Full version in HTML is available for free. EPUB and Kindle (AZW3, MOBI) versions are paid.

Ercoin: proof of stake, fair distribution, messages, accounts, flexible fees, original code
1511252688
Hero Member
*
Offline Offline

Posts: 1511252688

View Profile Personal Message (Offline)

Ignore
1511252688
Reply with quote  #2

1511252688
Report to moderator
1511252688
Hero Member
*
Offline Offline

Posts: 1511252688

View Profile Personal Message (Offline)

Ignore
1511252688
Reply with quote  #2

1511252688
Report to moderator
1511252688
Hero Member
*
Offline Offline

Posts: 1511252688

View Profile Personal Message (Offline)

Ignore
1511252688
Reply with quote  #2

1511252688
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511252688
Hero Member
*
Offline Offline

Posts: 1511252688

View Profile Personal Message (Offline)

Ignore
1511252688
Reply with quote  #2

1511252688
Report to moderator
1511252688
Hero Member
*
Offline Offline

Posts: 1511252688

View Profile Personal Message (Offline)

Ignore
1511252688
Reply with quote  #2

1511252688
Report to moderator
rat4
Full Member
***
Offline Offline

Activity: 180


View Profile
March 13, 2016, 08:26:09 AM
 #2

How does your proposal for 'dynamic minimum transaction fees' interact with complex use cases where a transaction is created long before (e.g. a month) it's broadcasted?
We can't predict future fees, but if minimum fee has risen and it's a policy, the tx is still valid and can be paid for being included into blockchain.
krzysiekj
Jr. Member
*
Offline Offline

Activity: 50

Founder of Ercoin and Paspagon


View Profile WWW
March 14, 2016, 03:00:57 PM
 #3

I see three ways to handle that problem.

Firstly, it is worth to note that fee values will barely depend on current transaction volume and mostly on hardware, network and electricity prices, which should be quite stable. Therefore if you pay higher fee, like 1.3 of the normal value, you should achieve a high level of probability that your transaction will enter the blockchain. A caveat of this approach is that while fees may be stable when denominated in fiat currencies, the price of BlackCoin itself may fluctuate. To protect himself from an event of a sudden collapse, one may want to pay even higher fees, like 2 or 3 times the normal value.

Economically, this problem is quite reasonable: if you were to prepare a cheque to pay for any other commodity (like a TV) with a monthly advance, then this would lead either to paying too much (and therefore losing money) or not paying enough (and the purchase not occuring).

Another approach is to generate multiple versions of the same transaction which would differ only by the fees paid. This shouldn’t involve much more complexity on the client side and would even allow constructing chains of transactions. When submitting a chain, one with a most accurate fee level can be chosen (I assume the price will be the same for all transactions in a particular chain, as they will presumably be stored in one block).

The last approach is to implement “child pays for parent” which, to simplify things, may be done in a generalized way, i.e. for a block to be valid, the sum of transaction fees paid must be greater than or equal the sum of transaction fees required.

The original proposition of dynamic minimum transaction fees can simplify relaying policy. In particular, there would be no need for the GetMinFee function to distinguish between the relaying and sending cases. However introducing “child pays for parent” would mean a step back, as there would be no way to determine whether a transaction with low fee is mineable upon receiving it. A few solutions to this problem are available:

⒈ Change binary protocol so that it allows sending a few transactions at once. (Doesn’t sound like a good idea).
⒉ Lower fee threshold when relaying.
⒊ Accept transactions with low fees into mempool conditionally and evict them if a child paying an additional fee is not received shortly after.
⒋ Ignore the transaction relaying problem altogether, implementing “child pays for parent” only as a block validation rule and assuming that the user has either to mine a relevant block himself or to find someone who does it for him.

As a starting point, I would recommend option ⒋ and consider changing the relay policy if there is a demand for that. This would not exclude usage of the first two approaches. Which one is the best for an user, depends on a particular use case.

Ercoin: proof of stake, fair distribution, messages, accounts, flexible fees, original code
HeroCat
Hero Member
*****
Offline Offline

Activity: 658


View Profile
March 14, 2016, 03:06:12 PM
 #4

More important is fast transaction time, nowadays when BTC transaction times can be many hours, this is very important. For example, Doge have transaction time - 3 - 5 minutes only.  Smiley
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!