celo-org / celo-blockchain Goto Github PK

Expected Behavior

Please describe the behavior you are expecting

Current Behavior

What is the current behavior?

Expected Behavior

Please describe the behavior you are expecting

Current Behavior

What is the current behavior?

• staging
• production

Expected Behavior

International phone numbers should be able to be verified. E164

Current Behavior

Our regex currently checks the decrypted phone number against a regex which will only match for US phone numbers.

Network testing / penetration testiing

Expected Behavior

Nodes should wait 30s between redialing another node

Current Behavior

Set to 10s as a hack because the nodes in our PoA testnet continually disconnect

Go Ethereum uses a test suite that is shared on other clients to assert its compliance with the ethereum protocol. It doesn't work for celo since our protocol is different, hence we don't use it.

We want to adapt it and use it for our blockchain.

Check
https://github.com/ethereum/tests/tree/ad2184adca367c0b68c65b44519dba16e1d0b9e2

Expected Behavior

Should be able to use original geth dockerfile.

Current Behavior

Added an extra dockerfile.

Expected Behavior

Please describe the behavior you are expecting

Current Behavior

What is the current behavior?

Expected Behavior

We should decide on a unit testing method, be that choosing a testing framework or conventions for our own tests. I've used Ginkgo with Gomega before, a typical unit testing framework with a DSL similar to mocha's.

Current Behavior

From a quick browse through the repo, looks like there's a bunch of different approaches to testing being used.

Expected Behavior

As part of validating a block miners should extract the public key from the previous block header and verify that it matches the block coinbase.

Current Behavior

No validation is done on the signature.

Expected Behavior

We should never have to think about rebuilding mobile geth

Current Behavior

We have to rebuild on every merge to master and update mobile package.json

Expected Behavior

Up script should automatically connect the two miners

Current Behavior

Miners need to be made aware of each other manually

Expected Behavior

When multiple light clients are on the same network, they should still be able to connect to the same node.

Current Behavior,

Due to ethereum/go-ethereum#16899 (comment), currently light clients cannot have the same IP address

Current workaround

We made a modification in #41 to change the identification of a peer by IP address to their enode address. This loosens our ability to actually identify badly behaving clients but allows us to continue to use our Kubernetes setup as well as have multiple light clients on the same network.

regular logs -> stdout, actual errors -> stderr -> Sentry ?

Expected Behavior

block.coinbase should return the address of the current block miner when running on a proof of authority testnet.

Current Behavior

block.coinbase is always set to 0x0 when using PoA

I can't map my phone number my new address, which is why when I'm sent funds they don't appear in my balance.

To repro:

1. Compute the address at which your actual address is stored:
   const hash = web3.utils.sha3('8579988722').slice(26)
   console.log(0x${hash})

2. Check the balance at that address to confirm that it's mapped to your current address:
   yarn run get-balances VALUE_LOGGED_IN_1
   Convert the gold balance amount to hex to get the address

3. Clear Celo app storage, reload, faucet your new address some money, and reverify

4. Rerun step 2, see that the balance did not change

Expected Behavior

Verification always works.

Current Behavior

We saw an issue where the miner wasn't able to decrypt the phone number.

Expected Behavior

A user shouldn't have to worry about having a balance of Celo Gold just to make Celo Dollar transactions.

Current Behavior

Right now you need Celo Gold to pay for gas, even if you are just sending Celo Dollars.

Expected Behavior

We will allow miners to set their own URL for their verification service.

Current Behavior

All miners use the same verification service. It is a URL that is hardcoded into Geth.

Expected Behavior

Users will need access to the Celo binary

Current Behavior

Private repo

Expected Behavior

Subdirectories are owned by certain users, who are required to approve PRs touching that code.

Current Behavior

Things are done ad-hoc.

Expected Behavior

We should have a branch for the current demo

Current Behavior

No demo branch

Expected Behavior

Redeploy and retain state

Current Behavior

State is nuked on helm upgrade

Expected Behavior

Tests should pass

Current Behavior

Tests don't pass

https://ethereum.stackexchange.com/questions/51580/how-can-we-implement-a-new-opcode-in-the-ethereum-virtual-machine

Expected Behavior

We don't have to allow future blocks

Current Behavior

We need future blocks for PoA

Merge and test upstream changes in
https://github.com/ethereum/go-ethereum/releases/tag/v1.8.16

Understand how Ethereum and ZCash launched their mainnet, e.g. what did they do to build mining power? community? how did they stage the roll-out? what would they do differently today? etc. to better define our path to mainnet launch.

Plan to build mining power

Expected Behavior

Users should be able to call all ERC20 contract functions on Gold. One way to do this would be to implement "transfer" and "lookup" precompiled contracts, callable only by the GoldToken contract.

Current Behavior

In order to get ERC20 functionality we wrap gold

Implement https://docs.google.com/document/d/1p2W9Efrgy0BCe39WipVjXUqnlgip_G1KdX_9Va5BxTY/edit#

Expected Behavior

When load is not high, miners will accept transactions with gasprice=0

Expected Behavior

We should CI/CD docker images, possibly on GCP

Current Behavior

Developers have to build docker images manually

Expected Behavior

Users SBAT send their encrypted phone number to the target verifier node without sending a transaction, via whisper or the gossip protocol.

Current Behavior

Users send their encrypted phone number via a transaction, which is then run by the verifier node when the block is mined.

Expected Behavior

Please describe the behavior you are expecting

Current Behavior

What is the current behavior?

Expected Behavior

CircleCI should be set up and prevent us from checking in commits that break the tests.

Current Behavior

CircleCI is not set up.

Expected Behavior

Tests should exist for abe/abe.go

Current Behavior

No tests exist for abe/abe.go

Expected Behavior

Some precompiled contracts should only be called by certain contracts, we have no way of enforcing this.

Current Behavior

We don't do this

Expected Behavior

Please describe the behavior you are expecting

Current Behavior

What is the current behavior?

Expected Behavior

We get successful or pending transactions metrics in geth

Current Behavior

We can't get successful or pending transactions metrics in geth

Expected Behavior

https://docs.google.com/document/d/1p2W9Efrgy0BCe39WipVjXUqnlgip_G1KdX_9Va5BxTY/edit

Current Behavior

Fees are paid exclusively in gold

We turned off V5 discovery and not sure if this is necessary

Expected Behavior

Contracts SBAT send encrypted phone numbers, the geth node should then decrypt the phone number and send a text with the verification code.

Current Behavior

Phone numbers are sent in plain text.

Expected Behavior

Miners can specify who will receive the reward for completed verifications. In the short term, this can be the verification pool's wallet address, longer term, a Terms of Service contract published by the verification pool that splits rewards between the miner and the pool.

This is the geth compliment to celo-org/celo-monorepo#738

Current Behavior

Verification rewards are always credited to the miner.

Expected Behavior

This contract should only be able to be called by the AddressBasedEncryption contract

Current Behavior

Anyone can call it

Expected Behavior

It should connect to the bootnode

Current Behavior

@asaj in his attempted deploy of a network set the bootnode tag to be 9568b4a305e6a51b4f4b48dfd3e8bee505ee83cc as they are currently set for all the other geth nodes. However, that resulted in all the geth nodes being unable to connect to the bootnode with the following error:

Bootstrap URL invalid enode=enode://d576d9d033023258a24cf55cd391e32fd4e2bf6bc5bff13d364e30bad2101e6a@10.20.6.43:30301 err="invalid node ID (wrong length, want 128 hex chars)" "

I found the following SO answer https://stackoverflow.com/questions/52835449/the-output-length-of-bootnode-writeaddress-command-is-64-bytes-not-128-bytes-a that leads to ethereum/go-ethereum#17643

What I don't quite get is why verificationrewards, the tag that predates our merge of upstream geth is the one bootnode version that is compatible with the rest of the geth nodes, vs. 9568b4a305e6a51b4f4b48dfd3e8bee505ee83cc which includes upstream is seemingly not compatible. My guess its somewhere around defaults of which p2p protocol we are using, but haven't dug deeper