[Bitcoin-development] deterministic transaction expiration

Alex Mizrahi alex.mizrahi at gmail.com
Tue Aug 5 18:01:29 UTC 2014


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/bd7de220/attachment.html>


More information about the bitcoin-dev mailing list