Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain
-Raystonn On 8 May 2015 1:41 pm, Mark Friedenbach <m...@friedenbach.org> wrote: > > Transactions don't expire. But if the wallet is online, it can periodically > choose to release an already created transaction with a higher fee. This > requires replace-by-fee to be sufficiently deployed, however. > > On Fri, May 8, 2015 at 1:38 PM, Raystonn . <rayst...@hotmail.com> wrote: >> >> I have a proposal for wallets such as yours. How about creating all >> transactions with an expiration time starting with a low fee, then replacing >> with new transactions that have a higher fee as time passes. Users can pick >> the fee curve they desire based on the transaction priority they want to >> advertise to the network. Users set the priority in the wallet, and the >> wallet software translates it to a specific fee curve used in the series of >> expiring transactions. In this manner, transactions are never left hanging >> for days, and probably not even for hours. >> >> -Raystonn >> >> On 8 May 2015 1:17 pm, Aaron Voisine <vois...@gmail.com> wrote: >>> >>> As the author of a popular SPV wallet, I wanted to weigh in, in support of >>> the Gavin's 20Mb block proposal. >>> >>> The best argument I've heard against raising the limit is that we need fee >>> pressure. I agree that fee pressure is the right way to economize on >>> scarce resources. Placing hard limits on block size however is an >>> incredibly disruptive way to go about this, and will severely negatively >>> impact users' experience. >>> >>> When users pay too low a fee, they should: >>> >>> 1) See immediate failure as they do now with fees that fail to propagate. >>> >>> 2) If the fee lower than it should be but not terminal, they should see >>> degraded performance, long delays in confirmation, but eventual success. >>> This will encourage them to pay higher fees in future. >>> >>> The worst of all worlds would be to have transactions propagate, hang in >>> limbo for days, and then fail. This is the most important scenario to >>> avoid. Increasing the 1Mb block size limit I think is the simplest way to >>> avoid this least desirable scenario for the immediate future. >>> >>> We can play around with improved transaction selection for blocks and >>> encourage miners to adopt it to discourage low fees and create fee >>> pressure. These could involve hybrid priority/fee selection so low fee >>> transactions see degraded performance instead of failure. This would be the >>> conservative low risk approach. >>> >>> Aaron Voisine >>> co-founder and CEO >>> breadwallet.com >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
