Alan Reiner [ARCHIVE] on Nostr: 📅 Original date posted:2013-08-07 📝 Original message:On 08/07/2013 05:10 PM, ...
📅 Original date posted:2013-08-07
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130807/56158e53/attachment.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130807/56158e53/attachment.html>;