New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use notifications to enable features #104

Closed
zathras-crypto opened this Issue Jun 30, 2015 · 23 comments

Comments

Projects
None yet
4 participants
@zathras-crypto
Copy link

zathras-crypto commented Jun 30, 2015

This issue is to discuss and gain consensus on the concept of using notifications (similar to the alert system) to activate features instead of using a hardcoded blockheight in the source.

I propose that:

  • We use a message to activate features instead of hardcoded source
  • Said message may only come from Exodus
  • Said message will contain the transaction type, version, and blockheight for go-live
  • Said message can be superseded by a new activation message with a later blockheight, in the event that we discover a critical issue and need to push back activation

This provides us with more granular control of feature activation, but most importantly allows us to do releases more frequently without always guaranteeing everything "beforehand" as it were.

Thoughts please :)

@dexX7 dexX7 added the feature label Jun 30, 2015

@dexX7 dexX7 referenced this issue Jun 30, 2015

Closed

Release process and plan for 0.0.10 #93

11 of 13 tasks complete
@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jun 30, 2015

  • There should be a hardcoded minimum/grace period, between the time the notification was received and the activation, so that users are guaranteed to have a chance to update, and as security buffer, in case keys got compromised. 1000 blocks?
  • NACK on Exodus, at least at this very moment: I'm still waiting to get a contact info, to fill the blanks for the alert system. Other than that though, Exodus would be suitable.
@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jun 30, 2015

I suggest to move the following into rules.cpp:

- enum TransactionType
- enum BLOCKHEIGHTRESTRICTIONS
- bool IsAllowedInputType()
- bool IsAllowedOutputType()
- bool IsTransactionTypeAllowed()

Maybe the Exodus address and marker, too?

Once done, the height restrictions could be transformed into a datatype, which allows inserting new entries.

Ideally, rules are "per network", i.e. "main", "test", "regtest".

@msgilligan

This comment has been minimized.

Copy link
Member

msgilligan commented Jun 30, 2015

I'm -1 on this idea because it seems too centralized of a solution. I realize there is already of level of centralization in the software release process, but this makes it explicit in the protocol.

I'm wondering if there is some variation of an idea that @zathras-crypto brought up in the all-hands that might work. That idea was using the version number of a particular transaction type. For example once 90% of simple sends are using version n of that transaction a new feature will become enabled within x blocks.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jun 30, 2015

I'm -1 on this idea because it seems too centralized of a solution.

Did you know about the alerting system, which was deployed with 0.0.9? It can be used to show messages in the status bar, and remotely shutdown (outdated) clients.. :S

It's not a good feeling to have that power, but the usefulness outweights the cost in my opinion. To make it less intrusive, there is the command-line option -overrideforcedshutdown, as well as options to add or ignore "alert senders" (via #68).

Now regarding the transaction enablers: it's equally centralized than hardcoding a number, but it has the potential to prevent disaster, and similar to the alerting system, users should have the option to add or ignore such messages.

I like this idea of signaling via some mechanism, though I think transaction volume can very, very easily be exploited.

@msgilligan

This comment has been minimized.

Copy link
Member

msgilligan commented Jun 30, 2015

equally centralized than hardcoding a number

With a hardcoded block number there are two checks on centralization that don't exist with a signed transaction enabler:

  1. Users must voluntarily install the version with the new feature and activation block number.
  2. Anyone can fork the software and make a version with a particular feature and activation block number.

In a technical sense, those two checks remain with transaction enablers, but we've now set an expectation among users that the enablers are the way to do upgrades, pushing them further towards centralization.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 1, 2015

Sorry, what are you referring to with "signed transaction enabler"? "Enable via notification" or "enable by send-version-signal"?

Users must voluntarily install the version with the new feature and activation block number.

And likewise users must install an updated client explicitly, which supports new features, which are enabled via notifications.

Anyone can fork the software and make a version with a particular feature and activation block number.

... but we've now set an expectation among users that the enablers are the way to do upgrades, pushing them further towards centralization

For what it's worth: anyone could still fork the software and edit the whitelisted notification sources. Or simply overwrite them via the configuration file, but I see your point.

I mean, the initial idea is certainly not intended to increase centralization, but to refine the activation mechanism. Instead of a hardcoded number, defined by a central party, the central party would have the ability to set the number on the fly. I proposed that "after the notification, there should be at least 1000 blocks" to make it less "arbitrary", and to define some boundaries.

In the long run I'd like to move into the direction of "user defined protocol settings", where users could "vote" and influence values like STO fees, but at this point I wouldn't consider something like this as feasible option to enable new transaction types at this point.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 1, 2015

Just wanted to add a note, a good point was made about liability for whomever sends such activation messages, because that entity could be deemed as having control (and thus some liability) over parts of the Omni layer.

Thus if we do go the messaging activation route (and I still advocate we do) I think the best route would be for activation messages to come from a multsig address controlled by the Omni Foundation, such that the foundation (and not any individual developer) is the entity responsible for activating features.

Hope that makes sense :)

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 1, 2015

And @msgilligan just to re-iterate @dexX7 sentiment, everything we do is override-able by the user - we're setting the 'default case' (which is required for consensus).

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 1, 2015

multsig address

Yes, please. And if this is going to happen, then the alert keys might as well be replaced.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 1, 2015

But just to underline: I see @msgilligan's concern, though I don't see alternatives, and thus suggest we move on with the proposal, unless you have anything else in mind than "signaling via simple-send-version".

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 2, 2015

Yes, please. And if this is going to happen, then the alert keys might as well be replaced.

I'm not so sure on the alert side - it could take an extended period of time (ie days) to contact all parties (board members? whoever is nominated I guess?) and handle signing of a transaction "from the foundation" - that's a non-issue for a pre-planned event like feature activation but in the event of something going wrong we might lose valuable time that we could be warning users...

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 2, 2015

Ahh, that's a good point.

Right now there is no handy way to create P2SH raw transactions from within Omni Core, and #77 does the trick, but I'm not sure, if this should be a priority at this point.

What do you suggest?

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 4, 2015

I still advocate for a P2SH address from the foundation for feature activation as it doesn't really matter if this takes a little time, I just meant regarding alerts specifically we should keep that a bit looser.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 6, 2015

I started with #116, but if you already have a PoC, please don't ditch it. This is one of the things I don't see it as a bad thing, if we have more than one potential implementation.

From a higher level, I think we should specify the mechanism first. Here are a few notes, I have in mind right now:

  • it should probably follow the format of other transaction types
  • we could easily add a few lines to parse the packet (like interpret_SendToOwners())
  • likewise, there should be a logic handler, similar to the other logicMath_XX() methods
  • I suggest to use type = 65534, version = 65535, which would be similar to the notification transaction (i.e. count backwards)

What's unclear to me right now is how the actual transaction might look like. Probably something like:

[type=65534] [version=65535] [feature identifier] [activation height]
@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 10, 2015

See my comment on #116 but to note:

From a higher level, I think we should specify the mechanism first. Here are a few notes, I have in mind right now:
it should probably follow the format of other transaction types

Agreed.

we could easily add a few lines to parse the packet (like interpret_SendToOwners())

Agreed. see interpret_Activation() on my branch 0.0.10-Z-DexX-FeatureActivation.

likewise, there should be a logic handler, similar to the other logicMath_XX() methods

Agreed, see logicMath_Activation() on my branch 0.0.10-Z-DexX-FeatureActivation.

I suggest to use type = 65534, version = 65535, which would be similar to the notification transaction (i.e. count backwards)

Agreed. CMPTransaction class has been expanded a little to handle the data for the feature ID and the activation block.

What's unclear to me right now is how the actual transaction might look like. Probably something like:
[type=65534] [version=65535] [feature identifier] [activation height]

Not probably like, exactly like my friend!! hehe :)

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 11, 2015

I've looked over #129 and it looks extremely good.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 11, 2015

I'm wondering, if we should move away from allowing everything on testnet/regtest.

I think ideally all upcoming features should be explicitly enabled, to allow testing, and to do test activations on testnet. Similar to the alerts it should be possible to add or ignore certain senders, and the min. and max. interval on testnet and in regtest mode should be more flexible, say for example min. two days on testnet, and min. 3 blocks in regtest mode.

This isn't necessarily a requirement for the upcoming release, but certainly something for the future. On the other hand, testing via regtest mode should probably be done before deploying it in the wild.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 11, 2015

Now thinking a bit far in the future: if we get to a point, where black holes and feature activation fits together, and we establish a concept of "local consensus" - that means: "I only care, whether a specific action succeeds, and this can be determined with a much more limited view, and I don't to need to know everything" - then we may move into the direction of "features as plugins", which may not even be provided by the foundation/core team. Or rephrased: I imagine it might be possible to get to a point, where features are no longer hard forks, but opt-in, and this could open a lot of possibilities.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 11, 2015

I've looked over #129 and it looks extremely good.

Thanks dude :)

I'm wondering, if we should move away from allowing everything on testnet/regtest.

I agree with this - I'm on my way out now but I'll make the appropriate changes soon...

Now thinking a bit far in the future...

That's a very interesting idea - confine certain actions to only a subset of the state - not sure how that would work in practice but definitely agree it would open up some further potential!

@stebansaa

This comment has been minimized.

Copy link

stebansaa commented Jul 23, 2015

Upon a new feature is activated, should that display a message in the client so that the user can accept new terms and conditions; thus reducing any liabilities by the parties activating the feature,

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Jul 27, 2015

@stebansaa brings up an important point: we currently don't have any visual notification that a new transaction type might be activated at some point in the future.

While I don't really see the need for another disclaimer/warning (we show one on startup on mainnet), it would probably good to know, given that, at least in the context of the MetaDEx, new features and actions are available.

Maybe we could show one info dialog, when an activation message was successfully processed, and another one, once the feature is activated?

Something along the lines of:

The distributed token exchange was unlocked and is now available. [...]

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Jul 28, 2015

@stebansaa brings up an important point: we currently don't have any visual notification that a new transaction type might be activated at some point in the future.

I'm not sure I see the problem - along with an activation we would send an alert out would we not? This would display a message to the user along with shutting down their client at the live height if the client doesn't support the new feature.

Perhaps there is some crossover between notifications/alerts and activations, and I certainly don't disagree with more info for the user (such as on receipt of activation message etc) but perhaps we should think of the ideal process we want to see, and then perhaps adjust the alerts and activations to work accordingly?

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Aug 4, 2015

The feature activation via notification was added with #159. While I think we should continue the general discussion about this mechanism, I'm going to close this issue for now, and suggest to open a new one, for the specific topic to discuss, once there is something to discuss. :)

@dexX7 dexX7 closed this Aug 4, 2015

@dexX7 dexX7 added the consensus label Sep 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment