Delayed multisig wallet - feasible?

[dnydublin12]

Would it be possible to have a new type of wallet, that was a type of multisig wallet. Delayed transaction multisig wallet.

Use case: People and companies like Bitstamp who want to have monies in hot wallet and are happy to forgo instant transactions in some of their wallets, in the interest of extra security and a chance to undo transactions within a certain timeframe. Like a half way house in terms of security between an offline wallet and a hot wallet.

Transactions initiated with this type of wallet would not be executed immediately, but would always be marked for processing, in X blocks (36 for 6 hour delay, 72 for 12, 144 for a day). The ability to "post date" transactions is already built into bitcoin, so would just be a matter of having a special case of multisig to throw transactions out of the pending pool if they were counter signed, as opposed to validating them if they were countersigned.

If the owner of the wallet noticed that an undesired transaction had being placed, they would have time to use a separate signature to mark the transaction as invalid.

Background ----
Bitstamp seem to have being doing everything quite well, keeping most of the funds in offline wallets. The money that was stolen was from a hot wallet. Petty cash, if you like, which they would understandably need to have easily accessible and in a hot wallet for operational reasons. Its a pain to have to transfer funds from cold storage frequently, but insecure to keep too much in a hot wallet.

Is it possible?

[DannyHamilton]

You've asked the same question here:
https://bitcointalk.org/index.php?topic=916576.0

It's generally a bad idea to post the exact same question in two different places.

You end up with a split conversation where nobody knows what has already been said.

You'll want to take the time to really think through all the possible situations and attacks that might be possible with something like this.

If a mining pool doesn't see the second signature in time, what happens when they eventually include the transaction in a block (after X blocks have occurred)?

How would this be different from a mining pool refusing to honor the second signature and including the transaction in a block (after X blocks), or would it be different?

Couldn't an attacker eat up all of the memory (or disk space) of the mining pools by generating these transactions as fast as they can so that the pools need to store millions of transactions that aren't ready to be confirmed, and then transmitting the "cancel" signature before the deadline?

[dnydublin12]

Thanks Danny for the reply. Some excellent points and exactly what I was looking for. I've locked the other topic.

On your points, you are absolutely right, what I suggested would not work, for exactly the reasons you highlighted. But the use case still exists - will try and think of something else.

[dnydublin12]

Actually just reading through your response again.

"If a mining pool doesn't see the second signature in time, what happens when they eventually include the transaction in a block (after X blocks have occurred)?"
If the transaction has not being included after delay + validity period blocks it should be disguarded. So for example if you had a 36 block (6 hour) delay wallet you could also have a validity period, so that if it was not included within the subsequent Y blocks it would be marked as invalid.

"How would this be different from a mining pool refusing to honor the second signature and including the transaction in a block (after X blocks), or would it be different?"
So I think you talking about a mining pool colluding with the hacker? If this did happen, you would be no worse off than today. But its fairly unlikely.

"Couldn't an attacker eat up all of the memory (or disk space) of the mining pools by generating these transactions as fast as they can so that the pools need to store millions of transactions that aren't ready to be confirmed, and then transmitting the "cancel" signature before the deadline?"
The 'cancel' action could consume a transaction fee to prevent this abuse?