Re: Black holes

[ghost]

The spec has this to say about sending versioned transactions above the currently implemented versions:

Protocol implementations are expected to keep pace with changes of this nature, but in the event one falls behind, it must treat addresses which broadcast messages using version numbers it does not recognize as "black holes". That is, any funds or properties which enter the control of that address are considered lost and unspendable, since that address is using a newer version of the Master Protocol. In the event that the out-dated implementation is upgraded to recognize the new message formats, the blockchain can be re-parsed, and nothing will be lost.

My question would be, are prior funds effected by sending a version of a transaction higher than the currently implemented one?

As an example, if I were to send a v5 simple send, would all the transactions on the address become black-holed?

[m21]

@petertodd was a proponent of this feature and I like it as well. But I didn't consider this implication.

I specifically need clarification on this statement: "any funds or properties which enter the control of that address are considered lost and unspendable". Does this include the funds that were in the address prior to its faulty broadcast? If so, the funds are stuck in the address forever (say a random message with v100 was broadcast).

[dacoinminster]

As with many hypothetical things people could do, I think the answer is "don't do that". :)

Given normal users doing normal things with normal implementations, this upgrade path should be reasonably smooth.

On Fri, Aug 8, 2014 at 8:31 AM, Michael notifications@github.com wrote:

@petertodd https://github.com/petertodd was a proponent of this feature and I like it as well. But I didn't consider this implication.

I specifically need clarification on this statement: "any funds or properties which enter the control of that address are considered lost and unspendable". Does this include the funds that were in the address prior to its faulty broadcast? If so, the funds are stuck in the address forever (say a random message with v100 was broadcast).

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/239#issuecomment-51617341.

[m21]

Thanks @dacoinminster

The only question I now have is: are all funds locked, i.e. funds that were in the address prior to the faulty TX as well as any funds that are received afterwards?

[dexX7]

@faizkhan00, @m21:

The black hole approach itself is horribly flawed and there was already some discussion + ideas:

https://github.com/mastercoin-MSC/spec/issues/111

Long story short: blacking out anything "unknown" is like a contagion that hides the whole system. The main problem: you do know how legit transactions looks like, but you don't know anything about "higher version" transactions. Maybe it's just junk? And in the case where "the complete balance" is set to zero, the result is a global blackout. ;)

The most promising approach right now is to define prefixes and version numbers to narrow down the scope and in the best case to seperate "balance reducing" and "balance crediting" parts of a transaction.

Here is a related example:

A simple send reduces the balance of the sender by the given amount. We later added crowdsales to the system which added the mechanism "if a simple send is sent to an address with an ongoing crowdsale, then also consider the send as participation in the crowdsale".

Old clients don't recognize the later part, but still understand the simple send component of this transaction.

Now think of this:

tx 0, version: 0 -- simple send, reduces balance by X, does .... tx 0, version: 1 -- simple send extended, reduces balance by X, does ... and does something else on top ...

Clients which are capable of understanding the extended version will execute the send as well as the new functionality. Right now regular clients probably render this transaction as invalid, because they only know [tx: 0, version: 0] and not [tx: 0, version: 1] ...

The idea, as mentioned, is to not invalidate this transaction and reduce the balance of the sender by X nevertheless. This allows that old clients continue to maintain a somewhat accurate view of world whereby some parts are blacked.

Say for example [tx: 0, version: 1] behaves like a simple send as we know, but on top X ActivityTokens are created out of thin air and credited to the sender. Old clients will proceed as usual, but think the sender's ActivityToken balance is 0 whereby new clients also know the sender's ActivityToken balance is now X.

Edit: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03890.html from Peter is worth a read.

Let's ignore for a second version numbers and other transaction types, but take a look at tx 0: simple send, tx 20: sell for bitcoins and tx 21: sell for tokens. What those transactions have in common is that the sender's balance is reduced by the currency and amount defined in the beginning of the transaction:

A ruleset for future clients could look like this: all transactions and potential transactions with a type number between 1 and 21 are balance reducing, if the transaction begins with a currency identifier and number of coins field.

This is just an example, but I hope the idea is clear.. :)

[dacoinminster]

I forgot about all that drama - you are right dexx. Whatever we do, we are certain to need to manage the release process and backwards compatibility of MasterCore carefully.

On Fri, Aug 8, 2014 at 1:31 PM, dexX7 notifications@github.com wrote:

@faizkhan00 https://github.com/faizkhan00, @m21 https://github.com/m21 :

The black hole approach itself is horribly flawed and there was already some discussion + ideas:

111 https://github.com/mastercoin-MSC/spec/issues/111

Long story short: blacking out anything "unknown" is like a contagion that hides the whole system. The main problem: you do know how legit transactions looks like, but you don't know anything about "higher version" transactions. Maybe it's just junk? And in the case where "the complete balance" is set to zero, the result is a global blackout. ;)

The most promising approach right now is to define prefixes and version numbers to narrow down the scope and in the best case to seperate "balance reducing" and "balance crediting" parts of a transaction.

Here is a related example:

I think this is a good example: a simple send reduces the balance of the sender by the given amount. We later added crowdsales to the system which added the mechanism "if a simple send is sent to an address with an ongoing crowdsale, then also consider the send as participation in the crowdsale".

Old clients don't recognize the later part, but still understand the simple send component of this transaction.

Now think of this:

tx 0, version: 0 -- simple send, reduces balance by X, does .... tx 0, version: 1 -- simple send extended, reduces balance by X, does ... and does something else on top ...

Clients which are capable of understanding the extended version will execute the send as well as the new functionality. Right now regular clients probably render this transaction as invalid, because they only know [tx: 0, version: 0] and not [tx: 0, version: 1] ...

The idea, as mentioned, is to not invalidate this transaction and reduce the balance of the sender by X nevertheless. This allows that old clients continue to maintain a somewhat accurate view of world whereby some parts are blacked.

Say for example [tx: 0, version: 1] behaves like a simple send as we know, but on top X ActivityTokens are created out of thin air and credited to the sender. Old clients will proceed as usual, but think the sender's ActivityToken balance is 0 whereby think the sender's ActivityToken balance is now X.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/239#issuecomment-51653620.

[m21]

Interesting discussions you've had on it.

So for now -- the spec is wrong and black holes as documented are not to be implemented. Correct?

[dexX7]

Yes, and only the following transaction types are valid (to my best knowledge of how the clients handle this):

Tx 0, v0: Simple Send Tx 20, v0: Sell mastercoins for bitcoins (without action field) Tx 20, v1: Sell mastercoins for bitcoins (action field added) Tx 22: v0: Sell tokens for bitcoins Tx 50: v0: Create property Tx 51: v0: Create crowdsale Tx 51: v1: Create crowdsale (edit: missed that, note: spec is not accurate here) Tx 53: v0: Close crowdsale

Not active:

Tx 3, v0: Send to owners (unsure, if already live) Tx 21, v0: Sell tokens for tokens Tx 52, v0: Promote property

[m21]

Pretty much @dexX7 TX51 has V1.

So to confirm -- no black holes, everything outside of those above is invalid.

Who will delete the "Black Holes" from the spec or move it to Future section?

[ghost]

Based on the discussion's progress, I moved the black-holes part of the spec to 'future additions', please discuss this change there: https://github.com/mastercoin-MSC/spec/pull/242/files