📅 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>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:33:59
in reply to nevent1q…x9lp
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:33:59Event JSON
{
"id": "7634578aa80ecf5c6fd2a142c9e3c0c7cf47093e3c3422244244ed1c8d13a177",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152039,
"kind": 1,
"tags": [
[
"e",
"aec396df7693e37c124fbd2891fe6c4a3b28f46e7fbc3f304a7b1d78d2f5ffbe",
"",
"root"
],
[
"e",
"af286ec35024fc58ce77b9d679a312e85113d316882e5b40bd83f9379ee8f9ee",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 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",
"sig": "8af6b3c76a72271e6d194bde474c7327a0ccc2abf41c9d606fa5888826bfedee90d946f0c7b9bca9fa7c2b21d7fa80d8f17d66dea20f15881d62859b736ee11a"
}