Turning `create_empty_blocks` to false has no effect

Even if we turn the create_empty_blocks param to false there are blocks being created at the rate of 1block /sec , we dont want to have empty blocks . I came across https://github.com/tendermint/tendermint/issues/1995 , how to stop app hash from being updated every block would be the second question .
I want to create blocks in 5 mins , can you suggest a way ?

What app are you using? If it’s something built with the Cosmos SDK, it’s currently not possible, unfortunately. Hopefully will be soon.

Really hope this can be back soon.

Hey ! yeah i was first trying with an app i made using the sdk , now im editing config.toml in tendermint , when i set the empty block flag to false , it doesnt not create new blocks , but weirdly when i send a transaction 2 blocks are created consecutively , height is incremented by 2 . Why is that happening @ebuchman?

no_empty_blocks is not currently compatible with the SDK.

yes you mentioned that earlier , hence i havent mentioned cosmos-sdk anywhere in the above message , i tried sending a transaction via “brodcast_tx_commit” to the tendermint core directly which resulted in formation of 2 blocks one with transaction data and another empty . Which brought me to the question why is that so , does tendermint core also not support empty blocks properly ?

You would expect 2 blocks.

The 1st block as the transaction.

The 2nd block has the state update

zaki:

The 1st block as the transaction.

thank you for your response ! ’

1. Can’t we combine those 2 ?
2. State cant be updated in the same block which contains the transaction ?
3. State update is a block without transaction (Empty block) which should not have been created because we turned it off , right ?

Am I missing something here ?

This is pretty fundemental to how tendermint works

Thank you for clarification, @zaki. I also use Tendermint with create_empty_blocks=false and was wondering, why I have 2 blocks per tx.

There is a great discussion of related issues going on here.

Issue: Run CheckTx before voting on blocks

Follow up from #2175
Consider a ConsensusParam that determines if we run CheckTx on proposal blocks before voting for them. This would...