Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 120. (Read 448462 times)

I believe that something like this would work, and as you say, it wouldn't create unspendable transactions. However, it would take a LOT more bytes to store the same data in the block chain using this method.

As I've said before, I need to get smarter about the internal workings of bitcoin, but I have a lot of confidence that our developers will come up with something which works. Currently they are (if I understand correctly) attempting to use Gavin's suggestion (https://bitcointalksearch.org/topic/m.3040840). If that doesn't work, they may try the OP_RETURN method suggested by maaku on the same thread. If that doesn't work, there may be more options which haven't been suggested yet.

Once this is nailed down, I'll be looking forward with great anticipation to see the first try at the distributed exchange using testnet and/or test MasterCoins. Given how dang fast these guys are, we may all be pleasantly surprised with how quickly that comes together

I thought you guys might like to see what some of the candidates for the open board seats at the bitcoin foundation are saying about MasterCoin:

Ben Davenport:

Elizabeth Ploshay:

Trace Mayer:

Meyer "Micky" Malka:

Luke Dashjr also sent me a PM about his candidacy and MasterCoin, but I don't have an official quote from him yet.

Disclaimer: I'm not endorsing anybody. I don't even know who I'm voting for!

In your PM, you asked me to send it to 1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb:


Which I did in this transaction: http://blockchain.info/tx/99160b37b3294eebc83bd8ff44849c813d2e9da986a25fb127b0c5915e799c0a

If you no longer have that address, I'm very sorry! I did post my intention to use that address for you publicly more than once. For instance: https://bitcointalksearch.org/topic/m.3132645

I'm totally fine with someone else doing it - it's the sort of thing that if we run into a snag we can always start a new one. If you guys really want me to I can, but the consequences of making a mistake on testnet are pretty small, and possibly the benefits of such a mistake would be worth the trouble - we might learn something valuable that will help keep the funds at the real Exodus Address safer.

First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas:


I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

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.


edit: follow-up here: https://bitcointalksearch.org/topic/m.3166749

Ran into this problem also when I was working on an application to try to implement 3 of 4 scheme. I had read somewhere that the maximum is 20 outputs also, but I guess only 3 is supported thus far by miners. Thanks to all you guys pushing this project forward I wish I could dig in and help but I got a full plate. I can be a continuous voice of encouragement for all its worth.



The mastercoin project translated into Chinese on weibo forum is pretty super exciting






All good forethought, I have been thinking about some of those potential problems too. I have several semi planned out solutions if any of some of the problems you mention arise. like the spam problem and centralized solution or the need for a blockchain escrow (integration at Coinsigner). I am bringing some more press to mastercoin this week. Just because I think it is necessary for more people to know about the project.

There are two types of multisig outputs available at the moment that are useful for us.

• 1-out-of-3
• 1-out-of-2

While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.  

What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.

Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.

I would like to suggest that we keep the original spec and use one output for the receiving address.

We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.

We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.

A simple encoded simple send would look like (and forgive my horrible photoshop skills):



A complete tx could look something like this:


I appreciate some feedback on this spec before I start writing code

I've got some time to work on the multsig again and it seems that there is something wrong with the change address output in my transaction. When removing it I successfully send a multsig transaction using Mastercoin encoded data. Working on how to properly encode Mastercoin data using all 1-out-of-3 transactions now.

Question, when am I going to receive my 3 BTC tip?

Would it not be a good idea for dacoinminster to create a Testnet Exodus address?  Surely it should be under his control, or that of the oversight board.

Fount the answer in the bitcoind code.



Seems we hit the first bump in the road. I suspect that our publickeys can't be parsed as valid ECDSA coordinates so transaction is not getting processed by nodes on real-net, 'ERROR: CTxMemPool::accept() : nonstandard transaction type'. The reason it worked on testnet is that testnet does not do strict checking before accepting a transaction. I will research to see if there is a way to somehow encode the data in a way that it looks like a valid publickey. I'm trying to figure out why it's not passing the tests.

I would appreciate it if somebody could replicate my tests, perhaps I simply made an error somewhere when crafting my raw transactions.

In order to replicate my tests please create a transaction with one input, two outputs. One ouput with a change address and one with a multisig script with 1 actual publickey, so you can redeem the output, and two data encoded publickeys.


Edit: Found an error in my first transaction because I was denoting it as a full publickey while I was actually using compressed ones. This one is valid according to my own tests but bitcoind doesn't like it still. The code responsible for flagging a tx as non-standard can be found here.

Yes, once you actually have something working, it becomes easier to defend.
At the moment, all there really is is money and some ideas.
Other people have money, and can just steal the ideas.

Yes, but I mean to point out that not many people would have sent me money if I was blatantly copying something that already existed. I think most of the money was raised because people recognized that this project is breaking new ground.

That said, a really compelling competitor is pretty high on the list of things that could go wrong. Our best bet is to keep up the current breakneck speed

Well, without meaning to be rude, they sent money to you, didn't they?

JR,
You don't have to mask my name. I only send via email so not to sound like a troll, but more like a subconscious. I do accept tips if you value any of my opinions (a shot out to Adam B. Levine's Project Watershed).

Why do you think that MasterCoin's vulnerability to clones fades as the project gains momentum? I suspect you are right, but... According to BitcoinMagazine, Tonal Bitcoin, the first alt-coin, did not come out for 2 years after Bitcoin. I did not read why Tonal Bitcoin failed. I do not think Mastercoin will be granted anywhere near that amount of time before something nefarious is attempted.

Does anyone else have any thoughts on this or other attack vectors that Mastercoin investors should try to protect themselves against?

Here's an email I got from somebody worried about MasterCoin clones:


MasterCoin is vulnerable to clones, although the problem fades as the MasterCoin project continues to gain momentum.

It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address?

A clone would have to offer some MAJOR innovations, and they would have to move very fast. In all likelihood, we would blatantly steal any innovations we saw in somebody else's clone, which I have said multiple times, in an attempt to discourage people from trying it

Yeah, anybody parsing MasterCoin transactions would not display sell orders from people who don't own the coins. And of course, we don't have this problem with the distributed exchange between MasterCoin and its child currencies.

The burden of these fees falls on the buyer, who is using bitcoins which are not subject to MasterCoin rules.

Does the spec enforce that the seller actually has the coins they are offering to sell?
If not, any malicious actor can poison the market by repeatedly making offers they have no intent to fullfill, causing potential buyers to repeatedly lose transaction fees as they attempt to purchase.
This all seems pretty unattractive compared to existing exchanges like Cryptsy, where ownership of the coins is enforced, and fees are only charged on completed transactions.

Sorry - I think we both posted at the same time. See my message right before yours

Fees currently go to the bitcoin miner, and are not recoverable under the current spec.