The answer is yes, it has been done many times.  The fee depends on the size of the transaction in bytes, not the amount of value being sent.  Therefore, if the transaction is a small number of byte (from a single address to a new single address) the transaction fee would be minimal.

Not true.

The mining reward does go to zero after is it one satoshi per block.

This will happen in about the year 2140.

I am pretty good with Excel (see here)

But I do not understand your question.  Can you be more specific about exactly what you want to do?

Very first post.

Wants BTC for PP.

Now that is funny.  Thanks, I needed a good laugh today.

Historically wasn't the original design to send to the public key as the destination - there was no hash in the original design?

Then, in order to save space, the whole hashing to a public address was added on top?

That was my understanding - which is often flawed when it comes to esoteric history.

Assuming we stick to the 64 bit size for a value, keep the 21 million Bitcoin cap, and we expand to the maximum number of decimal points offered by a 64 bit number we could comfortably expand the resolution to

2⁶⁴ = 18,446,744,073,709,551,616
      =   2,100,000,000,000,000,000 "millisatoshis"

So a factor of 1000 or about 2¹⁰

So that would lead to about 2⁶¹ addresses containing a millisatoshi each.

Unless it is directly related to the subject of this thread, for example the fact there can currently be only 3 transactions per second so how long would it take to burn through 2⁵⁵ addresses at only 3 TPS, any posts that stray into "block size debate" territory will be immediately deleted.  There are enough threads about that subject already.

Yes, your meaningless claim took time and energy.

Counting also takes time and energy.

Prove me wrong.

Proving me wrong will also take time and energy.

Correct.

First you would pay the tax on your income/profit during mining.  In your example you would pay tax on:

  [(40.5 BTC) x (the price at the time mined)] - (all expenses of mining including equipment depreciation)

Then when you sold them at a higher price you would need to pay taxes on the capital gains:

  (40.5 BTC) x [(price at the time of sale) - (the price at the time you mined them)]

There are only 2,100,000,000,000,000 satoshis.

Therefore the maximum number of Bitcoins addresses that can contain value at any one time is only about 2⁵¹ and that assumes only one satoshi per address.

At the time the block chain contains 2⁵⁵ transactions it would be somewhere between a petabyte and an exabyte in size.  So a full node would need a multi petabyte drive to store the entire block chain.

This thread has been totally trashed by signature spammers.

I have started a thread for serious discussion about the application of the birthday problem to the 160 bit hash space of Bitcoin.

Please join the signature spam free discussion here:  https://bitcointalk.org/index.php?topic=1895455.0

I may copy a few of the interesting posts from this thread over there.

gmaxwell:  Thanks Greg for your answer.  Sorry I accidentally deleted your post in my LBC delete fest.

LBC:  This thread was never intended to be about LBC.  I wish I had never mentioned it at all.  I have gone back and deleted the posts specifically about the merits/failings of LBC.

The thread is over unless anyone has comments about the application of the birthday problem to the hash space of Bitcoin.

Specifically, is the math presented in the OP correct?  Is this a real concern?

Please see my related thread here:  https://bitcointalk.org/index.php?topic=1895455.0

(no asshole signature spammers in my thread!)

Please see my related thread here:  https://bitcointalk.org/index.php?topic=1895455.0

Please see my related thread here:  https://bitcointalk.org/index.php?topic=1895455.0

The birthday problem can be applied to estimate the probability of a collision given the size of a hash function.

The Taylor series expansion of the exponential function can be used to estimate the probability of a collision as follows:

    p(n, d) = 1 - e^{-n(n - 1)/(2d)}

where n is the number of hashes and d is the total number of possible hashes.

Given a hash function size of h in bits and a number of Bitcoin addresses generated 2^x this can be simplified as follows:

    p(n, d) = 1 - e^{-2x(2x - 1)/(2(2h))}

               = 1 - e^{-(22x - 2x)/(2h + 1)}

               = 1 - e^{-[22x/(2h + 1) - 2x/(2h + 1)]}

               = 1 - e^{-(22x - h - 1 - 2x - h - 1)}

Within the limits of my Excel spreadsheet for h = 160 the probability of a collision for various values of x is:

This yields the interesting result that after "using up" only 2⁸³ out of our 2¹⁶⁰ Bitcoins addresses we will almost certainly have one or more address collisions.  In fact we really only want to "use up" about 2⁵⁵ Bitcoin addresses in order to keep the probability of a collision very near to zero (within the limits of the estimation function, my simplification, and the resolution abilities of the Excel spreadsheet).

How fast can we use up or generate 2⁵⁵ addresses?  

Well as of this posting the large bitcoin collider project has already sequentially searched the first 2^52.19 Bitcoin addresses and is on track to search the first 2^54.46 addresses within a year.  Given some serious resources to attack the problem, orders of magnitude more addresses could be generated and checked per year.

This thread is not about the merits or failing of the LBC so posts related to the LBC will be deleted.  I only use the maximum key generation rate of the LBC as an example of how fast keys can be created.

So far the LBC has had a peak key generation rate of about 2.5 x 10⁹ key pairs per second.  That is about

   (3.154 x 10⁷)(2.5 x 10⁹) = 7.885 x 10¹⁶

   or approximately 2⁵⁶ key pairs per year.

If we were to move from the current 160 bit Bitcoin address to a new system that would fully utilize all 256 bit available for Bitcoin addresses the situation is much better:

In this case we should be able to safely use up to 2¹⁰³ Bitcoin addresses before collisions would be a problem.

I think we should discuss phasing out the old 160 bit Bitcoin address version and replacing it with a new 256 bit address version.

I am currently writing a thread related to the the Bitcoin address space and need to know something about your project:

What is the maximum key generation rate you have every recorded, even for a short period of time?

Thanks!

Please see my related thread here:  https://bitcointalk.org/index.php?topic=1895455.0

In the US:

Mining income is taxed as ordinary income at the price on the day and at the time you mine the coins.

Profit/Loss while trading is taxed as a capital gain or loss.

I have paid the income tax on all the coins I have mined and the capital gains tax on all of my trading.

^^ POS sig spammer reported

Go to hell sig spammer.  Reported.

In fact I am going to go back and report every one of you assholes in this thread.  I hope you all get perm bans.