📅 Original date posted:2022-10-20
📝 Original message:On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
> bitcoin-dev wrote:
>> AJ previously wrote:
>> > presumably that makes your bitcoin
>> > payments break down as something like:
>> > 5% txs are on-chain and seem shady and are excluded from zeroconf
>> > 15% txs are lightning
>> > 20% txs are on-chain but signal rbf and are excluded from zeroconf
>> > 60% txs are on-chain and seem fine for zeroconf
>> Numbers are right. [...]
>
> [...]
>
> So the above suggests 25% of payments already get a sub-par experience
> [...]
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
Is it worth considering incremental steps between opt-in only (BIP125)
and replace anything full RBF? For example, in addition to opt-in RBF
rules, treat any transaction with a txid ending in `0x1` as replacable?
I assume 1/16th (6.25%) of transactions would match that pattern (some
of which already opt-in to RBF, so the net effect would be smaller).
This would have the following advantages:
1. We could see if miners are willing to enable unsignaled RBF at all
2. We could gather more evidence on how the change affects zeroconf
businesses and everyday users, hopefully without requiring they make
immediate and huge changes
3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding
their txids, at least until full RBF is accomplished
4. We can increase the percentage of transactions subject to unsignaled
RBF in later releases of Bitcoin Core, steadily moving the system
towards full RBF without any sudden leaps (assuming nobody builds a
successful relay and mining network with less restrictive replacement
rules)
I don't think this directly helps solve the problems with non-replacable
transactions suffered by contract protocols since any adversary can
opt-out of this scheme by grinding their txid, but I do think there's an
advantage in transitioning slowly when people are still depending on
previous behaviors.
Thanks,
-Dave
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 23:14:52
in reply to nevent1q…shqq
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:14:52Event JSON
{
"id": "5dda0cf94166eccba186f2bc583dbdd6c8480e5e7463bb199d2b3144c92a388f",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179692,
"kind": 1,
"tags": [
[
"e",
"946b9a8231803f73c278c08ca74b58bc34d6ba681eae8ff2a82e75b78f2e09ab",
"",
"root"
],
[
"e",
"d6befe24395a02fc54eec50c5ba332092f0db982d5cf12dffcae2f3efed2cc7c",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2022-10-20\n📝 Original message:On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:\n\u003e On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via \n\u003e bitcoin-dev wrote:\n\u003e\u003e AJ previously wrote:\n\u003e\u003e \u003e presumably that makes your bitcoin\n\u003e\u003e \u003e payments break down as something like:\n\u003e\u003e \u003e 5% txs are on-chain and seem shady and are excluded from zeroconf\n\u003e\u003e \u003e 15% txs are lightning\n\u003e\u003e \u003e 20% txs are on-chain but signal rbf and are excluded from zeroconf\n\u003e\u003e \u003e 60% txs are on-chain and seem fine for zeroconf\n\u003e\u003e Numbers are right. [...]\n\u003e \n\u003e [...]\n\u003e \n\u003e So the above suggests 25% of payments already get a sub-par experience \n\u003e [...]\n\u003e going full rbf would bump that from 25% to 85%, which would be pretty\n\u003e terrible.\n\nIs it worth considering incremental steps between opt-in only (BIP125) \nand replace anything full RBF? For example, in addition to opt-in RBF \nrules, treat any transaction with a txid ending in `0x1` as replacable? \nI assume 1/16th (6.25%) of transactions would match that pattern (some \nof which already opt-in to RBF, so the net effect would be smaller). \nThis would have the following advantages:\n\n1. We could see if miners are willing to enable unsignaled RBF at all\n\n2. We could gather more evidence on how the change affects zeroconf \nbusinesses and everyday users, hopefully without requiring they make \nimmediate and huge changes\n\n3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding \ntheir txids, at least until full RBF is accomplished\n\n4. We can increase the percentage of transactions subject to unsignaled \nRBF in later releases of Bitcoin Core, steadily moving the system \ntowards full RBF without any sudden leaps (assuming nobody builds a \nsuccessful relay and mining network with less restrictive replacement \nrules)\n\nI don't think this directly helps solve the problems with non-replacable \ntransactions suffered by contract protocols since any adversary can \nopt-out of this scheme by grinding their txid, but I do think there's an \nadvantage in transitioning slowly when people are still depending on \nprevious behaviors.\n\nThanks,\n\n-Dave",
"sig": "4561ac690c25c775a13d1e066d52f037221fcf8d3805c857c27224cb867ef446cad3faae359064e2c7b7bf63feee05413ad8772d8120e1055a5e468967428c15"
}