Freimarkets could be deployed in Bitcoin's blockchain if the required hardfork is accepted by the network.
It will likely happen on Freicoin first, but it is a protocol extension that can operate in both chains at the same time.
And as said, order-based colored coins (freimarkets are "tag-based colored coins" according to Meni Rosenfeld) is what worries me in the current bet.
In fact, I would not want to bet against a mastercoin based on a central issuer neither (I undesrtand that's possible, isn't it?). I just want to bet against your proposed p2p derivative issued by a protocol such as mastercoin.
If bitshares claims to be able to do the same p2p derivative or similar, I would prefer the new bet not to be so specific about the bitcoin chain so that the bitshare people can also disagree with me (the more coins against me, the higher the reward if I win).
It sounds like maybe you should write this bet  |
|
|
|
I would, except I spent all my bitcoins on MasterCoins! I literally have almost zero bitcoins left! If I get more bitcoins, I might set up another bet. Hehehe, I understand. I have also spent most of my bitcoins on freicoins. Suddenly my lately preferred way to buy btc was more restricted and I would like to explore other ways... I have some because [spolier]Skyler behaved as expected[/spolier], but maybe it's not the right time to bet on this. I still think I will lose the other one because of colored coins/freimarkets though. Maybe the absence of oilCoins will safe me? Let's see. Didn't bet much because of the time horizon anyway. I don't think you're in any danger from freimarkets, since the bet statement says: This statement will be regarded as true if before January 1st, 2015 it is possible to buy, sell, trade, and spend virtual currencies which track the value of gold, oil, and U.S. Dollars, with the record of these transactions stored in the primary bitcoin block chain (emphasis mine) Since by my understanding freimarkets won't use the primary bitcoin blockchain, I think colored coins and MasterCoin are your only worry. (By the same logic, Bitshares being successful also wouldn't cause you to lose your bet.) |
|
|
|
That's a cool idea. Probably the simplest implementation would be to allow for the creation of datafeeds which are dependent on other datafeeds (and thus don't have to be actively published - they can just update any time their constituent parts update). There's no reason this couldn't work as you describe, although a lot of other work has to happen first, obviously P.S. Is bitblu going to crowdfund by selling a smart-property IPO on MasterCoin? We'll be able to accommodate that soon!  |
|
|
|
Note that I've previously mentioned that I plan to add a "pay dividend" command to the spec.
Yes, I think this would be very important! I'm wondering how much information should be embedded in the genesis of a smart property. E.g., when creating a new property, would we need to have a "pays dividend" field? And do we need to define the currency in which dividends are paid right from the start when creating the smart property? Nah. Pay dividend will just be something like "Pay X amount of currency Y evenly distributed among people holding currency Z" |
|
|
|
I wrote that bet, and it hasn't changed.
Ok, then it's my bad because I didn't read that part with enough attention. Everybody knows that colored coins exist, but I personally doubt they will be able to maintain parity with their underlying asset, due to risk of default by the issuer. That is, I don't think USDCoins will be able to hold a value of $1 each. Consequently, I don't think you'll lose your bet due to colored coins.
I think I will lose my bet because of it. If there's reliable issuers that keep their promises I think they will have parity. For national currencies like usd or eur is very easy and already happening with bitstampUSD on ripple(tm), for example. The MasterCoin project, on the other hand . . . Exactly, I know you think it is possible to make p2p derivatives through a deterministic fund with mastercoin/bitcoin reserves and that's what I intuitively think that can be exploited and want to bet against. Maybe we can create another bet we are both comfortable in the opposite sides. Would you bet on a similar prediction excluding the centralized issuer with real reserves approach as a mean to achieve the "assetCoins parity"? I would, except I spent all my bitcoins on MasterCoins! I literally have almost zero bitcoins left! If I get more bitcoins, I might set up another bet. |
|
|
|
It seems to me that the description of this bet changed after I placed my bet: http://betsofbitco.in/item?id=1210It now says: "* http://www.Bitcoinx.org is working on a decentralized exchange for "colored coins", but there is doubt as to whether such coins will maintain their nominal face values when pegged to commodities and currencies. " I agree that that usdCoins, goldcoins, oilCoins, etc can be issued and backed by a central issuer. And if they back it I expect their price to be similar to their real/paper courterparties. What I don't believe is you can do this without trusting an issuer, which is what mastercoin attempts to do and what I bet against. Did I read that part too fast when I bet or has it really changed after I did it? If it changed, I want to take back my bet, I've been talking about usdCoins with an issuer inside the chain for years, before the term "colored coins" was even coined. I wrote that bet, and it hasn't changed. Everybody knows that colored coins exist, but I personally doubt they will be able to maintain parity with their underlying asset, due to risk of default by the issuer. That is, I don't think USDCoins will be able to hold a value of $1 each. Consequently, I don't think you'll lose your bet due to colored coins. The MasterCoin project, on the other hand . . . |
|
|
|
Ah, with namespace I was actually talking about the amount of user based currencies that could exist until the unique identifiers run out. If the creation is free you can just spam creations until you fill up the 4-bytes that are reserved for identifiers.
Ah. Using up all 4 billion identifiers would require 4 billion transactions and would cost hundreds of millions of dollars at today's prices, even with no extra fee attached. That's the sort of attack that only a government could contemplate. If we also destroy 0.0002 MasterCoins every time a currency is created, we'll run out of MasterCoins before we run out of currency IDs I guess that would be a good minimum fee, since it guarantees we'll never run out! |
|
|
|
Why base the price on name length?
Well, I was trying to address the concern you raised about someone hogging the namespace. How would you set the fee? |
|
|
|
So let's talk smart assets.
A few questions I had by reading the current specs.
Currently it looks like you don't have to spend any funds to create an asset. Wouldn't this indirectly mean that if I made a small script I could register all possible currency identifiers and break the system? Perhaps setting a required mining fee amount would fix this issue.
I expect most smart-properties to be some kind of dividend paying security. With his in mind it would be great if we could explicitly supply a bitcoin-address when using the "Purchasing a Currency Offered For Sale" method to buy shares, to keep it simple we could also define that when buying smart-properties the default dividend address is the Mastercoin address used for the payment.
I agree that smart property is more important than distributed e-commerce (which would effectively make a distributed silk road). Note that I've previously mentioned that I plan to add a "pay dividend" command to the spec. I agree with Tachikoma that we ought to add some friction to creating smart properties. Rather than pay the fee in bitcoins to the miner, I think we should destroy a small number of MasterCoins (increasing their value). How about we set the minimum fee to: | Property Name Length | Minimum Fee | | 1 | 5000 MSC | | 2 | 2000 MSC | | 3 | 1000 MSC | | 4 | 500 MSC | | 5 | 200 MSC | | 6 | 100 MSC | | 7 | 50 MSC | | 8 | 20 MSC | | 9 | 10 MSC | | 10 | 5 MSC | | 11 | 2 MSC | | 12 | 1 MSC | | 13 | 0.5 MSC | | 14 | 0.2 MSC | | 15 | 0.1 MSC | | 16 | 0.05 MSC | | 17 | 0.02 MSC | | 18 | 0.01 MSC |
. . . and so on . . . In this way, most people will register "Quantum Miner Shares Class B" rather than "QM", but if someone wants to burn a lot of money on a short name, they can This is just one way we could do it - if you guys have suggestions, I'd like to hear them. My main goal is to keep it as simple as possible without creating a single hard-coded value that we'll have to change later. Incidentally, if two people DID register "QM", the second one would be displayed as "QM[2]". There's no enforcement that names must be unique - only currency identifiers, which are assigned in the order currencies and properties are created. |
|
|
|
Masterchest WalletInitial alpha release of the Masterchest desktop wallet. This is the first alpha release of the Masterchest desktop wallet. Expect it to be littered with bugs, it's a 0.0.1 release. It'll be quicker to find them if others participate in testing, so please post bad behaviour, errors, failures or crashes etc. This is a testing release only and is not fit for real usage - do not under any circumstances plug it into a bitcoin wallet with any sizable amount of bitcoins/mastercoins. Test only with an almost empty wallet.With thanks to: BouncyCastle, Newtonsoft, Tachikoma Requirements: .NET 4, bitcoind/qt RPC server with transaction indexing enabled (disabled by default in 0.8+, add txindex=1 in bitcoin.conf and then start with -reindex to readd transaction index). Disclaimer: Please use it as you see fit, but remember this is very, very alpha. You should not risk anything other than a small amount of coins (bitcoin or mastercoin) when testing. To put some context around the risks involved - consider that as we build and broadcast transactions from scratch, if we grab a 100BTC input and miscalculate the change, then a miner somewhere is going to be very happy and you are going to lose out. I'm encouraging any and all testers to spin up a VM, create a new bitcoin wallet, depsoit a fraction of a bitcoin to cover fees and then use Masterchest software with this new bitcoin wallet.Usage I think is fairly self explanatory; configure the connection to bitcoind/qt and let it scan the blockchain. It will automatically add addresses from your bitcoin wallet and enumerate their balances. Sends should be debugged first and only signed/sent once you are sure you have checked the transaction and know what you are doing. The only time your bitcoin wallet passphrase is required is to sign&send a transaction. Transactions not in a block but detected from getblocktemplate (ie waiting to be included in a block) are interpreted as unconfirmed. I have also included the option of a preseeded database which will reduce the amount of blocks needed to scan for transactions. Please feel free to ask any questions and I'll be happy to answer them Some screenshots (@50%):          Hint: This runs contained in it's own folder (ensure you have write perms!). If things go wrong just unzip again and start over (no keys are stored in this wallet, bitcoind/qt does the signing). You can also add gettingstarted# to wallet.cfg to trigger the initial setup again after first run. I cannot stress this strongly enough; this is a testing release only and is not fit for real usage - do not under any circumstances plug it into a bitcoin wallet with any sizable amount of bitcoins/mastercoins. Test only with an almost empty wallet.Compiled binary and source : https://github.com/zathras-crypto/masterchest-walletFeedback/questions always of course welcome This. Looks. AWESOME!! I'd like to take this opportunity to remind everyone that testing and code-reviewing count towards the contest! If you test, provide feedback, find bugs, do code reviews, include that in your final summary and I'll consider that when payout time comes Speaking of payout time, it's getting close! In order to make sure we don't delay too much, please make sure you are ready on October 15th to post your final list of everything you did, and links to all the source (so everybody can see it all in one place). I will ask each of you to carefully consider the other contestants and tell me (privately) how you would distribute the money among them if you were not participating in the contest. Every time I think about the payout, I get nervous - hurt feelings seem inevitable, and I want to make sure I'm not solely responsible for those hurt feelings |
|
|
|
Bitfunder.com is going to exclude US residents from trading on their platform. This could be the first step of shutting down their site (as seen with btct.co). This would cause a huge vacuum in the bitcoin stock world and would create an even greater opportunity for Mastercoin's smart property feature. I'm calling for a dedicated development team and / or dedicated smart property contest.
Yup! Future contests will be feature-driven. Basically, once we reach a milestone, the project will pay anybody who helped us get there, in proportion to the size of their contribution. As before there will be a big focus on collaboration, and probably an explicit code review requirement in the acceptance criteria. We've got to get the distributed exchange working before smart property will make sense though. |
|
|
|
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 couldn't post when I made this transaction (because the forum was offline), but it did happen: http://blockchain.info/tx/fe12cbb37bf81f20feede134a00a31b8b51c568072b57ed480d9994e016830b7I finally got my act together and got the disparate change outputs consolidated back at the Exodus Address again. The balance at that address now accurately reflects the available project funds again. |
|
|
|
1EmSvBt5JKufGwV214xr2NU4FWwNKpDVMK
retweet post on twitter
thanks.
Sorry bro, this giveaway is long over. Thanks for reminding me though - I still have some funds to give away to the top promoters, then I can lock this thread. |
|
|
|
|
I think I have enough information now. The uncompressed public key would be absolutely ideal IF we could be confident that the bitcoin core devs were friendly to our cause. However, some of those guys are openly hostile to us, and if anybody in that group supports us, they haven't said so publicly.
Grazcoin, I hope you won't be sad if we hold onto your idea until we are more established? It's clear to me that we can't use it exclusively right now. We might be able to support both types of transactions, but I don't want to make things more complicated than we absolutely have to.
I would LOVE to get a CTO working full-time on this. That is one of the stated goals of our coding contest. I'm too expensive, and after some private conversations with Tachikoma, he's probably too expensive also, although I won't close that door completely until he does.
The board and I have bandied about 40 BTC/month as a suggested salary for a full-time hire, along with a generous allotment of MasterCoins, vesting like stock options.
Even when we have a CTO, I'll probably make the final decision on core issues like this, or at least reserve veto power.
So, for now, let's use Tachikoma's method. Once we are firmly established and/or the core bitcoin devs become friendly to our cause, we should switch to grazcoin's implementation, or at least support it.
Zathras - I haven't heard anything from you in awhile. What have you been up to?
|
|
|
|
maraoz sent me a PM bowing out: Hi J.R.
I'm out for now, personal problems + lack of motivation. If you guys think what I did so far contributed in any way, I'll accept part of the bounty. If not, I've already considered all the invested hours lost.
Just need something from zathras now. Thanks guys! |
|
|
|
First amendment protects us to create these neutral tools. We have no criminal intent by creating Mastercoin, it's not like we created it on the sole, primary, or with even any intention to break laws, which I believe a prosecutor would have to show. In any regard, JR getting snuffed legally seems very unlikely and trivially defendable. I suppose that you're alluding to recent events, and that is a very real threat by "fatally idealistic", but in the end, considering likelihoods of various risks, JR, would you agree that Mastercoin is too important not to press on? Getting killed by my government is very low on my current list of worries. I very much doubt they are paying attention to this project yet. If they do start paying attention, they would have no reason whatsoever to bother me. I'm developing a very powerful set of tools, and any powerful set of tools can be used for bad purposes. They have no more reason to hassle me than they have to hassle Gavin. If they did hassle me, I'd probably stop what I'm doing, but there would be no shortage of people well-qualified to take my place. I've heard Gavin make similar statements. I'm not out to destroy my government. Crypto-currencies do threaten to destroy our existing monetary systems, but that is simply because they are superior, not because they are malicious. It is in the government's interest to keep people like me involved - I'm not hostile to my government, and I'm very easy to keep an eye on. Why would they want to risk my being replaced by an anonymous anarchist? I tend to think of the government as inept, but even I don't think they are that inept. |
|
|
|
|
What are the advantages of using uncompressed public keys?
I'd really rather not rely on transactions which are non-standard in any way if they can be easily distinguished from normal bitcoin transactions. It wouldn't be very long before somebody introduced a "patch" to "fix the problem" (and exclude our transactions). I get the feeling that there are a couple people (at least) who have that kind of clout and wouldn't mind making an object lesson out of us. I don't want to make it easy for them!
What would be involved with "rotating" the data? Would the benefits of this method be worth the extra effort of the rotation and un-rotation?
Thanks!
|
|
|
|
grazcoin's work summary, sent via PM: Hey guys, please update the contest thread when you get a chance: 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.
Thanks! I try to collect the tasks I did in arbitrary order: cheers, Grazcoin |
|
|
|
Don't forget being targeted for encouraging money-laundering. If you think this 'protocol' idea isn't going to be under scrutiny from the Federal authorities, you're mistaken.
I'd recommend dacoinminster to return all the funds and take his ball and go home, before he ends up in a cell next to Dread Pirate Roberts.
But of course, he'll rationalize a way not to suspend development.
To my knowledge, nothing we are doing breaks any laws. We are building tools, which users could use to break laws, just like any tool. Speaking of dangerous tools, this whole silk road situation brings to the forefront of my mind something that has been percolating for awhile. The MasterCoin protocol could be rather trivially extended to support decentralized e-commerce. For instance: - Define a message for declaring what you are selling, your alias name and a link to a webpage with more info (if webpage gets taken down, simply rebroadcast this message with a new URL)
- Define a message for a buyer to initiate a purchase, with funds held in escrow by the protocol
- Define a message for a seller to accept a purchase initiated by a buyer (required before a buyer can complete payment and leave feedback)
- Define a message for a buyer to complete the transaction (either destroy funds in escrow or pay them to seller)
- Includes feedback as a rating number and a link to a webpage with feedback comments
- If purchase is completed successfully, a percentage of funds are destroyed (to make it more expensive to create fake feedback) Percentage can be lower once seller is established)
If we made something like this, it would then be possible to parse these messages to create a list of sellers and their reputations (and buyers and their reputations). Identities would be tied to bitcoin addresses. Payments would be in MasterCoin (or MasterCoin-derived currencies). I'm not sure we'll ever do this though. I'm not sure there are enough legal use cases to justify it! |
|
|
|
|
Show Posts
