{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:In a fee-dominated future, replace-by-fee is not an opt-in feature. When\nyou create a transaction, the wallet presents a range of fees that it\nexpects you might pay. It then signs copies of the transaction with spaced\nfees from this interval and broadcasts the lowest fee first. In the user\ninterface, the transaction is shown with its transacted amount and the\napproved fee range. All of the inputs used are placed on hold until the\ntransaction gets a confirmation. As time goes by and it looks like the\ntransaction is not getting accepted, successively higher fee versions are\nreleased. You can opt-out and send a no-fee or base-fee-only transaction,\nbut that should not be the default.\n\nOn the receiving end, local policy controls how much fee should be spent\ntrying to obtain confirmations before alerting the user, if there are fees\navailable in the hot wallet to do this. The receiving wallet then adds its\nown fees via a spend if it thinks insufficient fees were provided to get a\nconfirmation. Again, this should all be automated so long as there is a hot\nwallet on the receiving end.\n\nIs this more complicated than now, where blocks are not full and clients\ngenerally don't have to worry about their transactions eventually\nconfirming? Yes, it is significantly more complicated. But such\ncomplication is unavoidable. It is a simple fact that the block size cannot\nincrease so much as to cover every single use by every single person in the\nworld, so there is no getting around the reality that we will have to\ntransition into an economy where at least one side has to pay up for a\ntransaction to get confirmation, at all. We are going to have to deal with\nthis issue whether it is now at 1MB or later at 20MB. And frankly, it'll be\nmuch easier to do now.\n\nOn Fri, May 8, 2015 at 4:15 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\n\u003e That's fair, and we've implemented child-pays-for-parent for spending\n\u003e unconfirmed inputs in breadwallet. But what should the behavior be when\n\u003e those options aren't understood/implemented/used?\n\u003e\n\u003e My argument is that the less risky, more conservative default fallback\n\u003e behavior should be either non-propagation or delayed confirmation, which is\n\u003e generally what we have now, until we hit the block size limit. We still\n\u003e have lots of safe, non-controversial, easy to experiment with options to\n\u003e add fee pressure, causing users to economize on block space without\n\u003e resorting to dropping transactions after a prolonged delay.\n\u003e\n\u003e Aaron Voisine\n\u003e co-founder and CEO\n\u003e breadwallet.com\n\u003e\n\u003e On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e This is a clever way to tie block size to fees.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I would just like to point out though that it still fundamentally is\n\u003e\u003e\u003e using hard block size limits to enforce scarcity. Transactions with below\n\u003e\u003e\u003e market fees will hang in limbo for days and fail, instead of failing\n\u003e\u003e\u003e immediately by not propagating, or seeing degraded, long confirmation times\n\u003e\u003e\u003e followed by eventual success.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e There are already solutions to this which are waiting to be deployed as\n\u003e\u003e default policy to bitcoind, and need to be implemented in other clients:\n\u003e\u003e replace-by-fee and child-pays-for-parent.\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/5302db5a/attachment.html\u003e"}