Topic: CreateTransaction: suggest/enforce fee for big low-priority transactions - page 4. (Read 7864 times)

I don't think it will be a good idea to allow any announced transaction to fail to get processed by the network...the announcement of the transaction on the network should be the act of transacting...inclusion in a block just makes it confirmed and permanent.  I initially thought that some policy of expiring unprocessed transactions would be good, however that would open up the possibility of clients deliberating crafting transactions to fail (in order to get something for nothing).

So, what if both the age and the transaction fee are considered in the priority calculation?  Any transaction over 4 hours (just making something up) old should have priority over any younger, fee bearing transaction, no matter the fee involved.  In other words, transactions under 4 hours old would be processed based on fee first, age second, while transactions older than 4 hours would be processed based purely on age (fees breaking ties I guess...and obviously all the nodes on the network would have to enforce this such that a miner couldn't just ignore those rules).  Under this scheme (after the end of block awards), fee bearing transactions would entirely subsidize the cost of free transactions (otherwise there would be no incentive for block creation).

I don't know what implications this might have on block size limits...I haven't learned enough about the system to understand the importance of transaction or block size limits...if there is a high enough sustained transaction volume, I imagine the block chain would start to fall further and further behind.  Lifting those limits might open the network to DOS attacks but having those limits would seem to create an upper bound on transaction volume and the system would have no choice but to abandon really old transactions that have yet to be processed.

If abandoned transactions were unavoidably a part of the system, I don't think reclaiming those coins is really an issue...at least not at the protocol or network level.  Clients could simply reverse those transactions in their tallies if a certain amount of time has passed without confirmation (such that the network would have flushed it).  The goal of the network would be to never flush any transaction, but if it started to happen (even on a small scale), maybe the block and/or transaction size could be increased...all clients don't necessarily need to retain the transactions inside blocks...they could keep running tallies of bitcoins in various accounts and validate/digest each block as it comes through (maybe with a small tail to handle the case where blocks occur close in time to each other).  You would still want to have a number of super nodes keeping the full history (and making all transactions available to peers as needed), but you would eliminate a lot of storage requirements on a lot of nodes without losing their important block validation role.

Right, that's pretty much what dropping the concept of "free space" would do. All space is equal, transactions are ordered by fee and priority score. So you can never get a transaction that's too big/low priority to enter a block.

yay! I support that. if nothing else, collecting .0001 is a nice way of keeping score
now that the full precision display/handling seem to be fixed.

Seems like it just should be simpler so the strategies for dealing with it could be seen by everyone and dealt with behaviourly instead of with software patches. Like fifo for free txn with priority for fee txn and a way to add a fee to your txn.

Client should also warn about low priority transactions and suggest a fee to increase chance for inclusion.

This definitely needs fixing; it is another "people getting lots of very small change from mining pools" issue.

The code that controls this is CTransaction::GetMinFee() in main.h and CreateNewBlock() in main.cpp.

We should think about:

+ Is setting aside a specific amount of space for free transactions the right thing to do?  Maybe blocks should just get filled in reverse priority order (with transactions with fees at the front of the line)

+ What to do with the current transaction backlog.
If old, big, low-priority transactions get flushed, then there needs to be some way for the bitcoin client(s) that sent them to reclaim those coins.  Perhaps the client should stop retransmitting, and reclaim, transactions if, oh, 5,000 blocks go by without the transaction getting accepted.

Or maybe it makes sense to let those old transactions trickle in; perhaps the next version of bitcoin should take the oldest transaction in the memory cache and add it to the generated block.

It's not optimal if transactions are not being processed while there's space available in the blocks.

Why not experiment, in the next client, with a setting that allows the user to specify a very low default fee for all transactions (well below 0.01 BTC). Then see what happens.

This is:  https://github.com/bitcoin/bitcoin/issues#issue/86

currently (2011/03/01) a backlog of transactions that dont seem make it into blocks is building up (according to ArtForz now 670 transactions).

People are starting to complain, see https://bitcointalksearch.org/topic/m.57031 for an example.

This was discussed on #bitcoin-dev

ArtForz> that tx should have a score of 20567855
ArtForz> so it falls short of the dPriority > COIN * 144 / 250 test
ArtForz> and as tx size is > 4000, fAllowFree is never true for it
theymos> Ah. So it will never confirm?
ArtForz> probably not

ArtForz> looks like the tx-sending code needs some fixing
molecular> like not generate a tx with a score too low, or suggest to add a fee?
ArtForz> yep
ArtForz> check size and priority of transaction, if it's > 4kB and score < 57600000 require min fee
ArtForz> maybe reduce the size limit to 3.5k or so, otherwise it can only get into an otherwise empty block

Maybe the transaction cache should not be unlimited?