Topic: Do you want to pay the fee? - page 3. (Read 6894 times)
how many confirmations are usually needed on blockchain for bitcoins? like 2 btc's or 12 btcs moved to a paper wallet??
If less people are mining, will the difficulty go down? And if the difficulty goes down, does that mean that fees become more profitable for miners? Shouldn't that equal things out?
(NOTE: I HAVE EDITED THIS. IT GIVES CORRECT INFORMATION NOW)
Okay, first thing:
12 bytes plus 204 per input plus 32 per output is not misinformation.
And it's also pretty much obscured in the so called documentation so nobody can get it without chasing down multiple pages and obscure clues. That isn't misinformation either.
And I used the term "Coin" because "unspent txouts" is Martian and I was trying to explain it to non Martians. And I explained it the first time I used it and when someone confused it with value in bitcoins I explained it again. I will not call that misinformation.
For everything except for my immediate previous post I wasspeaking approximately DEAD WRONG and ignoring the free transactions that people whose wallets are full of dust won't get anyway. You could call that misinformation if you want to but people who try to spend dust will find it close enough to true that they can't tell the difference. WAS APPROXIMATE AT BEST, IGNORED RULES THAT GOVERN FREE TRANSACTIONS, AND OVERSTATED FEES IN MOST CASES BY ABOUT A FACTOR OF TEN.
And in the post right before you accused me of lying I laid it outaccurately WRONG BY A FACTOR OF TEN and in great detail.
So I'ma little bit upset about the accusations and I won't repudiate the advice I gave DEAD WRONG ABOUT FEES AND DEEPLY REGRETFUL FOR ANY ANXIETY I HAVE CAUSED. You can I WILL go through and make the figures exact if you want to AS PENANCE FOR MY STUPIDITY but don't call anyone a liar unless you provide the complete truth.
Okay, first thing:
12 bytes plus 204 per input plus 32 per output is not misinformation.
And it's also pretty much obscured in the so called documentation so nobody can get it without chasing down multiple pages and obscure clues. That isn't misinformation either.
And I used the term "Coin" because "unspent txouts" is Martian and I was trying to explain it to non Martians. And I explained it the first time I used it and when someone confused it with value in bitcoins I explained it again. I will not call that misinformation.
For everything except for my immediate previous post I was
And in the post right before you accused me of lying I laid it out
So I'm
Fees are needed to pay miners for their work in securing the network.
If miners don't work, transactions won't ever confirm anymore.
So you just have to pay miners enough for them to keep on confirming transactions.
0.0000001 or 0.05, all depends on what the miners think is acceptable.
If you don't agree, just mine and setup your own fee policy.
/thread.
If miners don't work, transactions won't ever confirm anymore.
So you just have to pay miners enough for them to keep on confirming transactions.
0.0000001 or 0.05, all depends on what the miners think is acceptable.
If you don't agree, just mine and setup your own fee policy.
/thread.
WAIT A MINUTE.. so can I still get a fast transaction with sending 12 btc's to a paper wallet with only a 0.0005 fee? or 0.005?? 
Now why do you all come up with $40 fee charges? people are sending 1 million dollars of bitcoins and they pay a 1 dollar fee?? I don't understand? when you say 0.005 fee does that actually mean 0.005% they are charging you out of your 12 bitcoins?
Now why do you all come up with $40 fee charges? people are sending 1 million dollars of bitcoins and they pay a 1 dollar fee?? I don't understand? when you say 0.005 fee does that actually mean 0.005% they are charging you out of your 12 bitcoins? 
I can see fees becoming a scammers dream.
Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.
This is incorrect. Even if the transaction is from many txouts in the sender's wallet (and they have to pay a larger fee), you will be receiving a single consolidated payment for the amount.Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.
The only instance where "buyer pays fees" may be services where you withdraw a balance from your account on an exchange or pool to your wallet. Professionals manage their wallets so amplified fees don't occur.
I can see fees becoming a scammers dream.
Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.
Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.
Please excuse if this has been asked before but quite a while back I mined 1.10024 coins through pools over a period of several weeks receiving payments on average of 0.01xxxxxxx to 0.02 coins.
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?
If you want to spend 0.5 Bitcoins, (say, $500) and that takes you 30 to 50 of the size coins you've got, you'll be paying 25 to 38 dollars in transaction fees. That's more reasonable than the situation the OP is faced with, but still damned annoying.
Like you say the OP is fucked basically and in my scenario nearly fucked as I doubt I would have used all that electric to mine had I known, I believed the "minimal fees" hype that everyone was flouting. It appears to me that Bitcoin is running into the realms of a currency of the wealthy ie. those who can buy whole coins, which will no doubt deter new users coming into the fold.
Could it not be built into the system that small fragments that are kept in a wallet for a certain length of time after x notifications are coalesced into larger units?
Read, understand:
http://we.lovebitco.in/how-bitcoin-works/transactions/
A transaction is composed of inputs, also known as unspent transaction outputs - individual previous payments that were received by a wallet, either to the same address or to multiple wallet addresses.
Those previous payments are then used as needed to fulfill the balance of a payment you may want to send. Here is a some examples of real transactions, demonstrating how large a transaction may be, based on the number of inputs it uses:
- 1 input: 257-259 bytes - 1x minimum fee
- 5 inputs: 976-980 bytes - 1x minimum fee
- 8 inputs: 1514 bytes - 2x minimum fee
- 39 inputs: 5848 bytes - 6x minimum fee
Lets make the most extreme example possible: you signed up for some scam-faucet that paid you what we would call "dust", useless payments of 0.00006 (nearly the minimum allowed to be sent, a few pennies). Then the fees would be a significant portion of a payment:
- 0.00006 x 39 = 0.00234
- minimum fee 0.0001 * 6kB = 0.00060
You can see that even dust is still spendable. For transactions that aren't bloat-by-design, the minimum fee will not be a multiplier of the minimum or a significant amount.
To answer the question, users can manage and consolidate their own coins. When you send your next payment, you can add another recipient, yourself, and send the balance of your wallet back to a new wallet address to solve the dust problem in the most efficient manner.
(NOTE: THIS POST HAS BEEN CORRECTED! ALL THE PEOPLE WHO AFTERWARDS SAY THAT IT GAVE WRONG INFORMATION WERE RIGHT AND I WAS WRONG. I HAVE EDITED THIS TO BE CORRECT SO THAT IT WON'T MESS PEOPLE UP IN THE FUTURE. ALSO SEE THE TOP OF PAGE 5 FOR THE CORRECT PROCEDURE TO DETERMINE FEES WITHOUT THE RANTING ABOUT POOR DOCUMENTATION I DID BELOW.)
Let me see if I get this:
First you have to figure out how big your transaction is, using a formula that the wiki never tells you. It took hours of reading and guessing and searching the wiki to figure out what the formula is.
I will tell you now, but it took the rest of this post to figure it out. It's 12 bytes, plus 204 bytes per input, plus 32 bytes per output. If it's more than 256 inputs or outputs, add one byte. If there's anything even a little bit unusual about the "scripts" involved for any input or output, this formula is not valid. Remember that your transaction usually has at least one more output than is visible; this is because you don't usually have exact change, and the transaction must split at least one of your coins (and may consolidate others) to come back to you.
Second, figure out your transaction's "priority" using a stupidly complex formula that they don't tell you how to calculate.
The formula is given as priority = sum(input_value_in_base_units * input_age)/size_in_bytes.
But I use input value in millibitcoins instead, to save the bother of dealing with five unnecessary decimal positions.
In order to figure out what it means for a given transaction, you must first multiply the value of each input in millibitcoin times the number of days since it was paid to you, add all the products together to get a sum, convert the number of inputs/outputs in your transaction to size_in_bytes, then divide the sum by the size_in_bytes which they did not tell you how to calculate.
Your transaction is "free" if all of the following are true.
* it's smaller than 10,000 bytes. (but they didn't tell you how to figure that out)
* All the outputs are 0.01 BTC (currently around $8) or larger.
* priority is greater than 576. (and you couldn't know that without being able to figure out the size)
(Note: when dev guys talk about "priority" they'll add five zeros onto the end. I've simplified the formula so you don't have to).
Your transaction is also "free" if its priority is higher than the priority of all other transactions in the block except for enough other transactions to make 27,000 bytes (BUT YOU HAVE NO IDEA WHETHER OTHER HIGHER-PRIORITY TRANSACTIONS ARE GOING INTO THIS BLOCK, AND THEY DON'T TELL YOU HOW TO CALCULATE THE SIZE IN BYTES OF YOUR TRANSACTION OR GUESS AT THE SIZE IN BYTES OF OTHER TRANSACTIONS OR TELL YOU WHAT IS TYPICAL NUMBER OF FREE TRANSACTIONS YOU'RE COMPETING FOR SPACE WITH).
Now, if your transaction qualifies as "free" it will be propagated across the network without fees. But the reference client will not spend more than 15,000 bytes per minute on propagating such transactions (AND YOU HAVE NO WAY OF KNOWING HOW THAT AFFECTS RELIABILITY AND SPEED WITHOUT KNOWING WHAT THE TYPICAL TRAFFIC IN FREE TRANSACTIONS IS AND/OR HAVING THE RESULTS OF EMPIRICAL MEASUREMENTS).
If your transaction is not "free" you had better add a transaction fee. To figure out the transaction fee you need to find the size of your transaction, round it up to the next even multiple of a thousand, then multiply the result by1 0.1 microbitcoins.
And the final gotcha: if you have to add another input, or more than one other input, in order to cover the transaction fee, then the size of your transaction in bytes has changed, and you must start over and figure out your fee again. And if you get your fee even one Satoshi wrong, then most clients will just drop your transaction on the floor instead of propagating it and you'll have absolutely no benefit from the fee you did add. If your transaction confirms at all it may take days, and the fee will have been a complete waste of your money.
********** STOP READING HERE UNLESS YOU WANT TO KNOW HOW I FIGURED OUT HOW TO FIND THE SIZE OF TRANSACTIONS *******
Does that about sum it up? Clear as mud? What's that? Still have unanswered questions about the size of your transaction which was the first thing you had to figure out?
Okay, going to https://en.bitcoin.it/wiki/Transactions, we can start to figure out how to find the size of a transaction in bytes.
it is 8 bytes, plus the size of the input count, plus the size of the output count, plus the number of inputs times the size of an input, plus the number of outputs times the size of an output. Nice and simple, right? questions answered, right?
oh, wait; THEY DON'T TELL YOU ON THAT PAGE WHAT THE SIZE OF AN INPUT OR THE SIZE OF AN OUTPUT OR THE SIZE OF THE INPUT COUNT OR THE SIZE OF THE OUTPUT COUNT IS.
Okay, going to https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer we find the size of the input count and the size of the output count. You're going to laugh. If the number of inputs is less than 0xfd it's one byte. Add another 2 bytes if the number of inputs is more than 0xfd and *another* two bytes if the number of inputs is more than 0xffff. The number of outputs is given the same way. For those who don't speak Martian, those numbers are 0xfd=254 and 0xffff = 65536. Because Martians count in base 16, that's why.
For any "normal" transaction, call that 12 bytes plus the number of inputs times the size of an input plus the number of outputs times the size of an output. But if you're using "dust" (more than 254 inputs) it can be 14 bytes rather than 12, so keep that in mind.
The size of an input is given at https://en.bitcoin.it/wiki/Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin.
It's 40 bytes plus another Martian number plus the size of the in-script.
The size of an output is given right below it. It's 8 bytes plus another Martian number plus the size of the out-script.
And the size of the Martian numbers depends on the size of the in-script and the out-script. BUT THEY DON'T TELL YOU ON THAT PAGE HOW TO FIND THE LENGTH OF THE SCRIPT.
Okay, it looks like scripts are almost universally less than 0xfd long, so the Martian numbers are going to be one byte long unless there is something really weird going on. That makes inputs 41 bytes plus the size of the in-script, and outputs 9 bytes plus the size of the out-script.
Going to https://en.bitcoin.it/wiki/Script, we find that the "standard" script consists of
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG. all of the OP_whatever are 1 byte, so this is 4 bytes plus the length of a pubKeyHash which is 20 bytes. Total is 24 bytes.
And it doesn't say ANYWHERE I can find whether this is the standard for an in-script or the standard for an out-script. You really need to know in order to figure out how big your transaction is in bytes. According to their example however, which I can read because I can read Martian, this has to be the standard for an out-script. So each "output" of your transaction, if it's a normal transaction, is 32 bytes - a nice round number, in Martian.
Now, an in-script is mentioned nowhere in the whole damn wiki, except on the page that says you need to know how big it is to figure out the size of your transaction and then doesn't define it. However, back on the Transactions page in an earlier link, it says that the "ScriptSig" is the "first half of a script" and that's the only mention of a script anything in the inputs of a transaction so it's pretty much got to be it. It also says that a "ScriptSig" consists of a signature and a public key. Okay, great. The size of an input is 41 bytes plus the size of a signature plus the size of a public key. Going back to the protocol specification, we find out that the size of a signature is two 32-byte integers plus a prefix 04 (presumably one byte). So, probably 65 bytes. But it can be given in a "compressed form" where one of the 32-byte numbers is replaced by a "sign" telling whether it is even or odd. The "sign" is 0x2 or 0x3 - again presumably one byte, so the compressed form is 33 bytes. So a signature is either 33 or 65 bytes, and we don't know which, making our input 74 or 106 bytes plus the size of a public key. I couldn't find anything on the wiki defining the number of bytes in a public key, so that's a dead end. However, there is a transcript of a Martian conversation on the protocol specification page that actually mentions a scriptsig and says that it's 139 bytes long.
139 plus either 65 or 33 bytes is 204 bytes or 172 bytes. Neither of those is a particularly "round" number in Martian. Nor does it tell in English anywhere which of them you should use. But, when I searched for "33" there was nothing interesting on the wiki and when I searched for "65" I found the page https://en.bitcoin.it/wiki/OP_CHECKSIG with a transcript of a Martian statement where it actually checks an input signature, and that signature is in fact 65 bytes long. Taking that as the norm, we conclude that each input is then 204 bytes long.
So, after a lot of chasing and assumptions and guesswork and reading in Martian where it's not given in English, the formula for the size of your transaction is the following:
12 bytes, plus 204 bytes per input, plus 32 bytes per output.
I'd put this formula into the damn wiki, except they want me to pay ten bucks for the privilege.
Okay, not spreading "misinformation" any more.
Let me see if I get this:
First you have to figure out how big your transaction is, using a formula that the wiki never tells you. It took hours of reading and guessing and searching the wiki to figure out what the formula is.
I will tell you now, but it took the rest of this post to figure it out. It's 12 bytes, plus 204 bytes per input, plus 32 bytes per output. If it's more than 256 inputs or outputs, add one byte. If there's anything even a little bit unusual about the "scripts" involved for any input or output, this formula is not valid. Remember that your transaction usually has at least one more output than is visible; this is because you don't usually have exact change, and the transaction must split at least one of your coins (and may consolidate others) to come back to you.
Second, figure out your transaction's "priority" using a stupidly complex formula that they don't tell you how to calculate.
The formula is given as priority = sum(input_value_in_base_units * input_age)/size_in_bytes.
But I use input value in millibitcoins instead, to save the bother of dealing with five unnecessary decimal positions.
In order to figure out what it means for a given transaction, you must first multiply the value of each input in millibitcoin times the number of days since it was paid to you, add all the products together to get a sum, convert the number of inputs/outputs in your transaction to size_in_bytes, then divide the sum by the size_in_bytes which they did not tell you how to calculate.
Your transaction is "free" if all of the following are true.
* it's smaller than 10,000 bytes. (but they didn't tell you how to figure that out)
* All the outputs are 0.01 BTC (currently around $8) or larger.
* priority is greater than 576. (and you couldn't know that without being able to figure out the size)
(Note: when dev guys talk about "priority" they'll add five zeros onto the end. I've simplified the formula so you don't have to).
Your transaction is also "free" if its priority is higher than the priority of all other transactions in the block except for enough other transactions to make 27,000 bytes (BUT YOU HAVE NO IDEA WHETHER OTHER HIGHER-PRIORITY TRANSACTIONS ARE GOING INTO THIS BLOCK, AND THEY DON'T TELL YOU HOW TO CALCULATE THE SIZE IN BYTES OF YOUR TRANSACTION OR GUESS AT THE SIZE IN BYTES OF OTHER TRANSACTIONS OR TELL YOU WHAT IS TYPICAL NUMBER OF FREE TRANSACTIONS YOU'RE COMPETING FOR SPACE WITH).
Now, if your transaction qualifies as "free" it will be propagated across the network without fees. But the reference client will not spend more than 15,000 bytes per minute on propagating such transactions (AND YOU HAVE NO WAY OF KNOWING HOW THAT AFFECTS RELIABILITY AND SPEED WITHOUT KNOWING WHAT THE TYPICAL TRAFFIC IN FREE TRANSACTIONS IS AND/OR HAVING THE RESULTS OF EMPIRICAL MEASUREMENTS).
If your transaction is not "free" you had better add a transaction fee. To figure out the transaction fee you need to find the size of your transaction, round it up to the next even multiple of a thousand, then multiply the result by
And the final gotcha: if you have to add another input, or more than one other input, in order to cover the transaction fee, then the size of your transaction in bytes has changed, and you must start over and figure out your fee again. And if you get your fee even one Satoshi wrong, then most clients will just drop your transaction on the floor instead of propagating it and you'll have absolutely no benefit from the fee you did add. If your transaction confirms at all it may take days, and the fee will have been a complete waste of your money.
********** STOP READING HERE UNLESS YOU WANT TO KNOW HOW I FIGURED OUT HOW TO FIND THE SIZE OF TRANSACTIONS *******
Does that about sum it up? Clear as mud? What's that? Still have unanswered questions about the size of your transaction which was the first thing you had to figure out?
Okay, going to https://en.bitcoin.it/wiki/Transactions, we can start to figure out how to find the size of a transaction in bytes.
it is 8 bytes, plus the size of the input count, plus the size of the output count, plus the number of inputs times the size of an input, plus the number of outputs times the size of an output. Nice and simple, right? questions answered, right?
oh, wait; THEY DON'T TELL YOU ON THAT PAGE WHAT THE SIZE OF AN INPUT OR THE SIZE OF AN OUTPUT OR THE SIZE OF THE INPUT COUNT OR THE SIZE OF THE OUTPUT COUNT IS.
Okay, going to https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer we find the size of the input count and the size of the output count. You're going to laugh. If the number of inputs is less than 0xfd it's one byte. Add another 2 bytes if the number of inputs is more than 0xfd and *another* two bytes if the number of inputs is more than 0xffff. The number of outputs is given the same way. For those who don't speak Martian, those numbers are 0xfd=254 and 0xffff = 65536. Because Martians count in base 16, that's why.
For any "normal" transaction, call that 12 bytes plus the number of inputs times the size of an input plus the number of outputs times the size of an output. But if you're using "dust" (more than 254 inputs) it can be 14 bytes rather than 12, so keep that in mind.
The size of an input is given at https://en.bitcoin.it/wiki/Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin.
It's 40 bytes plus another Martian number plus the size of the in-script.
The size of an output is given right below it. It's 8 bytes plus another Martian number plus the size of the out-script.
And the size of the Martian numbers depends on the size of the in-script and the out-script. BUT THEY DON'T TELL YOU ON THAT PAGE HOW TO FIND THE LENGTH OF THE SCRIPT.
Okay, it looks like scripts are almost universally less than 0xfd long, so the Martian numbers are going to be one byte long unless there is something really weird going on. That makes inputs 41 bytes plus the size of the in-script, and outputs 9 bytes plus the size of the out-script.
Going to https://en.bitcoin.it/wiki/Script, we find that the "standard" script consists of
OP_DUP OP_HASH160
And it doesn't say ANYWHERE I can find whether this is the standard for an in-script or the standard for an out-script. You really need to know in order to figure out how big your transaction is in bytes. According to their example however, which I can read because I can read Martian, this has to be the standard for an out-script. So each "output" of your transaction, if it's a normal transaction, is 32 bytes - a nice round number, in Martian.
Now, an in-script is mentioned nowhere in the whole damn wiki, except on the page that says you need to know how big it is to figure out the size of your transaction and then doesn't define it. However, back on the Transactions page in an earlier link, it says that the "ScriptSig" is the "first half of a script" and that's the only mention of a script anything in the inputs of a transaction so it's pretty much got to be it. It also says that a "ScriptSig" consists of a signature and a public key. Okay, great. The size of an input is 41 bytes plus the size of a signature plus the size of a public key. Going back to the protocol specification, we find out that the size of a signature is two 32-byte integers plus a prefix 04 (presumably one byte). So, probably 65 bytes. But it can be given in a "compressed form" where one of the 32-byte numbers is replaced by a "sign" telling whether it is even or odd. The "sign" is 0x2 or 0x3 - again presumably one byte, so the compressed form is 33 bytes. So a signature is either 33 or 65 bytes, and we don't know which, making our input 74 or 106 bytes plus the size of a public key. I couldn't find anything on the wiki defining the number of bytes in a public key, so that's a dead end. However, there is a transcript of a Martian conversation on the protocol specification page that actually mentions a scriptsig and says that it's 139 bytes long.
139 plus either 65 or 33 bytes is 204 bytes or 172 bytes. Neither of those is a particularly "round" number in Martian. Nor does it tell in English anywhere which of them you should use. But, when I searched for "33" there was nothing interesting on the wiki and when I searched for "65" I found the page https://en.bitcoin.it/wiki/OP_CHECKSIG with a transcript of a Martian statement where it actually checks an input signature, and that signature is in fact 65 bytes long. Taking that as the norm, we conclude that each input is then 204 bytes long.
So, after a lot of chasing and assumptions and guesswork and reading in Martian where it's not given in English, the formula for the size of your transaction is the following:
12 bytes, plus 204 bytes per input, plus 32 bytes per output.
I'd put this formula into the damn wiki, except they want me to pay ten bucks for the privilege.
Okay, not spreading "misinformation" any more.
So much bad information. Why do you make these things up?
It's really not that difficult. Detailed info for the reference client here:
https://en.bitcoin.it/wiki/Transaction_fees
mintxfee has historically been lowered to be less than $0.1
It's really not that difficult. Detailed info for the reference client here:
https://en.bitcoin.it/wiki/Transaction_fees
mintxfee has historically been lowered to be less than $0.1
Trouble with those wiki articles is they are written by people who know bitcoin inside out and make little sense to someone with no technical knowledge.
Please excuse if this has been asked before but quite a while back I mined 1.10024 coins through pools over a period of several weeks receiving payments on average of 0.01xxxxxxx to 0.02 coins.
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?
If you want to spend 0.5 Bitcoins, (say, $500) and that takes you 30 to 50 of the size coins you've got, you'll be paying 25 to 38 dollars in transaction fees. That's more reasonable than the situation the OP is faced with, but still damned annoying.
Like you say the OP is fucked basically and in my scenario nearly fucked as I doubt I would have used all that electric to mine had I known, I believed the "minimal fees" hype that everyone was flouting. It appears to me that Bitcoin is running into the realms of a currency of the wealthy ie. those who can buy whole coins, which will no doubt deter new users coming into the fold.
Could it not be built into the system that small fragments that are kept in a wallet for a certain length of time after x notifications are coalesced into larger units?
could there be a situation where bitcoins which has a shorter history are worth more than ones with a longer history?
Minimum fee in the reference client will likely be lowered everytime the the exchange rate rises. Minimum fee:
A typical transaction only pays minimum fee. In some cases (I would call those expert use), the fees may be higher (one time fees for consolidating balances).
Miners can make their own rules. That means they could include transactions with lower than minimum fee or even no fee. The price of bitcoin is based on supply and demand, and so is the transaction fee! Make it worth it for the miner to include a transaction and it will be included.
A typical transaction only pays minimum fee. In some cases (I would call those expert use), the fees may be higher (one time fees for consolidating balances).
Miners can make their own rules. That means they could include transactions with lower than minimum fee or even no fee. The price of bitcoin is based on supply and demand, and so is the transaction fee! Make it worth it for the miner to include a transaction and it will be included.
Such a complicated topic. I wish I was more studied on these aspects of computing. People out of the loop will be the last to know when bitcoin runs into trouble, and we won't be able to sell our coins before it's too late and the price has crashed to 0. This, ofcourse, is assuming that things and fees can't be fixed...
So if bitcoin rises to 10k USD, people paying 10 dollars for something will have to pay a 1-5 dollars in fees??
I don't think bitcoin will survive very long unless these payments happen off the blockchain...
Bitcoin wouldn't survive with off-the-chain transactions neither.I don't think bitcoin will survive very long unless these payments happen off the blockchain...
The current, simple payment system is one of bitcoins strengths and it has to work for bitcoin to be successful.
An intermediary between user and blockchain would make a simple and strong system complicated and weak and took away the original reason for bitcoins existence.
But I think we will see urgent changes in the protocol in the next months. Hopefully.
so can someone clarify this 0_o Is it a 0.0005 fee 70 cents or whatever it is or what??
So if bitcoin rises to 10k USD, people paying 10 dollars for something will have to pay a 1-5 dollars in fees??
I don't think bitcoin will survive very long unless these payments happen off the blockchain...
I don't think bitcoin will survive very long unless these payments happen off the blockchain...
So much bad information. Why do you make these things up?
It's really not that difficult. Detailed info for the reference client here:
https://en.bitcoin.it/wiki/Transaction_fees
mintxfee has historically been lowered to be less than $0.1
It's really not that difficult. Detailed info for the reference client here:
https://en.bitcoin.it/wiki/Transaction_fees
mintxfee has historically been lowered to be less than $0.1
Wait a minute, Do I get charged a fee for importing the balance into blockchain??!! What if I only sent small amounts such as keep 12 at a time in my blockchain wallet and only 2 at a time to a paper wallet? why can't I get away with only pay 0.0005 in fees like it was before??? or maybe it was 0.005 (whatever it was)
Guess you cant o_0.
It is a major downer. I hope problems like this do not kill the currency. I for one really believe in it, but I can also foresee some real scams coming out.
Imagine you have a wallet with 10 BTC. These 10 BTC are made up of 1,000 parts of 0.01 BTC. You could show someone this and "sell" them the wallet address for money. When they try to transfer this to their own wallet, they'll be shocked to find that the TX fee was over 10%.
Hopefully fees can get lowered again, but if fees get too low once the miners are done mining coins... could be the end of bitcoin as we know it!
Also imagine once lifecoin runs out of coins, and they realise everyone stops mining? Will that news automatically kill bitcoin?
It is a major downer. I hope problems like this do not kill the currency. I for one really believe in it, but I can also foresee some real scams coming out.
Imagine you have a wallet with 10 BTC. These 10 BTC are made up of 1,000 parts of 0.01 BTC. You could show someone this and "sell" them the wallet address for money. When they try to transfer this to their own wallet, they'll be shocked to find that the TX fee was over 10%.
Hopefully fees can get lowered again, but if fees get too low once the miners are done mining coins... could be the end of bitcoin as we know it!
Also imagine once lifecoin runs out of coins, and they realise everyone stops mining? Will that news automatically kill bitcoin?
Jump to: