Quote from: jl777 on March 19, 2016, 11:14:28 PM

maybe I am being a bit simplistic about this, but "unconfirmed" to me means that it hasnt been confirmed. So to require that all unconfirmed transactions must be confirmed contradicts the fundamental meaning of unconfirmed. What is the meaning of the word 'unconfirmed'?

Consider the standard refund transaction setup. A transaction with a 2 of 2 output is committed to the block-chain that is spent by a refund transaction.

If the refund transaction has a locktime 2 years into the future, then it cannot be spent for at least two years.

On the one hand, the refund transaction is unconfirmed. But on the other hand, there is no risk of its input being double spent. Both parties are safe to assume that the transaction will eventually be included.

A hard fork which makes the refund transaction invalid effectively steals that output. At the absolute minimum, there should be a notice period, but it is better to just not have that problem in the first place.

There was at least one thread that asked about leaving money to someone for their 18th birthday. A payment like that could very easily be locked for 10+ years. I think the conclusion in the thread was that leaving a letter with a lawyer was probably safer.

If someone has a 1MB transaction that spends a 2 of 2 output but is locked for 5 years, is it fair to say to them that it is no longer spendable?

There is probably a reasonable compromise, but it should err on the side of not invalidating locked transactions.

That is why increasing the version number helps. If someone has a locked transaction that uses a non-defined transaction version number, then I think it is fair enough that their locked transaction ends up not working. For the time being, only version 1 transactions are safe to use with locktime.

I made a post on the dev list at the end of last year with some suggestions for rules.

Transaction version numbers will be increased, if possible
Transactions with unknown/large version numbers are unsafe to use with locktime
Reasonable notice is given that the change is being contemplated
Non-opt-in changes will only be to protect the integrity of the network

I think if a particular format of transaction has mass use, then it is probably safer for locking than an obscure or very unusual transaction. A transaction that uses one of the IsStandard forms would be safer than one that is 500kB and has lots of OP_CHECKSIG calls.

The guidelines could say that transactions which put an 'excessive' load on the network are riskier.