|
You can't use test Bitcoins, sadly. I've lobbied to get an official Exodus on testnet but so far it has not happened yet.
|
|
|
|
I'm happy to report that the first distributed Mastercoin to Bitcoin transaction using the Mastercoin protocol has been done.
Congrats Tachikoma, this is just awesome! It's just incredible how fast this is evolving. Is the "Create new Selling offer" tool on your site already functional for public use? In theory, yes. I used this myself to create the transactions. It does require some knowledge of bitcoind/qt command-line though, I've written some instructions here if you want to give it a go. Also remember I'm only allowing test Mastercoin transactions. However the Bitcoin you are using to send the messages is always real so be careful you are not using high values for your offers if you decide to create one. hey Tachikoma, I am thinking to make this into a tutorial and put it in the next weekly update, so that you get some more exposure and people test this out. I would suggest that you add in a feedback or bug/issue button somewhere that goes to your github repo so that if people try this out and have problems they can note it in there. i am going to try this out tomorrow myself, you might hear from me if I get stuck  Awesome idea. People do need to realise though that these Selling/Purchase offers might be invalidated if we need to change the spec a bit. So when testing always use tiny amounts of Bitcoins as selling value since if you do a 'real' trade your Bitcoins won't be returned to you. I hope to find some time this weekend to implement Purchase/Selling offers into my Wallet software. This should make the whole process much easier. |
|
|
|
The solution I think is to add some logic to decoding to calculate the amount of reward MSC at the blocktime of the transaction during decoding but I'm still working on the details.
Mastercoin-explorer is already doing this. So for my code the outline I presented works, I think ^^
Yeah, I think we should use the timestamp of the most recent bitcoin block, rather than the node's local clock.
I guess the full formula is actually (1-(0.5^y)) * 10% * total number of mastercoins bought at 1Exodus before the deadline
Could somebody confirm my vesting calculation is correct? Let's set the time to 2013-10-31 10:45:45 +0100 the output I get for the Exodus vesting is MSC 6103.51504811. |
|
|
|
|
The Mastercoins that are being vested on the Exodus address could in theory be used as an extra reward for Miners. We could even build it into the protocol if we wanted to. However, for now I would prefer focussing on supporting more Mastercoin messages.
|
|
|
|
Just so I understand it correctly: The 'earned' amount of Mastercoins for the Exodus address at a given time is 1-(0.5^y). Correct?
This is trick since this does not depend on the Bitcoin protocol. A Mastercoin node who's time is drifted more then a few seconds might invalidate certain transactions. Should we perhaps somehow tie the vesting to Bitcoin?
Yeah, I think we should use the timestamp of the most recent bitcoin block, rather than the node's local clock. I guess the full formula is actually (1-(0.5^y)) * 10% * total number of mastercoins bought at 1Exodus before the deadline Having something in the blockchain already would make my job easier on supporting it. If you could send out a transaction and give us the hash that would be great. Also you should already have an MSC address for me, since I took part of the original bounty in MSC as boss  btw for the "Rewards MSC" how will this be implemented? Any simple send made by the Exodus address will be a valid generated MSC?
This is what I propose. Whenever Exodus sends a transaction do the following. 1. Get the balance of received transactions that the Exodus address might have received. 2. Get the date of the of the block the transaction got added in. 3. Generate the reward coins based on this date. 4. Add the received transactions and reward coins together and substract any send transactions. 5. If enough balance is left for this transaction it's valid, otherwise it's invalid. Should we also support other Mastercoin messages from the Exodus address or just simple sends? |
|
|
|
|
The security is in how you protect the private key of your Bitcoin address that holds your Mastercoins. The only way to spend Mastercoins is by creating Bitcoin transactions using that address. The only way to do that is by signing transactions with your private key. So as long as you keep your private key safe your Mastercoins are safe.
|
|
|
|
Hello folks,
Very excited about all the developments in the Mastercoin.
Great feat of engineering with amazing financial implications, all using the bitcoin protocol!
A Newbie question:
How is a Mastercoin indicated in a Bitcoin wallet, to differentiate from regular Bitcoins?
It's not, a Bitcoin client won't know anything about your Mastercoin. I have heard mention of the Mastercoin explorer to show transactions and address.
Is that the only way to verify that you have MSC???
http://mastercoin-explorer.com/, https://masterchest.info/ and http://masterchain.info/ should all show your balance. If you are adventurous you can also download one of the alpha wallet-software that I and other developers are working on. Although I wouldn't recommend it yet at this point. |
|
|
|
|
Just so I understand it correctly: The 'earned' amount of Mastercoins for the Exodus address at a given time is 1-(0.5^y). Correct?
This is trick since this does not depend on the Bitcoin protocol. A Mastercoin node who's time is drifted more then a few seconds might invalidate certain transactions. Should we perhaps somehow tie the vesting to Bitcoin?
|
|
|
|
|
If that's the case I would also setup an IP filter, just in case. I know this would rule out a lot of University/Office/Proxy based users but it will also greatly reduce the abuse.
|
|
|
|
Hosting is not cheap. Especially if you want to do it in a secure fashion. Secure hosting is needed since the server needs access to a private key with a sufficient Mastercoin balance. I also doubt that the people who will go for a 500 USD bounty are the same the people who know how to securely host and build their code. But I hope I'm proven wrong |
|
|
|
|
Of course, these are the rules set out by Bitcoin. If we don't follow the rules are transactions won't be accepted and relayed/mined.
|
|
|
|
|
Of course this is too hard. That's why we are developing Mastercoin wallets.
|
|
|
|
I used the Multibit client to send my BTCs to the Exodus address. Can anyone tell me if this presents any problems given the discussion above re. selling coins? Thanks in advance!
I have asked something similar in the past, and the answer that was given to me was to use qt or armory, because only from these wallets can an outgoing MasterCoin transaction start. Correct me if I am wrong. i used blockchain (which apparently also works) so i certainly hope you are wrong. I don't think you can use multibit because it doesn't allow you to send to multiple addresses in the same transaction. I also originally used multibit, but I have exported the private key from multibit and imported to a blockchain.info wallet so I could send them if I want to. Thanks for the replies. So, I just need to import the private key to a wallet that supports sending to multiple addresses in the same transaction such as Bitcoin-QT or Armory? I haven't used bockchain.info. It's web-based, correct? Thanks. Yes, either Bitcoin-qt or Armory will do the thing. Also, this sendmany transaction has to originate from the bitcoin address in which your Mastercoins are located. So for qt, if there are bitcoins in other addresses in your wallet, you'll have to send all of them first to that Mastercoin address. And this has to be done each time you send Mastercoins, because of the way qt handles change. You can also lock all other outputs then the ones from your Mastercoin address. |
|
|
|
Sadly from what I could find out Blockchain.info doesn't let you sign raw transactions. So for now creating either a Selling/Purchase offer requires either a Mastercoin wallet or a way to sign a raw transaction.
Ah..that's what I was guessing also after digging around. I'll try with another instance/qt-client later - just think its kinda fun that way vs. same console. Thanks for clarifying the time limit. I guess I'm wondering what the effects of this could mean compared to traditional, centralized exchanges. It seems like it could make for some pretty interesting market scenarios (manipulations?) and trading strategies if one can keep an eye on expirations/completions of other trades and offers for a given currency/share. That's basically why you can set the required Bitcoin transaction fee. To discourage sending fake offers. Although if there is enough many involved this of course won't stop it completely. |
|
|
|
Did someone mention that they successfully sent an exchange message on the forums? I thought I read it yesterday, now I cannot find it. Sorry about the trouble just trying to stay upto speed.
BTW, is there there an interest in forking the Bitcoin QT client to support mastercoin?
Thanks,
Dan
Yeah I did a successful exchange on Sunday. The post can be found here. If you guys think there are better ways though let's look at those I already said before that flexibility is welcomed for more advanced uses of mastercoin. I'm not sure I agree with this - the whole idea of using the sender for change (which I believe both Tachikoma and I do) is to 'solve the change problem' in the simplest manner. This is a strategic question that we are dealing here with, and more people have to decide on this (J.R., board, ...): Do we want masterchain to be future compatible or not?I obviously think that the answer is YES, and I try to come up with solutions that keep the common tx simple, but leave an option for more advanced uses (in a similar way to bitcoin's protocol approach). Any solution that enables reasonable future compatibility is fine with me. Taking zathras comments into consideration I modified my porposal to the following: TX with 3 outputs: exodus, recipient, BIP11 - is valid (trivial case). The redeeming public key inside BIP11 MUST be the one of the sender. TX with 4 outputs: exodus, recipient, change, BIP11 - is valid (change case). Like above + the change MUST go to the sender (to identify easily the recipient). TX with more than 4 outputs (future compatible) - valid ONLY under the following set of rules: - Exodus and recipient outputs MUST have the same value (we have it already today).
- Change MUST go to sender (tachikoma+zathras suggestion).
- Pubkey in BIP11 MUST belong to sender (tachikoma+zathras suggestion).
- Other outputs CANNOT have the same value like the Exodus one.
"Other outputs" (which are easily detectable) are ignored for mastercoin purposes. If tx has more than 4 outputs (the advanced sender uses future-compatible feature intentionally), the sender knows that by not following the above 4 rules, his tx will be invalid. I think for now we have enough ways to send the messages, we just need to code up support for more of them. I'm happy with the current implementation and think we should leave this discussion for when we are a bit further along. |
|
|
|
So..I have some time to mess around a bit and trying to buy the test coins from my sell offer. Have some basic questions I hope you don't mind answering.
I made a purchase offer and verified the transaction using mastercoin-explorer. I'm buying using an address at blockchain.info and sell is from qt wallet so I'm a bit unsure of how to apply the steps in this scenario. Is it possible to send an acceptance message using the tools available at blockchain.info? or are both parts of the transaction only possible currently with bitcoind/qt on either side?
Just so we are talking about the same things, the terms I use are "Selling offer" for the message telling an address is selling X amount of coins and accepting such a message is a "Purchase offer". Now the problem is that you will need to able to create a Mastercoin message from both wallets. Sadly from what I could find out Blockchain.info doesn't let you sign raw transactions. So for now creating either a Selling/Purchase offer requires either a Mastercoin wallet or a way to sign a raw transaction. Also, when I set the sell, I put a time limit of 6 blocks. Can you explain the function of the time limit? Sorry if this was explained elsewhere and I missed it or its just simply common knowledge I lack - I want to make sure I'm not making wrong assumptions.
The time limit is the time in blocks in which to send the payment in Bitcoins after accepting a Selling offer. If you send the funds later then the time limit the purchase will not be recognised. Just FYI you could in theory use the same client for all messages. An other wallet is in theory not needed. |
|
|
|
The same can be said for normal Bitcoin clients. A thin client that uses multiple servers to check for balances etc. should be safe enough. No. The difference is that thin Bitcoin client can check whether payment is valid using SPV. Have you read the original Satoshi's paper? Yes I have. I'm not saying I have a firm grasp of everything though. People were using Electrum long before it was using SPV though. I don't think it will be a showstopper. |
|
|
|
As of right now to my knowledge you cannot send Mastercoins using thin clients. You have to use either BitcoinQT or Armory. Electrum can receive Mastercoins but cannot send them
In theory you could use any client to send any Mastercoin message as long as they support an option to sign a raw unsigned transaction. Electrum can do this but the arguments it needs are a bit custom. Well, I see a problem: MasterCoin transactions are not linked together in a subgraph, so one needs to scan the whole Bitcoin blockchain to interpret them.
This means that thin clients are fundamentally impossible.
You are going to have either full clients (like Bitcoin-Qt) which download whole blockchain (8+ GB of data now).
Or server-trusting client, which undermines the whole point of having cryptocurrency. (If you are into that, just use Open Transactions: low overhead, impressive features.)
The same can be said for normal Bitcoin clients. A thin client that uses multiple servers to check for balances etc. should be safe enough. |
|
|
|
I'm happy to report that the first distributed Mastercoin to Bitcoin transaction using the Mastercoin protocol has been done.
Congrats Tachikoma, this is just awesome! It's just incredible how fast this is evolving. Is the "Create new Selling offer" tool on your site already functional for public use? In theory, yes. I used this myself to create the transactions. It does require some knowledge of bitcoind/qt command-line though, I've written some instructions here if you want to give it a go. Also remember I'm only allowing test Mastercoin transactions. However the Bitcoin you are using to send the messages is always real so be careful you are not using high values for your offers if you decide to create one. Really cool Tachikoma - decided to give it a try. I was able to set up a sell offer no problem: mastercoin-explorer and blockchainReally gotta get some sleep so didn't actually try to buy them from myself. FYI - I noticed on your instruction page you indicate "broadcastrawtransaction" rather than "sendrawtransaction" which I'm guessing is what you meant. Awesome that you managed to do it! It's not that easy. And yeah that sendrawtransaction thing, I keep typing that wrong when sending my transactions too, will update the doc asap. I also see the reserved value is wrong. I should update that. Accepting / Buying an offer is harder with Bitcoind since you need to lock all outputs that are not coming from the address you want to buy from. |
|
|
|
I'm happy to report that the first distributed Mastercoin to Bitcoin transaction using the Mastercoin protocol has been done.
Congrats Tachikoma, this is just awesome! It's just incredible how fast this is evolving. Is the "Create new Selling offer" tool on your site already functional for public use? In theory, yes. I used this myself to create the transactions. It does require some knowledge of bitcoind/qt command-line though, I've written some instructions here if you want to give it a go. Also remember I'm only allowing test Mastercoin transactions. However the Bitcoin you are using to send the messages is always real so be careful you are not using high values for your offers if you decide to create one. |
|
|
|
|
Show Posts
