On 08/07/2013 05:10 PM, Gavin Andresen wrote:

I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ?  The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

I have avoided any notion of locking inputs in Armory for offline wallets. The underlying concept of why a seemingly-random amount of funds are inaccessible at a given time is so non-intuitive and difficult to explain to a non-expert, that I haven't even tried to deal with it. Luckily, most users do one operation at a time, so it's not a real a problem. But as more businesses have started to use Armory, it will become a problem that will need to be addressed somehow.

I have considered at least "marking" inputs to indicate to the user that the transaction they are creating may not be valid unless all previous transactions have been broadcast. The user will not necessarily understand why, but they might easily comprehend the solution (and perhaps a button that says "Forget all previously created transactions that haven't been broadcast. Press this button if there are no transactions waiting to be broadcast").

Even if the user somewhat understands the concepts behind locking, you easily end up with a mess of some coins being locked and rejecting transaction creation somewhat randomly, especially when they create transactions that they later decide not to execute. And you have to give the user a way to manually unlock the outputs which they wouldn't know to use because it's so non-intuitive. I'd much rather say "either do one transaction at a time, or bundle payments into a single multi-output transaction. Or risk invalid transactions that have to be re-created and signed."

-Alan