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 1Ywyb4-0006bZ-8z for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 20:03:38 +0000 X-ACL-Warn: Received: from resqmta-po-03v.sys.comcast.net ([96.114.154.162]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1Ywyb3-0006ns-8b for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 20:03:38 +0000 Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-03v.sys.comcast.net with comcast id YL3L1q00458ss0Y01L3XD0; Mon, 25 May 2015 20:03:31 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6]) by resomta-po-14v.sys.comcast.net with comcast id YL3V1q00D2JF60R01L3W3j; Mon, 25 May 2015 20:03:31 +0000 From: Matt Whitlock To: Mike Hearn Date: Mon, 25 May 2015 16:03:28 -0400 Message-ID: <1515563.NQHYuaqTfB@crushinator> User-Agent: KMail/4.14.8 (Linux/3.18.11-gentoo; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: <2114827.D6GUhXtGkV@crushinator> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [96.114.154.162 listed in list.dnswl.org] 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: 1Ywyb3-0006ns-8b Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database 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: Mon, 25 May 2015 20:03:38 -0000 On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote: > > some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you > > can only spend confirmed UTXOs. I can't tell you how aggravating it is to > > have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for > > the last transaction I did to confirm first." All the more aggravating > > because I know, if I have multiple UTXOs in my wallet, I can make multiple > > spends within the same block. > > Andreas' wallet hasn't done that for years. Are you repeating this from > some very old memory or do you actually see this issue in reality? > > The only time you're forced to wait for confirmations is when you have an > unconfirmed inbound transaction, and thus the sender is unknown. I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30. The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, "You need x.xxxxxx more bitcoins to make this payment." But if you wait for your first payment to confirm, then you'll be able to make the second payment. If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as "Sent" until they appear in a block, presumably because the app never sees the transaction come in over any connection.