Fragmentation of bitcoins

[david123]

Hi all,

I have a question: If I understand it correctly, all bitcoins initially come in chunks of the size of the
block reward, so at the moment in 25btc chunks. If I have such a chunk and want to send
just 1 btc to someone, this chunk is split into two. If I happen to get this 1btc refunded,
this will not merge back into a 25-btc chunk but I will hold two chunks then, one 24 and one 1 btc.
This would not matter if there were not the fees.. It is much more expensive to send 25 btc
which are made up of say 100 small transactions than to send a block reward chunk in one
piece, right?

So, if this is how it works, in the end, inevitably, most balances will consist of
lots of tiny micro-chunks which makes transactions big, hence costly. Also, if I have
to send 1 btc to someone but I don't like him, I could send it in chunks of 5000 satoshis
each (or whatever is the minimum amount). I know this is costly for me, but it will
be equally costly for him to use this 1 btc. Is this right?

Thanks for any comment

[shorena]

Yes, it is more expensive (in KB thus in fees) to have many small inputs.


No, the newly generated output (e.g. 1 BTC) from many (e.g. 100) small inputs will be a single output. So you can spend this newly created 1 BTC as a single input. In a sense you melted all the former pennies and now have a new coin worth 1 btc.

[david123]

Ah, thanks, this calms me down a little.
But, still: If I don't like someone I owe 1btc, I can send him houndreds of 5000 satoshi transactions, maybe
time shifted so that they are not taken into a single output. He might merge this into 1 "proper" btc,
but it will be very costly for him to do so, and there's no way around.
This still seems a bit unsatisfying to me..

[DannyHamilton]

Hi all,

I have a question: If I understand it correctly, all bitcoins initially come in chunks of the size of the
block reward, so at the moment in 25btc chunks. If I have such a chunk and want to send
just 1 btc to someone, this chunk is split into two. If I happen to get this 1btc refunded,
this will not merge back into a 25-btc chunk but I will hold two chunks then, one 24 and one 1 btc.
This would not matter if there were not the fees.. It is much more expensive to send 25 btc
which are made up of say 100 small transactions than to send a block reward chunk in one
piece, right?

So, if this is how it works, in the end, inevitably, most balances will consist of
lots of tiny micro-chunks which makes transactions big, hence costly. Also, if I have
to send 1 btc to someone but I don't like him, I could send it in chunks of 5000 satoshis
each (or whatever is the minimum amount). I know this is costly for me, but it will
be equally costly for him to use this 1 btc. Is this right?

Thanks for any comment

As shorena has pointed out,

A transaction can have less outputs than inputs.  This has the effect of combining the smaller "chunks", as you describe them, into larger "chunks".

As an example, I might have in my wallet:

• a 1 BTC "chunk"
• a 0.25 BTC "chunk"
• a 2.15 BTC "chunk"
• a 0.003 BTC "chunk"
• a 0.0014 BTC "chunk"
• a 0.0003 BTC "chunk"

If I need to send 1.1547 bitcoins to a friend, my wallet might choose to use all except the 2.15 BTC "chunk" as inputs to the transaction, creating a single 1.1547 chunk that my friend now has in his wallet, and a 0.1 BTC chunk as change back into my wallet.

[DannyHamilton]

Ah, thanks, this calms me down a little.
But, still: If I don't like someone I owe 1btc, I can send him houndreds of 5000 satoshi transactions, maybe
time shifted so that they are not taken into a single output. He might merge this into 1 "proper" btc,
but it will be very costly for him to do so, and there's no way around.
This still seems a bit unsatisfying to me..

Correct.  "faucets" do this all the time.

Your choice as a receiver is to refuse to provide what every you are exchanging for the bitcoins if someone intentionally creates too many outputs.  Inform the sender that you will charge them a 10000 satoshi "processing fee" for every 6 outputs you receive after the first 7 outputs for a given expected payment.

[david123]

Ok, thanks for clearing that up.

Still, I cannot deny that I find this a bit dissatisfactory. One could argue that it is a disadvantage when compared
to other payment methods that every transaction might incur some "hidden fees" for the recipient, which he must
assess before giving away the service/good in question.

Does someone have a ballpark figure how much these hidden fees could be in the worst case? Like, if I really send one
btc in 5000sat transactions, how much would it cost to merge that?

[DannyHamilton]

Ok, thanks for clearing that up.

Still, I cannot deny that I find this a bit dissatisfactory. One could argue that it is a disadvantage when compared
to other payment methods that every transaction might occurr some "hidden fees" for the recipient, which he must
assess before giving away the service/good in question.

Bitcoin isn't just a payment system.  It is also a currency.  Think of it a bit like walking into a store and making a $1000 purchase, while trying to pay with 100,000 pennies.  The recipient needs to asses what he is receiving before deciding if he is going to accept such a payment.

Does someone have a ballpark figure how much these hidden fees could be in the worst case? Like, if I really send one
btc in 5000sat transactions, how much would it cost to merge that?

Worst case, (such as with many of the "faucets" out there) the fees can be higher than the total amount received.

In the example you've given the recipient would be receiving 1 / 0.00005 = 20,000 outputs.  If that recipient was using compressed key addresses and tried to spend all 20,000 outputs at once in a transaction with a single output, the transaction would be approximately:

10 bytes of transaction overhead + (20,000 inputs * 143 bytes) + (1 output * 34 bytes) = 2.8 megabytes (give or take 20 kilobytes).

Since the current maximum size of a block is only 1 megabyte, it wouldn't be possible to send such a transaction, but lets assume that in the future the maximum transaction size and maximum blocksize are increased.  With a fee of 0.0001 BTC per kilobyte, the total fee to send the transaction would be approximately 0.28 BTC (give or take 0.002 BTC).

Of course, the sender wouldn't be able to get their transactions confirmed without paying a fee. With a fee of 0.0001 BTC per transaction, sending 20,000 separate transactions each with a 0.00005 BTC output would require the sender to pay 2 BTC in fees to send the 1 BTC.  Meanwhile, a reasonably knowledgeable recipient is going to require at least a 0.30 BTC "processing fee".  This means the sender will have to send at least 2.3 BTC to receive their 1 BTC product or service.

[david123]

Nice, thanks for explaining. Also, I'm quite convinced by

Bitcoin isn't just a payment system.  It is also a currency.  Think of it a bit like walking into a store and making a $1000 purchase, while trying to pay with 100,000 pennies.  The recipient needs to asses what he is receiving before deciding if he is going to accept such a payment.

Still, I see the payment-system-aspect of bitcoin as our biggest advantage towards mass adoption, so
I just hope that this hidden fee stuff will not lead to any nasty situation. The risk doesn't seem high, though..

[behindtext]

since the blockchain is essentially a WORM filesystem, this fragmentation issue will obviously become a bigger issue in the future.

it does make me smile to think that at some point people will see messages like "Your wallet is being slow, would you like to defragment your wallet?".