[UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available

[etotheipi]

The quickest and easiest solution is probably to change the coin selection algorithm to always select the oldest coin(s) possible for the inputs, thereby not triggering a fee in bitcoind.  In most/many cases that will avoid the fee.

btc_artist:  this is already part of the SelectCoins algorithm optimization  (or at least it is in Armory, I assume Satoshi SelectCoins is similar).  But you don't always win when you do that -- you frequently have no way to construct a transaction without doing something that invokes a fee (usually having to combine lots of tiny inputs to make the transaction).   

From talking to gmaxwell, it sounded like the dust-output trigger (for sending a tx with any sub-0.01 outputs) is universal.  In otherwords, there are plenty of miners that will mine large transactions, or transactions with young inputs, but all nodes impose a fee for dust outputs.  Without it, there's nothing stopping people from spamming the network with single Satoshi coins and adding a GB to the blockchain per day.

[schnell]

I came here looking for a fork you could buy with bitcoins.
It was in the latest post in technical discussion, and I got excited.
And I get this.
Thanks a lot.

[grue]

For Sale: Bitcoin Fork
Zwilling J.A. Henckels Premiere Series "Earl Frost" 18/10 Stainless Flatware:
From the makers of the world's finest cutlery since 1731 comes the J. A. Henckels International Flatware Collection. The Earl pattern features a sculpted, contemporary design with a larger, continental size similar to those found in nicer restaurants around the world. All pieces in the collection are made of the highest quality, 18/10 stainless steel. The knives have hollow handles for a better balance and comfortable grip, and finely honed, extra-sharp blades for superior cutting.

Medium Solid Cold Meat Serving Fork:
http://we.lovebitco.in/img/fork1.jpg
http://we.lovebitco.in/img/fork2.jpg
2 BTC, Shipped USA

Complete 5-Piece Hostess Serving Set including fork:
http://ecx.images-amazon.com/images/I/41ASCFDFV4L.jpg
5 BTC Shipped USA

i see what you did there

[schnell]

:3

[ShadowOfHarbringer]

Could everybody please stop derailing this topic ?

I kind of wanted to use it to inform people about releases of NFTF.

[Luke-Jr]

https://github.com/bitcoin/bitcoin/pull/570

[ShadowOfHarbringer]

https://github.com/bitcoin/bitcoin/pull/570

Excellent. I will review the code, and if it is what i expect (and it gets pulled into mainline), then i will be able to stop maintaining this fork.

Force strong is with you, Luke - big thanks.

[ShadowOfHarbringer]

2012-03-21 Update:

NFTF - version 0.5.3.1 [critical security vulnerability hotfix] released.

Fresh tag - nftf-v0.5.3.1 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

More updates (other tags, trunk) should follow soon.

[Luke-Jr]

More updates (other tags, trunk) should follow soon.

Be aware that if you cross-compile, 0.6rc4 will only build securely if you rebuild Qt with the gitian hacks first (or merge #946).

[Steve]

What I would like to see is not only the ability to create transactions without a fee, but also the following:

a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks

b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction

[Raoul Duke]

b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction

Steve, that's the best friggin' idea I've read in this forum at least in the last 6 months
And I'm serious!

[ShadowOfHarbringer]

What I would like to see is not only the ability to create transactions without a fee, but also the following:

a) the client to offer a suggestion of a fee that would have a high probability of getting into the next block or two based on some kind of analysis of recent blocks

b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.

I have no intention (or required C/C++ skill) of taking it further.

Perhaps somebody else will take up the challenge.

[Luke-Jr]

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.

I'm not aware of any version that didn't force fees...

[ShadowOfHarbringer]

This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards.

I'm not aware of any version that didn't force fees...

Well yeah - to be precise I am talking about versions that force fee even when there is high probability of it being completely unnecessary.
All versions newer that 0.3.21 do that.

[DeathAndTaxes]

b) building on an unconfirmed transaction won't make the original transaction happen any sooner. The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.

What?

The RECEIVER would build upon the unconfirmed transaction.

i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me).  No fee was included so the transaction isn't being picked up by miners.  I take the unconfirmed B and send it to C (another address owned by me).  I include a fee of 0.10 BTC.

A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block.  A really awesome "confirmation booster".   A solid +1 to Steve.  A very nice way around senders paying for tx fees.

The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.

Um that is exactly what he proposed except there is no need for a special tx.  Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.

[Luke-Jr]

b) building on an unconfirmed transaction won't make the original transaction happen any sooner. The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector.

What?

The RECEIVER would build upon the unconfirmed transaction.

i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me).  No fee was included so the transaction isn't being picked up by miners.  I take the unconfirmed B and send it to C (another address owned by me).  I include a fee of 0.10 BTC.

A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block.  A really awesome "confirmation booster".   A solid +1 to Steve.  A very nice way around senders paying for tx fees.

The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.

Um that is exactly what he proposed except there is no need for a special tx.  Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.

I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.

[DeathAndTaxes]

True miners would need to notice that B->C depends on A->B but as subsidies decline and tx fees become more important it is a useful way to move the tx cost to the receiver.  Receiver can wait and hope it is included eventually (which maybe the want to do if the payment isn't pressing) or pay a premium fee to get it in the next block. 

[Steve]

I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.

I think that's a problem that would fix itself if clients had this feature and people started using it.  If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements.  This situation can occur today, though it's probably quite rare given the behavior of the main client.

Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block.  You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so).  This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.

In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes.  So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.

[ShadowOfHarbringer]

I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet.

I think that's a problem that would fix itself if clients had this feature and people started using it.  If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements.  This situation can occur today, though it's probably quite rare given the behavior of the main client.

Regarding my suggestion of a fee that has a high likelihood of making it into the next block, I was thinking of some sort of statistical analysis that could determine a fee that is in the Nth percentile with respect to the time between the transaction appearing on the network and it being included in a block.  You could configure the percentile that you wanted your client to suggest (with perhaps the 95th percentile being the default or so).  This means that if you applied the suggested fee, you would have a transaction that should be in the 95th percentile of all transactions in terms of the time it takes for that transaction to get included in a block.

In most cases, you either want the transaction to get into a block as fast as possible or you don't care at all how long it takes.  So choosing between a 95th percentile fee or no fee at all is likely the only choice most people need.

I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.

This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.

So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.

[Steve]

I don't know if you have already figured it out or not, but if you want something done in Free Software world, you have to either do it yourself, or make somebody to do it for you.

This is exactly what i did here, because nobody cared that i do not want to pay fees when they are not necessary.

So the best option is probably to start a fork of your own (if you can code), or pay/convince somebody to do it.

Yes, I know.  I've worked on open source projects for close to 15 years.  But I also know that if you keep an idea to yourself, there is close to zero chance that someone else will implement it if you don't anticipate having time to do it yourself.