The name-registry could have its own namespace (i.e. its own object in the pipe and endpoint). It would have methods for transacting, getting a stored value by key, and getting the entire list of stored values (with optional filters).

One problem with this when using local signing. In that case the transaction should be passed like any other, using the broadcastTx method. The alternative is to add the nameTransact function to transactions, and keep all transactions in the tx object. It's just temporary anyways, and will at some point be replaced with only local signing.

Another question is what to name it. "names" seems a bit ambiguous. It's a regular map as far as I know, which happens to be used for names atm. If name should be in it then I personally think that namereg (or some variation) would be the best choice. We should also be consistent and refer to it as the Tendermint name registry component everywhere.

Input welcome.

This repository is released GPL3

eris-db tmsp branch introduces the account, but the test (still ?) uses crypto from tendermint ?

Is there a small guidance that can set me on my way to possibly update the state tests for the tmsp branch?

ben-eris@machine:~/eris/golang/src/github.com/eris-ltd/eris-db/state (tmsp)$ go test
# github.com/eris-ltd/eris-db/state
./permissions_test.go:118: cannot use user[0].PubKey.(account.PubKeyEd25519) (type account.PubKeyEd25519) as type crypto.PubKeyEd25519 in field value
./permissions_test.go:143: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewSendTx
./permissions_test.go:156: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewSendTx
./permissions_test.go:169: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewSendTx
./permissions_test.go:185: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewSendTx
./permissions_test.go:210: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewNameTx
./permissions_test.go:222: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewNameTx
./permissions_test.go:245: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewCallTx
./permissions_test.go:254: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewCallTx
./permissions_test.go:263: undefined: "github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/types".NewCallTx
./permissions_test.go:263: too many errors
FAIL    github.com/eris-ltd/eris-db/state [build failed]

Godeps is on master for tendermint/tendermint

Have had a report earlier, and this has apparently been an issue. msg.sender and tx.origin are zero when calling from outside the vm, but not from within (i.e. from other contracts). Not sure whether it's tx only, or both with calls and txs.

currently using just tendermint
really what we'd like are the following options:

• erisdb
• tendermint on erisdb vendored commit
• tendermint on master
• tendermint on develop

though I guess it makes more sense for all this to be done through multiple tagged images than all in one image

I want to know what is in the name registry of an eris-db container so I created a shell and ran the following command:

eris@5e725856816f:~/.eris$ mintinfo names
Post http://pinkpenguin.chaintest.net:46657: dial tcp 128.199.230.153:46657: connection refused

I would expect mintinfo (and any similar commands) to be configured for the local node by default instead of pinkpenguin.chaintest.net.

The recommended way of working with eris-db is through eris-cli (develop branch as of now).

OK, I installed eris-cli and read its ginormous README.

Now, on to using it.

The simplest way to get started is by simply running $ erisdb.

$ erisdb
bash: erisdb: command not found

OK, looks like we're missing a step here. Perhaps erisdb is a "service"?

$ eris services known
ipfs
keys

Nope.

Is it a "chain"?

$ eris chains known

bash-3.2$

Guess not.

Wearing my hat of curious developer I'm losing interest. We need a smoother on-ramp.

I run erisdb ~/.eris/data/alistFirstID and non-transaction blocks flood my terminal output. They make it hard to locate logs for my transactions.

I would like a logging verbosity option that would suppress output from any block that has zero transactions.

tendermint/tendermint#98

really, sync with eth.

In DOCKER/start.sh

this leaves out folks that need to use edb server binary on those branches.

Following the tutorial I constructed a genesis.json by hand. when creating a new chain from it the chain_id was over written.

Proof:

Snippet of genesis.json:

{
  "chain_id": "simple_chain",
  "accounts": [
    {
      "address": "8C3A4A59FC07EA11433340D3B18F852EBD8DCA16",
      "amount": 690000000000
    },

and snippet of the output from localhost:46657/genesis

{"jsonrpc":"2.0","id":"","result":[17,{"genesis":{"genesis_time":"2016-01-21T01:24:35.082Z","chain_id":"simplexD","params":null,"accounts":[{"address":"8C3A4A59FC07EA11433340D3B18F852EBD8DCA16","amount":690000000000,"name":"","permissions":null},

trying to test eris-pm/tests/fixtures/app06 (with the strings lines at the bottom of the epm.yaml uncommented). there's more logs but this is reproducible.

(pc) 1053 (op) DUP3           (st) 8     => [3] 0x0000000000000000000000000000000000000000000000000000000000100020
(pc) 1054 (op) DUP2           (st) 9     => [2] 0x6E616B61627572726F7700000000000000000000000000000000000000000080
(pc) 1055 (op) GT             (st) 10    49926538621785658806052556028335402667741290619443898992232611561495597154432 > 1048608 = 1
(pc) 1056 (op) ISZERO         (st) 9      == 0 = 0
(pc) 1057 (op) PUSH2          (st) 9     => 0x000000000000000000000000000000000000000000000000000000000000043A
(pc) 1060 (op) JUMPI          (st) 10    ~> false
(pc) 1061 (op) DUP3           (st) 8     => [3] 0x0000000000000000000000000000000000000000000000000000000000100020
(pc) 1062 (op) MLOAD          (st) 9    INFO[03-02|04:58:04] Error on execution: Memory out of bounds module=state
NOTE[03-02|04:58:04] VM call complete                         module=state caller="VMAccount{000000000000000000000000B3C52790E0A6700D068850C8E208E5C7960476AF B:99999999938771 C: N:8}" callee="VMAccount{000000000000000000000000926CD229627065BD89442B753116BC6053F50CA7 B:52590 C:6060604
05236156100B5576000357C0100000000000000000000000000000000000000000000000000000000900480620267A4146100B75780630BCD3B33146100DA57806312A7B914146100FD5780631E26FD331461012057806338CC4831146101385780634EF65C3B146101715780636273899814610189578063747586B8146101AC5780637FCAF666146101C457806
389EA642F1461021A578063E30081A014610295578063E6748DA9146102AD576100B5565B005B6100C4600480505061032B565B6040518082815260200191505060405180910390F35B6100E760048050506103A9565B6040518082815260200191505060405180910390F35B61010A60048050506102E1565B6040518082815260200191505060405180910390F
35B61013660048080359060200190919050506102C5565B005B610145600480505061036C565B604051808273FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF16815260200191505060405180910390F35B610187600480803590602001909190505061031D565B005B610196600480505061030B565B6040518082815260200191505060405180910390F35B6
101C260048080359060200190919050506102FD565B005B6102186004808035906020019082018035906020019191908080601F0160208091040260200160405190810160405280939291908181526020018383808284378201915050505050509090919050506103BB565B005B610227600480505061046C565B604051808060200182810382528381815181526
02001915080519060200190808383829060006004602084601F0104600F02600301F150905090810190601F1680156102875780820380516001836020036101000A031916815260200191505B509250505060405180910390F35B6102AB600480803590602001909190505061033D565B005B6102C3600480803590602001909190505061039B565B005B8060006
0006101000A81548160FF021916908302179055505B50565B6000600060009054906101000A900460FF1690506102FA565B90565B806001600050819055505B50565B6000600160005054905061031A565B90565B806002600050819055505B50565B6000600260005054905061033A565B90565B80600360006101000A81548173FFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFF021916908302179055505B50565B6000600360009054906101000A900473FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF169050610398565B90565B806004600050819055505B50565B600060046000505490506103B8565B90565B80600560005090805190602001908280546001816001161561010002031660029004906000526020600
02090601F016020900481019282601F1061040A57805160FF191683800117855561043B565B8280016001018555821561043B579182015B8281111561043A57825182600050559160200191906001019061041C565B5B5090506104669190610448565B808211156104625760008181506000905550600101610448565B5090565B50505B50565B6020604051908
10160405280600081526020015060056000508054600181600116156101000203166002900480601F0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105195780601F106104EE57610100808354040283529160200191610519565B820191906000526020600020905B815481529
0600101906020018083116104FC57829003601F168201915B50505050509050610525565B9056 N:0}" return= err="Memory out of bounds"
INFO[03-02|04:58:04] Added to prevotes: VoteSet{H:12 R:0 T:1 +2/3:true BA{1:X}} module=consensus

I don't think this is a hurry, and as far as I know everyone's fine with this as a temp solution. Can't see any problems with this as of now, except from what i understand its a bit unconventional. Adding the issue nonetheless.

Would it be good to keep a tendermint fork in our repos later, or maybe just a tag in the main repo that all our current and coming tools can refer to? Just as a way to ensure that we keep everything the same. Gonna bring this up on some meeting.

An ENTRYPOINT allows you to configure a container that will run as an executable.

— https://docs.docker.com/reference/builder/#entrypoint

This container is run as a server, not as an executable.

Most collections returned by api methods (blocks, accounts, storage) should be automatically paginated. The responses should be updated to include information such as page number, total pages, and items per page. Queries should be updated as well. Since our search queries is modeled after the ones Github uses, and since the Github API is recognized as being very good, we should probably mimic their system for pagination as well (where possible).

perhaps using docker's container names algo ...?

expose an unsafe_flush_mempool rpc in erisdb? just do it direct in the godepped tendermint is fine. ill expose the same on latest tendermint

this is blocking until we move to tmsp (post 0.12.0). until we formally move to tmsp this work isn't very important. after that switch, we will need to control "more" from the erisdb-rpc port. Indeed, erisdb-rpc port should be the single gateway to eris chains and then be able to proxy to tmint's rpc if needed (or the application manager, etc.)

This is causing breakage with my genesis.json.

A continuation of this issue:

https://github.com/eris-ltd/eris-db.js/issues/28

On running -
$ go get github.com/eris-ltd/eris-db/cmd/erisdb

Getting below error.

github.com/eris-ltd/eris-db/Godeps/_workspace/src/github.com/tendermint/tendermint/vm/secp256k1

exec: "gcc": executable file not found in %PATH%

github.com/eris-ltd/eris-db/files

C:\Go\bin\src\github.com\eris-ltd\eris-db\files\windows.go:15: undefined: isWritable

there are way too many hanging branches in this repository.

once the refactor is complete in tmnt branch then we need to remove / merge / clean up all of these branches and adhere to our coding practices...

feature -> (develop) -> staging -> master

currently we have too many config files. And we haven't even started moving to the consensus+app separation. config files will be reduced by closing #70 and better reliance on env vars (which will give the cli more fine tuneable control over boot configuration).

per @AFDudley we should be thinking of large config files which can include other config files. in general we need to be smarter about our strategy here.

Add more examples to the api doc. A simple example will usually clear things up a lot, perhaps more so then the specification, but it will make the already 1800 lines document even fatter. It would be good to have it all in one place though. Eth has an example for each method in their RPC doc, which is great.

any and all specifications should be in docs/ directory per eris standards (relates to #74)

that .project file needs to be removed.

DOCKER/build.sh -> tests/build_tool.sh (eris platform standard)

main test harness should run from -> tests/test.sh (eris platform standard)

Dockerfile should be in repository root

seems to happen when pushing a lot of txs the first thing you do as the chain is created. this could be gone. keep issue up in case it happens again.

While it has helped me quite a bit, particularly in testing, this type of throw-away chain generation will be possible with eris-cli so no need to do double work. eris-cli may not generate an endpoint you can call to produce a chain remotely, but if there happens to be a huge demand for that I guess it could be worked in.

Changing this means the server code can be reduced a bit, and there will be no need for erisdbss in build scripts.

all of the ecm stuff (currently bash start scripts in this repository in the docker directory) we currently have in bash scripts should be collapsed into the erisdb boot process.

The boot process should respect a variety of env vars currently encapsulated in the ecm scripts in this repository. The docker images should be refactored to remove those bash scripts and just boot the edb binary.

Two env vars we will use frequently but that I do not think are currently respected:

ERISDB_FAST_SYNC which should be an easy way for us to turn fast_sync to try via env vars when booting from containers.
ERISDB_SEEDS which should be an easy way for us to pass in the IP address of the seed to the binary.

Obviously, all env vars should overwrite anything in a static config file.

• Change <*> to <string> in the filter object description.
• Fix so all links to the filter section works.

• permanent names
• contract guarded names
• multisig

not sure if they should be the exact same binary, but at least they should be collapsed into this repository for coherence. the mint-client tooling needs to then be refactored (post rpc reconciliation process) so that it is low level go libs for "using" eris chains

eris-pm/tests/fixtures/app17 is our grandmaster factory test.

a factoryfactory creates a factory which creates a contract that is tested.

this test has some stability which is at the vm level. same contracts, same chain setup, etc. everything else is isolated but with divergent results.

the sometimes failing test is:

Executing Job                                 getGSFactoryAddr
Too little data                           end=0
                                          len=20
                                         name=
                                         next=32
                                       retBlk=32
                                        start=0
                                         type=
                                          val=
Too little data; usually means a bad return from a contract

The error message means that eris-pm is expecting a return from the contract but that does not happen.

To recreate:

have eris-cli on develop
pull eris-pm on develop (or mergeCompilers branch if that is not merged)
current eris-db:0.11.3 image

Comment out line 180 in eris-pm/tests/test.sh (so you can examine the chain logs after failure).

run:

tests/test.sh app17 && tests/test.sh app17 && tests/test.sh app17 && tests/test.sh app17

or however many times you need to.

commit the fixes we did locally with keys not being padded sometimes. this will be in next patch.

For 0.11 the Network object should probably be deprecated and a Node object added, since Network currently has things like the client version in it. Network data would be part of Node.

This would be a name change, the logic would remain the same.

In the CLI, this is a called a "chain". Here it's called "DB". This is a confusing inconsistency.

Given that our marketing is promoting that we make it easier to work with blockchains, it makes more sense to me to call this a "chain" as well. "DB" implies database and a blockchain is not going to meet the expectations of coders who think they're getting a database.

erisdb needs a --fast-sync flag too