profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ngyam/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Adam Z. Nagy ngyam @energywebfoundation Making the world a better place and stuff

energywebfoundation/energyweb-ui 39

Energy Web UI - Dapp shell, browser & launcher (Electron app)

energywebfoundation/precise-proofs 4

EWF Origin's proof-of-concept precise proofs implementation and demos

energywebfoundation/ewf-chainspec 2

Chainspec repository of EWF for various chains

energywebfoundation/ewf-genesis-generator 1

EWF's chain genesis JSON generator

energywebfoundation/local-tobalaba-network 1

Setting up a local tobalaba-like network with ease

energywebfoundation/secretstore-py 1

Python package for Parity's SecretStore RPC API and sessions

energywebfoundation/MultiSigWallet 0

Allows multiple parties to agree on transactions before execution.

energywebfoundation/volta-system-contracts 0

Infrastructure contracts for Volta

gruniswap/assets 0

Grüni assets

issue commentgoerli/testnet

Berlin Validator Checklist

Flashbots has updated to geth v1.10.1

q9f

comment created time in 12 minutes

issue closedethereum/EIPs

Generalized interface for ERC721 wrapping and unwrapping

Prize Bounty

2,000 USDC

Challenge Description

Currently there exist the capability to wrap NFTs as ERC20s. Some examples are NFTX, WG0 (Wrapped Gen 0 Kitties), WK (Wrapped Cryptokitties). This bounty is for the definition of an ERC721, ERC1155 to ERC20 wrapping interface. Please review source material for common design patterns and submit an EIP. https://github.com/ethereum/EIPs

Submission Requirements

  • Draft EIP in the repository detailing the interface
  • Example implementation of the interface

Judging Criteria

First valid submission received.

Winner Announcement Date

First to submit.

closed time in 2 hours

dangerousfood

issue commentethereum/EIPs

Generalized interface for ERC721 wrapping and unwrapping

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

dangerousfood

comment created time in 2 hours

issue openedethereum/EIPs

Generalized interface for ERC721 wrapping and unwrapping

Prize Bounty

2,000 USDC

Challenge Description

Currently there exist the capability to wrap NFTs as ERC20s. Some examples are NFTX, WG0 (Wrapped Gen 0 Kitties), WK (Wrapped Cryptokitties). This bounty is for the definition of an ERC721, ERC1155 to ERC20 wrapping interface. Please review source material for common design patterns and submit an EIP. https://github.com/ethereum/EIPs

Submission Requirements

  • Draft EIP in the repository detailing the interface
  • Example implementation of the interface

Judging Criteria

First valid submission received.

Winner Announcement Date

First to submit.

created time in 2 hours

push eventOpenZeppelin/openzeppelin-contracts

renovate[bot]

commit sha 9612b891c9d2d1a5a10691e97bc397625019507a

Update lockfile (#2573) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 3 hours

delete branch OpenZeppelin/openzeppelin-contracts

delete branch : renovate/lock-file-maintenance

delete time in 3 hours

PR merged OpenZeppelin/openzeppelin-contracts

Update lockfile

WhiteSource Renovate

This PR contains the following updates:

Update Change
lockFileMaintenance All locks refreshed

:wrench: This Pull Request updates lock files to use the latest dependency versions.


Renovate configuration

:date: Schedule: "before 3am on Monday" (UTC).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:ghost: Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+824 -806

0 comment

1 changed file

renovate[bot]

pr closed time in 3 hours

issue commentethereum/EIPs

Discussion for ERC-721 Royalties EIP.

I was going to suggest having multiple royalty addresses (incase royalties are to be split amongst multiple addresses) but I think that should be up to the recipient on how to handle and the standard should be as minimal as possible.

Thanks for filing this standard, I think it's great and I support it.

VexyCats

comment created time in 3 hours

push eventenergywebfoundation/iam-client-lib

John Henderson

commit sha 27e4ae4b438ea31fb9f0c8c6db6c33190a528c7d

feat: mutate new roleDefResolver - use multicall to combine tx - importing roleDefResolver from iam-contracts

view details

push time in 3 hours

PR opened energywebfoundation/iam-client-lib

feat: mutate new roleDefResolver
  • use multicall to combine tx
  • importing roleDefResolver from iam-contracts
+295 -37

0 comment

14 changed files

pr created time in 4 hours

push eventethereum/EIPs

Sam Wilson

commit sha bec4802460b78998a6582d49c2235cd50b141415

Automatically merged updates to draft EIP(s) 3074 (#3348) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing

view details

push time in 4 hours

PR merged ethereum/EIPs

Add depthLeft [EIP-3074]

Removes type from stack; Adds depthLeft to stack; Adds two checks to the valid preconditions; Expands security considerations for invokers.

+18 -8

0 comment

1 changed file

SamWilsn

pr closed time in 4 hours

PR opened ethereum/EIPs

Add depthLeft [EIP-3074]

Removes type from stack; Adds depthLeft to stack; Adds two checks to the valid preconditions; Expands security considerations for invokers.

+18 -8

0 comment

1 changed file

pr created time in 4 hours

delete branch ensdomains/ens

delete branch : dependabot/npm_and_yarn/elliptic-6.5.3

delete time in 4 hours

PR closed ensdomains/ens

Bump elliptic from 6.4.1 to 6.5.3 launch dependency

Bumps elliptic from 6.4.1 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li><a href="https://github.com/indutny/elliptic/commit/60489415e545efdfd3010ae74b9726facbf08ca8"><code>6048941</code></a> 6.5.2</li> <li><a href="https://github.com/indutny/elliptic/commit/9984964457c9f8a63b91b01ea103260417eca237"><code>9984964</code></a> package: bump dependencies</li> <li><a href="https://github.com/indutny/elliptic/commit/ec735edde187a43693197f6fa3667ceade751a3a"><code>ec735ed</code></a> utils: leak less information in <code>getNAF()</code></li> <li><a href="https://github.com/indutny/elliptic/commit/71e4e8e2f5b8f0bdbfbe106c72cc9fbc746d3d60"><code>71e4e8e</code></a> 6.5.1</li> <li><a href="https://github.com/indutny/elliptic/commit/7ec66ffa255079260126d87b1762a59ea10de5ea"><code>7ec66ff</code></a> short: add infinity check before multiplying</li> <li><a href="https://github.com/indutny/elliptic/commit/ee7970b92f388e981d694be0436c4c8036b5d36c"><code>ee7970b</code></a> travis: really move on</li> <li><a href="https://github.com/indutny/elliptic/commit/637d0216b58de7edee4f3eb5641295ac323acadb"><code>637d021</code></a> travis: move on</li> <li><a href="https://github.com/indutny/elliptic/commit/5ed0babb6467cd8575a9218265473fda926d9d42"><code>5ed0bab</code></a> package: update deps</li> <li>Additional commits viewable in <a href="https://github.com/indutny/elliptic/compare/v6.4.1...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

1 comment

1 changed file

dependabot[bot]

pr closed time in 4 hours

pull request commentensdomains/ens

Bump elliptic from 6.4.1 to 6.5.3

Superseded by #374.

dependabot[bot]

comment created time in 4 hours

create barnchensdomains/ens

branch : dependabot/npm_and_yarn/elliptic-6.5.4

created branch time in 4 hours

PR opened ensdomains/ens

Bump elliptic from 6.4.1 to 6.5.4

Bumps elliptic from 6.4.1 to 6.5.4. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/43ac7f230069bd1575e1e4a58394a512303ba803"><code>43ac7f2</code></a> 6.5.4</li> <li><a href="https://github.com/indutny/elliptic/commit/f4bc72be11b0a508fb790f445c43534307c9255b"><code>f4bc72b</code></a> package: bump deps</li> <li><a href="https://github.com/indutny/elliptic/commit/441b7428b0e8f6636c42118ad2aaa186d3c34c3f"><code>441b742</code></a> ec: validate that a point before deriving keys</li> <li><a href="https://github.com/indutny/elliptic/commit/e71b2d9359c5fe9437fbf46f1f05096de447de57"><code>e71b2d9</code></a> lib: relint using eslint</li> <li><a href="https://github.com/indutny/elliptic/commit/8421a01aa3ff789c79f91eaf8845558a7be2b9fa"><code>8421a01</code></a> build(deps): bump elliptic from 6.4.1 to 6.5.3 (<a href="https://github.com/indutny/elliptic/issues/231">#231</a>)</li> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li><a href="https://github.com/indutny/elliptic/commit/60489415e545efdfd3010ae74b9726facbf08ca8"><code>6048941</code></a> 6.5.2</li> <li><a href="https://github.com/indutny/elliptic/commit/9984964457c9f8a63b91b01ea103260417eca237"><code>9984964</code></a> package: bump dependencies</li> <li><a href="https://github.com/indutny/elliptic/commit/ec735edde187a43693197f6fa3667ceade751a3a"><code>ec735ed</code></a> utils: leak less information in <code>getNAF()</code></li> <li>Additional commits viewable in <a href="https://github.com/indutny/elliptic/compare/v6.4.1...v6.5.4">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+23 -9

0 comment

1 changed file

pr created time in 4 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DIDService {       },     );   }++  async getAssetsByOwner(owner: string) {+    const assets = await this.didRepository.queryAssetByOwner(owner);+    if (assets.length < 1) return assets;+    return Promise.all(+      assets.map(async asset => {+        const resolvedDocument = await asset.getResolvedDIDDocument();+        this.enhanceWithClaims(asset, resolvedDocument);+        return resolvedDocument;+      }),+    );+  }++  async getAssetsByOfferedTo(offeredTo: string) {+    const assets = await this.didRepository.queryAssetByOfferedTo(offeredTo);+    if (assets.length < 1) return assets;+    return Promise.all(+      assets.map(async asset => {+        const resolvedDocument = await asset.getResolvedDIDDocument();+        this.enhanceWithClaims(asset, resolvedDocument);+        return resolvedDocument;+      }),+    );

Similar to another comment, just my opinion, but I think this would be more modular if it were in another file, maybe asset.service.ts?

dwojno

comment created time in 5 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DIDService {       DID_REGISTRY_ADDRESS,       this.provider,     );+    this.offerableIdentity = OfferableIdentityFactory.connect(+      DID_REGISTRY_ADDRESS,

I'm not sure this will work because, AFAIK, each OfferableIdentity will be its own contract and have its own address (which won't be the address of the DID_REGISTRY). Maybe you already have a plan for this?

dwojno

comment created time in 5 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DIDService {    private async InitEventListeners(): Promise<void> {     const DIDAttributeChanged = 'DIDAttributeChanged';-    this.didRegistry.addListener(-      DIDAttributeChanged,-      async (owner, hash, value) => {-        this.logger.info(-          `${DIDAttributeChanged} event received for owner: ${owner}`,-        );-        const did = `did:${Methods.Erc1056}:${owner}`;-        const didObject = new DID(did);-        const didDocEntity = await this.didRepository.queryById(didObject);-        // Only refreshing a DID that is already cached.-        // Otherwise, cache could grow too large with DID Docs that aren't relevant to Switchboard-        if (didDocEntity) {-          await this.didQueue.add(this.refresh_queue_channel, did);-        }+    this.didRegistry.addListener(DIDAttributeChanged, async owner => {+      this.logger.info(+        `${DIDAttributeChanged} event received for owner: ${owner}`,+      );+      const did = `did:${Methods.Erc1056}:${owner}`;+      const didObject = new DID(did);+      const didDocEntity = await this.didRepository.queryById(didObject);+      // Only refreshing a DID that is already cached.+      // Otherwise, cache could grow too large with DID Docs that aren't relevant to Switchboard+      if (didDocEntity) {+        await this.didQueue.add(this.refresh_queue_channel, { did });+      }+    });++    this.offerableIdentity.addListener(+      'OfferableIdentityCreated',+      async (identity, owner) => {+        const did = `did:${Methods.Erc1056}:${identity}`;+        await this.didQueue.add(this.upsert_queue_channel, { did, owner });+      },+    );++    this.offerableIdentity.addListener(+      'IdentityOffered',+      async (identity, offeredTo) => {+        const did = `did:${Methods.Erc1056}:${identity}`;+        await this.didQueue.add(this.refresh_queue_channel, { did, offeredTo });+      },+    );++    this.offerableIdentity.addListener(+      'IdentityTransferred',+      async (identity, owner) => {+        const did = `did:${Methods.Erc1056}:${identity}`;+        await this.didQueue.add(this.refresh_queue_channel, { did, owner });+      },+    );

IMO, I would separate the offerableIdentity stuff from the DID stuff a little more. Like maybe this could go in an offerableIdentity.service.ts or asset.service.ts? I think it's just mentally nice to have everything related to offerableIdentity grouped together and not mixed in with the ERC1056 stuff. But if you have a different opinion, glad to hear it.

dwojno

comment created time in 5 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 lerna-debug.log*  # Using either dev or prod docker-compose file docker-compose.yml+ db_dumps+private.pem

Nice 👍

dwojno

comment created time in 7 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DgraphService implements OnModuleInit {       type DIDDocument {         id         logs+        owner+        offeredTo

IMHO, it would be nice if the Asset/OfferableIdentity data was grouped/separate from DIDDocument to some extent. Like maybe an Asset inherits from DIDDocument somehow. Or maybe a nice approach is to have an Asset type that has both a DIDDocument and an OfferableIdentity? Something like this?

type Asset {
  document DIDDocument
  ownership OfferableIdentity
}
type OfferableIdentity {
  owner
  owfferTo
}
dwojno

comment created time in 5 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DIDService {     this.logger.debug(`Beginning sync of DID Documents`);     const cachedDIDs = await this.didRepository.queryAllDIDs();     cachedDIDs.forEach(async did => {-      await this.didQueue.add(this.refresh_queue_channel, did.id);+      await this.didQueue.add(this.refresh_queue_channel, { did: did.id });     });   } +  private async syncAssets() {+    this.logger.debug('Beginning of assets sync');+    const assetsInterface = new utils.Interface(offerableIdentityContract);+    const Event = this.offerableIdentity.filters.OfferableIdentityCreated(+      null,+      null,+    );+    const filter = {+      fromBlock: 0,+      toBlock: 'latest',+      address: Event.address,

I'm quite new to blockchain so maybe this is a dumb question, but why is the address of the Event being used here? Is this the address of the contract that emitted the event? If so, maybe clearer to use this.offerableIdentity.address?

dwojno

comment created time in 5 hours

Pull request review commentenergywebfoundation/iam-cache-server

feat(assets): add support of did assets

 export class DIDService {     this.logger.debug(`Beginning sync of DID Documents`);     const cachedDIDs = await this.didRepository.queryAllDIDs();     cachedDIDs.forEach(async did => {-      await this.didQueue.add(this.refresh_queue_channel, did.id);+      await this.didQueue.add(this.refresh_queue_channel, { did: did.id });     });   } +  private async syncAssets() {+    this.logger.debug('Beginning of assets sync');+    const assetsInterface = new utils.Interface(offerableIdentityContract);+    const Event = this.offerableIdentity.filters.OfferableIdentityCreated(+      null,+      null,+    );+    const filter = {+      fromBlock: 0,+      toBlock: 'latest',+      address: Event.address,+      topics: [...(Event.topics as string[])],+    };+    const logs = await this.provider.getLogs(filter);+    for (const log of logs) {+      const {+        values: { identity },+      } = assetsInterface.parseLog(log);+      const owner = await this.offerableIdentity.owner();+      this.didQueue.add(this.upsert_queue_channel, {

I don't really get this 🤔 . Every time there is an event from offerableIdentity then the ERC1056 data is being refreshed? I don't think the offerableIdentity events reflect a change to ERC1056 data, so the ERC1056 data don't need to be refreshed do to an offerableIdentity event?

dwojno

comment created time in 5 hours

issue commentOpenZeppelin/openzeppelin-contracts

Make some private functions internal to allow the developpement of "withSignature" functions (like permit)

I agree that having the contract itself have the admin role can work ... even though it would be a mess if there are many different admin roles. I don't think its a good solution though.

Also tweaking that in the Context doesn't sound right. It would be possible but I fear it would require sload in context which would be bad in the long run.

Amxx

comment created time in 5 hours

issue commentOpenZeppelin/openzeppelin-contracts

Make some private functions internal to allow the developpement of "withSignature" functions (like permit)

I'm not fond of this change, I still believe we need to protect the internal admin logic of AccessControl.

For generic "withSignature" functions it would be interesting to evaluate whether a Context variant can implement this pattern, although it seems impossible to do without using storage.

For AccessControl this is not really necessary. The contract itself can be made an admin of a role, and it can have a public function that validates a signature and calls itself with a role management operation.

Amxx

comment created time in 5 hours

pull request commentOpenZeppelin/openzeppelin-contracts

Add an internal _useNonce(address) function in ERC20Permit

nonces should be made virtual now that it is possible to override _useNonce.

Amxx

comment created time in 6 hours