(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. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development