tkuhrt (Tue, 28 Nov 2017 17:24:28 GMT):
Contributor/maintainer discussion for the Hyperledger Burrow project

silasdavis (Tue, 28 Nov 2017 18:39:27 GMT):
Hello @brillia @ashlinSajan @rosemaria @VenuReddy @jojujacob

VenuReddy (Tue, 28 Nov 2017 18:39:27 GMT):
Has joined the channel.

rosemaria (Tue, 28 Nov 2017 18:39:27 GMT):
Has joined the channel.

brillia (Tue, 28 Nov 2017 18:39:27 GMT):
Has joined the channel.

ashlinSajan (Tue, 28 Nov 2017 18:39:27 GMT):
Has joined the channel.

jojujacob (Tue, 28 Nov 2017 18:39:27 GMT):
Has joined the channel.

silasdavis (Tue, 28 Nov 2017 18:39:53 GMT):
Tracy has created us this channel to speak about and plan the work we will be doing together on Burrow

silasdavis (Tue, 28 Nov 2017 18:41:03 GMT):
I've made start on a Burrow hub page on the wiki but I will sending round a single email starter pack based on our earlier call: https://wiki.hyperledger.org/projects/burrow

silasdavis (Tue, 28 Nov 2017 18:41:27 GMT):
I'm putting together my rough roadmap which I will post there and we can iterate on a bit

silasdavis (Tue, 28 Nov 2017 18:41:37 GMT):
I'll also try to add a dependency graph

silasdavis (Tue, 28 Nov 2017 18:41:53 GMT):
and put in some starter paths that you can start persuing

compleatang (Wed, 29 Nov 2017 19:56:33 GMT):
Has joined the channel.

highlander (Thu, 30 Nov 2017 15:26:07 GMT):
Has joined the channel.

iamprem (Thu, 30 Nov 2017 21:53:56 GMT):
Has joined the channel.

silasdavis (Tue, 05 Dec 2017 15:58:45 GMT):
@adamludvik let's default to talking here

adamludvik (Tue, 05 Dec 2017 15:58:45 GMT):
Has joined the channel.

silasdavis (Tue, 05 Dec 2017 15:59:08 GMT):
Question posed: what are transitive deps of Burrow's `./execution/evm`

silasdavis (Tue, 05 Dec 2017 15:59:22 GMT):
answer: `go list -f "{{.Deps}}" ./execution/evm/... | sed 's/[][]//g' | sed 's/ /\n/g' | sort | uniq`

adamludvik (Tue, 05 Dec 2017 16:00:52 GMT):
cool

silasdavis (Tue, 05 Dec 2017 16:01:25 GMT):
doesn't look too bad

swetha (Tue, 05 Dec 2017 16:38:49 GMT):
Has joined the channel.

guoger (Tue, 05 Dec 2017 16:38:51 GMT):
Has joined the channel.

muralisr (Tue, 05 Dec 2017 16:39:15 GMT):
Has joined the channel.

adamludvik (Tue, 05 Dec 2017 16:39:39 GMT):
What's the purpose of this wrapper class? https://github.com/hyperledger/burrow/pull/657/commits/da15dbd0a05332d174db279d7fdffb598580c86e#diff-b8162a179c0f7b80fbdc40cc0e2b8f64R69

adamludvik (Tue, 05 Dec 2017 21:56:23 GMT):
@silasdavis I asked today whether burrow interacted with tendermint and my understanding of your response was that it didn't. I found this while reviewing your PR and am wondering if burrow contains code for both sides of the ABCI? https://github.com/hyperledger/burrow/blob/hypermarmot/consensus/tendermint/abci/app.go

ashlinSajan (Wed, 06 Dec 2017 04:48:09 GMT):
@silasdavis How does sleepy model of consensus work?

ashlinSajan (Wed, 06 Dec 2017 04:54:00 GMT):
@silasdavis What is difference between ERC22 and ERC20?

silasdavis (Wed, 06 Dec 2017 10:31:00 GMT):
I would have defined the interface methods on the `ConcreteAccount` but the symbols that make most sense to use as function names: `Sequence` and `Address` clash with the field names. I need `ConcreteAccount` as a 'model of serialisation' (amongst other things) and in go that means I need to export those fields so I can't get away with `address` etc

silasdavis (Wed, 06 Dec 2017 10:45:48 GMT):
I think my answer about that was unclear - we do interact with Tendermint through the ABCI interface it's just we do it in a single process

silasdavis (Wed, 06 Dec 2017 10:46:28 GMT):
via https://github.com/tendermint/tendermint/blob/master/proxy/client.go#L26-L31

ashlinSajan (Wed, 06 Dec 2017 12:30:32 GMT):
@silasdavisHi, We went through the links you sent.In the documents you have mentioned about providing an out-of-the-box deployment experience (no need for('monax chains make')).Could you please clarify how the contracts are deployed?

ashlinSajan (Wed, 06 Dec 2017 12:35:08 GMT):
@silasdavis Hi, We have gone through the links that you have sent.In that, you have mentioned about providing an out-of-the-box deployment experience (no need for('monax chains make').Could you please clarify how the contracts are deployed?

SomaNayak (Wed, 06 Dec 2017 18:03:03 GMT):
Has joined the channel.

Soundharya (Fri, 08 Dec 2017 05:26:43 GMT):
Has joined the channel.

adamludvik (Fri, 08 Dec 2017 18:27:04 GMT):
@silasdavis I am happy to continue reviewing your PR, but I think it would be much easier to work through if the commits were a little bit more focused. As it stands right now, it will take me a while to make sense of everything.

silasdavis (Sun, 10 Dec 2017 11:22:42 GMT):
yeah you are right, given that you are willing to put in the time, let me take some time to rebase what I have into logical units of chances, it will also help me document the changes in the PR

silasdavis (Sun, 10 Dec 2017 11:22:42 GMT):
yeah you are right, given that you are willing to put in the time, let me take some time to rebase what I have into logical units of changes, it will also help me document the changes in the PR

smblucker (Tue, 12 Dec 2017 16:26:09 GMT):
Has joined the channel.

adamludvik (Tue, 12 Dec 2017 20:48:33 GMT):
Sounds good. Let me know when you've made some progress and I'll get back to it.

smblucker (Wed, 13 Dec 2017 13:40:04 GMT):
@silasdavis This is Sean from TCS Cincinnati. I have a few questions, and I ask that you forgive my ignorance. The questions are as follows:

smblucker (Wed, 13 Dec 2017 13:41:26 GMT):
@silasdavis What are the essential differences between Monax and Burrow--i.e. functionality--if any?

smblucker (Wed, 13 Dec 2017 13:44:22 GMT):
@silasdavis Do you have to fall back to the Monax tooling to deploy contracts; if so, how is Burrow 'serve' affected by this; if not, how is this accomplished with Burrow?

smblucker (Wed, 13 Dec 2017 13:45:59 GMT):
@silasdavis Will Burrow eventually have all of the functionality of Monax?

silasdavis (Wed, 13 Dec 2017 14:16:53 GMT):
Hi Sean, first of all 'Monax' is the company behind Burrrow, 'monax' is our tool. Burrow is a blockchain peer, monax is a developer tool for amongst other things deploying contract to Burrow over its RPC

silasdavis (Wed, 13 Dec 2017 14:17:49 GMT):
monax incorporates a declarative deployment/testing/interaction language contained in its job specification 'epm.yaml' files

silasdavis (Wed, 13 Dec 2017 14:19:26 GMT):
Burrow will never have all of the monax features, but the next version already has the ability to form it's own genesis

silasdavis (Wed, 13 Dec 2017 14:20:52 GMT):
Currently burrow has an RPC and an RPC client library in go that would allow you to do most things without monax in principle, the main thing that we do not have is the ability to pack the ethereum ABI, which is essential for calling solidity functions

silasdavis (Wed, 13 Dec 2017 14:21:13 GMT):
the monax tool uses the GPL go-ethereum ABI and this cannot be included in the main Burrow repo

silasdavis (Wed, 13 Dec 2017 14:21:42 GMT):
I have a much slimmed-down version of all of our satellite tooling that I will release shortly as a monorepo called 'bosmarmot'

silasdavis (Wed, 13 Dec 2017 14:22:36 GMT):
this drops the docker management features of monax and talk directly to a running instance of Burrow

silasdavis (Wed, 13 Dec 2017 14:22:51 GMT):
it supports the same 'epm.yaml' files

silasdavis (Wed, 13 Dec 2017 14:23:55 GMT):
and it is intended to serve as a stop-gap before either or both of: web3 API, a Burrow native ABI layer (not that hard to do, and probably needed)

smblucker (Wed, 13 Dec 2017 14:28:55 GMT):
Thank you for your time

guoger (Thu, 14 Dec 2017 15:03:19 GMT):
A quick question, the signature of `vm.call` in `execution/evm/vm.go`: `func (vm *VM) call(caller, callee acm.MutableAccount, code, input []byte, value uint64, gas *uint64) (output []byte, err error)` Shouldn't `code` be always the same as `callee.Code()`?

silasdavis (Thu, 14 Dec 2017 16:49:17 GMT):
@guoger yeah the place that comes to mind is `CallCode`: https://github.com/hyperledger/burrow/blob/hypermarmot/execution/transactor.go#L128

silasdavis (Thu, 14 Dec 2017 16:49:51 GMT):
It's a 'simulated call' and you can provide virtual code for a 'what if' execution, which has various applications

guoger (Mon, 18 Dec 2017 08:17:04 GMT):
@silasdavis I'm trying to verify that burrow evm works as expected, here's what I did: 1. compile a simple solidity [program](http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html) with `solc` 2. encode function signature with `web3.sha3("set(uint256)")` 3. take results from first two steps and write a simple unit test in `vm_test.go`, see https://hastebin.com/jimarabumo.css What I expect: - `SetStorage` API should be called by evm since we are calling `set` in contract - `accounts` and `storage` in fake app state shouldn't be empty But I failed to observe both of them. Any suggestions? thx!

guoger (Mon, 18 Dec 2017 09:06:05 GMT):
ah, I figured out why `accounts` is empty, basically ``` account1 := newAccount(1) account2 := newAccount(2) ```

guoger (Mon, 18 Dec 2017 09:06:05 GMT):
ah, I figured out why `accounts` is empty, basically ``` account1 := newAccount(1) account2 := newAccount(2) ``` actually created the same account (right padded word256 converted to word160, where beginning bytes are discarded)

guoger (Mon, 18 Dec 2017 09:17:03 GMT):
Never mind.... it's compiler problem, switched to `Remix` online compiler and problem solved..

silasdavis (Mon, 18 Dec 2017 12:05:13 GMT):
Did you get `INVALID JUMP DEST` at all?

silasdavis (Mon, 18 Dec 2017 12:05:45 GMT):
it's not guaranteed but that's often where you end up with malformed bytecode

guoger (Mon, 18 Dec 2017 13:02:42 GMT):
@silasdavis no I didn't get that actually... vm call returned normally with `err == nil`

VenuReddy (Mon, 18 Dec 2017 13:19:09 GMT):
@silasdavis thanks for your response to @smblucker 's message. When you say that Burrow will never have all monax features, what features are you referring to and why are they not included. We have some basic questions on differences/similarities between monax and Burrow. The confusion is exacerbated by the mixture of tools and setup instructions between the two at this point. The team is not able to understand where one ends and the other begins. Any clarity you can provide will be helpful. If we can talk this week, we can ask questions interactively and get past it.

guoger (Tue, 19 Dec 2017 09:45:08 GMT):
@silasdavis what does`evm.call` actually return? If I send a query call, e.g. `get()`, can I rely on that to retrieve return value? (I vaguely remember that evm actually returns a tx hash?)

silasdavis (Tue, 19 Dec 2017 12:45:46 GMT):
FYI TCS people: https://github.com/monax/bosmarmot

silasdavis (Tue, 19 Dec 2017 12:55:02 GMT):
https://github.com/monax/bosmarmot/tree/hypermarmot/monax/tests/jobs_fixtures You12:48 https://github.com/hyperledger/burrow/pull/657 You12:50 watch docker ps -a You12:52 image versions can be found: ~/.monax/chains/foo/foo_full_000/config.tom You12:53 https://github.com/hyperledger/burrow/blob/master/Dockerfile You12:54 /home/silas/.monax/chains/foobar/foobar_full_000 You12:54 cd into that

silasdavis (Tue, 19 Dec 2017 12:55:02 GMT):
https://github.com/monax/bosmarmot/tree/hypermarmot/monax/tests/jobs_fixtures You12:48 https://github.com/hyperledger/burrow/pull/657 You12:50 watch docker ps -a You12:52 image versions can be found: ~/.monax/chains/foo/foo_full_000/config.toml You12:53 https://github.com/hyperledger/burrow/blob/master/Dockerfile You12:54 /home/silas/.monax/chains/foobar/foobar_full_000 You12:54 cd into that

smblucker (Tue, 19 Dec 2017 13:55:00 GMT):
@silasdavis Thank you for the clarifications on the call today...

silasdavis (Tue, 19 Dec 2017 13:59:14 GMT):
my pleasure

silasdavis (Tue, 19 Dec 2017 13:59:19 GMT):
will just write up notes here shortly

silasdavis (Tue, 19 Dec 2017 14:02:07 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=mKEqADhxFoADvB35M) @guoger

silasdavis (Tue, 19 Dec 2017 14:02:07 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=mKEqADhxFoADvB35M) @guoger `vm.call` will return the value of a solidity-compiled function in general, see: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/vm.go#L913-L921

silasdavis (Tue, 19 Dec 2017 14:03:24 GMT):
the function code will terminate with a `RETURN` that returns a contiguous block of memory to the caller

silasdavis (Tue, 19 Dec 2017 14:03:54 GMT):
a `CallTx` from the execution layer above will return a TxHash as part of the receipt

silasdavis (Tue, 19 Dec 2017 14:04:03 GMT):
but the VM layer is not even aware of the tx

silasdavis (Tue, 19 Dec 2017 14:05:05 GMT):
there are various issues with solidity compilers/ABI implementations that are a caveat to this (e.g. https://ethereum.stackexchange.com/questions/17312/solidity-can-you-return-dynamic-arrays-in-a-function) but they are being worked on (e.g. https://github.com/ethereum/solidity/issues/2948)

silasdavis (Tue, 19 Dec 2017 14:05:32 GMT):
generally simple values will be returned as the bytes that represent them: https://github.com/ethereum/solidity/issues/2948

silasdavis (Tue, 19 Dec 2017 14:05:58 GMT):
and this is by the design of solidity/ABI, not something the EVM is explicitly 'aware of'

silasdavis (Tue, 19 Dec 2017 14:28:47 GMT):
*TCS call 19/12/2017* Here are my notes from the call today. Briefly: 'monax' is command line tool for the 'Burrow' blockchain node, disregarding name changes it has always been that way. The latest _released_ version of monax is 0.18.0, the latest released version of Burrow is 0.17.0. They work as a pair and `monax init` will download Burrow. However, going forward you should be working on the as yet unreleased next version of Burrow. The upcoming version of Burrow is currently on a WIP feature branch 'hypermarmot', pull request here: https://github.com/hyperledger/burrow/pull/657. The commits are subject to change until early January, but it is stable enough for you to download and use now, and this is the relevant development. The tooling (chiefly a subset of 'monax pkgs do') has been condensed into a new monorepo including keys, compilers, and a version of the monax tool renamed 'bos' here: https://github.com/monax/bosmarmot. Here is how to get set up with the new stuff (assuming working Go environment - ask me if you need help): ``` # Install the new keys service go install github.com/monax/bosmarmot/keys/cmd/monax-keys # Go get burrow (in order to clone - note this will be master initially) go get -u github.com/hyperledger/burrow/cmd/burrow # Change branch and install hypermarmot version cd $GOPATH/src/github.com/hyperledger/burrow git checkout hypermarmot go install ./cmd/burrow ```

silasdavis (Tue, 19 Dec 2017 14:28:47 GMT):
*TCS call 19/12/2017* Here are my notes from the call today. Briefly: 'monax' is command line tool for the 'Burrow' blockchain node, disregarding name changes it has always been that way. The latest _released_ version of monax is 0.18.0, the latest released version of Burrow is 0.17.0. They work as a pair and `monax init` will download Burrow. However, going forward you should be working on the as yet unreleased next version of Burrow. The upcoming version of Burrow is currently on a WIP feature branch 'hypermarmot', pull request here: https://github.com/hyperledger/burrow/pull/657. The commits are subject to change until early January, but it is stable enough for you to download and use now, and this is the relevant development. The tooling (chiefly a subset of 'monax pkgs do') has been condensed into a new monorepo including keys, compilers, and a version of the monax tool renamed 'bos' here: https://github.com/monax/bosmarmot. Here is how to get set up with the new stuff (assuming working Go environment - ask me if you need help): ``` # Install the new keys service go install github.com/monax/bosmarmot/keys/cmd/monax-keys # Go get burrow (in order to clone - note this will be master initially) and install Hypermarmot version go get -u github.com/hyperledger/burrow/cmd/burrow # Change branch and install hypermarmot version cd $GOPATH/src/github.com/hyperledger/burrow git checkout hypermarmot go install ./cmd/burrow ```

silasdavis (Tue, 19 Dec 2017 14:28:47 GMT):
*TCS call 19/12/2017* Here are my notes from the call today. Briefly: 'monax' is command line tool for the 'Burrow' blockchain node, disregarding name changes it has always been that way. The latest _released_ version of monax is 0.18.0, the latest released version of Burrow is 0.17.0. They work as a pair and `monax init` will download Burrow. However, going forward you should be working on the as yet unreleased next version of Burrow. The upcoming version of Burrow is currently on a WIP feature branch 'hypermarmot', pull request here: https://github.com/hyperledger/burrow/pull/657. The commits are subject to change until early January, but it is stable enough for you to download and use now, and this is the relevant development. The tooling (chiefly a subset of 'monax pkgs do') has been condensed into a new monorepo including keys, compilers, and a version of the monax tool renamed 'bos' here: https://github.com/monax/bosmarmot. Here is how to get set up with the new stuff (assuming working Go environment - ask me if you need help): ``` # Install the new keys service go install github.com/monax/bosmarmot/keys/cmd/monax-keys # Go get burrow (in order to clone - note this will be master initially) and install Hypermarmot version go get -u github.com/hyperledger/burrow/cmd/burrow # Change branch and install hypermarmot version cd $GOPATH/src/github.com/hyperledger/burrow git checkout hypermarmot go install ./cmd/burrow ``` Now start keys and run a single-node chain (make sure you have disabled any running chains from a previous version of Burrow/monax) (note `$GOPATH/bin` must be in your `$PATH`): ``` # Start monax-keys in background (ps aux | grep monax-keys to find out its PID to kill it later) monax-keys server & # make a chain-dir (not really necessary) mkdir chain-dir && cd chain-dir # magically start a chain (see explanation later) burrow spec -f1 -p1 | burrow configure -v0 -s- | burrow -c- ```

silasdavis (Tue, 19 Dec 2017 14:28:47 GMT):
*TCS call 19/12/2017* Here are my notes from the call today. Briefly: 'monax' is command line tool for the 'Burrow' blockchain node, disregarding name changes it has always been that way. The latest _released_ version of monax is 0.18.0, the latest released version of Burrow is 0.17.0. They work as a pair and `monax init` will download Burrow. However, going forward you should be working on the as yet unreleased next version of Burrow. The upcoming version of Burrow is currently on a WIP feature branch 'hypermarmot', pull request here: https://github.com/hyperledger/burrow/pull/657. The commits are subject to change until early January, but it is stable enough for you to download and use now, and this is the relevant development. The tooling (chiefly a subset of 'monax pkgs do') has been condensed into a new monorepo including keys, compilers, and a version of the monax tool renamed 'bos' here: https://github.com/monax/bosmarmot. Here is how to get set up with the new stuff (assuming working Go environment - ask me if you need help): ``` # Install the new keys service go install github.com/monax/bosmarmot/keys/cmd/monax-keys # Go get burrow (in order to clone - note this will be master initially) and install Hypermarmot version go get -u github.com/hyperledger/burrow/cmd/burrow # Change branch and install hypermarmot version cd $GOPATH/src/github.com/hyperledger/burrow git checkout hypermarmot go install ./cmd/burrow ``` Now start keys and run a single-node chain (make sure you have disabled any running chains from a previous version of Burrow/monax) (note `$GOPATH/bin` must be in your `$PATH`): ``` # Start monax-keys in background (ps aux | grep monax-keys to find out its PID to kill it later) monax-keys server & # make a chain-dir (not really necessary) mkdir chain-dir && cd chain-dir # magically make and start a chain (see explanation later) burrow spec -f1 -p1 | burrow configure -v0 -s- | burrow -c- ```

silasdavis (Tue, 19 Dec 2017 14:37:12 GMT):
That last command is a kind of (code) golf-y one-liner, here is what each command in the sequence does:

silasdavis (Tue, 19 Dec 2017 14:38:31 GMT):
``` # The burrow spec command helps you to form template 'GenesisDoc' files: burrow spec --full-accounts=1 --participant-accounts=1 # returns: { "Accounts": [ { "Amount": 9999999999, "Name": "Participant_0", "Permissions": [ "send", "call", "name", "hasRole" ] }, { "Amount": 99999999999999, "AmountBonded": 9999999999, "Name": "Full_0", "Permissions": [ "all" ] } ] } ```

silasdavis (Tue, 19 Dec 2017 14:43:23 GMT):
Now let's store that genesis spec file: ``` burrow spec --full-accounts=1 --participant-accounts=1 > genesis-spec.json ``` From that we can use the `burrow configure` command to form a burrow config (including a genesis doc): ``` # Ask burrow configure to generate the necessary keys and otherwise 'fill in the blanks' to get a full genesis doc and burrow config burrow configure --genesis-spec genesis-spec.json # Returns the default TOML file: ```[GenesisDoc] GenesisTime = 2017-12-19T14:41:52Z ChainName = "BurrowChain_A8F46F" [GenesisDoc.GlobalPermissions] Roles = [] [GenesisDoc.GlobalPermissions.Base] Perms = 2302 SetBit = 16383 [[GenesisDoc.Accounts]] Address = "8BCE4CFCA4A4852FD1B32C4023D45F7D90F08A37" PublicKey = "{\"type\":\"ed25519\",\"data\":\"0F6BFB2091E3893008663DDB901FD74F304D673AA7158D7D7405B427035E64BD\"}" Amount = 9999999999 Name = "Participant_0" [GenesisDoc.Accounts.Permissions] [GenesisDoc.Accounts.Permissions.Base] Perms = 2118 SetBit = 2118 [[GenesisDoc.Accounts]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 99999999999999 Name = "Full_0" [GenesisDoc.Accounts.Permissions] [GenesisDoc.Accounts.Permissions.Base] Perms = 16383 SetBit = 16383 [[GenesisDoc.Validators]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 9999999999 Name = "Full_0" [[GenesisDoc.Validators.UnbondTo]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 9999999999 [Tendermint] Seeds = "" ListenAddress = "tcp://0.0.0.0:46656" Moniker = "" TendermintRoot = ".burrow" [Keys] URL = "http://localhost:4767" [RPC] [RPC.TM] ListenAddress = ":46657" [Logging] [Logging.root_sink] [Logging.root_sink.output] output_type = "stderr" ```

silasdavis (Tue, 19 Dec 2017 14:43:23 GMT):
Now let's store that genesis spec file: ``` burrow spec --full-accounts=1 --participant-accounts=1 > genesis-spec.json ``` From that we can use the `burrow configure` command to form a burrow config (including a genesis doc): ``` # Ask burrow configure to generate the necessary keys and otherwise 'fill in the blanks' to get a full genesis doc and burrow config burrow configure --genesis-spec genesis-spec.json # Returns the default TOML file: [GenesisDoc] GenesisTime = 2017-12-19T14:41:52Z ChainName = "BurrowChain_A8F46F" [GenesisDoc.GlobalPermissions] Roles = [] [GenesisDoc.GlobalPermissions.Base] Perms = 2302 SetBit = 16383 [[GenesisDoc.Accounts]] Address = "8BCE4CFCA4A4852FD1B32C4023D45F7D90F08A37" PublicKey = "{\"type\":\"ed25519\",\"data\":\"0F6BFB2091E3893008663DDB901FD74F304D673AA7158D7D7405B427035E64BD\"}" Amount = 9999999999 Name = "Participant_0" [GenesisDoc.Accounts.Permissions] [GenesisDoc.Accounts.Permissions.Base] Perms = 2118 SetBit = 2118 [[GenesisDoc.Accounts]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 99999999999999 Name = "Full_0" [GenesisDoc.Accounts.Permissions] [GenesisDoc.Accounts.Permissions.Base] Perms = 16383 SetBit = 16383 [[GenesisDoc.Validators]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 9999999999 Name = "Full_0" [[GenesisDoc.Validators.UnbondTo]] Address = "F748047A99221DF37189E2E7E839670C95CA0584" PublicKey = "{\"type\":\"ed25519\",\"data\":\"CADDC30A9B4158D8B76770F35773981BA37720F6C3B23C6FC788CDC04AC4A047\"}" Amount = 9999999999 [Tendermint] Seeds = "" ListenAddress = "tcp://0.0.0.0:46656" Moniker = "" TendermintRoot = ".burrow" [Keys] URL = "http://localhost:4767" [RPC] [RPC.TM] ListenAddress = ":46657" [Logging] [Logging.root_sink] [Logging.root_sink.output] output_type = "stderr" ```

silasdavis (Tue, 19 Dec 2017 14:44:39 GMT):
Note that the new Burrow (hypermarmot) allows you to specify the genesis doc embedded in the main config or to provide config separately

silasdavis (Tue, 19 Dec 2017 14:44:39 GMT):
Note that the new Burrow (hypermarmot) allows you to specify the genesis doc embedded in the main config or to provide config separately in a 'burrow.toml' and 'genesis.json' (by default)

silasdavis (Tue, 19 Dec 2017 14:55:49 GMT):
(the developer UI is kind of a mess here, having it as I do supporting JSON and TOML - I need to tidy up the configure command)

silasdavis (Tue, 19 Dec 2017 14:56:22 GMT):
nonetheless `burrow configure` replaces the essential functionality of `monax chains make`

silasdavis (Tue, 19 Dec 2017 14:56:52 GMT):
`burrow spec` is just a convenience since you could make the genesis spec by hand easily enough

silasdavis (Tue, 19 Dec 2017 14:57:58 GMT):
So for TCS team: I suggest you follow instructions above then get to a working chain

silasdavis (Tue, 19 Dec 2017 14:58:10 GMT):
also get it running in the vscode debugger using the go plugin

silasdavis (Tue, 19 Dec 2017 15:01:29 GMT):
some areas you could potentially look to contributing on very soon (as soon as hypermarmot PR is stabilised - I'll let you know when) are: - Improving the `configure` tool - like I say the JSON/TOML stuff is inconsistent and doesn't really work - just a UI/UX thing rather than anything fundamental but needs a bit of thought - Improving the genesis spec presets - currently only have participant and full account setup, but the underlying mechanism allows you to composite any number of template genesis spec files to arrive at a result. We should find a nice way to support common chain types - Improving logging - there is a powerful mechanism for customising logs, but it lacks presets and debug output from the EVM is hard to read All of these things would be good starters to get you familiar with codebase without requiring deep knowledge of blockchains or Burrow

tkuhrt (Tue, 19 Dec 2017 19:00:06 GMT):
silasdavis

smblucker (Tue, 19 Dec 2017 19:49:17 GMT):
@silasdavis and India Team: The above environment setup was not quite clear and led to some compilation errors. The following is what worked for me:

smblucker (Tue, 19 Dec 2017 19:49:37 GMT):
#ENVIRONMENT SETUP 1) Create directory for binaries in current $PATH mkdir ~/bin 2) Make working directory for monax-keys and move into it mkdir ~/Monax-Keys && cd Monax-Keys 3) Set $GOPATH export GOPATH=~/Monax-Keys 4) Install new keys service go get install github.com/bosmarmot/keys/cmd/monax-keys 5) Move binary into $PATH bin directory cd bin/ && mv monax-keys ~/bin 6) Make working directory for burrow and move into it mkdir ~/Burrow && cd Burrow 7) Set $GOPATH export GOPATH=~/Burrow 8) Get burrow go get -u github.com/hyperledger/burrow/cmd/burrow Note: no binary will be created due to compilation error; this will be corrected when hypermarmot branch is checked out 9) Make bin directory mkdir ~/Burrow/bin 10) Checkout hypermarmot branch cd src/github.com/hyperledger/burrow && git checkout hypermarmot 11) Install burrow go install ./cmd/burrow 12) Move binary into $PATH bin directory mv ~/Burrow/bin/burrow ~/bin

smblucker (Tue, 19 Dec 2017 19:52:51 GMT):
@silasdavis and India Team: the rest of the commands ran fine after environment setup

silasdavis (Tue, 19 Dec 2017 20:05:04 GMT):
Rather than juggling go path around, best generally to set it to fixed location

silasdavis (Tue, 19 Dec 2017 20:05:54 GMT):
here's what i have in my desktop environment init scripts (.profile or .bashrc will probably work): ``` export GOROOT=/usr/lib/go export GOPATH=$HOME/code/go export PATH="$GOPATH/bin:$PATH" ```

silasdavis (Tue, 19 Dec 2017 20:06:37 GMT):
but otherwise looks fine

silasdavis (Tue, 19 Dec 2017 20:07:12 GMT):
see: https://golang.org/doc/install

smblucker (Tue, 19 Dec 2017 20:18:32 GMT):
I move it around because it allows for more flexibility for working on multiple go projects...

silasdavis (Tue, 19 Dec 2017 20:19:38 GMT):

smblucker (Tue, 19 Dec 2017 20:20:19 GMT):
Nonetheless, this is just preference...

smblucker (Wed, 20 Dec 2017 14:22:00 GMT):
@silasdavis In the long-term, Andreas would like me to focus on parallelization of the EVM; in the short term, he thinks it would be beneficial to work on EVM related issues in order to get more familiar with the code and how it works. Can you provide some guidance on or suggestions of where I should start?

smblucker (Wed, 20 Dec 2017 16:49:21 GMT):
@silasdavis I ran the above commands--i.e. monax-keys server & and the magic make and start chain--yesterday without an issue; however, today I get the following error:

smblucker (Wed, 20 Dec 2017 16:49:31 GMT):
panic: Tendermint state.AppHash does not match AppHash after replay. Got A18417BB554F44D85E5031E6A9D11FADE441863E, expected 31F6284DA01AC057EDF33E48521C4C2581986527 [recovered] panic: Tendermint state.AppHash does not match AppHash after replay. Got A18417BB554F44D85E5031E6A9D11FADE441863E, expected 31F6284DA01AC057EDF33E48521C4C2581986527

smblucker (Wed, 20 Dec 2017 16:50:06 GMT):
What is this the result of and how can this be remedied?

smblucker (Wed, 20 Dec 2017 17:25:33 GMT):
@silasdavis Disregard last message; I figured it out...

silasdavis (Fri, 22 Dec 2017 10:02:12 GMT):
Regarding call now, I have to sort something out with baby, will join in 15 mins

silasdavis (Fri, 22 Dec 2017 10:02:54 GMT):
I also don't see any webex invite in the calendar

ashlinSajan (Fri, 22 Dec 2017 10:11:30 GMT):
Hi Silas

ashlinSajan (Fri, 22 Dec 2017 10:12:18 GMT):
I had sent meeting invite with WebEx details.

ashlinSajan (Fri, 22 Dec 2017 10:13:16 GMT):
Joju had send you the meeting invite

silasdavis (Fri, 22 Dec 2017 10:22:27 GMT):
I have details now (they were not in calendar) I am having issues connecting, I will try and restart my device. Can we get started in text here please

silasdavis (Fri, 22 Dec 2017 10:23:26 GMT):
As I said on the last call I foresee this mostly to be a text job, but I will try to connect to the voice call shortly

silasdavis (Fri, 22 Dec 2017 10:23:53 GMT):
What stage in the set up of Burrow according to instructions above have people got to?

smblucker (Fri, 22 Dec 2017 10:25:38 GMT):
done

silasdavis (Fri, 22 Dec 2017 10:26:33 GMT):
I am on chat now, but seem to be unable to speak

silasdavis (Fri, 22 Dec 2017 10:26:39 GMT):
it briefly said 'meeting room is locked'

silasdavis (Fri, 22 Dec 2017 10:27:09 GMT):
have I been given permissions as external guest?

smblucker (Fri, 22 Dec 2017 10:27:33 GMT):
did you dial into the bridge phone number?

silasdavis (Fri, 22 Dec 2017 10:28:37 GMT):
no I joined via the web, I suppose I can try to dial in

ashlinSajan (Fri, 22 Dec 2017 10:29:25 GMT):
silas please use the bridge details joju shared

smblucker (Fri, 22 Dec 2017 10:29:25 GMT):
screen sharing is through webex; audio is via call in

smblucker (Fri, 22 Dec 2017 10:29:54 GMT):
numbers for your region should have also been included in your email

silasdavis (Fri, 22 Dec 2017 10:35:28 GMT):
So I think Sean had mentioned using: https://code.visualstudio.com/

silasdavis (Fri, 22 Dec 2017 10:35:38 GMT):
what IDE/text editors do yo use?

silasdavis (Fri, 22 Dec 2017 10:48:49 GMT):
https://github.com/monax/bosmarmot/tree/master/monax/tests/jobs_fixtures

silasdavis (Fri, 22 Dec 2017 10:50:34 GMT):
https://github.com/monax/bosmarmot

silasdavis (Fri, 22 Dec 2017 10:51:45 GMT):
`go install github.com/monax/bosmarmot/monax/cmd/bos`

silasdavis (Fri, 22 Dec 2017 11:04:14 GMT):
`burrow spec --full-accounts=1 --participant-accounts=1 | burrow configure -s- -v0 > burrow.toml`

silasdavis (Fri, 22 Dec 2017 11:04:27 GMT):
to run this chain `burrow`

silasdavis (Fri, 22 Dec 2017 11:04:37 GMT):
to reset chain `rm -rf .burrow`

silasdavis (Fri, 22 Dec 2017 11:08:42 GMT):
`$GOPATH/src/github.com/monax/bosmarmot/monax/tests/jobs_fixtures/app13-binding_abi_using_naming_pattern_and_explicit_abi_fields_single_file`

silasdavis (Fri, 22 Dec 2017 11:11:50 GMT):
`cd chain-dir burrow configure -j | jq -r '.GenesisDoc.Validators[0].Address'`

silasdavis (Fri, 22 Dec 2017 12:32:55 GMT):
@jojujacob I got kicked from that call

silasdavis (Fri, 22 Dec 2017 12:33:42 GMT):
Shall we wrap this up now anyway

smblucker (Fri, 22 Dec 2017 12:40:39 GMT):
Thanks for your time

silasdavis (Fri, 22 Dec 2017 12:41:20 GMT):
So I think where we were rounding of there was what bits of the code would be good for you to work on. I will have some more structured tickets to work on as soon as I have finished off the hypermarmot/bosmarmot work. In the meantime I hope you can have a play with the development loop we covered

silasdavis (Fri, 22 Dec 2017 12:41:52 GMT):
I am also suggesting that you might look at the tooling UX and could experiment with changes their, the vm_test.go tests, and possibly logging

silasdavis (Fri, 22 Dec 2017 12:42:44 GMT):
if that seems horribly open-ended then I would spend the time between now and early Jan converting your Burrow 0.17.0 understanding to the new way of doing things - they are substantially the same under the hood

silasdavis (Fri, 22 Dec 2017 12:42:56 GMT):
@smblucker no problem, glad we got a screen sharing sorted out

silasdavis (Fri, 22 Dec 2017 12:43:11 GMT):
I'm just going to drink more coffee, then I'll add notes of what we did here

smblucker (Fri, 22 Dec 2017 12:43:49 GMT):
@silasdavis By development loop, you mean?

silasdavis (Fri, 22 Dec 2017 12:45:29 GMT):
as in the 'human loop' of 'run monax-keys', 'make burrow config', (*), 'run burrow', 'run bos pkgs do', 'change code', repeat (*)

silasdavis (Fri, 22 Dec 2017 12:45:48 GMT):
how to get stuff done on Burrow

smblucker (Fri, 22 Dec 2017 12:46:04 GMT):
okay

silasdavis (Fri, 22 Dec 2017 13:48:46 GMT):
*Burrow and Bosmarmot instructions* We'll reprise the earlier instructions to set up a Burrow chain and create a persistent `burrow.toml` config to work with. _note: the jq tool is not essential but to use command below you will need it, install with: `sudo apt-get install jq`_ *Step 1* Stop any running chains or services. *Step 2* Start `monax-keys` in a terminal: ``` monax-keys server ``` *Step 3* In another terminal, create a chain directory to store Burrow config and working directory: ``` mkdir frollicking-marmota cd frollicking-marmota ``` *Step 4* Generate `burrow.toml` config: ``` burrow spec --full-accounts=1 --participant-accounts=1 | burrow configure --genesis-spec=- --validator-index=0 > burrow.toml ``` This will generate the keys for 2 accounts (1 validator, 1 participant) and populate a Burrow config file with the necessary addresses. Since Burrow looks for `burrow.toml` by default in the next step we don't need any arguments *Step 5* Run Burrow: ``` burrow ``` *Step 6* In another terminal deploy a package (assuming you have a single global `$GOPATH`): ``` # Ensure you have the monax replacement 'bos': go get -u github.com/monax/bosmarmot/monax/cmd/bos # Enter directory of a particular test fixture (chosen randomly, feel free to chose another or your own epm directory): cd $GOPATH/src/github.com/monax/bosmarmot/monax/tests/jobs_fixtures/app13-binding_abi_using_naming_pattern_and_explicit_abi_fields_single_file # Grab the address of the validator of this 1-node chain (calls running chain RPC and uses jq): addr=$(curl -s http://localhost:46657/genesis | jq -r '.result.data.genesis.Validators[0].Address') echo "should see an address:" $addr ```

silasdavis (Fri, 22 Dec 2017 13:48:46 GMT):
*Burrow and Bosmarmot instructions* We'll reprise the earlier instructions to set up a Burrow chain and create a persistent `burrow.toml` config to work with. _note: the jq tool is not essential but to use command below you will need it, install with: `sudo apt-get install jq`_ *Step 1* Stop any running chains or services. *Step 2* Start `monax-keys` in a terminal: ``` monax-keys server ``` *Step 3* In another terminal, create a chain directory to store Burrow config and working directory: ``` mkdir frollicking-marmota cd frollicking-marmota ``` *Step 4* Generate `burrow.toml` config: ``` burrow spec --full-accounts=1 --participant-accounts=1 | burrow configure --genesis-spec=- --validator-index=0 > burrow.toml ``` This will generate the keys for 2 accounts (1 validator, 1 participant) and populate a Burrow config file with the necessary addresses. Since Burrow looks for `burrow.toml` by default in the next step we don't need any arguments *Step 5* Run Burrow: ``` burrow ``` *Step 6* In another terminal deploy a package (assuming you have a single global `$GOPATH`): ``` # Ensure you have the monax replacement 'bos': go get -u github.com/monax/bosmarmot/monax/cmd/bos # Enter directory of a particular test fixture (chosen randomly, feel free to chose another or your own epm directory): cd $GOPATH/src/github.com/monax/bosmarmot/monax/tests/jobs_fixtures/app13-binding_abi_using_naming_pattern_and_explicit_abi_fields_single_file # Grab the address of the validator of this 1-node chain (calls running chain RPC and uses jq): addr=$(curl -s http://localhost:46657/genesis | jq -r '.result.data.genesis.Validators[0].Address') echo "should see an address:" $addr # Run the EPM (equivalent to monax pkgs do): bos pkgs do -a $addr ```

silasdavis (Fri, 22 Dec 2017 13:48:46 GMT):
*Burrow and Bosmarmot instructions* We'll reprise the earlier instructions to set up a Burrow chain and create a persistent `burrow.toml` config to work with. *Prerequisites* - Install Burrow from hypermarmot branch - Install monax-keys: `go get -u github.com/monax/bosmarmot/keys/cmd/monax-keys` - Install bos: `go get -u github.com/monax/bosmarmot/monax/cmd/bos` - Install jq: `sudo apt-get install jq` (on Ubuntu) _ note: the jq tool is not essential but to use command below you will need it _ *Step 1* Stop any running chains or services. *Step 2* Start `monax-keys` in a terminal: ``` monax-keys server ``` *Step 3* In another terminal, create a chain directory to store Burrow config and working directory: ``` mkdir frollicking-marmota cd frollicking-marmota ``` *Step 4* Generate `burrow.toml` config: ``` burrow spec --full-accounts=1 --participant-accounts=1 | burrow configure --genesis-spec=- --validator-index=0 > burrow.toml ``` This will generate the keys for 2 accounts (1 validator, 1 participant) and populate a Burrow config file with the necessary addresses. Since Burrow looks for `burrow.toml` by default in the next step we don't need any arguments *Step 5* Run Burrow: ``` burrow ``` *Step 6* In another terminal deploy a package (assuming you have a single global `$GOPATH`): ``` # Ensure you have the monax replacement 'bos': go get -u github.com/monax/bosmarmot/monax/cmd/bos # Enter directory of a particular test fixture (chosen randomly, feel free to chose another or your own epm directory): cd $GOPATH/src/github.com/monax/bosmarmot/monax/tests/jobs_fixtures/app13-binding_abi_using_naming_pattern_and_explicit_abi_fields_single_file # Grab the address of the validator of this 1-node chain (calls running chain RPC and uses jq): addr=$(curl -s http://localhost:46657/genesis | jq -r '.result.data.genesis.Validators[0].Address') echo "should see an address:" $addr # Run the EPM (equivalent to monax pkgs do): bos pkgs do -a $addr ``` *Step 7* You should see a successful EPM run ending with: ``` *****Executing Job***** Job Name assertStorage Assertion Succeeded 5 == 5 ``` Now you should be able to substitute that test fixture with your own contracts and epm.yaml files. Note that I am still ironing out some last issues with the new packages and you may encounter some issues with sequence number collisions. This will be resolved shortly.

silasdavis (Fri, 22 Dec 2017 13:48:46 GMT):
*Burrow and Bosmarmot instructions* We'll reprise the earlier instructions to set up a Burrow chain and create a persistent `burrow.toml` config to work with. *Prerequisites* - Install Burrow from hypermarmot branch: ``` # Make sure you have repo (ignore errors) go get -u github.com/hyperledger/burrow/cmd/burrow # Checkout hypermarmot branch cd $GOPATH/src/github.com/hyperledger/burrow git checkout hypermarmot # Install burrow binary go install ./cmd/burrow ``` - Install monax-keys: `go get -u github.com/monax/bosmarmot/keys/cmd/monax-keys` - Install bos: `go get -u github.com/monax/bosmarmot/monax/cmd/bos` - Install jq: `sudo apt-get install jq` (on Ubuntu) _ note: the jq tool is not essential but to use command below you will need it _ *Step 1* Stop any running chains or services. *Step 2* Start `monax-keys` in a terminal: ``` monax-keys server ``` *Step 3* In another terminal, create a chain directory to store Burrow config and working directory: ``` mkdir frollicking-marmota cd frollicking-marmota ``` *Step 4* Generate `burrow.toml` config: ``` burrow spec --full-accounts=1 --participant-accounts=1 | burrow configure --genesis-spec=- --validator-index=0 > burrow.toml ``` This will generate the keys for 2 accounts (1 validator, 1 participant) and populate a Burrow config file with the necessary addresses. Since Burrow looks for `burrow.toml` by default in the next step we don't need any arguments *Step 5* Run Burrow: ``` burrow ``` *Step 6* In another terminal deploy a package (assuming you have a single global `$GOPATH`): ``` # Ensure you have the monax replacement 'bos': go get -u github.com/monax/bosmarmot/monax/cmd/bos # Enter directory of a particular test fixture (chosen randomly, feel free to chose another or your own epm directory): cd $GOPATH/src/github.com/monax/bosmarmot/monax/tests/jobs_fixtures/app13-binding_abi_using_naming_pattern_and_explicit_abi_fields_single_file # Grab the address of the validator of this 1-node chain (calls running chain RPC and uses jq): addr=$(curl -s http://localhost:46657/genesis | jq -r '.result.data.genesis.Validators[0].Address') echo "should see an address:" $addr # Run the EPM (equivalent to monax pkgs do): bos pkgs do -a $addr ``` *Step 7* You should see a successful EPM run ending with: ``` *****Executing Job***** Job Name assertStorage Assertion Succeeded 5 == 5 ``` Now you should be able to substitute that test fixture with your own contracts and epm.yaml files. Note that I am still ironing out some last issues with the new packages and you may encounter some issues with sequence number collisions. This will be resolved shortly.

silasdavis (Fri, 22 Dec 2017 13:51:26 GMT):

silasdavis (Fri, 22 Dec 2017 14:05:05 GMT):

rohanagarwal (Mon, 25 Dec 2017 21:31:02 GMT):
Has joined the channel.

ashlinSajan (Tue, 26 Dec 2017 10:16:43 GMT):
hi @silasdavis I am getting an error while deploying "The program 'bos' is currently not installed. To run 'bos' please ask your administrator to install the package 'openafs-client'".

ashlinSajan (Tue, 26 Dec 2017 10:48:58 GMT):
hi @silasdavis I am getting an error while deploying "The program 'bos' is currently not installed. To run 'bos' please ask your administrator to install the package 'openafs-client'".I installed openafs-client.Then the terminal shows " bos: Unrecognized operation 'pkgs'; type 'bos help' for list"

silasdavis (Tue, 26 Dec 2017 16:55:42 GMT):
@ashlinSajan bos has nothing to do with openafs and that message is just Ubuntu trying to suggest a package that contains a binary with the same name. We need the go binary we are installing with `go get -u github.com/monax/bosmarmot/monax/cmd/bos`. You need to have `$GOPATH/bin` in your `$PATH` variable. Make sure you have followed https://golang.org/doc/install to set up your Go environment properly.

silasdavis (Tue, 26 Dec 2017 16:56:22 GMT):
If you have installed the `bos` binary you can run it directly with `$GOPATH/bin/bos`

silasdavis (Tue, 26 Dec 2017 16:56:41 GMT):
but you'll probably want to have the go binary directory in your PATH like I say

smblucker (Tue, 26 Dec 2017 23:53:41 GMT):
@silasdavis I am getting the following error deploying the contract:

smblucker (Tue, 26 Dec 2017 23:53:48 GMT):
*****Executing Job***** Job Name defaultAddr *****Executing Job***** Job Name setStorageBase *****Executing Job***** Job Name deployGSFactory exec: "solc": executable file not found in $PATH: Error compiling contracts: Language error: exec: "solc": executable file not found in $PATH:

smblucker (Tue, 26 Dec 2017 23:54:16 GMT):
My path variable:

smblucker (Tue, 26 Dec 2017 23:55:23 GMT):
home/ubuntu1/anaconda3/bin:/home/ubuntu1/bin:/home/ubuntu1/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/usr/local/go/bin:/home/ubuntu1/go/bin

smblucker (Tue, 26 Dec 2017 23:55:59 GMT):
My GOPATH:

smblucker (Tue, 26 Dec 2017 23:56:08 GMT):
home/ubuntu1/go

smblucker (Tue, 26 Dec 2017 23:58:02 GMT):
Everything else ran fine without any problems--i.e. monax-keys, burrow, and bos --help.

smblucker (Wed, 27 Dec 2017 00:07:18 GMT):
@silasdavis Nevermind. I needed to install solc. Everything ran fine after that...

ashlinSajan (Wed, 27 Dec 2017 03:39:18 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=3fTjCNEHLptCsiife) @silasdavis I have the bos binary but still unable to run

ashlinSajan (Wed, 27 Dec 2017 09:53:29 GMT):
Thank you @silasdavis We have resolved the issue.The contract was deployed successfully.

silasdavis (Wed, 27 Dec 2017 09:56:26 GMT):
@smblucker yes sorry that was an omission from my instructions, bos uses the system solc and needs that go be present rather than using a version packaged in a docker container.

smblucker (Wed, 27 Dec 2017 14:48:14 GMT):
@silasdavis Are revisions being made to the code of bos and burrow right now? I am trying to set up my environment at work, and the go get commands are failing.

silasdavis (Wed, 27 Dec 2017 14:54:53 GMT):
Go get will fail with burrow because master is not go gettable. It will still download code but you need the hypermarnot branch. Best to manage the repos with git commands and install from there. Bos should be go gettable. Master had not changed. Nor should have hypermarnot branch on burrow, but I do need to rebase it at some point

smblucker (Wed, 27 Dec 2017 14:56:05 GMT):
Here is the go get error for bos:

smblucker (Wed, 27 Dec 2017 14:56:57 GMT):
github.com/monax/bosmarmot/monax/keys src/github.com/monax/bosmarmot/monax/keys/keys.go:41:23: localKeyClient.HealthCheck undefined (type *LocalKeyClient has no field or method HealthCheck) src/github.com/monax/bosmarmot/monax/keys/keys.go:52:24: localKeyClient.HealthCheck undefined (type *LocalKeyClient has no field or method HealthCheck) # github.com/hyperledger/burrow/account src/github.com/hyperledger/burrow/account/account.go:86:20: undefined: wire.Codec src/github.com/hyperledger/burrow/account/priv_account.go:38:26: invalid type assertion: pA.PrivKey.(crypto.PrivKeyEd25519) (non-interface type crypto.PrivKey on left) src/github.com/hyperledger/burrow/account/priv_account.go:67:9: cannot use pubKey (type crypto.PubKeyEd25519) as type crypto.PubKey in field value src/github.com/hyperledger/burrow/account/priv_account.go:68:10: cannot use privKey (type crypto.PrivKeyEd25519) as type crypto.PrivKey in field value src/github.com/hyperledger/burrow/account/priv_account.go:87:9: cannot use pubKey (type crypto.PubKeyEd25519) as type crypto.PubKey in field value src/github.com/hyperledger/burrow/account/priv_account.go:88:10: cannot use privKey (type crypto.PrivKeyEd25519) as type crypto.PrivKey in field value src/github.com/hyperledger/burrow/account/priv_account.go:103:9: cannot use pubKey (type crypto.PubKeyEd25519) as type crypto.PubKey in field value src/github.com/hyperledger/burrow/account/priv_account.go:104:10: cannot use privKey (type crypto.PrivKeyEd25519) as type crypto.PrivKey in field value # github.com/tendermint/go-p2p src/github.com/tendermint/go-p2p/peer.go:169:42: cannot use p.PubKey() (type crypto.PubKeyEd25519) as type crypto.PubKey in argument to peerNodeInfo.PubKey.Equals src/github.com/tendermint/go-p2p/secret_connection.go:51:34: invalid type assertion: locPrivKey.PubKey().(crypto.PubKeyEd25519) (non-interface type crypto.PubKey on left) src/github.com/tendermint/go-p2p/secret_connection.go:99:26: invalid type assertion: remPubKey.(crypto.PubKeyEd25519) (non-interface type crypto.PubKey on left) src/github.com/tendermint/go-p2p/secret_connection.go:258:43: invalid type assertion: locPrivKey.Sign(challenge[:]).(crypto.SignatureEd25519) (non-interface type crypto.Signature on left) src/github.com/tendermint/go-p2p/secret_connection.go:273:48: cannot use pubKey (type crypto.PubKeyEd25519) as type crypto.PubKey in field value src/github.com/tendermint/go-p2p/secret_connection.go:273:56: cannot use signature (type crypto.SignatureEd25519) as type crypto.Signature in field value src/github.com/tendermint/go-p2p/secret_connection.go:297:40: cannot use remSignature (type crypto.SignatureEd25519) as type crypto.Signature in argument to remPubKey.VerifyBytes src/github.com/tendermint/go-p2p/switch.go:157:44: invalid type assertion: nodePrivKey.PubKey().(crypto.PubKeyEd25519) (non-interface type crypto.PubKey on left) src/github.com/tendermint/go-p2p/switch.go:216:42: cannot use peer.PubKey() (type crypto.PubKeyEd25519) as type crypto.PubKey in argument to sw.nodeInfo.PubKey.Equals src/github.com/tendermint/go-p2p/switch.go:534:31: invalid type assertion: privKey.PubKey().(crypto.PubKeyEd25519) (non-interface type crypto.PubKey on left) src/github.com/tendermint/go-p2p/switch.go:534:31: too many errors # github.com/hyperledger/burrow/genesis src/github.com/hyperledger/burrow/genesis/make_genesis_file.go:146:9: cannot use pubKey (type crypto.PubKeyEd25519) as type crypto.PubKey in field value src/github.com/hyperledger/burrow/genesis/types.go:128:29: cannot convert nil to type crypto.PubKey

smblucker (Wed, 27 Dec 2017 15:04:48 GMT):
@silasdavis Nevermind. Whatever the issue was, it resolved itself. I did not do anything except retry the command...

smblucker (Wed, 27 Dec 2017 20:41:14 GMT):
@silasdavis In response to a previous question posed by me, you characterized the development loop as a "'human loop' of 'run monax-keys', 'make burrow config', (*), 'run burrow', 'run bos pkgs do', 'change code', repeat (*)". I am hung up on the 'change code', repeat(*) part, and it is not surprising given that the above instructions cover everything up to these points. After reading the burrow contributing file (a prerequisite read), code changes--i.e. working on issues and creating new features--would require forking the burrow repository, cloning the fork locally, adding the remote, checking out the hypermarmot branch, creating a new branch for the issue or feature, merging/rebasing, pushing, etc. Testing the changes would require compiling and running the tools as explained above. My question include the following:

smblucker (Wed, 27 Dec 2017 20:41:38 GMT):
1) Should we be thinking about this right now or just how to use the tools?

smblucker (Wed, 27 Dec 2017 20:49:31 GMT):
2) If we should, can you explain cloning in the context of our Go workspace (the GOPATH target)--i.e. where should the clone of fork be placed-- which would be required for rebuilding and testing changes?

smblucker (Wed, 27 Dec 2017 21:05:53 GMT):
@silasdavis I apologize for my noob-ness in advance...

silasdavis (Thu, 28 Dec 2017 16:48:33 GMT):
not at all

silasdavis (Thu, 28 Dec 2017 16:49:21 GMT):
Here is how I Burrow: ```

silasdavis (Thu, 28 Dec 2017 16:49:21 GMT):
Here is how I Burrow: ``` cd $GOPATH/src/github.com/hyperledger/burrow git remote add silas git@github.com:silasdavis/burrow.git git fetch silas ```

silasdavis (Thu, 28 Dec 2017 16:49:21 GMT):
Here is how I Burrow: ``` cd $GOPATH/src/github.com/hyperledger/burrow git remote add silas git@github.com:silasdavis/burrow.git git fetch silas git checkout origin/hypermarmot git checkout -b hyperforkingmarmot # git push -u silas hyperforkingmarmot ```

silasdavis (Thu, 28 Dec 2017 16:53:21 GMT):
so I think to answer your question, I'd work in a single GOPATH root, each top-level package is generally a git repo so you can add remotes and switch branches within the same canonical directory (so code will compile)

silasdavis (Thu, 28 Dec 2017 16:54:38 GMT):
Burrow 'vendors' its dependencies (in the latest version), this means it uses deps that are in the `vendor/` directory in preference to dependencies under the same namespaces (i.e. paths) in your `$GOPATH`

silasdavis (Thu, 28 Dec 2017 16:56:19 GMT):
sometimes when working across projects - in our case we might see this with working on bosmarmot which depends on (and vendors in) Burrow it can be convenient to temporarily delete, for example, burrow from the bosmarmot vendor directory so that it uses your whatever is in your current working directory as its Burrow dependency - which may contain some updated code you are integrating

silasdavis (Thu, 28 Dec 2017 16:59:18 GMT):
for changes just to Burrow it is straightforward though - just add your fork as a remote, fork the hypermarmot branch, make changes, push it to you fork, ... , make a PR

silasdavis (Thu, 28 Dec 2017 16:59:53 GMT):
again, right now I am a bad person and I am sharing commits that I will need to rebase, but I intend to sort that soon

smblucker (Thu, 28 Dec 2017 19:39:00 GMT):
@silasdavis Should the instruction 'git checkout origin/hypermarmot' be 'git checkout silas/hypermarmot'?

compleatang (Fri, 29 Dec 2017 10:09:38 GMT):
@smblucker yeah, indeed it should be.

smblucker (Fri, 29 Dec 2017 15:19:37 GMT):
@compleatang Thank you.

compleatang (Fri, 29 Dec 2017 16:11:18 GMT):
No worries.

elias_p (Sat, 30 Dec 2017 10:30:41 GMT):
Has joined the channel.

silasdavis (Sat, 30 Dec 2017 17:26:21 GMT):
no I did mean `origin/hypermarmot` assuming origin is the hyperledger repo - I was assuming `s/silas/sean` and that you wouldn't have a hypermarmot branch yourself... `silas/hypermarmot` does happen to exist of course...

smblucker (Tue, 02 Jan 2018 15:28:26 GMT):
@silasdavis Given that Andreas wanted me to focus on the EVM, I know you mentioned that I should have a look at vm.go and vm_test.go to gain an understanding of what is going on there. Can you perhaps point me toward something specific you would like me to change/improve in those files or perhaps a current issue that has been brought up on Github that would be good for a beginner?

silasdavis (Tue, 02 Jan 2018 16:10:18 GMT):
@smblucker one aspect you could look at is removing the use of 'magic' byte literals in `vm_test.go`. Such as here: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/vm_test.go#L81

silasdavis (Tue, 02 Jan 2018 16:10:53 GMT):
You'll find that the named constants are dot-imported into `vm.go` from here: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/opcodes/opcodes.go

silasdavis (Tue, 02 Jan 2018 16:12:00 GMT):
So for example rather than using hard-coded `0x60` we should use the symbol `PUSH1`

silasdavis (Tue, 02 Jan 2018 16:13:27 GMT):
some of this is a bit mechanical, but if you first translate the hard-coded test values into bytecode, then spend some time understanding it, add some comments (sorely missing from much of those tests), and possibly generalise the test (either by adding a variant or extending the existing one - but make sure we are covering the same cases.

silasdavis (Tue, 02 Jan 2018 16:13:51 GMT):
Where this gets more involved would be with a test like: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/vm_test.go#L124-L153

silasdavis (Tue, 02 Jan 2018 16:14:06 GMT):
which is based on some Serpent code now lost the winds of time

silasdavis (Tue, 02 Jan 2018 16:14:06 GMT):
which is based on some Serpent code now lost to the winds of time

silasdavis (Tue, 02 Jan 2018 16:14:42 GMT):
reverse engineering that test and re-writing in a clear way to test the same functionality would be useful. Currently if we were to break a test like that we'd have very little to go on

silasdavis (Tue, 02 Jan 2018 16:16:25 GMT):
Oh, those links are to master, you'll want to work in hypermarmot branch obviously

silasdavis (Tue, 02 Jan 2018 16:16:34 GMT):
I have a helper named splice: https://github.com/hyperledger/burrow/blob/hypermarmot/execution/evm/vm_test.go#L205

silasdavis (Tue, 02 Jan 2018 16:16:34 GMT):
I have a helper named `Splice`: https://github.com/hyperledger/burrow/blob/hypermarmot/execution/evm/vm_test.go#L205

silasdavis (Tue, 02 Jan 2018 16:16:42 GMT):
that you might find useful for working with bytecode

silasdavis (Tue, 02 Jan 2018 16:16:42 GMT):
that you might find useful for working with bytecode. It joins together various bytecode-like values collapsing sequences into a single sequence (i.e. splice/flatten).

silasdavis (Tue, 02 Jan 2018 16:17:10 GMT):
you can give certain combinations of instructions their own name which can aid readability

silasdavis (Tue, 02 Jan 2018 16:17:10 GMT):
This allows you to reuse certain combinations of instructions by assigning them to a variable or output of a function, which you can then mix in to other bytecode and splice will stitch the entire sequence together. This can aid readability significantly.

silasdavis (Tue, 02 Jan 2018 16:18:49 GMT):
ideally we should have a suite of tests written in bytecode at a sort of 'intermediate' level of abstraction - not in Solidity, since these are unit tests we don't want to couple ourselves to the solidity compiler - but with enough helpers for us to write non-trivial bytecode to test at the EVM/ABI level of abstraction

silasdavis (Tue, 02 Jan 2018 16:20:09 GMT):
So the tl;dr for getting started would be: 1. Use the constant references to opcodes rather than magic bytes 2. Understand what each test is doing by running the bytecode in your head 3. Document what is being tested

BrianPurvis (Tue, 02 Jan 2018 17:23:04 GMT):
Has joined the channel.

smblucker (Wed, 03 Jan 2018 18:44:07 GMT):
@silasdavis In vm_test.go (line 80), there is a byte array element byte(0x60 + len(N) - 1), which I have interpreted and changed to PUSH2, and another element (line 81) byte(0x1b + len(N)), which I have interpreted and changed to the value 0x1d given the previous PUSH1. I have run 'go test' against vm_test.go with changes that left these elements untouched and it passed; I also ran 'go test' against vm_test.go with my interpreted values, and it also passed. My question is why did you originally tie these values to the length of the byte array N? Also, in changing the magic bytes to opcodes, I had to cast them in the following way--i.e. for a PUSH1, I had to write byte(PUSH1). Is this what you intended for me to do, or is there a cleaner way to achieve this casting?

jtclark (Thu, 04 Jan 2018 17:09:12 GMT):
Has joined the channel.

smblucker (Mon, 08 Jan 2018 15:55:36 GMT):
@silasdavis I created a pull request for the changes I made to vm_test.go. I await your feedback at your earliest convenience. Thank you.

silasdavis (Mon, 08 Jan 2018 16:07:15 GMT):
Hey Sean, sorry I didn't get back you yet on the above. I've been on a limited schedule. I'll take a look at PR and get back to you. I am currently rebasing commits so we may need to retarder

smblucker (Mon, 08 Jan 2018 18:20:52 GMT):
Okay.

silasdavis (Tue, 09 Jan 2018 19:50:18 GMT):
@smblucker @jojujacob @ashlinSajan @rosemaria I have finalised the work so far on the hypermarmot refactor (subject to review) and have opened a new pull request here: https://github.com/hyperledger/burrow/pull/666 (PR of the beast...)

silasdavis (Tue, 09 Jan 2018 19:51:43 GMT):
I have created a new feature branch `feature/hypermarmot` (just so as to not to rebase commits on the `hypermarmot` branch), which is even with develop aside from having all of the updated third party dependencies pusher there

silasdavis (Tue, 09 Jan 2018 19:52:09 GMT):
the pull request is into that feature branch where I intend to make further PRs to stabilise the refactor

silasdavis (Tue, 09 Jan 2018 19:52:46 GMT):
However I promise to not change (rebase) any commits on feature/hypermarmot once it is merged

silasdavis (Tue, 09 Jan 2018 19:53:38 GMT):
furthermore as a feature branch I believe this PR is mergeable despite rpc/v0 (the javascript RPC) being broken (not wired up)

silasdavis (Tue, 09 Jan 2018 19:54:29 GMT):
I have discovered a race condition in my testing of this code that I think may be a bug in Tendermint. Until I can get the bottom of that issue this code will not be good for release (to master), but it should be a safe base to base any further work on

silasdavis (Tue, 09 Jan 2018 19:54:57 GMT):
once rpc/v0 is implemented again (my next task - should not take more than a day or so) then I will consider this code mergeable to develop

silasdavis (Tue, 09 Jan 2018 19:55:38 GMT):
There are then various bugs we can work on and I will make sure these are properly capture by issues

silasdavis (Tue, 09 Jan 2018 19:56:21 GMT):
@jojujacob could you make an issue for the chain panic you are seeing. It is on an much older version of the code but looking at the trace I believe it should still be present.

silasdavis (Tue, 09 Jan 2018 20:08:46 GMT):
@smblucker regarding your question - bear in mind I didn't actually write any of the vm tests - the reason the length of `N` is used in combination with the `PUSH` opcode is that the intention of the code is to push the bytes in the `N` slice onto the stack and a the appropriate push is the one corresponding to the length of the slice. My 'Splice' function (https://github.com/silasdavis/burrow/blob/hypermarmot/execution/evm/asm/bc/helpers.go#L15) can help here with the casting/readability. We should be able to rewrite the entire `code` assignment in a single declarative block, e.g.: ``` sixZeroes := Splice(0,0,0,0,0,0) code := Splice(PUSH1, 0x21, sixZeroes) assert.Equal(t, []byte{0x60,0x21,0x0,0x0,0x0,0x0,0x0,0x0}, code) ``` So we can mix `OpCode` (just an explicit named type for a byte that happens to be a real opcode), bytes, and sequences of bytes (as `[]byte`) and it will convert in a flattened sequence of bytes. In a particular if you have a repetitive reusable segment of code (like the sixZeroes example) then you can define a function to emit that or a variable and just pass it to splice, which is much easier than doing something similar with an explicit loop all the time.

silasdavis (Tue, 09 Jan 2018 20:10:20 GMT):
Your PR will need to be based off the commits currently waiting to be merged from https://github.com/silasdavis/burrow/tree/hypermarmot on the PR above

silasdavis (Tue, 09 Jan 2018 20:10:31 GMT):
you can rebase now or you can wait until its merged

silasdavis (Tue, 09 Jan 2018 20:11:03 GMT):
then you will need to make the pr to the `feature/hypermarmot` branch not `master` as you currently have it

silasdavis (Tue, 09 Jan 2018 20:11:15 GMT):
I want to get the hypermarmot branch merged this week

ashlinSajan (Wed, 10 Jan 2018 07:05:53 GMT):
@silasdavis panic: Paniced on a Sanity Check

ashlinSajan (Wed, 10 Jan 2018 07:09:31 GMT):
@silasdavis We have mentioned the issue for chain panic in https://github.com/hyperledger/burrow/issues named panic: Paniced on a Sanity Check#668 and Chain getting stopped on transaction execution #667 Could you please check and review the same.

ashlinSajan (Wed, 10 Jan 2018 12:36:01 GMT):
@silasdavis We have seen the pull request you have sent. Can you provide some guidance on or suggestions of where we should start?

silasdavis (Wed, 10 Jan 2018 12:44:23 GMT):
Hi Ashlin I've taken a look at the issue. That seems to be the panic you get when restarting the chain - not the panic that @jojujacob sent me that originally stops the chain. The chain restart issue is an issue with Tendermint that has been resolved. Can you you review my comment which has the stack trace I think is of interest - I assume they are from the same issue.

ashlinSajan (Wed, 10 Jan 2018 12:58:49 GMT):
@silasdavis I have sent the same issue that Joju mentioned in the https://github.com/hyperledger/burrow/issues named Chain getting stopped on transaction execution#667 Could you please help in resolving the same?

silasdavis (Wed, 10 Jan 2018 13:00:25 GMT):
Sorry I see you send both, easier if you direct link to the issue rather than the issues page

silasdavis (Wed, 10 Jan 2018 13:00:43 GMT):
Also you can use back ticks ```

silasdavis (Wed, 10 Jan 2018 13:00:43 GMT):
Also you can use back ticks \`\`\`

silasdavis (Wed, 10 Jan 2018 13:00:43 GMT):
Also you can use back ticks \`\`\` as code fence for sections of logs or code to make them more readable in the issue

silasdavis (Wed, 10 Jan 2018 13:05:11 GMT):
regarding the PR: it's a big ask to get a comprehensive review given that you are new to the codebase

silasdavis (Wed, 10 Jan 2018 13:06:10 GMT):
so I'm not expecting you to catch deep or wide-ranging issues at this stage, but anything you might spot in terms of code quality issues will be a useful contribution

silasdavis (Wed, 10 Jan 2018 13:06:41 GMT):
for example - if I am shadowing a variable, making a concurrency mistake, etc

silasdavis (Wed, 10 Jan 2018 13:07:10 GMT):
I realise it will probably be difficult to follow the full logic - though it will be useful learning experience for you to try

silasdavis (Wed, 10 Jan 2018 13:07:35 GMT):
but at the unit/function level just checking my go code will be useful

silasdavis (Wed, 10 Jan 2018 13:07:51 GMT):
They way I suggest you approach it is to look at changes from each commit in order

silasdavis (Wed, 10 Jan 2018 13:09:02 GMT):
Github has a good UI for this, if you go to the changes view you can filter changes by commits with the dropdown on the left

silasdavis (Wed, 10 Jan 2018 13:09:45 GMT):

PR-commits.png

silasdavis (Wed, 10 Jan 2018 13:10:35 GMT):
Feel free to ask questions by creating a comment on a line

silasdavis (Wed, 10 Jan 2018 13:10:58 GMT):
when you click on a line a comment box will come up

silasdavis (Wed, 10 Jan 2018 13:18:28 GMT):
oh, you can also show commits from multiple changes by shift-clicking on them in the changes view

jtclark (Wed, 10 Jan 2018 15:18:59 GMT):
GM!

jtclark (Wed, 10 Jan 2018 15:19:25 GMT):
@silasdavis I'm going to try out Burrow this AM on my local machine

jtclark (Wed, 10 Jan 2018 15:19:55 GMT):
Perhaps I can grab some time with you this week, so that you can bring me up to speed on things?

silasdavis (Wed, 10 Jan 2018 18:02:49 GMT):
glad to though next week would be better

silasdavis (Wed, 10 Jan 2018 18:02:49 GMT):
glad to though next week would be better for me though

ashlinSajan (Thu, 11 Jan 2018 04:09:50 GMT):
@silasdavis Thank you for the guidance Silas.We'll go through the changes in commits for sure.

silasdavis (Fri, 12 Jan 2018 10:00:32 GMT):
here is hangout for Tata meeting: To join the video meeting, click this link: https://meet.google.com/emy-nueg-xfc

silasdavis (Fri, 12 Jan 2018 10:13:55 GMT):
https://git-scm.com/book/en/v2/Git-Branching-Rebasing

silasdavis (Fri, 12 Jan 2018 10:23:40 GMT):
https://github.com/golang/dep

PrakashJha (Sat, 13 Jan 2018 15:17:28 GMT):
Has joined the channel.

PrakashJha (Sat, 13 Jan 2018 15:17:33 GMT):
can you pls help me to setup xo_java in aws sawtootth ami server

silasdavis (Mon, 15 Jan 2018 13:31:18 GMT):
To PR https://github.com/hyperledger/burrow/pull/666 reviewers, I noticed some incorrectly checked in vendor changes and some other changes that were separated between the EVM/execution commits. So I have rebased fixing those and squashing the EVM/Execution commits into one. If you have checked out from my fork you will need to: ``` git fetch silas git reset --hard silas/hypermarmot ``` To see latest changes, assuming you added me as a remote with `git remote add silas https://github.com/hyperledger/burrow/pull/666`

silasdavis (Mon, 15 Jan 2018 13:32:13 GMT):
User User_1 removed by silasdavis.

smblucker (Tue, 16 Jan 2018 16:27:16 GMT):
@silasdavis In order to properly place my PR, do I need to refork hyperledger/burrow (my current fork does not include feature/hypermarmot), checkout feature/hypermarmot, checkout -b changes, push to new fork, and submit new PR to feature/hypermarmot?

silasdavis (Tue, 16 Jan 2018 16:28:36 GMT):
you don't need to clone again, no. Can you show me the output of `git remote -vv`

smblucker (Tue, 16 Jan 2018 19:10:50 GMT):
@silasdavis smblucker@smblucker-VirtualBox:~/go/src/github.com/hyperledger/burrow$ git remote -vv origin https://github.com/hyperledger/burrow (fetch) origin https://github.com/hyperledger/burrow (push) sean git@github.com:smblucker/burrow.git (fetch) sean git@github.com:smblucker/burrow.git (push)

smblucker (Tue, 16 Jan 2018 19:55:09 GMT):
@silasdavis Also, will Friday's call (1-19-18) be through Google Hangouts?

silasdavis (Tue, 16 Jan 2018 22:34:41 GMT):
@smblucker if you do: ``` # add my fork (where I PR'ing from) git remote add silas git@code.monax.io:silasdavis/burrow.git git fetch silas # create (and checkout) a new local branch called 'hypermarmot-pr' that tracks - and is a copy of - my fork's hypermarmot branch git checkout -b hypermarmot-pr silas/hypermarmot # branch again to start working on your stuff git checkout -b vmtestchanges-rebased # now we'll cherry-pick your commits git cherry-pick 9bee1671d82b9624b81a2e7b713e8abfabcbcd87 e791daf63fddd4bf8479524f22fa2934ebb8eb63 ``` Since the origin/hypermarmot branch is no longer interesting (base is feature/hypermarmot) and vmtestchanges-rebase supercedes vmtestchanges I would then get our your big point stick and do: ``` git checkout vmtestchanges git reset --hard vmtestchanges-rebased

silasdavis (Tue, 16 Jan 2018 22:35:38 GMT):
with the latter you could just skip the `git checkout -b hypermarmot-pr silas/hypermarmot` line

silasdavis (Tue, 16 Jan 2018 22:36:33 GMT):
having said, lazy mode I've done it for you: https://github.com/silasdavis/burrow/commits/vmtestchanges-rebased

silasdavis (Tue, 16 Jan 2018 22:37:04 GMT):
so add my remote and just: ``` git fetch silas git reset --hard silas/vmtestchanges-rebased ```

silasdavis (Tue, 16 Jan 2018 22:38:32 GMT):
which will have the effect of all of the above - apart from also `git checkout hypermarmot && git reset --hard silas/hypermarmot` which is fine provided you have no changes on your local hypermarmot branch (beware reset --hard rewrite history - the reflog can still save you if you overwrite something with rebase, cherry-pick, or reset --hard though...)

silasdavis (Tue, 16 Jan 2018 22:39:23 GMT):
Regarding the call I will be screen-sharing on hangouts - link in invite - but I think we are doing voice over webex/dial in @jojujacob can you email round the numbers and participant codes

silasdavis (Tue, 16 Jan 2018 22:39:31 GMT):
isn't it stupid o'clock for you again though?

silasdavis (Tue, 16 Jan 2018 22:39:41 GMT):
I would be happy to do a separate session with you

silasdavis (Tue, 16 Jan 2018 22:39:51 GMT):
though not on the same day...

silasdavis (Tue, 16 Jan 2018 22:43:24 GMT):
alternatively I could attempt to record the session - though I have never tried to record something that long with ffmpeg

silasdavis (Tue, 16 Jan 2018 22:43:39 GMT):
I think GSuite Enterprise has that feature but we don't have it...

silasdavis (Tue, 16 Jan 2018 22:44:09 GMT):
also happy to reschedule if there is a mutually acceptable time - I think it's tricky though, you are -8:00 hours IIRC ?

silasdavis (Tue, 16 Jan 2018 22:46:21 GMT):
though it would have to be a day other than Friday as I can only do morning then

jojujacob (Wed, 17 Jan 2018 06:36:46 GMT):
Hi Silas, No issues will have the meeting as you scheduled. Bridge details shared in the mail.

smblucker (Wed, 17 Jan 2018 18:00:03 GMT):
@silasdavis To recap:

smblucker (Wed, 17 Jan 2018 18:01:47 GMT):
```*git remote add silas git@code.monax.io:silasdavis/burrow.git*

smblucker (Wed, 17 Jan 2018 18:02:13 GMT):
git fetch silas

smblucker (Wed, 17 Jan 2018 18:02:54 GMT):
git reset --hard silas/vmtestchanges-rebased

smblucker (Wed, 17 Jan 2018 18:03:28 GMT):
git checkout hypermarmot && git reset --hard silas/hypermarmot

smblucker (Wed, 17 Jan 2018 18:03:56 GMT):
git checkout silas/vmtestchanges-rebased

smblucker (Wed, 17 Jan 2018 18:05:00 GMT):
git push sean silas/vmtestchanges-rebased

smblucker (Wed, 17 Jan 2018 18:05:13 GMT):
make new PR

smblucker (Wed, 17 Jan 2018 18:12:55 GMT):
As for the call, I can be on the call this week (yes, it is very early) so as to not hold up progress, but I would like to work out an arrangement for the future where we (you and I) can have meetings that do not require the coordination of three time zones. I am open to meetings on any day of the week and am flexible to accommodate your scheduling demands. Also, I have brought this up to Joju and wanted to get your take on it for this call: Since Google Hangouts supports both screen sharing and voice, is there a need for a separate bridge call?

silasdavis (Wed, 17 Jan 2018 18:17:52 GMT):
@smblucker what I would do is: ``` git fetch silas # your branch git checkout vmtestchanges # overwrite your branch locally git reset --hard silas/vmtestchanges-rebased # _force_ push the overwritten branch to your fork git push sean +vmtestchanges ``` I'm not sure what `git push sean silas/vmtestchanges-rebased` will do, but I think it might create a remote branch called 'silas/vmtestchanges-rebased' which I don't think it what you want

smblucker (Wed, 17 Jan 2018 18:19:54 GMT):
Okay. Should I submit a new PR as well?

silasdavis (Wed, 17 Jan 2018 18:30:11 GMT):
Yes, but the question is against what branch

silasdavis (Wed, 17 Jan 2018 18:31:28 GMT):
Before I can merge it I really need to have the silas/hypermarmot -> origin/feature/hypermarmot, then silas/rpc-v0 -> origin/feature/hypermarmot (possibly), then origin/feature/hypermarmot -> origin/develop

silasdavis (Wed, 17 Jan 2018 18:32:09 GMT):
by rebasing your commits we are trying to anticipate getting on the end of that queue

silasdavis (Wed, 17 Jan 2018 18:32:42 GMT):
what we could do is make a feature branch on origin for you to start PRing into

silasdavis (Wed, 17 Jan 2018 18:33:41 GMT):
how about I push 'origin/feature/vm-testing' as a copy of 'silas/hypermamot'

silasdavis (Wed, 17 Jan 2018 18:34:07 GMT):
we can accumulate vm testing work there and it should be minimal work when we need to merge/rebase it onto develop

silasdavis (Wed, 17 Jan 2018 18:36:23 GMT):
Okay... let's do that, here is the branch: https://github.com/hyperledger/burrow/tree/feature/vm-testing

silasdavis (Wed, 17 Jan 2018 18:36:30 GMT):
make your new PR against that

silasdavis (Wed, 17 Jan 2018 18:36:54 GMT):
@smblucker I take it you saw my remarks in this channel about how you can use `Splice`?

smblucker (Wed, 17 Jan 2018 18:50:23 GMT):
@silasdavis Okay, I see; sorry about my confusion. Indeed, I did see your remarks on how to use Splice. However, if the goal of changing to opcode constants is to increase readability/clarity so as to make it more apparent what the testing code is doing, I think the mileage we get out of using Splice will vary. It certainly has value for reducing the PUSH29 in TestSubcurrency; however, much of the rest of the code does not have many repetitive sequences or long PUSH operations that would lend themselves to variable assignment. If you have chance, can we speak about this, as well as the previous concerns, at some time?

silasdavis (Wed, 17 Jan 2018 18:52:03 GMT):
I agree that there is some cognitive cost to using `Splice`, but my hope is that it is worth that cost in providing an idiom for writing something akin to 'bytecode literals'

silasdavis (Wed, 17 Jan 2018 19:31:07 GMT):
@smblucker yes it would be good to talk, I've sent you an invite for I think your 10am on Monday - if that doesn't work suggest another time

silasdavis (Wed, 17 Jan 2018 19:31:53 GMT):
regarding Friday meeting - we don't really need the voice, but sometimes Plain Old Telephony has better voice and perhaps someone needs to dial in...? @jojujacob

jojujacob (Thu, 18 Jan 2018 04:35:41 GMT):
@silasdavis Yes you are right telephony has better voice, there won't be any network issues come in between. So we will use the bridge for the voice and screen sharing on hangout..

guoger (Thu, 18 Jan 2018 15:33:45 GMT):
@silasdavis does Burrow check permission when one contract is invoking another contract? IIUC Ethereum doesn't do that? thx

pouladzade (Mon, 22 Jan 2018 06:52:36 GMT):
Has joined the channel.

pouladzade (Mon, 22 Jan 2018 06:52:58 GMT):
Hi guys, We are considering using burrow for our project but unfortunately the burrow doesn't have the API like web3, and legacy-db and legacy-contracts are mentioned as deprecated in the github, as I know there should be an web3 like API under development, but I am not sure when will be ready. if anyone know about that please share with me maybe we can also contribute on that If the burrow can support web3, the community easily can benefit of all the ethereum tools like truffle I am already developing a simple tool using truffle and legacy-db and legacy-contract modules for compiling, deploying, testing and doing transactions on burrow, if any body interested to contribute please let me know

pouladzade (Mon, 22 Jan 2018 07:03:45 GMT):
but this tool will not cover all our requirements and it's only for short time usage

pouladzade (Mon, 22 Jan 2018 07:04:19 GMT):
Still we hope hear some news about the web3 on the burrow

guoger (Mon, 22 Jan 2018 07:59:34 GMT):
web3 layer is needed by Fabric/Burrow/Sawtooth, and collaborative effort is ongoing

pouladzade (Mon, 22 Jan 2018 08:25:41 GMT):
@guoger thanks for update, do you have any Idea about the release date?

guoger (Mon, 22 Jan 2018 08:53:15 GMT):
@pouladzade sorry I don't know the release date... it's still in design phase.. to consolidate interfaces for 3 projects is a bit tough...

pouladzade (Mon, 22 Jan 2018 08:54:23 GMT):
@guoger I see, so it seems it will not be released in near future!

guoger (Mon, 22 Jan 2018 08:54:34 GMT):
I'm afraid not :(

pouladzade (Mon, 22 Jan 2018 09:06:18 GMT):
are they gonna change the rpc json api layer in the Burrow ?

prithveesh (Mon, 22 Jan 2018 11:44:02 GMT):
Has joined the channel.

silasdavis (Mon, 22 Jan 2018 12:12:20 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=iMRuarXrTbCCBKpSJ) @guoger at that stage we know Tx input address has the `Call` permission so we have nothing to check. We do check for the `Create` permission when a contract tries to do that. Is that what you meant?

silasdavis (Mon, 22 Jan 2018 12:13:21 GMT):
@pouladzade I am aiming to provide some form of web3 support sooner than a month. Achieving good compatibility may take a little longer

silasdavis (Mon, 22 Jan 2018 18:37:57 GMT):
@smblucker Possible that this code: https://github.com/ethereum/serpent-go/blob/master/serpent/examples/subcurrency.se

silasdavis (Mon, 22 Jan 2018 18:38:10 GMT):
Is where this test comes from: https://github.com/silasdavis/burrow/blob/607d44666195c9f758d33b5a677fa90e6057fb0b/execution/evm/vm_test.go#L137

silasdavis (Mon, 22 Jan 2018 18:48:33 GMT):
@smblucker See EVM issues: https://github.com/hyperledger/burrow/issues/588

pouladzade (Tue, 23 Jan 2018 10:17:44 GMT):
@silasdavis Thanks

smblucker (Tue, 23 Jan 2018 19:33:27 GMT):
@silasdavis First, today my ubuntu-vm at work crashed and was totally destroyed. I spent most of today reconfiguring a new vm. Good news...everything (monax-keys, bos, burrow) is functioning correctly. I followed the former instructions to create a remote based on my fork. I checked out sean/vmtestchanges and then tried to add your remote: git remote add silas git@code.monax.io:silasdavis/burrow.git and fetch silas. I received this error: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Thoughts?

silasdavis (Tue, 23 Jan 2018 19:38:25 GMT):
ah

silasdavis (Tue, 23 Jan 2018 19:38:33 GMT):
happens

silasdavis (Tue, 23 Jan 2018 19:39:10 GMT):
unless you have a backup of you SSH key, usually at: `~/.ssh/id_rsa` you'll need to reconfigure github to accept a new ssh key

silasdavis (Tue, 23 Jan 2018 19:39:31 GMT):
You just need to add it here: https://github.com/settings/keys

smblucker (Tue, 23 Jan 2018 20:01:24 GMT):
I did setup a new ssh key on github

silasdavis (Wed, 24 Jan 2018 11:18:30 GMT):
oh I seen to have given you my private fork

silasdavis (Wed, 24 Jan 2018 11:18:30 GMT):
oh I seen to have given you my private fork on Monax's gitlab

silasdavis (Wed, 24 Jan 2018 11:18:35 GMT):
must have copy and pasted wrong at some point

silasdavis (Wed, 24 Jan 2018 11:19:42 GMT):
Should be: `git remote add silas git@github.com:silasdavis/burrow.git`

silasdavis (Wed, 24 Jan 2018 11:21:37 GMT):
I had copy-pasted from the wrong repo when I sent original instructions, sorry about that

smblucker (Wed, 24 Jan 2018 20:50:23 GMT):
@silasdavis Thank you. I was able to add your remote, fetch silas, and git reset --hard silas/vmtestchanges-rebased without complication. I added gpg keys on my work systems so future commits will be signed as well. I will get to editing vm_test.go using Splice as well as the other tasks we discussed...

reyaansh (Thu, 25 Jan 2018 11:55:31 GMT):
Has joined the channel.

guoger (Mon, 29 Jan 2018 05:16:29 GMT):
@silasdavis is `feature/hypermarmot` current buildable? `make build` gives quite a few errors...

silasdavis (Mon, 29 Jan 2018 09:05:45 GMT):
@guoger it's not buildable it currently serves as a base with all the updated dependencies. It will be largely buildable after this PR: https://github.com/hyperledger/burrow/pull/666 which I will get merged today

bharatahuja (Mon, 29 Jan 2018 16:29:16 GMT):
Has joined the channel.

bharatahuja (Mon, 29 Jan 2018 16:29:32 GMT):
hi

guoger (Tue, 30 Jan 2018 02:26:14 GMT):
@silasdavis just to make sure I get this correct, to leverage burrow-evm lib, I should use `feature/hypermarmot` instead of `hypermarmot`, right? thx!

smblucker (Tue, 30 Jan 2018 16:44:30 GMT):
@silasdavis I created new pull request against feature/vm-testing branch for your review. Again, it is devoid of any rebasing (there are only three commits that could be considered a 'logical unit of work') since we have been unable to connect regarding how to accomplish this...

silasdavis (Tue, 30 Jan 2018 18:32:02 GMT):
That's right

smblucker (Wed, 31 Jan 2018 16:37:50 GMT):
@silasdavis I was trying to setup my development environment on my company laptop and some issues popped up. First, the instruction to 'git checkout hypermarmot' after using 'go get' to fetch burrow had to be changed to 'git checkout feature/hypermarmot'. After this change, burrow built fine. The second issue arose when trying to 'go get' bos; I received this error: ```github.com/monax/bosmarmot/monax/keys/keys.go:30:3: undefined: "github.com/hyperledger/burrow/keys".NewBurrowKeyClient```. Checking the relevant files, it seems that if NewBurrowKeyClient() existed it has either been deleted or replaced. In hyperledger/burrow/keys/key_client.go there is a NewKeyClient(...) function; this is what I believe is being called in monax/keys/keys.go. However, the call is being made by a function with the same name, though the number of arguments for the two functions are different. If I change the call in order to try to get bos to build, will go be intelligent enough to know that the call to the function with the same name is not a recursive call to itself? Also, should I be messing with this at all?

smblucker (Wed, 31 Jan 2018 16:53:47 GMT):
@silasdavis Update: I changed all references to NewBurrowKeyClient() in keys.go, jobs_contracts.go, and jobs_transact.go, and bos built fine. Would you like me to raise an issue on GitHub, make the changes, and submit a PR? (Sorry for messing with this--my thinking was I could delete everything if it did not work out)

silasdavis (Wed, 31 Jan 2018 18:47:15 GMT):
ah ... this needs to be mentioened

silasdavis (Wed, 31 Jan 2018 18:47:15 GMT):
ah ... this needs to be resolved but bosmarmot depends on Burrow in the GOPATH

silasdavis (Wed, 31 Jan 2018 18:48:23 GMT):
this was to ease mutual development but I will put Burrow back in the bosmarmot vendor directory at some point

silasdavis (Wed, 31 Jan 2018 18:49:19 GMT):
Yeah that won't have been synced across, PR welcome :) - I do need to take another pass to reintegrate

LeDang (Thu, 01 Feb 2018 04:00:18 GMT):
Has joined the channel.

smblucker (Thu, 01 Feb 2018 14:57:14 GMT):
@silasdavis PR for bosmarmot is ready for review

mohit.sharma (Fri, 02 Feb 2018 06:18:30 GMT):
Has joined the channel.

silasdavis (Sun, 04 Feb 2018 19:04:28 GMT):
@ashlinSajan @rosemaria @jojujacob @brillia sorry I wasn't able to package you up with a suggestion of what to work on is to test that the rpc/V0 works against https://github.com/monax/legacy-db.js. I believe you will have some hello would type apps written in node.js from you training that you might be able to use, otherwise I will try and provide you with some code. The initial research task is to check that the app runs against master and try to get it working against develop. I'll try to provide more guidance tomorrow but wanted you to have an idea of my suggestion in the morning

silasdavis (Mon, 05 Feb 2018 10:37:32 GMT):
Today I will move JS libs to monorepo

gaurav94 (Mon, 05 Feb 2018 15:12:40 GMT):
Has joined the channel.

guoger (Wed, 07 Feb 2018 06:11:36 GMT):
@silasdavis how is `msg.sender` handled in burrow-evm? is it caller address? thx

guoger (Wed, 07 Feb 2018 07:08:52 GMT):
I load this simple solidity contract code into burrow-evm, which seems to be giving me a truncated original bytecode, instead of `caller address` I expected ``` pragma solidity ^0.4.0; contract SimpleStorage { function get() public constant returns (address) { return msg.sender; } } ```

guoger (Wed, 07 Feb 2018 07:08:52 GMT):
I load this simple solidity contract code into burrow-evm, which seems to be giving me a truncated original bytecode, instead of `caller address` I expected. I'm using Remix only compiler. ``` pragma solidity ^0.4.0; contract SimpleStorage { function get() public constant returns (address) { return msg.sender; } } ```

guoger (Wed, 07 Feb 2018 07:08:52 GMT):
burrow-evm seems to give me truncated original bytecode, instead of caller account address I expected. Here's what I did: Adding following test to `vm_test.go` at latest `feature/hypermarmot` branch ``` func TestMsgSender(t *testing.T) { st := newAppState() account1 := newAccount(1, 2, 3) account2 := newAccount(3, 2, 1) st.accounts[account1.Address()] = account1 st.accounts[account2.Address()] = account2 ourVm := NewVM(st, DefaultDynamicMemoryProvider, newParams(), acm.ZeroAddress, nil, logger) var gas uint64 = 100000 /* pragma solidity ^0.4.0; contract SimpleStorage { function get() public constant returns (address) { return msg.sender; } } */ // This bytecode is compiled from Solidity contract above using remix.ethereum.org online compiler code, err := hex.DecodeString("6060604052341561000f57600080fd5b60ca8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636d4ce63c146044575b600080fd5b3415604e57600080fd5b60546096565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6000339050905600a165627a7a72305820b9ebf49535372094ae88f56d9ad18f2a79c146c8f56e7ef33b9402924045071e0029") if err != nil { t.Fatal(err) } // Input is the function hash of `get()` input, err := hex.DecodeString("6d4ce63c") if err != nil { t.Fatal(err) } output, err := ourVm.Call(account1, account2, code, input, 0, &gas) fmt.Printf("Output: %x Error: %v\n", output, err) if err != nil { t.Fatal(err) } } ```

guoger (Wed, 07 Feb 2018 07:08:52 GMT):
burrow-evm seems to give me truncated original bytecode, instead of caller account address I expected. Here's what I did: Adding following test to `vm_test.go` at latest `feature/hypermarmot` branch ``` func TestMsgSender(t *testing.T) { st := newAppState() account1 := newAccount(1, 2, 3) account2 := newAccount(3, 2, 1) st.accounts[account1.Address()] = account1 st.accounts[account2.Address()] = account2 ourVm := NewVM(st, DefaultDynamicMemoryProvider, newParams(), acm.ZeroAddress, nil, logger) var gas uint64 = 100000 /* pragma solidity ^0.4.0; contract SimpleStorage {function get() public constant returns (address) { return msg.sender; } } */ // This bytecode is compiled from Solidity contract above using remix.ethereum.org online compiler code, err := hex.DecodeString("6060604052341561000f57600080fd5b60ca8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636d4ce63c146044575b600080fd5b3415604e57600080fd5b60546096565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6000339050905600a165627a7a72305820b9ebf49535372094ae88f56d9ad18f2a79c146c8f56e7ef33b9402924045071e0029") if err != nil { t.Fatal(err) } // Input is the function hash of `get()` input, err := hex.DecodeString("6d4ce63c") if err != nil { t.Fatal(err) } output, err := ourVm.Call(account1, account2, code, input, 0, &gas) fmt.Printf("Output: %x Error: %v\n", output, err) if err != nil { t.Fatal(err) } } ```

guoger (Wed, 07 Feb 2018 07:09:00 GMT):
cc @silasdavis

compleatang (Wed, 07 Feb 2018 13:32:05 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=8qDsepBhS8B3KFcrt) @guoger yes. i'm almost certain that's correct.

guoger (Wed, 07 Feb 2018 14:24:12 GMT):
@compleatang thanks! Do you know what's wrong with the unit test I posted?

silasdavis (Wed, 07 Feb 2018 17:14:55 GMT):
@guoger I've updated the test to reflect what I said on call: https://github.com/hyperledger/burrow/pull/681

silasdavis (Wed, 07 Feb 2018 17:15:05 GMT):
give it a quick review and I'll merge to Burrow

silasdavis (Wed, 07 Feb 2018 17:17:44 GMT):
See this section of code to see how that replicates the logic of the current execution framework: https://github.com/hyperledger/burrow/blob/develop/execution/execution.go#L343-L379

silasdavis (Wed, 07 Feb 2018 17:18:24 GMT):
And yes `msg.sender` compiles to the `CALLER` opcode which is the caller address

silasdavis (Wed, 07 Feb 2018 17:52:45 GMT):
@jojujacob et al: what I'd like to ask you and the team to take a look at is verifying some legacy-contracts based node js apps against the develop branch of burrow. My colleague Tyler has added a simple getter setter test: https://github.com/monax/bosmarmot/tree/master/test

silasdavis (Wed, 07 Feb 2018 17:53:18 GMT):
but if you could update some existing apps you have (ideally as mocha tests) that is going to be useful

craik.zhang (Thu, 08 Feb 2018 00:43:52 GMT):
Has joined the channel.

guoger (Thu, 08 Feb 2018 07:11:01 GMT):
@silasdavis another question, in burrow-evm, what's the relation between `callee.code` and `code`? ``` func (vm *VM) call(caller, callee acm.MutableAccount, code, input []byte, value uint64, gas *uint64) (output []byte, err error) ``` Quoting [Solidity doc](http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html#index-8) > If the target account contains code, that code is executed and the payload is provided as input data. I guess it's not the case? we are always executing `code`, instead of `callee`'s code, correct?

guoger (Thu, 08 Feb 2018 07:11:01 GMT):
@silasdavis @compleatang another question, in burrow-evm, what's the relation between `callee.code` and `code`? ``` func (vm *VM) call(caller, callee acm.MutableAccount, code, input []byte, value uint64, gas *uint64) (output []byte, err error) ``` Quoting [Solidity doc](http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html#index-8) > If the target account contains code, that code is executed and the payload is provided as input data. I guess it's not the case? we are always executing `code`, instead of `callee`'s code, correct?

smblucker (Thu, 08 Feb 2018 16:18:40 GMT):
@silasdavis I would like to tackle issue #660 (Glide install from source fails due to outdated / migrated dependencies on tendermint packages), but I have a some questions? Do I need to be assigned to the issue; if so, can you assign me to it? Which branch would the PR need to be made against? I have used an amended process for the glide install referenced in the former, and it ran without error or prompting for github credentials. However, I have ssh keys set up as well. Do you think it is worth noting in the revised install instructions that ssh keys should be set up, or do you want alternate installs where ssh keys are and are not set up? Thoughts?

silasdavis (Thu, 08 Feb 2018 16:26:45 GMT):
@smblucker see my responses in DM also

silasdavis (Thu, 08 Feb 2018 16:29:10 GMT):
Actually I fixed #660 and have now closed (thanks)

silasdavis (Thu, 08 Feb 2018 16:29:44 GMT):
I'd like you to take a look at: https://github.com/hyperledger/burrow/issues/600

smblucker (Thu, 08 Feb 2018 16:29:54 GMT):
Okay.

silasdavis (Thu, 08 Feb 2018 16:30:13 GMT):
I also have another thing that would be handy which there is no ticket for and I was thinking of doing

silasdavis (Thu, 08 Feb 2018 16:30:41 GMT):
which was to build a lexer for bytecode - basically automatically doing some of what you did in vm_tests

silasdavis (Thu, 08 Feb 2018 16:31:23 GMT):
takes bytecodes and spits out a slice of opcodes/values render as strings

silasdavis (Thu, 08 Feb 2018 16:31:47 GMT):
600 is fairly clearly more important

silasdavis (Thu, 08 Feb 2018 16:32:01 GMT):
but if you'd like a nice self-contained go problem it's kind of cute

silasdavis (Thu, 08 Feb 2018 16:32:14 GMT):
and useful for generating human-readable test cases from solc

silasdavis (Thu, 08 Feb 2018 16:32:46 GMT):
bonus: use `go generate` to automatically create test cases in go from solidity bytecode

smblucker (Thu, 08 Feb 2018 16:35:12 GMT):
Okay. I will look into both of these, but you should expect some questions along the way...

smblucker (Thu, 08 Feb 2018 16:37:16 GMT):
Please create the ticket for the lexer and assign both issues to me

silasdavis (Thu, 08 Feb 2018 17:15:21 GMT):
I've just invited you to the Burrow collaborators group, you'll need to accept then you can assign that issue to yourself I think

silasdavis (Thu, 08 Feb 2018 17:15:33 GMT):
at least you need to accept for me to be able to assign it to you

zramsay (Thu, 08 Feb 2018 18:11:21 GMT):
Has joined the channel.

smblucker (Thu, 08 Feb 2018 19:16:30 GMT):
I accepted it, but I am still not listed as a contributor

smblucker (Thu, 08 Feb 2018 19:19:28 GMT):
Also cannot currently assign myself an issue...

silasdavis (Thu, 08 Feb 2018 21:38:58 GMT):
You're assigned now

smblucker (Fri, 09 Feb 2018 19:50:59 GMT):
@silasdavis In vm.go, I can see only two places (line #'s 854 and 927) where gas is manipulated; there is also a todo comment for adding functionality related to gas. Since the primary functionality of revert is to return a value and refund any remaining gas, is there any part of that todo that relates to the changes that I have to make?

silasdavis (Mon, 12 Feb 2018 11:37:04 GMT):
There is also `useGasNegative` throughout vm.go, however we effectively run with a 0 gas cost though we do allow transactions to specify a gas limit to stop them from running forever

silasdavis (Mon, 12 Feb 2018 11:37:04 GMT):
There is also `useGasNegative` throughout vm.go. However, we do not charge for gas so effectively run with a 0 gas cost allowing transactions to specify a gas limit to stop them from running forever, so we have nothing to refund, which is what I assume the EIP means by 'returning remaining gas'

silasdavis (Mon, 12 Feb 2018 11:38:55 GMT):
So in Burrow I think the utility of Revert will be in returning an error message - but don't trust me on that make sure that makes sense in context of the EIP: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-140.md

silasdavis (Mon, 12 Feb 2018 11:39:20 GMT):
I may be missing something

silasdavis (Mon, 12 Feb 2018 11:43:29 GMT):
Might be worth seeing what go-ethereum does: https://github.com/ethereum/go-ethereum/ and see if anything else transferred

silasdavis (Mon, 12 Feb 2018 11:44:30 GMT):
not sure which TODO you are referring to, perhaps you mean the 'do something with fee'. That's a separate issue - namely that we currently deduct a fee but don't send it anywhere. I don't think you need to touch that to implement this

gaurav94 (Tue, 13 Feb 2018 11:27:50 GMT):
how could we add new accounts using RPC endpoints using node js using burrow chain? Any help will be appreciated ?

smblucker (Wed, 14 Feb 2018 17:14:17 GMT):
@silasdavis I am having a problem with one of the requirements of the REVERT opcode--i.e. that it should, in addition to returning an error message, return a message. Like RETURN, REVERT returns a byte array and an error message. The byte array it seems cannot be rendered as a message--i.e. a human readable message. The following output should clarify:

smblucker (Wed, 14 Feb 2018 17:16:24 GMT):
```Testing Code: func TestRevert(t *testing.T) { ourVm := NewVM(newAppState(), DefaultDynamicMemoryProvider, newParams(), acm.ZeroAddress, nil, logger) // Create accounts account1 := newAccount(1) account2 := newAccount(1, 0, 1) var gas uint64 = 100000 bytecode := MustSplice(PUSH32, 0x72, 0x65, 0x76, 0x65, 0x72, 0x74, 0x20, 0x6D, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, PUSH1, 0x00, MSTORE, PUSH1, 0x0E, PUSH1, 0x00, REVERT) start := time.Now() output, err := ourVm.Call(account1, account2, bytecode, []byte{}, 0, &gas) fmt.Printf("Output: %v Error: %v\n", output, err) assert.Error(t, err, "Expected execution reverted error") fmt.Println("Call took:", time.Since(start)) } 'go test' Output: Output: [] Error: Call took: 237.957493ms Output: [114 101 118 101 114 116 32 109 101 115 115 97 103 101] Error: Execution reverted Ethereum EVM Tool Output (using same bytecode): #### TRACE #### PUSH32 pc=00000000 gas=10000000000 cost=3 PUSH1 pc=00000033 gas=9999999997 cost=3 Stack: 00000000 726576657274206d657373616765000000000000000000000000000000000000 MSTORE pc=00000035 gas=9999999994 cost=6 Stack: 00000000 0000000000000000000000000000000000000000000000000000000000000000 00000001 726576657274206d657373616765000000000000000000000000000000000000 Memory: 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| PUSH1 pc=00000036 gas=9999999988 cost=3 Memory: 00000000 72 65 76 65 72 74 20 6d 65 73 73 61 67 65 00 00 |revert message..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| PUSH1 pc=00000038 gas=9999999985 cost=3 Stack: 00000000 000000000000000000000000000000000000000000000000000000000000000e Memory: 00000000 72 65 76 65 72 74 20 6d 65 73 73 61 67 65 00 00 |revert message..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| REVERT pc=00000040 gas=9999999982 cost=3 ERROR: invalid opcode 0xfd Stack: 00000000 0000000000000000000000000000000000000000000000000000000000000000 00000001 000000000000000000000000000000000000000000000000000000000000000e Memory: 00000000 72 65 76 65 72 74 20 6d 65 73 73 61 67 65 00 00 |revert message..| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00```

smblucker (Wed, 14 Feb 2018 17:20:33 GMT):
You will notice that the testing code generates an output [] and an error message; however, the content of the output are the integer equivalents of the ascii characters contained in the evm tool output in memory ('revert message')--i.e. 'r' = 114 = 0x72. How do you want me to proceed, and do you have recommendations on how to solve this?

smblucker (Wed, 14 Feb 2018 17:22:12 GMT):
Sorry, testing output should read:

smblucker (Wed, 14 Feb 2018 17:22:42 GMT):
```Output: [114 101 118 101 114 116 32 109 101 115 115 97 103 101] Error: Execution reverted Call took: 1.396569ms```

silasdavis (Fri, 16 Feb 2018 11:47:27 GMT):
@smblucker could you push your changes to a branch so I can look at them please?

smblucker (Fri, 16 Feb 2018 14:41:58 GMT):
@silasdavis My changes are pushed to branch 'implementrevertop-600'

silasdavis (Fri, 16 Feb 2018 18:06:32 GMT):
A few things here: 1. Strings in Go are arbitrary byte slices, to all intents and purposes you can treat `string` as identical to `[]byte` and they are convertable, so `str := string(bs)` and `bs := []byte(str)` are availabe and that's what you should do if you have a byte slice with some text. 2. When our execution receives an error from `vm.Call` it 'automatically reverts' - actually it just doesn't commit the tx which has the same effect. We will want to return an exception and that may be all we need to do (we can embed the return value in the exception as a string) - but I need to have a closer look at other implementations to make sure that is correct - particularly for nested calls. I think its the right thing to do but I need to check. Will get back to you on that. 3. It is not idiomatic to return a value and an error in Go so we should avoid that. In any case in the case of a full revert then that output can't be used and should just be a message. Again I need to check that this is not actually meant to provide a non-error return for nested calls.

smblucker (Fri, 16 Feb 2018 18:28:24 GMT):
I tried the conversions you mentioned; however, you cannot return the string from revert because go views the string as a string and not a byte array, and a byte array must be returned from revert. Further, I tried making it into a string and, using hex.DecodeToString which returns a byte array, tried returning the decoded version, but when you convert it back to a byte array you get the integer equivalents of ascii values. The EIP 140 clearly states that there should be both an error returned and a message that essentially says the same thing (except in the case of create, where I believe only the error message is needed). I am perfectly fine with revert returning only the error message; I can leave the output as nil. Thoughts?

smblucker (Fri, 16 Feb 2018 18:36:47 GMT):
I think the idea of the output message, in addition to the error message, was that the programmer could define a more specific error message to display (besides "execution reverted"); this also explains the purpose of the two stack items it pulls (offset and size), which would allow for variable length user-defined messages to be displayed...

smblucker (Fri, 16 Feb 2018 18:37:26 GMT):
Surely this would be more informative...

pouladzade (Sat, 17 Feb 2018 03:25:46 GMT):
Hi guys, I have a question, I just made a small app for working with Burrow using legacy-db and legacy-contract and put it in github. I choose the MIT license for that but the the legacy-contract is LGPL 2

pouladzade (Sat, 17 Feb 2018 03:26:07 GMT):
I just use the libraries and didn't change them

pouladzade (Sat, 17 Feb 2018 03:26:32 GMT):
so, the MIT license is ok?

pouladzade (Sat, 17 Feb 2018 03:26:40 GMT):
https://github.com/pouladzade/snack/tree/master

pouladzade (Sat, 17 Feb 2018 03:27:07 GMT):
https://www.npmjs.com/package/snak

silasdavis (Sat, 17 Feb 2018 14:15:04 GMT):
@pouladzade that is awesome! Given the effort you've already put in I'd be very interested in getting you involved with the Javascript libraries if you are interested. With the possibility of becoming a contributor/maintainer if that interests you. In particular I think it is important for you to understand our plans for developing a web3 compatible API - though for the time being we will maintain our own and we may continue to provide additional features/event modalities through them. I'd be happy to have a call about this.

silasdavis (Sat, 17 Feb 2018 14:25:30 GMT):
regarding licensing - as far as any code we have written goes I'm fairly sure we would be happy to relicense it (we'd choose Apache 2.0 to be consistent with our Hyperledger license I think). I believe the reason the JS libs are LGPL is sort of precautionary since the depend on web3.js. Now I'm not a lawyer, but I believe that a node.js dependency meets the permissible requirements for being a combined work: >1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. In particular an interface-compatible web3.js replacement could replace the web3 dependency. an using npm is the appropriate analogue of a dynamically linked shared library (even if you are vendoring it - I think). If I'm right about this then we should probably put our money where our mouth us and relicense the JS libs. Let me get back to you on that.

silasdavis (Sat, 17 Feb 2018 14:25:30 GMT):
regarding licensing - as far as any code we have written goes I'm fairly sure we would be happy to relicense it (we'd choose Apache 2.0 to be consistent with our Hyperledger license I think). I believe the reason the JS libs are LGPL is sort of precautionary since the depend on web3.js. Now I'm not a lawyer, but I believe that a node.js dependency meets the permissible requirements for being a combined work: >1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. In particular an interface-compatible web3.js replacement could replace the web3 dependency. an using npm is the appropriate analogue of a dynamically linked shared library (even if you are vendoring it - I think) in an interpreted language like Javascript. If I'm right about this then we should probably put our money where our mouth us and relicense the JS libs. Let me get back to you on that.

silasdavis (Sat, 17 Feb 2018 14:36:58 GMT):
@smblucker I think you're slightly missing the point here. `string` and `[]byte` are different types, which effects how the are printed by default. `[]byte` is the appropriate type to use for the vm output because it can be arbitrary bytes (including possibly text). The VM does not know (or care) when it is text. The reason the output is printed like that is just because the test use the fmt package to print the default byte slice representation: ``` // original fmt.Printf("Output: %v Error: %v\n", output, err) // If you happen to know output contains text and you _want_ to print it fmt.Printf("Output: %v Error: %v\n", string(output), err) ``` Regarding the return value, it does look like this might be needed so that EVM calling code can make use of the message. So seem like execution might be able to continue (for example to add to the error message) even though all state changes will be reverted. The confusing thing about this is that 'all remaining gas is refunded', but the previous remark would suggest more gas could be consumed (even though we don't need to worry about that. I need to have a look at go-ethereum to convince myself of the right way to handle this.

pouladzade (Sat, 17 Feb 2018 15:48:46 GMT):
@silasdavis Thank you so much for your reply and your useful information about the license

pouladzade (Sat, 17 Feb 2018 15:50:05 GMT):
@silasdavis I would be more than happy if I contribute on the project and work with you guys

pouladzade (Sat, 17 Feb 2018 15:50:05 GMT):
@silasdavis I would be more than happy if I can contribute on the project and work with you guys

smblucker (Mon, 19 Feb 2018 18:33:36 GMT):
@silasdavis Okay, I see the issue with the output now (sorry). As for execution halting, have a look at: https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go--particularly, take a look at how the "errExecutionReverted" error is checked in CREATE, CALL, CALLCODE and DELEGATE CALL. I looked for a similar way to do such checks in our VM; however, because CALL, CALLCODE and DELEGATE CALL are all handled in one case definition, where and how to make such a check becomes clouded. I believe this plays a part in reverting state for Ethereum, but it is not the entire picture...

smblucker (Fri, 23 Feb 2018 14:12:28 GMT):
@silasdavis Have you had a chance to look at go-ethereum's implementation of revert?

silasdavis (Fri, 23 Feb 2018 14:13:00 GMT):
Sorry I've been a bit buried trying to get Bosmarmot into shape

smblucker (Fri, 23 Feb 2018 14:13:49 GMT):
No worries. I was just checking in.

silasdavis (Fri, 23 Feb 2018 14:14:14 GMT):
I have had a reasonable look - and it led to considering how the EVM handles nested call errors vs how Solidity handles throws

silasdavis (Fri, 23 Feb 2018 14:14:37 GMT):
You are welcome to put a WIP pull request up of what you have

silasdavis (Fri, 23 Feb 2018 14:15:10 GMT):
I just need to take an hour or so to convince myself of what the geth code is doing

smblucker (Fri, 23 Feb 2018 14:18:17 GMT):
If you can have a look at that file I linked above, I would appreciate it. I do not want do PR until it is correctly implemented, and there is some checking of the revert error by CREATE, DELEGATECALL, CALL and CALLCODE along with actions if it occurs that I think are relevant...

smblucker (Fri, 23 Feb 2018 14:19:42 GMT):
As I stated above, this becomes confused in our VM since 3 of the for operations are covered in one case definition...

smblucker (Fri, 23 Feb 2018 14:20:57 GMT):
Also, I believe the associated actions, if the revert error is thrown, are memory writes...

smblucker (Fri, 23 Feb 2018 14:22:19 GMT):
Take your time, but let me know when you have finished reviewing it...

pouladzade (Mon, 26 Feb 2018 03:34:12 GMT):
hi guys

pouladzade (Mon, 26 Feb 2018 03:36:36 GMT):
I just add a new feature to the snak, the calling functions of contract, and during my test I realized that the Burrow's EVM has many problems and some results are very different from ethereum EVM especially the assembly codes

pouladzade (Mon, 26 Feb 2018 03:39:21 GMT):
I have a question, Since Burrow aims to be very modular, as I understand, why not to use the external evm module or just provide an interface to use the external standalone EVM like https://github.com/ethereumproject/sputnikvm

silasdavis (Mon, 26 Feb 2018 09:57:53 GMT):
@pouladzade can you share the tests you were running - that would be really useful

silasdavis (Mon, 26 Feb 2018 10:00:53 GMT):
If you have a test harness you can share I'll also take a look

silasdavis (Mon, 26 Feb 2018 10:03:50 GMT):
regarding Sputnik - this is the first time I have seen this codebase - it seems like it appeared around June 2017. I haven't had a proper chance to look at it but at a cursory glance: it looks like a really interesting project, and the bits of code I have looked at look really nice!

silasdavis (Mon, 26 Feb 2018 10:03:50 GMT):
regarding Sputnik - this is the first time I have seen this codebase - it seems like came into existence March 2017. I haven't had a proper chance to look at it but at a cursory glance: it looks like a really interesting project, and the bits of code I have looked at look really nice!

silasdavis (Mon, 26 Feb 2018 10:17:16 GMT):
To give some preliminary thoughts on your question 'why not use it': - I was not aware of another Apache 2.0 EVM like this at all before - Actually the most recent raison d'etre for Burrow is not really to be modular in itself (we leave that to Sawtooth and Fabric) , but to be a decent library and extensible (not pluggable in execution engine or consensus). So there is something to be said for our niche as being a single process, single language (Go) codebase with a concrete (not generic) feature-set: our own permission layer, snatives, EVM, and Tendermint consensus. Having said that, this just reflects my most recent thinking and is not in itself a good enough reason not to change. - Our permissions layer is quite tightly/deeply integrated into the EVM - we probably can't easily just use something like SputnikVM unless their API boundaries provide the appropriate hooks to build them in. - Although Burrow has some issues it has had many non-trivial things built on it over years. Sometimes better the devil you know... But really this is the first time I have seen this project, so thanks for bringing it to my attention. I think Rust is a great choice for something like this, and the project looks really on point in terms of their aims and the velocity they seem to have. I would need more time to study the code quality and maturity of the project.

silasdavis (Mon, 26 Feb 2018 10:19:22 GMT):
In the meantime, I would be very motivated to take a look at the issues you are seeing with the Burrow VM.

pouladzade (Mon, 26 Feb 2018 10:48:30 GMT):
@silasdavis Thank you so much for your comprehensive answer

silasdavis (Mon, 26 Feb 2018 10:48:59 GMT):
We have a tracker of possible EVM issues here: https://github.com/hyperledger/burrow/issues/674 I am now at a place to work through a lot of these issues at some pace. And we have a new full-time team member with a decade of low-level DB experience who can be working on such issues.

pouladzade (Mon, 26 Feb 2018 10:49:02 GMT):
I am gonna provide the results with the all detailes to you

silasdavis (Mon, 26 Feb 2018 10:49:15 GMT):
great... could you open an issue

pouladzade (Mon, 26 Feb 2018 10:49:32 GMT):
yes sure

gaurav94 (Mon, 26 Feb 2018 11:29:05 GMT):
Is there any way to start the chain from the last block height we stopped the chain?? Coz if we stop the chain and try to start again it reads the chain till the last block stopped and then continue to start the chain after that

silasdavis (Mon, 26 Feb 2018 12:42:50 GMT):
@guarav94 can I ask you to not cross-post the same question to all burrow channels. This room is for development discussion. I can see your question in #burrow - I will reply to questions there when I have time as will others.

pouladzade (Mon, 26 Feb 2018 14:42:42 GMT):
@silasdavis Here is the Issue :

pouladzade (Mon, 26 Feb 2018 14:43:32 GMT):

Burrow-EVM-Issue.txt

pouladzade (Mon, 26 Feb 2018 14:43:47 GMT):
Burrow's EVM issue : I did deployed this smart contract on the Burrow, and called the Test method with this parameters 5,6,7 but the result is very different with Remix Ide (Ethereum JavaScript VM) Here is the issue information : ******************************************************************* Smart Contract : pragma solidity ^0.4.16; contract ByteCasting { function Test(int8 _in1, int256 _in2, int16 _in3) public pure returns(bytes out,int8 _out1, int256 _out2, int16 _out3) { bytes memory _buff = new bytes(128); ////////////// // Serializing uint128 _offst = 128; int8ToBytes(_offst,_in1,_buff); _offst -= 1; int256ToBytes(_offst,_in2,_buff); _offst -= 32; int16ToBytes(_offst,_in3,_buff); _offst -= 2; out = _buff; //////////////// // Deserializing _offst = 128; _out1 = bytesToInt8(_offst,_buff); _offst -= 1; _out2 = bytesToInt256(_offst,_buff); _offst -= 32; _out3 = bytesToInt16(_offst,_buff); _offst -= 2; } function int8ToBytes(uint128 _offst, int8 _input, bytes _output) public pure { assembly { mstore(add(_output, _offst), _input) } } function int16ToBytes(uint128 _offst, int16 _input, bytes _output) public pure { assembly { mstore(add(_output, _offst), _input) } } function int256ToBytes(uint128 _offst, int256 _input, bytes _output) public pure { assembly { mstore(add(_output, _offst), _input) } } function bytesToInt8(uint128 _offst, bytes _input) public pure returns (int8 _output) { assembly { _output := mload(add(_input, _offst)) } } function bytesToInt16(uint128 _offst, bytes _input) public pure returns (int16 _output) { assembly { _output := mload(add(_input, _offst)) } } function bytesToInt256(uint128 _offst, bytes _input) public pure returns (int256 _output) { assembly { _output := mload(add(_input, _offst)) } } } ******************************************************************* Function call : Test(5,6,7) ******************************************************************* Burrow's output : "0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000800600 0000000000000000000000000000000000000000000000000000000000000684", "-124", "6", "-32762" ******************************************************************* Remix(Ethereum) output : 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000700 0000000000000000000000000000000000000000000000000000000000000605", "1": "int8: _out1 5", "2": "int256: _out2 6", "3": "int16: _out3 7"

pouladzade (Mon, 26 Feb 2018 14:51:32 GMT):
I just inserted the issue as : Burrow's EVM returns results different from Remix(Javascript VM) #696

pouladzade (Mon, 26 Feb 2018 14:53:22 GMT):
@silasdavis and I face another bug which totally corrupted the blockchain data and I needed to uninstall and install burrow again :

pouladzade (Mon, 26 Feb 2018 14:54:43 GMT):

burrow-log.txt

pouladzade (Mon, 26 Feb 2018 15:01:18 GMT):
panic: runtime error: slice bounds out of range #697

silasdavis (Mon, 26 Feb 2018 15:03:34 GMT):
The contract you deployed, was this through js libs I assume?

silasdavis (Mon, 26 Feb 2018 15:03:48 GMT):
Haven't looked at ticket because on the move

silasdavis (Mon, 26 Feb 2018 15:04:13 GMT):
But will do.

silasdavis (Mon, 26 Feb 2018 15:04:48 GMT):
We should try deploying bytecode with matching solc compiler

silasdavis (Mon, 26 Feb 2018 15:05:05 GMT):
Also we should get you on develop branch ASAP

silasdavis (Mon, 26 Feb 2018 15:06:47 GMT):
Not surprised to see different results if we have deployed different bytecode. Can check this by querying deployed contract address via getaccount

pouladzade (Mon, 26 Feb 2018 15:28:26 GMT):
@silasdavis I deployed through js lib (Legacy-contracts)

pouladzade (Mon, 26 Feb 2018 15:29:35 GMT):
If you need bytecode or any other results please let me know

smblucker (Mon, 26 Feb 2018 16:41:44 GMT):
@silasdavis I submitted a WIP PR for the REVERT opcode implementation; There are additional checks that I wrote in the CREATE, CALL, CALLCODE, and DELEGATECALL case definitions. The former were largely based on Ethereum's EIP spec and their subsequent implementation. When you get a chance, let me know what you think....

silasdavis (Mon, 26 Feb 2018 17:41:37 GMT):
Poulazade can you replicate the slice out of bounds? I believe it is when a negative number ends up being used for a code copy. I've stopped it from panicking on develop but I'd be very interested in the solidity that causes that panic

silasdavis (Mon, 26 Feb 2018 22:21:02 GMT):
@smblucker thanks - I am still not quite ready to pull myself away from JS land, but what you've done looks to me to be likely correct. Before I get round to that I have another task that I think you could tackle. It is based on this PR: https://github.com/hyperledger/burrow/pull/624

silasdavis (Mon, 26 Feb 2018 22:22:59 GMT):
I have left that open as a placeholder for too long - it could be captured as an issue - but I believe the way to solve it is to introduce a new event `AccPreCall` and change `AccCall` to `AccPostCall` (or whatever naming we prefer)

silasdavis (Mon, 26 Feb 2018 22:22:59 GMT):
I have left that open as a placeholder for too long - it could be captured as an issue - but I believe the way to solve it is to introduce a new event `AccountPreCall` and change `AccountCall` to `AccountPostCall` (or whatever naming we prefer)

silasdavis (Mon, 26 Feb 2018 22:24:25 GMT):
Then in `TransactAndHold` and `SendAndHold`: https://github.com/hyperledger/burrow/blob/develop/execution/transactor.go#L248 we will subscribe to `AccountPreCall`

silasdavis (Mon, 26 Feb 2018 22:26:13 GMT):
and correlate the first call there with a height parameter

silasdavis (Mon, 26 Feb 2018 22:26:30 GMT):
actually it might be sufficient to add a height parameter and just check it is 0

silasdavis (Mon, 26 Feb 2018 22:34:06 GMT):
the first step though is to try and replicate the issue which arises from a recursive call

silasdavis (Mon, 26 Feb 2018 22:34:51 GMT):
we don't need to replicate at RPC level - we can do it in execution_test.go

silasdavis (Mon, 26 Feb 2018 22:59:28 GMT):
let me give you a more coherent view of this my AM, but I think we just need to add the height to the call event on reflection since we already have the tx hash

smblucker (Tue, 27 Feb 2018 19:05:37 GMT):
@silasdavis Okay, I will wait for your explanation (your am). I looked at execution/transactor.go, and I can see a call to SubscribeAccountCall (from execution/evm/events/events.go) in TransactAndHold; I can also see a call to SubscribeAccountOutputSendTx (from execution/events/events.go) in SendAndHold--there is no subscription to AccountCall here. When you say 'change AccountCall to AccountPostCall', do you mean change SubscribeAccountCall to SubscribeAccountPostCall (while adding a SubscribeAccountPreCall)? Also what other files are involved here--i.e. Am I looking at all the relevant files?

swetha (Wed, 28 Feb 2018 00:08:26 GMT):
@silasdavis, Wanted to give you an update on Web3 RPC server work. Currently what we have a local http server that translates the calls from web3 to something Fabric can use. Upon further research about how ethereum users are expected to use web3, we are going to continue with the approach of having users run something locally which would be configured with their certificates, and will not add the API to our actual Peer nodes. Looking at the web3 documentation it seems though that http providers are being deprecated in favor of ipc providers. So we will looking into that.

pouladzade (Wed, 28 Feb 2018 10:39:15 GMT):
@silasdavis Hi, I provide the solidity code to generate this bug : slice bounds out of range #697

pouladzade (Wed, 28 Feb 2018 10:39:46 GMT):
@silasdavis I've already updated the bug

pouladzade (Wed, 28 Feb 2018 10:50:49 GMT):
@silasdavis Actually this bug is very dangerous vulnerability, if someone deploys this contract over the Burrow's network and calls the method , all the nodes will be stuck.

silasdavis (Wed, 28 Feb 2018 11:53:46 GMT):
thanks @pouladzade, I'll be taking a look this morning. This is certainly a liveness vulnerability - though there are ways to recover from this panicking on a transaction is bad. Both Burrow and Tendermint are pre-1.0 though, and I know we have issues like this, though this is the first time I've seen this one in particular. There are three levels on which to address: 1. We need to wrap `Execute(tx) error` with panic/recover so that any downstream panic in the execution engine is handled as an error. This addresses not only this issue but all issues with panicking on a Tx - rather than crashing the chain we will just reject the transaction. I've been intending to do this for a while - but needed to fix our internal API a bit. Now is a good time to do it! 2. We need to (this is the royal we - I mean I need to) change our memory implementation so that it does not accept negative offsets: https://github.com/hyperledger/burrow/blob/develop/execution/execution.go#L153 - it probably makes sense to use `uint64` here, though they are not so good for arithmetic/have their own issues. In any case there will be some negative number checks. 3. This was going to be: we need to find out why your code fails on Burrow but not remix, having looked at your issues it looks like it is when gas goes negative, so this is a legit error - you expect the Tx to fail - can you confirm?

silasdavis (Wed, 28 Feb 2018 11:53:46 GMT):
thanks @pouladzade, I'll be taking a look this morning. This is certainly a liveness vulnerability - though there are ways to recover from this panicking on a transaction is bad. Both Burrow and Tendermint are pre-1.0 though, and I know we have issues like this, though this is the first time I've seen this one in particular. There are three levels on which to address: 1. We need to wrap `Execute(tx) error` with panic/recover so that any downstream panic in the execution engine is handled as an error. This addresses not only this issue but the entire class of 'panic on tx' issues - rather than crashing the chain we will just reject the transaction. I've been intending to do this for a while - but needed to fix our internal API a bit. Now is a good time to do it! 2. We need to (this is the royal we - I mean I need to) change our memory implementation so that it does not accept negative offsets: https://github.com/hyperledger/burrow/blob/develop/execution/execution.go#L153 - it probably makes sense to use `uint64` here, though they are not so good for arithmetic/have their own issues. In any case there will be some negative number checks. 3. This was going to be: we need to find out why your code fails on Burrow but not remix, having looked at your issues it looks like it is when gas goes negative, so this is a legit error - you expect the Tx to fail - can you confirm?

silasdavis (Wed, 28 Feb 2018 11:54:47 GMT):
I think I can turn around 1 and 2 pretty quickly. I'm also going to take a closer look at your other issue which I have replicated with our tooling and need to isolate whether there is disagreement at the EVM level or somewhere further out.

silasdavis (Wed, 28 Feb 2018 11:54:52 GMT):
thanks for the great issues!

silasdavis (Wed, 28 Feb 2018 12:05:53 GMT):
@swetha can you link docs that talk about deprecating HTTP providers? Looking at geth they all use the same ServerCodec at least

silasdavis (Wed, 28 Feb 2018 12:18:48 GMT):
@pouladzade out of interest what are you working/what is motivating your use of burrow, and also your use of inline assembly - if this for testing or motivated by some real world use?

pouladzade (Wed, 28 Feb 2018 13:14:33 GMT):
@silasdavis Actually we are interested to use burrow, but we haven't made our decision yet, Burrow is very good option for us but it's not the only option. I am also working on the serializing and deserializing library for all solidity types in a very efficient way (it's why I am using solidity-assembly), I almost compeleted it. if you are interested I can give you more information in private chat.

silasdavis (Wed, 28 Feb 2018 18:27:27 GMT):
@pouladzade I'm trying to simplify your test case, and I have: ``` pragma solidity ^0.4.4; contract ByteCasting { function Test(int8 input) public returns (int8 output) { bytes memory buffer = new bytes(128); // Serializing uint128 offset = 128; assembly { mstore(add(buffer, offset), input) } // Deserializing offset = 128; assembly { output := mload(add(buffer, offset)) } } } ```

silasdavis (Wed, 28 Feb 2018 18:28:05 GMT):
this compiles okay and runs with the same result as in the larger context in Burrow but I find in remix it remains pending and static analysis complains of infinite gas cost

swetha (Wed, 28 Feb 2018 18:54:38 GMT):
@silasdavis : I found it in the documentation for web3 1.0

swetha (Wed, 28 Feb 2018 18:54:38 GMT):
@silasdavis : I found it in the documentation for web3 1.0: https://web3js.readthedocs.io/en/1.0/web3-eth.html#providers

silasdavis (Wed, 28 Feb 2018 19:05:16 GMT):
@swetha thanks

silasdavis (Wed, 28 Feb 2018 19:06:12 GMT):
@pouladzade also another thing when we are adding the `bytes` buffer to the offset... what is that meant to be doing treating the bytes as a value and adding it or is it implicitly taking length or something?

dplumb (Wed, 28 Feb 2018 22:26:27 GMT):
Has joined the channel.

pouladzade (Thu, 01 Mar 2018 00:11:28 GMT):
@silasdavis Thank you, but I have already completed it, I would be glad if you guys take a look at it on github https://github.com/pouladzade/Seriality

silasdavis (Thu, 01 Mar 2018 00:12:54 GMT):
not simplify the code per se, but make the test case that breaks burrow shorter while still demonstrating the issue

pouladzade (Thu, 01 Mar 2018 00:13:40 GMT):
@silasdavis and about your code, actually I need to support 32 int + 32 uint + string + bool + address, and since we need very easy to use and clear code I implemented the casting function for all types

silasdavis (Thu, 01 Mar 2018 01:39:37 GMT):
@pouladzade I've discovered after some detective work that this is a bug in our SIGNEXTEND opcode, specifically in how we calculate the mask: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/vm.go#L362

silasdavis (Thu, 01 Mar 2018 01:45:01 GMT):
should be `mask := backb.Lsh(big.NewInt(1), bit)` not `mask := new(big.Int).Lsh(big.NewInt(1), bit)`!

pouladzade (Thu, 01 Mar 2018 12:26:03 GMT):
@silasdavis I can only say it could be, because I don't have enough knowledge about the EVM specification and your implementation of it.

silasdavis (Thu, 01 Mar 2018 12:26:44 GMT):
It is... I will post a patch today

silasdavis (Thu, 01 Mar 2018 12:27:29 GMT):
this line: https://github.com/hyperledger/burrow/blob/master/manager/burrow-mint/evm/vm.go#L367

pouladzade (Thu, 01 Mar 2018 12:27:40 GMT):
very good news

silasdavis (Thu, 01 Mar 2018 12:27:41 GMT):
Should be `.And` not `.Add`

pouladzade (Thu, 01 Mar 2018 12:30:01 GMT):
It pretty makes sense, because we never add a number to a mask.

silasdavis (Thu, 01 Mar 2018 12:30:14 GMT):
I'm going to try and set up a test harness with all of these VM tests: I'm going to try and set up a test harness

silasdavis (Thu, 01 Mar 2018 12:30:14 GMT):
I'm going to try and set up a test harness with all of these VM tests:

silasdavis (Thu, 01 Mar 2018 12:30:27 GMT):
https://github.com/ethereum/tests/tree/develop/VMTests

pouladzade (Thu, 01 Mar 2018 12:32:04 GMT):
I think you have your own tools for deploying and testing the Burrow

pouladzade (Thu, 01 Mar 2018 12:32:21 GMT):
is it?

silasdavis (Thu, 01 Mar 2018 12:33:29 GMT):
yes we have various of our own integration level tests, but we should be running those table-based tests against EVM too

silasdavis (Thu, 01 Mar 2018 12:34:04 GMT):
@smblucker I think this would be a good thing for you to work on/with

silasdavis (Thu, 01 Mar 2018 12:34:29 GMT):
Take a look at: http://ethereum-tests.readthedocs.io/en/latest/test_types/vm_tests.html

silasdavis (Thu, 01 Mar 2018 12:36:52 GMT):
integration should not be too hard - I will try and provide some build script automation to get hold of the JSON tables to start with though

silasdavis (Thu, 01 Mar 2018 12:37:13 GMT):
the state tests (which they have for `REVERT`) do not look like they will generalise so well though/

pouladzade (Thu, 01 Mar 2018 12:38:23 GMT):
Greate1

pouladzade (Thu, 01 Mar 2018 12:39:11 GMT):
how you apply those tests on the EVM?

pouladzade (Thu, 01 Mar 2018 12:39:45 GMT):
which tools do you use for?

pouladzade (Thu, 01 Mar 2018 12:39:54 GMT):
or recommend?

silasdavis (Thu, 01 Mar 2018 12:40:38 GMT):
we would need to build a little harness around `Call` in `execution/evm/vm.go`

silasdavis (Thu, 01 Mar 2018 12:41:19 GMT):
I would not expect everything to translate - things around gas consumption certiainly won't for example

silasdavis (Thu, 01 Mar 2018 12:41:54 GMT):
also logs done differently

silasdavis (Thu, 01 Mar 2018 12:42:21 GMT):
but I think we could get something going to iterate on without too much trouble

silasdavis (Thu, 01 Mar 2018 12:42:26 GMT):
it's definitely needed

pouladzade (Thu, 01 Mar 2018 12:43:22 GMT):
maybe I can provide a nodejs tools or bash script to do that automatically

pouladzade (Thu, 01 Mar 2018 12:46:18 GMT):
I will work on that

pouladzade (Thu, 01 Mar 2018 12:52:20 GMT):
@silasdavis there is another thing I wanted to ask, When I try to send a bulk of transactions for example(10000), in very high speed rate, but all valid transactions, the Burrow after responding to some of the suddenly gets stop

pouladzade (Thu, 01 Mar 2018 12:52:54 GMT):
is it normal ? I mean my test is somehow stress test

pouladzade (Thu, 01 Mar 2018 12:54:32 GMT):
however, I think it is not a big deal

silasdavis (Thu, 01 Mar 2018 13:00:33 GMT):
It shouldn't stop Burrow, you may get a back log. How does it stop? What do logs say?

pouladzade (Thu, 01 Mar 2018 13:08:03 GMT):

Clipboard - March 1, 2018 9:07 PM

pouladzade (Thu, 01 Mar 2018 13:11:03 GMT):

Clipboard - March 1, 2018 9:10 PM

pouladzade (Thu, 01 Mar 2018 13:12:38 GMT):
I choose random account from an account list and make transaction out of them

silasdavis (Thu, 01 Mar 2018 13:37:43 GMT):
And the Burrow process dies?

pouladzade (Thu, 01 Mar 2018 13:43:24 GMT):
yes

pouladzade (Thu, 01 Mar 2018 13:43:51 GMT):
there was no burrow process in the process list

smblucker (Thu, 01 Mar 2018 15:37:56 GMT):
@silasdavis If I understand you correctly, you want something similar to ethereum/testeth for burrow?

smblucker (Thu, 01 Mar 2018 16:29:32 GMT):
Or, for that matter, something similar to https://github.com/ethereum/go-ethereum/tree/master/tests

SKDHANUKA (Thu, 01 Mar 2018 17:22:31 GMT):
Has joined the channel.

silasdavis (Thu, 01 Mar 2018 19:33:03 GMT):
Similar to that in the sense that that is geth integrating: https://github.com/ethereum/tests

silasdavis (Thu, 01 Mar 2018 19:33:23 GMT):
but we don't recreate that for burrow, we literally use it

smblucker (Thu, 01 Mar 2018 20:10:44 GMT):
@silasdavis ```So, what you want is to "...set up a test harness...[for] running those table-based tests against EVM too..." --i.e. according to the standard defined at http://ethereum-tests.readthedocs.io/en/latest/test_types/vm_tests.html By setting up, I take you to mean integrating ("...integration should not be too hard...") something that already exists (https://github.com/ethereum/tests) outside of burrow ("...we don't recreate that for burrow, we literally use it...") because nothing currently exists like this in burrow that I can see ('make test,' 'make test_integration,' and 'make test_race' only run 'go test'). Is this correct thus far?```

smblucker (Thu, 01 Mar 2018 20:53:51 GMT):
@silasdavis ```I have an unrelated EVM question as well. When comparing go-ethereum's implementation of CREATE, I noticed the following difference: ethereum/go-ethereum/core/vm/evm.go (comments are mine): //The contract address is based off of the caller's address and nonce contractAddr = crypto.CreateAddress(caller.Address(), nonce) //The account for the contract is created from this address evm.StateDB.CreateAccount(contractAddr) hyperledger/burrow/execution/evm/vm.go (comments are mine): //We are deriving an account (and address) from the callee newAccount := DeriveNewAccount(callee, permission.GlobalAccountPermissions(vm.state)) //The account for the contract is created from this account vm.state.UpdateAccount(newAccount) Question: Why is CREATE using callee instead of caller?```

silasdavis (Fri, 02 Mar 2018 17:29:54 GMT):
On the first message, that all sounds correct. Would it help for me to draft the framework for what I am thinking of which would include: makefile target to fetch the test json, test runner to set up a test that has access to the JSON values. Then you can iterate on that and try and get the tests to actually run?

silasdavis (Fri, 02 Mar 2018 17:30:09 GMT):
On the second, well spotted! That is a typo from the refactor!

silasdavis (Fri, 02 Mar 2018 17:30:21 GMT):
It should be caller as it is elsewhere

silasdavis (Fri, 02 Mar 2018 17:41:03 GMT):
On second point, you are pasting code from the `evm.Create` function where the argument is called `caller`, if you look at the corresponding place in geth where they are executing the `CREATE` instruction: https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go#L644 is `contract`, now in the body of Burrow's `call` `callee` is the contract being called. So `callee` is the contract whose code is being executed and contains the `CREATE` opcode, so callee is the creator. I don't find their choice of argument name particularly helpful in this case - but they mean the 'caller' of the `Create` function.

silasdavis (Fri, 02 Mar 2018 17:41:03 GMT):
On second point, you are pasting code from the `evm.Create` function where the argument is called `caller`, if you look at the corresponding place in geth where they are executing the `CREATE` instruction: https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go#L644 the argument being passed as `caller` is called `contract` - the contract being executed. Now in the body of Burrow's `call` `callee` is the contract being called. So `callee` is the contract whose code is being executed and contains the `CREATE` opcode, so callee is the creator. I don't find their choice of argument name particularly helpful in this case - but they mean the 'caller' of the `Create` function.

silasdavis (Fri, 02 Mar 2018 17:41:03 GMT):
On second point, you are pasting code from the `evm.Create()` function where the argument is called `caller`, if you look at the corresponding place in geth where they are executing the `CREATE` instruction: https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go#L644 the argument being passed as `caller` is called `contract` - the contract being executed. Now in the body of Burrow's `call()` function `callee` is the contract being called. So `callee` is the contract whose code is being executed and contains the `CREATE` opcode, so callee is the creator. I don't find their choice of argument name particularly helpful in this case - but they mean the 'caller' of the `Create` function.

smblucker (Fri, 02 Mar 2018 18:27:05 GMT):
@silasdavis If by drafting the framework you mean outlining/defining the individual tasks (writing makefile target, creating test runner, etc) involved in integrating these tests, then yes this would help (greater specificity is never a bad thing). As for the second point, thank you for clearing that up. I was reading a series of articles on how the EVM functions and happened to notice this, and due to my inexperience, did not understand the difference...

silasdavis (Fri, 02 Mar 2018 18:27:55 GMT):
I will write some of the code is what I mean

silasdavis (Fri, 02 Mar 2018 18:27:55 GMT):
I will write some of the code is what I mean and put it in a PR

silasdavis (Fri, 02 Mar 2018 18:28:15 GMT):
It was a good spot actually, I had to double take

smblucker (Fri, 02 Mar 2018 18:30:42 GMT):
Can I help with writing some of the code or could you perhaps walk me through some of it (I do not have experience fetching json or setting up a test runner)?

silasdavis (Fri, 02 Mar 2018 18:37:26 GMT):
I thought that it might make sense for me to do that boring/plumbing stuff since I've added some scripts recently to fetch external repos for testing - then you can get stuck in to the actual Go level coding - unless you are keen to take a broader approach

silasdavis (Fri, 02 Mar 2018 18:37:44 GMT):
I'm just working on some fairly critical fixing brought to our attention by @pouladzade now

smblucker (Fri, 02 Mar 2018 19:35:42 GMT):
I actually want to learn (even the boring/plumbing stuff), so I would not mind taking a broader approach (could still use an outline of tasks). I understand that you have more pressing matters now; I will keep busy in the meantime (Do you still want me to look at PR: https://github.com/hyperledger/burrow/pull/624 ?)...

silasdavis (Fri, 02 Mar 2018 20:27:17 GMT):
Yeah it would be good to have a test that replicates the issue. Not something that depends on the transact method but just shows how a nested/or recursive call can make it ambiguous which even belongs to the root call

silasdavis (Fri, 02 Mar 2018 20:28:29 GMT):
then I am pretty sure the resolution is just to include the stack height (which we follow in the vm struct) in the AccountCallEvent, then a subscriber will look for `eventData.TxHash == txHash && eventData.CallDepth == 0`

silasdavis (Fri, 02 Mar 2018 20:28:37 GMT):
but let's get replication

silasdavis (Fri, 02 Mar 2018 20:28:54 GMT):
I'd also like a review on the PR I'll make ready shortly

silasdavis (Sat, 03 Mar 2018 00:06:13 GMT):
@smblucker @pouladzade would appreciate a review on this if you have time: https://github.com/hyperledger/burrow/pull/704

pouladzade (Sat, 03 Mar 2018 00:13:09 GMT):
@silasdavis Yes sure, but I need also to get the code, compile and test it , I think it takes a little bit time. is it ok if I do it tomorrow?

pouladzade (Sat, 03 Mar 2018 00:15:56 GMT):
I need to get the develop branch

silasdavis (Sat, 03 Mar 2018 09:48:01 GMT):
@pouladzade oh certainly not expecting anything this weekend unless you feel that way inclined!

silasdavis (Sat, 03 Mar 2018 09:49:36 GMT):
you should just be able to checkout develop and run `make test` to get the basics running. You won't so easily be able to run your own test because this version of Burrow needs updated tooling. I do have the updated test ready to go in Bosmarmot, but its passing CI depends on a newer version of burrow... To be fair I can work around that

silasdavis (Sat, 03 Mar 2018 09:49:36 GMT):
you should just be able to checkout develop and run `make test` to get the basics running. You won't so easily be able to run your own test because this version of Burrow needs updated tooling. I do have the updated test ready to go in Bosmarmot, but its passing CI depends on the version of Burrow on the PR being merged to develop. Though I could work around that.

pouladzade (Sat, 03 Mar 2018 10:38:39 GMT):
@silasdavis Ok sure.

silasdavis (Sat, 03 Mar 2018 11:29:16 GMT):
@smblucker I've also updated: https://github.com/hyperledger/burrow/issues/674 removing various fixed or dead issues

silasdavis (Sat, 03 Mar 2018 11:29:27 GMT):
the opcode issues are top priority if you fancy taking a look at any of them

kevinstr (Sat, 03 Mar 2018 17:30:18 GMT):
Has joined the channel.

silasdavis (Sat, 03 Mar 2018 22:16:02 GMT):
@smblucker I've finally dropped you a review on: https://github.com/hyperledger/burrow/pull/698#pullrequestreview-100986925

silasdavis (Sat, 03 Mar 2018 22:16:26 GMT):
it outlines what I think we need to do to add full support

silasdavis (Sat, 03 Mar 2018 22:16:31 GMT):
we should work together on a branch

silasdavis (Sat, 03 Mar 2018 22:17:32 GMT):
I think if we are focussed on the new opcodes issue I have updated here: https://github.com/hyperledger/burrow/issues/674 we can get through them efficiently and quickly

silasdavis (Sat, 03 Mar 2018 22:17:58 GMT):
INVALID, and the bitwise ops are pretty trivial

silasdavis (Mon, 05 Mar 2018 13:52:45 GMT):
A thought about the ethereum tests there is actually a lot of https://github.com/ethereum/go-ethereum/tree/master/tests we could reuse directly

silasdavis (Mon, 05 Mar 2018 13:53:04 GMT):
if we were to make the tests part of bosmarmot

silasdavis (Mon, 05 Mar 2018 13:53:26 GMT):
which would be fine because it's where all the other integration tests are

silasdavis (Mon, 05 Mar 2018 13:54:38 GMT):
we actually already have a dependency on geth there.. though it's an older version

silasdavis (Mon, 05 Mar 2018 13:55:15 GMT):
there is no reason that all the sub-projects of bosmarmot share a vendor directory really - the first task would be to drop vendor down and give each sub-project its own vendor dir and Gopkg.toml

smblucker (Mon, 05 Mar 2018 15:40:29 GMT):
@silasdavis I will get to making the minor changes you mention to my WIP implementation of REVERT, rebasing, and pushing right away. We will have to find some time to coordinate our efforts on the opcode issues. Perhaps maybe a call (Google Hangout session) 15min might be in order here. Let me know your thoughts...

smblucker (Mon, 05 Mar 2018 16:04:01 GMT):
@silasdavis See comment about you renaming to callErr https://github.com/hyperledger/burrow/pull/698#pullrequestreview-100986925 not sure what to do...

smblucker (Mon, 05 Mar 2018 16:04:22 GMT):
Other changes have already been completed

smblucker (Mon, 05 Mar 2018 16:45:08 GMT):
Renamed based on my interpretation of your meaning. I will rebase and push--let me know if I misinterpreted what you meant...

silasdavis (Mon, 05 Mar 2018 17:20:33 GMT):
Call would be good

silasdavis (Mon, 05 Mar 2018 17:20:36 GMT):
free any time

silasdavis (Mon, 05 Mar 2018 17:55:35 GMT):
@smblucker let me know when you are around

pouladzade (Mon, 05 Mar 2018 18:13:38 GMT):
@silasdavis I reviewed the code, but I didn't have anything to mention!

pouladzade (Mon, 05 Mar 2018 18:13:59 GMT):
I got the burrow's develop and run the tests

silasdavis (Mon, 05 Mar 2018 18:14:04 GMT):
great thanks, would you mind adding a LGTM review?

silasdavis (Mon, 05 Mar 2018 18:14:18 GMT):
nice to show our growing community of contributors

pouladzade (Mon, 05 Mar 2018 18:14:35 GMT):
The test That have implemented were ok!

pouladzade (Mon, 05 Mar 2018 18:14:47 GMT):
you r welcome, yeah sure

pouladzade (Mon, 05 Mar 2018 18:15:39 GMT):
how can I run the burrow and use the RPC to work with it?

pouladzade (Mon, 05 Mar 2018 18:15:52 GMT):
I mean the develop branch

pouladzade (Mon, 05 Mar 2018 18:18:38 GMT):
if is it possible for now, of course

silasdavis (Mon, 05 Mar 2018 18:27:29 GMT):
Did you see my remark in #burrow: https://chat.hyperledger.org/channel/burrow?msg=Mrg8wMEdx3QtWDyL3

pouladzade (Mon, 05 Mar 2018 18:29:25 GMT):
Actually I tried that but it gets failed

silasdavis (Mon, 05 Mar 2018 18:29:44 GMT):
the test fails?

silasdavis (Mon, 05 Mar 2018 18:30:17 GMT):
Do you have the burrow version from my PR installed?

pouladzade (Mon, 05 Mar 2018 18:30:26 GMT):
no

pouladzade (Mon, 05 Mar 2018 18:30:47 GMT):

Clipboard - March 6, 2018 2:30 AM

silasdavis (Mon, 05 Mar 2018 18:30:52 GMT):
ah right you will need that

smblucker (Mon, 05 Mar 2018 18:31:23 GMT):
@silasdavis I will make myself available for a call at a time that works best for you; however, if we can try to avoid a 3am call my time, it would be appreciated. Send me a link for a Google Hangout (if necessary) with date and time, or I can post my number to you in private channel...

silasdavis (Mon, 05 Mar 2018 18:31:27 GMT):
and you need my fork of bosmarmot with the chance too sorry

silasdavis (Mon, 05 Mar 2018 18:31:27 GMT):
and you need my fork of bosmarmot with the new test too sorry

pouladzade (Mon, 05 Mar 2018 18:31:31 GMT):
I think I should install some dependencies

silasdavis (Mon, 05 Mar 2018 18:31:41 GMT):
https://github.com/silasdavis/bosmarmot/tree/app39-remix-byte-cast

silasdavis (Mon, 05 Mar 2018 18:31:47 GMT):
dependencies?

silasdavis (Mon, 05 Mar 2018 18:31:58 GMT):
all our go deps are vendored so should not need to install any deps

silasdavis (Mon, 05 Mar 2018 18:32:01 GMT):
if you do, something is broken

pouladzade (Mon, 05 Mar 2018 18:32:42 GMT):
I can build and run the burrow's test

pouladzade (Mon, 05 Mar 2018 18:34:24 GMT):
I mean dependencies like burrows files, keys, .. or

pouladzade (Mon, 05 Mar 2018 18:34:31 GMT):

Clipboard - March 6, 2018 2:34 AM

silasdavis (Mon, 05 Mar 2018 18:34:48 GMT):
take a look at instructions above

pouladzade (Mon, 05 Mar 2018 18:34:53 GMT):
is it .burrow

silasdavis (Mon, 05 Mar 2018 18:34:55 GMT):
you have to launch it in the appropriate bosmarmot directory

silasdavis (Mon, 05 Mar 2018 18:35:31 GMT):
monax/tests is where the test chain assets are

pouladzade (Mon, 05 Mar 2018 18:35:47 GMT):
I see

pouladzade (Mon, 05 Mar 2018 19:26:02 GMT):

Clipboard - March 6, 2018 3:25 AM

pouladzade (Mon, 05 Mar 2018 19:27:11 GMT):
anyway, I try to figure it out, thanks for your useful advices

silasdavis (Mon, 05 Mar 2018 19:59:17 GMT):
you need to run keys too, do check the comment I reposted above I mention it all there

silasdavis (Mon, 05 Mar 2018 20:13:17 GMT):
@smblucker that PR Is merged... happy rebasing

smblucker (Mon, 05 Mar 2018 21:57:19 GMT):
@silasdavis Rebase is done (?)...I think and was, for the most part, not happy...

minfun (Tue, 06 Mar 2018 13:40:31 GMT):
Has joined the channel.

aj07 (Fri, 09 Mar 2018 18:26:12 GMT):
Has joined the channel.

jjjjpppp (Thu, 15 Mar 2018 00:59:20 GMT):
Has joined the channel.

ShikarSharma (Tue, 20 Mar 2018 22:31:36 GMT):
Has joined the channel.

KOttoni (Wed, 28 Mar 2018 16:51:22 GMT):
Has joined the channel.

tkuhrt (Thu, 29 Mar 2018 14:43:03 GMT):
compleatang

Pan0ptic (Fri, 30 Mar 2018 16:27:59 GMT):
Has joined the channel.

tkuhrt (Fri, 30 Mar 2018 18:49:56 GMT):
I was looking for "good first bugs" or "help wanted" issues in Hyperledger Burrow. I did not see a label for these types of issues. Does something exist that I may have missed? If not, this might be a good way to get more contributors into the project.

thalisson (Sun, 01 Apr 2018 02:38:36 GMT):
Has joined the channel.

compleatang (Mon, 02 Apr 2018 19:27:20 GMT):
Thanks Tracey, we've been finishing up this massive refactor and stabilizing it. Once we're thru that then we'll start to mark issues as such.

toniyasundaram (Tue, 03 Apr 2018 07:11:51 GMT):
Has joined the channel.

tkuhrt (Tue, 03 Apr 2018 20:08:42 GMT):
Great...thanks @compleatang. I will be looking forward to the label.

snowy13 (Wed, 04 Apr 2018 22:08:59 GMT):
Has joined the channel.

ningyan325 (Mon, 09 Apr 2018 15:53:28 GMT):
Has joined the channel.

ThangDC (Tue, 10 Apr 2018 08:46:52 GMT):
Has joined the channel.

ThangDC (Tue, 10 Apr 2018 10:28:21 GMT):
Hi all,

ThangDC (Tue, 10 Apr 2018 10:29:53 GMT):
I've got the certificate from hyperledger IBM course, now I would like to contribute to the project

compleatang (Tue, 10 Apr 2018 17:38:42 GMT):
Welcome! Where are you interested in helping?

ThangDC (Wed, 11 Apr 2018 01:35:24 GMT):
@compleatang I think anything architecture, coding, review code, testing ...

ThangDC (Wed, 11 Apr 2018 02:01:57 GMT):
Could u pls consult me on this one? What you mostly need right now for this project

bird_alone (Wed, 11 Apr 2018 08:21:39 GMT):
Has joined the channel.

zigen 1 (Fri, 13 Apr 2018 02:52:33 GMT):
Has joined the channel.

Rekha (Tue, 17 Apr 2018 05:16:45 GMT):
Has joined the channel.

bird_alone (Tue, 17 Apr 2018 09:37:41 GMT):
Hello everyoe. I have pushed a PR. It's simple renaming function name. Please check it here: https://github.com/hyperledger/burrow/pull/742

silasdavis (Tue, 17 Apr 2018 12:16:16 GMT):
thanks @bird_alone made some comments and responses

silasdavis (Tue, 17 Apr 2018 12:16:22 GMT):
regarding your question about authenc

silasdavis (Tue, 17 Apr 2018 12:18:08 GMT):
Duplicating here to increase visibility hope you don't mind: > However I see this : https://github.com/hyperledger/burrow/commit/82cde171ff14243021927c35d1fc0cdcbbb1fe86 >I think it's better to encrypt the peer authentication for more security. I don't know why you have disabled it.

silasdavis (Tue, 17 Apr 2018 12:20:44 GMT):
This was a bit of a quick fix after upgrading Tendermint. I intend to expose this in config and probably have it enabled by default. This issue with having it on now is that it complicates cloud deployments quite a bit as you either need to pre-generate node keys and share the addresses or have another step that shares them around.

silasdavis (Tue, 17 Apr 2018 12:22:02 GMT):
it's important to note this does not disable any encryption, but it does disable authenticated connections, which is to say it provides protection against man-in-the-middle attacks (provided you know the peers node key addresses ahead of time (or get them from someone you trust)

silasdavis (Tue, 17 Apr 2018 12:24:59 GMT):
this is important in a public setting, but in our cloud deployment that is currently driving development on the develop branch we don't really worry about MITM because we are operating within a secure cluster with a validator pool under our control. Now ultimately this perimeter based security is not the way to do things but I'd like to provide a better answer for booting/sharing node keys first and I needed Tendermint 0.15.0 behaviour back

silasdavis (Tue, 17 Apr 2018 12:26:03 GMT):
its worth nothing that Tendermint was doing without this altogether before. The security implications here are also not consensus failures in the sense of it making it possible for people who are not validators to sign nefarious blocks/votes - it just means that the network liveness could be compromised

silasdavis (Tue, 17 Apr 2018 12:26:16 GMT):
by someone impersonating a peer and then just not forwarding messages for example

silasdavis (Tue, 17 Apr 2018 12:27:19 GMT):
It's an important piece but its not a first-order security issue - and much less of an issue for private networks where you are likely to have connection authentication by some other means like VPC peering etc

silasdavis (Tue, 17 Apr 2018 12:29:22 GMT):
but like I say - I have no intention of keeping this disabled. I'd probably prefer to: expose in config, enable by default, provide support for it in a 'burrow boot' network formation tool that can help 'do genesis' on a network (chiefly sharing generated public keys for validators, participants, and nodes on boot), which I think can be a powerful tool for launching pools of validators

silasdavis (Tue, 17 Apr 2018 13:39:24 GMT):
BTW if something you want now will accept PR adding it to `TendermintConfig`

compleatang (Tue, 17 Apr 2018 20:14:58 GMT):
@ThangDC that's great to hear, we could always use more help building testing... particularly with respect to setting up multi-node smoke tests and/or performance benchmarking within Circle. or just writing tests where they do not exist. We will be trying to mark a few issues as beginner issues to get folks used to the code base, but helping with some CI tests would also give you a tour of the user interfaces of burrow as well.

ThangDC (Wed, 18 Apr 2018 06:14:17 GMT):
@compleatang Thanks. That's fine for me. Pls guide me where I can have starting with

bird_alone (Wed, 18 Apr 2018 06:50:22 GMT):
Thanks @silasdavis for sharing my comment and you answer. My concern was more about light client security. In the real world light clients can securely connect with known ```peerId```. However for testnet we can ignore it. Although I believe in the real world majority of the nodes of honest, but security comes first in term of being consistence and reliable.

bird_alone (Wed, 18 Apr 2018 06:50:22 GMT):
Thanks @silasdavis for sharing my comment and you answer. My concern was more about light client security. In the real world light clients can securely connect with known `peerId`. However for testnet we can ignore it. Although I believe in the real world majority of the nodes of honest, but security comes first in term of being consistence and reliable.

bird_alone (Wed, 18 Apr 2018 06:50:22 GMT):
Thanks @silasdavis for sharing my comment and you answer. My concern was more about light client's security. In the real world light clients can securely connect with known `peerId`. However for testnet we can ignore it. Although I believe in the real world majority of the nodes are honest, but security comes first in term of being consistence and reliable.

bird_alone (Wed, 18 Apr 2018 06:55:52 GMT):
Today I shared my Burrow TestNet project on github. Because I don't have any clouding system for developing purpose. Also using kubernetes or dockers is little bit cumbersome. So I decided to write more simple test net for running the burrow. I does't use gossiping for finding peers, In my implementation peers are deterministic and known. Maybe it is useful for you if you want to have a very simple test net. Find it here:

bird_alone (Wed, 18 Apr 2018 06:55:52 GMT):
Today I shared my Burrow TestNet project on github. Because I don't have any clouding system for developing purpose. Also using kubernetes or dockers is little bit cumbersome. So I decided to write more simple test net for running the burrow. It does't use gossiping for finding peers, In my implementation peers are deterministic and known. Maybe it is useful for you if you want to have a very simple test net. Find it here:

bird_alone (Wed, 18 Apr 2018 06:55:52 GMT):
Today I shared my TestNet project on github. Find it here:

bird_alone (Wed, 18 Apr 2018 06:55:59 GMT):
https://github.com/b00f/burrow-testnet

guoger (Fri, 20 Apr 2018 06:26:47 GMT):
do we have the semantic in evm to delete a k/v pair? or we could only set a key to nil. thx

guoger (Fri, 20 Apr 2018 06:26:47 GMT):
do we have the semantic in evm to delete a k/v pair? or we could only set a key to nil. thx /cc @silasdavis

silasdavis (Fri, 20 Apr 2018 16:46:09 GMT):
@guoger setting the zero value (not nil since it is an `Word256`) is meant to be the semantic for removal (as receiving `Zero256` is the semantic for 'not set') but I notice this would actually cause a panic on develop after IAVL upgrade, review appreciated: https://github.com/hyperledger/burrow/pull/744

YoussefAshraf (Fri, 20 Apr 2018 22:55:17 GMT):
Has joined the channel.

silasdavis (Fri, 20 Apr 2018 23:43:50 GMT):
@bird_alone this is great I've been having a play with it. I think your test net scripts can be used to prototype some native functionality in burrow for starting bare metal testnets, when I'm back from holiday I'm looking forward to us all (burrow contributors and you and @pouladzade in particular) getting on a call. I'll post details here

silasdavis (Fri, 20 Apr 2018 23:44:18 GMT):
Also got a pr to use template strings and enable logging

silasdavis (Mon, 23 Apr 2018 01:12:17 GMT):
Just understood your point on light client security. Guess we need it for that

seanyoung (Mon, 23 Apr 2018 08:25:41 GMT):
Has joined the channel.

seanyoung (Mon, 23 Apr 2018 11:15:43 GMT):
@smblucker Please ping when you're online, so we can have a chat

smblucker (Mon, 23 Apr 2018 15:14:38 GMT):
@seanyoung I am online.

seanyoung (Mon, 23 Apr 2018 15:16:33 GMT):
Hello, how are you? Sorry for not getting in touch earlier. I've recently started at monax, so still learning a lot.

smblucker (Mon, 23 Apr 2018 15:19:25 GMT):
I am well. Thank you for asking. No worries about the communication; I have been learning as well. Apparently, you must be further along than me--i.e. I have seen you merging changes into develop already.

smblucker (Mon, 23 Apr 2018 15:19:31 GMT):
How are you?

seanyoung (Mon, 23 Apr 2018 15:20:22 GMT):
I'm good, thanks. I'm enjoying learning various bits of burrow :)

seanyoung (Mon, 23 Apr 2018 15:21:18 GMT):
Is there anything you would like to look at? One of the outstanding issues is that burrow connects to a keys server -- unencrypted. I've moved the key server into burrow, now it needs some changes to use it directly, rather than connect to it.

smblucker (Mon, 23 Apr 2018 15:28:27 GMT):
Today I was going to make changes as described here: https://github.com/hyperledger/burrow/issues/745 --these are non-substantive (not related to coding). I have not had any specific direction of concern with the project for quite some time (all issues I have worked on thus far have never been completed--see Casey) other than to become familiar with the code base and how burrow functions. So, is there anything I would like to look at? Yes, I want to look at things I have a reasonable shot at finishing. I want to be able to contribute in some way...

smblucker (Mon, 23 Apr 2018 15:29:57 GMT):
I am not familiar with the issue you mentioned, so would need time to look at it

seanyoung (Mon, 23 Apr 2018 15:39:09 GMT):
In issue #745 you mention LN, what does that mean?

smblucker (Mon, 23 Apr 2018 15:41:36 GMT):
Line numbers

seanyoung (Mon, 23 Apr 2018 15:43:37 GMT):
So currently we have monax-keys server, which listens on port 4746. That can be started with "monax-keys server" and can be used from the command line using "monax-keys name ls" etc. burrow calls the keys server from keys/keys_client.go. I've moved the monax-keys command into burrow, see https://github.com/seanyoung/burrow/tree/monax-keys. The next step would be for keys/keys_client.go to be able to switch to use the keys directly (without going to the server, or use a separate keys server).

seanyoung (Mon, 23 Apr 2018 15:51:46 GMT):
So on this branch you can run "burrow keys name ls" rather than "monax-keys name ls".

smblucker (Mon, 23 Apr 2018 16:05:57 GMT):
So, if you want burrow to use the keys directly--i.e. without have to connect to a server--the client itself should be eliminated as well, right?

seanyoung (Mon, 23 Apr 2018 16:08:46 GMT):
that's the idea, yes. However, it should still be possible to run a separate keys server. So this needs some config options

seanyoung (Mon, 23 Apr 2018 16:12:00 GMT):
that would mean that the key does not get sent over tcp

smblucker (Mon, 23 Apr 2018 16:17:03 GMT):
Since there is a concern with the unencrypted connection to the server, would it be possible to create an encrypted tcp connection to a server? In other words (and this may sound stupid and maybe like I am belaboring the point), if you moved the functionality into burrow and still want the ability to connect to a server of configured, is there not still a problem with an unencrypted connection?

smblucker (Mon, 23 Apr 2018 16:17:53 GMT):
'if configured'

seanyoung (Mon, 23 Apr 2018 16:21:50 GMT):
Having the keys server inside burrow makes it both secure and easier to set up. We should probably also look at the burrow configure command line (and the command line in general).

seanyoung (Mon, 23 Apr 2018 16:23:05 GMT):
The security of a separate keys server, that is also interesting, I would have to talk Silas to see what he thinks

seanyoung (Mon, 23 Apr 2018 16:24:28 GMT):
I'm not sure if we moved the keys api under a general api then it could all be secured in one go (authentication + encryption)

smblucker (Mon, 23 Apr 2018 17:24:04 GMT):
Is there anything you would like me to help with? Also, do you have suggestions for how we might coordinate our activities?

seanyoung (Mon, 23 Apr 2018 17:43:08 GMT):
That depends on what you would like to work on really. How would you feel about wiring up burrow so it can use an internal keys server, if so configured?

seanyoung (Mon, 23 Apr 2018 18:38:38 GMT):
There is an evm opcode issue that I could look at, so we don't get in each other's way. Let me know if there is anything I can do to help. I probably won't know the answer but we can try and find out together!

smblucker (Mon, 23 Apr 2018 19:02:19 GMT):
I would first like to finish my work on implementing the REVERT opcode. I was able to complete most of the easier tasks associated with this but was unable to finish for many reasons--i.e. I did not have a very good understanding of how state was managed in burrow and therefore how it could be manipulated to revert state; the former handling was undergoing significant changes (tx_cache-->state_cache); etc. I think a good place to start would be to attempt to write some of the tests in state_cache_test.go as Silas suggested and then move on to tackle the harder issues associated with REVERT.

smblucker (Mon, 23 Apr 2018 19:44:28 GMT):
As for wiring up burrow to use the internal keys server, I noticed that the only thing that you did not bring over from bosmarmot is the app.go. If I am not mistaken, I think that this can be added to the client package to add the necessary functionality?

smblucker (Mon, 23 Apr 2018 19:53:19 GMT):
Actually, the contents of app.go may need to be in the cmd package instead--the primary plumbing provided by github.com/spf13/cobra

seanyoung (Mon, 23 Apr 2018 20:07:57 GMT):
app.go is no longer needed

seanyoung (Mon, 23 Apr 2018 20:08:16 GMT):
it's all in main.go now

seanyoung (Mon, 23 Apr 2018 20:09:06 GMT):
ok

seanyoung (Mon, 23 Apr 2018 20:21:56 GMT):
if you work on that then I can finish this

smblucker (Mon, 23 Apr 2018 20:22:20 GMT):
My supervisor would like to set up a call for this Friday at a time that would convenient for all parties. Can you send me your email, a time, and I will forward you the call details...

seanyoung (Mon, 23 Apr 2018 20:30:08 GMT):
sent via direct message

bird_alone (Tue, 24 Apr 2018 07:19:47 GMT):
bond

seanyoung (Wed, 25 Apr 2018 12:46:40 GMT):
@smblucker how are you getting on? Anything I can help you with?

tkuhrt (Wed, 09 May 2018 00:06:20 GMT):
Hey, all. I am looking for some good tutorials for Hyperledger Burrow that we can add to the website. Appreciate any links you might have.

silasdavis (Wed, 09 May 2018 12:21:02 GMT):
We have an updated single page tutorial that has been sitting here for a while: https://github.com/monax/bosmarmot/pull/10

silasdavis (Wed, 09 May 2018 12:21:27 GMT):
I've just bumped the author who was working on it for us

tkuhrt (Wed, 09 May 2018 17:29:49 GMT):
Thanks, Silas. I have added my desire to see this done soon too.

compleatang (Thu, 10 May 2018 17:40:10 GMT):
#helpwanted :)

PoojaVarshneya (Mon, 14 May 2018 17:25:30 GMT):
Has joined the channel.

robwahl (Sat, 19 May 2018 16:08:17 GMT):
Has joined the channel.

ThangDC (Mon, 21 May 2018 02:48:04 GMT):
@compleatang could u pls show which ones? :)

finterran (Tue, 22 May 2018 00:48:38 GMT):
Has joined the channel.

AnkurDaharwal (Tue, 22 May 2018 06:50:02 GMT):
Has joined the channel.

vlas 6 (Tue, 22 May 2018 06:54:25 GMT):
Has joined the channel.

silasdavis (Tue, 22 May 2018 10:35:03 GMT):
@finterran on permissions, they work in the following way. An account's permissions is a composition of some number of `BasePermissions` objects (currently we have just two - the account level and the global - but we could have more). Each BasePermissions are logically a set of ternary flags, either: true, false, or unset. To compose two `BasePermissions`, for each flag if true or false use that value, if unset take the second permissions value.

silasdavis (Tue, 22 May 2018 10:36:14 GMT):
Concretely, for account permissions we explicitly set _some_ flags, for global permissions we explicitly set all flags (i.e. there are no 'unset' values)

silasdavis (Tue, 22 May 2018 10:36:40 GMT):
So for accounts their explicitly set permissions take precedent over any global permissions, only when are unset do they fall through

silasdavis (Tue, 22 May 2018 10:37:57 GMT):
in terms of what appears in the genesis.json and also is accessible through snatives we allow our particular implementation of this model to leak through into the declaration in genesis

silasdavis (Tue, 22 May 2018 10:38:31 GMT):
in my view this is a little unfortunate (something I have addressed in genesis spec where we have a named list of flags - those omitted are unset)

silasdavis (Tue, 22 May 2018 10:42:35 GMT):
Anyway, our representation uses two bit fields `Perms` and `SetBit`. `Perms` sets the flags according to the bit (1 being true, 0 being false) at the index corresponding to one of our defined permissions. `SetBit` describes whether each bit is 'set', if the ith SetBit is 1 then we use the ith Perms bit as the flag, if the ith SetBit is 0 we ignore the value in Perms

silasdavis (Tue, 22 May 2018 10:44:52 GMT):
because of this there are a class of `BasePermisisons` with different representations with the same semantics. In particular if Perms > SetBit (as an integer) then we could represent the same Perms with a smaller integer

silasdavis (Tue, 22 May 2018 10:45:07 GMT):
anyway this is probably more navel gazing that you required

silasdavis (Tue, 22 May 2018 10:46:24 GMT):
Here's the composition function: https://github.com/hyperledger/burrow/blob/develop/permission/types/base_permissions.go#L84-L90

silasdavis (Tue, 22 May 2018 10:50:21 GMT):
----------------

silasdavis (Tue, 22 May 2018 10:52:04 GMT):
regarding fees - I haven't yet studied finterra-burrow but will do soon (hopefully after we can rebase on a shared history)

silasdavis (Tue, 22 May 2018 10:52:32 GMT):
I plan to introduce a mechanism for fee collection and disbursement very soon, let me outline that shortly

silasdavis (Tue, 22 May 2018 10:57:39 GMT):
regarding gas - it's important to note that we meter gas to bound computation time - but we do not charge for gas, i.e. we do not convert subtract value sent in a CallTx subject to a gasCost conversion rate. This is something that could be added - but since we are interested with Burrow in building incentives around our specific domain model - we tend to think of computation as a commoditised negligible cost what it has be bound so we always terminate. We do need to expose the max gas and also increase our baseop gas cost from 0 to 1 though - I will address that with the fee stuff.

silasdavis (Tue, 22 May 2018 11:04:05 GMT):
Here's how I am thinking about charging and disbursing fees: on account creation (either through and additional field in CallTx or a call to a special SNative in the constructor) each account can be set a network fee that must be provided within the value sent to the contract. It's an open question whether we allow the fee to be mutable, i.e. allow the contract to adjust it's own fee after creation. When a contract is called the executor (a type in Burrow that runs txs) looks up the fee (if any - we will not attach a fee to various utility and administrative contracts in our network - only our domain assets) and subtracts that from the value that the contract itself will be transferred as part of the call.

silasdavis (Tue, 22 May 2018 11:04:52 GMT):
So far this is a straightforward extension to what we have with the `fee` variable

silasdavis (Tue, 22 May 2018 11:20:10 GMT):
... will return to this ...

finterran (Tue, 22 May 2018 11:21:09 GMT):
@silasdavis Thanks for the responses on these questions! Very helpful :slight_smile:

silasdavis (Tue, 22 May 2018 19:03:18 GMT):
@finterran here's a little write up of my current thinking on fees, I think it could be extended to validator pools in a number of ways (possibly doesn't need it at all)

silasdavis (Tue, 22 May 2018 19:03:31 GMT):

Validator_Fee_Disbursement.pdf

silasdavis (Tue, 22 May 2018 19:06:27 GMT):

Validator_Fee_Disbursement.pdf

silasdavis (Tue, 22 May 2018 19:07:33 GMT):

Validator_Fee_Disbursement.pdf

finterran (Wed, 23 May 2018 05:10:10 GMT):
@silasdavis Thanks for this, it is an interesting model. Just some clarifying questions and exploratory push back:  1) Attaching a fee at account creation - Does this mean that the contract creator will set the fee for a deployed contract? I’m thinking in the public chain context where anyone can deploy contracts. If this is the case, then there could be a race to the bottom for fees, at the cost of the validator fees. On the other hand if the protocol sets the contract Fee on what basis will it find a fair price?  2) Will the fee then be aggregated for cross contract calls? (E.g. - A user calls a method on contract A with Fee X, which in turn calls contract B (with Fee Y), is the original call Fee then X+Y or X alone? If not aggregated, then users could wrap an ‘expensive’ contract call in a ‘cheap’ cross contract call.  3) Contracts have different functionalities. A method setting a single storage variable, is much less work than iterating over a large array. Even with a gas limit for termination, I wonder if a single fee is granular enough to accommodate the difference in possible functionality.  4) What do you see as the benefits of abandoning the gas per operation model of fee calculation? If a flat fee model is adopted, how to keep it in line with a sense of “fair” payment for network resource usage? Your proposal seems good from a user standpoint since network resources (computation and storage) could theoretically be used for small flat fees, but will validators want to support the network (again thinking of a public network) if there are little fees to compensate them for their operating costs? My thought is that the best part of the pay per operation model is that the free market dictates how much resources cost on the network and should achieve a ‘fair’ equilibrium. If users pay too little, the miners don’t process their transactions (or do in a slow manner). If the miners charge too much, there are less transactions as users move to other networks or just limit their transaction activity to save costs. 

finterran (Wed, 23 May 2018 05:21:54 GMT):
I think I agree though that computation could be considered negligible (or very low cost) compared to storage which I imagine could be abused and cause chain bloat if not costed properly.

silasdavis (Wed, 23 May 2018 20:30:48 GMT):
I think it needs pushing back on. To clarify where my blinkers are - in our current model the only contracts deployed are the operational contracts ordained at genesis (i.e. eventually no human has CREATE permission). I'm not totally wedded to this for us, and certainly this is a smaller use case than what Burrow is meant to serve, but for the sake of argument. In this scenario these foundation contracts are all factory contracts and responsible for creating the actual business contracts (for us: archetypes (templates of agreements), agreements, processes, etc). So since 'we' as the designers of the networks are controlling the base contracts we can control the fee we charge at the same time as the value contract demands to be transferred. Since archetypes are competing there is a market for their value but there's no market (or incentive) for them to charge a higher fee as you point out. I want a system where validators make a percentage cut of all value changing hands on the network. Here is a better model, I think more in line with what I actually intended: when value is transferred a percentage fee (let's punt on how this is set, whether it is per account) is deducted and taken as the validator fee and then distributed as I described.

silasdavis (Wed, 23 May 2018 20:32:25 GMT):
so on 1) Let's say the fee is set for the network flat - validators have a defined upside that scales with volumes, consumers have to transfer value to pay for things, but other utility level things could be free (in our model this works because all our contracts are 'friendly')

silasdavis (Wed, 23 May 2018 20:33:09 GMT):
2) The cut of the value would be taken on the outermost call and that would account for any subsequent transfers. In my original model I agree this would be a problem

silasdavis (Wed, 23 May 2018 20:41:27 GMT):
3) / 4) So burrow has never implemented paying for gas, I think because it mattered very little for the non-public use cases. It would not be that hard to implement and for our public/semi-public use cases I'm increasingly thinking that maybe we should. I'd also like to have a flexible fee charging structure so perhaps we do need the ability to charge for gas. It seems silly to me that Ethereum once pitched itself as a 'computer for the world' when it is so slow - the value is obviously in reaching consensus on transactions so metering computation seems a bit beside the point. Also there is a lot of room for optimising computation whereas there is less room to optimising the slowness of consensus (at least in PBFT-ish) so I'm inclined towards thinking of computation as commodity - which doesn't mean it's right to do that.

silasdavis (Wed, 23 May 2018 20:42:10 GMT):
Thinking about the idea of a flat percentage fee taken out of value transferred that essentially means validator voting power/token is a license to extract rent from the network

silasdavis (Wed, 23 May 2018 20:42:32 GMT):
It can also be an obligation to operate the network through some use-it-or-lose it model

silasdavis (Wed, 23 May 2018 20:43:25 GMT):
if selling such licenses funds genuine value creation in developing such a network then of course it might not be pure rent, but still I'm not quite sure how I feel about that

silasdavis (Wed, 23 May 2018 20:45:20 GMT):
There is also potential for us to have competition between individual validators if we use a fee attached to the transaction (as it currently is)

silasdavis (Wed, 23 May 2018 20:45:53 GMT):
we might need to more formally model transaction volume quota as a side-effect of power - another way to extract rent

silasdavis (Wed, 23 May 2018 20:50:18 GMT):
So we have a number of dimensions to think about: 1. Where to attach the fee? Tx, Contract, Validator's RPC 2. How to meter the fee? fixed, percentage of tx value, percentage of total network volume, some other dynamic fee adjustment process 3. 'Who' sets the fee? network parameter, contract owner, contract caller, validator market

silasdavis (Wed, 23 May 2018 20:51:36 GMT):
Also since spots in the validator set (not pool) are inherently scarce how do we create some competition for fees whilst keeping validator the network profitable?

silasdavis (Wed, 23 May 2018 20:52:09 GMT):
On that last point I sort of think the ability to start a connected fork of an existing network might be how subnets compete with each other

silasdavis (Wed, 23 May 2018 20:56:24 GMT):
Maybe we need a fee structure that is set by genesis/governance not under a market as such (contracts on the network will be where market forces can enter - and there could be competition between chains). But maybe that fee structure needs to be dynamic with access to variables representing total transaction volume so we could ensure that validator fees grow in sum with volume but individual transaction fees are reduced

silasdavis (Wed, 23 May 2018 20:56:39 GMT):
hmm I think you are right that could do with being tuned by some kind of market force on the validator fee

silasdavis (Wed, 23 May 2018 20:56:53 GMT):
anyway to bed for me, will think on

bird_alone (Thu, 24 May 2018 03:09:37 GMT):
It is a good discussion about how to manage fee calculation on Burrow. Thanks @silasdavis for your response. Ethereum platform for fee reduction has some weak points, however it works. As you said there are more rooms to for optimizing computation and also managing storage.

bird_alone (Thu, 24 May 2018 03:09:37 GMT):
Good discussion here about how to calculate fee amount on Burrow. Thanks @silasdavis and @finterran . Ethereum platform for fee reduction has some weak points, however it works. As you said there are more rooms for optimizing computation and also managing storage. This article might be interesting: https://cryptonewsmagnet.com/vitalik-proposes-new-ethereum-fee-to-reduce-network-overload/

bird_alone (Thu, 24 May 2018 03:09:37 GMT):
Good discussion here about how to calculate fee amount on Burrow. Thanks @silasdavis and @finterran . Ethereum platform for fee reduction has some weak points, however it works. As you said there are more rooms for optimizing computation and also managing storage. I believe the fee amount should be arbitrary, however we can just have a minimum for it. In the other hand validators are interested to transfer or execute codes with higher fees. I think in long round it's fair enough.

bird_alone (Thu, 24 May 2018 03:17:52 GMT):
This article might be interesting: https://cryptonewsmagnet.com/vitalik-proposes-new-ethereum-fee-to-reduce-network-overload/

bird_alone (Thu, 24 May 2018 03:20:15 GMT):
Maybe we need to think about scaling as well...

finterran (Thu, 24 May 2018 07:10:33 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=jE6bc5n7nY3LNsZgh) @silasdavis I totally agree with your view of the Ethereum “world computer”. I seems that the the pricing of pure computation operations on Ethereum is out of proportion (not to mention the limit it imposes on system computation). So I also am inclined to view computation in a similar manner, except for when it comes to storage. For me storage is the real pain point for fees. It is required to secure the network (the data is required to validate itself) and has long term implications for maintenance as it is ever growing.

finterran (Thu, 24 May 2018 07:11:06 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=WdQcyRbwzRwAwPAsd) @silasdavis I can imagine that this is true in your proposed use case. However, more generally not all transactions transfer value or can be quantified directly into token value. For example, imagine a twitter contract, or chess game contract. These do have value but directly ass you suggest. I think a fee structure needs to accommodate these more general cases as well.

finterran (Thu, 24 May 2018 07:11:06 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=WdQcyRbwzRwAwPAsd) @silasdavis I can imagine that this is true in your proposed use case. However, more generally not all transactions transfer value or can be quantified directly into token value. For example, imagine a twitter contract, or chess game contract. These do have value but not directly as you suggest. I think a fee structure needs to accommodate these more general cases as well.

finterran (Thu, 24 May 2018 07:11:30 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=3JN3EcgZ6rYQca2y7) @silasdavis I agree here, validators should want to compete to gather and propose blocks to get rewarded based on the validated tens in those blocks

finterran (Thu, 24 May 2018 07:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=zeQaLtHxLJTFNKzyn) @silasdavis 1. I am inclined to favour the Tx model (maybe because I haven’t done enough “outside the box” thinking on it. It should be noted that the other role of fees is for spam prevention, so as long as a fee is safely enforceable on the Contract level then Contract attachment may also be workable. I’m a bit skeptical of placing fees in control of the validator node RPC, it seems that there could arise the possibility for validators to act selfishly to acquire more fees. Not sure exactly how, but my spider sense is tingling. 2. As mentioned - % of Tx value only works for some use cases. % of network volume seems interesting, I will give it some thought as well.   If I were to imagine something that is dynamic per operation based, I would suggest accepting the Ethereum gas model (with some possible amendments to the gas table) to account for termination and computational limits (as Burrow already has), but then keep ‘pure computation’ operations free (gas tallied but not charged in the fee), and only charge for storage modifying operations.   This way termination is still ensured and validators can still set their ‘computational threshold’ by having their say about this limit. But also pure computation is no longer costly for consumers (and computation efficiency becomes a competitive advantage of a network/sub-network whereby validators can increase the computational limit to compete with others).  On this account storage costs are covered since the gas for them is included in the fee. I will say the storage rental model proposed by VB in @bird_alone’s post may have some merit as a supplemental implementation for a more sustainable model, at the very least there should be some incentive for contract makers (and consumers) to garbage collect their unused storage space. 3. The current model: network minimum, then user defined, then validator incentive to take the largest, seems to work well. I don’t really like the idea of consumers being able to jump the queue by paying higher prices, but I have to admit that it does extract the optimal amount of value for network resource usage. On this note, it is also the reason I am a proponent of leader based payouts rather than distributing fee across the validators directly.   For contract owner fee setting, unless the contract creator get a portion of the fee I don’t see any incentive for contract creator to increase fees at all. Either they will use the contract themselves in which case they want it as cheap as possible, or they want everyone else to use their contract so similar.  The validators defiantly should have a say in the fees they collect, and on the current paradigm they do through leader Tx selection and gas price voting. I’m open to suggestion for a more efficient model.  In any case, it is good to keep the ideas flowing. Thanks much.

finterran (Thu, 24 May 2018 07:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=zeQaLtHxLJTFNKzyn) @silasdavis 1. I am inclined to favour the Tx model (maybe because I haven’t done enough “outside the box” thinking on it. It should be noted that the other role of fees is for spam prevention, so as long as a fee is safely enforceable on the Contract level then Contract attachment may also be workable. I’m a bit skeptical of placing fees in control of the validator node RPC, it seems that there could arise the possibility for validators to act selfishly to acquire more fees. Not sure exactly how, but my spider sense is tingling.  2. As mentioned - % of Tx value only works for some use cases. % of network volume seems interesting, I will give it some thought as well.   If I were to imagine something that is dynamic per operation based, I would suggest accepting the Ethereum gas model (with some possible amendments to the gas table) to account for termination and computational limits (as Burrow already has), but then keep ‘pure computation’ operations free (gas tallied but not charged in the fee), and only charge for storage modifying operations.   This way termination is still ensured and validators can still set their ‘computational threshold’ by having their say about this limit. But also pure computation is no longer costly for consumers (and computation efficiency becomes a competitive advantage of a network/sub-network whereby validators can increase the computational limit to compete with others).   On this account storage costs are covered since the gas for them is included in the fee. I will say the storage rental model proposed by VB in @bird_alone’s post may have some merit as a supplemental implementation for a more sustainable model, at the very least there should be some incentive for contract makers (and consumers) to garbage collect their unused storage space.  3. The current model: network minimum, then user defined, then validator incentive to take the largest, seems to work well. I don’t really like the idea of consumers being able to jump the queue by paying higher prices, but I have to admit that it does extract the optimal amount of value for network resource usage. On this note, it is also the reason I am a proponent of leader based payouts rather than distributing fee across the validators directly.   For contract owner fee setting, unless the contract creator get a portion of the fee I don’t see any incentive for contract creator to increase fees at all. Either they will use the contract themselves in which case they want it as cheap as possible, or they want everyone else to use their contract so similar.  The validators defiantly should have a say in the fees they collect, and on the current paradigm they do through leader Tx selection and gas price voting. I’m open to suggestion for a more efficient model.  In any case, it is good to keep the ideas flowing. Thanks much.

finterran (Thu, 24 May 2018 07:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=zeQaLtHxLJTFNKzyn) @silasdavis 1. I am inclined to favour the Tx model (maybe because I haven’t done enough “outside the box” thinking on it. It should be noted that the other role of fees is for spam prevention, so as long as a fee is safely enforceable on the Contract level then Contract attachment may also be workable. I’m a bit skeptical of placing fees in control of the validator node RPC, it seems that there could arise the possibility for validators to act selfishly to acquire more fees. Not sure exactly how, but my spider sense is tingling.  2. As mentioned - % of Tx value only works for some use cases. % of network volume seems interesting, I will give it some thought as well.   If I were to imagine something that is dynamic per operation based, I would suggest accepting the Ethereum gas model (with some possible amendments to the gas table) to account for termination and computational limits (as Burrow already has), but then keep ‘pure computation’ operations free (gas tallied but not charged in the fee), and only charge for storage modifying operations.   This way termination is still ensured and validators can still set their ‘computational threshold’ by having their say about this limit. But also pure computation is no longer costly for consumers (and computation efficiency becomes a competitive advantage of a network/sub-network whereby validators can increase the computational limit to compete with others).   On this account storage costs are covered since the gas for them is included in the fee. I will say the storage rental model proposed by VB in @bird_alone’s post may have some merit as a supplemental implementation for a more sustainable model, at the very least there should be some incentive for contract makers (and consumers) to garbage collect their unused storage space.  3. The current model: network minimum, then user defined, then validator incentive to take the largest, seems to work well. I don’t really like the idea of consumers being able to jump the queue by paying higher prices, but I have to admit that it does extract the optimal amount of value for network resource usage. On this note, it is also the reason I am a proponent of leader based payouts rather than distributing fee across the validators directly.    For contract owner fee setting, unless the contract creator get a portion of the fee I don’t see any incentive for contract creator to increase fees at all. Either they will use the contract themselves in which case they want it as cheap as possible, or they want everyone else to use their contract so similar.  The validators defiantly should have a say in the fees they collect, and on the current paradigm they do through leader Tx selection and gas price voting. I’m open to suggestion for a more efficient model.   In any case, it is good to keep the ideas flowing. Thanks much.

finterran (Thu, 24 May 2018 07:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=zeQaLtHxLJTFNKzyn) @silasdavis 1. I am inclined to favour the Tx model (maybe because I haven’t done enough “outside the box” thinking on it. It should be noted that the other role of fees is for spam prevention, so as long as a fee is safely enforceable on the Contract level then Contract attachment may also be workable. I’m a bit skeptical of placing fees in control of the validator node RPC, it seems that there could arise the possibility for validators to act selfishly to acquire more fees. Not sure exactly how, but my spider sense is tingling.  2. As mentioned - % of Tx value only works for some use cases. % of network volume seems interesting, I will give it some thought as well.   If I were to imagine something that is dynamic per operation based, I would suggest accepting the Ethereum gas model (with some possible amendments to the gas table) to account for termination and computational limits (as Burrow already has), but then keep ‘pure computation’ operations free (gas tallied but not charged in the fee), and only charge for storage modifying operations.   This way termination is still ensured and validators can still set their ‘computational threshold’ by having their say about this limit. But also pure computation is no longer costly for consumers (and computation efficiency becomes a competitive advantage of a network/sub-network whereby validators can increase the computational limit to compete with others).   On this account storage costs are covered since the gas for them is included in the fee. I will say the storage rental model proposed by VB in @bird_alone’s post may have some merit as a supplemental implementation for a more sustainable model, at the very least there should be some incentive for contract makers (and consumers) to garbage collect their unused storage space.  3. The current model: network minimum, then user defined, then validator incentive to take the largest, seems to work well. I don’t really like the idea of consumers being able to jump the queue by paying higher prices, but I have to admit that it does extract the optimal amount of value for network resource usage. On this note, it is also the reason I am a proponent of leader based payouts rather than distributing fee across the validators directly.    For contract owner fee setting, unless the contract creator get a portion of the fee I don’t see any incentive for contract creator to increase fees at all. Either they will use the contract themselves in which case they want it as cheap as possible, or they want everyone else to use their contract so similar.   The validators defiantly should have a say in the fees they collect, and on the current paradigm they do through leader Tx selection and gas price voting. I’m open to suggestion for a more efficient model but can't think of anything sufficient currently.   In any case, it is good to keep the ideas flowing. Thanks much.

finterran (Thu, 24 May 2018 07:36:03 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=a7zE5hnefpAf8DL6R) @bird_alone Agreed - a sustainable model that accurately represents the long-term costs is good to think about. In the current era we think everything is good because generally the token prices are increasing. But many years in the future this may not be the case, and so chain death could occur because the maintenance cost is so large that validators drop out. On the other hand it could be argued that this maintenance cost is what supports the value of the token, similar to the Bitcoin mining/electricity argument.

silasdavis (Thu, 24 May 2018 09:55:13 GMT):
Plenty to think about, I will go away and do a bit more of that before responding - maybe try and work up some examples of how they would fit in Burrow. Regarding long-term costs point above, one of the reason for separating a bonding token from a usage token is that we avoid using a deflationary token (bonding) as our means of exchange. When you say leader-based, for Tendermint I assume this would mean that the proposer of a block receives the payout. We would need to think about this, there is an opportunity for collusion here - which would still require > 1/3 of validators to behave badly and so we might consider already factored in - whereby a minority times out a round in order to get hold of lucrative transactions. Now I think the Tendermint accum that determines proposer might get around this - and possibly other measures. The other practical thing is to get a hook into block formation and alter that as a proposer dependent on transaction fee offered would require new code in Tendermint which I think they would be reluctant to provide

silasdavis (Thu, 24 May 2018 09:55:13 GMT):
Plenty to think about, I will go away and do a bit more of that before responding - maybe try and work up some examples of how they would fit in Burrow. Regarding long-term costs point above, one of the reason for separating a bonding token from a usage token is that we avoid using a deflationary token (bonding) as our means of exchange. When you say leader-based, for Tendermint I assume this would mean that the proposer of a block receives the payout. We would need to think about this, there is an opportunity for collusion here - which would still require > 1/3 of validators to behave badly and so we might consider already factored in, but it could be a plausibly deniable form of collusion - whereby a minority times out a round in order to get hold of lucrative transactions. Now I think the Tendermint accum that determines proposer might get around this - and possibly other measures. The other practical thing is to get a hook into block formation and alter that as a proposer dependent on transaction fee offered would require new code in Tendermint which I think they would be reluctant to provide

silasdavis (Thu, 24 May 2018 09:55:13 GMT):
Plenty to think about, I will go away and do a bit more of that before responding - maybe try and work up some examples of how they would fit in Burrow. Regarding long-term costs point above, one of the reason for separating a bonding token from a usage token is that we avoid using a deflationary token (bonding) as our means of exchange. When you say leader-based, for Tendermint I assume this would mean that the proposer of a block receives the payout. We would need to think about this, there is an opportunity for collusion here - which would still require > 1/3 of validators to behave badly and so we might consider already factored in, but it could be a plausibly deniable form of collusion - whereby a minority times out a round in order to get hold of lucrative transactions. Now I think the Tendermint accum that determines proposer might get around this - and possibly other measures. But such a starvation attack wouldn't effect consistency but it could bias rewards. The other practical thing is to get a hook into block formation and alter that as a proposer dependent on transaction fee offered would require new code in Tendermint which I think they would be reluctant to provide

silasdavis (Thu, 24 May 2018 10:02:44 GMT):
at some point (need to code today!) I'd like to write down a wishlist for a parameterisable fee charging system (BTW I'm fairly happy that the disbursement side is along the right lines, but the allocation is not) and start from a blank sheet of paper to see what we can come up with. It would be nice if it could accommodate a fee structure similar to public ethereum as well as fees based on value/volume/contract. It also seems crucial to align the incentives of validators and users of the network both in the near term (low volume, high fee per consumer) and long term (high volume, low fee per consumer) limits.

silasdavis (Thu, 24 May 2018 10:09:43 GMT):
See also: https://github.com/tendermint/tendermint/issues/1072

silasdavis (Thu, 24 May 2018 10:13:58 GMT):
Okay I am out of date

silasdavis (Thu, 24 May 2018 10:14:46 GMT):
ABCI now integrates gas and fee notion, see example: https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/baseapp.go#L318-L358

silasdavis (Thu, 24 May 2018 10:15:32 GMT):
the previous issue still applies - it seems a little odd the application has no input

silasdavis (Thu, 24 May 2018 10:17:27 GMT):
It looks like Tendermint is planning to have proposers maximise fees per block: https://github.com/tendermint/abci/issues/57

cbf (Thu, 24 May 2018 14:13:50 GMT):
Has joined the channel.

jtclark (Thu, 24 May 2018 20:51:57 GMT):
Has left the channel.

coinvest518 (Mon, 28 May 2018 20:16:56 GMT):
Has joined the channel.

finterran (Mon, 28 May 2018 22:52:42 GMT):
Hello all. We would like to inform you that our implementation of the validation pool/validator set model is almost done. The idea behind the validation pool is that anyone who put some stake can have the right to enter the validator set each round and can be accordingly slashed if they are Byzantine at any time. The Bonding stake should have a minimum amount to cover any Byzantine gains while in the validator set, and should probably have a maximum limit to ensure that a coalition of Byzantine nodes cannot take control of the validator set in an easy manner.(we can talk about Sybil attack implications of this) To Bond, anyone can send a BondTx to the network between the minimum and maximum stake requirements (assuming BondTxs are either globally allowed or set for that account). Once a BondTx has been accepted, validated, and consensed upon, the sending node has a chance to elect itself into the validator set in each round. A BondTx operates in essence like a SendTx, but rather than the sent amount being added to the receiving address as a token balance amount, it is instead added as a stake amount stored separately per address in the IVAL tree. This way addresses can be both accounts and validators with token amounts and stake amount being separate. Validators who are in the validation pool (but not yet included in the validator set) 'self elect' by running a Verifiable Random Function (VRF) in each round using the previous block hash as a seed. The result of this VRF should be absolutely random and crypto-provable. (Silas has pointed out that our current implementation of the VRF may be vulnerable to gaming due to signature malleability) Once a VRF output meets the protocol requirements for election, the validator can send these results to the network as a 'sortition transaction'. Only after this transaction is validated and signed by 2/3rds by of the current round's validators, can the 'self-elector' enter the validation set. When a validator enters the pool, the validator set automatically adjust itself, according to these rules: 1 - The total power of the validator set should target some maximum number 2 - The validator set should keep 2/3 of the power of the previous round's set (to fulfil the Tendermint lite-client requirements) 3 - The validator set should never exceed 99 nodes (since Tendermint performance drops dramatically after this) While the validator set is adjusted, some validators will be removed from the set by the protocol. During this, priority for removal is given to the validators who have been in the set longest and those with power 0 (Byzantine nodes). To decouple stake from vote power and leader selection - while in the validator set - each validator has power equal to (1). This gives a uniform distribution of vote power and of proposer/leader selection in the Tendermint protocol. In addition to ensuring that stake only contributes to entering the validator set, this model also provides the maximum resilience to coalition attacks on the set since it maximises the number of nodes necessary to get 1/3 power, and also ensures that statistically each validator will be selected once for the proposer/leader role while in the set before removal.

finterran (Mon, 28 May 2018 22:52:42 GMT):
Hello all. We would like to inform you that our implementation of the validation pool/validator set model is almost done. The idea behind the validation pool is that anyone who put some stake can have the right to enter the validator set each round and can be accordingly slashed if they are Byzantine at any time. The Bonding stake should have a minimum amount to cover any Byzantine gains while in the validator set, and should probably have a maximum limit to ensure that a coalition of Byzantine nodes cannot take control of the validator set in an easy manner.(we can talk about Sybil attack implications of this) To Bond, anyone can send a BondTx to the network between the minimum and maximum stake requirements (assuming BondTxs are either globally allowed or set for that account). Once a BondTx has been accepted, validated, and consensed upon, the sending node has a chance to elect itself into the validator set in each round. A BondTx operates in essence like a SendTx, but rather than the sent amount being added to the receiving address as a token balance amount, it is instead added as a stake amount stored separately per address in the IVAL tree. This way addresses can be both accounts and validators with token amounts and stake amount being separate. Validators who are in the validation pool (but not yet included in the validator set) 'self elect' by running a Verifiable Random Function (VRF) in each round using the previous block hash as a seed. The result of this VRF should be absolutely random and crypto-provable. (Silas has pointed out that our current implementation of the VRF may be vulnerable to gaming due to signature malleability) Once a VRF output meets the protocol requirements for election, the validator can send these results to the network as a 'sortition transaction'. Only after this transaction is validated and signed by 2/3rds by of the current round's validators, can the 'self-elector' enter the validation set. When a validator enters the pool, the validator set automatically adjust itself, according to these rules: 1 - The total power of the validator set should target some maximum number 2 - The validator set should keep 2/3 of the power of the previous round's set (to fulfil the Tendermint lite-client requirements) 3 - The validator set should never exceed 99 nodes (since Tendermint performance drops dramatically after this) While the validator set is adjusted, some validators will be removed from the set by the protocol. During this, priority for removal is given to the validators who have been in the set longest and those with power 0 (Byzantine nodes). To decouple stake from vote power and leader selection - while in the validator set - each validator has power equal to (1). This gives a uniform distribution of vote power and of proposer/leader selection in the Tendermint protocol. In addition to ensuring that stake only contributes to entering the validator set, this model provides the maximum resilience to coalition attacks on the set since it maximises the number of nodes necessary to get 1/3 power, and also ensures that statistically each validator will be selected once for the proposer/leader role while in the set before removal.

finterran (Mon, 28 May 2018 22:52:42 GMT):
Hello all. We would like to inform you that our implementation of the validation pool/validator set model is almost done. The idea behind the validation pool is that anyone who put some stake can have the right to enter the validator set each round and can be accordingly slashed if they are Byzantine at any time. The Bonding stake should have a minimum amount to cover any Byzantine gains while in the validator set, and should probably have a maximum limit to ensure that a coalition of Byzantine nodes cannot take control of the validator set in an easy manner.(we can talk about Sybil attack implications of this) To Bond, anyone can send a BondTx to the network between the minimum and maximum stake requirements (assuming BondTxs are either globally allowed or set for that account). Once a BondTx has been accepted, validated, and consensed upon, the sending node has a chance to elect itself into the validator set in each round. A BondTx operates in essence like a SendTx, but rather than the sent amount being added to the receiving address as a token balance amount, it is instead added as a stake amount stored separately per address in the IVAL tree. This way addresses can be both accounts and validators with token amounts and stake amount being separate. Validators who are in the validation pool (but not yet included in the validator set) 'self elect' by running a Verifiable Random Function (VRF) in each round using the previous block hash as a seed. The result of this VRF should be absolutely random and crypto-provable. (@silasdavis has pointed out that our current implementation of the VRF may be vulnerable to gaming due to signature malleability) Once a VRF output meets the protocol requirements for election, the validator can send these results to the network as a 'sortition transaction'. Only after this transaction is validated and signed by 2/3rds by of the current round's validators, can the 'self-elector' enter the validation set. When a validator enters the pool, the validator set automatically adjust itself, according to these rules: 1 - The total power of the validator set should target some maximum number 2 - The validator set should keep 2/3 of the power of the previous round's set (to fulfil the Tendermint lite-client requirements) 3 - The validator set should never exceed 99 nodes (since Tendermint performance drops dramatically after this) While the validator set is adjusted, some validators will be removed from the set by the protocol. During this, priority for removal is given to the validators who have been in the set longest and those with power 0 (Byzantine nodes). To decouple stake from vote power and leader selection - while in the validator set - each validator has power equal to (1). This gives a uniform distribution of vote power and of proposer/leader selection in the Tendermint protocol. In addition to ensuring that stake only contributes to entering the validator set, this model provides the maximum resilience to coalition attacks on the set since it maximises the number of nodes necessary to get 1/3 power, and also ensures that statistically each validator will be selected once for the proposer/leader role while in the set before removal.

finterran (Mon, 28 May 2018 22:53:36 GMT):

1.png

finterran (Mon, 28 May 2018 22:54:28 GMT):

2.png

finterran (Mon, 28 May 2018 22:55:07 GMT):

3.png

finterran (Mon, 28 May 2018 22:56:40 GMT):
https://github.com/finterra/finterra-burrow This is the finterra-burrow repository forked from Hyperledger Burrow. Take a look, and all feedback is welcome! Thanks!

silasdavis (Tue, 29 May 2018 13:09:26 GMT):
Thanks for this @finterran I have opened this PR: https://github.com/hyperledger/burrow/pull/780/files not with a view to merging it in current form (as you know we have some issues to work through at least on licensing) but I was planning to make some comments that can help us harmonise the code bases with a view to merging in parts or all of your changes

silasdavis (Tue, 29 May 2018 13:18:20 GMT):
I'll probably start with some divergences that seem are quite minor - but where I suggest we try and maintain existing convention from Burrow

silasdavis (Tue, 29 May 2018 13:27:50 GMT):
It will take a certain amount of work/time to harmonise our efforts but I think it should be worth it down the line. Please do let me know if you are in a position to put in that time now, later, or at all so I can best use my time - if we can't bring things in line together then I may have to reimplement certain elements.

silasdavis (Tue, 29 May 2018 15:41:38 GMT):
I am pretty keen on the `SortitionTx`. I think `ValidatorSet` needs to be split into a base multiset over validators with basic validation and your VRF churn mechanism needs to be wrapped up as some kind of policy

silasdavis (Tue, 29 May 2018 15:43:17 GMT):
@bird_alone I've left some comments on that PR. I think once legal is sorted we should try and find a place to make a cut and I'd like to be able to accept some of the core work you've done with bond, unbond, sortition, and validator_pool

grice_32 (Tue, 29 May 2018 16:44:44 GMT):
Has joined the channel.

bird_alone (Wed, 30 May 2018 02:49:23 GMT):
@silasdavis I will check the code and will do some amendments due to License issue we have right now. About VRF: There are some flaws on our `VRF` implementation (Transaction Malleability). I remember when I was studying the VRF functionality, I saw in some implementations that they send some parameters from the curve as parts of the proof. That time I didn't know why and for what this extra information is sending. Now I think I know the reason! Thanks for the hint.

silasdavis (Wed, 30 May 2018 12:40:01 GMT):
@bird_alone thanks, I've made some further remarks and also a note on how I was hoping we could proceed

jwaup (Wed, 30 May 2018 13:53:03 GMT):
Has joined the channel.

silasdavis (Thu, 31 May 2018 15:09:56 GMT):
@finterran @bird_alone an idea about fee price setting mechanisms...

silasdavis (Thu, 31 May 2018 15:13:31 GMT):
in Tendermint since all validators must process all transactions it is difficult to have market-based competition to set a fair price. A validator could reject transactions coming to it before submitting to the mempool but it is a byzantine fault for CheckTx to return a different result on different nodes

silasdavis (Thu, 31 May 2018 15:13:31 GMT):
in Tendermint since all validators must process all transactions it is difficult to have market-based competition to set a fair price. Any transaction must be run by all validators regardless who offers a particular minimum fee. A validator could reject transactions coming to it before submitting to the mempool but it is a byzantine fault for CheckTx to return a different result on different nodes.

silasdavis (Thu, 31 May 2018 15:13:42 GMT):
So validators need a way to set fees collaboratively

silasdavis (Thu, 31 May 2018 15:14:21 GMT):
but ideally we would like to align incentives of validators and producers on the network and have low fees rather than monopolistic rent extraction based on validator token

silasdavis (Thu, 31 May 2018 15:15:58 GMT):
I propose that we could have a network fee setting mechanism based on a generalisation of Vickrey auction (https://en.wikipedia.org/wiki/Vickrey_auction) - this type of auction is used for online ads and encourages bidding your true value. The basic auction has every bidder submit a sealed bid. The highest bid wins, but that winning bidder pays the second highest price. See wikipedia for analysis of why the optimal strategy is bidding true value.

silasdavis (Thu, 31 May 2018 15:15:58 GMT):
I propose that we could have a network fee setting mechanism based on a generalisation of a Vickrey auction (https://en.wikipedia.org/wiki/Vickrey_auction) - this type of auction is used for online ads and encourages bidding your true value. The basic auction has every bidder submit a sealed bid. The highest bid wins, but that winning bidder pays the second highest price. See wikipedia for analysis of why the optimal strategy is bidding true value.

silasdavis (Thu, 31 May 2018 15:22:07 GMT):
In our setting we could periodically run an auction to set the minimum fee accepted by all validators (whether that is percentage of value, fixed, or dynamic doesn't really matter). The 'winners' of this auction will be validators who's bids are within the lowest 2/3 of all bids (by order), the remaining 1/3 are the losers (fractions arbitrary... but making it _possible_ for a quorum to be winners feels right). The minimum fee set by this auction is the lowest _losing_ bid (this is generalisation of the Vickrey concept)

silasdavis (Thu, 31 May 2018 15:22:07 GMT):
In our setting we could periodically run an auction to set the minimum fee accepted by all validators (whether that is percentage of value, fixed, or dynamic doesn't really matter). The 'winners' of this auction will be validators who's bids are within the lowest 2/3 of all bids (by order), the remaining 1/3 are the losers (we use 2/3 so that auctions complete with at least a majority of non-byzantine validators). The minimum fee set by this auction is the lowest _losing_ bid (this is generalisation of the Vickrey concept)

silasdavis (Thu, 31 May 2018 15:22:07 GMT):
In our setting we could periodically run an auction to set the minimum fee accepted by all validators (whether that is percentage of value, fixed, or dynamic doesn't really matter). The 'winners' of this auction will be validators who's bids are within the lowest 2/3 of all bids (by order), the remaining 1/3 are the losers (we use 2/3 so that auctions complete with at least a majority of non-byzantine validators... see later). The minimum fee set by this auction is the lowest _losing_ bid (this is generalisation of the Vickrey concept)

silasdavis (Thu, 31 May 2018 15:23:23 GMT):
All validators must accept transactions with a fee above this minimum (though tendermint will still prioritise higher fee transactions), txs below this bid will be rejected by all validators

silasdavis (Thu, 31 May 2018 15:23:23 GMT):
All validators must accept transactions with a fee above this minimum (though tendermint will still prioritise higher fee transactions when forming block proposals), txs below this price will be rejected by all validators

silasdavis (Thu, 31 May 2018 15:25:44 GMT):
When we come to fee disbursement we add into our formula (taking account of voting power and availability) a factor that means losing validators earn half what winning validators earn per unit stake per unit availability

silasdavis (Thu, 31 May 2018 15:27:58 GMT):
The way we could implement this by adding a FeeBidTx which contains an auction id, an encrypted minimum fee bid, and a signature from the validator submitting

silasdavis (Thu, 31 May 2018 15:27:58 GMT):
The way we could implement this by adding a FeeBidTx which contains an auction id, the validator address, the validator sequence number, an encrypted minimum fee bid, and a signature from the validator submitting

silasdavis (Thu, 31 May 2018 15:28:32 GMT):
other validators can join the auction by sending a FeeBidTx with the same auction bid (or start a new one with a new auction id)

silasdavis (Thu, 31 May 2018 15:28:32 GMT):
other validators can join the auction by sending a FeeBidTx with the same auction bid (or start a new one with a new auction id though with a higher sequence number and invalidating previous bids)

silasdavis (Thu, 31 May 2018 15:30:35 GMT):
once 2/3 off FeeBidTx have been collected for a particular auction (none of which are invalidated by a bid in a newer auction) then the bid phase is complete

silasdavis (Thu, 31 May 2018 15:30:35 GMT):
once 2/3 of FeeBidTx have been collected for a particular auction (none of which are invalidated by a bid in a newer auction) then the bid phase is complete

silasdavis (Thu, 31 May 2018 15:30:35 GMT):
once a grace period has elapsed to allow validators to bid and at least 2/3 of FeeBidTx have been collected for a particular auction (none of which are invalidated by a bid in a newer auction) then the bid phase is complete

silasdavis (Thu, 31 May 2018 15:33:06 GMT):
then validators need to submit a RevealFeeBidTx that contains the auction id, validator address, key they encrypted their bid with, and signature

silasdavis (Thu, 31 May 2018 15:38:23 GMT):
once a grace period has elapse and at least 2/3 RevealFeeBidTx are received the auction completes and the lowest 2/3 of bids are winners, we may need to choose 2/3 N - 1 to ensure someone who submitted in the auction always loses. The lowest losing price is now the minimum fee accepted, and the non-voters are defined as losers

silasdavis (Thu, 31 May 2018 15:38:48 GMT):
the fee reduction for losers can obviously be tuned

silasdavis (Thu, 31 May 2018 15:38:59 GMT):
1/2 might be too extreme

silasdavis (Thu, 31 May 2018 15:40:01 GMT):
but if you are in the loser group you can trigger a new auction whenever you like to try and recover winner fee disbursement status

silasdavis (Thu, 31 May 2018 15:40:51 GMT):
this could be just a component of a fee system with a fixed amount but at least something like this could introduce a price setting mechanism

silasdavis (Thu, 31 May 2018 15:44:41 GMT):
incidentally for mechanism like this and your SortitionTx I think I would to introduce transaction executor go plugins - configured in genesis and changeable through governance at some point

VinayChaudharyOfficial (Fri, 01 Jun 2018 04:55:50 GMT):
Has joined the channel.

abraham (Fri, 08 Jun 2018 03:52:50 GMT):
Has joined the channel.

basilji (Wed, 13 Jun 2018 06:10:54 GMT):
Has joined the channel.

basilji (Wed, 13 Jun 2018 06:13:26 GMT):
Hi

basilji (Wed, 13 Jun 2018 06:13:56 GMT):

Clipboard - June 13, 2018 11:44 AM

basilji (Wed, 13 Jun 2018 06:14:11 GMT):
We are getting above error while deploying contract

basilji (Wed, 13 Jun 2018 06:14:11 GMT):
We are getting above error while deploying contract . Could you please let us know why the above error is occuring

aswinuthara (Wed, 13 Jun 2018 08:54:10 GMT):
Has joined the channel.

seanyoung (Wed, 13 Jun 2018 08:59:31 GMT):
@basilji looks like you are using a new burrow with an old bos; also monax-keys is gone a recent burrow

aswinuthara (Wed, 13 Jun 2018 09:29:37 GMT):
@seanyoung can you share all those versions of bos, burrow and keys

basilji (Wed, 13 Jun 2018 09:51:44 GMT):
@seanyoung Could you please provide the installation version required to install correct bos version

basilji (Wed, 13 Jun 2018 09:51:44 GMT):
@seanyoung Could you please provide correct bos version version

seanyoung (Wed, 13 Jun 2018 10:08:23 GMT):
hmm the situation is ideal right now, bos 0.2.0 (master) and burrow develop branch. We'll try to do a burrow release soon

silasdavis (Wed, 13 Jun 2018 10:09:54 GMT):
@tkuhrt my colleague @seanyoung will be attending the Amsterdam hackfest, who should he connect with/what should he do to ensure he hits the ground running? @amundson (from STL Sean) has DM'd asking if I will be there so would be good if we might find something to work on. One ideas I had was a go based ethereum ABI (with an eye to ABI2 compatibility) that would be Apache licensed and could free us from go-ethereum as well as allowing some powerful stuff server side in terms of 'calling through' to the contract layuer

amundson (Wed, 13 Jun 2018 10:09:56 GMT):
Has joined the channel.

amundson (Wed, 13 Jun 2018 10:22:26 GMT):
@silasdavis I was thinking specifically that maybe we could figure out an estimate on the level of effort required to use the current burrow with seth

amundson (Wed, 13 Jun 2018 10:23:22 GMT):
and perhaps make some progress on it

basilji (Wed, 13 Jun 2018 11:17:29 GMT):

Clipboard - June 13, 2018 4:47 PM

basilji (Wed, 13 Jun 2018 11:18:24 GMT):
@seanyoung Thanks. I am getting above error while deploying contract. I have used below command bos pkgs do --keys="http://localhost:4767" --chain-url="tcp://localhost:46657" --address="5C3D781E8CA58AD566D580712FD932C5935587C4"

basilji (Wed, 13 Jun 2018 11:28:12 GMT):

Clipboard - June 13, 2018 4:58 PM

basilji (Wed, 13 Jun 2018 11:29:44 GMT):
Please find the logs when I tried to deploy a sample contract. I have used bos 0.2.0 (master) and burrow develop branch

basilji (Wed, 13 Jun 2018 11:29:44 GMT):
@seanyoung Please find the logs when I tried to deploy a sample contract. I have used bos 0.2.0 (master) and burrow develop branch

seanyoung (Wed, 13 Jun 2018 14:54:38 GMT):
@silasdavis and I are aware of some problems, we're trying to fix it now

compleatang (Thu, 14 Jun 2018 10:52:34 GMT):
@basilji and @aswinuthara this room is for developers working on the core burrow codebase, please in the future move such questions to the #burrow room where a larger grouping of the community can help.

basilji (Thu, 14 Jun 2018 12:26:05 GMT):
ok thanks

guoger (Fri, 15 Jun 2018 06:03:45 GMT):
hi, burrow devs, just wondering when will `REVERT` be available? thx!

silasdavis (Fri, 15 Jun 2018 13:45:46 GMT):
NOW

silasdavis (Fri, 15 Jun 2018 13:45:48 GMT):
:)

silasdavis (Fri, 15 Jun 2018 13:45:55 GMT):
it's on develop

silasdavis (Fri, 15 Jun 2018 13:46:10 GMT):
possibly master actually

silasdavis (Fri, 15 Jun 2018 13:46:24 GMT):
I need to pull my finger out and make a release

guoger (Fri, 15 Jun 2018 15:34:38 GMT):
awesome!! we will try it out on develop branch

pouladzade (Sat, 16 Jun 2018 11:18:26 GMT):
@silasdavis Hi Silas, Are you working on API's , if yes, I would be happy if you share with us. Because we also working on API and trying to make one module instead of legacy-db and legacy-contracts.

pouladzade (Sat, 16 Jun 2018 11:22:49 GMT):
@silasdavis another thing about the private accounts in Burrow, as I understood we can totally remove it. it's better to have a signer interface as well as go ethereum. I afraid to sign a transaction by it's class is not a good Idea. please correct me if I am wrong!

silasdavis (Sat, 16 Jun 2018 11:29:44 GMT):
@pouladzade we really should try and coordinate this work, yes - my colleague has just moved the RPC over to GRPC and I have implemented a service in Burrow

silasdavis (Sat, 16 Jun 2018 11:30:07 GMT):
This is a GRPC service: https://github.com/hyperledger/burrow/blob/develop/rpc/burrow/transaction_server.go

silasdavis (Sat, 16 Jun 2018 11:33:27 GMT):
I will get Tyler on here, but he has implemented the client side and has already done some work to merge them

silasdavis (Sat, 16 Jun 2018 11:34:05 GMT):
> another thing about the private accounts in Burrow, as I understood we can totally remove it. Currently I am keeping this in for legacy, we may want to remove it, but I'd like to reflect on that a bit more

silasdavis (Sat, 16 Jun 2018 11:34:38 GMT):
I'd like us to try and share and discuss changes before we both start making them and so we can avoid wasted effort/incompatible work, let's try and get more stuff in github issues

silasdavis (Sat, 16 Jun 2018 11:35:25 GMT):
It's also better if we can keep PRs focused so we can merge them more quickly

silasdavis (Sat, 16 Jun 2018 11:36:19 GMT):
I'd also like us to consider the real value of changes because if there are a lot of changes that are peripheral we may disagree on the merit and they are probably beside the main point, for example: https://github.com/hyperledger/burrow/pull/804

silasdavis (Sat, 16 Jun 2018 11:37:00 GMT):
What would it take in terms of changes for you to be able to use mainline Burrow? It's a real shame we are diverging on code - possibly on pointless stuff

silasdavis (Sat, 16 Jun 2018 11:38:13 GMT):
Can I suggest that before starting work (on both sides) we will put up a brief issue, and ping each other here, then we can coordinate. Not saying we have to wait on each other but let's at least have the chance to influence before we start hacking

pouladzade (Sat, 16 Jun 2018 11:38:51 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=89FCxw9JfCxYsvoCN) @silasdavis Yes sure, Of course

pouladzade (Sat, 16 Jun 2018 11:39:20 GMT):
Actually i wanted share with you before I create an issue

silasdavis (Sat, 16 Jun 2018 11:42:08 GMT):
I'm currently on this: https://github.com/hyperledger/burrow/issues/658

silasdavis (Sat, 16 Jun 2018 11:43:37 GMT):
BTW if you have any comments on recently merged pull request feel free to comment there (and possibly give me a ping though I should get notified). I'm happy to respond in comments/code to any suggestion you have even after the fact. Do you get notified of new PRs on Burrow?

pouladzade (Sat, 16 Jun 2018 11:46:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=iB8M7RSQEZbbdjLtr) @silasdavis You mean GRPC? or renaming tx to payload and making envelop ?

pouladzade (Sat, 16 Jun 2018 11:48:37 GMT):
I am just reading the burrow package

pouladzade (Sat, 16 Jun 2018 11:51:25 GMT):
are going to deprecate v0?

pouladzade (Sat, 16 Jun 2018 11:51:25 GMT):
are you going to deprecate v0?

pouladzade (Sat, 16 Jun 2018 11:51:25 GMT):
are you going to remove v0 after that?

pouladzade (Sat, 16 Jun 2018 11:52:21 GMT):
@bird_alone https://github.com/hyperledger/burrow/issues/658

silasdavis (Sat, 16 Jun 2018 12:02:11 GMT):
I won't get rid of v0 until it 'becomes a problem' at some point soonish I will probably disable it by default

silasdavis (Sat, 16 Jun 2018 12:02:11 GMT):
I won't get rid of v0 until it 'becomes a problem', but at some point soonish I will probably disable it by default

dennismckinnon (Sat, 16 Jun 2018 14:00:35 GMT):
Has joined the channel.

dennismckinnon (Sat, 16 Jun 2018 14:27:02 GMT):
Hi all. Silas requested i post about my plans regarding the reinvigoration of the js libs. There are a couple things that are on my mind here. First is switching to use GRPC. An ongoing process but one that removes a bunch of handwritten code for server communiation. Once done, the 'db' portion of the lib starts to become small enough to not really consider it its own lib (it never really was suited for that anyways) so im planning on merging them into a single lib. One which still exposes the lower level access but then builds with contracts and abi handling on top. A major consideration at this point is if I want to continue wrapping the web3 solidity function or move away from that since a lot of that code is strickly speaking unnecessary and i could just use the abi coder. Im still back and forth a bit on this so ill probably decide when I get there. When the merge is complete im hoping to do away with the ContractManager... i really think its unecessary and should just be new Contract(abi, [input account]) but im still feeling my way through it. Ultimately im planning on retaining most of the functionality but hopefully cleaning up the code so its easier to maintain.

Katie_Wei (Wed, 20 Jun 2018 18:40:36 GMT):
Has joined the channel.

silasdavis (Thu, 21 Jun 2018 14:48:12 GMT):
@amundson I think Sean could help with that - I don't think it will be that hard and hopefully our interface boundaries are improved. What I think @seanyoung and I would like to work on is building a clean and light go-based apache licensed ethereum ABI. This would allow people to deploy and call ethereum contracts without relying on web3 or go-ethereum and would allow us to pull package tooling into burrow, expose Ethereum functions in a natural style (call by name and args and formulate tx server side) and parse event schema for driving databases integrations we are working on. A liberally licensed library ABI in Go seems like a nice hack project, and really useful down the line. I would have thoguht useful for us and fabric-evm... cc @swetha @guoger @adamludvik ?

silasdavis (Thu, 21 Jun 2018 14:48:12 GMT):
@amundson I think Sean could help with that - I don't think it will be that hard and hopefully our interface boundaries are improved. What I think @seanyoung and I would like to primarily work on is building a clean and light go-based apache licensed ethereum ABI. This would allow people to deploy and call ethereum contracts without relying on web3 or go-ethereum and would allow us to pull package tooling into burrow, expose Ethereum functions in a natural style (call by name and args and formulate tx server side) and parse event schema for driving databases integrations we are working on. A liberally licensed library ABI in Go seems like a nice hack project, and really useful down the line. I would have thoguht useful for us and fabric-evm... cc @swetha @guoger @adamludvik ?

swetha (Fri, 22 Jun 2018 00:04:30 GMT):
@silasdavis, that sounds like an interesting idea. Are you thinking a parallel to the ethereum json rpc api?

swetha (Fri, 22 Jun 2018 00:04:30 GMT):
@silasdavis, that sounds like an interesting idea. Are you thinking of it as parallel to the ethereum json rpc api?

silasdavis (Wed, 27 Jun 2018 18:44:14 GMT):
@swetha yes although to our priorities it's currently more interesting (since we are not using web3). I have just added an execution events service that can be used to build a SQL database from EVM events (see: https://github.com/hyperledger/burrow/pull/808). Having an ABI server-side can allow us to interpret the schema/encoding of emitted events and do much more interesting things. Sean has made a good start on this already and looks very doable. Sean would be happy to work with people at the hackfest on any upgrades or helping with web3, but we'd like the ABI to be our main focus - and it's pretty fun stuff getting familiar with Go's fairly nice reflection features in an area where it is unusually apposite.

silasdavis (Wed, 27 Jun 2018 18:46:05 GMT):
@swetha are you attending Amsterdam, @amundson who from your team is going? cc @Dan @cbf would be good to team up on this - some possibilities around calling Solidity code through a common server-side interface as other chaincodes

Dan (Wed, 27 Jun 2018 18:46:05 GMT):
Has joined the channel.

cbf (Wed, 27 Jun 2018 18:51:14 GMT):
@swetha is on her way.. think she's planning to be there tomorrow (Thursday)

cbf (Wed, 27 Jun 2018 18:51:22 GMT):
I'll be there too

swetha (Wed, 27 Jun 2018 19:14:44 GMT):
@silasdavis , Yes I will be there tomorrow

silasdavis (Wed, 27 Jun 2018 20:19:31 GMT):
cool, btw after this fanfare I won't, but I'd like you to meet Sean who will be doing a lot of Burrow work

Dan (Wed, 27 Jun 2018 20:31:55 GMT):
@silasdavis Shawn, Peter, and Adam will be there. I unfortunately will not be there.

amundson (Wed, 27 Jun 2018 21:28:17 GMT):
@silasdavis we have burrow accessible via a network interface as a transaction processor. not sure how an ABI would give us more features? we also have web3 support in seth and working with some common tools, and I'm of the opinion it could be extended to support fabric as well. (and maybe native burrow?)

amundson (Wed, 27 Jun 2018 21:32:15 GMT):
@swetha ^

silasdavis (Thu, 28 Jun 2018 09:12:55 GMT):
@amundson with web3 you still need to know how to formulate the client side call, i.e. what do I pack into the Data field of `sendTransaction`. Web3 doesn't help you do this and without an ABI we are limited with connecting services that talk to ethereum unless we use the ethereum libraries (which are GPL and not that minimal in terms of just providing an ABI). If I want to write an events processor that understands solidity events I will need to use web3.js or go-ethereum (event with a web3 RPC). If I want If we want to build non-GPL services that can call a solidity function they need to know how to form the function selector, pack arguments, and return values. We can do this by buying in to existing Ethereum tooling (and I'm all for that) but there are good reasons not to want to buy into those libraries - they are very public ethereum centric and not as easy to hack. If we start dealing with the ABI server side we can also start to abstract over the EVM altogether - for example by having a Go EVM calling layer that another Go microservice can call into over GRPC and ask to do something without even knowing that is implemented as Solidity in an EVM. I'd like to be able to do that sort of thing without needing go-ethereum as dependency (I mean - if you're happy with go-ethereum as a dependency - you might be happy without Burrow)

silasdavis (Thu, 28 Jun 2018 09:12:55 GMT):
@amundson with web3 you still need to know how to formulate the client side call, i.e. what do I pack into the Data field of `sendTransaction`. Web3 doesn't help you do this and without an ABI we are limited with connecting services that talk to ethereum unless we use the ethereum libraries (which are GPL and not that minimal in terms of just providing an ABI). If I want to write an events processor that understands solidity events I will need to use web3.js or go-ethereum to formulate my calls and unpack my returns or events (even with a web3 RPC). If I want If we want to build non-GPL services that can call a solidity function they need to know how to form the function selector, pack arguments, and return values. We can do this by buying in to existing Ethereum tooling (and I'm all for that) but there are good reasons not to want to buy into those libraries - they are very public ethereum centric and not as easy to hack. If we start dealing with the ABI server side we can also start to abstract over the EVM altogether - for example by having a Go EVM calling layer that another Go microservice can call into over GRPC and ask to do something without even knowing that is implemented as Solidity in an EVM. I'd like to be able to do that sort of thing without needing go-ethereum as dependency (I mean - if you're happy with go-ethereum as a dependency - you might be happy without Burrow)

silasdavis (Thu, 28 Jun 2018 09:16:03 GMT):
In terms of Burrow I'd be interested in seeing a shim under your web3 RPC too - particularly if it could serve Fabric too. We are now exposing our base transactor service over GRPC which I think would be the ideal target for the core of web3: https://github.com/hyperledger/burrow/blob/develop/execution/pbtransactor/transactor.proto

silasdavis (Thu, 28 Jun 2018 09:17:19 GMT):
Another reason for us wanting an ABI (less so you - other than it improves Burrow) is that testing is more convoluted without it. Rather than having the ABI formulation happen in your tests the developer has to do it with tooling locally and copy the derived artefacts - the bytecode etc - into Burrow

amundson (Thu, 28 Jun 2018 09:50:16 GMT):
@silasdavis ABI is a very generic term, so just trying to understand. Do you envision it running at the same portion of the architecture as web3?

silasdavis (Thu, 28 Jun 2018 10:43:36 GMT):
ABI means this in the context of Solidity/EVM: https://solidity.readthedocs.io/en/v0.4.24/abi-spec.html

compleatang (Thu, 28 Jun 2018 10:43:57 GMT):
@amundson it is largely orthogonal to web3 in that web3 as ethereum folks define it is simply an RPC standard. so that bit focused on connection and transmission. one needs an ABI library if one is trying to make sense of what is going through the transport layer in terms of routing, querying, or other higher level functionality than simple transport into the chain system. Solidity's ABI system is *typically* a client/tooling side activity. One of the big limitations right now in the space is that the only libraries for ABIs are improperly licensed to allow tools within the Hyperledger community to be developed that can help with specifics around interacting with the Hyper frameworks.

silasdavis (Thu, 28 Jun 2018 10:44:00 GMT):
I envisage it as a modular libary thing that does that work

compleatang (Thu, 28 Jun 2018 10:44:47 GMT):
as an example, a liberally licensed ABI library could be helpful for Caliper to define smart contract functional tests that could effectively benchmark Sawtooth vis a vis Fabric vis a vis Burrow (at least when all were operating in EVM mode.

silasdavis (Thu, 28 Jun 2018 10:44:59 GMT):
functionality that go-ethereum provider here: https://github.com/ethereum/go-ethereum/blob/master/accounts/abi/abi.go

compleatang (Thu, 28 Jun 2018 10:45:08 GMT):
there are lots of other examples.... but that's the basic idea.

compleatang (Thu, 28 Jun 2018 10:46:09 GMT):
for our purposes we want to collapse the rest of the previous monax tooling into burrow for many reasons, but this will include our high level operational system for deploying systems of smart contracts to the chain (think, chef or ansible for your smart contract systems)

compleatang (Thu, 28 Jun 2018 10:46:54 GMT):
the limitation currently is we need an appropriately licensed ABI framework to do this. having this framework in burrow would also allow it to be more easily leveraged by other tooling systems within the hyper community.

cbf (Thu, 28 Jun 2018 11:39:27 GMT):
@compleatang why are we doing functional testing with caliper? I thought it was for performance and scale benchmarking

jhscheufen (Thu, 28 Jun 2018 11:42:51 GMT):
Has joined the channel.

compleatang (Thu, 28 Jun 2018 13:05:15 GMT):
@cbf I was just positing a potential test. it would be relevant to, say, what's the performance of a simple get-set EVM contract across the platforms... given that enabling smart contract functionality is so vital to use cases benchmarking based on TPS which simply move tokens around would be, in my view, of nominal value in the real world.

compleatang (Thu, 28 Jun 2018 13:05:15 GMT):
@cbf I was just positing a potential benchmark. it would be relevant to, say, what's the performance of a simple get-set EVM contract across the platforms... given that enabling smart contract functionality is so vital to use cases benchmarking based on TPS which simply move tokens around would be, in my view, of nominal value in the real world.

compleatang (Thu, 28 Jun 2018 13:07:11 GMT):
i used functional test wrongly there....

compleatang (Thu, 28 Jun 2018 13:15:19 GMT):
TBH I haven't looked into Caliber enough but benchmarking smart contract performance and scale would be of great value to everyone in my view... Too much noise in the space around tps when the real metric folks should be focusing on is tps with varying degrees of smart contract complexity. Because that's a better proxy for real world performance in my view.

compleatang (Thu, 28 Jun 2018 13:15:19 GMT):
TBH I haven't looked into Caliber enough but benchmarking smart contract performance and scale would be of great value to everyone in my view... Too much noise in the space around raw tps of token transfers when the real metric folks should be focusing on is tps with varying degrees of smart contract complexity. Because that's a better proxy for real world performance in my view.

compleatang (Thu, 28 Jun 2018 13:16:24 GMT):
I don't mean hyper specifically but greater blockchain ecosystem.

cbf (Thu, 28 Jun 2018 13:24:06 GMT):
agree

boatnoy (Sat, 30 Jun 2018 19:13:24 GMT):
Has joined the channel.

vagnerasilva (Sun, 01 Jul 2018 13:03:19 GMT):
Has joined the channel.

jelbazi (Mon, 02 Jul 2018 12:12:05 GMT):
Has joined the channel.

BabuPallam (Wed, 04 Jul 2018 22:18:23 GMT):
Has joined the channel.

ds2xor (Tue, 10 Jul 2018 02:41:12 GMT):
Has joined the channel.

rjones (Fri, 13 Jul 2018 21:14:57 GMT):
Has joined the channel.

rjones (Fri, 13 Jul 2018 21:15:05 GMT):
@all : 2FA will soon be required across all GitHub orgs. If you do not have 2FA enabled for your account, you will be automatically removed from the Hyperledger org and will need to be re-added. Please check to ensure you have 2FA enabled. https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/

compleatang (Mon, 16 Jul 2018 12:56:06 GMT):
thanks Ry.

pandagopal (Fri, 20 Jul 2018 05:13:31 GMT):
Has joined the channel.

VenkataY (Wed, 25 Jul 2018 17:02:55 GMT):
Has joined the channel.

angieology (Tue, 31 Jul 2018 17:51:14 GMT):
Has joined the channel.

mmartinez.blocknitive (Thu, 02 Aug 2018 11:30:54 GMT):
Has joined the channel.

fulldecent (Sat, 18 Aug 2018 02:07:23 GMT):
Has joined the channel.

fulldecent (Sat, 18 Aug 2018 02:07:32 GMT):
Hello room, this is William Entriken

fulldecent (Sat, 18 Aug 2018 02:09:12 GMT):
I am studying real-world, corporate problems for non-fungible tokens. Also, I'm the lead author of ERC-721

rjones (Sat, 18 Aug 2018 02:11:13 GMT):
hello @fulldecent

compleatang (Mon, 20 Aug 2018 15:19:10 GMT):
hi William! thanks for the PR and welcome!

compleatang (Mon, 20 Aug 2018 15:19:48 GMT):
lots of room for ERC-721 implementations on burrow so we're happy to have you around!

compleatang (Thu, 23 Aug 2018 08:17:04 GMT):
@rjones when you have a chance can we get a burrow-downstream room which we can focus on downstream developers from Sawtooth and Fabric that are using Burrows evm as a library. Those communications don't fit cleanly in either this room or the general burrow room. Thanks in advance!

sureshtedla (Fri, 31 Aug 2018 17:28:36 GMT):
Has joined the channel.

draysams (Sun, 02 Sep 2018 19:26:53 GMT):
Has joined the channel.

gregdhill (Fri, 07 Sep 2018 14:22:58 GMT):
Has joined the channel.

baoyangc (Wed, 12 Sep 2018 01:14:18 GMT):
Has joined the channel.

adamludvik (Tue, 18 Sep 2018 15:09:51 GMT):
Has left the channel.

gmkprabhu1983 (Wed, 19 Sep 2018 21:09:24 GMT):
Has joined the channel.

gmkprabhu1983 (Wed, 19 Sep 2018 21:09:40 GMT):
Hi

compleatang (Fri, 21 Sep 2018 17:45:03 GMT):
Hello

gmkprabhu1983 (Fri, 21 Sep 2018 19:17:16 GMT):
I would like contribute , where can I start ?

gmkprabhu1983 (Fri, 21 Sep 2018 19:17:24 GMT):
to contribute*

rjones (Fri, 21 Sep 2018 23:13:30 GMT):
@gmkprabhu1983 what is your interest and ability?

gmkprabhu1983 (Sat, 22 Sep 2018 02:55:58 GMT):
I can do coding

compleatang (Mon, 24 Sep 2018 09:07:20 GMT):
Hi @gmkprabhu1983 we've tagged a number of issues in burrow as good starter issues. Feel free to start on any of those if you'd like to contribute. We're happy to help you get started but at this point most any coder with go abilities should be able to begin with those tagged issues.

tkuhrt (Mon, 24 Sep 2018 16:21:01 GMT):
Just to make it easier, these would be the Good Starter issues: https://github.com/hyperledger/burrow/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%2Fgood+starter+issue%22

tkuhrt (Mon, 24 Sep 2018 16:21:35 GMT):
I also see a number of help wanted issues: https://github.com/hyperledger/burrow/issues?q=is%3Aissue+is%3Aopen+label%3A%22status%2Fhelp+wanted%22

gmkprabhu1983 (Mon, 24 Sep 2018 16:30:44 GMT):
@compleatang , @tkuhrt ok ,Thank you. I will get started with the tagged or starter issues.

phymbert (Sat, 29 Sep 2018 09:24:08 GMT):
Has joined the channel.

phymbert (Sat, 29 Sep 2018 09:24:47 GMT):
Hello Burrow contributors, First thank you for your great job on this project. I see issue 669 is flagged as help wanted, I coded a short implementation of abci.Query support for peer filtering, before I start to add integration test and submit PR. Is this contribution welcomed to burrow core? https://github.com/hyperledger/burrow/compare/develop...phymbert:authorised-only-node-sync

compleatang (Wed, 03 Oct 2018 01:54:46 GMT):
@phymbert yes indeed. Very welcome!

phymbert (Wed, 03 Oct 2018 12:00:09 GMT):
@compleatang great, I have opened a PR, I am not really fan to add a new parameter in kernel.New method but I didn't find a better way to so. Please feel free to review and ask for changes:

phymbert (Wed, 03 Oct 2018 12:00:38 GMT):
https://github.com/hyperledger/burrow/pull/924

compleatang (Wed, 03 Oct 2018 12:52:51 GMT):
Ok. @silasdavis or @seanyoung will get on a review shortly. It's sort of a hectic week with the member event in Montreal and some internal deadlines for us at Monax so don't worry if it takes a few days.

phymbert (Wed, 03 Oct 2018 15:52:08 GMT):
sure, thank you

phymbert (Wed, 03 Oct 2018 15:54:10 GMT):
oh it has been merged already, great 🤗

compleatang (Fri, 05 Oct 2018 13:32:44 GMT):
Excited for your help!

snowy13 (Fri, 05 Oct 2018 13:37:01 GMT):
Hey all, I'm having trouble compiling burrow `vendor/github.com/tmthrgd/go-hex/hex_decode_amd64.s:64: unrecognized instruction "VPCMPGTB"`

phymbert (Fri, 05 Oct 2018 13:50:22 GMT):
Hello @snowy13 , which version of go / which branch of burrow / which GOOS ?

snowy13 (Fri, 05 Oct 2018 13:51:34 GMT):
go version 1.9.2 , develop branch, os is debian stretch

phymbert (Fri, 05 Oct 2018 13:52:51 GMT):
@compleatang Thank you for your request about docs for multiple validators. In this example I have used local key client, I would like to understand benefits and concerns of local keys client vs keys server mode. If I document an "how to" set up multi validator network, what is the preferable way ? local or server keys ? thank you

snowy13 (Fri, 05 Oct 2018 14:01:11 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=sQFwagQoDyg24wsci) @phymbert GOOS=linux GOARCH=amd64

phymbert (Fri, 05 Oct 2018 14:01:52 GMT):
@snowy13 Can you try: go get github.com/tmthrgd/go-hex cd $GOPATH/src/github.com/tmthrgd/go-hex go test -v ./... If it does not pass, I suggest you to open an issue to go-hex directly. Try to build on another platform or use a docker image go-lang based for example

snowy13 (Fri, 05 Oct 2018 14:24:16 GMT):
@phymbert All good, was my bad. my exports hadn't persisted. Also updated to golang 1.10

compleatang (Sun, 07 Oct 2018 08:19:08 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=LZzo6QSaXoWm58KgG) @phymbert Probably local keys I'd say.

phymbert (Mon, 08 Oct 2018 10:14:24 GMT):
ok, I did this way. I took the liberty to move some part of the main README.md to docs folder. While trying seed mode, I faced an identified issue on tendermint (peer deconnected before receiving addresses). I have opened a PR for documentations update: https://github.com/hyperledger/burrow/pull/931 Please tell me if it is what you are looking for and/or changes requested.

compleatang (Mon, 08 Oct 2018 10:43:54 GMT):
Thanks @phymbert it looks good to me. I'll wait on @silasdavis to give a second eye though. In general seeds and persistentPeers should be used mutually exclusive of one another. If seed addresses are given then seedMode should be on whereas if persistentPeers are used then seedMode should be off. SeedMode is helpful when the seed peer is *very* static whereas persistentPeers are generally used where there is *some* dynamism in the nodes. For the AN we use only persistentPeers because we're on cloud nodes and they are liable to move around on various nodes within the cluster.

silasdavis (Mon, 08 Oct 2018 10:54:23 GMT):
Hi @phymbert I'm back in action this week having been at Hyperledger events last week. I'm going to take a look at your contributions shortly and get any outstanding ones merged. We're extremely grateful for your contributions which look great so far. I'd be interested to know a bit more about your use case and also if you are interested in possible maintainership of Burrow in the future?

phymbert (Mon, 08 Oct 2018 13:28:58 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=S73inMutQSzuGdscQ) @silasdavis Hello @silasdavis, thank you for your message. And congrats for the new role you have now at Hyperledger Technical Committee, this is really cool Burrow is represented there. Actually, I have started to look into Burrow at early stage in last February (remember our discussion about key local client), I am impressed by the achievement the team has done so far. I choose Burrow because it is the perfect bridge between public and permissioned blockchain, plus hosted by Hyperledger community. I am personally trying to learn more about blockchain network and smart contracts. I am working for the financial industry in France, yet nothing related to blockchain, although I am confident this Hyperledger implementation will be largely adopted by the industry in the future. Since I feel now more confident with Go with professional experience, I have restarted a personal project trying running Burrow on gomobile (FYI it's just perfectly works on Android). I am really happy if I can contribute to Burrow core, and maybe one day be granted with write access; Note as most of open source maintainers, I am welling to contribute during personal time only.

compleatang (Mon, 08 Oct 2018 13:45:01 GMT):
burrow on android. neat! :)

phymbert (Mon, 08 Oct 2018 13:48:35 GMT):
Yes :grinning: I didnt try yet smartcontract calls, only classical Send transaction; but I think it will just work smoothly

silasdavis (Mon, 08 Oct 2018 14:11:50 GMT):
I'm out-of-date on Android development, but what's the experience like with Go - you do it as a native app?

silasdavis (Mon, 08 Oct 2018 14:12:12 GMT):
Do you need a Java wrapper?

silasdavis (Mon, 08 Oct 2018 14:13:49 GMT):
I guess for all the UI stuff you are still using Java SDK

phymbert (Mon, 08 Oct 2018 14:47:38 GMT):
Yes, gomobile generates a native lib and gobind exposes a java interface with all public method of a go package. Then you just include it in your android app, and code the UI in xml+kotlin/java. There is a way in gomobile to code the user interface directly in go, but it is in openGl, IMO too complex. What is cool, it works the same on Android and iPhone. My initial goal was to reconciliate both platform in a blockchain Transaction :family_mwbb:

compleatang (Mon, 08 Oct 2018 22:01:23 GMT):
nice!

phymbert (Tue, 09 Oct 2018 06:47:04 GMT):
Hello, I would like to discuss again authorized peers filter feature done recently. I have tried to use it and it is not so easy: you receive Tendermint node ID (address of the nodeKey) but this key is nothing related to our accounts and validators keys set ( app layer vs p2p layer). As-is it is difficult to filter except if you use name registery to store all nodeKey. Any better idea? I have asked Tendermint users group, if we can use nodeKey.PrivKey as privValidator.privKey but so far no answer, I dunno if it is a security issue but it would make thing easier.

compleatang (Tue, 09 Oct 2018 08:57:35 GMT):
so my understanding is that the nodeKey can't be the privValidator key because ed22519 keys (which are used for privValidators) can't be used for diffie helman key exchange (needed for the p2p). so, as I understand it, ECDH keys are used for the nodeKey and ed22519 keys are used for privValidator. you're right that this creates a bit of a hassle. one way to overcome it is to do something like the issue i logged yesterday -> https://github.com/hyperledger/burrow/issues/933 (which is basically the same as what you propose) another way to tackle the issue is to be a bit more public about the burrow.toml. we do that for the Agreements Network -> https://github.com/agreements-network/info/blob/master/t4/burrow.toml tendermint *just* exposed the nodeKey as an interface in their most recent version IIRC but I don't remember if we did anything with that yet, @silasdavis or @seanyoung do either of you remember?

phymbert (Tue, 09 Oct 2018 09:23:17 GMT):
Thank you @compleatang for the explanation, it is clearer. Is there a chance from burrow user point of view we expose a simple boolean in config i.e ForbidPeerWithoutAccountToSync and hide all this complexity ?

silasdavis (Tue, 09 Oct 2018 14:01:20 GMT):
.... Just to reprise earlier convo about seeds. SeedMode is something that can be enabled on a node. If a node is in seed mode it will accept inbound connections, share its address book, then hang up. Seeds modes will do a bit of gossip but not that usefully. You can list any type of node in 'Seeds' in the config, whether or not another node considers you a seed is independent of whether you are in 'seed mode'. These are different concepts. You are free to use a non-seed-mode node as a seed. You do not want to have too many seeds in your network (because they just keep hanging up on other nodes once they've spread their wild oats), but they are useful for accelerating peer exchange (of addresses). Persistent peers are peers that you want to connect of regardless of the heuristics and churn dynamics built into the p2p switch. Ordinarily you would not stay connected to a particular peer forever, and you would not indefinitely redial, but you will for a persistent peer. Incidentally there is an online interface for dialling peers and seeds which has a flag for persistent. I I'd like to expose this functionality over Burrow's RPC, but perhaps not at such a low level.

silasdavis (Tue, 09 Oct 2018 14:09:39 GMT):
Regarding the node key/validator key. My hunch is that nothing would explode if you were to use a single key for both purposes. There are two reasons not to I can think of: 1. the node key is used (a lot) for the station-to-station protocol (can think of it as a kind of peer-to-peer TLS). This effectively runs down the entropy in the key from the perspective of what you have revealed to a potential attacker. I don't know how this would be quantified, but having a separate transport level key to your identity's signing key is 'good practice'. 2. is basically segregation - your validator key may in principle have real-world value (validator voting power == bond) by keeping it used for the single purpose of signing votes the attack surface area (and frequency of signatures) is reduced. Actually the node key doesn't get used for signatures, but it is still 'exposed' through the STS DH.

silasdavis (Tue, 09 Oct 2018 14:10:32 GMT):
I would be wary of trying to use the same key for both. Though now the node key is provided programmatically it would be fairly easy to do in Burrow.

silasdavis (Tue, 09 Oct 2018 14:13:14 GMT):
To get to your point - you are right about it being a pain mapping between node key and validator key. Burrow gives every node (even if not a validator) a validator key. So we end up with a 1-to-1 correspondence but we have no way of mapping the two.

silasdavis (Tue, 09 Oct 2018 14:14:43 GMT):
If we are happy that is a reasonable think to give every node a validator key, and if we are happy that that should be it's primary identity (in some sense), then I actually think a network-wide registry is not a bad idea

silasdavis (Tue, 09 Oct 2018 14:15:23 GMT):
the way I would like to do it is have nodes submit their p2p identities by way of a handshake

silasdavis (Tue, 09 Oct 2018 14:16:07 GMT):
The way that springs to mind is to broadcast a transaction of a new type `IdentifyTx` signed by the validator key with the nodekey

silasdavis (Tue, 09 Oct 2018 14:16:19 GMT):
this would also allow you to register a replacement nodekey identity

silasdavis (Tue, 09 Oct 2018 14:16:56 GMT):
we would verify a multisig of this tx of two inputs: validator key, node key

silasdavis (Tue, 09 Oct 2018 14:17:34 GMT):
if they mutually sign then that key mapping gets added to registry (which can be a fairly simple store)

silasdavis (Tue, 09 Oct 2018 14:18:50 GMT):
I envisage a bunch of features/use cases where being able to lookup the p2p address (ID and NetAddress for that matter) will be useful, such as state channels/subnets. But it will be useful today for ops - I've often spent time trying to figure who's node is who's

phymbert (Tue, 09 Oct 2018 14:32:13 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=rkkkXPPQ7TZPB3Sop) @silasdavis I am trying to write a unit test on issue #2092 in tendermint, I was thinking it blocks our quick start doc about seed node example merged yesterday. But first I will go the way you explained, disable seedMode on the seed peer as a workaround. Thank you for the clarification (and I will quote you in the doc :thumbsup: )

silasdavis (Tue, 09 Oct 2018 14:37:15 GMT):
Just reviewed your dynamic stack stuff

silasdavis (Tue, 09 Oct 2018 14:37:20 GMT):
have one remark but basically LGTM

silasdavis (Tue, 09 Oct 2018 14:38:15 GMT):
hm just looking at that issue

silasdavis (Tue, 09 Oct 2018 14:38:31 GMT):
I feel like there a re few bugs kicking around pexreator in seed/persistent modes

silasdavis (Tue, 09 Oct 2018 14:38:38 GMT):
looks like they are getting seen to

phymbert (Tue, 09 Oct 2018 14:39:40 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=vKhdEms8BonbTz96v) @silasdavis Understood, I think it is in the continuity of the recent issue described by @compleatang #933 . For chain audit purpose, it is better to have a distinct transaction type and possibility to register non validator node in this store. If you are ok, I am welling to work on it.

phymbert (Tue, 09 Oct 2018 14:39:40 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=vKhdEms8BonbTz96v) @silasdavis Understood, I think it is in the continuity of the recent issue described by @compleatang # 933 . For chain audit purpose, it is better to have a distinct transaction type and possibility to register non validator node in this store. If you are ok, I am welling to work on it.

phymbert (Tue, 09 Oct 2018 14:40:49 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=FMRDNYfY76zLRgyki) @silasdavis More reactor you add before PEX reactor, more this issue may arrive. They need to implement StopGracefully and wait for all reactor to have finished to receive messages.

silasdavis (Tue, 09 Oct 2018 14:41:34 GMT):
that'd be fantastic!!

silasdavis (Tue, 09 Oct 2018 14:41:47 GMT):
and yes you are right natural to combine with #933

silasdavis (Tue, 09 Oct 2018 14:42:21 GMT):
I think the first thing to come up with would be the protobuf spec for the transaction type that contains the payload

silasdavis (Tue, 09 Oct 2018 14:42:54 GMT):
the other potential use we have for such a registry is providing a mechanism for binding off-chain keys (e.g. GPG keys) to on-chain keys

silasdavis (Tue, 09 Oct 2018 14:43:09 GMT):
however I don't want to over-complicate this too much at this stage

silasdavis (Tue, 09 Oct 2018 14:43:29 GMT):
My other slight concern about this is data accumulation

silasdavis (Tue, 09 Oct 2018 14:44:33 GMT):
we have been taking about supporting a few of these 'registration' use cases with a slight rework of the NameReg

silasdavis (Tue, 09 Oct 2018 14:44:49 GMT):
so it may make sense to consider it in that context

silasdavis (Tue, 09 Oct 2018 14:45:43 GMT):
in any case I think it would be a good idea to capture a short markdown document describing out approach - I'd like to start putting these type of documents under docs/adr (architecture decision record)

silasdavis (Tue, 09 Oct 2018 14:45:43 GMT):
in any case I think it would be a good idea to capture a short markdown document describing our approach - I'd like to start putting these type of documents under docs/adr (architecture decision record)

silasdavis (Tue, 09 Oct 2018 14:46:30 GMT):
if you're up for it then opening a WIP PR that just documents the registration payload we need to store, then we can work out the 'where' followed by the 'how'

phymbert (Tue, 09 Oct 2018 14:50:55 GMT):
OK I will start this way, good move. Thank you for your Review on dynamic stacks stuff, I will rework it first the soonest.

phymbert (Wed, 10 Oct 2018 09:21:08 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=QJbXou9Hnamhh2Fzr) @silasdavis Hello @silasdavis , I just read your suggestion about adr directory, I chose yesterday to go with EIPs like approach, it may sound ambitious, I think the process is mature enough to reuse it partially for Burrow. I have opened a PR for this change in the docs, feel free to tell if we need to simplify. IMHO The Burrow Improvement Proposals concept sounds good.

phymbert (Wed, 10 Oct 2018 09:21:46 GMT):
+initial version of BIP2 for IdentifyTx

silasdavis (Wed, 10 Oct 2018 09:31:13 GMT):
looks good, I'm not sure ADRs and EIPs have quite the same purpose on the face of it, though there is clearly overlap and I don't see why we can't fold both into a 'BIP' document/process

silasdavis (Wed, 10 Oct 2018 09:31:46 GMT):
EIPs do contain motivation but feels like they are more declarative and don't address options considered but not taken

silasdavis (Wed, 10 Oct 2018 09:31:54 GMT):
see for example: https://adr.github.io/madr/

silasdavis (Wed, 10 Oct 2018 09:32:03 GMT):
having said that I would rather not introduce a lot of busywork

silasdavis (Wed, 10 Oct 2018 09:32:33 GMT):
it looks like you have a decent template for the BIP - do you think you could add a template for the BIP either in that PR or another one?

silasdavis (Wed, 10 Oct 2018 09:33:01 GMT):
we don't need to settle on the exact structure before we merge that one though

silasdavis (Wed, 10 Oct 2018 09:33:34 GMT):
I'll get round to reviewing the identify BIP before then

silasdavis (Wed, 10 Oct 2018 09:35:25 GMT):
one think I would like to differently to the EIPs of the bat though is to include both an index number and short text moniker in the file name, like `bip-2-identify-tx.md` or `bip-2_identify-tx.md` if that isn't too ugly

silasdavis (Wed, 10 Oct 2018 09:35:42 GMT):
`bip002-identify-tx.md` maybe

silasdavis (Wed, 10 Oct 2018 09:36:03 GMT):
`bip_002-identify-tx.md`

silasdavis (Wed, 10 Oct 2018 09:36:13 GMT):
bike sheds anyone :)

silasdavis (Wed, 10 Oct 2018 09:36:51 GMT):
but anyway it makes them easier to browse if they have a little descriptive moniker I think

phymbert (Wed, 10 Oct 2018 10:33:00 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=iZmq8gp7QL57c5xeD) @silasdavis I did that in a distinct PR, to introduce BIPs:

phymbert (Wed, 10 Oct 2018 10:33:36 GMT):
https://github.com/hyperledger/burrow/pull/935

phymbert (Wed, 10 Oct 2018 10:34:04 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=FqTZ8D2ccY8MWaQSw) @silasdavis Definitely understood & agreed

phymbert (Wed, 10 Oct 2018 10:36:52 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=i33eRSSBXSWGfzeCo) @silasdavis I have added the Motivation chapter for that purpose in the bip-X.md template. Yes the idea is to have a simple process that fits our need, let's change and adjust it later if you are ok ?

phymbert (Wed, 10 Oct 2018 10:37:29 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=XDjY7b4gGW6jQk5DS) @silasdavis I didn't know that approach, I will read it, thank you

silasdavis (Thu, 11 Oct 2018 15:03:02 GMT):
Great thanks @phymbert, I'm just working on some STATICCALL stuff on a branch and improving our error handling/surfacing a bit, then will get to your PRs

phymbert (Thu, 11 Oct 2018 17:01:35 GMT):
no hurry for sure, thank you

totolouis (Thu, 11 Oct 2018 17:30:52 GMT):
Has joined the channel.

phymbert (Fri, 12 Oct 2018 10:18:05 GMT):
https://github.com/hyperledger/burrow/blob/develop/docs/PROPOSALS.md

phymbert (Fri, 12 Oct 2018 10:18:17 GMT):
😀😀😀

phymbert (Fri, 12 Oct 2018 10:18:49 GMT):
Welcome to the BIPs authors ^^

compleatang (Fri, 12 Oct 2018 22:42:20 GMT):
:tada:

manuvarghese (Mon, 15 Oct 2018 23:05:41 GMT):
Has joined the channel.

karthikmohan91 (Thu, 18 Oct 2018 04:48:25 GMT):
Has joined the channel.

devlintrace (Fri, 19 Oct 2018 18:40:13 GMT):
Has joined the channel.

Abdul_khaliq (Sun, 21 Oct 2018 10:36:14 GMT):
Has joined the channel.

Abdul_khaliq (Sun, 21 Oct 2018 10:36:21 GMT):
hello everyone

Abdul_khaliq (Sun, 21 Oct 2018 10:41:17 GMT):
new to hyperledger can anyone suggest me the best framework for python language

silasdavis (Sun, 21 Oct 2018 11:36:03 GMT):
@Abdul_khaliq I see if you've cross-posted this in general - it would be better to wait for a reply there rather than send to multiple channels - this channel is for contributors to Burrow. But seeing as you are new, we'll let you off :) Both Fabric and Sawtooth have python SDK support for smart contracts. Burrow does not have any prepackaged libraries for that but our interfaces are GRPC. If you have any further end user questions about Burrow please direct them to #burrow

Abdul_khaliq (Sun, 21 Oct 2018 11:55:21 GMT):
@silasdavis thank you

carlosfaria (Mon, 22 Oct 2018 20:29:50 GMT):
Has joined the channel.

Mr.Reddington (Fri, 26 Oct 2018 09:56:43 GMT):
Has joined the channel.

AnkitDroidGit (Thu, 01 Nov 2018 09:12:25 GMT):
Has joined the channel.

rorochan (Tue, 06 Nov 2018 06:31:33 GMT):
Has joined the channel.

tkuhrt (Tue, 13 Nov 2018 18:41:49 GMT):
FYI, the TSC Quarterly Project update is overdue.

silasdavis (Fri, 16 Nov 2018 13:36:41 GMT):
thanks for reminder - I bailed on the update because of my voice, not that that's a reason to hold up the written document - I'll submit next week for review the week after since there is no TSC next week

tkuhrt (Fri, 16 Nov 2018 16:54:20 GMT):
Thanks, @silasdavis

dev-d (Wed, 21 Nov 2018 10:41:33 GMT):
Has joined the channel.

KirkWallace (Sun, 25 Nov 2018 17:14:23 GMT):
Has joined the channel.

bd (Tue, 27 Nov 2018 15:15:48 GMT):
Has joined the channel.

phymbert (Mon, 10 Dec 2018 06:45:14 GMT):
Hello team, I have fighted a lot this weekend to interract with smartcontract function from golang transactor+abi. I would suggest to make it more convenient, example: user declares a go interface and a new api provides in one method the good implementation targetting transactor.CallSim or CallTx. All this evm types to go type nightmare should be hidden

sly514 (Mon, 10 Dec 2018 15:23:47 GMT):
Has joined the channel.

compleatang (Mon, 10 Dec 2018 23:36:24 GMT):
been fighting that fight for years @phymbert I feel your pain so deeply!

compleatang (Mon, 10 Dec 2018 23:37:05 GMT):
the start of that is this -> https://github.com/hyperledger/burrow/issues/858

bd (Thu, 13 Dec 2018 09:34:02 GMT):
hi folks, i try debug on vscode the burrow code but how i can passing config to burrow adding 'chain_dir' folder?

bd (Thu, 13 Dec 2018 09:34:09 GMT):
`{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [{ "name": "Launch", "type": "go", "request": "launch", "mode": "debug", "program": "${workspaceRoot}/cmd/burrow/main.go", "env": { "GOPATH": "/home/bd/gocode" }, "args": ["start", "--validator-address=A388CE800DAB14B9362FC44A8F217F169C3DA3A9"], "showLog": true }] } `

bd (Thu, 13 Dec 2018 09:34:22 GMT):
this is my .launch.json of vscode

bd (Thu, 13 Dec 2018 09:34:53 GMT):
i have this error.

bd (Thu, 13 Dec 2018 09:34:59 GMT):
`Sourcing config from first of: defaults Sourcing config from defaults Using validator address: A388CE800DAB14B9362FC44A8F217F169C3DA3A9 could not create Burrow kernel: no GenesisDoc defined in config, cannot make Kernel`

bd (Thu, 13 Dec 2018 09:35:51 GMT):
i need to pass main.go to run debug, but on this config the burrow is not executed on chain_dir

bd (Thu, 13 Dec 2018 09:36:09 GMT):
any suggestions please?

bd (Thu, 13 Dec 2018 09:37:13 GMT):
i have stucked for one day... :pensive:

bd (Thu, 13 Dec 2018 09:44:12 GMT):
what is the config file ?

bd (Thu, 13 Dec 2018 09:44:21 GMT):
burrow.toml ?

bd (Thu, 13 Dec 2018 09:44:50 GMT):
what i need to change to work outside of chain_dir

bd (Thu, 13 Dec 2018 09:45:08 GMT):
or what the methods for debug burrow

bd (Thu, 13 Dec 2018 09:45:08 GMT):
or what is the methods for debug burrow

bd (Thu, 13 Dec 2018 12:20:38 GMT):
ja consegui executar o debug! :tada:

bd (Thu, 13 Dec 2018 12:20:38 GMT):
I already managed to run the debug! :tada:

bd (Thu, 13 Dec 2018 12:21:10 GMT):
thx for the help

bd (Thu, 13 Dec 2018 12:21:12 GMT):
:D

bd (Thu, 13 Dec 2018 12:21:54 GMT):
:laughing:

bd (Thu, 13 Dec 2018 12:22:18 GMT):
#alone

phymbert (Thu, 13 Dec 2018 12:36:23 GMT):
Hello @bd, please try the tutorial on how to steup a burrow network: https://github.com/hyperledger/burrow/blob/develop/docs/quickstart/single-full-node.md Then you may try to wrap it in your own GoLang code (doc is coming) #neveralone :)

bd (Thu, 13 Dec 2018 13:01:17 GMT):
:sweat_smile:

bd (Thu, 13 Dec 2018 15:03:30 GMT):
if there is any more documentation than exists in the git repo, it should be available. even if it was disorganized! as ultra beta documentation :D right? maybe some information is more useful than nothing!

phymbert (Thu, 13 Dec 2018 15:32:10 GMT):
The code base is self documented here: https://godoc.org/github.com/hyperledger/burrow/rpc

bd (Thu, 13 Dec 2018 15:33:18 GMT):
ok

bd (Thu, 13 Dec 2018 15:33:32 GMT):
this link exsit on git hub Readme?

bd (Thu, 13 Dec 2018 15:33:32 GMT):
this link exist on github Readme?

phymbert (Thu, 13 Dec 2018 15:36:13 GMT):
yes

bd (Thu, 13 Dec 2018 15:38:46 GMT):
ok :D

bd (Thu, 13 Dec 2018 15:49:57 GMT):
exist any way on Snative contract call one method of other Smart Contract?

bd (Thu, 13 Dec 2018 15:50:53 GMT):
like SC_A -> call method of SnativeX -> call method of SC_B -> return data to SC_A

bd (Thu, 13 Dec 2018 15:50:53 GMT):
like SC_A -> call method of SnativeX -> call method of SC_B -> return data or make some changes on storage

bd (Thu, 13 Dec 2018 15:50:53 GMT):
like SC_A -> call method of SnativeX -> call method of SC_B -> return data or make some changes on storage of B

Abhinavgrg074 (Fri, 14 Dec 2018 06:13:14 GMT):
Has joined the channel.

bd (Fri, 14 Dec 2018 11:32:53 GMT):
hi

bd (Fri, 14 Dec 2018 11:33:13 GMT):
i'm working on one solution like truffle for burrow.js

bd (Fri, 14 Dec 2018 11:33:27 GMT):
and i get some issues like

bd (Fri, 14 Dec 2018 11:34:10 GMT):
` const accountToCheck = '0x0694A27F6B8B92902CBCEA272946E57FF8A2CF7D'; const initialBalance = await this.burrow.query.GetAccount(Buffer.from(accountToCheck, 'hex')); console.log('\n\n\n initialBalance', initialBalance); `

bd (Fri, 14 Dec 2018 11:34:27 GMT):
so for get the account balance i put this

bd (Fri, 14 Dec 2018 11:34:30 GMT):
and the result is

bd (Fri, 14 Dec 2018 11:34:41 GMT):
` initialBalance { Address: , PublicKey: { CurveType: 0, PublicKey: }, Sequence: '0', Balance: '1337', Code: , Permissions: { Base: { Perms: '16862', SetBit: '131071' }, Roles: [] } } `

bd (Fri, 14 Dec 2018 11:35:11 GMT):
the account balance using burrow deploy getBalance.yaml is 10

bd (Fri, 14 Dec 2018 11:35:25 GMT):
beacause i send 10 to this 0x0694A27F6B8B92902CBCEA272946E57FF8A2CF7D account

bd (Fri, 14 Dec 2018 11:35:38 GMT):
why Balance is 1337 ?

bd (Fri, 14 Dec 2018 11:35:51 GMT):
https://github.com/hyperledger/burrow/blob/develop/execution/state.go#L155

bd (Fri, 14 Dec 2018 11:36:11 GMT):
@silasdavis can help on this please ?

bd (Fri, 14 Dec 2018 11:46:36 GMT):
it's christmas time!!! please

bd (Fri, 14 Dec 2018 11:46:40 GMT):
:-)

bd (Fri, 14 Dec 2018 12:49:53 GMT):
anyone can help i mean! :sweat_smile:

silasdavis (Fri, 14 Dec 2018 14:37:51 GMT):
@bd please don't cross-post to contributors if it doesn't relate to burrow contrib - I will get to questions when I can in #burrow

bd (Fri, 14 Dec 2018 14:38:07 GMT):
ok thx

mslavitch (Tue, 18 Dec 2018 15:39:04 GMT):
Has joined the channel.

merq (Sun, 23 Dec 2018 03:32:46 GMT):
Has joined the channel.

rjones (Sun, 30 Dec 2018 05:08:22 GMT):
Has left the channel.

saranshj07 (Sun, 30 Dec 2018 23:27:27 GMT):
Has joined the channel.

silasdavis (Fri, 04 Jan 2019 16:36:31 GMT):
Hope you had a good Christmas/New Year @phymbert

silasdavis (Fri, 04 Jan 2019 16:40:40 GMT):
I just wanted to mention that I've given the identify tx proposal some thought along the lines I sketched out in person in Basel. What I'd like to do is build the ideas there into a unified system that handles: - Authorisation (allowed to sync - via account permission) - Introduction (here is my node key, name, signed by my public key) - Bonding/unbonding (I have some token, and I am permitted to validate with it, and I'm online) I don't have a complete design, but I have some things I could describe that might constrain a design and I want to put them in an updated RFC

silasdavis (Fri, 04 Jan 2019 16:41:48 GMT):
I probably need to finish up some work now on merging our vent and burrow.js repos into Burrow as well as finishing up dump/restore work before I'll have a chance to write it down - though frankly if you have time soon I can make time

silasdavis (Fri, 04 Jan 2019 16:42:10 GMT):
but if you are up for it then I think you could complete the design and implement this

silasdavis (Fri, 04 Jan 2019 16:42:32 GMT):
down the line I think it can allow for some quite powerful ways of forming networks and dealing with single-authority-managed validator pools

phymbert (Fri, 04 Jan 2019 18:26:03 GMT):
Hello @silasdavis , thank you, I wish you all an happy new _Burrow_ year. I am exciting to continue this task, about that unified authority system : _Remind tendermint abci query peer filter provides only 2 params to burrow: peer node net address and ID (node key) _ 1) Authorization: allowed to sync via account permission: It means we have a map/registery maintained by who ? 2) IntroductionTx ? of (node_key, net address, account address) If we enable this feature, `burrow config` binary should be able to serialize it to `burrow.toml` in order to let validator nodes to sync. 2) Introduction (here is my node key, name, signed by my public key) OK, node needs to be allowed to sync first, or this Tx can be sent from an already trusted peer, BUT we first need to have the new node tendermint keys pair generated, or be able to generate/managed it from `burrow config` binary 3) Bonding/unbonding (I have some token, and I am permitted to validate with it, and I'm online) Yet to see a working unit/integration test that make it clear that governance.AlterPowerTx actually works with 2/3 validators nodes + The "and I m online" is definitely an interresting use case, but yet I dont know how it integrates with tendermint validators set, need to check I think the easiest way for me is to start with coding IntroductionTx (or IdentityTx/IdentifyTx/PeerTx), document it in the BIPs/WIPs and check again together, also I will add a simple unit test for AlterPowerTx with 3 tendermint peers. Am I on the right way ?

phymbert (Fri, 04 Jan 2019 18:26:03 GMT):
Hello @silasdavis , thank you, I wish you all an happy new _Burrow_ year. I am excited to continue this task, about that unified authority system : _Remind tendermint abci query peer filter provides only 2 params to burrow: peer node net address and ID (node key) _ 1) Authorization: allowed to sync via account permission: It means we have a map/registery maintained by who ? 2) IntroductionTx ? of (node_key, net address, account address) If we enable this feature, `burrow config` binary should be able to serialize it to `burrow.toml` in order to let validator nodes to sync. 2) Introduction (here is my node key, name, signed by my public key) OK, node needs to be allowed to sync first, or this Tx can be sent from an already trusted peer, BUT we first need to have the new node tendermint keys pair generated, or be able to generate/managed it from `burrow config` binary 3) Bonding/unbonding (I have some token, and I am permitted to validate with it, and I'm online) Yet to see a working unit/integration test that make it clear that governance.AlterPowerTx actually works with 2/3 validators nodes + The "and I m online" is definitely an interresting use case, but yet I dont know how it integrates with tendermint validators set, need to check I think the easiest way for me is to start with coding IntroductionTx (or IdentityTx/IdentifyTx/PeerTx), document it in the BIPs/WIPs and check again together, also I will add a simple unit test for AlterPowerTx with 3 tendermint peers. Am I on the right way ?

silasdavis (Wed, 09 Jan 2019 10:44:04 GMT):
yes I think so, finishing off some sprint planning today, let me share some output from that with you after

silasdavis (Tue, 15 Jan 2019 14:42:49 GMT):
@phymbert just to let you know I didn't manage to get design work on the introduction stuff into our current sprint (running until 25 January). The questions you are ask are good but I don't want to get too distracted thinking about them, and I'd rather give more carefully considered responses in design doc. I also don't to hold you back so if you feel you have time to update the IdentifyTx BIP and rename (to rfx/introduction or something like that) then that would be useful work. I'll make a task for next sprint to try and give everything you would need to work on it...

silasdavis (Thu, 24 Jan 2019 14:17:51 GMT):
@phymbert not sure if you have any time, but while I get my arse in gear do you have any interest in tackling: https://github.com/hyperledger/burrow/issues/866

silasdavis (Thu, 24 Jan 2019 14:18:06 GMT):
it would be really nice to have a nice terminal logging output and to clean up our logging story in general

phymbert (Tue, 29 Jan 2019 18:45:53 GMT):
[ ](https://chat.hyperledger.org/channel/burrow-contributors?msg=syzHaQwPhAeFouHHW) @silasdavis @silasdavis my apologies to answer late, console output is always a nice journey, will have a look this weekend

VtpVlan-oo7 (Fri, 08 Feb 2019 09:35:52 GMT):
Has joined the channel.

Spar (Mon, 11 Feb 2019 14:53:02 GMT):
Has joined the channel.

Spar (Mon, 11 Feb 2019 14:58:39 GMT):
Hi, I'll help out on issue 866. I'm learning go and I have some blockchain knowledge and its time for me to start building things.

silasdavis (Mon, 11 Feb 2019 21:31:45 GMT):
Sounds great, it would be good to seek some assistance from our maintainer @phymbert who will be able to get you on the right tracks

silasdavis (Mon, 11 Feb 2019 21:32:10 GMT):
@phymbert a bug worth looking at (and probably interesting) is: https://github.com/hyperledger/burrow/issues/1011

tiennv (Tue, 12 Feb 2019 04:43:19 GMT):
Has joined the channel.

phymbert (Tue, 12 Feb 2019 07:00:27 GMT):
Hi @Spar welcome, ping me if you have question.

phymbert (Fri, 22 Feb 2019 06:35:13 GMT):
Guys, my congratulations for the first Monax public beta release! Hoping Burrow will have its 1.0.0.RC1 soon, good luck

compleatang (Fri, 22 Feb 2019 10:05:55 GMT):
thanks! with Tendermint nearing it's 1.0 personally I'm excited about getting burrow there too....

bjwswang (Tue, 05 Mar 2019 06:44:22 GMT):
Has joined the channel.

meet.s (Thu, 07 Mar 2019 12:45:29 GMT):
Has joined the channel.

gWOLF3 (Thu, 21 Mar 2019 18:14:42 GMT):
Has joined the channel.

Behzad 2 (Thu, 04 Apr 2019 10:19:46 GMT):
Has joined the channel.

Behzad 2 (Fri, 05 Apr 2019 22:00:18 GMT):
Hi, is there any walkthrough to build burrow from source?``` What I have done: ```

KarlKneis (Tue, 14 May 2019 04:16:57 GMT):
Has joined the channel.

Consultant1bcg (Sat, 20 Jul 2019 04:44:53 GMT):
Has joined the channel.

amundson (Tue, 06 Aug 2019 15:51:23 GMT):
Has left the channel.

silasdavis (Thu, 29 Aug 2019 15:06:01 GMT):
@KellyCooper https://hyperledger.github.io/burrow/#/

KellyCooper (Thu, 29 Aug 2019 15:06:01 GMT):
Has joined the channel.

silasdavis (Thu, 29 Aug 2019 15:06:33 GMT):
https://github.com/knkski/burrow/tree/develop/docs

gregdhill (Thu, 29 Aug 2019 15:11:50 GMT):
http://hyperledger.github.io/burrow/#/tutorials/4-multiple-validators

silasdavis (Thu, 29 Aug 2019 15:24:51 GMT):
https://docs.google.com/presentation/d/12R1eB1YoXc1k6dGYu9LoGYHYGVPZ6aRltrmshDWRPvM/edit?usp=sharing

KellyCooper (Fri, 06 Sep 2019 15:58:39 GMT):
@silasdavis are you thinking to submit Burrow for the global forum? Submissions are due 9/27.

silasdavis (Tue, 10 Sep 2019 15:52:10 GMT):
Thanks for heads up

silasdavis (Tue, 10 Sep 2019 15:54:34 GMT):
Not sure, didn't realise deadline so early

KellyCooper (Mon, 16 Sep 2019 15:30:05 GMT):
@silasdavis I spent last week and this week reviewing related skills I haven't worked with for awhile. Still here.

silasdavis (Mon, 16 Sep 2019 15:33:53 GMT):
I've been switching around tasks a bit. I have quite a few extra docs to publish. I'll let you know when that is complete so you can review

KellyCooper (Mon, 16 Sep 2019 15:36:27 GMT):
@silasdavis Sounds good.

KellyCooper (Fri, 20 Sep 2019 15:31:30 GMT):
In the Public Sector SIG I am working on a use case for grants management (NSF and other grants organizations). We are submitting to present at the Global Forum and I will create a PoC with Burrow for the talk. I will document this use case for onboarding Burrow developers.

compleatang (Tue, 24 Sep 2019 09:51:39 GMT):
:burrow:

compleatang (Tue, 24 Sep 2019 09:51:41 GMT):
neat.

nathalie-ckc (Fri, 15 Nov 2019 06:33:35 GMT):
Has joined the channel.

nathalie-ckc (Mon, 02 Dec 2019 06:18:30 GMT):
Has left the channel.

rjones (Thu, 19 Dec 2019 17:39:14 GMT):
Has joined the channel.

rjones (Thu, 19 Dec 2019 17:39:15 GMT):
Howdy - I got a ping from GitHub that you are or were using old macOS 10.14 images as part of your GitHub Actions. I don't see them in there - but that support is or has ended so, if you want to use them in the future, please use macOS-latest.

rjones (Thu, 19 Dec 2019 17:39:18 GMT):
```GitHub Actions has deprecated the macOS-10.14 virtual environment. Workflows will instead use macOS-10.15 until January 15th, when workflow files must be updated to continue to run.```

compleatang (Fri, 20 Dec 2019 11:35:37 GMT):
thanks Ry.

compleatang (Fri, 20 Dec 2019 11:37:03 GMT):
I've looked through all the burrow workflows here -> https://github.com/hyperledger/burrow/tree/master/.github and we don't use any osx images in `runs-on` fields.

rjones (Fri, 20 Dec 2019 14:14:07 GMT):
I was confused by the report: it said it was used in the last 7 days, but none of those files have been touched in that timeframe.

KellyCooper (Fri, 20 Dec 2019 18:28:12 GMT):
@silasdavis @compleatang Checking in to make sure you received the Global Forum presentation approval materials.

compleatang (Mon, 06 Jan 2020 22:50:22 GMT):
strange. in any event guess it'll be ok...

strongwares (Tue, 14 Jan 2020 21:51:39 GMT):
Has joined the channel.

rjones (Wed, 22 Jan 2020 23:51:30 GMT):
@silasdavis @gregdhill you both should have invites to join the Hyperledger org at npm. Once you do, I'll add you to the burrow package group

silasdavis (Tue, 28 Jan 2020 17:25:13 GMT):
@rjones greg should have responded, I couldn't add him myself though

rjones (Tue, 28 Jan 2020 19:51:29 GMT):
He’s added. The NPM interface sucks

silasdavis (Wed, 29 Jan 2020 10:51:48 GMT):
thanks, npm kinda sucks, I recently found your unanswered suggestion of using github packages directly... I will reply to that

rjones (Wed, 29 Jan 2020 16:14:20 GMT):
yeah, GitHub actions publishing to GitHub packages is a builtin. Super easy

rjones (Wed, 29 Jan 2020 17:09:15 GMT):
gregdhill

rjones (Wed, 29 Jan 2020 17:10:39 GMT):
@silasdavis I don't remember where I mentioned that - where was it?

rjones (Wed, 29 Jan 2020 17:19:22 GMT):
Found it.

rjones (Wed, 29 Jan 2020 19:06:52 GMT):
@silasdavis take a look at https://github.com/hyperledger/burrow/pull/1327/files - this is the default GitHub action

silasdavis (Thu, 30 Jan 2020 15:06:08 GMT):
will do ta

rjones (Thu, 30 Jan 2020 15:07:06 GMT):
I can create and add a token to your repo

jramps9 (Tue, 07 Apr 2020 15:52:38 GMT):
Has joined the channel.

jramps9 (Tue, 07 Apr 2020 15:52:39 GMT):
Hello Burrow contributors! Friendly reminder to pls join us for the Marketing Committee-DevRel call tomorrow, 4/8 at 9am PT. This is a great opportunity to learn how you can get involved in many aspects of Hyperledger marketing including overall messaging, events, content, social media, PR etc. Feel free to add items to the agenda: https://wiki.hyperledger.org/x/_QjcAQ Hope to see you there :slight_smile:

dshe (Mon, 13 Apr 2020 14:55:22 GMT):
Has joined the channel.

silasdavis (Mon, 13 Apr 2020 15:16:44 GMT):
Hello @dshe, are you around?

dshe (Mon, 13 Apr 2020 15:17:13 GMT):
Hi @silasdavis I'm here. :)

silasdavis (Mon, 13 Apr 2020 15:17:20 GMT):
nice to meet you :)

silasdavis (Mon, 13 Apr 2020 15:17:31 GMT):
I just wanted to check you saw my most recent root comment on your PR

dshe (Mon, 13 Apr 2020 15:17:45 GMT):
Nice to meet you too!

dshe (Mon, 13 Apr 2020 15:18:13 GMT):
Yeah I'll take a look at the bitmap and work on it.

silasdavis (Mon, 13 Apr 2020 15:20:44 GMT):
Let me push some scaffold to a branch

silasdavis (Mon, 13 Apr 2020 15:20:54 GMT):
we use gogoproto to generate the account type

silasdavis (Mon, 13 Apr 2020 15:21:09 GMT):
then if you are willing you can just do the interesting/time-consuming part!

dshe (Mon, 13 Apr 2020 15:22:31 GMT):
Currently I have something urgent to work on. Do you mind if I do it after finishing my other work?

silasdavis (Mon, 13 Apr 2020 15:24:05 GMT):
I am delighted if you spend any time on it any time of your choosing, of course!

silasdavis (Mon, 13 Apr 2020 15:24:15 GMT):
also that gives me time just to get this groundwork done for you

dshe (Mon, 13 Apr 2020 15:24:44 GMT):
Sure, thanks!

silasdavis (Mon, 13 Apr 2020 17:11:23 GMT):
@dshe here is some prep for your work: https://github.com/hyperledger/burrow/pull/1369/commits/9630cf7038fbbb93bc0fbda2a086b9fc66da201a

silasdavis (Mon, 13 Apr 2020 17:11:29 GMT):
hopefully we can get it merged into master soon

silasdavis (Mon, 13 Apr 2020 17:11:33 GMT):
then you can rebase your PR on that

silasdavis (Mon, 13 Apr 2020 17:12:07 GMT):
I've added a stub table test which from which you can implement and remove `t.skip`

silasdavis (Mon, 13 Apr 2020 17:13:14 GMT):
once you write the init code for `OpcodeBitset` you'll just be able to write `account.OpcodeBitset.Set(n)` to see if the code symbol at n is an opcode and not data and use that to test if the `JUMPDEST` is real

silasdavis (Mon, 13 Apr 2020 17:26:14 GMT):
actually I've implemented the OpcodeBitset code, it could use some more tests but just remains to make use of it

dshe (Mon, 13 Apr 2020 17:28:01 GMT):
Great! :thumbsup:

manuvarghese (Wed, 15 Apr 2020 03:24:15 GMT):
Has left the channel.

jramps9 (Wed, 13 May 2020 12:12:05 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY, 5/13! Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-05-13+Meeting+notes

jramps9 (Tue, 09 Jun 2020 15:53:28 GMT):
Hi Burrow contributors! Reminder the Marketing Committee-Dev Relations call is tomorrow, 6/10 at 9am PT. Hope to see you there! https://wiki.hyperledger.org/display/Marketing/2020-06-010+Meeting+notes

jramps9 (Tue, 11 Aug 2020 00:09:31 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT this Weds 8/12. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-08-12+Meeting+notes

jramps9 (Mon, 14 Sep 2020 17:35:39 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 9/16 this week. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-09-16+Meeting+notes

nkl199 (Tue, 15 Sep 2020 09:12:53 GMT):
Has joined the channel.

nkl199 (Tue, 15 Sep 2020 09:12:53 GMT):
Hi Burrow contributors - nick here from caliper-contributors. You may/may not be aware that the main remit of Caliper is to permit people to performance test different Hyperledger technologies. We're reaching the point where we need to reach out and ask for assistance in keeping "connectors" up to date and working with the main project as it moves forwards. Unfortunately Burrow is one of the connectors we are in the position to have to remove if we cannot raise interest in helping us maintain it, simply due to a lack of in-house experience with Burrow our side. Is anyone here willing to help us get the Burrow connector into a working state and be a point of contact moving forwards? Fell free to reply here, in the caliper-contributors channel, or even via a PM. Cheers

silasdavis (Thu, 01 Oct 2020 14:37:19 GMT):
@gregdhill any thoughts?

gregdhill (Mon, 05 Oct 2020 16:12:25 GMT):
Unfortunately I do not have the capacity to update the adapter, I also have no reason to believe anyone will miss it...

jramps9 (Wed, 14 Oct 2020 14:08:05 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-10-14+Meeting+notes

jramps9 (Thu, 29 Oct 2020 13:53:29 GMT):
Hello! we're low on project news and updates for the dev/weekly newsletter going out tomorrow 10/30. If there's anything you'd like to suggest, please do so in the comments here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=41584474

jramps9 (Mon, 09 Nov 2020 18:12:56 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 11/11 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-11-11+Meeting+notes

Helen_Garneau (Fri, 12 Feb 2021 13:57:01 GMT):
Has joined the channel.

rjones (Wed, 17 Feb 2021 19:23:36 GMT):
Hi, @silasdavis: I'm updating the `maintainers` email list, and the address for Greg Hill bounces. ```$ grep -R hill hyperledger/* hyperledger/burrow/MAINTAINERS.md:| Greg Hill | gregdhill | ```

gregdhill (Thu, 18 Feb 2021 16:32:13 GMT):
@rjones please use my personal email for this: `gregorydhill@outlook.com`

rjones (Thu, 18 Feb 2021 17:33:20 GMT):
@gregdhill invite sent.

nkl199 (Wed, 10 Mar 2021 13:01:17 GMT):
Has left the channel.

Helen_Garneau (Wed, 10 Mar 2021 14:43:42 GMT):
Hello Burrow contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT today. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/x/Nqx6Ag

Helen_Garneau (Wed, 10 Mar 2021 14:44:24 GMT):
(Please note new zoom info!)

silasdavis (Thu, 25 Mar 2021 14:58:05 GMT):
@seanyoung could you merge: https://github.com/hyperledger/burrow/pull/1470

seanyoung (Thu, 25 Mar 2021 16:24:57 GMT):
@silasdavis sorry I was in the crawl space under my house

silasdavis (Fri, 26 Mar 2021 12:59:12 GMT):
Haha of course you were. Sounds like you got out 👍 what you doing building a cellar?

seanyoung (Sun, 28 Mar 2021 21:57:30 GMT):
I'm putting a new wooden floor in downstairs, and I wanted to check if the joist etc were all sound.

iamsdas (Wed, 09 Jun 2021 19:58:56 GMT):
Has joined the channel.

kaushambi (Fri, 20 Aug 2021 13:58:47 GMT):
Has joined the channel.

sashankh (Fri, 27 Aug 2021 19:01:21 GMT):
Has joined the channel.

rjones (Fri, 11 Feb 2022 22:09:45 GMT):
chat has moved to https://discord.gg/hyperledger/

rjones (Wed, 23 Mar 2022 17:21:26 GMT):