No, it's quite apparent most miners just aren't thinking about block sizes at all.
Jim is correct. The right solution to this is for miners to make bigger blocks. Bitcoin is still tiny. Having people "fight" for block space via fees today is ridiculous. Rather than telling people to set higher fees, go talk to miners and tell them that you're sometimes having problems with transactions taking a long time to confirm. Or better yet, build visualisations so miners can see it for themselves.
Topic: Setting tx fee manually (Read 1614 times)
There are a few other reasons why transactions can take a while - it is not just fees.
+ if you have any unconfirmed inputs those have to confirm first (regardless of the fee you pay)
+ if you have any unconfirmed inputs those have to confirm first (regardless of the fee you pay)
About 5-10% of the hashing power does child-pays-for-parent fee evaluation, so paying a fee on the child acts as a fee for the parent.
+ miners are creating blocks of size up to 330 KB - a lot are smaller. This is somewhere around 600 transactions. If you look on blockchain.info in their stats there are about 60K transactions per day. So the volume of tx is, say, 100 completely full blocks.
There are typically 150 blocks in a day so if the network is busy tx will start getting 'bumped'. Miners could mine larger blocks if they wanted. Increasing your fee makes your tx more attractive but bumps someone else down the list. Raw capacity is the real solution.
There are typically 150 blocks in a day so if the network is busy tx will start getting 'bumped'. Miners could mine larger blocks if they wanted. Increasing your fee makes your tx more attractive but bumps someone else down the list. Raw capacity is the real solution.
Remember that the larger the block you create, the higher your orphan rate and the less money you make as a miner. Blocks up to nearly the 1MB limit have been created recently, but for the most part pools appear to have decided that they make more money with smaller blocks, and there's no simple way to add capacity.
Blockchain space is after all a limited resource in the Bitcoin system and that limited resource is subject to supply and demand pricing. By not implementing the ability to set fees you shut your users out of that market.
There isn't a quick answer to be honest.
It won't make any difference changing those parameters in the multibit.properties files (which I don't recommend as you can break things).
There are a few other reasons why transactions can take a while - it is not just fees.
+ if you have any unconfirmed inputs those have to confirm first (regardless of the fee you pay)
+ miners are creating blocks of size up to 330 KB - a lot are smaller. This is somewhere around 600 transactions. If you look on blockchain.info in their stats there are about 60K transactions per day. So the volume of tx is, say, 100 completely full blocks.
There are typically 150 blocks in a day so if the network is busy tx will start getting 'bumped'. Miners could mine larger blocks if they wanted. Increasing your fee makes your tx more attractive but bumps someone else down the list. Raw capacity is the real solution.
I have put in the use cases for the next version of MultiBit to put in a slider (or something similar) so that users can tweak the fee per KB.
The current code I don't really want to prioritise as there are plenty of other things to work on.
It won't make any difference changing those parameters in the multibit.properties files (which I don't recommend as you can break things).
There are a few other reasons why transactions can take a while - it is not just fees.
+ if you have any unconfirmed inputs those have to confirm first (regardless of the fee you pay)
+ miners are creating blocks of size up to 330 KB - a lot are smaller. This is somewhere around 600 transactions. If you look on blockchain.info in their stats there are about 60K transactions per day. So the volume of tx is, say, 100 completely full blocks.
There are typically 150 blocks in a day so if the network is busy tx will start getting 'bumped'. Miners could mine larger blocks if they wanted. Increasing your fee makes your tx more attractive but bumps someone else down the list. Raw capacity is the real solution.
I have put in the use cases for the next version of MultiBit to put in a slider (or something similar) so that users can tweak the fee per KB.
The current code I don't really want to prioritise as there are plenty of other things to work on.
So what was the answer ?
I posted the same question earlier (should have spotted this thread) but its becoming quite serious , hours & hours for the majority of transactions and it makes no dif if its 25btc or .25 , iv tried changing the setting in the .properities to sendFee=0.0005 (well it was already set there) but it just will not change from 0.0001 and it driving me mad
surely others using this wallet have the same problem ?
I dont know what to do, i would change wallet but i dont know how to migrate all my addresses / keys , if there is no way to change this without coding it myself which i might stand a chance of doing but not particularly quickly and besides im busy with trading then that would be great if not i hope migrating my keys is not to hard.
Real pity.
Thx.
I posted the same question earlier (should have spotted this thread) but its becoming quite serious , hours & hours for the majority of transactions and it makes no dif if its 25btc or .25 , iv tried changing the setting in the .properities to sendFee=0.0005 (well it was already set there) but it just will not change from 0.0001 and it driving me mad
surely others using this wallet have the same problem ?I dont know what to do, i would change wallet but i dont know how to migrate all my addresses / keys , if there is no way to change this without coding it myself which i might stand a chance of doing but not particularly quickly and besides im busy with trading then that would be great if not i hope migrating my keys is not to hard.
Real pity.
Thx.
This is a bit more like it !
You can fork the MB code, set bounties, have assurance contracts for functionality you want implemented.
The code is there to be used.
It is intentionally licenced as MIT so that you can do anything with it.
A nice implementation of, say, a slider where you can ramp up the fee per KB in the preferences would be a great pull request.
You can fork the MB code, set bounties, have assurance contracts for functionality you want implemented.
The code is there to be used.
It is intentionally licenced as MIT so that you can do anything with it.
A nice implementation of, say, a slider where you can ramp up the fee per KB in the preferences would be a great pull request.
Ah good - a pull-request, perhaps in conjunction with an "Advanced" mode or at least an "Advanced" release, seems like the sanest way to handle such differences in UI philosophy.
This is a bit more like it !
You can fork the MB code, set bounties, have assurance contracts for functionality you want implemented.
The code is there to be used.
It is intentionally licenced as MIT so that you can do anything with it.
A nice implementation of, say, a slider where you can ramp up the fee per KB in the preferences would be a great pull request.
You can fork the MB code, set bounties, have assurance contracts for functionality you want implemented.
The code is there to be used.
It is intentionally licenced as MIT so that you can do anything with it.
A nice implementation of, say, a slider where you can ramp up the fee per KB in the preferences would be a great pull request.
Good grief people - the whole client is open source.
If you want something changed you have the power.
Certainly. And if we were able to code and compile C++ we could just write our own client.If you want something changed you have the power.
But that's not what we're talking about here. I just want to send a payment to someone and be sure it's included in the next block. I can't afford to spend days to learn and test how to compile my own version of the fine Multibit client. But that's just me!
In the Bitcoin world, the customer is always wrong.
I think that should be a slogan somewhere. I recommend using the daemon in the Satoshi client. Once you get the hang of it there is no better way to build your transactions. Also your friends will totally think you passed Computer Science III. Feel free to PM me if you need some help
So, are you telling me there is no user friendly way to change the fee?
If so (with all respect), I must consider the client unusable. We cannot afford guesswork whether the transaction will be included in a block an hour or a day away from now. Other than that critical issue, multibit was a fine client.
If so (with all respect), I must consider the client unusable. We cannot afford guesswork whether the transaction will be included in a block an hour or a day away from now. Other than that critical issue, multibit was a fine client.
Good grief people - the whole client is open source.
If you want something changed you have the power.
I have no use for MultiBit myself, but a "MultiBit Advanced" that let you set fees sounds like a useful fork. I do use the Android Bitcoin Wallet, and if anyone wants to go to the effort of releasing a "Bitcoin Wallet Advanced" with the ability to set fees I'll pledge 1 BTC. (I'd prefer it if you get it into the app store too)
Certainly. And if we were able to code and compile C++ we could just write our own client.
But that's not what we're talking about here. I just want to send a payment to someone and be sure it's included in the next block. I can't afford to spend days to learn and test how to compile my own version of the fine Multibit client. But that's just me!
In the Bitcoin world, the customer is always wrong.
But that's not what we're talking about here. I just want to send a payment to someone and be sure it's included in the next block. I can't afford to spend days to learn and test how to compile my own version of the fine Multibit client. But that's just me!
In the Bitcoin world, the customer is always wrong.
Note my bounty above; might be worth thinking about getting a few more people in and hiring someone to do it. I'd be happy to do the technical evaluation of any code written, and I think some other people I know would be willing to lend a hand too.
Good grief people - the whole client is open source.
If you want something changed you have the power.
Certainly. And if we were able to code and compile C++ we could just write our own client.If you want something changed you have the power.
But that's not what we're talking about here. I just want to send a payment to someone and be sure it's included in the next block. I can't afford to spend days to learn and test how to compile my own version of the fine Multibit client. But that's just me!
In the Bitcoin world, the customer is always wrong.
This is the minimum tx structure being accepted by the network currently. Your tx should confirm but when the network is busy it can obviously be bumped to a later block. There is only so much space in a block.
So, are you telling me there is no user friendly way to change the fee?If so (with all respect), I must consider the client unusable. We cannot afford guesswork whether the transaction will be included in a block an hour or a day away from now. Other than that critical issue, multibit was a fine client.
Good grief people - the whole client is open source.
If you want something changed you have the power.
This is the minimum tx structure being accepted by the network currently. Your tx should confirm but when the network is busy it can obviously be bumped to a later block. There is only so much space in a block.
So, are you telling me there is no user friendly way to change the fee?If so (with all respect), I must consider the client unusable. We cannot afford guesswork whether the transaction will be included in a block an hour or a day away from now. Other than that critical issue, multibit was a fine client.
Disappointing to hear that MultiBit has gone down the same obnoxious path that the Android Wallet has; I've heard people local to me that do face-to-face trades recommend that you stay away from the Android Wallet for the same reason because of how long it can take to get a transaction confirmed at minimum fee.
FWIW those people don't find anything unintuitive or surprising about the idea that by paying more money you can get faster service/higher priority by miners. Again, the feedback I've gotten is that paying a fee of $0.1 or even $1 on a $1000 transfer is something many consider to be a "no-brainer" even if it means they're paying 20x or even 200x the theoretical minimum - the fee is so low compared to all the other costs that it's just not worth caring about.
This is the minimum tx structure being accepted by the network currently. Your tx should confirm but when the network is busy it can obviously be bumped to a later block. There is only so much space in a block.
So, are you telling me there is no user friendly way to change the fee?If so (with all respect), I must consider the client unusable. We cannot afford guesswork whether the transaction will be included in a block an hour or a day away from now. Other than that critical issue, multibit was a fine client.
ah, so the blank properties file is where it loads the config file..(user prefs) good explanation.i think I get it now
When multibit starts up it wants to load its configuration.
This is things like what language to use, which wallets are open.
Normally it looks in a 'user data directory'. This varies by operating system but is a specific directory for any particular user.
When you want to run locally you create an empty multibit.properties 'next' to where the executable is.
Multibit checks for a local copy of the properties file and will use thst if it exists.
Everything has a default e.g. 'use English' so the fact that it is initially empty does not matter.
This is things like what language to use, which wallets are open.
Normally it looks in a 'user data directory'. This varies by operating system but is a specific directory for any particular user.
When you want to run locally you create an empty multibit.properties 'next' to where the executable is.
Multibit checks for a local copy of the properties file and will use thst if it exists.
Everything has a default e.g. 'use English' so the fact that it is initially empty does not matter.
you mention adding a blank .properities to run locally on thumb drive(according to directions)...does this just auto use the local comps settings by import..i don't get it
The transaction fee algorithm is no longer just a straight fee, but rather:
+ 0.0001 BTC/ KB of transaction
+ small change outputs are not produced, which stops a tx being relayed now, but added to the fee and the change output disappeared.
This is the minimum tx structure being accepted by the network currently. Your tx should confirm but when the network is busy it can obviously be bumped to a later block. There is only so much space in a block.
I don't advise editing the multibit.properties file directly as it can produce unwanted sideeffects or break things.
+ 0.0001 BTC/ KB of transaction
+ small change outputs are not produced, which stops a tx being relayed now, but added to the fee and the change output disappeared.
This is the minimum tx structure being accepted by the network currently. Your tx should confirm but when the network is busy it can obviously be bumped to a later block. There is only so much space in a block.
I don't advise editing the multibit.properties file directly as it can produce unwanted sideeffects or break things.
How do I set the transaction fee on Windows XP Multibit 5.14? It remains 0.0001 in the spend screen even when multibit.properties shows sendFee=0.0005 and previousSendFee=0.0005, and client is restarted. Transactions get easily stuck unconfirmed if the fee is 0.0001, thus rendering Multibit unusable for me at the moment.
Jump to: