I have cloned the github repo of the spec ( https://github.com/mastercoin-MSC/spec), and I have prepared the following comprehensive list of changes planned for version 1.2 of the spec: - Fix incorrect sequence number description (https://bitcointalk.org/index.php?topic=265488.msg3122349#msg3122349)
- Clean up various things which were still undecided as of 1.1 or are now out-dated (as I find them)
- Include description of how to determine change addresses (https://bitcointalk.org/index.php?topic=265488.msg3190175;topicseen#msg3190175)
- All protocol transactions should have the same output amount. If one output is different, that is the change address.
- If all outputs are the same, then look at sequence numbers:
- If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
- If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
- If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!
- Integrate Zathras' Class A/B/C documentation describing multi-sig (https://masterchest.info/files/mscappendix_draft.pdf)
- Clarify distributed exchange rules when BTC is not involved (especially that buy/sell orders can be matched automatically
- Add support for "pay dividend" command (https://bitcointalk.org/index.php?topic=265488.msg3233723;topicseen#msg3233723)
- Add support for "spending limits" on a savings address (https://bitcointalk.org/index.php?topic=265488.msg3412565;topicseen#msg3412565)
- Add support for "kickstarter" type fundraisers (where money is returned if the goal isn't met) (https://bitcointalk.org/index.php?topic=265488.msg3451098;topicseen#msg3451098)
- Add support for "Contract For Difference" betting (https://bitcointalk.org/index.php?topic=324830.0)
- Add support for "Distributed e-commerce" transactions (http://www.reddit.com/r/mastercoin/comments/1nqcq3/mastercoin_could_be_extended_into_a_fully/)
I hope I got everything. If you think something else should be in that list, please let me know! Excellent! I would like to hereby appoint you as the Mastercoin Protocol Lead. Do you accept? I have no issues at all with your changes. I do however suggest a different work process. This document describes the process of making changes to the Mastercoin spec. This process is it's very early stages, and is expected to change rapidly in the future (e.g. to include Voting). The current Protocol Owner is J.R Willett.
Right now, there are two possible change mechanisms to the spec document:
Developers can fork the repository, work on their own copy, push their proposed changes, and send a pull request accompanied with a post to bitcointalk. The Protocol Owner and the community reviews the changes, and when enough consensus has been generated, The Protocol Owner merges the changes back to the parent repository on mastercoin-MSC.
Minor and/or non-breaking changes can be made directly on top of the mastercoin-MSC parent repository, by people who have push right to this repository. If you want to be included in this group, ask Willett.
For sake of convenience, people who already have push access to the parent repository can work on branches instead of forks. This achieves the same purpose as option 1 above, in a manner that might be more convenient to some developers.
The disadvantage over the way Willett proposed the v1.2 changes is that with his current approach, we cannot examine the full updated spec before he pushes it to master. I would like the master branch on the official repository to always be an up-to-date version of the official spec. Sounds good to me! I got a couple hours in last night on this, but I still have a ways to go. This is a fairly big set of changes . . . |
|
|
|
The root of the criticism seems to be that this distribution was not fair, and I agree. It wasn't intended to be fair.
The meaning of "fair" that I care about is "does not create perverse incentives". Creating perverse incentives is bad because it incentives people to do perverse things, thus I want things to be fair. I was hoping to incentivize passionate involvement, investment, evangelism, and thus momentum. The incentives seem to be working well so far. What perverse things do you expect to see? I think it might be instructive to look at the way new ideas are usually funded. Typically, I would have made the rounds to venture capitalists, jumped through a lot of hoops, and if I was VERY lucky, raised some money to go implement my new idea. Then, if I beat the odds, a bunch of wealthy venture capitalists would become even MORE wealthy. Nobody would call this "fair", but it works.
That's ok for a company offering some specific service. Not for what aspires to be the foundation of the entire world economy. Nobody ever accused me of being unambitious, but that is a pretty high aspiration! I'll be very happy if we are just a thriving segment of the economy in a few years. Disrupting the entire world economy is a possibility, but I actually hope that doesn't happen - too many people will get hurt (those who don't know what I mean should check out "bitcoin's dystopian future" in my signature). |
|
|
|
You guys might be interested in this post I made on another thread about the criticisms that the intial distribution of Mastercoins was unfair: This was a great discussion. I'd like to respond publicly to the criticism about the way MasterCoins were originally sold (in a one-month time frame rather than over several years). The root of the criticism seems to be that this distribution was not fair, and I agree. It wasn't intended to be fair.
I think it might be instructive to look at the way new ideas are usually funded. Typically, I would have made the rounds to venture capitalists, jumped through a lot of hoops, and if I was VERY lucky, raised some money to go implement my new idea. Then, if I beat the odds, a bunch of wealthy venture capitalists would become even MORE wealthy. Nobody would call this "fair", but it works.
Instead of that approach, I took my idea to the people in the bitcoin community. Instead of making the rounds to venture capitalists, I launched my project with a kickstarter-style fundraiser. As it happens, a bunch of venture capitalists invested a lot of money, but they were joined by lots of average people who were following bitcoin closely. It turns out that my project ALSO made a bunch of wealthy venture capitalists even more wealthy, but normal people got to participate too.
The distribution wasn't fair and wasn't trying to be fair. Capitalism is unfair. Bitcoin is unfair too. There are other ways Mastercoin could have been sold, but I doubt any of them would have given us the funding (and thus the momentum) that we have today.
The complaints about the distribution model also seem to assume that the party is over now that the early investors are up ~30x. I personally do not think that is the case. I believe the party has barely begun.
|
|
|
|
|
This was a great discussion. I'd like to respond publicly to the criticism about the way MasterCoins were originally sold (in a one-month time frame rather than over several years). The root of the criticism seems to be that this distribution was not fair, and I agree. It wasn't intended to be fair.
I think it might be instructive to look at the way new ideas are usually funded. Typically, I would have made the rounds to venture capitalists, jumped through a lot of hoops, and if I was VERY lucky, raised some money to go implement my new idea. Then, if I beat the odds, a bunch of wealthy venture capitalists would become even MORE wealthy. Nobody would call this "fair", but it works.
Instead of that approach, I took my idea to the people in the bitcoin community. Instead of making the rounds to venture capitalists, I launched my project with a kickstarter-style fundraiser. As it happens, a bunch of venture capitalists invested a lot of money, but they were joined by lots of average people who were following bitcoin closely. It turns out that my project ALSO made a bunch of wealthy venture capitalists even more wealthy, but normal people got to participate too.
The distribution wasn't fair and wasn't trying to be fair. Capitalism is unfair. Bitcoin is unfair too. There are other ways Mastercoin could have been sold, but I doubt any of them would have given us the funding (and thus the momentum) that we have today.
The complaints about the distribution model also seem to assume that the party is over now that the early investors are up ~30x. I personally do not think that is the case. I believe the party has barely begun.
|
|
|
|
Congratulations JR on what is a brilliant, elegant protocol that opens up mindblowing possibilities. I'd like you to talk to us more about trust issues though. What can you offer the sceptic that thinks you will mint more MSC when it suits you?
Thanks! Trying to issue more MSC would fork the protocol - it would be just as hard as trying to change bitcoin to have more than 21M bitcoins. You can say you are doing that, but really all you have done is forked bitcoin, and anybody who doesn't like your idea will stay on the original branch. Same with Mastercoin. |
|
|
|
The question I don't see discussed yet; was Buyer A's purchase request confirmed in a block before Buyer B placed their purchase request?
Yeah, the order in the block chain is what matters. We shouldn't show confirmation that it is ok to send bitcoins until at LEAST one block, preferably more. |
|
|
|
I still think this is a different situation. At one point there _were_ 10 coins available, it just wasn't the case when the payment got confirmed. Only 3 were left. I think it would be weird to see my Purchase Offer being accepted but all of the sudden the amount got reduced from 10 to 3 coins. I might not notice and send Bitcoins worth 10 MSC instead of the 3 I got now. It's all around confusing. I don't understand why not just invalidate the whole Purchase Offer and make it easier for everybody.
I think this is more of a UI design question than a spec question. There will be lots of buy and sell offers going on, and the higher the trading volume, the more annoying it will be to not get partial fills. We already need to design the UI carefully so that the user knows not to send bitcoin payment until they receive confirmation. We also need to make sure that the confirmation is very explicit about how many coins they have reserved for purchase (which might not be the amount they were trying to buy) and how much money they need to send, and where to send it. A simple binary switch (you got it, or you didn't) doesn't handle collisions very elegantly. |
|
|
|
I should probably at least mention in this thread my list of proposed changes for the next rev of the spec: I have cloned the github repo of the spec ( https://github.com/mastercoin-MSC/spec), and I have prepared the following comprehensive list of changes planned for version 1.2 of the spec: - Fix incorrect sequence number description (https://bitcointalk.org/index.php?topic=265488.msg3122349#msg3122349)
- Clean up various things which were still undecided as of 1.1 or are now out-dated (as I find them)
- Include description of how to determine change addresses (https://bitcointalk.org/index.php?topic=265488.msg3190175;topicseen#msg3190175)
- All protocol transactions should have the same output amount. If one output is different, that is the change address.
- If all outputs are the same, then look at sequence numbers:
- If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
- If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
- If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!
- Integrate Zathras' Class A/B/C documentation describing multi-sig (https://masterchest.info/files/mscappendix_draft.pdf)
- Clarify distributed exchange rules when BTC is not involved (especially that buy/sell orders can be matched automatically
- Add support for "pay dividend" command (https://bitcointalk.org/index.php?topic=265488.msg3233723;topicseen#msg3233723)
- Add support for "spending limits" on a savings address (https://bitcointalk.org/index.php?topic=265488.msg3412565;topicseen#msg3412565)
- Add support for "kickstarter" type fundraisers (where money is returned if the goal isn't met) (https://bitcointalk.org/index.php?topic=265488.msg3451098;topicseen#msg3451098)
- Add support for "Contract For Difference" betting (https://bitcointalk.org/index.php?topic=324830.0)
- Add support for "Distributed e-commerce" transactions (http://www.reddit.com/r/mastercoin/comments/1nqcq3/mastercoin_could_be_extended_into_a_fully/)
I hope I got everything. If you think something else should be in that list, please let me know! |
|
|
|
I have cloned the github repo of the spec ( https://github.com/mastercoin-MSC/spec), and I have prepared the following comprehensive list of changes planned for version 1.2 of the spec: - Fix incorrect sequence number description (https://bitcointalk.org/index.php?topic=265488.msg3122349#msg3122349)
- Clean up various things which were still undecided as of 1.1 or are now out-dated (as I find them)
- Include description of how to determine change addresses (https://bitcointalk.org/index.php?topic=265488.msg3190175;topicseen#msg3190175)
- All protocol transactions should have the same output amount. If one output is different, that is the change address.
- If all outputs are the same, then look at sequence numbers:
- If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
- If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
- If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!
- Integrate Zathras' Class A/B/C documentation describing multi-sig (https://masterchest.info/files/mscappendix_draft.pdf)
- Clarify distributed exchange rules when BTC is not involved (especially that buy/sell orders can be matched automatically
- Add support for "pay dividend" command (https://bitcointalk.org/index.php?topic=265488.msg3233723;topicseen#msg3233723)
- Add support for "spending limits" on a savings address (https://bitcointalk.org/index.php?topic=265488.msg3412565;topicseen#msg3412565)
- Add support for "kickstarter" type fundraisers (where money is returned if the goal isn't met) (https://bitcointalk.org/index.php?topic=265488.msg3451098;topicseen#msg3451098)
- Add support for "Contract For Difference" betting (https://bitcointalk.org/index.php?topic=324830.0)
- Add support for "Distributed e-commerce" transactions (http://www.reddit.com/r/mastercoin/comments/1nqcq3/mastercoin_could_be_extended_into_a_fully/)
I hope I got everything. If you think something else should be in that list, please let me know! |
|
|
|
Sheesh. With the recent bitcoin price run-up, this contest is now worth ~$80k! Compare that to the meager $25k we gave away for the last one . . . Of course, the price sometimes falls hard too, but still . . . pretty cool for the moment.  |
|
|
|
|
So cool! Somehow I forgot to sign up for notifications on this thread, so I am only just now seeing this. Please post to reddit when you are ready for the masses!
Have we made provision to fund this faucet somehow? I assume that is in addition to the bounty money . . .
|
|
|
|
Today I took a look at raw transactions, multi signatures and class B transactions. And after observing the exodus address I was wondering: Is there a specific reason to use an additional output for the change when doing multi sign transactions? Example transaction: Tx id: d445e92dc860b9fe62c53200906c7dfefd011ff2c46d3d99ef996dee0f2ae820In: Out: Total out: 0.04966+0.00006+0.00006+0.00012 = 0.0499 BTC If I'm not mistaken, this would yield the same result: In: Out: Total out: 0.0000543+0.0000543+0.0497914 = 0.0499 BTC It is possible to use the multi signature output as transaction input in the next transaction with: In: - 0: (simplified multi sign tx id from above), vout: 2
Out: .... Those 1-of-n outputs are redeemable, too, so why not use them?  The MSC devs may not notice your question here on the general discussion thread (they are really busy). Maybe try posting this question on our developer thread: https://bitcointalk.org/index.php?topic=292628.0 |
|
|
|
|
bitoy - great job on mymastercoins.com!
I've added links to the OP of the main project thread, and to our subreddit. I'll see about getting it listed on Mastercoin.org too. Looks like masterchain.info needs a link from there too.
Thanks!
If anybody notices that their project isn't linked from one of our channels, please let me know. I don't want to slight anyone!
|
|
|
|
I really don't understand the problem.
Zathras is making an Windows based client. I'm sure it will have a nice installer with it and for him this is as easy as pressing the compile button.
My client will be very easy to use on any unix-based system, much like Grazcoin's implementation. As long as there is a wallet for any flavour I don't really see a problem.
I feel strongly about this because I have no way to accomplish a windows installer because of a decision I made months earlier. If I knew this was a requirement before hand I would have decided to build the application in Python since it's much easier to build on Windows. I am working my ass of and you are basically telling me; sorry it's useless.
Whew! I'm relieved to hear you say this. I think I must have chosen my words poorly at first. I didn't mean to say that all desktop clients need a Windows installer, but rather that we need a Windows installer for at least one of the desktop clients before we can call this contest finished. It sounds like you agree? |
|
|
|
You changed the rules of the contest after the fact. Whatever the rules were or how they were interpreted this just isn't cool. The fact that I picked ruby as my language of choose now fucks me because I can't make an easy 1 click installer which is possible with compile-able languages.
OK. For now, I've removed that note from the acceptance criteria. It's clear you feel strongly about this, and it's very important to me to keep the developers as happy as I can. I'd be interested to hear what the other devs think about this. I personally wouldn't feel that we had met our acceptance criteria without a Windows installer, but I don't want you guys to feel like I am moving the goalposts either. |
|
|
|
I'm not too happy with this. Basically it might throw way all the work I've been doing on my client since there is no guarantee my wallet will ever support a windows installer. I don't feel this is acceptable to change afterwards.
Throw away work?? That's definitely not what I want. I just want the average Joe-user on Windows to be able to use MasterCoin without a lot of headaches. I'm surprised to hear you say it might not ever have a Windows installer. How certain are you about that? Even still, it could have a Linux installer, couldn't it? That would at least cover the linux side. The acceptance criteria already specified that there needed to be a Windows client and a Linux client. All I added was a clarification that the Windows client should really have an installer. I don't really consider any client to be completely ready for the masses without a user-friendly installer. And that's the whole point of this project milestone - bringing distributed exchange to the masses. The acceptance criteria also said that there would be a high bar for usability. Doesn't that goal seem incompatible with "Step 1: download my source code, required libraries, dev environment tools, and compile . . . "? |
|
|
|
|
Hey guys,
Please be advised that I have added a clarifying note to our acceptance criteria. In order for the "high bar for usability" goal to be met, we really need a Windows installer on one of the clients.
That's now explicitly called out in the acceptance criteria, although I think it was already implicit in the usability goal.
Thanks!
|
|
|
|
|
Hey guys - Just a quick warning that I may be unresponsive for a couple days while I catch up on other responsibilities. Thanks!
|
|
|
|
I started the MasterCoin project, and I'm the biggest investor. I invested every last BTC I had in MasterCoin. Since then, I haven't sold one single MasterCoin. Not one. I know I'll have to eventually, but that will be very painful for me. meh, since you control the exodus address, you are in the better position than everyone else to put every coin into it. Obviously. The point I was trying to emphasize is that I haven't sold any. |
|
|
|
|
Show Posts
