What to do if a tx gets copied from an undecided or decided_valid block to the backlog?

[ttmc]

What if a "bad" node copies a transaction from an undecided or decided_valid block to the backlog? (That shouldn't happen, but hey, it's possible.)

Maybe when a node builds a block, it should check each transaction to see if that transaction is already in an undecided or decided_valid block. If so, it should delete the transaction in question (i.e. delete the one in the backlog table, not the one in the bigchain table).

[r-marques]

this is related to #131

[rhsimplex]

Related to #568, closing to consolidate discussion.

[ttmc]

@rhsimplex Are you thinking that the soon-to-come check for duplicate transactions will handle this scenario (where a bad node copies a transaction from a block in the bigchain table to the backlog, when it shouldn't)?

[rhsimplex]

That's the idea...did I miss something?

[ttmc]

@rhsimplex I was just making sure I understood your reasoning. All is well, carry on.

[rhsimplex]

Reopening, because #359 and #609 don't fully solve this. There is no explicit check for duplicate CREATE transactions in validate_block. Even if there were, it's no guarantee due to concurrency. Will the votes take care of it?

[ttmc]

I think this issue is resolved now. I'm pretty sure that if a transaction in a valid or undecided block gets copied to the backlog, the copy will get deleted as invalid (either as a double-create or as a double-spend).

@libscott Can you confirm?

[ssadler]

This is correct, all transactions are checked for conflicting transactions (another tx that spends same outputs or has same ID in a non INVALID block):

bigchaindb/bigchaindb/pipelines/vote.py

Line 103 in dc58466

new = self.bigchain.is_new_transaction(tx.id, exclude_block_id=block_id)

bigchaindb/tests/pipelines/test_vote.py

Line 641 in dc58466

def test_vote_no_double_inclusion(b):