Well, the main goal is to get the MSC into lots of hands, but not for completely free. I didn't (for instance) look at how many followers twitter accounts had. I mostly looked at how much effort the person put out, and how well they understood the project. There's a network effect involved when lots of people participate in something like this. Many of them learn about the project then decide to get involved or buy some, so it's usually worth it on average even if nobody ever sees their tweet.

Perhaps the best model would be for me to reimburse people who run the giveaway out of their own pockets, plus 10% for their trouble.

I'd suggest that the standard payout be 10x smaller now, since MSC is ~10x more valuable.

In fact, I DID do a giveaway thread during the month of August when MSC was first on sale: https://bitcointalk.org/index.php?topic=272577.0

I actually have some left over from that giveaway, which I previously said I would split up among the top promoters. I'd still like to give some money to the top promoters from the first giveaway, but the value of MSC has risen a lot since then, so I think it's fair to reserve most of it for another giveaway.

There's still 394.84328263 MSC earmarked for giveaway here: http://mastercoin-explorer.com/addresses/15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b

Running the giveaway took a LOT of my time, but if someone trustworthy wants to get it running again, I can turn over that 394 MSC. I gave bits of MSC out for people who wrote blog posts, changed their forum signature, or otherwise made some good-faith effort to promote the project. I would suggest continuing the model where you have to at least tweet about MSC to qualify for some.

Given how much time it took me to run the giveaway, I think it would be fair to have the person running it take a bit off the top for themselves. Maybe 10%?

If someone wants to run this, let me know. I'm a little paranoid about trusting someone with that much money. I'd probably not give it all to you at once, no matter how trustworthy you are

Any volunteers?

I'll speak to this: feel free to use anybody's code. Just please be clear that you are doing so and don't try to take credit for it when payout time comes. If other people build on Zathras' code, the contest rules state that his payout gets bigger (how much it gets bigger is subjective, based on our collective feelings about how much his code sharing helped achieve the contest goals)

Redundancy is helpful too - if you write your own version of the code, the differences will help find bugs. The payouts in the last contest reflected this, with four people getting a share of the pot with a lot of overlap between their work.

I agree with vokain about the work you guys are doing - I couldn't be happier.

I keep thinking that I need to find a way to throw some water on this fire before someone gets hurt, but the only way I can really do that is to sell some MSC, which I don't want to do at these prices

I hope everybody isn't buying now with the intention of selling when the distributed exchange opens. If so, that very positive news for MSC could actually be correlated with a price drop!

Be careful folks.

The first ever distributed exchange between two crypto-currencies is going to be a pretty big deal, IMHO.

Still, while I'm not planning on selling my own MSC at the current price, keep in mind this run-up is being driven by speculation - a very fickle source of value.

What I'm saying is: it's going to be a wild ride, and even in the best-case scenario there will be some huge pullbacks on the way up. I've said this before: distributed currencies are an inherently risky investment, and nobody should be putting their life savings or rent money into this.

So, only invest money you can afford to lose, and then enjoy the ride, wherever it goes

Actually, I wouldn't say it feels good. It feels kind of scary. There are a lot of things that could go terribly wrong still!

Yeah, my poor wife - she cares not one whit for material things. All she wants is for me to be around for her and the kids and not be thinking about this stuff all the time when I am not working on it. I'm trying my best . . .

I think (hope) that nobody transferred any major amount of money that way yet, at least, not to a different person than themselves. If somebody did transfer a bunch of money that way in good faith, we should try to support it . . .

For some reason a bunch of new buyers came in the last 24 hrs. It's more like 10x now.

It makes me feel good that so many long term investors are ignoring a 10x return and holding. I hope I don't disappoint them

I think in volunteering to provide this service, he got a bit more than he bargained for

Glad you guys are tipping him

This is brilliant. You guys are awesome.

I support the nested SHA256(address) method that Tachikoma and Zathras have been discussing here. I'll add the data in Zathras' appendix to the spec in some way.

In the unlikely event that we end up in a war with miners, we can always add the MSC balance of the address to what is being hashed, but I agree that shouldn't be done right now. At this point they would be more likely to target the Exodus Address anyway. If they ever do that, we can obfuscate the Exodus Address too (which would create unspendable UTXOs, so hopefully that won't be necessary)

Zathras, when you and Tachikoma feel the appendix is final, let me know, and I'll link to it from the OP of this thread.

grazcoin, I hope this sounds good to you too?

Another idea for obfuscation: instead of always flipping the most significant bit or flipping all bits (XOR with 0x80 or 0xFF), we could XOR with data which can only be known to someone parsing MasterCoin transactions. For instance, what if we run the user's MSC balance through SHA256, and then XOR that with the data that is being encoded. Only someone who knows the MasterCoin balance of the address could tell if the address was sending a MasterCoin transaction (aside from the Exodus Address tell, which could also be obfuscated if desired) . . .

That's probably too complicated for now, but if we get into a war with miners trying to exclude us, we have a LOT of options.

I see from your first referenced post that you require the change address to be the same as the sending address. Since we are reusing addresses all over the place (including the Exodus Address) I don't see any problem with doing that. We'll never get a sequence number collision that way. Any objections on this?

One way to avoid looking like ASCII without a lot of work would be to flip (XOR) the most-significant bit of every byte. This would be essentially zero cost to us, and would make all ASCII characters non-ASCII (and many non-ASCII characters would consequently become ASCII). How does that sound? We could also just XOR everything (flip every bit we store), if that seems simpler.

I realize that the spec is overdue for a revision - this stuff will go in there for sure

MasterCoin is very vulnerable to copycats technically, but much less vulnerable socially. There is nothing to prevent somebody from forking our code and doing their own thing. However, in order to be successful they would have to offer something that MasterCoin does not offer. As soon as they did that, MasterCoin would almost certainly add that feature too.

Potential investors will have to decide for themselves how likely a copycat is to be successful. The thought experiments involved in such scenarios are almost entirely social, not technical, and are heavily influenced by network effects (the reason it is so darn hard to unseat eBay as the king of auctions, even though making an auction website is fairly trivial).

edit: And yes, you need something of value stored in escrow for the escrow-backed currencies to work. You couldn't use a "free" currency for this.

I agree with this approach, but I'm curious how we would obfuscate (point 3). That might be something to do later . . .

Edit: Does byte rotation mean we can still use all sequence numbers? It sounds like we'd be sacrificing the last byte of every key, which seems like a good tradeoff to be able to store data for every sequence number.

Replying to some development-related stuff from the other thread . . .


I agree that Peter's comments are extremely helpful. I think  you guys are on the right track (massaging Tachikoma's multisig method output until it is valid). I can offer some general guidelines here:

• We don't want to to anything that can be easily blocked without specifically targeting MasterCoin. For instance anything which could be screened out by a validity check, or a "too much ASCII" check
• We can't really worry about blacklists. If something like that happens, we have a few options. The Exodus Address can always be changed. We could even get rid of it altogether, although that would make finding MasterCoins transactions MUCH more difficult (we'd have to watch the transactions from any address which holds MasterCoins).
• We also have the "nuclear option" of returning to the original spec (spending to fake addresses), but I don't think that will be needed.
• All clients should be generous with fees to bitcoin miners by default. We want to create a situation where an anti-mastercoin stance by a miner should be very expensive for them!

Sorry for the out-of-date spec. Fixing this (and adding some new stuff) is at the top of my list.

Note that the sequence number of the change address only needs to be considered when the change amount is exactly the same as all the other outputs. Invalidating a MasterCoin transaction because the change amount just happens to be 0.00006 BTC AND a bad sequence number should be exceedingly rare.



Spending multisig bitcoins is painful right now, and I'd rather avoid that extra complexity until it isn't painful. Let's keep that extra output to the destination address for now. I think that supporting two different encoding methods will end up increasing the testing burden dramatically, and I'd rather not do that yet.

Let me see if I understand the current proposal:

We are (if I understand it correctly) taking Tachikoma's proposed multisig, then for each key after the first one we change the sequence number until we get a valid ECDSA point? Can anybody explain why this problem only affects keys after the first one (sorry if I missed this somewhere)?

Current valid transactions (not using multisig) have the last data packet sequence number before the target address be n-1. Theoretically, earlier data packets would have had n-2, n-3, all the way back to the first data packet (although simple send never has more than one data packet). Perhaps for multi-sig we should change this paradigm. It might be easier to start at the sequence number of the destination/target address, then increment up from there. If a given sequence number does not pass our "valid ECDSA" test, we just go on to the next one. Is that what you guys are doing already?

It sounds like this method significantly reduces how much data we can potentially store per transaction. Can anybody give a guess as to what a reasonable upper bound for how much data we should try to store using this method in a single transaction?

I've updated our official contest thread with the rules for the next contest: https://bitcointalk.org/index.php?topic=292628.0

My intention is that thread should become our hub for development-related discussion, while this thread will remain for general MasterCoin discussion.

For instance, the discussion with dillpicklechips about MasterCoin's value would stay here, while just about anything by tachikoma, zathras, grazcoin, retep, and other devs would go in the other thread.

I won't be a jerk about it on this thread (I'll just give gentle reminders if needed), but I may be more of a jerk about it on the development thread, as I want to keep it focused on development.

I see a couple dev-related things (especially the stuff related to multi-sig) which I need to reply to. I'll do that shortly on the other thread.

Thanks!

I have updated this thread with the official rules about contest #2. My intention is to have all development-related discussion here, but I'm not going to be a jerk about it (if people post development stuff in the other thread, they might get a gentle reminder from me).

The other thread is now intended to be for general MasterCoin discussion.

Please take a look at the rules for this contest, and let me know if anything isn't clear. Note that I added one thing to the original proposal: for the PC clients we need both Linux and Windows to be supported.

Thanks!

-J.R.

The smart property feature is probably what people are the most excited about right now, but you are right that it probably is the smallest feature in terms of impact on MSC prices. The main benefit to MasterCoin holders will be that you need MSC to buy/sell these smart properties (but not to create them).

Personally, I'm much more excited about some of the other features, but we need to be responsive to what the market wants if we want to remain in the lead. That's why getting smart property features implemented is our top priority right now (we the need distributed exchange first, but that will be directly used to trade smart property).



Wow. I sure hope it won't be jail!

On an unrelated note, I apologize in advance for being unresponsive for the next few days. I've fallen behind on other important responsibilities in my life

I apologize that this thread does not yet reflect the new coding contest. I plan to change the OP and thread title to reflect whatever we are currently working on, and I'd like this to become the development thread (to separate it from the discussion thread). Rough sketch of the next coding contest is here: https://bitcointalk.org/index.php?topic=265488.msg3358444#msg3358444

I had a long phone-call this morning with the board, which was very productive (Ron's minutes from the meeting should be public soon), but that call put me behind on other obligations. I may be unresponsive/offline for awhile - sorry!