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 |
|
|
|
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. why don't you answer me , will current "Mastercoins" aka MST get wiped out or are you planning a buyout of sorts?  thank you looks like you are keeping busy here Why would you even think that would happen? |
|
|
|
As I mentioned a few posts back I'm transitioning priority from web wallet to desktop wallet - could I solicit a little feedback on UI design? What do you guys think? I'm thinking of dropping test mastercoins from the overview as my feeling is most 'regular' users wouldn't be interested - thoughts?  Thanks That looks pretty awesome  |
|
|
|
The latest version supports sending multisig Mastercoin-transaction via Bitcoin-Qt (or Bitcoind). However as always please be very careful what you do. It's very basic but the same logic could be used by any full-fledged Mastercoin client. Mastercoin-explorer will also recognise multsig transactions now.
This is HUGE! I tried to create a new transaction, but got an error. Should "New Transaction" be working right now? Hopefully the rest of you are working on parsing these transactions too! All our new features beyond simple send will use this method (until we find a better way such as if we decide to switch to OP_RETURN once it is fully supported by the network). Yeah it should work but it's very fragile at the moment. You can paste the error here but I rather do it over pm or irc (#mastercoin) so we don't pollute the topic. I'm already working on turning this into a 'real' wallet that should be less fragile. I wanted to say one thing about web-wallets. Please don't host other peoples money; if you really want to build a web-wallet please make it at least client-side encoded so that no important data can be leaked. It would be very easy to build-in a web-wallet to mastercoin-explorer but I'm not doing this for a reason, it will get hacked. If not sooner, then later. |
|
|
|
I've added a quick JSON-API on top of mastercoin-explorer. You can find the documentation here. |
|
|
|
The library behind http://mastercoin-explorer.com is now available on Github. At this moment it can do the following: - Decoding and encoding Mastercoin-data from addresses
- Decoding and encoding Mastercoin-data from public keys
- Decoding multi-sig Mastercoin-data from a tx hash, requires bitcoin-ruby node
- Decoding normal Mastercoin-data from a tx hash, requires bitcoin-ruby node
- Advise address-based Mastercoin transaction
- Calculate Exodus coins bought based on address or transaction-id
- Create and send multisig-encoded Masteroin transaction
|
|
|
|
I'm back in action after being tied to the bed for the last week. I've released ' Masteroin-ruby' which is the library behind mastercoin-explorer.com. I am trying to keep the readme up-to-date whenever I update it. The latest version supports sending multisig Mastercoin-transaction via Bitcoin-Qt (or Bitcoind). However as always please be very careful what you do. It's very basic but the same logic could be used by any full-fledged Mastercoin client. Mastercoin-explorer will also recognise multsig transactions now. I've send three (invalid, because the sending address did not buy from Exodus, did not want to send real coins until spec is finalised) multisig transactions, one, two and three. As always I hope all you other developers working around can also try my implementation so we can finalise the spec. A few things I came across. - Sequences for multisig public keys need to start with 01 instead of 00. If you don't do this more often then not the public key won't be a valid ECDSA point.
- My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
- Bitcoin-qt doesn't recognise multsig-transactions as outputs ready for spending. You will have to manually redeem those outputs.
Thanks! This should now be fixed. I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @ https://masterchest.info. This is very alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour. Woops; grats! Diversity is a good thing |
|
|
|
I've been under the weather these past days and bound to bed. I have done some initial work and I will be releasing some source code as soon I've fought of this flu |
|
|
|
CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.
It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.
The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong. Making the outputs redeemable is a good and welcome improvement -- but that doesn't eliminate their UTXO storage cost. It just makes that storage recoverable and transferable. The extraneous data continues to be stored in the UTXO set, with this multisig method. One person may redeem a MasterCoin multisig transaction, yes, but the payment target will just create another multisig output that consumes similar amount of UTXO storage space. The data continues to bloat the UTXO dataset, because there is always some multisig output sitting around, waiting to be spent. Question 1:Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat? So my advice would be:
1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach
What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs). Correct. OP_RETURN data is provably not spendable. Anything provably unspendable may be eliminated from the UTXO data set. Note! Besides OP_RETURN, there is yet another possibility: P2SH: https://en.bitcoin.it/wiki/BIP_0016With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming. This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin. I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question. Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data. |
|
|
|
CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.
It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.
The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong. Question 1:Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat? So my advice would be:
1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach
What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs). |
|
|
|
There are two types of multisig outputs available at the moment that are useful for us. While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones. What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction. I would like to suggest that we keep the original spec and use one output for the receiving address. We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output. We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.A simple encoded simple send would look like (and forgive my horrible photoshop skills):  A complete tx could look something like this: {"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}
I appreciate some feedback on this spec before I start writing code First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas: https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that. I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?" If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past ( pybond) and may be able to take on that role. I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will. I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it. I'm sorry but this pisses me off beyond believe. I've been spending a lot of my own free time, which I don't have much off, trying to help out this project. I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories. Now finally somebody steps forward who sees that something is wrong with my proposal but he wants to be paid in order to tell us what is wrong with it? Why not just specify what's wrong so we can work around it? I won't be giving this any more energy if this is the way the community is going to respond to a group effort. |
|
|
|
There are two types of multisig outputs available at the moment that are useful for us. While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones. What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction. I would like to suggest that we keep the original spec and use one output for the receiving address. We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output. We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.A simple encoded simple send would look like (and forgive my horrible photoshop skills): A complete tx could look something like this: {"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}
I appreciate some feedback on this spec before I start writing code |
|
|
|
According to #bitcoin-dev the only supported ones are n-of-3... I think we need to test it out before deciding on the final spec. Fount the answer in the bitcoind code. bool IsStandard(const CScript& scriptPubKey)
{
vector<valtype> vSolutions;
txnouttype whichType;
if (!Solver(scriptPubKey, whichType, vSolutions))
return false;
if (whichType == TX_MULTISIG)
{
unsigned char m = vSolutions.front()[0];
unsigned char n = vSolutions.back()[0];
// Support up to x-of-3 multisig txns as standard
if (n < 1 || n > 3)
return false;
if (m < 1 || m > n)
return false;
}
return whichType != TX_NONSTANDARD;
}
Seems we hit the first bump in the road. I suspect that our publickeys can't be parsed as valid ECDSA coordinates so transaction is not getting processed by nodes on real-net, 'ERROR: CTxMemPool::accept() : nonstandard transaction type'. The reason it worked on testnet is that testnet does not do strict checking before accepting a transaction. I will research to see if there is a way to somehow encode the data in a way that it looks like a valid publickey. I'm trying to figure out why it's not passing the tests. I would appreciate it if somebody could replicate my tests, perhaps I simply made an error somewhere when crafting my raw transactions.In order to replicate my tests please create a transaction with one input, two outputs. One ouput with a change address and one with a multisig script with 1 actual publickey, so you can redeem the output, and two data encoded publickeys. {"hash":"0e2183cf1d5943c130e9594c44ba3981fe046ceee8851444f4407de6da3232a7","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":371,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100ca5d8934c8acf7060e0826e52b55c7e28ae18ab2d22bd9f65b8e44f16856c6c5022100fc69c5d003607aa4114f8eae8026c549aff542ed452ac9af85328ea2b0a292f701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 04c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d9188fb464fba3911efc10ac8d1936a088f4682795b40e60aa87b43601339ec76808 045200000001000000020000000000000001000000000000000000000000000000 042600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}
Edit: Found an error in my first transaction because I was denoting it as a full publickey while I was actually using compressed ones. This one is valid according to my own tests but bitcoind doesn't like it still. The code responsible for flagging a tx as non-standard can be found here. {"hash":"e2fd41377f1fb432e9ebe5fe681a127572f0e157e326598bd217e2117e3104f5","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":338,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"304502204b08c27d0286660dfde1ee5e79060d57409f3a8eff52e5fddda3c28bf8a9e1b0022100cd5b6591bfcedd6c0cf48a8cece0d1e27baecc723fe1c81d84a7d85d4e88fd8701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 025200000001000000020000000000000001000000000000000000000000000000 022600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}
|
|
|
|
I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me.
I put an offer out there to sell 100 coins for 5 BTC.
User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins.
What happens to the 5BTC from user A that he send to the address?
First of all don't sell 100 coins for 5 BTC. Let's say you sell 100 coins for 50 BTC ;-) The BTC from A land also on the seller's address, so according to the current spec, the seller should refund it, which is indeed a problem. Solutions: - If the payment would have been done using some mastercoin-derived-currency (even with BTC face value), the protocol could have automatically handle the refund.
- Using multisig based escrow - the funds are sent by the buyer to 2-of-3 address (buyer,seller,escrow) + marker output. If the buyer sees that he is the only buyer (e.g. after 6 confirmations), he signs the tx and the seller signs it, and the protocol interpret it as a closed deal. In this case any later buyers could get their funds back by seller or escrow signature. If there is some disagreement, the escrow signs the needed tx (refund to buyer or funds to seller).
For this we need:
- trusted escrow address (it cannot steal the funds, just decide to which side the funds go to)
- everyone's public key which may be a problem (not anyone like to share their public key)
- some communication channel to transfer the half-signed tx.
Buying MasterCoins with bitcoins on the distributed exchange is actually a two-step process: 1) Signal your intent to buy, paying a transaction fee specified by the seller to prove you are serious 2) If you are recorded in the block chain as the first one to signal your intent to buy, THEN you send payment within the specified time window of your signal If you don't send payment within the time window, the MasterCoins become available for sale again. In this way, you don't risk sending payment and not being first. This is the current logic in the spec, but I probably wasn't clear enough. Here's the actual wording from the spec, with certain bits relevant to this question highlighted: Selling MasterCoins for Bitcoins
Say you want to publish an offer to sell 1.5 MasterCoins for 1000 bitcoins. Doing this takes 33 bytes, which fits into two data payments:
1. Transaction type = 20 for currency trade offer for bitcoins (32-bit unsigned integer, 4 bytes)
2. Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount for sale = 150,000,000 (1.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does, assume the user is selling all of them)
4. Amount of bitcoins desired = 100,000,000,000 (1000.00000000 bitcoins) (64-bit unsigned integer, 8 bytes)
5. Time limit = 10 (10 blocks in which to send payment after counter-party accepts these terms) (8-bit unsigned integer, 1 byte)
6. Minimum bitcoin transaction fee = 10,000,000 (require that the buyer pay a hefty 0.1 BTC transaction fee to the miner, discouraging fake offers) (64-bit unsigned integer, 8 bytes)
Selling MasterCoins for Other MasterCoin-Derived Currencies
Say you want to publish an offer to sell 2.5 MasterCoins for 50 GoldCoins (coins which each represent one ounce of gold, derived from MasterCoins and described later in this document). For the sake of example, we'll assume that GoldCoins have currency identifier 3. Doing this takes 28 bytes, which fits into two data payments:
1. Transaction type = 21 for currency trade offer for another MasterCoin-derived currency (32-bit unsigned integer, 4 bytes)
2. Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount for sale = 250,000,000 (2.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does, assume the user is selling all of them)
4. Currency identifier desired = 3 for GoldCoin (32-bit unsigned integer, 4 bytes)
5. Amount of GoldCoins desired = 5,000,000,000 (50.00000000 GoldCoins) (64-bit unsigned integer, 8 bytes)
Changing an Offer
Say you decide you want to change the number of coins you are offering for sale, or change the asking price. Simply re-send the offer with the new details. If your change gets into the block chain before someone accepts your old offer, your offer has been updated.
If you decide you want to cancel an offer, simply send the offer again, but enter the number of coins for sale as zero.
Purchasing a Currency Offered For Sale
Say you see an offer such as those listed above, and wish to accept it. Doing so takes 16 bytes, which fits into 1 data payment:
1. Transaction type = 22 for accepting currency trade offer (32-bit unsigned integer, 4 bytes)
2. Currency identifier you are purchasing = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount you are purchasing = 130,000,000 (1.30000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed number available for sale, but if it does, assume buyer is purchasing all of them)
The reference address should point to the seller's address, to identify whose offer you are accepting.
If you are purchasing with bitcoins, make sure your total expenditures on bitcoin transaction fees while accepting the purchase meet the minimum fee requested!
You will need to send the appropriate amount of bitcoins before the time limit expires to complete the purchase. Note that you must send the bitcoins from the same address which initiated the purchase. If you send less than the correct amount of bitcoins, your purchase will be for that amount. Update 9/8/2013: In order to make parsing MasterCoin transactions easier, you must also include an output to the Exodus Address when sending the bitcoins to complete a purchase of MasterCoins. The output can be for any amount, but should be above the dust threshold.
If you are purchasing with MasterCoin or a MasterCoin-derived currency such as GoldCoins, your purchase is complete as soon as you accept the offer (assuming you are recorded in the block chain as the first to accept the offer). If you have less than the correct amount on hand, your purchase will be for that amount.
Note that when only some coins are purchased, the rest are still for sale with the same terms.
If you guys have any ideas about how to make the spec more clear on these points, I'd love to hear them. Thanks! I'm not sure how this resolves the issue of having to refund a payment if all transactions happen in the same block. |
|
|
|
According to #bitcoin-dev the only supported ones are n-of-3... I think we need to test it out before deciding on the final spec. |
|
|
|
I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data. Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine. I've created a test transaction on testnet3 ( raw) to test this functionality. miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each. In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs. Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it. I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type. Please let me know your thoughts so we can continue building cool things on top of Mastercoin looks good I would try to optimize the tx so it has only 2 outpus and not 4: - 0.00006000 as marker (exodus)
- all the rest (with no separation between another 0.00006000 or change) to the multisig address, where the first multisig address belongs to the multisig sender and the embedded data (which comes from the other addresses) contains whatever we want, including the reference address, but not as a valid redeemer.
We have to keep in mind though, that fully spent transactions can be pruned (for keeping the blockchain smaller), and then we lose the mastercoin information. Good point, reducing the outputs sounds like a good idea. I am personally using bitcoin-ruby as backend so pruning won't be a problem. (Although having 40GB worth of blockchain data ain't pretty neither). Do you know if '1 out of X' transactions where X is higher then 3 are fully valid transactions? |
|
|
|
Ik heb het al met Phedny overlegd maar voor de compleetheid. Ik ben ook van de partij wanneer we tot actie overgaan |
|
|
|
I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me. I put an offer out there to sell 100 coins for 5 BTC. User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins. What happens to the 5BTC from user A that he send to the address? Tachikoma: can you please verify that we have identical parsing?
Will do this ASAP. Edit: They match 100% |
|
|
|
I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data. Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine. I've created a test transaction on testnet3 ( raw) to test this functionality. miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each. In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs. Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it. I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type. Please let me know your thoughts so we can continue building cool things on top of Mastercoin |
|
|
|
|
Show Posts
