From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7BZo-0006Oy-Px for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:47:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.48 as permitted sender) client-ip=209.85.216.48; envelope-from=etotheipi@gmail.com; helo=mail-qa0-f48.google.com; Received: from mail-qa0-f48.google.com ([209.85.216.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7BZo-0005nd-1F for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:47:28 +0000 Received: by mail-qa0-f48.google.com with SMTP id o19so1356051qap.0 for ; Wed, 07 Aug 2013 14:47:22 -0700 (PDT) X-Received: by 10.224.12.81 with SMTP id w17mr2903891qaw.37.1375912042483; Wed, 07 Aug 2013 14:47:22 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id i1sm14101071qas.10.2013.08.07.14.47.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 14:47:21 -0700 (PDT) Message-ID: <5202C05B.8090509@gmail.com> Date: Wed, 07 Aug 2013 17:47:07 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------010800050007040508020100" X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V7BZo-0005nd-1F Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:47:29 -0000 This is a multi-part message in MIME format. --------------010800050007040508020100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------010800050007040508020100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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


--------------010800050007040508020100--