{"type":"rich","version":"1.0","author_name":"npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","author_url":"https://nostr.ae/npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:That's fair, and we've implemented child-pays-for-parent for spending\nunconfirmed inputs in breadwallet. But what should the behavior be when\nthose options aren't understood/implemented/used?\n\nMy argument is that the less risky, more conservative default fallback\nbehavior should be either non-propagation or delayed confirmation, which is\ngenerally what we have now, until we hit the block size limit. We still\nhave lots of safe, non-controversial, easy to experiment with options to\nadd fee pressure, causing users to economize on block space without\nresorting to dropping transactions after a prolonged delay.\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e This is a clever way to tie block size to fees.\n\u003e\u003e\n\u003e\u003e I would just like to point out though that it still fundamentally is\n\u003e\u003e using hard block size limits to enforce scarcity. Transactions with below\n\u003e\u003e market fees will hang in limbo for days and fail, instead of failing\n\u003e\u003e immediately by not propagating, or seeing degraded, long confirmation times\n\u003e\u003e followed by eventual success.\n\u003e\u003e\n\u003e\n\u003e There are already solutions to this which are waiting to be deployed as\n\u003e default policy to bitcoind, and need to be implemented in other clients:\n\u003e replace-by-fee and child-pays-for-parent.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/561f60f5/attachment.html\u003e"}