api-market / ore-protocol Goto Github PK

Go through all branches in the ore-protocol repo (and other repos), close branches that are no longer needed, merge branches where necessary into master

@traylewin commented on Mon Jan 21 2019

@traylewin commented on Wed Oct 24 2018

The rights registry should be able to remove a right if it is not referenced by any instrument.

We should only do this if it's relatively easy to do.

We might also consider adding a 'retired' flag to designate that a right is no longer usable.

@surabhil commented on Wed Nov 14 2018

• Add "encrypedWith" field to instrument_data
• Update licenseapi to take in following inputs in adddition to existing inputs:
  • additionalUrlParams to add to voucher's additionalUrlParams
  • encrypt to specify whether to encrypt the additionalUrlParams

More details in the following doc:
https://www.notion.so/aikon/Instrument-encryption-discussion-7d437e39c70942eca797e573f0f766ae

@surabhil commented on Tue Nov 13 2018

• Add the require(to == "verifier.ore") condition in the approve and transferfrom action

@surabhil commented on Wed Nov 21 2018

We deployed the changes that will allow users stack ORE to create accounts. Soon we will need a way to switch accounts' tiers when more/less resource is needed for an account.

ore system contract now should be able to:

Create a new account with the default price of 5 ORE and lock the same amount of SYS minus SYS that actually used.
Delegate-undelegate net/cpu/ram with the 2x amount of SYS requirement as ORE, and lock-unlock the price difference as SYS.

@surabhil commented on Wed Nov 21 2018

@petemccarthy commented on Fri Nov 02 2018

@surabhil commented on Wed Nov 21 2018

Since the token caps are the same between ORE and SYS, available tokens should always match.

Acceptance Criteria

• Make sure the contracts are working appropriately
• Define proposal for new token price for production
• Deploy & migration
• Migrate existing accounts to use ORE tokens

@surabhil commented on Fri Nov 16 2018

• Add additionalUrlParams parameters to the LicenseApi action:
• Push back the additionalUrlParams parameters block to the additionalUrlParams coming from the offer if any.

additionalUrlParams are the optional values that are combined with any additionalUrlParams that are already defined in the offer and the combined result appears in the output voucher’s additional_url_params

These could optionally have the following structure:
"additional_url_params": [
{ "params": [{"name":"encryptedWith","value":"user1@authVerifier", {"name": "param1", "value": "v1" },{ "name": "param2", "value": "v2" }]

Using the latest way of compiling contracts.
Adding end-to-end test scripts

@surabhil commented on Mon Nov 05 2018

While trying to license an offer with no rights, the chain throws "Runtime error: processing wasm" .
The offer shouldn't have been allowed to create in the first place. So the instrument contract should assert if there are no rights.

@surabhil commented on Fri Nov 16 2018

@traylewin commented on Mon Nov 19 2018

For Parameter Rules in an instrument, we should allow multiple values for the same parameter. This would be treated as an OR condition. If an incoming request includes any of the values included in the list, then it's a valid request and allowed.

For example:
Locked Params: UserId: 123, UserId: 456, UserID: 789
If a request comes in with UserId=456 then it meets the locked params rule. UserId=111 would not.

This solution would require an index for the lookup of the name/value pair since the number of possible values for a lock param could be very very large (10K+)

@surabhil commented on Wed Nov 21 2018

Current interface and the logic of createbridge is incompatible account creation with ORE. Because we set a fixed price for account creation and store it on contract's table, createbridge also needs to reach that table and get account creation parameters from there.
We also want createbridge contract to be generic so we need to decide on the changes we need to apply.