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

You dont hedge as a trading strategy you hedge to make your balance sheet deterministic.

Hedging is actually not idiotic at all. It is in fact what most large organizations do if they have currency or interest rate risks with respect to their accounts payable. That's why the OTC derivative market is so huge. It is certainly not 'idiotic' to think about it and have a plan for it given how volatile BTC is. Let me give you an example. Let say BTC reaches $1000 in 3 months and then crashes to $200 in month 4. Lets say the Board plans to spend X amount of BTC or USD in the next 12 months. That X amount is being spent regardless in the next 12 months. It is not being held long term as an investment - so one's view on the long term future of BTC is irrelevant. Hedging a certain amount of the outgoing funds would mean the Foundation would have sufficient funds available regardless of any crash in the price of BTC. Again, we are spending a certain % of the funds regardless, not holding it all as a long term investment.

Mastercoin is on slashdot!

http://slashdot.org/firehose.pl?op=view&type=submission&id=3108443

I'll reply to other things later.

Was just going to read 0.5, glad I caught this before I did.

Lock in gains!?  lol that is funny.  You don't 'lock in gains' - you lock out future value.  Don't do this idiot move.  Only take this step on the day you no longer believe in bitcoin's future.  Right now, I'd have to say we are all a bit bullish on bTC

A few questions regarding the Mastercoin funds:

1) Has any thought been given to selling a small % of BTC for USD to lock in some of the gains we've made in the development funds and hedge against the risk BTC crashes? For example, let's say we have a huge run up next week and 1 BTC = $500. Or if BTC reaches $1000 in the next several months? In the latter example, would it make sense to sell 1000 BTC and put $1 million USD in the Mastercoin Foundations' bank account. I don't believe the board should engage in trading the funds on a regular basis at all, but a "one off" sale of some small % of BTC for fiat as a hedge might be something worthy of discussion.

2) Similarly, has any thought been given to paying bounties denominated in anything other than BTC or in some sort of hybrid that hedges the payment such as a combination of BTC/MSC/USD? Or is that too confusing? It seems to make sense to reward the developers with some MCS, to increase their incentive to work.

3) If the funds are being distributed amongst board members what precautions/considerations are being made for/against (i) a rogue board member misappropriating funds, (ii)  death or incapacity of a board member and (iii) security of funds? In the case of (i) is it possible to require two or more board members to access fund in storage? In the case of (ii) it is important that more than one person has access to the private keys (private keys should be in safety deposit boxes or some other secure place accessible by the board in case a board member dies).

4) In the case of BTC, will all of the public addresses holding the funds be published so that MSC holders can periodically view the balance of funds?

5) Has any thought been given to appointing a Treasurer of the Mastercoin Foundation funds, to oversee all of the above, and report to the board and MSC holders? This person should be separate from both JR and RG imo.

  

That last part sounds good and I understand your reasons for the first part. I was just thinking, given that we aren't there yet, and with Willett's note that someone attempted to clickbait him a few days ago, it would be a shame to lose a big chunk of a big chunk of money. Something where a quick sane standard  (i.e. for anyone holding foundation money must either use armory offline wallet, or keep it as a totally cold/paper wallet) would go a long way. You could be open about the general technique(s) you were using at that kind of a high level to secure the funds among the foundation members (or whoever) to give confidence to the community, without having to go into details about who, what, where, etc.

Just seen too many stories of people losing tons of BTC to thieves in the last few months... would hate to see that happen here. That's all.

What's wrong with the Google Docs? If you can make a spec for what's needed for the website I can ask around with some developer friends if they are interested. I would do it myself but I already have a todo list that only increases in size...

We need either budget.mastercoin.org or a dedicated thread for this.

https://trello.com/c/wtFdcTtl/15-build-a-budget-website

New proposed expenditure: $1099 to Stas, the guy in charge of our Hebrew blog. Ron knows him well, so we are giving him $1000 in discretionary funds to pay him for various IT tasks he is doing for us. The other $99 is paying for the blog registration.

He wants MSC, so I'll get him some on the buyer/seller thread.

This expenditure has been approved by the board.

FYI here is the full 1.2 spec on J.R's repository:

https://github.com/dacoinminster/spec

Welcome back!

OK - Ron has gotten about a billion balls rolling all at once, and I can't keep up.

What I can do, and did, was get most of the changes I promised ready for version 1.2 of the spec. It's a giant pull request, but I agree that future pull requests should be smaller: https://github.com/mastercoin-MSC/spec/pull/3

This version of the spec, which I labeled 1.2, has dividend payments, CFD betting, spending rate-limits for savings wallets, and distributed e-commerce. Many people will probably use the latter feature as a distributed silk road, but I used selling contraband Bibles as my example

I haven't done proof-of-stake voting yet, although that should be easy. I decided against a kickstarter feature, since someone who can be trusted to run a kickstarter can also be trusted to give the money back if the target isn't raised.

The main problem right now is that for some reason the reference client will only accept x-out-of-y where y is smaller then four. I'm guessing there are more  foundation members then three so right now that's not even an option. I really hope they lessen the restrictions on these type of transactions in the near future.

I've never done a multisig address in my life.
We're going to get there, but we need tooling, documentation and testing of multisig.

Current plan is to use the SX tools for that.
Vitalik Buterin, author of SX, is also on the team, which should help a lot with that.

Current urgent plan - split up funds manually without multisig. We'll move to multisig when we feel we're ready for that.
The trigger for the urgency is the huge spike in bitcoin prices.

We talked security among ourselves.
We haven't decided yet to make our specific security practices public.
I know this isn't the spirit of open source, but we're talking specific people here that may be at risk of mugging or legal risk.
This is why I'm ok with us being a bit secretive about our current practices.

I'll give you the long term vision.
We want to destroy ourselves.
We want every protocol itself to hold all the bitcoins.
Everything will be open, and there will be no central points whatsoever.

We're going from a centralized Willett --> Foundation --> More pen foundation --> No foundation.

Split, that could mean they are using x-out-of-y multisig.

Ron,

I read that the bitcoin from the Exodus address will be split among the MSC foundation member's wallets. That sounds like a good idea in general, however, do you guys have a list of specific security precautions each member is taking with these wallets? I.e. will each member be using an offline machine with Armory, or it be a totally cold wallet, etc? Maybe I missed where this is mentioned.

I will be experimenting with using Armory in offline mode to sign MSC simple send transactions, based on some tips from Tachikoma. I'll be documenting this and hopefully we can post it into the wiki or FAQ.

Just thought I would post a little explanation about this feature.

I thought that it was decided that any arbitrary 33-byte number can, by manipulation of the last byte, be made into a valid ECDSA point.

In any case, the public key would just have to be both obviously unspendable and still a valid ECDSA point. It could be, for instance, the point on the curve in question which, when in compressed form, has the lowest numerical value. (This is just another example.)