Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-08 📝 Original message:Transactions don't expire. ...
📅 Original date posted:2015-05-08
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/a201447f/attachment.html>;
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/a201447f/attachment.html>;