* crypto: revert to mainline Go crypto lib
We used to use a fork for a modified bcrypt so we could pass our own
randomness but this was largely unecessary, unused, and a burden.
So now we just use the mainline Go crypto lib.
* changelog
* fix tests
* version and changelog
* config: cors options are arrays of strings, not strings
Fixes#2980
* docs: update tendermint-core/configuration.html page
* set allow_duplicate_ip to false
* in `tendermint testnet`, set allow_duplicate_ip to true
Refs #2712
* fixes after Ismail's review
* Revert "set allow_duplicate_ip to false"
This reverts commit 24c1094ebc.
* optimize addProposalBlockPart
* optimize addProposalBlockPart
* if ProposalBlockParts and LockedBlockParts both exist,let LockedBlockParts overwrite ProposalBlockParts.
* fix tryAddBlock
* broadcast lockedBlockParts in higher priority
* when appHeight==0, it's better fetch genDoc than state.validators.
* not save state if replay from height 1
* only save state if replay from height 1 when stateHeight is also 1
* only save state if replay from height 1 when stateHeight is also 1
* only save state if replay from height 0 when stateHeight is also 0
* handshake info's response version only update when stateHeight==0
* save the handshake responseInfo appVersion
(left after committing a block)
Fixes#2961
--------------
ORIGINAL ISSUE
Tendermint version : 0.26.4-b771798d
ABCI app : kv-store
Environment:
OS (e.g. from /etc/os-release): macOS 10.14.1 What happened: Set
mempool.recheck = false and create empty block = false in config.toml.
When transactions get added right between a new empty block is being
proposed and committed, the proposer won't propose new block for that
transactions immediately after. That transactions are stuck in the
mempool until a new transaction is added and trigger the proposer.
What you expected to happen: If there is a transaction left in the
mempool, new block should be proposed immediately.
Have you tried the latest version: yes
How to reproduce it (as minimally and precisely as possible): Fire two
transaction using broadcast_tx_sync with specific delay between them.
(You may need to do it multiple time before the right delay is found, on
my machine the delay is 0.98s)
Logs (paste a small part showing an error (< 10 lines) or link a
pastebin, gist, etc. containing more of the log file):
https://pastebin.com/0Wt6uhPF
Config (you can paste only the changes you've made): [mempool] recheck =
false create_empty_block = false
Anything else we need to know: In mempool.go, we found that proposer
will immediately propose new block if
Last committed block has some transaction (causing AppHash to changed)
or mem.notifyTxsAvailable() is called. Our scenario is as followed.
A transaction is fired, it will create 1 block with 1 tx (line 1-4 in
the log) and 1 empty block. After the empty block is proposed but before
it is committed, second transaction is fired and added to mempool. (line
8-16) Now, since the last committed block is empty and
mem.notifyTxsAvailable() will be called only if mempool.recheck = true.
The proposer won't immediately propose new block, causing the second
transaction to stuck in mempool until another transaction is added to
mempool and trigger mem.notifyTxsAvailable().
Fixes#2715
In crawlPeersRoutine, which is performed when seedMode is run, there is
logic that disconnects the peer's state information at 3-hour intervals
through the duration value. The duration value is calculated by
referring to the created value of MConnection. When MConnection is
created for the first time, the created value is not initiated, so it is
not disconnected every 3 hours but every time it is disconnected. So,
normal nodes are connected to seedNode and disconnected immediately, so
address exchange does not work properly.
https://github.com/tendermint/tendermint/blob/master/p2p/pex/pex_reactor.go#L629
This point is not work correctly.
I think,
https://github.com/tendermint/tendermint/blob/master/p2p/conn/connection.go#L148
created variable is missing the current time setting.
* p2p: panic on transport error
Addresses #2823. Currently, the acceptRoutine exits if the transport returns
an error trying to accept a new connection. Once this happens, the node
can't accept any new connections. So here, we panic instead. While we
could potentially be more intelligent by rerunning the acceptRoutine, the
error may indicate something more fundamental (eg. file desriptor limit)
that requires a restart anyways. We can leave it to process managers to
handle that restart, and notify operators about the panic.
* changelog
deliverTxResCh, like any other eventBus (pubsub) channel, is closed when
eventBus is stopped. We must check if the channel is still open. The
alternative approach is to not close any channels, which seems a bit
odd.
Fixes#2408
* WIP: tests for #2785
* rebase onto develop
* add Bucky's test without changing ValidatorSet.Update
* make TestValidatorSetBasic fail
* add ProposerPriority preserving fix to ValidatorSet.Update to fix
TestValidatorSetBasic
* fix randValidator_ to stay in bounds of MaxTotalVotingPower
* check for expected proposer and remove some duplicate code
* actually limit the voting power of random validator ...
* fix test
* types: ValidatorSet.Update preserves ProposerPriority
This solves the other issue discovered as part of #2718,
where Accum (now called ProposerPriority) is reset to
0 every time a validator is updated.
* update changelog
* add test
* update comment
* Update types/validator_set_test.go
Co-Authored-By: ebuchman <ethan@coinculture.info>
* set the accum of a new validator to (-total voting power):
- disincentivize validators to unbond, then rebon to reset their
negative Accum to zero
additional unrelated changes:
- do not capitalize error msgs
- fix typo
* review comments: (re)capitalize errors & delete obsolete comments
* More changes suggested by @melekes
* WIP: do not batch clip (#2809)
* substract avgAccum on each iteration
- temporarily skip test
* remove unused method safeMulClip / safeMul
* always substract the avg accum
- temp. skip another test
* remove overflow / underflow tests & add tests for avgAccum:
- add test for computeAvgAccum
- as we substract the avgAccum now we will not trivially over/underflow
* address @cwgoes' comments
* shift by avg at the end of IncrementAccum
* Add comment to MaxTotalVotingPower
* Guard inputs to not exceed MaxTotalVotingPower
* Address review comments:
- do not fetch current validator from set again
- update error message
* Address a few review comments:
- fix typo
- extract variable
* address more review comments:
- clarify 1.125*totalVotingPower == totalVotingPower + (totalVotingPower >> 3)
* review comments: panic instead of "clipping":
- total voting power is guarded to not exceed MaxTotalVotingPower ->
panic if this invariant is violated
* fix failing test
Anton Kaliaev
Zach
Ethan Buchman
Jae Kwon
Hleb Albau
JamesRay
mircea-c
Dev Ojha
Daniil Lashin
Leo Wang
Ismail Khoffi