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; 
Message-ID: <5202C05B.8090509@gmail.com>
Date: Wed, 07 Aug 2013 17:47:07 -0400
From: Alan Reiner <etotheipi@gmail.com>
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: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
	<CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
	<CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
In-Reply-To: <CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------010800050007040508020100"
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Precedence: list

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 08/07/2013 05:10 PM, Gavin Andresen wrote:<br>
    <blockquote
cite="mid:CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com"
      type="cite">
      <pre wrap="">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.

</pre>
    </blockquote>
    I have avoided any notion of locking inputs in Armory for offline
    wallets.&nbsp; 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. &nbsp;&nbsp; Luckily, most users do one operation at a time, so
    it's not a real a problem.&nbsp; But as more businesses have started to
    use Armory, it <i>will</i> become a problem that will need to be
    addressed <i>somehow</i>. <br>
    <br>
    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.&nbsp; 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.&nbsp; Press this button
    if there are no transactions waiting to be broadcast").&nbsp; <br>
    <br>
    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.&nbsp; 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.&nbsp; I'd much
    rather say "either do one transaction at a time, or bundle payments
    into a single multi-output transaction.&nbsp; Or risk invalid
    transactions that have to be re-created and signed."<br>
    <br>
    -Alan<br>
    <br>
    <br>
  </body>
</html>

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