Yes, that's correct!

You can currently trade Mastercoins and Test Mastercoins. To buy, sell or whatever you need a few Bitcoins for the fees, because Mastercoin is build on top of Bitcoin and uses Bitcoin transactions to facilitate Mastercoin transactions. You may get a small amout of Mastercoins and Test Mastercoins via http://mastercoin-faucet.com to start.

Those two videos are probably also helpful:

http://masterprotocoleducation.org/how-to-send-mastercoins-from-masterchain-info/
http://masterprotocoleducation.org/how-to-sell-and-buy-mastercoins-through-the-decentralized-exchange-and-masterchain-info/

Haha thanks...

Please tell, if you need anything else. We are here to help.

Hehe, I see you used the faucet!

Okay, the problem here is that you need some Bitcoins there, because you actually send a Bitcoin transaction which includes the Mastercoin data. If it's a simple send, then you'd need about 0.000341 BTC (probably a little less) in that address, if I'm not mistaken.

This is how a simple send transaction would look like:

https://blockchain.info/tx/5d78eeace44ed05d6cc1642c00ba1d6be4cd666d5dce870b9cff15a624929b48


Here is some explanation about the involved amounts. What we are dealing with is a "class B" transaction:

https://github.com/mastercoin-MSC/spec#appendix-e---understanding-the-cost-of-master-protocol-messages

Do you have a blank char/space within this address?

Try to copy this line:

Can you tell me what you put in the fields or make a screenshot? Of course per PM is fine. I'll take a look and try to help.


Did you already see this video tutorial? http://www.youtube.com/watch?v=P_gOu566EOU

You can probably skip the first half of the video and start at 5:33. Edit: this video is about sending MSC.

Edit: there is also one about buying and selling: http://www.youtube.com/watch?v=2aJyQATQx3Y

I don't use the blockchain.info wallet, but I think I found a way: Can you go to your blockchain.info wallet - "Receive Money" and then click on "Actions" right from your address? There should be an option called "Show Public Key". A line like this should appear:


The last long thing (which will start with 02, 03 or 04) is your public key!

Hey guys,

over the last days I tried to look out for edge cases and errors, so they can be fixed and I have the impression that the developers do listen to feedback and try their best.

I'd be interested in your opinion what you would improve in particular. Let's discuss and work this out, so everyone is happy!



Actually the multi sig output does include your public key, but in a compressed form, if I'm not mistaken?

See for example:

204e02988b1a7262d90168dfe4574a69b3ab6617dddfc3737e6a296ec4d17b8f:

Input:


Output:




Do you have bitcoin-qt running? If that's the case, please navigate to Help - Debug Window - Console and enter:


This should result some lines including one with "pubkey". This is the one you'd need to copy.



I think trades of Mastercoin vs. other-currency-than-Bitcoin are yet to come. Nice idea by the way with escrow.  Any idea who would be the escrow partner in this case? A wallet provider?

I agree, adding more currencies to Omniwallet would be awesome! There are also some bounties attached to this task, maybe you can take the lead and push it so that Doge is included, too? http://mastercointalk.org/index.php?topic=185.0

Because this thread is now revived:

OP is a well known troll. I tried to give him direct instructions and assistance on IRC via PM about how he could rebroadcast/chain the transaction with a fee attached so it would confirm in time. He simply ignored my offer.

I think there are two ways:

You can calculate the transaction size by taking each subitem into consideration (e.g. public key, signature, outputs etc.) and determine the fee directly. All those numbers should be fixed, but I think this is probably a pain. Or you create the transaction, sign it, check the length and adjust the fee, if necessary, and sign again.

I could create a lookup-table for all included parts, if that would help? E.g. one uncompressed public key = 65 byte etc.

This is the most important part related to this transaction. Over 1 KB size = 0.0002 fee required to be treated as standard transaction. If this was issued via one of the wallets, the wallet creator needs to adjust to take transaction size into consideration asap. Delayed transactions due to insufficient fees can be a game breaker, if MSC are bought via DEX and the time window closes before the transaction confirms.

My first thought was "why the hell..?", too.

Consider it as anti-spam fee.

Feeless alternatives are encoding within the multi sig outputs similar to XCP or using OP_RETURN.

I'd like to sign up.

Could you outline the escrow use case? Are you referring to MSC/BTC or something else?

Ahahahaha this is hilarious.

What a coincidence:



Source: Google => http://www.kotek.pl/kotek/1,87050,6453318,Kotek_bedzie_mial_dowod_osobisty_.html


Edit: Un-cat-yfied:



Source: More Google => http://wyborcza.biz/biznes/1,100896,8648619,Czy_zagraniczna_firma_wyprodukuje_nam_nowe_dowody.html

There is only one account with a balance of 453.8649    BTC in the Gox database, but it very, very likely not yours or VMC:

http://mark-karpeles.com/m.php
http://mark-karpeles.com/m.php?page=trades&user_id=203786

I fully agree with grazcoin. Rejecting transactions because they are in the same block is not intuitive and I don't see any real reason why this should be enforced in the first place. How do you handle payments for accepts that are in the same block?

An advanced and somewhat risky play could be for example: I send an accept offer transaction and use it's change output to send the payment right after. In this case both transactions will most likely be in the same block (but ordered) and I get my MSC as fast as possible - though I run into the risk that I pay for something that was not accepted and already sold/canceled, but that may be acceptable.

Re the case above: worst case I see right now could be that users start to spam accept offers, but in this case they still need to pay all MSC related fees (the DEX fee + Exodus anti spam fee), so this should be allowed in my opinion.

In general: by using the change of the previous transaction the order within a block can be enforced and given the fact that most MSC wallets probably only have dust outputs and one large unspent output available for the next transaction, the order is given very naturally.

Awesome, really not much of a change.

Not sure about this:

Case 4 and 5 basically allow to have no input public key included, but case 6 requires one, more or less?

Thanks. Yes and I agree, keeping it as simple as possible, would be good.

Okay, I'll try to cover a few cases I found:


1. https://blockchain.info/tx/bda81e0c2117fb6ecefb92143995a6ebc3d9569f54c4a0c074ff3070bcf3e011

Input: compressed public key
Output: compressed input public key, data-package #1, data-package #2

No conflict.


2. https://blockchain.info/tx/95b10a4721a69a1028e70fd2ccd0692219095fb6f5087b9e72b155a3e0832602

Input: uncompressed public key
Output: uncompressed public key, data package #1

Conflict: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (has only one compressed public key)


3. https://blockchain.info/tx/f8e2eb56f50f7a98a8c76ef45ed591aedd8aa973c5f4dfd5b7685aae4b48ae6c

Input: uncompressed public key
Output: compressed public key, data package #1

Public key was compressed, but that's no conflict.


4. https://blockchain.info/tx/4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a

Input: uncompresssed public key
Output: compressed public key with flawed prefix byte, data package #1

Conflict: "As one signatory must be the sender for redemption purposes, ..."

"Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (not the case, because of a small flaw during the compression [prefix "02" instead of "03"], so this output is neither redeemable nor the sender's address)


5. https://blockchain.info/tx/2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a

Input: compressed public key
Output: unknown package, data package #1

Conflict: "As one signatory must be the sender for redemption purposes, ..."

"Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (not the case, because the first package has no relation to the input address)


6. https://blockchain.info/tx/1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235

Input: uncompressed public key
Output: data package #1, compressed public key

This is an edge case. All data packages are ordered (it's only one) and it includes the sender's address.

No, I'm not. The order of packages should be required.

I tried to formalize this with something like "use the longest sequence of MSC data-packages within a transaction's output with ascending sequence numbers, starting from 01 and in the case that multiple multisig outputs are available, the same should apply, but starting from last-seq-num + 1", here an example:


This gives some space to cover the transactions that are already out which don't fit exactly in the schema "sender-pubKey, data #1, data #2".

I don't suggest to change anything, but to be very specific about how packages are handled.

Didn't receive the mail you quoted, but including the pubKey shouldn't be required, at least on the spec level, and as you said, it's not validated at the moment anyway. Keep also in mind that the number of n-of-m multisig parts will rise and won't be limited to 3. Actually those are already "accepted", but the standard client refuses to send them.