Benefits of multisig usage?

[etotheipi]

(This can be resolved with backups, but I feel that backups are quite a nuisance from the user's perspective)

So is reverting to a previously-considered-insecure security model after 6 months, which is long enough for the user to forget about it.

Anyone who handles important documents/information makes copies.  They keep them in a safe place for when they need them.  Bitcoin private keys should be handled the same way.

[cunicula]

(This can be resolved with backups, but I feel that backups are quite a nuisance from the user's perspective)

So is reverting to a previously-considered-insecure security model after 6 months, which is long enough for the user to forget about it.

Anyone who handles important documents/information makes copies.  They keep them in a safe place for when they need them.  Bitcoin private keys should be handled the same way.

But many people won't make copies. It is not helpful to tell stupid people they shouldn't be stupid. The consequences of idiocy can be mitigated through good design choices.

The reversion could be extended automatically for another six months every time a new 2 of 2 txn is signed. The point is that if a 2 of 2 txn doesn't happen for a long enough period, then at least 1 of the 2 factors is likely lost. I think most users would prefer insecurely stored coins to no coins at all.
 

[kjj]

The scripts have no notion of time, and this is for good reasons.

Maybe try 2-of-3, with an option to print and forget one of the keys.  That way, if the second device is lost, you can load that key up, recover all of the transactions that used it, and make new ones.

[cunicula]

The scripts have no notion of time, and this is for good reasons.

Okay. Awareness of time would be a useful feature.

[kjj]

The scripts have no notion of time, and this is for good reasons.

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

[nimda]

The scripts have no notion of time, and this is for good reasons.

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

Blocks have timestamps which need to be accurate within a few hours. Blockcount can also more or less work.

[kjj]

The scripts have no notion of time, and this is for good reasons.

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

Blocks have timestamps which need to be accurate within a few hours. Blockcount can also more or less work.

Yes, but the scripts do not.

Basically, transactions only depend on their order, specifically they must come after their inputs, and before their own double-spend attempt.  Adding a notion of time or block count would make it possible to have transactions that might be valid in one block, but not another, which could have cascading consequences and be a big ugly mess.  And that is only the most obvious problem, the one that we are aware of, there are probably plenty of others too.

[nimda]

The scripts have no notion of time, and this is for good reasons.

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

Blocks have timestamps which need to be accurate within a few hours. Blockcount can also more or less work.

Yes, but the scripts do not.

Basically, transactions only depend on their order, specifically they must come after their inputs, and before their own double-spend attempt.  Adding a notion of time or block count would make it possible to have transactions that might be valid in one block, but not another, which could have cascading consequences and be a big ugly mess.  And that is only the most obvious problem, the one that we are aware of, there are probably plenty of others too.

Doesn't nLockTime make use of blockcount and timestamps?