Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 7. (Read 448462 times)

This is how I'd formalize a class B transaction:

• has an pay-to-pubkeyhash-output to the Exodus address.
   
• has an "input reference" which is a public key within the input script sig whereby multiple inputs are allowed, if they all originate from the same public key. This allows parsing on an atomic level. The spec further allows to add different inputs and choses the one with the highest summed value. This comes for the cost of the need of fetching all input transactions in the worst case, but allows more freedom on the other hand.
   
• has valid Mastercoin transaction data encoded with the "input reference" within multi signature output(s). As far as I know the current implementations parse and identify data-packages in the following way: [don't care] [data package #1] (optional: data package #2).
  
  I'd generalize the choice of data-packages to something like "treat several outputs as a stream of potential data-packages and chain the longest sequences of MSC data-packages within transaction's output with ascending sequence numbers, starting from 01" (see an example here). No generalization is needed, if the data-package length is less than 61 byte which is currently the case for all accepted MSC transactions.
   
• has an "reference output" where the transaction requires such reference which is a pay-to-pubkeyhash-output not to the Exodus address, a data package or any form of the "input reference".
   
• all output values are >= dust threshold.
   

My wording is probably fishy.. but let me summarize how I think about this: as long as there is no ambigiousness (which shouldn't be the case) this explicitly allows to not include any form of sender's public key. This is of course not desired in most cases due to potential redemption, but I think the lack of the sender's public key shouldn't render the transaction as invalid to allow all forms of compression, faulty public keys and odd cases where the multi sig output may be redeemable by the user, but not by the "input reference" - without any further need of verification or checks. Keeping it a) as simple as possible while b) being as open and general as possible is what I would aim for to not create artificial limitations that may be hindering in the future.


Agreed. Forced compression does probably more harm than good.


Well, I'd say those are two different issues. One is the actual encoding and the other one is the redemption of multi signature outputs. I agree that OP_RETURN data-packages would be nicer, but I currently don't see how 40 bytes could be enough to store the data.


Good thing then that you raised this point. I think this kind of feedback is crucial and should be very welcomed.

This all is pretty technical, so I suggest to continue in the dev thread maybe?

You're using Mike Hearn's narrow definition of smart property. It has become a far more general term that encompasses deeds, titles and shares.

It's dynamic new area and expect movements and shifts to occur, especially as everyone wants a bigger slice of the pie. Greed is a big component here.

Keep in mind that Charles Hoskinson from Ethereum was sacked by Protoshares due to some kind of disagreement and decided to start Ethereum. We don't know the details and what happened exactly. This is what he told me in a pm January 3rd before actually announcing Ethereum: According to his own words, Invictus fired him. So Ethereum project came to life after Charles got the boot from Invictus.

Ethereum got some initial hype and press time due to their hyped presence at the Miami convention and might have drew in few people. Suffice to say Vitalik tried to have his way with Mastercoin, by creating a scripting language but that proposition carried way too much risk to be considered. There is a reason why Bitcoin doesn't do script. This is one of the areas where Charles didn't see eye to eye with Protoshares team. Invictus (Protoshares) saw the downsides of a scripting language, which can be huge and can delay a successful implementation by years, yes YEARs. Why do you think Ethereum is set to launch Q4 only if all goes well? That's a big if. Ethereum wants to be some kind of Java and Java developers to this date keep patching it up to fix many security issues. Sure, might work with random stuff apps but it's a major pain when there are financial assets and sensitive data involved. Everyone should read this article http://blog.mastercoin.org/2014/02/04/should-the-master-protocol-do-scripting/

Tachikoma was working on Linux wallet. Not the most high priority item at this point.  

I appreciate the response.


I do not think that it is by any means reasonable to think that a client is close to a "high bar for usability" if it doesn't recognize the outputs of a transaction it created, signed and broadcast, cannot spend unspent outputs which it is (cryptographically) capable, and creates multisig outputs that cannot be spent by a key pair in the wallet - let alone the fact that there are only native Windows clients, and those with other OSes must manually handle WIF private keys in order to use the web wallet.

I've been pretty jazzed about mastercoin, however recently it seems esoteric, loose, and out of touch with the user. I bought at exodus last year, I was one of the first to attempt decentralized trades back in mid November, and I was one of the first to succeed on the 15th. Yes, it's groundbreaking, and yes, trades can be made. But mastercoin doesn't have a specification that describes current implementation, the clients privilege Windows users, and the depth of understanding in bitcoin required to spend Class B outputs (i.e. not bloat the blockchain) is a great bar to entry.

Nobody comments on why Tachikoma and his friend went to Etherium just a month after he agreed to work full time for Mastercoin? Nobody cares who is working on the reference implementation of mastercoind now? Why people keeps believing or wishing but never really ask these kind of important questions? Trying to prove mastercoin is better than counterpary, Etherium, or whatever else does not help anything. We, the investors of MSC, should keep asking questions to JR, Ron about the current status and the real reason why the 2/3 of full time developers (they spent so much time in hiring them in the first space) leave.

Great you ask. This topic was recently discussed in the dev thread. I'll try to say something to each point:


Correct.


It doesn't matter, if someone has access to the Exodus address in the context of identifying transactions nor does the identification mechanism has any implications related to (de-) centralization.

Agreed, in terms of transaction costs the approach of magic bytes makes XCP transactions cheaper for the user. If it's much better? Well, I think that's rather a matter of personal opinion than something that can be generalized. All you can represent is your opinion and it seems I have a different one. This is probably the reason why you stick to XCP and I primarily prefer MSC. The trade off was already outlined: cheaper transactions vs. resilience and contributing to further improvements. And I'll bite: what happens, if a XCP bounty fund raiser loses the private key to the bounty wallet?

I'm not 100 % sure what you are addressing right now - that there is an output to the Exodus address or that JR holds the keys to the coins that were raised to fund Mastercoin?

Magic bytes in the payload is just simply a much better way of identifying transactions. It's cheaper, it's truly decentralised, and it doesn't send J.R. any of your money for bogus hand-wavy reasons like "DOS protection", which Bitcoin obviously handles itself through standard BTC TX fees.

What if someone steals the private key to the Exodus address from J.R.? What if he loses it? Why take the chance?

'Smart property' isn't really something that Mastercoin, or Counterparty, has anything to do with directly. The Mastercoin Project just loves throwing around such buzzwords. 'Smart property' is hardware (like a car) that might itself, for instance, parse Bitcoin, or Mastercoin, or Counterparty transactions, and behave differently depending on what it sees (e.g. unlock itself only for someone with a particular private key). The only real prerequisite technology at the protocol level is virtual assets, which Counterparty has totally working and Mastercoin hasn't even begun to implement.

A 'smart contract' is a more general idea, and really applies to any contract enforced by a protocol. Bitcoin, Mastercoin and Counterparty all have these to varying degrees. Counterparty undeniably has the most sophisticated and diverse smart contracts at the moment, though. The only smart contracts implemented in Mastercoin that I know of are those of its mostly-still-in-the-planning-stages distributed exchange.

as a btc holder I'm glade XCP exists. Without direct competition, MSC team would even be relax and slower than they already are. NXT crap / Ether / Emunie / Skycoin and what not are eying add features that Bitcoin lacks.

LTBCoin is probably only smart contract that brings bit of hope to Counterparty. I have, though, some reservations but I won't go into details. Suffice to say it might not end up on Counterparty entirely. Adam Levine is thinking of spreading it out over other 2.0s like Mastercoin (he said so in his last live video chat). I won't be surprised it won't make it on Counterparty at all, as Mastercoin's advantage becomes more obvious.

Mastercoin will have dozen of them in Q2-Q3 ranging from decentralized "dropbox" type app to 3rd layer coins. Adam Levine, LTB owner, is working with Mastercoin on GoxCoin. This will be one of the Mastercoin 3rd layer coins. http://www.humint.is/goxcoin/


Adam Levine doesn't get paid by Mastercoin PR department. You are probably confusing it with Next, which buys LTB ads on regular basis.

For the sake of clarification:

• If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?
• Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?
• The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?
• The mastercoin spec states that a Class B transaction must satisfy the following: "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." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
• Is a Class B transaction valid if the multisig output is to an uncompressed public key?
• Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?
• Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?
• With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?
• When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.

I guess we'll see.

Its funny how Lets Talk Bitcoin gets paid by Mastercoin's PR department to do so many segments on Mastercoin, but they are themselves releasing LTBCoin on the Counterparty protocol. Or so I have heard.

@Patel

You twist and bend the facts to your liking. I've just knocked out every claim you've made in your previous post. You are clearly rooting for the wrong team here and this will become very obvious to you in Q2 and Q3 of this year.

The stuff Counterparty released is something Mastercoin could have released many months ago but didn't because would have been poor quality work. Mastercoin had a trial exchange in testing for months.

You ignore the very important cash position Mastercoin has and the plethora of smart apps that will make it into the Mastercoin ecosystem in Q2 2014. http://blog.mastercoin.org/2014/03/14/development-update-9-impending-dex-launch/

MSC can work on several projects at the same time by offering multiple bounties, in effect having a very large dev team. Counterparty stands no chance to compete. Check their bounty section on website. It's empty. They can't afford any.

I think this is a great misunderstanding. Initially there was a huge amount of Bitcoins raised and sent to the Exodus address to create something very innovative - the Master protocol. Those coins were and are used to pay for bounties and whatsoever and controlled by the Mastercoin Foundation - whose members are those with a high stake in this game (if I'm not mistaken). This means: coins in the Exodus wallet = funds for the project itself.

The output to the Exodus address is another thing: there are several ways to tag and identify a meta-transaction, for example transactions can be created with an additional output to a specific address (Master protocol) or one could encode some magic bytes (XCP) within the data payload. Or one may use OP_RETURN with some magic bytes etc. etc. ...

But there is actually another reason: DOS protection. DOS is not yet an issue and may not be in the short term, but for the same reason that there is a DEX fee (XCP and MSC both use one) or a Bitcoin transaction fee in general, this is a filter against spam.


Re MSC vs. XCP: both projects follow different approaches, for example:

Pre-funded by the community vs. ongoing funding by donations
Coins were bought by funding the project vs. proof-of-burn
Transaction marker is an output vs. marker is encoded within the data payload
An additional transaction processing fee is raised vs. no additional transaction processing fee
Many developers and different parsing engines vs. one implementation
Only sellers in the DEX orderbook vs. buyers and sellers
...

I wouldn't say one or the other is better or worse - each approach has benefits and downsides. In the end XCP is a MSC fork and because of this there are of course great similarities, but I hope over time more differences will emerge and I'm very curious where all this leads to.

Please explain how Counterparty copied Mastercoin. You keep saying that, but what did they copy exactly? Code? No, there was none written.

The ideas behind Mastercoin still have not been fully coded, and they have with XCP.

You can bash it all you want, but XCP is still ahead right now. Mastercoin lost its first mover advantage a while back. Ethereum is going to overtake Mastercoin soon. They have many well-known, competent, developers, you can't dismiss it because it has a few flaws while its still in conceptual phase.

I would like to hear your argument about how Mastercoin can be sustainable for more users, when there are 4 different implementations with different consensus most of the time. They should have designed something like mastercoind from the start, and everyone could use 1 specific reference.

Nothing but pretty much cloned the whole thing. Only problem is they aren't going anywhere and people who invested in them hoping they've got Santa Claus by the feet will realize this soon enough. I'm sorry for you if you sold MSC to buy Counterparty. Big mistake.

Worth reading about the many flaws Ethereum model has http://blog.mastercoin.org/2014/02/04/should-the-master-protocol-do-scripting/

MSC the decentralized exchange in most advanced stage. Nothing competition has comes close.
JR sold small stake of his position to join the project full time, so stop spreading lies and bullshit. He quit his real life job to put full focus on this project. http://blog.mastercoin.org/2014/01/24/j-r-coming-full-time/

This is another fat lie. Ever heard of this guy? https://twitter.com/brockpierce http://en.wikipedia.org/wiki/Brock_Pierce



The Mastercoin 2014 Roadmap for those interested https://trello.com/b/DzHG5qJY/roadmap

Usually, when one is only left with insults, the argument is lost.  For the record, I own both MSC and XCP equally.

Chill out. I am just asking questions. That implied I know I am ignorant on the subject and have stuff to learn.

You for real or joking? Are you guys part of some trio of jokers doing free advertising for Counterparty in this thread? Your statement sounds surreal at best.

Herp, give credit where its due.

Counterparty copied nothing from MSC because there was nothing to copy, code wise. Ideas may have been taken, but they were fully coded by the XCP developers before MSC even had specs written. Give credit where its due.

Mastercoin had a 5 month head start, and Counterparty was announced around January 1st I think. With a 2 man crew, PhantomPhreak and Xnova did more development work and implemented more features than Mastercoin has done in 7 months. And even now, with Mastercoins, you can't do anything more than let it sit. Its been 7 months, and the only thing you can do is trade it back and forth. It has no use (yet) besides that.

Mastercoin is going downhill, and Ethereum + Open Transactions is gonna put the nail in the coffin. Believe it.

After 7 months, they still are having issues parsing transactions and getting consensus. This is a huge issue in my opinion. Also Jr controlling 30% of the coins, doesn't help. Jr even cashed out his initial 1500btc investment. So he could care less if it fails or not. And no stable release of a wallet after 7 months.

The only real person which has vested interest in Mastercoin succeeding is David Johnston because his Bitangels company invested like $5 million worth of BTC into this project. And of course, people who bought in after the IPO.

The good thing Mastercoin has is good PR and marketing. Besides that, they haven’t delivered anything profound yet in 7 months besides promises.