Re: [Bitcoin-development] deterministic transaction expiration

[Alex Mizrahi <alex.mizrahi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 1527 bytes --]