cosmos / cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:

ToC

• Purpose
• Whitepaper
• Crowdfund Plan
• Faq
• Chat

Disambiguation

This Cosmos is not related to the React-Cosmos project (yet). Many thanks to Evan Coury and Ovidiu (@skidding) for this Github organization name. As per our initial agreement, this disambiguation notice will stay here.

cosmos-sdk's Issues

basecoin crash when no internet

I[06-08|09:10:56.734] Applying block                               module=consensus height=655
I[06-08|09:10:56.734] Applying block                               module=consensus height=656
I[06-08|09:10:56.735] Completed ABCI Handshake - Tendermint and App are synced module=consensus appHeight=0 appHash=
I[06-08|09:10:56.741] Starting EventSwitch                         module=types impl=EventSwitch
I[06-08|09:10:56.741] This node is a validator                     module=consensus 
I[06-08|09:10:56.748] Starting Node                                module=node impl=Node
I[06-08|09:10:56.749] Local listener                               module=p2p ip=:: port=46656
I[06-08|09:10:56.749] Getting UPNP external address                module=p2p
I[06-08|09:10:59.750] Could not perform UPNP discover              module=p2p error="write udp4 0.0.0.0:62196->239.255.255.250:1900: i/o timeout"
panic: Panicked on a Crisis: Could not determine external address!

goroutine 1 [running]:
github.com/tendermint/tmlibs/common.PanicCrisis(0x16ea940, 0xc4216ee3d0)
	/Users/garie/gocode/src/github.com/tendermint/tmlibs/common/errors.go:33 +0xdd
github.com/tendermint/tendermint/p2p.NewDefaultListener(0xc4204b0040, 0x3, 0xc4204b0046, 0xd, 0x1c89000, 0x1c89040, 0xc4207a45a0, 0xd, 0x17f65dc)
	/Users/garie/gocode/src/github.com/tendermint/tendermint/p2p/listener.go:93 +0x72f
github.com/tendermint/tendermint/node.(*Node).OnStart(0xc420442360, 0xc4216ee030, 0xd)
	/Users/garie/gocode/src/github.com/tendermint/tendermint/node/node.go:237 +0x1f5
github.com/tendermint/tmlibs/common.(*BaseService).Start(0xc420442360, 0xc42046c820, 0x1c7f740, 0xc4204b9040)
	/Users/garie/gocode/src/github.com/tendermint/tmlibs/common/service.go:105 +0x482
github.com/tendermint/basecoin/cmd/commands.startTendermint(0xc42012cc00, 0x16, 0xc420468f60, 0xc4204b8640, 0x2)
	/Users/garie/gocode/src/github.com/tendermint/basecoin/cmd/commands/start.go:154 +0x356
github.com/tendermint/basecoin/cmd/commands.startCmd(0x1ccc840, 0x1cf3b68, 0x0, 0x0, 0x0, 0x0)
	/Users/garie/gocode/src/github.com/tendermint/basecoin/cmd/commands/start.go:104 +0xc56
github.com/spf13/cobra.(*Command).execute(0x1ccc840, 0x1cf3b68, 0x0, 0x0, 0x1ccc840, 0x1cf3b68)
	/Users/garie/gocode/src/github.com/spf13/cobra/command.go:647 +0x3f8
github.com/spf13/cobra.(*Command).ExecuteC(0xc42007c6c0, 0x2, 0x2, 0xc42012cca0)
	/Users/garie/gocode/src/github.com/spf13/cobra/command.go:726 +0x339
github.com/spf13/cobra.(*Command).Execute(0xc42007c6c0, 0xc420460310, 0x16)
	/Users/garie/gocode/src/github.com/spf13/cobra/command.go:685 +0x2b
github.com/tendermint/tmlibs/cli.Executor.Execute(0xc42007c6c0, 0x17f5a0b, 0x2)
	/Users/garie/gocode/src/github.com/tendermint/tmlibs/cli/setup.go:92 +0x4e
main.main()
	/Users/garie/gocode/src/github.com/tendermint/basecoin/cmd/basecoin/main.go:33 +0x1c3

Use tendermint/light-client for IBC

ERROR: Expected either "info", "debug", "error" or "none" level, given state:info,*:error

branch: master

Basecoin is not a coin, but a framework

We should somehow make it clear that Basecoin itself is not a cryptocurrency.

Though, maybe it's a good idea to call some token "Basecoin".

not enough arguments in call to eyes.NewClient

Hi, when I try compile basecoin, I get these errors:

cmd/basecoin/main.go:23: not enough arguments in call to eyes.NewClient
cmd/basecoin/main.go:41: not enough arguments in call to server.NewServer

It can be fixed by adding in the transport parameter (socket | grpc) for those calls in main.go

Build issue

Tendermint and basecoin on the development branches:

make

go test `go list github.com/tendermint/basecoin/... | grep -v /vendor/`
cmd/basecoin/main.go:7:2: cannot find package "github.com/tendermint/basecoin/version" in any of:
        /root/.gvm/pkgsets/go1.8/global/src/github.com/tendermint/basecoin/vendor/github.com/tendermint/basecoin/version (vendor tree)
        /root/.gvm/gos/go1.8/src/github.com/tendermint/basecoin/version (from $GOROOT)
        /root/.gvm/pkgsets/go1.8/global/src/github.com/tendermint/basecoin/version (from $GOPATH)
Makefile:14: recipe for target 'test' failed
make: *** [test] Error 1

make install

go test `go list github.com/tendermint/basecoin/... | grep -v /vendor/`
cmd/basecoin/main.go:7:2: cannot find package "github.com/tendermint/basecoin/version" in any of:
        /root/.gvm/pkgsets/go1.8/global/src/github.com/tendermint/basecoin/vendor/github.com/tendermint/basecoin/version (vendor tree)
        /root/.gvm/gos/go1.8/src/github.com/tendermint/basecoin/version (from $GOROOT)
        /root/.gvm/pkgsets/go1.8/global/src/github.com/tendermint/basecoin/version (from $GOPATH)
Makefile:14: recipe for target 'test' failed
make: *** [test] Error 1

Had been working a week ago? Probably I am missing something insignificant that is blocking the build?

Rename /data folder to clarify tutorial

In the Basecoin Basics file, it says:

Now we need some initialization files for basecoin. We have included some defaults in the basecoin directory, under data. For purposes of convenience, change to that directory:

cd $GOPATH/src/github.com/tendermint/basecoin/data
The directory contains a genesis file and two private keys.

You can generate your own private keys with tendermint gen_validator, and construct the genesis.json as you like. Note, however, that you must be careful with the chain_id field, as every transaction must contain the correct chain_id (default is test_chain_id).

1. basecoin/data should probably be renamed to basecoin/example_dir or something that is more clear
2. basecoin/data/genesis.json can be renamed to basecoin/data/bc_genesis.json
3. Docs need to be clarified here.

This issue is dependent on #48

basecoin init returns error if already initialized

This has been resolved in the cli_cobra branch

Using custom genesis (and key) files

With the new simplify PR to develop we've moved all the genesis info into init command. I think it makes sense to be able to use custom genesis information for 3rd party basecoin apps. for instance currently I'd like to be able to use custom tokens for the paytovote basecoin app, but can initialize accounts from genesis to use custom coin types.

Maybe we could add a flag as a part of init that will load genesis from the current directory? It will need the ability to the remove the existing genesis... and will cause chain breakage if there is already a blockchain loaded, aka unsafe_reset_all should maybe be called if this flag is used as well

Make `StateKey` `stateKey`

No need to expose this outside the package.

But maybe clients want it because they need to know what to Query for?

Convert CLI to Cobra

If we want consistency, let's go for that.

Decision was made for Cobra in tendermint and the that was the better approach. Approved by bucky andr rigel.

Trader create escrow error

This is the error I get when I try to create escrow by running "# let's make an escrow
trader tx escrow create --chain_id trader_chain_id --from key.json --amount 400 --recv 2ABAA2CCFA1F618CF9C97F1FD59FC3EE4968FE8A --arbiter 4793A333846E5104C46DD9AB9A00E31821B2F301".

"Signed AppTx:............
BroadcastTxCommit got non-zero exit code: BaseInsufficientFunds. ; Error in CheckTx;in validateInputAdvanced();Error (base) insufficient funds"

May be being new to both Go and blockchain I'm missing out on something. Additionally when I check the receiver account I get :
"Account bytes are empty for address: 2ABAA2CCFA1F618CF9C97F1FD59FC3EE4968FE8A"

App.SetOption function types

I can't see any good reason for returning a string here instead of error, this string is mimicking error functionality
https://github.com/tendermint/basecoin/blob/master/app/app.go#L55

Also, I think it makes more for the value to be of type interface{} to allow it to be used as a string or a []byte array if being used to set an account, right now if you're setting the account value is parsed into a byte array from a string and then unmarshalled... seems unnecessary. Thoughts on either of these?

Update genesis.json to be embeddable in TM genesis file

1. Let's change from array to object. This:

[
  "base/chainID", "test_chain_1",
  "base/account", {
    "pub_key": [1, "B3588BDC92015ED3CDB6F57A86379E8C79A7111063610B7E625487C76496F4DF"],
    "coins": [
        {   
          "denom": "mycoin",
          "amount": 9007199254740992
        }   
    ]   
  }
]

becomes

{
  "base/chainID": "test_chain_1",
  "base/account": {
    "pub_key": [1, "B3588BDC92015ED3CDB6F57A86379E8C79A7111063610B7E625487C76496F4DF"],
    "coins": [
        {   
          "denom": "mycoin",
          "amount": 9007199254740992
        }   
    ]   
  }
}

2. Let's give it app/tendermint structure:

{
  "app": { ... },
  "tendermint": { ... }
}

so we can embed the tendermint genesis in the app genesis and only have one.

3. We need to do something about chain_id. They are specified separately in tendermint and app genesis objects. Do we let one overwrite the other? Remove one? Not sure what's right here yet.

test in tests/tendermint/main.go fails

Hi, running tests/tendermint/main.go does not work correctly.

On line 116 in github.com/tendermint/basecoin/app/app.go you have:
res = sm.ExecTx(app.cacheState, app.plugins, tx, true, nil)

The function is given the argument app.cacheState, but I dont think that cacheState is ever initialized.
Perhaps it should just be app.state?

key new cmd should return a json?

basecoin -v
basecoin version 0.3.1
basecoin key new
[123 10 9 34 97 100 100 114 101 115 115 34 58 32 34 54 57 49 98 102 48 101 99 56 99 57 102 57 102 53 97 100 57 50 101 102 52 52 50 49 102 56 102 101 100 97 98 98 99 100 9852 49 100 101 34 44 10 9 34 112 117 98 95 107 101 121 34 58 32 123 10 9 9 34 116 121 112 101 34 58 32 34 101 100 50 53 53 49 57 34 44 10 9 9 34 100 97 116 97 34 58 32 34 49 102 55 49 99 55 100 48 53 56 53 99 97 49 98 55 50 57 53 51 101 54 51 101 54 54 99 100 56 53 50 52 100 52 53 50 57 49 100 54 102 49 55 53 102 98 49 51 57 55 52 53 97 50 5154 56 55 54 101 50 102 101 56 34 10 9 125 44 10 9 34 112 114 105 118 95 107 101 121 34 58 32 123 10 9 9 34 116 121 112 101 34 58 32 34 101 100 50 53 53 49 57 34 44 10 9 9 34 100 97 116 97 34 58 32 34 100 50 51 50 102 51 102 101 49 51 49 102 98 48 48 49 51 51 56 49 49 53 56 57 97 98 99 102 50 54 102 56 98 50 57 48 98 52 50 57 56 49 57 97 101 54 100 101 56 50 98 102 50 98 52 48 51 49 101 48 99 50 99 53 49 102 55 49 99 55 100 4853 56 53 99 97 49 98 55 50 57 53 51 101 54 51 101 54 54 99 100 56 53 50 52 100 52 53 50 57 49 100 54 102 49 55 53 102 98 49 51 57 55 52 53 97 50 51 54 56 55 54 101 50 102 101 56 34 10 9 125 10 125]

Remove Cost from plugins, make them a Fee.

Review plugin architecture

I had a look at the code, and in general it makes sense. A special AppTx can set a byte (or later string?) to specify which plugin should handle it. After being verified and payment deducted by the basecoin system, the validated tx is passed to the registered plugin.

This allows us to add arbitrary tx processing with a plugin, without changing basecoin core code, just adding a plugin to the server and implementing the tx on the client.

Three issues, mostly minor.

In the current implementation, there is no way to override this in the constructor (eg. I cannot import basecoin and just init it with my special plugin). This would not be hard to change, but should be done. It is a private member and the only constructor I find is here:

func NewBasecoin(eyesCli *eyes.Client) *Basecoin {
	govMint := gov.NewGovernmint()
	state := sm.NewState(eyesCli)
	plugins := types.NewPlugins()
	plugins.RegisterPlugin(PluginTypeByteGov, PluginNameGov, govMint)
	return &Basecoin{
		eyesCli:    eyesCli,
		govMint:    govMint,
		state:      state,
		cacheState: nil,
		plugins:    plugins,
	}
}

Another issue is that the plugin cannot handle queries. Maybe this is not desired, but it may be nice to have some higher-level queries done by the plugin. But then maybe it would be unable to provide a merkle proof, and you only ever want to do queries by key. Again, this shouldn't be much work to change if it is wanted.

More questionable, is that, while the address that signed the original transaction is passed into the plugin as ctx and set in the cache
I don't see that this in any way limits the ability of the plugin to modify data from any account. Maybe I missed something. Maybe this is not needed. But it would be nice to understand the security implications of plugins. Do they have access to the entire data store and can modify anything they like? Or are they sandboxed in their own app-specific db? Or something in between?

Create egress packets and listening for incoming packets

Jae:

We're missing is a way for other plugins to initiate an egress packet.
We should just start with a test transaction called IBCTestTx which can be signed by anyone (at first). So any user can submit an IBCTestTx to save an egress Packet of any sort.

We're also missing a way for other plugins to handle incoming packets. How can another plugin, like the TokenTransferPlugin register to "listen" for incoming "coin" packets?

Remove tutorial dependency on Tendermint for Basecoin

Basecoin includes Tendermint, but in order to successfully follow the tutorials you still need to install Tendermint separately. We need to remove that dependency altogether so that a dev can just install Basecoin and not worry about installing Tendermint separately.

This will require importing the Tendermint CLI commands that are found here and exposing them as Basecoin CLI commands.

(Alternatively we could just automatically init Tendermint when we start Basecoin--tbd by whoever works on this issue).

We also need to make sure that the ~/.tendermint directory isn't being used by Basecoin.

Once this is done we'll have to also update the docs:
https://github.com/tendermint/basecoin/blob/develop/docs/guide/basecoin-basics.md

CheckTx shouldn't reference mid-block state

CheckTx references the current mid-block state and not the committed block state. Cachewrap is used but will still reference the underlying store as the mid-block state. Possible solutions include using copy of the state for checkTx instead cachewrap.

pseudocode to illustrate:

foo has 5 coins
bar has 0 coins
foo CheckTx 3 Coins to bar -> (passes as expected)
foo DeliverTx 3 Coins to bar -> (passes as expected)
foo CheckTx 3 Coins to bar -> (expected pass b/c uncommitted, actually fails)
CommitTx -> (passes as expected)
foo CheckTx 3 Coins to bar -> (fails as expected)

move GoBasics to the website

@ethanfrey awesome job here, but let's move it to the docs/guides section on the website and point to it from the various places (ie. from https://tendermint.com/docs/guides/install)

Coin.IsGTE bad logic

https://github.com/tendermint/basecoin/blob/master/types/coin.go#L96-L102

assumptions

• IsGTE means Greater Than Or Equal (>=)
• A wallet which contains only 0 of coin 'X' is equal to an empty wallet (AKA have zero of a coin is like not having any reference to that coin in your wallet)

Orig code:

func (coinsA Coins) IsGTE(coinsB Coins) bool {
	diff := coinsA.Minus(coinsB)
	if len(diff) == 0 {
		return true
	}
	return diff.IsPositive()
}

This function will incorrectly return false under the circumstance that coinA and coinB contain different coins but of an amount of zero. Under this circumstance diff != 0 because there are different coins, however diff.IsPositive() returns false because it's not positive it is zero. The fix is to simply replace diff.IsPositive() with diff.IsNonnegative()

basecli: allow tx args

It would be great to be able to add arguments to plugin txs defined within basecli. Not vital because we can always just define a new flag for what would normally be an arg, but it would be nice to implement this versatility eventually.

chain_id is DEPRECATED and will be removedin a future version. Use chain-id instead, but ERROR: unknown flag: --chain-id

Got error when I tried to use chain-id flag.

$    kubectl exec -c app tm-0 -- basecoin tx send --to "0x$ADDR" --amount 5mycoin --from /app/key.json --chain_id chain-tTH4mi
W0601 01:07:40.138730   51332 flags.go:39] chain_id is DEPRECATED and will be removedin a future version. Use chain-id instead.
W0601 01:07:40.139980   51332 flags.go:39] chain_id is DEPRECATED and will be removedin a future version. Use chain-id instead.
W0601 01:07:40.140027   51332 flags.go:39] chain_id is DEPRECATED and will be removedin a future version. Use chain-id instead.
Signed SendTx:
0100000000000000000104636F696E000000000000000001010114A677E98456071E3240EF0A2E0B80FFE7D36515BF010101066D79636F696E00000000000000050101010F0525B8D5E196201FFA12F430ED2417B2E464DD4D1D1456D740588B8BD60B9C766F8F47CF3E7ED37A9EF38207A13E4BE69897C898512A4A601821E3E88EBA0701793B7E33EF94132E16534CC9BA59F74944065FA917A98DB68ABA806D219A452901010114E2AFEA4A193E85A2DBB8668D4EA0DC0B1A6AD63A010101066D79636F696E0000000000000005
Response: 3B494E933D6B470DA651195BB3A3D299E4788CFA ;
bash-3.2$    kubectl exec -c app tm-0 -- basecoin tx send --to "0x$ADDR" --amount 5mycoin --from /app/key.json --chain-id chain-tTH4mi
ERROR: unknown flag: --chain-id

basecoin: 0.5.1
difficulty: easy

track height for queries

Query needs to return the height it's at but basecoin doesn't track height

genesis shouldnt care about pubkeys, just addrs

Document --chain_id better

Add unit tests for state/execution.go and app/app.go

still need tests for state/execution.go and app/app.go

How to find all tx that affect an account

Sure, if you send me tokens and also send me the tx hash out of bound, I can verify the tx.

Or if I poll all blocks, I can detect when I receive tokens.

But, if I just want to query for all tx on my account (send or receive) in the last 2 weeks?? How do I do this? Should this even be in the abci app/tendermint? Or do we rely on some non-trusted index, that we then verify? But that make censorship of proof of a tx too easy.

@ebuchman @rigelrozanski I'd love to hear some ideas here

Change AppTx to have "Type" field be of String type, not byte.

It's a few extra bytes per transaction, but I think the legibility is worth it.

unsafe_reset_all broken: height regression error

The following set of commands generate an error, where there shouldn't be one

rm -rf ~/.basecoin     ..........Work from a clean Dir
basecoin init
basecoin start
..............Wait for a few blocks to pass
<CTRL-C> .............. to stop basecoin
basecoin unsafe_reset_all
basecoin start

will cause the error on round 0

WARN[04-21|16:05:46] enterPrevote: ProposalBlock is nil       module=consensus
WARN[04-21|16:05:46] Error signing vote                       module=consensus height=1 round=0 vote="Vote{0:7A956FADD20D 1/00/1(Prevote) 000000000000 <nil>}" error="Error signing vote: Height regression"

Plugins: BeginBlock and EndBlock

We should probably make them match the 0.8.0 ABCI

genesis without app_options causes panic

genesis:

{
  "genesis_time":"2017-06-05T04:34:55Z",
  "chain_id":"up-n-comer",
  "app_hash":""
}

Response:

BCHOME=/var/lib/basecoin/.basecoin basecoin start --without-tendermint
no existing db, creating new db
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x5d17e2]

goroutine 1 [running]:
panic(0xae6680, 0xc42000e090)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/tendermint/basecoin/app.loadGenesis(0xc420474c90, 0x28, 0xaa8280, 0x1, 0xc420474cf0)
        /go/src/github.com/tendermint/basecoin/app/genesis.go:74 +0x122
github.com/tendermint/basecoin/app.(*Basecoin).LoadGenesis(0xc420474900, 0xc420474c90, 0x28, 0xc420056340, 0x0)
        /go/src/github.com/tendermint/basecoin/app/genesis.go:16 +0x50
github.com/tendermint/basecoin/cmd/commands.startCmd(0x109b260, 0xc42046b520, 0x0, 0x1, 0x0, 0x0)
        /go/src/github.com/tendermint/basecoin/cmd/commands/start.go:87 +0xeec
github.com/tendermint/basecoin/vendor/github.com/spf13/cobra.(*Command).execute(0x109b260, 0xc42046b4f0, 0x1, 0x1, 0x109b260, 0xc42046b4f0)
        /go/src/github.com/tendermint/basecoin/vendor/github.com/spf13/cobra/command.go:656 +0x247
github.com/tendermint/basecoin/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200766c0, 0x2, 0x2, 0xc420072620)
        /go/src/github.com/tendermint/basecoin/vendor/github.com/spf13/cobra/command.go:735 +0x367
github.com/tendermint/basecoin/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200766c0, 0xc42046b3e0, 0x16)
        /go/src/github.com/tendermint/basecoin/vendor/github.com/spf13/cobra/command.go:694 +0x2b
github.com/tendermint/basecoin/vendor/github.com/tendermint/tmlibs/cli.Executor.Execute(0xc4200766c0, 0xba5cce, 0x2)
        /go/src/github.com/tendermint/basecoin/vendor/github.com/tendermint/tmlibs/cli/setup.go:92 +0x4e
main.main()
        /go/src/github.com/tendermint/basecoin/cmd/basecoin/main.go:33 +0x1c1

CLI Multiple Coins

This issue is intended to be a discussion space surrounding sending transaction coins through the CLI. Currently there are three transaction fields using coins:

• coin: string identifier for the coin type
• fee: integer containing the fee
• amount: integer containing the amount to send in the transaction

Problems with this current setup:

• only allows for one coin type for the fee
• only allows for one coin type for the transaction amount
• type of coin must be the same for the transaction as well as the fee

Initial proposed solution: hack it with slashes. Rather than having fee and amount be integer types, we could make them strings which we parse at execution, this would of course limit the use of the slash character within the coin-type name if operating from the CLI. This would also eliminate the need for the coin flag, as it would be built right into fee or amount. Here are some examples that could be valid strings to send into the proposed fee or amount flags:

blank/1/btc/2
gold/10
atoms/10/btc/100/silver/666
etc.

The intention of using this is to simplify use of the CLI so the user doesn't need to point to a .json file nor type any json code. Thoughts?

Layout of ~/.basecoin directory

By default, basecoin should store data in ~/.basecoin. If using --in-proc, all tendermint data should be stored there as well. Dir can be overwritten with --dir flag. If using basecoin out-of-proc, should set --in-proc=$TMROOT to have same effect - otherwise app and tendermint will use separate dirs.

Layout of the dir would be:

.basecoin/
  config.toml
  data
  genesis.json  
  priv_validator.json
  merkleeyes.db

Note we should only have one genesis file: https://github.com/tendermint/basecoin/issues/32

Fee as type Coins instead of Coin

Why should the fee only be one coin, maybe there are multiple types of coins that could be sent as a fee? If the transaction is already provisioning the type of coin the validator is going to need to be making complex value judgements between currencies, so why not?

Coins IsValid() Ordering

It appears as though the IsValid() method is only checking if each coin is sorted against the first coin denom, not the previous denom in order? https://github.com/tendermint/basecoin/blob/master/types/coin.go#L30-L34

Better tooling for ensuring coins are in alphabetical order

Support for hardware wallets, e.g.: Nano Ledger S

Once the network is live we should already have an integration for some hardware wallets as to allow especially big validators to securely store and transfer their atom holdings.

This issue is designed to gather the necessary resources and ideas to make this a reality.

Ethereum for Nano Ledger S
Ethereum Chrome

Process according to btchip on slack

btchip [5:19 PM] 
good question as I don't know much about Tendermint
[5:19] 
usually the process goes like this
[5:19] 
find out what you need to sign - and the cryptographic algorithms involved (edited)
[5:19] 
find out what you need to be verified (and displayed to the user) in what you sign
[5:20] 
then you can write a device app
[5:20] 
then the client app to talk to it or just a library

There are two parts to the implementation. The first one is a the software that runs on the secure device and the second one is the software that runs in Chrome or on the OS. For the former we have to write it in C or if we write the bindings in Rust. The latter can be implemented in JS.

Resources
https://blog.ledger.co/dynamic-secure-applications-with-bolos-and-ledger-blue-a-use-case-with-ethereum-and-the-dao-6be91260e89f

unsafe_reset_all should not remove genesis

Basecoin CLI errors with apptx

Start Server:

tendermint init
tendermint unsafe_reset_all
cd $GOPATH/src/github.com/tendermint/basecoin/data
basecoin start --in-proc --counter-plugin

Try client:

cd $GOPATH/src/github.com/tendermint/basecoin/data
basecoin apptx counter --valid
-> Error about no coins send :(
basecoin apptx --amount 10 counter --valid
-> Another error about fees
basecoin apptx --amount 10 --fee 2 counter --valid
-> Finally works!

The other tutorials (with sendtx and ibc didn't require fees...)

Better checks on ParseCoins format

ParseCoins seems to be a bit too eager to accept input, where I feel it should return an error. But maybe that is just personal opinion and it should actually work as it does. @ebuchman I would like some feedback here.

Two examples:

ParseCoins("17 22hike") => types.Coins{types.Coin{Denom:"hike", Amount:17}}

ParseCoins("17 and more,  18things to do") => types.Coins{types.Coin{Denom:"and", Amount:17}, types.Coin{Denom:"things", Amount:18}}

Note that if the coin name has whitespace or numbers, they are dropped, and just the first word is accepted. Which may not be what the user wanted. I feel it would be better to die early, telling them that "22hike" is not a valid coin name.

Some basic test case in parse-coins branch.

Integrate Autotest Tutorials with Shelldown

Within here, I suspect that the light client doesn't like txs that don't include the --fee flag
https://github.com/tendermint/basecoin/tree/master/cmd/basecli

Support apptx with basecli

We only have sendtx. At least demo how to plug in the counter app.

`basecoin init` should create config file

tendermint/tendermint#515

tendermint init does this now (I believe only since 0.10.0)

ibc: need blockID to verify commit

On IBCUpdateChainTx, We need to check the commit matches the header, but a commit is for a blockID, which we can't derive from the header alone. So either we:

1. Fetch the LastBlockID from the next block and include it with the Header and Commit in the IBCUpdateChainTx. We actually only need the PartSetHeader from the BlockID, since we can compute the Hash from the Header. So to prepare such a tx we would fetch the header from block H and the LastBlockID and LastCommit from block H+1.

2. Write a new VerifyCommit that returns the blockID with +2/3 of the power. This would leave IBCUpdateChainTx unchanged. Currently, VerifyCommit takes a BlockID as argument and ignores votes for other IDs. We could have an alternative, VerifyCommitReturnBlockID that instead returns the BlockID that has +2/3, if there is one.

Make SendTx a PluginTx

Rather than separating out this one type of transaction which is SendTx, why not fit it in as default plugin built right into basecoin? It might be way nicer to have everything go through one process stream instead of having to check this fundamental type of Tx when really SendTx could be built out has a PluginTx :)

It would also allow for folks to build out alternative versions of SendTx for custom "plugin" implementations of basecoin, or to suppress this functionality if it wasn't needed for some niche application

Thoughts?

Abstract Coin/Coins and Accounts to be more general

It would be nice to abstract out the types:

• Coin/Coins
• Accounts

These two types could be re-implemented for specialized basecoin-plugins. For instance, maybe you want to turn the "coin" object into a smart-invoice that can get passed around with context for an expanded Account type.

Thoughts? Is there anything else that should be abstracted out while were on this train?

dont panic when `--name` isnt provided

If you use basecli tx send and dont provide --name, it panics, and doesnt really explain why