Complete seperation of data layer by removing "reference address"

[dexX7]

TL;TR: I propose to introduce a new transaction field to make the use of reference addresses obsolete. This completes the seperation of transportation and data layer and allows to pack multiple transactions into one.

The current situation:

The Master protocol was created to allow a rich set of new transaction types and is build upon the Bitcoin protocol.

1. To identify a potential Mastercoin transaction every Mastercoin transaction has an output reference to the Exodus address.
2. Pay-to-pubkey standard transaction outputs or multi signature outputs are used to transport data. The data is encoded and converted into the base58check format as part of an pay-to-pubkey standard transaction output ("class A") or as public key equivalent in multi signature outputs ("class B"). Sequence numbers are used to make sure the interpretation of transaction outputs is unambigious and further allow to split data into multiple, ordered packages.
3. Such transaction data is parsed and interpreted according to the Master specification.

Some transactions use an additional output to reference an address ("reference address"). It is furthermore permitted to use an output for the remainder of the input ("change").

Limitations:

Using multiple, additional outputs such as "change" and "reference" output requires to implement rules to determine the role of an output due to the potential ambiguousness and creates several limitations, such as:

• Change can only be sent back to the input address, otherwise it wouldn't be possible to determine, if the output shall be treated as "change" or "reference" output.
• Besides the "reference" output only one other non-data output is permitted which must be a "change" output with a reference to the input address.
• Very obvious, but most important: only one "reference address" is possible.

  A reference is just data:

When seeing the Master protocol as combination of modular layers such as a transportation and data layer, the usage of an output as some kind of source of information appears to be an overlap between the layers.

I therefore propose to treat "reference addresses" as what they are - a part of transaction data. I furthermore propose to introduce a new data field which acts as substitute for the "reference address" output.

Benefits:

This completes the seperation of data and paves the way to consider different layers of the Master protocol as something modular.

But most important in my opinion: it also paves the way to make use of the several thousand byte data storage capacity of class B transactions.

Without the limitation of one "reference field" per Mastercoin transaction, it could be possible to chain transactions within one transaction. This allows in particular multiple sends without creating new transaction types.

Transactions could be chained by either treating additional data after the first complete parse of a transaction as a new transaction which would require to use fixed length data fields or the usage of data field length properties, or by using "transaction seperators".

This all is of course not to be considered as final proposal, but intended to start a discussion. Input is very welcomed. Cheers!

[ripper234]

@dacoinminster @marv-engine - please review.

[dacoinminster]

Sorry - I meant to comment on this earlier, but apparently I didn't.

Having an output to the reference address has a couple advantages too:

• The recipient gets a ping when somebody sends them money, even if they are only using a standard bitcoin wallet
• The recipient wallet can send the money out again using the BTC received as part of the outgoing transaction, such that if the incoming transaction gets invalidated, the outgoing transaction will also be invalidated. This removes the need to wait for confirmations if you want to immediately use money you have received.

Both of these advantages would be lost if we merely encoded the recipient address in our data fields.

I think if we make a change in this direction, it would need to be a new multi-send transaction type. Perhaps this new transaction type could also take multiple balance inputs.

[ripper234]

Please make sure to consider #77 if/when making progress on this issue.

[dexX7]

The recipient wallet can send the money out again using the BTC received as part of the outgoing transaction, such that if the incoming transaction gets invalidated, the outgoing transaction will also be invalidated. This removes the need to wait for confirmations if you want to immediately use money you have received.

That's an interesting argument. One could do almost trustless escrow-free trades. Say I want to buy MSC from you directly, but I don't trust you enough to simply send you BTC: you could prepare the transaction and tell me the TXID. I then could build the BTC transaction which includes your output. If you - for any reason - invalidate the MSC send transaction - you'd also invalidate my BTC payment. (edit: invalidated due to the potential of a double-spent, since the tokens are not bound to the output exclusively)

I haven't thought much about use-cases, but a simple multi-send is the most obvious one, if multiple transactions could be chained and I thought seperation should be a general goal. :)

Edit: after reading #77, this idea for another use-case came into my mind. Some say address reuse should be avoided, so one could attach another send of the remaining balance to the next wallet. Say I have 5 MSC and I'd like to send Ron 2 MSC, I then could create a chained transaction:

Input: [My wallet A with 5 MSC], Output: [Tx1: Send 2 MSC to Ron] [Tx 2: Send 3 MSC to my wallet B]

[dacoinminster]

If we do this, it will be under issue #54

[ripper234]

If you don't mind, I'll reopen this is as a reminder.

The reason for reopning is it seems to be two completely separate issues - I can see us doing one but not the other. Why not keep both open for the time being?

[dexX7]

Even though it doen't seem to be in work since yesterday, I literally stumbled upon this pretty much the day before:

A similar concept is currently implemented in XCP which moves references aka. destinations onto the data layer, seperated by an underspace to allow multiple recipients. Haven't reviewed it completely yet, but it also seems like multiple senders are possible as well (and data packs are now obfuscated).

https://github.com/CounterpartyXCP/counterpartyd/pull/ 298

Edit: it's actually much less neat as expected.

[dexX7]

Small note and addition:

A seperator is not necessary, if there is a terminator at the end of a chain, e.g.:

[transaction 1] [transaction 2] [...] [0x0000]

This aligns well with current transactions, because due to the fixed length of a data package embedded as public key, we usually end up with zero padding at the end anyway.