Topic: Is Mastercoin bloating the blockchain and what we can do about it? (Read 10263 times)

There was a lot of critics about the Mastercoin network, in particular due to the many generated un-prunable transactions that are necessary to transmit the data between Mastercoin users.

I have an idea how to solve this problem, but this would require some changes to the protocol. Basically, instead of sending Bitoins to a data address without known private key (which is the current Mastercoin implementation), data can also be transmitted by sending Bitcoins to addresses that other Bicoin users own. To do so, a 'directory' of addresses has to be generated first. Each address can store a few bytes of data - and by sending tiny amounts of Bitcoins to these addresses, the pieces of data can be connected (similar to the current Mastercoin implementation). In this presented implementation, each address can store about 3 bytes. Therefore, to have enough data for a Mastercoin transaction, about 6 - 12 Bitcoin transactions have to be sent.

However, there is an important advantage in this implementation: Users that 'own' these addresses can later send all their earned Bitcoins to a single address. As a result, the millions of addresses are fully spent, and the whole system becomes prunable.

In contrast, in the current Mastercoin system, all the data addresses will remain with 0.00006 BTC stored and have to be saved in the blockchain forever.


Here's the implementation:

First, a global list of length 58^4 = 11316496 and width = 30 is created, and each cell can contain a Bitcoin-address. Let us index these cells with (n,#). The size of the list is a few GB, which is well managable to keep in lots of copies among all Mastercoin users.

Now to the actual idea: The cells (1,#) must contain addresses with the last four characters being -1111. The cells (2,#) must contain addresses -1112, and so on. Finally, the cells (11316496,#) must contain addresses with the last 4 characters -zzzz.

Now, every Bitcoin user that finds a key pair can publish the corresponding address in this list. To this end, he has to prove that he owns the private key of this address, to prevent people 'scamming' the list. Assumed, he found an address ending with -1113, he publishes it and it will be written into cell (3,1). Now let's assume > 29 other users also find addresses ending with -1113 and publish them. Then, all these addresses are alphabetically ordered and written into cells (3,1), (3,2), ... (3,30). Addresses with index > 30 are discarded. Obviously, with time, it becomes harder and harder to 'win' a cell in the list, because an address with low alphabetical index has to be found to kick out another one.

Since it is attractive for users to 'own' cells in the list, the time will come the list is complete, meaning that every cell has an address written in it. Of course, after completing the list, new addresses with lower index can still be published, and the list will be continuously updated.

Last, how can a string of data be transmitted?
First, the data is converted into base58 and chopped into pieces with length 4. Example: 3HZ28xpWUhq4... -> 3HZ2, 8xpW, Uhq4... The addresses (taken from the global directory) to send bitcoins to must have the following properties:

1.) They have to end with -3HZ2, -8xpW, -Uhq4...
2.) The addresses have to be in alphabetic order: (...-3HZ2) < (...-8xpW) < (...-Uhq4) < ...

Point 2 is important to connect the data pieces in the right order. It should be possible to find such an alphabetic order, since there are 30 different available addresses for each piece of data.


So, what you think... Assumed that Bitcoin miners feel threatened by the current Mastercoin implementation and stop to confirm transactions that have an Exodus recipient, this implementation could be a solution, since it harms the Bitcoin network less.

GMaxwell, I hope you enjoy your 3 BTC I sent you, courtesy of d'aniel.

Hey Peter! Thanks for checking out the project!

Not doing something like merged mining which relies on 100% Bitcoin is the biggest risk. The days of bitcoin bloatware are numbered. Your funeral, and the funeral of all the poor suckers who gave you money already when it finally happens. You're probably safe until Bitcoin 0.9, but by 1.0, it'll be game over.

One reason I didn't mention in the paper is that this method of accomplishing my goals is way, way easier and faster than building an alt coin. Building on bitcoin significantly reduces the technical risk of my project.