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 1VnAE1-0001jX-Kq for bitcoin-development@lists.sourceforge.net; Sun, 01 Dec 2013 16:50:29 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VnAE0-0003hu-JM for bitcoin-development@lists.sourceforge.net; Sun, 01 Dec 2013 16:50:29 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnADt-0000xh-0R for bitcoin-development@lists.sourceforge.net; Sun, 01 Dec 2013 17:50:21 +0100 Received: from e179039132.adsl.alicedsl.de ([85.179.39.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Dec 2013 17:50:21 +0100 Received: from andreas by e179039132.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Dec 2013 17:50:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Sun, 01 Dec 2013 17:50:10 +0100 Message-ID: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e179039132.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> X-Spam-Score: -0.4 (/) 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 [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VnAE0-0003hu-JM Subject: Re: [Bitcoin-development] Floating fees and SPV clients 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: Sun, 01 Dec 2013 16:50:29 -0000 (my post hasn't shown up for an hour, so I'm sending it again) On 12/01/2013 02:41 PM, Mike Hearn wrote: >> As long as the tx is not confirmed (by a broadcast), apps can offer to >> bump up the fee a little bit. > > Unfortunately there are risks to that approach. I assume you're right, since I do not have so much experience with game theory. About the UI: Generally, for pending tx I'd like to measure time they're not being broadcast-confirmed and count blocks that they missed being included. Both can be combined into adapting the current generic messages ("This payment should become spendable shortly" for incoming and "This payment has not been transmitted yet" for outgoing transactions). Hint: Statistics could be offered by bitcoinj. For outgoing transactions, if it is very clear that they're never going to be confirmed, I'd like to see a "Revoke" button. This would have saved us some support hassles with the transmit bugs. It could also offer a "Top up fee" button, which would replace the tx by a new one. I'm aware about a possible double spend but who cares? It doesn't matter which of the two transactions gets into the chain, as long as not both will be included.