The problem now becomes how to refund the initial transaction fee of the failed bids.
You haven't removed the problem, you've just made the amounts concerned smaller.
And you have doubled the bitcoin transaction fees you need to pay.
And every Mastercoin transaction has to pay a small amount to you (the Exodus address) for the privilege?
So each transfer has to pay Bitcoin fees*2 plus a small Exodus fee?
(Actually Bitcoin fees*3 , as the seller presumably needs another transaction to actually move the Mastercoins.)

If you are writing off your mining equipment as a tax loss, I'm sure you are also paying taxes on Bitcoin earned as either income or capital gains, yes?

No.
They might claim they can do it.
That is not, in any way, the same as demonstrating that they can do it.
You have claimed you can compress any file by 90%+. You have not demonstrated that you can do it.

No, not dead.
The ideologically pure Bitcoin might die, but Bitcoin as a currency won't.


Yup, completely true, I forgot that things in my head weren't available to other people.
I think this sort of consolidation of power is inevitable, as the cost of entry keeps rising, both in hardware terms, and also in regulatory ones.

To elaborate a little, this is what I see happening:

- Mining power get consolidated, as is already happening
- As block reward drops, transaction fees increase
- This starts to make small transactions inefficient
- Mining pools start to offer online wallets, and provide fee-reduced or fee-eliminated transfers between accounts on their own systems
(Which they can do, as they can choose to mine their own low-fee transactions, but not other people's)
- This leads to a few large entities which we might as well call banks at this point
- They control both transaction processing and mining
- Most users, and most merchants, will not want the hassle of running their own clients, and will not want to pay higher fees, so will sign up with one of the 'banks'
- To consolidate their control, interbank arrangements will form, which offer higher fees than intra-bank transfers, but lower than for non-bank accounts
- This will encourage all but the very largest of merchants to move their accounts to the mining 'banks'

At that point, network control is consolidated in a few hands, who can simply enact changes.

If Bitcoin becomes seriously profitable, it will be run by exactly the same sort of people who run all the other seriously profitable systems.

Is that also true of SPV nodes?
I doubt there will be many, if at all, full nodes running that are not connected to mining operations in 10/20/50 years time.
Most people will have online wallets, all that needs to happen is that the wallet provider upgrades, the users don't get a choice.

Exactly. That wouldn't happen if 51% decided to accept them instead.

Think of it from the other point of view, look ahead to the mining reward dropping from 12.5 to 6.25.
There could be hundred of millions of dollars invested in mining equipment by that point.
Difficulty will be so massively high that only huge pools would have any real chance of finding blocks at a consistent rate.
Why wouldn't people vote to pay themselves more money?

The users wouldn't have to switch.
They would have their transactions confirmed (most of the time) by the 51%, because they have more hash power.
Miner rewards are simply an extra transaction included by miners in each mined block.
Currently everyone agrees to use the same formula for calculating them (current 25 BTC per block).
I could decide to mine for myself, and pay myself 100 BTC per block instead, but noone else would accept my blocks, so there wouldn't be much point.
But if over half of the network decide to accept those blocks, those blocks get built into the blockchain, and the new reward structure works.

Controversial: It will never happen.
Ultimately, the people who control things like miner rewards are ... the miners.
If 51% of the hashing power decides to change the rewards, the other 49% has the choice of either going along with it, or forking to their own chain, and having two competing Bitcoins, with theirs being less powerful. 51% means the owners of the 2-4 largest pools.
There will be too many people who have invested too much money in mining equipment, and who have no philosophical attachment to a deflationary currency, to simply accept seeing their income vanish. At the moment, there are still probably too many people with ideological reasons to oppose this for it to work, they would simply switch to different pools. In 10/20/50 years time, that will no longer be the case.
They will find some way to rationalise the decision as being in everyone's best interests, but ultimately turkeys won't vote for Christmas.

I think it would make for a neat 'secret decoder ring' type of encryption, especially for kids learning about maths or computing.
Each byte or byte sequence is assumed to occur in Pi somewhere, so you could encrypt your messages by replacing each byte, pair of bytes, etc... with the corresponding index of that next byte sequence in Pi. Essentially a book cipher, with Pi as the cipher, so no need to share the book.
It will increase, not decrease, the length of your message, but would be a fun computing project.

However you approach it, it is simply impossible to design a lossless compression algorithm that reduces the size of all possible input files given to it.

Encoding all possible one to three byte files using only 62 printable characters gives a total of 426 resulting index values, compared to the 242234 that would be required for full uniqueness.
Of those 426 values, only 26 were uniquely mapped to by a single string.
Lowest used index was 76, highest was 790. (These indexes all start with 1 = the 3 of 3.14).
Most popular index was 517, which was mapped to by 18891 different strings.

The following two letter strings give the same index value as 'Pi', using the new method outlined above:

String: 0M (0011000001001101) Index: 197
String: 0Y (0011000001011001) Index: 197
String: 0e (0011000001100101) Index: 197
String: 0i (0011000001101001) Index: 197
String: 1I (0011000101001001) Index: 197
String: PM (0101000001001101) Index: 197
String: PY (0101000001011001) Index: 197
String: Pe (0101000001100101) Index: 197
String: Pi (0101000001101001) Index: 197
String: QI (0101000101001001) Index: 197
String: rA (0111001001000001) Index: 197

The following single letter strings give the same index as P:
String: 0 (00110000) Index: 110
String: P (01010000) Index: 110

Encoding the same 1.3MB file as before now gives:

After byte 1295988, pi position is 202830581
After byte 1295989, pi position is 202830702
After byte 1295990, pi position is 202830819

So you are now using 157 digits of Pi for each byte encoded, almost exactly the 160 that would be expected.

We have proven it can't work, repeatedly.
You just don't believe us.

I downloaded 1 billion digits of Pi from here: http://stuff.mit.edu/afs/sipb/contrib/pi/
I downloaded the complete works of Gilbert and Sullivan (text format) from here: http://www.gutenberg.org/files/808/

The ~1.3MB file needs just over 100 million digits of Pi to encode.

After byte 1295987, pi position is 103683939
After byte 1295988, pi position is 103684011
After byte 1295989, pi position is 103684099
After byte 1295990, pi position is 103684138

That is almost exactly 80 digits of Pi required for each 1 byte of input files.
(Which is exactly what you would expect.)

So a 100MB file would require 8.4 billion digits of Pi.
A 50GB file would require 4.2 trillion digits of Pi.

The current record for calculating digits of Pi is 10 trillion, and that took 371 days to do, so I think we agree real-time calculation is out of the question?
4.2 trillion digits of Pi require 4.2 trillion bytes to store uncompressed. That is a 4 Terabyte drive just to store Pi to be able to perform your 'compression'.
(Which doesn't work anyway, because it is not reversible.)

A single 5 byte file: "Hello", results is many many more than two million collisions.
There will only ever be more collisions the longer the file is.
A 100MB movie file would result in more collisions than could be saved to a hard drive.

You are going to ignore this, by saying that your theory magically only works on large files not small ones, which conviently means that we can't run a test program to demonstrate you are wrong.
But you are wrong.
If two 5 byte combinations give the same hash, then any pair of files which are exactly the same, except that they each start with a different one of those 5 byte combinations, will also give the same hash.
Making the file bigger just stops us demonstrating that you are wrong, it doesn't make you right.

For the 5 letter input file "Hello", I cancelled the program early on in the search for duplicate encodings, but it had already found almost 2 million five letter words which gave the same Pi index (305). There are 227k words starting with 0 which do.
Hopefully it is clear that this process does not work, as it assigns the same output value to multiple different input files, and therefore there is no way of reconstructing the original input file from just the output index.

On the other hand, you sold items and said they would be delivered in August, and it is now a third of the way through September, and some people haven't got them. It is reasonable of them to feel that you haven't delivered on your promises. Especially as you have diverted hardware that could have gone to them to another part of your business.
This isn't a backorder situation, where people are buying now and know the units aren't available, it was a preorder situation with a delivery promise.

That is a pretty poor analogy.
Paintings and sculture are unique and indivisible.
BTC is neither.
One BTC is just like any other, and they can be subdivided at will.

If anyone else is still reading at this point, and wants to check my working, I think I've demonstrated clearly that this is not a reversible compression scheme.

The two letter word "Pi" gives an index of 148.
The following 156 two letter words also give the same index:
(This is restricted to just printable characters, there could be far more matches using the full 256 combinations for each byte)

String: 0i (0011000001101001) Index: 148
String: 0j (0011000001101010) Index: 148
String: 0l (0011000001101100) Index: 148
String: 1I (0011000101001001) Index: 148
String: 1J (0011000101001010) Index: 148
String: 1L (0011000101001100) Index: 148
String: 8I (0011100001001001) Index: 148
String: 8J (0011100001001010) Index: 148
String: 8L (0011100001001100) Index: 148
String: 9A (0011100101000001) Index: 148
String: 9B (0011100101000010) Index: 148
String: 9D (0011100101000100) Index: 148
String: :A (0011101001000001) Index: 148
String: :B (0011101001000010) Index: 148
String: (0011101001000100) Index: 148
String: <A (0011110001000001) Index: 148
String: <B (0011110001000010) Index: 148
String: <D (0011110001000100) Index: 148
String: @; (0100000000111011) Index: 148
String: @= (0100000000111101) Index: 148
String: @> (0100000000111110) Index: 148
String: @[ (0100000001011011) Index: 148
String: @] (0100000001011101) Index: 148
String: @^ (0100000001011110) Index: 148
String: @k (0100000001101011) Index: 148
String: @m (0100000001101101) Index: 148
String: @n (0100000001101110) Index: 148
String: @y (0100000001111001) Index: 148
String: A9 (0100000100111001) Index: 148
String: A: (0100000100111010) Index: 148
String: A< (0100000100111100) Index: 148
String: AK (0100000101001011) Index: 148
String: AM (0100000101001101) Index: 148
String: AN (0100000101001110) Index: 148
String: AY (0100000101011001) Index: 148
String: AZ (0100000101011010) Index: 148
String: A\ (0100000101011100) Index: 148
String: Ai (0100000101101001) Index: 148
String: Aj (0100000101101010) Index: 148
String: Al (0100000101101100) Index: 148
String: B9 (0100001000111001) Index: 148
String: B: (0100001000111010) Index: 148
String: B< (0100001000111100) Index: 148
String: BK (0100001001001011) Index: 148
String: BM (0100001001001101) Index: 148
String: BN (0100001001001110) Index: 148
String: BY (0100001001011001) Index: 148
String: BZ (0100001001011010) Index: 148
String: B\ (0100001001011100) Index: 148
String: Bi (0100001001101001) Index: 148
String: Bj (0100001001101010) Index: 148
String: Bl (0100001001101100) Index: 148
String: CI (0100001101001001) Index: 148
String: CJ (0100001101001010) Index: 148
String: CL (0100001101001100) Index: 148
String: D9 (0100010000111001) Index: 148
String: D: (0100010000111010) Index: 148
String: D< (0100010000111100) Index: 148
String: DK (0100010001001011) Index: 148
String: DM (0100010001001101) Index: 148
String: DN (0100010001001110) Index: 148
String: DY (0100010001011001) Index: 148
String: DZ (0100010001011010) Index: 148
String: D\ (0100010001011100) Index: 148
String: Di (0100010001101001) Index: 148
String: Dj (0100010001101010) Index: 148
String: Dl (0100010001101100) Index: 148
String: EI (0100010101001001) Index: 148
String: EJ (0100010101001010) Index: 148
String: EL (0100010101001100) Index: 148
String: GA (0100011101000001) Index: 148
String: GB (0100011101000010) Index: 148
String: GD (0100011101000100) Index: 148
String: H9 (0100100000111001) Index: 148
String: H: (0100100000111010) Index: 148
String: H< (0100100000111100) Index: 148
String: HK (0100100001001011) Index: 148
String: HM (0100100001001101) Index: 148
String: HN (0100100001001110) Index: 148
String: HY (0100100001011001) Index: 148
String: HZ (0100100001011010) Index: 148
String: H\ (0100100001011100) Index: 148
String: Hi (0100100001101001) Index: 148
String: Hj (0100100001101010) Index: 148
String: Hl (0100100001101100) Index: 148
String: MA (0100110101000001) Index: 148
String: MB (0100110101000010) Index: 148
String: MD (0100110101000100) Index: 148
String: P9 (0101000000111001) Index: 148
String: P: (0101000000111010) Index: 148
String: P< (0101000000111100) Index: 148
String: PK (0101000001001011) Index: 148
String: PM (0101000001001101) Index: 148
String: PN (0101000001001110) Index: 148
String: PY (0101000001011001) Index: 148
String: PZ (0101000001011010) Index: 148
String: P\ (0101000001011100) Index: 148
String: Pi (0101000001101001) Index: 148
String: Pj (0101000001101010) Index: 148
String: Pl (0101000001101100) Index: 148
String: QI (0101000101001001) Index: 148
String: QJ (0101000101001010) Index: 148
String: QL (0101000101001100) Index: 148
String: SA (0101001101000001) Index: 148
String: SB (0101001101000010) Index: 148
String: SD (0101001101000100) Index: 148
String: UA (0101010101000001) Index: 148
String: UB (0101010101000010) Index: 148
String: UD (0101010101000100) Index: 148
String: YA (0101100101000001) Index: 148
String: YB (0101100101000010) Index: 148
String: YD (0101100101000100) Index: 148
String: ZA (0101101001000001) Index: 148
String: ZB (0101101001000010) Index: 148
String: ZD (0101101001000100) Index: 148
String: \A (0101110001000001) Index: 148
String: \B (0101110001000010) Index: 148
String: \D (0101110001000100) Index: 148
String: `9 (0110000000111001) Index: 148
String: `: (0110000000111010) Index: 148
String: `< (0110000000111100) Index: 148
String: `K (0110000001001011) Index: 148
String: `M (0110000001001101) Index: 148
String: `N (0110000001001110) Index: 148
String: `Y (0110000001011001) Index: 148
String: `Z (0110000001011010) Index: 148
String: `\ (0110000001011100) Index: 148
String: `i (0110000001101001) Index: 148
String: `j (0110000001101010) Index: 148
String: `l (0110000001101100) Index: 148
String: aI (0110000101001001) Index: 148
String: aJ (0110000101001010) Index: 148
String: aL (0110000101001100) Index: 148
String: cA (0110001101000001) Index: 148
String: cB (0110001101000010) Index: 148
String: cD (0110001101000100) Index: 148
String: eA (0110010101000001) Index: 148
String: eB (0110010101000010) Index: 148
String: eD (0110010101000100) Index: 148
String: iA (0110100101000001) Index: 148
String: iB (0110100101000010) Index: 148
String: iD (0110100101000100) Index: 148
String: jA (0110101001000001) Index: 148
String: jB (0110101001000010) Index: 148
String: jD (0110101001000100) Index: 148
String: lA (0110110001000001) Index: 148
String: lB (0110110001000010) Index: 148
String: lD (0110110001000100) Index: 148
String: qA (0111000101000001) Index: 148
String: qB (0111000101000010) Index: 148
String: qD (0111000101000100) Index: 148
String: rA (0111001001000001) Index: 148
String: rB (0111001001000010) Index: 148
String: rD (0111001001000100) Index: 148
String: tA (0111010001000001) Index: 148
String: tB (0111010001000010) Index: 148
String: tD (0111010001000100) Index: 148

In fact, even with the single character 'P', there are three other printable characters with the same index:
String: B (01000010) Index: 74
String: D (01000100) Index: 74
String: P (01010000) Index: 74
String: ` (01100000) Index: 74