Subject: Re: [Bitcoin-development] deterministic transaction expiration

From: Alex Mizrahi <[email-masked]>
Date: Tue, 5 Aug 2014 21:01:29 +0300

>
> A distinction there is that they can only become invalid via a
> conflict— replaced by another transaction authored by the prior
> signers. If no other transaction could be created (e.g. you're a
> multisigner and won't sign it again) then there is no such risk.

You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
 If one of inputs depends on transaction which is signed by parties with
unknown trustworthiness, then it isn't safe.

>  It now introduces chance events ("act of god") into the mix where they
> they didn't exist before.

You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
  If one of inputs depends on transaction time-locked script (or other
unrecognized script), then it isn't safe.

Situation is identical, you might need several extra lines of code.

I think it would matter only if we had deterministic, reliable mempool and
reorganization behavior. But it's not something we can depend on.