Topic: [UPDATE: 2015-05-10] Bitcoin Core soft-fork "No Forced TX Fee" v0.10.1 available - page 2. (Read 59296 times)

I'm a question : in Windows XP 32 bits SP3 + all available updates ... the v0.9.2.1 crash before 24h of use.
I use bitcoin core only for RPC server and node (-disablewallet).

Can this version have a modification for this (crash) ?
Or only the fees strategy is modified ?

Thanks

2014-08-10 Update:

NFTF - versions 0.9.2 & 0.9.2.1 released.

Fresh tags - nftf-v0.9.2, nftf-v0.9.2.1 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the newest version (0.9.2.1).

If Bitcoin becomes REALLY expensive, the developers will have to lower the fees in the core client anyway (or finally create a dynamic fee calculation/voting algorithm).

If BTC reaches really high price lower fees might be crucial when choosing clients.

Great idea. I will test this out, just to see how it works.

2014-06-01 Update:

NFTF - versions 0.9.0 & 0.9.1 released.

Fresh tags - nftf-v0.9.0, nftf-v0.9.0 are avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was updated to the newest tag (0.9.1).

Actually nowadays fixing a transaction potentially(still, low probability) broken by using my fork is getting easier and easier.

For example, you could probably undo a broken transaction (with not enough fees included) using Bitundo:
http://www.reddit.com/r/Bitcoin/comments/234iem/bitundo_allowing_you_to_undo_bitcoin_transactions/

Of course, you can always do it using raw transaction API, but that's complex.

I hadn't noticed that.

You're right, it is a bit confusing.  Apparently there are still some conditions where the fee is still required by this wallet.  That's probably a good thing, since all peers would just ignore the transaction anyhow, but I suppose it would be better to call this the "reduced conditions for TX fees" wallet.

This:
But maybe I'm misunderstanding, the wording is a little bit confusing.

As far as I know, this forked client doesn't force you to include a fee.  What makes you think that it does?

So wait, this is called "No Forced TX Fee" but it still forces TX fees in some cases? Is there any client that REALLY doesn't force transaction fees?

Hi Shadow,

This is an interesting fork and I'm going to read through the thread in more detail.  I have an interest in forwarding small bitcoin amounts between addresses where low fees are more important than timeliness.

If I understand correctly, there are typically currently more transactions spots available per block than are currently being used, so is there any reason that a transaction with the minimum fees will not get incorporated in to the next block?  I'm not sure why there would be any delay if this is the case, and from blockchain.info, all the blocks appear to be under 1M in size.  Any insight here?

Anyways, please correct me if I'm wrong, but I guess I have to find some way to have a huge number of small, old coins in reserve to both keep the minimum priority for each transaction above 57.6 M and each transaction under 1 kB in order to have the network process a transaction with a 0 fee.

Cheers,

Erik

No, it does not.  That is the original intended design of bitcoin whether you want it to be or not. Bitcoin is a voluntary system.  You are not forced to use it, nodes are not forced to relay, miners are not forced to confirm.


You have a better suggestion on how to prevent denial of service attack?


Mining (transaction processing) IS a business.


There is no way to guarantee that the rest of the network knows about every transaction that your node knows about.  There may not have been "ample transactions" at the time that the block was created, but there may be "ample transactions" by the time your node receives the block.  How will your node know how many transactions existed at the time of block creation?  More transactions may come in after the miner starts mining the block, how would you handle such a situation.  Platitudes will get you nowhere. You need to come up with real solutions to real problems, otherwise all your pontificating is just useless noise.


Without a high enough difficulty, blocks will be created too fast, and there will be a rediculous number of orphaned blocks.  Less than a few hundred confirmations will become meaningless since there will be so many forked chains and orphaned blocks.


Right, just like everyone will pay transaction fees right now to be able to spend what they earned?  You want others to pay for what you want to use now, why would it be any different in the future?


Mining is transaction processing.  If you want transactions processed, then miners (transaction processors) are needed.


Block limit is currently 1 MB.  Given average transaction size, I think we can fit about 4,200 transactions per block.  Are you suggesting that fees are worthless unless you have $42,000 in fees per block?  Maximum block size may increase in the future.  If maximum block size is increased to 10 MB, then bitcoin would be able to fit about 42,000 transactions per block.  Are you suggesting that fees are worthless unless you have $420,000 in fees per block?


I think you are mistaken on that.  Have you even tried the math behind it, or are you just spouting off numbers that you like and assuming that because you like them they must fix all problems?

Love your efforts. I stopped using wallets, except for mining, so this is great.

You can't "lose" coins... They either send, or expire.

If your wallet does not see them after they expire, it needs to be "repaired".

However, unless blocks become "full", there should not be any discrimination for "free tx's", ever. That defeats the purpose of the whole network. There is no excuse for discrimination like that. Saying it is for security is like saying you won't allow large transactions, to stop theft. It is not a solution, it is not the purpose of the "transaction processor". Bitcoin is not a business, it is a service. The ones doing the processing should be rejected for blocks, if they fail to "fill a block", when there is ample transactions waiting to fill the block. Free or paid.

If the point comes, at the end of the cycle, when TX-fees MAY be required... Then they should ultimately be enforced. However, difficulty could be zero, so any open wallet could use CPU power for a transaction, and miners would not actually be needed. Why would they do it for free... Because if they want to be able to spend what they earned, they will do it at a cost. Miners are NOT needed for the future of bitcoins and processing.

Fees are already essentially worthless, unless you have a full block full of thousands of $10 fees.

They should have simply made the minimum fee 0.00000001 for all transactions, and then just made bigger blocks as needed. That would have simply solved everything. Well, that and faster block-times.

2014-01-26 Update:

NFTF - version 0.8.6 released.

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

MASTER branch was updated to the last tag (0.8.6).

Well, it would seem i have to retest my fork for these new conditions.
For now, i will keep updating. When majority is already using new rules, i will check if there is a point in continuing my fork.

Transactions without the minimum fee will not be relayed. They will not be stored in the memory pools of miners. They will not be included in blocks. As they are ignored, a proper fee double-spend transaction will be included promptly.

The minimum fee rules have been simplified in 0.8.6, which is the network majority. A fee is no longer required just because any one output is smaller that 0.01 BTC (dust < 5.6mBTC invalid rule takes care of spam), but the minimum fee is now required for any transaction over 1kB in size. This is in addition to the requirement that input priority less than 57.6M (1 BTC, 144 blocks old; 0.01 BTC ~100 days old) include minimum fee.

The network is currently a hybrid of old rules and new rules, and some Bitcoins may also be altered from defaults by network members.

If users are inclined to throw caution to the wind and try this out, please back up your wallet.dat immediately before transmitting a transaction. It is much easier to restore a wallet backup than to repair your wallet to remove the will-never-confirm spent coin transaction.

What I am worried about is that the relaying nodes (not mining nodes) will keep broadcasting the transaction forever, and thus - it will be stuck in a limbo.

However you should be able to fix such transaction using Raw Transactions API by rebroadcasting it with a (larger) fee.

Somebody with greater knowledge of Bitcoin-QT code should step in here to clarify that.

I don't have a citation for you. It was asked on this forum and I learned from that. nodes aren't fond of keeping around transactions that can't be mined because the fee is too small. The only reason it sticks around is because -qt keeps broadcasting it over and over again in vain. I can tell you that pywallet supports removing transactions from wallet.dat file for this very reason:

https://bitcointalksearch.org/topic/guide-delete-your-0unconfirmed-transactions-in-30-seconds-35214

This is not what i referred to.
I refrerred to the part of your answer which stated that "it worries you that i don't know that there is no chance of losing coins".

Sure I don't know, because I have not studied the Bitcoin-QT code in detail - I didn't need that in order to create my fork.

Are you sure about that ? Won't some other nodes keep relaying the transaction so it will be forever stuck in a limbo ?
Is there a time limit for how long a transaction can be kept in memory before it becomes obsolete & is removed ?

[Citation needed] Actually i would like to see a citation (or a snippet of code) for that. I don't have time to study the whole code.