Bitcoin Forum

I have set up another computer and so a second wallet just to play around a little. Now on the second wallet I mined 0.05 BTC and I wanted to transfert them to my primary wallet. The clients says I need to pay a transaction fee. But I heard, that its possible to transfer BTC *without* paying a fee. How does that work?  ???

vanilla client, can't do it(well sometimes...).
modify and compile your own.

Well we need something more than the very helpful "modify and compile your own".

I am sure somebody already build a derivative client that does not charge for TX fees.

What about a SC client that does not give many TX fees to King RealScam ?

Just wait.  Coins gain priority with age.  If they have sufficient priority there will be no transfer fee (some non applicable exceptions apply). 

And how long does this normaly take?

I usually had to wait around 3 days

Good to know. Thank you! :)

The exact time depends on the value of each address and time.

The formula the client uses is:


If priority is >57,600 there is no transaction fee.

Basically it works out to 1 day for 1 BTC.   Larger addresses (not total wallet value) require less time, smaller addresses require more time.

You can always import the private key into your new wallet.

Yes.  You can search for pywallet, install it and use that to import the private keys into your main wallet, instead of sending the BTC via a transaction.

It does not work with windows, or does it?  :-\


Ahm, how do i calculate this?
My client shows the number of confirmations, the date, the 0.05BTC a description. What now?  ???

Works anywhere python is installed.
Install python, download pywallet to a folder, run python pywallet.py in terminal

Satoshi's client version 0.3.20 (and all previous ones) does not impose any fee.

Choose your favorite from here: http://sourceforge.net/projects/bitcoin/files%2FBitcoin/ (http://sourceforge.net/projects/bitcoin/files%2FBitcoin/)

You've got to be careful. The fee isn't 'imposed' to harm you. If you send without a fee when the current version wants it other nodes may consider your tx to be spam and not forward it.

.001 cent is pretty cheap to pay to prove you actually care about the tx getting processed. 

It's a bad idea to keep using an older version no matter what. For example, newer versions can do wallet encryption, while older versions can't. Apart from that there may be bugs in older versions which would have been fixed in the version you're not using, and you will miss out on new features that may become important to bitcoin in general.

There's also the thing FreeMoney mentioned just now:

Not forwarded ever, or will it just take a long time?
And does the protocol allow for something like "Send 0.003BTC without any fee, but if it hasn't been processed within 30 blocks, return it to my wallet"? That would have been a nice feature.

The bitcoin protocol can do something like what you describe, but the standard client can not do this. It will just keep waiting until it's processed, and you can't "reclaim" it.

The current vanilla client doesn't refuse to forward the transaction, but most miners are not going to include the transaction until it's old enough to qualify as a free transaction.  I believe that the current client defaults to a transaction fee, but that can be changed in the settings.  The vanilla client will refuse to create a transaction based upon an input transaction that is newer than 6 confirmations old.

Yes, but that set of features is based upon the transaction 'scripting' which is not implimented yet.  And even when it is, I can't imagine that miners are going to be willing to process a scripted transaction without a fee.

Oh, my bad. I was sure that it was the others won't forward it. So a modified client can flood the network? Everyone will forward? Reference to a thread about the current state of this would be much appreciated.

I can't give you a reference, because I'm no more inclined to use the search function than you seem to be.  A modified client could only flood the network to a point, because there is a limit to the number of unique transactions any given client could produce from any given wallet.dat before it was forced to attempt to double-spend (which an honest client will not even try to do) and any transaction that attempts to spend coins that another transaction before it has legitimately tried to spend will be rejected as invalid, and not forwarded for that reason.  Since even a modified client can't send coins to himself that he has already sent to himself without the first transaction being included into a block, the 'spamming' of the network can only proceed at a pace dictated by the rate at which blocks are created and miners include free transactions into blocks.  Since free transactions generally require aging, such costless spamming is severely restricted.  A fee paying transaction would likely be included in each block, but the costs of spamming would be born by the spammer, and eventually he would run out of funds.

This is an interesting detail for me. Is there a discussion going on somewhere on how to develop on this mechanism? How does the fee count into the equation?

For the network it is bad to have too many transactions and this priority is an effective flood protection ... to a certain extent. With 1M BTC I can still produce 1M transactions per day which is about 50MB  (if I don't do weird 1000 addresses to 1000 addresses transactions (http://blockexplorer.com/b/134334) which might cost the basic fee) per day. For free.

Wouldn't it make sense to completely ignore the input value and take the transaction size for a fixed fee? From the user perspective we want to charge for the service which does not depend on the wealth being transferred but only on the effort to note down some numbers.

Each kB (which is about 2 transactions) will get stored forever on at least 10k computers and not only on the one miner's computer that accept it in the first place. 1kB*10k equals to something like 10MB web space which in turn would justify to charge 0.001$ or 0.0003BTC wouldn't it?
(A TB costs about 20BTC. A kB therefore costs 0.00002BTC=20uBTC.)
Which arguments go against such a fixed fee? With the 50BTC reward we have now, you can easily make it 2uBTC with both a flood-protection effect and a long time model removing all this uncertainty about fees.

Although I myself promoted Bitcoin as a tool for micropayment, it is and will never be fit to be that on a large scale. With 10uBTC fee for my transactions I could still do pretty small payments.

Continuing on that thought why should only the miner who packs a ridiculously large transaction into the block chain be rewarded while all miners have to live with it? I suggest to add all fees to a fee pool in the block chain and miners are allowed to reclaim 1% of that fee pool. Miners would then have an incentive to not build on chains containing blocks like this one (http://blockexplorer.com/b/134334). 330kB for 46 transactions and 0.24BTC fee mostly from old clients 0.02BTC as I suppose.

The Bitcoin network has no idea what the useful portion of the transaction size is.  It only knows a transaction has x as the total input and y as the total output( including the unidentified change address).  The fee is x -y.

I don't understand. Ok, there is no "<fee>xy BTC</fee>" in the block. Maybe. Still the fee exists and clients and miners can calculate it.
Right now
the miner can decide what to do with any coins left over from all the transactions in "his" block, including the generation "transaction".
My suggestion was that
the miner can decide what to do with 1% of the coins left over from all the transactions in "his" and all prior blocks, including the generation "transaction". Within each transaction, the input must be bigger than the output by a magnitude of 20uBTC per kB the transaction takes in raw format.

I misunderstood what you were saying.

Yes that would work.   Gavin has indicated the current fee structure isn't intended to be "fair" or generate sufficient revenue to run the network.  Fees will need to change and the block subsidy declines.  The current fee structure is just intended to prevent malicious use of the network.  Think of it as a "payment captcha".

Longer term a more robust fee structure will be necessary.  The network has "real" and significant costs.  Those costs have to be paid for.   Currently it is 99% paid for by block subsidies but that will continually decline and by 2030 there will be no block subsidies.  A fee structure that is low but fair and generates sufficient revenue is a necessity.

It was my understanding that miners were not required to include any transactions in the blocks they process - they like to process fee-paying transactions for their own financial benefit, and that they process no-fee transactions only out of the goodness of their hearts (and a desire to see Bitcoin flourish.)

Is this accurate? And if so, is the 'priority' of older transactions only a recommendation, or are miners eventually required to process old, no-fee transactions?

Yes


Miners are not required to process anything.  Technically if a miner wanted to be an ass they could mine empty blocks. :)

One thing is that if a transaction requires a fee because its priority is too low many miners will exclude it, also nodes will not forward transactions they consider invalid and thus many miners may never see the transaction.

The problem w/ fee structure longer term is there is absolutely no reason for a miner to exclude even a 1 satoshi transaction (unless the block is full).  Including = 1 satoshi in revenue, excluding = no revenue.  Nodes not forwarding isn't much of an issue as one could write a client that sends transactions directly to the major pools and bypass any nodes which would block the transaction.

So under current fee rules the fee per transaction will aproach 1 satoshi.  Current block subsidies are about 2,628,000 BTC per year.  If fees aproach 1 satoshi then to support the current network in fees would require 2.6M / 1E-8 = 260 trillion transactions per year.  That is about 8M tps (transactions per second).  To put it into perspective VISA average volume is ~4K tps and peak volume is ~10K tps. 

Obviously fees need to be higher than 1 satoshi per transaction to support the network.  We have plenty of time but some equitable solution to share the cost of running the network needs to be devised.  That is at a high level what we are talking about with fees.  What set of "rules" most fairly distributes the cost of running the network among the participants.

Clarification here: https://bitcointalk.org/index.php?topic=51081.0

But how can it even be known if a fee is "required" ? Isn't that dependent on the policy of whoever mines the next block, so it is unknown?

And since miners can choose for themselves which transactions they will include, and they will most likely make their decision based only on what gets them the highest fees, what is the function of "priority" as mentioned in this thread?





I don't understand this - so the priority will increase when the transaction hangs around longer without getting into a block? Aren't transaction fees paid when the transaction is first sent, when you have no idea how long it is going to hang around before getting into a block?

There really needs to be a way to re-submit a transaction with a different (larger) fee, and have the previous transaction(s) ignored.

There is.  It just isn't implemented in the mainline client.  The protocol supports multiple versions for the same transaction. 

I did not know that.  Thank you.

I mean required per the mainline client rules.  Sure miners can put free transactions in blocks that should require a fee but honestly why would miners do that again?

Currently the only purpose for fees is to avoid malicious transactions.  Period.  Bitcoin is a work in progress (including the fee structure).  The purpose of priority is to organize transactions of the same fee size in the event their is insufficient room in the block.  For example if there isn't enough room in a block for all free transactions those with higher priority will be confirmed first.

Today block subsidies are massive compared to fees and blocks are 99% empty.  There is no reason to every pay a fee for anything other than if the transaction has insufficient priority and thus miners won't include it for free.  Period.  Obviously that will change in the future but today fees exist solely to prevent malicious transactions.

The age in the formula is the age of the COINS not the transaction.  Yes coins keep getting older until transferred but at the time you submit a transaction you know exactly how old they are.  If the priority (based on age & coin size) is too low you need to pay a fee.  If you don't pay a fee then miners may exclude your transaction.

Remember this exists solely to prevent malicious transactions by making spam too expensive to be used effectively.

Oh! Interesting! So I can broadcast several transactions that are in conflict and clients will not drop those that arrive later?
While at first I thought that sounded like facilitating double spending, it is actually pretty decent in order to detect double spendings :)

(I love bitcoin. Something to learn every day.)

Yes and no.  The versioning of a delayed transaction is only possible with the scripting mech, which doesn't actually exist in the mainline client yet.  So at present, the answer is no.  Also, scripting won't ever be free, becase you are asking miners to actually process something for you personally.  Expect higher fees for scripted transactions, but once implimented, scripted transactions will be able to do a great many cool things, many of which don't really have any direct equivilant in the real world.  Multiplely addressed coins is one of them.  You will be able to send the same coins to more than one address, and dictate to the future network that those coins can only be used again under your stated conditions.  For example, you could send them to a set of addresses, and require that the claiming address have an additional keycode; so it's like you are putting up a prize for a compatition.  Or you could require that more than one of the addresses must sign the next transaction, requiring that more than one of the recipents have to get together to spend the coins.  There are a number of ways that this scripting mech can be used to create escrowed transactions.

Sorry to threadbump, but I still have a question about this:


Are the following statements true?

Priority is not meaningful at all right now, as blocks are nowhere near full.

The priority calculation is a thing that is built into some mining software, but not necessarily used by all miners.

A transaction paying a higher transaction fee will never have a higher priority than a transaction paying a lower fee.

No, because there is a minimum priority level for a transaction to be included into a block at all.  In practice, this means that a fee paying transaction gets a much higher priority than a free transaction, and a free transaction must have inputs of a certain age in order to be processed.  This not only limits spam, it encourages senders to add a small fee to the transaction for speed, particularly if the inputs used are very recent.


True, miners are not required to honor the priority system to process otherwise valid transactions.


False, I think.  I'm pretty sure that the priority number is something along the lines of ((number of confirmations for the newest input transaction included in the present transaction) + (transaction fee in BTC * arbitrary priority multiplier)) in which case, the higher the fee paid, the higher the priority number.

Thanks, Moonshadow.

I mistyped my last sentence - I meant to say "A transaction with a lower transaction fee will never have a higher priority than a transaction with a higher transaction fee."

A transaction containing tenthousand inputs with a small fee, might have a lower priority than a 1-to-1 transaction with no fee.

Well, this is also false.  It's possible for a free transaction with all inputs very deep in the blockchain to have a higher priority than a transaction that pays the minimum fee with very recent input transactions.