rich1.0npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlhttps://nostr.ae/npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlnjumphttps://nostr.ae📅 Original date posted:2015-05-08 📝 Original message:That's fair, and we've implemented child-pays-for-parent for spending unconfirmed inputs in breadwallet. But what should the behavior be when those options aren't understood/implemented/used? My argument is that the less risky, more conservative default fallback behavior should be either non-propagation or delayed confirmation, which is generally what we have now, until we hit the block size limit. We still have lots of safe, non-controversial, easy to experiment with options to add fee pressure, causing users to economize on block space without resorting to dropping transactions after a prolonged delay. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach <mark at friedenbach.org> wrote: > On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine at gmail.com> wrote: > >> This is a clever way to tie block size to fees. >> >> I would just like to point out though that it still fundamentally is >> using hard block size limits to enforce scarcity. Transactions with below >> market fees will hang in limbo for days and fail, instead of failing >> immediately by not propagating, or seeing degraded, long confirmation times >> followed by eventual success. >> > > There are already solutions to this which are waiting to be deployed as > default policy to bitcoind, and need to be implemented in other clients: > replace-by-fee and child-pays-for-parent. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/561f60f5/attachment.html>