📅 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>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:05:38
in reply to nevent1q…p7fr
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:05:38Event JSON
{
"id": "05132ff96edb73bcf57a56199dd66875004c033dbfcc5b300bce6f7340b3867f",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150338,
"kind": 1,
"tags": [
[
"e",
"c5e56f29f73ae037803d4c07616ae2b1311014baf62f54f10973c0b1b685df68",
"",
"root"
],
[
"e",
"5952285afa4e600140f69e47a942dbe0f46e1856a6417843ebd652616d09cd66",
"",
"reply"
],
[
"p",
"58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950"
]
],
"content": "📅 Original date posted:2013-08-07\n📝 Original message:On 08/07/2013 05:10 PM, Gavin Andresen wrote:\n\u003e I'd like to hear from other wallet implementors. Do you have a notion\n\u003e of 'locked inputs' ? The tricky bit in constructing a transaction but\n\u003e not broadcasting it right away is the inputs must be locked, so\n\u003e they're not accidentally double-spent.\n\u003e\nI have avoided any notion of locking inputs in Armory for offline\nwallets. The underlying concept of why a seemingly-random amount of\nfunds are inaccessible at a given time is so non-intuitive and difficult\nto explain to a non-expert, that I haven't even tried to deal with it.\n Luckily, most users do one operation at a time, so it's not a real a\nproblem. But as more businesses have started to use Armory, it /will/\nbecome a problem that will need to be addressed /somehow/.\n\nI have considered at least \"marking\" inputs to indicate to the user that\nthe transaction they are creating may not be valid unless all previous\ntransactions have been broadcast. The user will not necessarily\nunderstand why, but they might easily comprehend the solution (and\nperhaps a button that says \"Forget all previously created transactions\nthat haven't been broadcast. Press this button if there are no\ntransactions waiting to be broadcast\"). \n\nEven if the user somewhat understands the concepts behind locking, you\neasily end up with a mess of some coins being locked and rejecting\ntransaction creation somewhat randomly, especially when they create\ntransactions that they later decide not to execute. And you have to\ngive the user a way to manually unlock the outputs which they wouldn't\nknow to use because it's so non-intuitive. I'd much rather say \"either\ndo one transaction at a time, or bundle payments into a single\nmulti-output transaction. Or risk invalid transactions that have to be\nre-created and signed.\"\n\n-Alan\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130807/56158e53/attachment.html\u003e",
"sig": "b94b4ebd2748f2cd5dc00d3a5e3043663656605e9c039dbd6bca8616977ea1e3c2094ed08826b8a7f6b19c16642019c26890175a648c8800fa87cef6821af927"
}