Re: MasterCoin: New Protocol Layer Starting From “The Exodus Address”
The "to sender" multisig output should be defined as one of the following ...
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.Share a private key, yes, however do not have same WIF private key, public key, or address. If some mastercoin outputs are spendable by a compressed address, and other outputs are spendable by the corresponding uncompressed address, then both should be represented in the wallet and identified as such.
The implication of a client automatically receiving/signing transactions for both the compressed and uncompressed versions of the key pair is that the mastercoin 'unit of identification' is a private key, and thus two key pairs. This isn't compatible with any other client that I'm aware of, can be a privacy leak, and security risk if one of the WIF private keys is compromised.
I agree with intelligent input selection, however I'd not be inclined to use a wallet that treats two key pairs interchangeably, especially if both pairs were not represented and identified as such.
The implication of a client automatically receiving/signing transactions for both the compressed and uncompressed versions of the key pair is that the mastercoin 'unit of identification' is a private key, and thus two key pairs. This isn't compatible with any other client that I'm aware of, can be a privacy leak, and security risk if one of the WIF private keys is compromised.
I agree with intelligent input selection, however I'd not be inclined to use a wallet that treats two key pairs interchangeably, especially if both pairs were not represented and identified as such.
Agreed. Forced compression does probably more harm than good.
I see Class B transactions as a great transition to Class C transactions - but if Class B transactions are not depreciated, and multisig output dust is not properly handled, the implementation of Class B transactions does little to address the intent behind eliminating unspendable outputs. Sure, it technically does not create unspendable outputs, however it's a cop out to say that Class B transactions address the concern of blockchain bloat due data storage. Others may disagree, but as far as I'm concerned if outputs of a transaction are not recognized, cannot be spent, or are otherwise not used in transactions when reasonable, they will not be spent and are subject to loss due to perceived lack of value or understanding.
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.
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.
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?
