Complete seperation of data layer by removing "reference address"

[omnilayer]

Complete seperation of data layer by removing "reference address"

[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.