Re: [Bitcoin-development] Block Size Increase

[Raystonn <raystonn@hotmail.com>]

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 <mark@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 . <raystonn@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 <voisine@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
>>
>