📅 Original date posted:2022-10-18
📝 Original message:Hello John,
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
> Simply, 0conf acceptance can be monitored and enforced by the merchant and exposure to doublespends can be both mitigated and limited in size per block. It is less expensive to be double-spent occasionally than to have a delayed checkout experience. Responsible 0conf acceptance is both rational and trusting.
29% of all transactions explicitly signal replaceability (see
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/), trend
rising. If ignoring risk is an acceptable approach now, why would it no
longer work when the remaining 71% of transactions also became subject
to replaceability?
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
> Now RBF just kinda haunts us as the establishment keeps baking it deeper and deeper into Bitcoin, despite almost no one using it, and despite it having negative consequences on more popular use cases.
How can RBF at the same time be hardly used as well as an incalculable risk?
Fact of the matter is that one can neither rely on having seen all
transactions that miners are considering for their block templates, nor
that a replacement be received by the miners before the original is
picked into a block.
We're between seats: first-seen is an unstable gentlemen's agreement,
inevitable to fail eventually once a few defect. Meanwhile propping up
the illusion of "reliable payment promises" is hampering price discovery
of blockspace and complicating protocol development. By converging on
the inevitable outcome and facilitating replaceability for all
transactions, we can rip off the band-aid rather than suffer uncertainty
indefinitely—even if it requires some to honestly reassess their
business approach in light of the natural modus operandi of Bitcoin's
gossip system.
Cheers,
Murch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xACFDB93A9175DCAB_and_old_rev.asc
Type: application/pgp-keys
Size: 119298 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.sig>;
Murch [ARCHIVE] /
npub148…ftkk4
2023-06-07 23:15:25
in reply to nevent1q…z7gu
Author Public Key
npub148nv6ef02rzspkm4wszntt77m9k80plvtgaxwrg9amxch2cmge0qxftkk4Published at
2023-06-07 23:15:25Event JSON
{
"id": "ac3452e47de707ec4ac2aad41a2a8aec7bb439378361423d72864299457d799c",
"pubkey": "a9e6cd652f50c500db75740535afded96c7787ec5a3a670d05eecd8bab1b465e",
"created_at": 1686179725,
"kind": 1,
"tags": [
[
"e",
"89970f4377ce419c8cdad2d3f0ffe79ad76f9b8568111e057fec0e041e25d1c4",
"",
"root"
],
[
"e",
"08aa60656178f335dda13b812f1d1fd96cd356693b725748c58c8886047660b0",
"",
"reply"
],
[
"p",
"02283afe5d7e6355ba7a0c2f5283e3149f651dab319cfb553d46a1d180234ed5"
]
],
"content": "📅 Original date posted:2022-10-18\n📝 Original message:Hello John,\n\nOn 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:\n\u003e Simply, 0conf acceptance can be monitored and enforced by the merchant and exposure to doublespends can be both mitigated and limited in size per block. It is less expensive to be double-spent occasionally than to have a delayed checkout experience. Responsible 0conf acceptance is both rational and trusting.\n\n29% of all transactions explicitly signal replaceability (see \nhttps://transactionfee.info/charts/transactions-signaling-explicit-rbf/), trend \nrising. If ignoring risk is an acceptable approach now, why would it no \nlonger work when the remaining 71% of transactions also became subject \nto replaceability?\n\nOn 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:\n\u003e Now RBF just kinda haunts us as the establishment keeps baking it deeper and deeper into Bitcoin, despite almost no one using it, and despite it having negative consequences on more popular use cases.\n\nHow can RBF at the same time be hardly used as well as an incalculable risk?\n\nFact of the matter is that one can neither rely on having seen all \ntransactions that miners are considering for their block templates, nor \nthat a replacement be received by the miners before the original is \npicked into a block.\nWe're between seats: first-seen is an unstable gentlemen's agreement, \ninevitable to fail eventually once a few defect. Meanwhile propping up \nthe illusion of \"reliable payment promises\" is hampering price discovery \nof blockspace and complicating protocol development. By converging on \nthe inevitable outcome and facilitating replaceability for all \ntransactions, we can rip off the band-aid rather than suffer uncertainty \nindefinitely—even if it requires some to honestly reassess their \nbusiness approach in light of the natural modus operandi of Bitcoin's \ngossip system.\n\nCheers,\nMurch\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OpenPGP_0xACFDB93A9175DCAB_and_old_rev.asc\nType: application/pgp-keys\nSize: 119298 bytes\nDesc: OpenPGP public key\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OpenPGP_signature\nType: application/pgp-signature\nSize: 833 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.sig\u003e",
"sig": "aeaae8f3492bcc9b05443f7dbccf6fe5911090bdadac38089de36356c64e795150add1db602e360ffe1b502a18d3c8044d62e5937cbbb2152ef0ec8ab71c39c4"
}