Wow. Dread Pirate Roberts in jail, silk road seized, bitcoin prices plummeting.
Just a reminder: the contest is for $25k, not a specific number of bitcoins. I was thinking of making the next contest for a specific number of bitcoins, but . . . maybe not.
This is a good opportunity to mention something important: once we have features which COULD be used for illegal things, all devs should make sure to have really bold and visible warnings that everyone is responsible to know the laws in their own jurisdiction, and not break them. We must never be seen as encouraging illegal activity, even though our tools can be used in that way.
|
|
|
|
|
Wow. Dread Pirate Roberts in jail, silk road seized, bitcoin prices plummeting.
Just a reminder: the contest is for $25k, not a specific number of bitcoins. I was thinking of making the next contest for a specific number of bitcoins, but . . . maybe not.
This is a good opportunity to mention something important: once we have features which COULD be used for illegal things, all devs should make sure to have really bold and visible warnings that everyone is responsible to know the laws in their own jurisdiction, and not break them. We must never be seen as encouraging illegal activity, even though our tools can be used in that way.
|
|
|
|
Disclaimer: I did post that scheme in general because I believe it would help to resolve the mastercoin protocol bloating the bitcoin blockchain concern. I posted it here also because be visible for the respected developers of the project to see and use some aspect of it, if they feel workable. There is no need to show cold feet or telling me not welcome indirectly. I do not consider myself a coder and therefore has not any interest or intention to participate in a coding contest, dacoinminster  I just wanted to help the project in that direction, but sure I remove it away soon! I doubt we'll do off-chain transactions anytime soon, but I'm happy to see people are thinking about how that might be done someday. |
|
|
|
The board is asking for a summary of progress so far on this contest, but I know if I try to summarize everybody's work, I'll leave important stuff out. Contest participants: please summarize your work so far, and I'll take your summaries to the board. Here's what Tachikoma's might look like: - Wrote ruby library to parse MasterCoin simple-send transactions
- Used ruby library to launch MasterCoin-Explorer.com (note: not open source, and can't be considered for contest payout)
- Ported J.R.'s Python script for creating transactions to MasterCoin-Explorer, so people can create transactions without downloading custom software
- Cross-checked parsing code with implementations by grazcoin and Zathras
- Invented multi-sig approach to storing MasterCoin data, which we are now all using
- Implemented multi-sig in the ruby library (and MasterCoin-Explorer)
- Published API for accessing MasterCoin-Explorer programatically
- Used API to create proof-of-concept for thin client implentation of MasterCoin
- Answered numerous technical questions from other developers
- ??
I'm sure I left some important items off that list, but hopefully you get the idea. We'll update these lists again when the contest is over. Thanks guys! (I sent PM's to tachicoma, grazcoin, maraoz, and zathras about this) |
|
|
|
For complete financial transparency: ---------- Forwarded message ----------
From: J.R. Willett
Date: Tue, Oct 1, 2013 at 8:12 AM
Subject: Notice of proposed expenditures
To: Mastercoin Board
Please be advised of a couple upcoming payments from MasterCoin project funds.
$45.90 in BTC to 1CTctpqg7JdomAeq3fz7Ynw43VDVJjc4o3 to reimburse David's purchase of a couple MasterCoin-related domains
1 BTC to 1KLoFjuq6o4Q6RGNdDSdHoWjazQqQLRnmH to Mich for our slick new website
I'll try to process these tomorrow if I don't hear any objections.
Thanks! |
|
|
|
I'd just like to bring attention to Retep's proposition at this link and Cunicula's valuable comment regarding derivatives/smart property, in case anyone didn't catch it. https://bitcointalk.org/index.php?topic=299679.0I really think these things need serious consideration and I'm a bit concerned with the dismissive attitude they have received. The consensus on Retep's ability and knowledge regarding Bitcoin is that of high regard from what I can tell. This seems like a potentially invaluable resource. The white paper is a good outline, but this could provide a more solid framework to build on, giving focus and direction and accelerating development. I'm sure the content of the reports can be optimized so it's effectively aligned with the projects goals, as decided by the board and community. It's at least worth negotiating, even if you don't go down that road in the end. Regarding Cunicula's comment, is there a plan to consult someone with an economics background to be sure you're building a viable system for the smart property/derivatives? J.R., you said one of the great features of the planned smart property implementation is it's simplicity. Are you professionally qualified to claim viability of the planned design in these type of systems and markets? A well working system is as simple or complicated as it needs to be. To move forward rigidly with your plan, viability be damned because you want a "simple" design, seems like a setup for failure. I realize these aren't absolute priorities at the moment. But they will be in the (near) future and it just feels a bit flying-by-the-seat-of-your-pants with the talk about some of this. You've laid out the basics with the white paper. Personally, I'd expect team building (probably more ad-hoc than structured for the moment, I know) so the goals for the respective parts of the project can be met effectively by those with the most suitable skills and knowledge. The coding contest and everyone doing the work they are is a great start. These considerations could be an important addition. About that, can the board officially prononce a statement about the retep offer? J.R. When you have a few minutes, would you care to comment on any of this? It would be appreciated. One of my board members said he was going to reach out to reteP to get some more info, but I haven't heard anything since then. I don't consider this high priority, as it seems pretty likely that reteP would recommend changes we are unwilling to make (like getting rid of MasterCoins or moving to an alt chain). |
|
|
|
If you are feeling adventurous you can try out my wallet implementation; but you will need to be comfortable around a terminal for now.  Yes, we need more testers! There's also blockchain.info - a lot of people seem to be using that. It can do sendmany, and I understand it can be fairly secure if used correctly. |
|
|
|
|
I've added links to mastercoin.org and masterchest.info to the OP. Not sure why I didn't have a masterchest link there already - sorry Zathras.
If anybody knows of links that should be in the OP or on the MasterCoin.org page or in the reddit sidebar, please let me know!
-J.R.
|
|
|
|
Selling Mastercoin for Bitcoin specNow that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec. I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins. Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins. My solution has other problems and I am not even sure it's better but I wanted to provide an alternative. The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation. Let's see how this would work in practice. * User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin. * User B and User C both accept this offer in the exact specified quantity. Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins. User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction). The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well. However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction. The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience. Feedback welcome, as always I'd definitely like to experiment with some alternate implementations of the distributed exchange at some point. Tachikoma is correct that the suggested changes here would reduce the cost overhead while increasing centralization. I'd make one major change: the MasterCoin Foundation should not play middle-man, for legal reasons. We need to stay out of the money flows lest we be held liable for them. Allowing users to choose their own middleman would fix that problem and make the solution less centralized, but we would end up with multiple middle-man apps, and therefore multiple exchanges with multiple order books. Another potential problem is keeping the middle-man secure. It would be a potential attack vector to compromise the middle-man account and then set up situations that allow stealing of BTC from market participants. I'd like to stick with the existing implementation described in the spec for now, which is decentralized but marginally more expensive to users (it should only be expensive when the exchange is under attack, and since attackers lose money and can't actually shut down the exchange, I don't expect any attack would last very long or be effective). If we find that fees rise unreasonably high, we can play around with middle-man apps, but I expect that fees will not be very high long term, except for brief periods when hostile forces decide to burn some bitcoins. During those periods, we'll always have the option of using escrow just like we do today. Keep in mind that the decentralized exchange can't be burdened with fees in this way when exchanging between MasterCoins and other MasterCoin-derived currencies. This only affects MasterCoin/bitcoin exchange. |
|
|
|
Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction. I believe this is actually already explicitly defined by JR both in his comments and the spec. It's less about the value of the amount, more that all outputs have the same amount. All protocol transactions should have the same output amount. If one output is different, that is the change address.
(From the spec)
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.
Based on the above those rules are applied in my implementation and I require all outputs to be for the same amount. The exception is multisig where I've temporarily allowed the multisig output amount to be ref/exodus amount * 2 while we firm up the discussion. Having all the outputs be the same amount is merely a convenience for identifying the change address. I'm fine with a less strict implementation as long as it is still possible to identify the change address. |
|
|
|
Just a work-in-progress update on my (thin) Mastercoin client. I've been working on a Mastercoin client that uses a combination of the Mastercoin ruby library and Mastercoin-explorer in order to create a thin-client implementation for Mastercoin. This means that you don't need a local synchronised Bitcoind instance in order to make Mastercoin payments. Right now this is a very centralised solution but once the Alpha version is out I will create a Mastercoin-server project that will enable users to setup their own Mastercoin servers which clients can connect to; think Electrum. All the client requires is a private key of a Mastercoin address and enough Bitcoin balance to create a valid transaction. I just send my first valid multi-sig Mastercoin transaction so I figured this is as good as time as any to show some early wip screenies.   The first real transaction can be found on Mastercoin-explorer and Blockchain.infoThere is still a lot of work to do but at least we are getting somewhere. I hope somebody else can send some multisig transactions soon so we can finalise the spec and start working on the next feature This will be my last post for a while as I will be leaving the country and be without internet for a few days. See you all on monday Holy crap! Tachikoma strikes again!  Did you see the post I JUST MADE about how to do thin clients?! It's like you're reading my mind! (Are you?) |
|
|
|
In a conversation with the board, I was asked how companies who IPO using MasterCoin can pay dividends. My response: You are right that many people will use the smart property to create IPOs and pay dividends. I haven't explicitly put dividends into the spec, although it would be trivial to do so. Someone owning a lot of MasterCoins could then publish a message like "I hearby pay 500 MasterCoins to be distributed to all holders of currency ID XYZ" (which could be a user issued stock). The protocol would then recognize those MasterCoins as distributed among the owners of that stock.
I'll mention this dividends idea on the project thread. Expect to see such a "pay everyone holding currency X" message in the next rev of the spec! |
|
|
|
|
Please note: I will be completely offline (and not even reachable by phone) tomorrow through Sunday. I'm online for a few more hours today, so if you need something from me, make sure you PM me soon. Otherwise, I'll be back online Monday. I look forward to seeing what you guys come up with over the weekend!
While I'm gone, I'm relying on you guys to answer each others questions, as you have done in the past
|
|
|
|
You guys might find this post I made in the colored coins mailing list about thin clients interesting: I haven't been following these threads closely enough, but this one caught my eye.
Meni is absolutely correct about MasterCoin transactions - they can be created by anyone, even people who don't own MasterCoins. That's why mastercoin-explorer.com and masterchest.info both have a valid/invalid flag on every transaction. (I didn't specify that they do that - they came up with that on their own).
My expectation (mentioned on the MasterCoin project thread today) is that MasterCoin will support creating IPOs and other property, as well as the distributed trading of such property by the end of the year. It appears that we are moving toward a model where transactions are created (and value is stored) on user PCs, and the state of the network is displayed on various websites which have the whole block chain and interpret it according to MasterCoin transaction rules. This separation is needed due to the long-term inability of MasterCoin to do full-featured thin clients, which Alex has mentioned in several places. Our "thin clients" will probably follow that same model, but with tighter integration with available web services.
However, MasterCoin can never do a trust-free thin client like colored coins can. The best we can hope for is having multiple websites giving us the state of the network so we hopefully don't have to trust one website completely. |
|
|
|
Dacoinmaster,
Would it be possible to create a short video (and post it on YT) that would explain in simple English what your project is about? My gut feeling is telling me it is something big, but I can't conceptualize it. Pictures would be welcome explaining how e.g. this decentralized exchange would work. Seeing a picture will help understand your project more than words. Pictures stay in brain for a longer time.
The reason I ask for this that I am neither a good speaker of English (which is a minor problem), but I am also a non-techie (which is a bigger problem).
Let me give you an example of a non-techie level: when you speak that Mastercoin protocol is a higher level protocol built upon Bitcoin protocol and you give the example of http built upon tcp/ip, then I neither have a clue of tcp/ip is nor have knowledge what http is (except for I use http everyday - but I have no clue what it is - it is too abstract).
Thanks
It is possible to understand the potential of this project without understanding the technology, but you DO have to have a pretty good grasp of how markets work to understand the explosive potential of MasterCoin. You also need to be able to understand the limitations of bitcoin as it is today. Putting on my marketing hat for a moment: Somebody with a background in trading stocks and other assets will immediately grasp how groundbreaking it is to have distributed, unregulated exchange between assets, and the ability to pseudo-anonymously (as anonymous as bitcoin can get) place bets on real-world assets. There is an UNBELIEVABLE amount of money waiting for something like this, and only ~600k MasterCoins. If, on top of all that, the escrow-backed currencies work as I expect, the real-world applications for distributed currencies with stable values would make MasterCoins yet another order of magnitude more valuable. The difficulty of understanding the potential of MasterCoin is not a limitation of technical understanding, but a limitation of understanding how markets work (and how freakishly big they are), and a limitation of imagination. Our ~600k MasterCoins are worth about 12000 BTC at current prices (about $1.5M). MasterCoins don't have a huge market cap right now because there are also a lot of risks. A TON of very real risks from numerous sources (potential competitors, technical risks, security risks, etc). However, I believe we are on track so far to overcome those risks. Can anybody else add to that marketing pitch? |
|
|
|
I agree that with the shutdown of BTCT it would be perfect timing for Mastercoin to come up with a smart propery feature. Share issuers are actively looking for new ways to do their business, e.g. the issuer of RSM is reaching out here on Google groups. Also, I want to bring attention to this posting about colored coins / smart property. The OP killerstorm about Mastercoin: To progress faster, we need more developers.
But not just more developers, we need developers who can participate in design of protocols and architecture, who have opinion on various design considerations, and who can make decisions on their own.
Even though we do have several developers now (working in their free time, i.e. after the day job, on weekends, etc), but only I'm responsible for all planning, design architecture, etc. So it is the bottleneck: when I'm not making a progress, project isn't making a progress.
So in the light of btct.co announcement, it is a pressing issue now. It might be a good opportunity for issuers to switch to colored coins, but software isn't ready yet, and if we won't increase development speed, it will be too late.
There are many competing projects, for example, Bitshare, Freimarkets, Mastercoin.
But with colored coins we had almost-working software back in January of 2013, and design was reviewed by many people, so it might be the best thing to deploy quickly.
Also colored coins is one of few projects which allows trading in Bitcoins directly, with no reliance on 3rd parties.
The only other one I'm aware of is Mastercoin, but Mastercoin's design is often criticized as being immature.
I think that this topic should be priority #1 right now – because Mastercoin could solve a burning problem. J.R., would it be possible to fund a special developer force to work on this? This begs the question, isn't the intention for this project to find independent leadership? J.R., you've made it clear that Mastercoin takes a priority below many other things in your life. Shouldn't the big hustle be in finding a project manager so there can be effective structure and direction brought to the development? I realize this is partly the purpose of the coding contest, but are any other steps being taken to find talent? I've been discussing this with the board regularly. We're not sure if we'll be able to negotiate for and find the right full-time hire, but we ARE committed to spending more project money to spur development forward at the maximum possible pace. I expect that once the coding contest is finished on 10/15, we will immediately launch another contest. The next one will probably have a bigger prize, and will be awarded once we reach the next major project milestone rather than on a specific date. Distribution rules will be similar to the current contest (rewarding wide participation and collaboration), as that incentive structure seems to be working really well (although most contestants seem to be motivated more by working on something awesome than getting paid). Now that we know how we will be storing data in the block chain for advanced features, the next major milestone is distributed exchange. Once we have that exchange running between bitcoin and MasterCoin, we'll have a foundation upon which to create and trade smart properties for IPOs and and other property. I'll be handing out a LOT of money over the next few months. I'm hoping that the project milestones will fall at a rate of about one per month. You can see the list of milestones here: https://bitcointalk.org/index.php?topic=265488.msg2841329#msg2841329If I'm right about one milestone per month, our community will be issuing and trading MasterCoin-derived properties like company IPOs by the end of the year. It could happen considerably sooner - it all depends on how much time our coders can commit to new feature development. I agree that smart property has the potential to be the first "killer app" for MasterCoin, and implementing it could cause MasterCoin prices to explode upwards. |
|
|
|
The foundation can be controversial (I doubt anybody completely agrees with everything they've done and supported, and some of their members are quite controversial), but I'm a member because they are doing a great job of building a community of people working on world-bending (and world-saving) ideas. Also, I'm controversial myself, so who am I to judge |
|
|
|
I'm not fully understanding all the technical specs currently. But with BTC-TC who's winding down and the current developement/tools/knowledge is it possible to offer an elegant prototype solution to handle shares of an asset over the bitcoin protocol/with mastercoin protocol within a few weeks ? It's a good timing to do so I think because a lot of speculation are done also about the possible shutdown of the 2 others important securities exchanges which are Bitfunder and Havelock. And without these exchanges, a lot of people are afraid to hold only bags of non-existing shares.
With what happened to Btc-tc and the SEC inquiries, that would be a KILLER feature in a perfect timing (and very profitable).
Hmmm. A lot of people seem to be excited about this feature of MasterCoin. I went ahead and bumped it up a few places in the list of project milestones: https://bitcointalk.org/index.php?topic=265488.msg2841329#msg2841329Now it's listed right after distributed currency exchange. Once we've got the distributed exchange going, we can jump right into Smart Property (which allows for creation of IPOs, which should just seemlessly work with the distributed exchange logic. Thanks for the idea! |
|
|
|
That looks beautiful A full MasterCoin wallet will eventually have to support display of dozens and dozens of currencies (and smart properties). Most users may not care about Test MasterCoins right now, but handling both coins is a good way to start thinking about the UI needed for all those kinds of coins. |
|
|
|
The video is not working / no longer available / internal error - something like this. Can you repost this video on YT please? MasterCoins are intended to be an investment opportunity [...]
Is there a chart service showing the value of this investment over time? The video is working for me at that link. Is anybody else seeing errors at that URL? No charts yet. That will undoubtedly come with implementations of the distributed exchange |
|
|
|
|
Show Posts
