PrivKey needs to be readonly by owner alone (chmod 0400)

Having a timestamp on all RPC responses will enable easier monitoring and debugging of nodes.
i.e. if Network Monitor is sends an RPC request for status and receives an old block height/timestamp but a more recent timestamp from the node that would indicate the node is online but not processing blocks. There may be a number of ways to achieve this.

Unbonding should succeed after a while, but also fail if validator duped out.

• error when the file is different

Mainly to help with development.

Would be good to get a tree-based view of the dependency structure, available as a Makefile command.

Also we should figure out vendoring.

rpcs should take an optional proof flag, and corresponding responses should supply merkle proof of the response data

Add the node name, which can be displayed. (future: add a fleeting pubkey for each node to detect anomalous situations wrt name spoofing)
Add the node version, which communicates that there may be pending upgrades to perform, and may help with debugging issues.
Add these to the handshake.

requestBlocksFromRandomPeers is inefficient (though it is sufficient)
We should find pending blocks and sample the peers in one go rather than the current O(n^2) impl.

Test all the major exported functions, including deterministic hashing regardless of order of Add/Remove.

Also, generally should test AddrBook.

We need to estimate the cost of each op and charge accordingly, if we want to open the VM to public use.

Split into Broadcast() and BroadcastTry().
Broadcast() and Send() should time out. **
Errors/failures are returned as a slice.

Adjust the buffer sizes for each channel appropriately, especially increase the StateCh buffer size since it's the most important. HasVoteMessage shouldn't block NewRoundStep/Commit messages.

** think harder

[ ] Add an *error into Comparator
[ ] Make merkle/iavl_node panic upon comparator error.

Test the storage of block parts, validation, and meta (block header).

Remove link to outdated PDF whitepaper, move contents to tendermint.com/blog.
Update "whitepage".

I thought it was a service to decentralize voting on tinder dates. After that, I thought it was some sort of steak (tenderloin). Once I read the splash page, the words describing de-insentivizing energy consumption etc. all fell into background as i pictured thin slices of juicy mint-flavored roast beef dripping out of my wallet.

We should create a test client that just sends money around 24/7 amongst a 100K accounts and just swamps the blockchain.

Fun!

By the time a node precommits, it should have the justification (POL) prevotes, the block itself, etc saved to disk so that should it restart, it can recall its lock state and prevote accordingly. Without this, validators can accidentally unlock upon restart right after a precommit, perhaps causing the blockchain to halt.

This isn't a problem unless a large number of valdiators go offline simultaneously. It could be a problem in the early stages of a blockchain when less than 4 validators are online, assuming equal voting powers.

The problem is if, say, a proposer maliciously proposes a block where the first transaction deletes a nameTx, then a second transaction updates that name. Not sure if this is actually a problem or not, but state/execution seems to panic in this case, and I'm not sure what catches it.

We should catch panics during block execution and return an error.

low priority

module=p2p peer=Peer{MConn{149.129.180.153:55101}->}
INFO[04-03|00:08:05] Stopping peer for error module=p2p peer=Peer{MConn{149.129.180.153:55101}->} error="Error: Unknown message type 47\nStack: /home/zack/gocode/src/github.com/tendermint/tendermint/p2p/connection.go:166 (0x5eaa56)\n\t(_MConnection)._recover: stack := debug.Stack()\n/home/zack/go/src/runtime/asm_amd64.s:401 (0x452de5)\n\tcall16: CALLFN(·call16, 16)\n/home/zack/go/src/runtime/panic.go:387 (0x42a0b8)\n\tgopanic: reflectcall(unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))\n/home/zack/gocode/src/github.com/tendermint/tendermint/p2p/connection.go:424 (0x5edca8)\n\t(_MConnection).recvRoutine: panic(Fmt("Unknown message type %X", pktType))\n/home/zack/go/src/runtime/asm_amd64.s:2232 (0x454f21)\n\tgoexit: \n"
INFO[04-03|00:08:05] Stopping gossipDataRoutine for Peer{MConn{149.129.180.153:55101}->}. module=consensus
INFO[04-03|00:08:05] Stopping gossipVotesRoutine for Peer{MConn{149.129.180.153:55101}->}. module=consensus
INFO[04-03|00:08:06] Added peer module=p2p peer=Peer{MConn{149.129.180.153:55117}->}
INFO[04-03|00:08:06] Stopping peer for error module=p2p peer=Peer{MConn{149.129.180.153:55117}->} error="Error: Unknown message type 47\nStack: /home/zack/gocode/src/github.com/tendermint/tendermint/p2p/connection.go:166 (0x5eaa56)\n\t(_MConnection)._recover: stack := debug.Stack()\n/home/zack/go/src/runtime/asm_amd64.s:401 (0x452de5)\n\tcall16: CALLFN(·call16, 16)\n/home/zack/go/src/runtime/panic.go:387 (0x42a0b8)\n\tgopanic: reflectcall(unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))\n/home/zack/gocode/src/github.com/tendermint/tendermint/p2p/connection.go:424 (0x5edca8)\n\t(_MConnection).recvRoutine: panic(Fmt("Unknown message type %X", pktType))\n/home/zack/go/src/runtime/asm_amd64.s:2232 (0x454f21)\n\tgoexit: \n"
INFO[04-03|00:08:06] Stopping gossipDataRoutine for Peer{MConn{149.129.180.153:55117}->}. module=consensus
INFO[04-03|00:08:06] Stopping gossipVotesRoutine for Peer{MConn{149.129.180.153:55117}->}. module=consensus
INFO[04-03|00:08:09] Running round action module=consensus height=73060 round=13 step=RoundStepPropose roundAction="RoundAction{H:73060 R:13 A:RoundActionPrevote}" startTime=2015-04-03T00:01:49-0400
WARN[04-03|00:08:09] ProposalBlock is nil module=consensus

With the objective of enabling more convenient and effective development of the Network consider creating / configuring the following features:

1: A script running on node start-up to enable the node User to review/add/amend the following:
> Node Moniker and optional user contact details
> Which Tendermint network names(s) to join, listen out for or exclude
> an IP:port peer address list for initial bootstrap p2p comms
> Whitelist / blacklist IP:ports for RPC

2: Add a Code Build three group version number (v1.1.1) and potentially also a Code Hash and Compile date/timestamp.

3: Configure the RPC Status call to report all the above details and additionally:
> report hardware, OS and other relevant node system config details (Ram, HDD, processor/cores)
> Validator Account Public Key for holding bonded stake.

4: Configure Barac RPC to report listening/active status and allowed function list

Rebonding fails sometimes (repeatedly) for a validator.
Suggested change:

@@ -693,7 +693,8 @@ func ExecTx(blockCache *BlockCache, tx_ types.Tx, runCall bool, evc events.Firea
                }

                // tx.Height must be equal to the next height
-               if tx.Height != _s.LastBlockHeight+1 {
+               //if tx.Height != _s.LastBlockHeight+1 {
+               if _s.LastBlockHeight-(validatorTimeoutBlocks/2) <= tx.Height <= _s.LastBlockHeight+1 {
                        return errors.New(Fmt("Invalid rebond height.  Expected %v, got %v", _s.LastBlockHeight+1, tx.Height))
                }

I don’t see any problems with this approach because RebondTx isn’t very important for consensus or light client security… it’s only when it gets committed into the blockchain that the unbonding validator becomes active again.

Thanks Ethan for spotting the logical bug.

• fix debora stop
• take hosts from cli
• --bg labelname
• some way to unite the logs across boxes so we can easily grep through them all (since they might deploy at different seconds and so have different names)
• debora status should return which jobs are running too
• barak should close and release log files.
• debora open/close should take "0.0.0.0:port" and ":port" as well. (currently must be "[::]:port")
• move debora public key out of group config?

In the various reactors (consensus/pex/mempool etc), bad behavior should be reported and eventually trickle to the addrbook somehow and call MarkBad() so we know not to dial the peer again. Or not to dial the peer again for a while. Not sure what the addrbook does but we should make sure the behavior is reasonable.

We should discuss the overall strategy of peer ethics before hastily disconnecting/banning nodes (or even being too lenient) because it could cause the network to fragment. Maybe we should err on the side of being lenient (and suffer some spam)?

In any case we should keep a good record of things so when things change (e.g. a peer is marked bad, banned, etc) we know how to debug it. It could be as simple as a log.Info().

Unless I'm missing something, there is no way to send funds from a contract to an account. Presumably this would be done with the CALL opcode, but that simply calls vm.Call(...) which panics if there is no code passed in. Instead, we should remove the panic, do the transfer, and then return if there's no code. This is more or less what happens in go-eth. Also CALL expects the destination account to exist, and returns an error if it doesn't, so we might have to remove that check so the contract can send funds to a new account. Happy to fix it once you acknowledge.

Followed the steps from: https://github.com/tendermint/tendermint/wiki/Developer-Quick-Start

Get the output

INFO[04-07|19:42:34] No PrivValidator found                   module=main file=/Users/jehan/.tendermint/priv_validator.json
INFO[04-07|19:42:34] Added Listener(@192.168.1.104:8080)      module=main
INFO[04-07|19:42:34] Starting Node                            module=main
INFO[04-07|19:42:34] Starting AddrBook                        module=p2p
INFO[04-07|19:42:34] Starting Switch                          module=p2p
INFO[04-07|19:42:34] Starting PEXReactor                      module=p2p
INFO[04-07|19:42:34] Starting MempoolReactor                  module=mempool
INFO[04-07|19:42:34] Starting ConsensusReactor                module=consensus
INFO[04-07|19:42:34] Starting ConsensusState                  module=consensus
INFO[04-07|19:42:34] Dialing peer                             module=p2p address=23.239.22.253:8080
INFO[04-07|19:42:34] Running round action                     module=consensus height=1 round=0 step=RoundStepNewHeight roundAction="RoundAction{H:1 R:0 A:RoundActionPropose}" startTime=2015-04-07T19:42:32-0700
EROR[04-07|19:42:37] Error dialing seed                       module=main error="dial tcp 23.239.22.253:8080: i/o timeout"

The website will link to each submodule github README page.
Newcomers should be able to get a good sense of the architecture and scope of the project by browsing these pages.

I'm building a javascript lib for Thelonious-Tendermint and would like to contribute to the server side, particularly the RPC/RMI section. Seems like the logic is mostly there, so I'd be refining & standardizing.

This is my suggestions:

Coding

Separate into two different RPC protocols. The first would be used between Go libraries that can just import the serialization/binary stuff. The second would be generic (JSON) RPC, and that's what I'd be working with. I'd create proxies and conversion functions for all the needed data-structures and hook them up with the handlers. I guess regular HTTP requests could use them as well, though I wouldn't be concerned with that.

This would also involve going over method names, namespacing etc. Maybe add some more functions (a way to get the client version etc.), and divide a few of the current ones up etc. The model I use in the javascript library (as of now) has the following classes:

• Accounts
• Blockchain
• Consensus
• Core
• Networking
• Transactions
• Unsafe

These are based on the current rpc commands (and looking at the client), and I don't think more classes will be needed for some time.

Tests

I would make sure the tests are working before PRing to develop, and add any new ones that might be needed.

Docs

I could put the spec in the wiki.

Time

It would probably take about a week for the code, and another for doing good tests and docs + the time it takes to look into / research the library more. Around 3 weeks in total.

Support a field tag like

type MyStruct struct {
    MyField uint32 `binary:”uvarint"`
}

instead of

type MyStruct struct {
    "MyField uint"
}

and replace usage of (u)int, make it explicitly (u)int64/32/16.

0000000000000000000000000600035046315CF2684811415610040576004356040526040515460605260206060F35B63693200CE8114156100875760043560805260243560A052335460C0523360E05260A05160C051121515
6100865760A05160C0510360E0515560A0516080515401608051555B5B505B6000F3
(pc) 0 (op) PUSH3 (st) 0 => 0x00000000000000000000000000000000000000000000000000000000000F4240
(pc) 4 (op) CALLER (st) 1 => 7B50B28A287E4F48D565610E16588DF4033DB802000000000000000000000000
(pc) 5 (op) SSTORE (st) 2 {0x7B50B28A287E4F48D565610E16588DF4033DB802000000000000000000000000 : 0x00000000000000000000000000000000000000000000000000000000000F4240}
(pc) 6 (op) PUSH2 (st) 0 => 0x0000000000000000000000000000000000000000000000000000000000000089
(pc) 9 (op) DUP1 (st) 1 => [1] 0x0000000000000000000000000000000000000000000000000000000000000089
(pc) 10 (op) PUSH2 (st) 2 => 0x0000000000000000000000000000000000000000000000000000000000000014
(pc) 13 (op) PUSH1 (st) 3 => 0x0000000000000000000000000000000000000000000000000000000000000000
(pc) 15 (op) CODECOPY (st) 4 => 0, 0, 0 16 (op) PUSH2 (st) 1 => 0x000000000000000000000000000000000000000000000000000000000000009D
(pc) 19 (op) JUMP (st) 2 [15F8F67A43AA27B78BC70BABFE084AFB9FADF64CCFFA2A59B3A0BFB6196A6DB3]: [0001000000000000001114AC89A6DDF4C309A89A2C4078CE409A5A7B28227014AC
89A6DDF4C309A89A2C4078CE409A5A7B282270000000C2EB0B000000000000]

208B0D661E2B8868E78E4AB6EF558D4A16C9F3EDCF6046BAAAD63104AEBD59950B01147B50B28A287E4F48D565610E16588DF4033DB802A0860100000000000040420F000000000000000000000000000000]

147B50B28A287E4F48D565610E16588DF4033DB80201208B0D661E2B8868E78E4AB6EF558D4A16C9F3EDCF6046BAAAD63104AEBD59950B00000140420F0000000000000000000000000001147B50B28A287E4F48D565610E165
88DF4033DB80201208B0D661E2B8868E78E4AB6EF558D4A16C9F3EDCF6046BAAAD63104AEBD59950B00000140420F000000000000000000000000000020C65E636FE2CF3D4414141F513F56ED5BB5211B4A38F8BF8E813ADC0C
5E2A8BD1206BCCE3AF22F761ACBB4A8331298A2E826A8B27B4C201F79B270091C7ACBE59E8]

0000C2EB0B000000000000]

5393DFE45E5E9E210F60832015F8F67A43AA27B78BC70BABFE084AFB9FADF64CCFFA2A59B3A0BFB6196A6DB3]
panic: Value missing for key 0000000000000000000000000000000000000000000000000000000000000000

goroutine 31 [running]:
github.com/tendermint/tendermint/merkle.(_nodeDB).GetNode(0xc208dd9a70, 0xc208e03b80, 0xc208f1a560, 0x20, 0x20, 0x0)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/merkle/iavl_tree.go:214 +0x379
github.com/tendermint/tendermint/merkle.(_IAVLTree).Load(0xc208e03b80, 0xc208f1a560, 0x20, 0x20)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/merkle/iavl_tree.go:129 +0x60
github.com/tendermint/tendermint/state.(_VMAppState).Sync(0xc208dd9530)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/state/vm_app_state.go:233 +0xec1
github.com/tendermint/tendermint/state.(_State).ExecTx(0xc208e0c000, 0x5217bc8, 0xc208115360, 0x1, 0x0, 0x0)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/state/state.go:369 +0x176a
github.com/tendermint/tendermint/state.(_State).appendBlock(0xc208e0c000, 0xc208e00d20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/state/state.go:709 +0x3ff
github.com/tendermint/tendermint/state.(_State).SetBlockStateHash(0xc2080ed360, 0xc208e00d20, 0x0, 0x0)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/state/state.go:618 +0x89
github.com/tendermint/tendermint/consensus.(_ConsensusState).RunActionPropose(0xc208001560, 0x3, 0x0)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/consensus/state.go:638 +0x166e
github.com/tendermint/tendermint/consensus.(_ConsensusState).stepTransitionRoutine(0xc208001560)
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/consensus/state.go:391 +0xbd0
created by github.com/tendermint/tendermint/consensus.(*ConsensusState).Start
/Users/BatBuddha/Programming/megaGoApps/goApps/src/github.com/tendermint/tendermint/consensus/state.go:286 +0xaf

goroutine 549801 [select, 553 minutes]:
github.com/tendermint/tendermint/common.(_RepeatTimer).fireRoutine(0xc216b86d40, 0xc21608f380)
/home/jae/gocode/src/github.com/tendermint/tendermint/common/repeat_timer.go:34 +0x151
created by github.com/tendermint/tendermint/common.(_RepeatTimer).Reset
/home/jae/gocode/src/github.com/tendermint/tendermint/common/repeat_timer.go:52 +0xdf

go test -race

Yeah.

Also, might as well uncomment the SeedNode. That will make onboarding easier.

net info output:

{"result":
{"Moniker":"anonymous","Network":"tendermint_testnet3","Listening":true,"Listeners":["Listener(@128.199.230.153:8080)"],
"Peers":[
{"NodeInfo":{"Moniker":"anonymous", "Network":"tendermint_testnet3", "Host":"162.243.85.60", "P2PPort":46656, "RPCPort":46657}, "IsOutbound":true}, 
{"NodeInfo":{"Moniker":"anonymous", "Network":"tendermint_testnet3", "Host":"162.243.85.60", "P2PPort":46656, "RPCPort":46657}, "IsOutbound":false},
 {"NodeInfo":{"Moniker":"anonymous", "Network":"tendermint_testnet3", "Host":"10.0.0.3", "P2PPort":8080, "RPCPort":8081}, "IsOutbound":false}]}, "error":"","id":"","jsonrpc":"2.0"}

Upon connection we should send our peer our height/round/state.
Currently we don't, so we have to wait until the round is over until peers receive a NewRoundStepMessage. This could be arbitrarily long if the node hadn't synced in a while, as it would be on some large round number!

Solution: have a nonce strictly for signed txs and another one for creates

Otherwise when a user first joins the same network with a different genesis file, it won't be obvious why no blocks are syncing.

otherwise might overload a peer or not get a chance to get new ones

Test the syncing of new/late nodes, catching up to the tip.

There was a bug there.