Bitcoin Forum

I am currently trying to upgrade Instawallet to allow for transactions that a smaller than 0.01 BTC. I'm running into a couple of problems which I'm sure many other webmasters of Bitcoin-related sites will share. So I would like to try again to start a discussion on a more flexible transaction fee structure.

There are two problems:
1) The current RPC interface doesn't provide a very good way of dealing with fees. I want to be able to know in advance what fees I have to pay and be able to provide a maximum on a per-transaction basis. BlueMatt has worked on an improved interface (see this pull request: https://github.com/bitcoin/bitcoin/pull/289), which I think is very promising and I hope it can get the attention it deserves and this or a similar improvement can be merged into mainline soon.

2) The fee structure for getting a transaction relayed is too rigid. I'm not talking about what ends up in a block here. The miners are free to come up with good fee structure and I'm sure they will. I'm talking about the step before that, when transactions are getting relayed by the Bitcoin network. My users/customers will be using a standard Bitcoin client and will hook into the Bitcoin network at a random position. I want to receive from or send transactions to them and as such am bound by what the network in between will relay. The rules for this are not flexible enough.

What's the issue exactly? We have two shared resources:
a) network bandwidth of nodes
b) space in blocks

Again, I think that "b" will be taken care of by the miners. But access to "a" is governed by what the majority of Bitcoin nodes will do and the majority of Bitcoin nodes will run the standard Bitcoin client software. Currently this means that a transaction smaller than 0.01 BTC and which does not include a fee will not be forwarded by the network - and as such never has a chance to get to a low-fee miner unless you get out of the way to directly connect to the miner, which again your users/customers will probably not do.

I believe that free and as-cheap-as-possible transactions are a killer feature of Bitcoin at it's current stage. We need to make sure that free market effects can work not only on what miners will include in a block, but also on what nodes will forward in the network.

That's why I think we need some form of auto-adapting mechanism when it comes to forwarding transactions. We will never come up with a reliable set of fixed rules of what differentiates a spam transaction from a legit transaction. Instead, I think nodes should simply forward as much as they are able to, but focus on high-priority transactions when they are starting to get overwhelmed.

To describe the algorithm, lets assume a node can wait a while before it forwards a transaction: So it would collect transactions for some time, then sort all the transactions by priority and then forward as many as it is able to, starting from the top of the list. Obviously transactions should be forward as soon as possible, so this algorithm needs to be adapted to work in real-time: It would probably need to look at past transactions and dynamically determine the threshold it needs to apply to stay within the rate limits in needs to obey with regard to network bandwidth.

If such an adaptive algorithm were in place at the majority of nodes, the network bandwidth would be available at a price that corresponds to the current level of traffic. On "good days" you would probably get away without a transaction fee for the time being. On days where the network is spammed by some person, you still only need to pay a little more than the spammer to still get through.

Your thoughts?

This seems like a good idea. Is there something wrong with it?
Is this proposal (or a similar one) discussed in another thread?

Similar: Let spammers (and everyone) pay for spreading transactions. Section 4.3 of http://www.newbitcoin.org/documents/newbitcoin.pdf (http://www.newbitcoin.org/documents/newbitcoin.pdf).