MIME-Version: 1.0
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
 <Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au>
 <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com>
 <Y05PHYtrNmA0vg7U@erisian.com.au>
In-Reply-To: <Y05PHYtrNmA0vg7U@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 18 Oct 2022 23:01:12 -0400
Message-ID: <CALZpt+Fyp+6VUB5cUmKCbTgzd5yOUSdtGADrzSZgLU_vFY8Lqw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000008c99df05eb5a6cd9"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

--0000000000008c99df05eb5a6cd9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.

Yes, this has been the crux of the conceptual discussion in #25600.

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.

In the present case, I don't think there is a real concern of a frivolous
or half-baked lawsuit. My concern is rather the pretension to omniscience
that we would adopt as Core devs w.r.t policy changes, as far from being a
more closed, hermetic system like the p2p stack, it's interfacing with the
operations of a number of Bitcoin applications and second-layer contracting
protocols. As of today, I think this is still a relatively short process to
analyze the implications of any policy changes on the major Bitcoin
applications
flows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure
this statement will stay true in a future with a growing fauna of L2s (i.e
vaults, DLC-over-channel, peerswaps, etc), each presenting unique
characteristics.

How do we minimize the odds of policy-based disruptions for current Bitcoin
softwares and users ? I don't have strong ideas, though I wish for the Core
project to adopt a more open-ended and smooth approach to release
context-rich policy changes. I aimed with #25353 and #25600 to experiment
with such a smoother approach advocated for (rather than the last year
proposal of turning on by default full-rbf, that was a wrong and missing
context). I hope at least one good outcome of this gradual process has been
to give time to Dario to publish a thoughtful standpoint for 0conf
operators, of which at least I learnt a few interesting elements on the UX
of such applications.

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable=
,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Yeah, I'm still valuing the mailing list as a kind of "broadcast-all"
communication channel towards all the community stakeholders, though this
is the perspective of a developer and I'm not sure business/services
operators have the same communication habits. There is definitely a
reflection to hold, if we, as Core devs, we should follow a better
communication standard when we propose significant policy changes. And go
the full-tour of Reddit AMA, podcasts and newsletters as suggested in my
reply to Dario. It's hard to know if lack of vocal reactions on the mailing
list or to the publication of optech newsletter signifies a lack of
opposition, a lack of negatively impacted users or lack of interest from
the wider community. Maybe we should have a formalized, bulletpoints -based
for future policy changes, with clear time buffers and actions items, I
don't know.

> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

In the present case, it's more a lack of feedback showing up until we start
doing rcs, rather than a pretty closed-off way of doing things. That we
should amend expected and already-merged changes in the function of
feedback, I'm all for it in principle. The hard question is the set of
decision heuristics to converge on to qualify such feedback as worthy to
react on. Again in this case, we're doing some risk arbitrage (which I
really dislike as a situation) between 0conf applications and multi-party
funding flows of contracting protocols. Correcting our release process
isn't free of implications as we're removing the risk burden on some class
of use-case to pour it on a second class, in my opinion. Moreover, assuming
we have to bind to reasonable communication standards which is an open
question, I'm also worried we would also normalize the publication of very
late feedback from community stakeholders.

> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.

First, without more visibility brought back on the 0confs operations
necessary to adapt their operations, two months might be considered as
enough. 8 weeks is sensibly the release schedule followed by few
open-source projects in the ecosystem. Second, the communication machine
behind softforks activation sounds to be far more fine-tuned, or at least
gather spontaneously community self-coordination than policy changes, and
it would be reasonable to expect things to be slower with policy changes.
However, I would agree you can have a quick adoption a day from another
with one single well-crafted meme buzzing on Twitter. Social phenomenas
don't offer the same degree of predictability than system engineering. How
we cope up with that, as core devs, I don't know.

> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks=
.

I'm not sure if it has been established clearly, though as I announced on
IRC two weeks ago, Dario reached out to me offline before publishing his
mail. My recommendation to him have been immediately to adjoin 0confs
services examples impacted, if possible with numbers on users affected and
evaluation of engineering and operational effort if would request to adapt
their use-cases, and inviting to publish on this venue, as business
operators might not be used to with open-source process (I can disclose the
correspondence if requested and with Dario approval).

Goal was to collect the maximum of data points in our community
decision-making process about full-rbf. Now this doesn't relieve us of
finding a common ground on what should be a minimal bar to accept those
points, how to value those data
points, if we should take operators on their raw numbers or request the
publication of "light" proofs like on-chain transactions, lightning
invoices (everyone in business would take the happy measure showing the
most active users possible). The question of what signals we should
collect, and how we process them is a hard question in a decentralized and
trust-minimized process like the Bitcoin development one, from my
perspective. I don't have strong ideas there.

Though speaking for myself, and not for other contributors, I've raised the
warnings about potential impacts of full-rbfs in both my June 2021 [0] and
June 2022 [1] mails, so I find the qualification of disingenuous is a bit
ungrounded. Overall, I would remind all that it's better to keep patience
in face of complex changes in Core, rather than to fall quickly in a blame
ascription position.

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.ht=
ml
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.ht=
ml

(I don't deny "blame-and-reward" assignments can be worthy a posteriori,
once we're out of the "hot" discussion phase, especially to introspect on
how we can improve our engineering process, though in the middle of a
discussion... I don't know, it sounds premature and noisy).

> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)

I can share the sentiment about mainstream economics and the way
risk-management impacts large-range of human beings is completely shrug
on... Though again in the present case, I think it would be more productive
to describe what engineering
needs or standards expectations of you are not fulfilled rather than to
fallback on the pure expression of an uncomfortableness and how as a
community of contributors we could improve on that. Though to object,
speaking of risk appreciation, not hardening the funding phase of
multi-party funding protocols also lets the door open to DoS attacks by
deanonymizing attackers targeting things like coinjoin.

> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?

I agree. I would like to observe that "reasonable time to react" and
"adequate risk statement" is more an art than a science.

> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").

About John Carvalho disagreeing about full-rbf, I think he voiced a concern
during the summer on one of the PR introducing a full-rbf setting and I did
invite to voice his concerns on the ML, invitation stayed without follow-up
until the recent days [2] [3]. I would have loved to spend time back then
arguing on the full-rbf and miners incentives compatibility.

[2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654
[3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017

I know we all have busy agendas and a short timeline to react to all the
changes happening in the Bitcoin ecosystem... I think I replied to John
Carvalho answer on this thread, inviting him to develop his argumentation
further and I'm staying available to discuss with any full-rbf opponents,
in a calm and respectful fashion [4].

[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027=
.html

> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.

Yeah I mean this could have been a forward process before Dario published
his thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would
have assumed landing #25600 _and_ actually reach out to few mining pools to
inform them about the potential economic benefits. Now, I think the best
process is to keep listening to more feedback from the community, lay out
all the deployment options in code we have done and think more before
committing to something.

> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?

I think this might be the point where I could say we're diverging. In
principle, I agree we should listen to negative feedback raising harmful
disruptions risks for users and services. The more open, practical question
to me is more how we collect, qualify and sanitize such negative feedback
in a way which is acceptable for the community at large. Giving concrete
bounds to the immediate dangers in a consensual way, and asserting this
danger results from a lack of communication of the Core project, I'm still
wondering on those subjects. And note again, I didn't deny the option 3)
approach as you laid out was zero-risk for 0conf operators.

All that said, if we think as a project we should offer a "zero-risk"
process towards 0conf operators w.r.t full-rbf, at the detriment of the
risk encumbered by contracting protocols, I think it can be wise to
resurrect #26287.

Best,
Antoine

Le mar. 18 oct. 2022 =C3=A0 03:00, Anthony Towns <aj@erisian.com.au> a =C3=
=A9crit :

> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > >  1) Continue supporting and encouraging accepting unconfirmed
> "on-chain"
> > >     payments indefinitely
> > >  2) Draw a line in the sand now, but give people who are currently
> > >     accepting unconfirmed txs time to update their software and
> business
> > >     model
> > >  3) Encourage mainnet miners and relay nodes to support unconditional
> > >     RBF immediately, no matter how much that increases the risk to
> > >     existing businesses that are still accepting unconfirmed txs
> > To give more context, the initial approach of enabling full RBF through
> > #25353 + #25600 wasn't making the assumption the enablement itself woul=
d
> > reach agreement of the economic majority or unanimity.
>
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
>
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
>
> > Without denying that such equilibrium would be unstable, it was designe=
d
> to
> > remove the responsibility of the Core project itself to "draw a hard
> line"
> > on the subject.
>
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
>
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.
>
> At that point, the technical experts *should* be coming up with a
> specific recommendation, and, personally, I think that's exactly what
> happened with [0] [1] and [2].
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033=
.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.=
html
>
> That did draw hard line in the sand: it said "hey, opt-in RBF had a good
> run, but it's time to switch over to full RBF, for these reasons".
>
> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable=
,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").
>
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
>
> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.
>
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to rea=
ct
> > in consequence.
>
> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.
>
> > So the current path definitely belongs more to a 3) approach.
>
> > >  3) Encourage mainnet miners and relay nodes to support unconditional
> > >     RBF immediately, no matter how much that increases the risk to
> > >     existing businesses that are still accepting unconfirmed txs
>
> Yes, that's how it appears to me, too. It's not my preference (giving
> people clear warning of changes seems much better to me), but I can
> certainly live with it.
>
> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks=
.
>
> That is, it seems to me that Dario was exactly right in titling this
> thread "Zero-conf apps in immediate danger", and our co-developers who
> are dismissing the risk by saying things along the lines of "probably
> nothing will change anytime soon" are exactly wrong.
>
> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)
>
> > While this
> > way cannot be denied to be a zero-risk deployment for business acceptin=
g
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
>
> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?
>
> > Since Dario's mail, I think we have learnt new data points, a) on the
> long
> > term full RBF to align miner incentives is acknowledged and b) a clear
> > timeline based on e.g a block height is favored over the pollination
> > deployment.
>
> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").
>
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
>
> Slowing that down from January-ish to May seems like it ought to be a
> big win for anyone who has been doing zeroconf, and having it be easy
> to find a path to miners when it is supported seems like a big win even
> given a cost of a few months delay.
>
> OTOH, if we're really not expecting full rbf to be available for many
> months, then I would have expected the "disable this for mainnet,
> reconsider after the release" PR (#26287) to have gone ahead already.
>
> > Tie-breaking between
> > both, I believe I would favor something like #26323 though only post 24=
.0
> > to avoid introducing a bikeshedding precedent in terms of release
> process,
>
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
>
> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?
>
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.
>
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
>
> Cheers,
> aj
>
>

--0000000000008c99df05eb5a6cd9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Full RBF doesn&#39;t need a majority or unanimity to =
have an impact; it needs<br>&gt; adoption by perhaps 10% of hashrate (so a =
low fee tx at the bottom of<br>&gt; a 10MvB mempool can be replaced before =
being mined naturally), and some<br>&gt; way of finding a working path to r=
elay txs to that hashrate.<br><br>Yes, this has been the crux of the concep=
tual discussion in #25600.<br><br>&gt; I mean, I guess I can understand wan=
ting to reduce that responsibility<br>&gt; for maintainers of the github re=
po, even if for no other reason than to<br>&gt; avoid frivolous lawsuits, b=
ut where do you expect people to find better<br>&gt; advice about what thin=
gs are a good/bad idea if core devs as a whole<br>&gt; are avoiding that re=
sponsibility?<br>&gt; <br>&gt; Core devs are supposedly top technical exper=
ts at bitcoin -- which means<br>&gt; they&#39;re the ones that should have =
the best understanding of all the<br>&gt; implications of policy changes li=
ke this. Is opt-in RBF only fine? If<br>&gt; you look at the network today,=
 it sure seems like it; it takes a pretty<br>&gt; good technical understand=
ing to figure out what problems it has, and<br>&gt; an even better one to f=
igure out whether those problems can be solved<br>&gt; while keeping an opt=
-in RBF regime, or if full RBF is needed.<br><br>In the present case, I don=
&#39;t think there is a real concern of a frivolous or half-baked lawsuit. =
My concern is rather the pretension to omniscience that we would adopt as C=
ore devs w.r.t policy changes, as far from being a more closed, hermetic sy=
stem like the p2p stack, it&#39;s interfacing with the operations of a numb=
er of Bitcoin applications and second-layer contracting protocols. As of to=
day, I think this is still a relatively short process to analyze the implic=
ations of any policy changes on the major Bitcoin applications<br>flows and=
 L2s of the day (i.e mainly Lightning and coinjoins). I&#39;m not sure this=
 statement will stay true in a future with a growing fauna of L2s (i.e vaul=
ts, DLC-over-channel, peerswaps, etc), each presenting unique characteristi=
cs.<br><br>How do we minimize the odds of policy-based disruptions for curr=
ent Bitcoin softwares and users ? I don&#39;t have strong ideas, though I w=
ish for the Core project to adopt a more open-ended and smooth approach to =
release context-rich policy changes. I aimed with #25353 and #25600 to expe=
riment with such a smoother approach advocated for (rather than the last ye=
ar proposal of turning on by default full-rbf, that was a wrong and missing=
 context). I hope at least one good outcome of this gradual process has bee=
n to give time to Dario to publish a thoughtful standpoint for 0conf operat=
ors, of which at least I learnt a few interesting elements on the UX of suc=
h applications.<br><br>&gt; It&#39;s a bit disappointing that the people th=
at&#39;s a problem for didn&#39;t<br>&gt; engage earlier -- though looking =
back, I guess there wasn&#39;t all that<br>&gt; much effort made to reach o=
ut, either. There were two mentions in the<br>&gt; optech newsletter [3] [4=
] but it wasn&#39;t called out as an &quot;action item&quot;<br>&gt; (maybe=
 those aren&#39;t a thing anymore), so it may have been pretty missable,<br=
>&gt; especially given RBF has been discussed on and off for so long. And t=
he<br>&gt; impression I got from the PR review club discussion more seemed =
like<br>&gt; devs making assumptions about businesses rather than having ta=
lked to<br>&gt; them (eg &quot;[I] think there are fewer and fewer business=
es who absolutely<br>&gt; cannot survive without relying on zeroconf. Or at=
 least hope so&quot;).<br><br>Yeah, I&#39;m still valuing the mailing list =
as a kind of &quot;broadcast-all&quot; communication channel towards all th=
e community stakeholders, though this is the perspective of a developer and=
 I&#39;m not sure business/services operators have the same communication h=
abits. There is definitely a reflection to hold, if we, as Core devs, we sh=
ould follow a better communication standard when we propose significant pol=
icy changes. And go the full-tour of Reddit AMA, podcasts and newsletters a=
s suggested in my reply to Dario. It&#39;s hard to know if lack of vocal re=
actions on the mailing list or to the publication of optech newsletter sign=
ifies a lack of opposition, a lack of negatively impacted users or lack of =
interest from the wider community. Maybe we should have a formalized, bulle=
tpoints -based for future policy changes, with clear time buffers and actio=
ns items, I don&#39;t know.<br><br>&gt; If we&#39;re happy to not get feedb=
ack until we start doing rcs, that&#39;s fine;<br>&gt; but if we want to sa=
y &quot;oops, we&#39;re into release candidates, you should<br>&gt; have so=
mething earlier, it&#39;s too late now&quot;, that&#39;s a pretty closed-of=
f<br>&gt; way of doing things.<br>&gt; <br>&gt; And I mean: all this is onl=
y about drawing a line in *sand*; if people<br>&gt; think core devs are wro=
ng, they can still let that line blow away in<br>&gt; the wind, by running =
different software, configuring core differently,<br>&gt; patching core, or=
 whatever else.<br><br>In the present case, it&#39;s more a lack of feedbac=
k showing up until we start doing rcs, rather than a pretty closed-off way =
of doing things. That we should amend expected and already-merged changes i=
n the function of feedback, I&#39;m all for it in principle. The hard quest=
ion is the set of decision heuristics to converge on to qualify such feedba=
ck as worthy to react on. Again in this case, we&#39;re doing some risk arb=
itrage (which I really dislike as a situation) between 0conf applications a=
nd multi-party funding flows of contracting protocols. Correcting our relea=
se process isn&#39;t free of implications as we&#39;re removing the risk bu=
rden on some class of use-case to pour it on a second class, in my opinion.=
 Moreover, assuming we have to bind to reasonable communication standards w=
hich is an open question, I&#39;m also worried we would also normalize the =
publication of very late feedback from community stakeholders.<br><br>&gt; =
I don&#39;t think that&#39;s remotely true: take a look at taproot activati=
on:<br>&gt; it took two months between releasing code that supported signal=
ling and<br>&gt; having 98% of hashrate signalling; with 40% of blocks sign=
alling within<br>&gt; the first two weeks.<br><br>First, without more visib=
ility brought back on the 0confs operations necessary to adapt their operat=
ions, two months might be considered as enough. 8 weeks is sensibly the rel=
ease schedule followed by few open-source projects in the ecosystem. Second=
, the communication machine behind softforks activation sounds to be far mo=
re fine-tuned, or at least gather spontaneously community self-coordination=
 than policy changes, and it would be reasonable to expect things to be slo=
wer with policy changes. However, I would agree you can have a quick adopti=
on a day from another with one single well-crafted meme buzzing on Twitter.=
 Social phenomenas don&#39;t offer the same degree of predictability than s=
ystem engineering. How we cope up with that, as core devs, I don&#39;t know=
.<br><br>&gt; But if the line in the sand is &quot;we&#39;re doing this, no=
 matter how much that<br>&gt; increases the risk to existing businesses tha=
t weren&#39;t expecting it&quot; then<br>&gt; it seems *very* disingenuous =
not to make those risks very clear so that<br>&gt; people who weren&#39;t e=
xpecting it actually take action to avoid those risks.<br><br>I&#39;m not s=
ure if it has been established clearly, though as I announced on IRC two we=
eks ago, Dario reached out to me offline before publishing his mail. My rec=
ommendation to him have been immediately to adjoin 0confs services examples=
 impacted, if possible with numbers on users affected and evaluation of eng=
ineering and operational effort if would request to adapt their use-cases, =
and inviting to publish on this venue, as business operators might not be u=
sed to with open-source process (I can disclose the correspondence if reque=
sted and with Dario approval).<br><br>Goal was to collect the maximum of da=
ta points in our community decision-making process about full-rbf. Now this=
 doesn&#39;t relieve us of finding a common ground on what should be a mini=
mal bar to accept those points, how to value those data<br>points, if we sh=
ould take operators on their raw numbers or request the publication of &quo=
t;light&quot; proofs like on-chain transactions, lightning invoices (everyo=
ne in business would take the happy measure showing the most active users p=
ossible). The question of what signals we should collect, and how we proces=
s them is a hard question in a decentralized and trust-minimized process li=
ke the Bitcoin development one, from my perspective. I don&#39;t have stron=
g ideas there.<br><br>Though speaking for myself, and not for other contrib=
utors, I&#39;ve raised the warnings about potential impacts of full-rbfs in=
 both my June 2021 [0] and June 2022 [1] mails, so I find the qualification=
 of disingenuous is a bit=C2=A0 ungrounded. Overall, I would remind all tha=
t it&#39;s better to keep patience in face of complex changes in Core, rath=
er than to fall quickly in a blame ascription position.<br><br>[0] <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/01907=
4.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/0=
19074.html</a><br>[1] <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2022-June/020557.html">https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2022-June/020557.html</a><br><br>(I don&#39;t deny &quot;=
blame-and-reward&quot; assignments can be worthy a posteriori, once we&#39;=
re out of the &quot;hot&quot; discussion phase, especially to introspect on=
 how we can improve our engineering process, though in the middle of a disc=
ussion... I don&#39;t know, it sounds premature and noisy).<br><br>&gt; (Mo=
re generally, that&#39;s similar to one of the things I&#39;ve hated<br>&gt=
; watching in mainstream economics over the past few years: &quot;doing thi=
s<br>&gt; will cause massive inflation&quot; &quot;no it won&#39;t, there&#=
39;s no inflation risk&quot;<br>&gt; &quot;oops, inflation magically appear=
ed, how did that happen? oh well, too<br>&gt; bad, we have to live with it =
now&quot;. This looks pretty similar to me: &quot;do<br>&gt; something risk=
y, deny the risk, make sure nobody can hold us accountable<br>&gt; when the=
 risk eventuates later&quot; so it makes me really uncomfortable)<br><br>I =
can share the sentiment about mainstream economics and the way risk-managem=
ent impacts large-range of human beings is completely shrug on... Though ag=
ain in the present case, I think it would be more productive to describe wh=
at engineering<br>needs or standards expectations of you are not fulfilled =
rather than to fallback on the pure expression of an uncomfortableness and =
how as a community of contributors we could improve on that. Though to obje=
ct, speaking of risk appreciation, not hardening the funding phase of multi=
-party funding protocols also lets the door open to DoS attacks by deanonym=
izing attackers targeting things like coinjoin.<br><br>&gt; Sure; that&#39;=
s a fine reason to draw the line in the sand. But it&#39;s not<br>&gt; a go=
od reason to have it happen immediately, rather than giving people<br>&gt; =
time to react, and it&#39;s not a good reason to understate the risk of<br>=
&gt; it happening now. Maybe there are good reasons for either or both of<b=
r>&gt; those, though?<br><br>I agree. I would like to observe that &quot;re=
asonable time to react&quot; and &quot;adequate risk statement&quot; is mor=
e an art than a science.<br><br>&gt; Using the passive voice there doesn=
9;t seem helpful. Who learnt these<br>&gt; things? You, I and Dario all see=
m to agree with (a), but John Carvalho<br>&gt; certainly appears not to, fo=
r instance. I&#39;m not sure who agrees with<br>&gt; (b) -- I know I do, an=
d I think Dario does; but multiple people seem<br>&gt; opposed to the clear=
 timeline offered in #26323, and your #26305 seems<br>&gt; more likely to e=
ncourage a &quot;pollination&quot; approach rather than discourage<br>&gt; =
it (&quot;oh, this will be the default option for 25.0, might as well enabl=
e<br>&gt; it now like all the cool kids are&quot;).<br><br>About John Carva=
lho disagreeing about full-rbf, I think he voiced a concern during the summ=
er on one of the PR introducing a full-rbf setting and I did invite to voic=
e his concerns on the ML, invitation stayed without follow-up until the rec=
ent days [2] [3]. I would have loved to spend time back then=C2=A0 arguing =
on the full-rbf and miners incentives compatibility.<br><br>[2] <a href=3D"=
https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654">http=
s://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654</a><br>[3=
] <a href=3D"https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-116=
3815017">https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815=
017</a><br><br>I know we all have busy agendas and a short timeline to reac=
t to all the changes happening in the Bitcoin ecosystem... I think I replie=
d to John Carvalho answer on this thread, inviting him to develop his argum=
entation further and I&#39;m staying available to discuss with any full-rbf=
 opponents, in a calm and respectful fashion [4].<br><br>[4] <a href=3D"htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027.ht=
ml">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/02=
1027.html</a><br><br>&gt; For what it&#39;s worth, my guess is that releasi=
ng core with full rbf<br>&gt; support and having you and Murch and others a=
dvocating for people to<br>&gt; try it out, will mean that full RBF is usab=
le on mainnet within two<br>&gt; or three months, supported by perhaps 5%-2=
0% hashpower, but probably<br>&gt; still requiring special effort to actual=
ly find a peer that can relay<br>&gt; full rbf txs to that hashpower (proba=
bly doing an addnode, despite the<br>&gt; privacy implications). Even if th=
at happens, I&#39;m not super confident<br>&gt; that it would mean people w=
ould actively steal from zeroconf businesses<br>&gt; in any volume, though.=
 It&#39;s not something I&#39;d risk happening to me,<br>&gt; but accepting=
 zeroconf from strangers isn&#39;t something I&#39;d risk anyway.<br><br>Ye=
ah I mean this could have been a forward process before Dario published his=
 thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would have a=
ssumed landing #25600 _and_ actually reach out to few mining pools to infor=
m them about the potential economic benefits. Now, I think the best process=
 is to keep listening to more feedback from the community, lay out all the =
deployment options in code we have done and think more before committing to=
 something.<br><br>&gt; And if the choice is between &quot;bikeshedding&quo=
t; and &quot;merge a PR, then ignore<br>&gt; feedback that it&#39;s harmful=
&quot;, I&#39;d much rather the bikeshedding. What&#39;s<br>&gt; the point =
of having rcs if you&#39;re going to ignore negative feedback?<br><br>I thi=
nk this might be the point where I could say we&#39;re diverging. In princi=
ple, I agree we should listen to negative feedback raising harmful disrupti=
ons risks for users and services. The more open, practical question to me i=
s more how we collect, qualify and sanitize such negative feedback in a way=
 which is acceptable for the community at large. Giving concrete bounds to =
the immediate dangers in a consensual way, and asserting this danger result=
s from a lack of communication of the Core project, I&#39;m still wondering=
 on those subjects. And note again, I didn&#39;t deny the option 3) approac=
h as you laid out was zero-risk for 0conf operators.<br><br>All that said, =
if we think as a project we should offer a &quot;zero-risk&quot; process to=
wards 0conf operators w.r.t full-rbf, at the detriment of the risk encumber=
ed by contracting protocols, I think it can be wise to resurrect #26287.<br=
><br>Best,<br>Antoine<br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">Le=C2=A0mar. 18 oct. 2022 =C3=A0=C2=A003:00, Antho=
ny Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt;=
 a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-de=
v wrote:<br>
&gt; &gt;=C2=A0 1) Continue supporting and encouraging accepting unconfirme=
d &quot;on-chain&quot;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0payments indefinitely<br>
&gt; &gt;=C2=A0 2) Draw a line in the sand now, but give people who are cur=
rently<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0accepting unconfirmed txs time to update their=
 software and business<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0model<br>
&gt; &gt;=C2=A0 3) Encourage mainnet miners and relay nodes to support unco=
nditional<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0RBF immediately, no matter how much that incre=
ases the risk to<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0existing businesses that are still accepting u=
nconfirmed txs<br>
&gt; To give more context, the initial approach of enabling full RBF throug=
h<br>
&gt; #25353 + #25600 wasn&#39;t making the assumption the enablement itself=
 would<br>
&gt; reach agreement of the economic majority or unanimity. <br>
<br>
Full RBF doesn&#39;t need a majority or unanimity to have an impact; it nee=
ds<br>
adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of<br>
a 10MvB mempool can be replaced before being mined naturally), and some<br>
way of finding a working path to relay txs to that hashrate.<br>
<br>
Having a majority of nodes/hashrate support it makes the upsides better,<br=
>
but doesn&#39;t change the downsides to the people who are relying on it<br=
>
not being available.<br>
<br>
&gt; Without denying that such equilibrium would be unstable, it was design=
ed to<br>
&gt; remove the responsibility of the Core project itself to &quot;draw a h=
ard line&quot;<br>
&gt; on the subject.<br>
<br>
Removing responsibility from core developers seems like it&#39;s very much<=
br>
optimising for the wrong thing to me.<br>
<br>
I mean, I guess I can understand wanting to reduce that responsibility<br>
for maintainers of the github repo, even if for no other reason than to<br>
avoid frivolous lawsuits, but where do you expect people to find better<br>
advice about what things are a good/bad idea if core devs as a whole<br>
are avoiding that responsibility?<br>
<br>
Core devs are supposedly top technical experts at bitcoin -- which means<br=
>
they&#39;re the ones that should have the best understanding of all the<br>
implications of policy changes like this. Is opt-in RBF only fine? If<br>
you look at the network today, it sure seems like it; it takes a pretty<br>
good technical understanding to figure out what problems it has, and<br>
an even better one to figure out whether those problems can be solved<br>
while keeping an opt-in RBF regime, or if full RBF is needed.<br>
<br>
At that point, the technical experts *should* be coming up with a<br>
specific recommendation, and, personally, I think that&#39;s exactly what<b=
r>
happened with [0] [1] and [2].<br>
<br>
[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/20=
21-May/003033.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a><br>
[1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/25353" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/25353</a><b=
r>
[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020557.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-June/020557.html</a><br>
<br>
That did draw hard line in the sand: it said &quot;hey, opt-in RBF had a go=
od<br>
run, but it&#39;s time to switch over to full RBF, for these reasons&quot;.=
<br>
<br>
It&#39;s a bit disappointing that the people that&#39;s a problem for didn&=
#39;t<br>
engage earlier -- though looking back, I guess there wasn&#39;t all that<br=
>
much effort made to reach out, either. There were two mentions in the<br>
optech newsletter [3] [4] but it wasn&#39;t called out as an &quot;action i=
tem&quot;<br>
(maybe those aren&#39;t a thing anymore), so it may have been pretty missab=
le,<br>
especially given RBF has been discussed on and off for so long. And the<br>
impression I got from the PR review club discussion more seemed like<br>
devs making assumptions about businesses rather than having talked to<br>
them (eg &quot;[I] think there are fewer and fewer businesses who absolutel=
y<br>
cannot survive without relying on zeroconf. Or at least hope so&quot;).<br>
<br>
[3] <a href=3D"https://bitcoinops.org/en/newsletters/2022/06/22/" rel=3D"no=
referrer" target=3D"_blank">https://bitcoinops.org/en/newsletters/2022/06/2=
2/</a><br>
[4] <a href=3D"https://bitcoinops.org/en/newsletters/2022/07/13/" rel=3D"no=
referrer" target=3D"_blank">https://bitcoinops.org/en/newsletters/2022/07/1=
3/</a><br>
<br>
If we&#39;re happy to not get feedback until we start doing rcs, that&#39;s=
 fine;<br>
but if we want to say &quot;oops, we&#39;re into release candidates, you sh=
ould<br>
have something earlier, it&#39;s too late now&quot;, that&#39;s a pretty cl=
osed-off<br>
way of doing things.<br>
<br>
And I mean: all this is only about drawing a line in *sand*; if people<br>
think core devs are wrong, they can still let that line blow away in<br>
the wind, by running different software, configuring core differently,<br>
patching core, or whatever else.<br>
<br>
&gt; Moreover, relying on node operators turning on the setting<br>
&gt; provides a smoother approach offering time to zero-conf services to re=
act<br>
&gt; in consequence.<br>
<br>
I don&#39;t think that&#39;s remotely true: take a look at taproot activati=
on:<br>
it took two months between releasing code that supported signalling and<br>
having 98% of hashrate signalling; with 40% of blocks signalling within<br>
the first two weeks.<br>
<br>
&gt; So the current path definitely belongs more to a 3) approach.<br>
<br>
&gt; &gt;=C2=A0 3) Encourage mainnet miners and relay nodes to support unco=
nditional<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0RBF immediately, no matter how much that incre=
ases the risk to<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0existing businesses that are still accepting u=
nconfirmed txs<br>
<br>
Yes, that&#39;s how it appears to me, too. It&#39;s not my preference (givi=
ng<br>
people clear warning of changes seems much better to me), but I can<br>
certainly live with it.<br>
<br>
But if the line in the sand is &quot;we&#39;re doing this, no matter how mu=
ch that<br>
increases the risk to existing businesses that weren&#39;t expecting it&quo=
t; then<br>
it seems *very* disingenuous not to make those risks very clear so that<br>
people who weren&#39;t expecting it actually take action to avoid those ris=
ks.<br>
<br>
That is, it seems to me that Dario was exactly right in titling this<br>
thread &quot;Zero-conf apps in immediate danger&quot;, and our co-developer=
s who<br>
are dismissing the risk by saying things along the lines of &quot;probably<=
br>
nothing will change anytime soon&quot; are exactly wrong.<br>
<br>
(More generally, that&#39;s similar to one of the things I&#39;ve hated<br>
watching in mainstream economics over the past few years: &quot;doing this<=
br>
will cause massive inflation&quot; &quot;no it won&#39;t, there&#39;s no in=
flation risk&quot;<br>
&quot;oops, inflation magically appeared, how did that happen? oh well, too=
<br>
bad, we have to live with it now&quot;. This looks pretty similar to me: &q=
uot;do<br>
something risky, deny the risk, make sure nobody can hold us accountable<br=
>
when the risk eventuates later&quot; so it makes me really uncomfortable)<b=
r>
<br>
&gt; While this<br>
&gt; way cannot be denied to be a zero-risk deployment for business accepti=
ng<br>
&gt; unconfirmed transactions, it should be weighed in face of multi-party<=
br>
&gt; contracting protocols encumbering an annoying pinning vector.<br>
<br>
Sure; that&#39;s a fine reason to draw the line in the sand. But it&#39;s n=
ot<br>
a good reason to have it happen immediately, rather than giving people<br>
time to react, and it&#39;s not a good reason to understate the risk of<br>
it happening now. Maybe there are good reasons for either or both of<br>
those, though?<br>
<br>
&gt; Since Dario&#39;s mail, I think we have learnt new data points, a) on =
the long<br>
&gt; term full RBF to align miner incentives is acknowledged and b) a clear=
<br>
&gt; timeline based on e.g a block height is favored over the pollination<b=
r>
&gt; deployment.<br>
<br>
Using the passive voice there doesn&#39;t seem helpful. Who learnt these<br=
>
things? You, I and Dario all seem to agree with (a), but John Carvalho<br>
certainly appears not to, for instance. I&#39;m not sure who agrees with<br=
>
(b) -- I know I do, and I think Dario does; but multiple people seem<br>
opposed to the clear timeline offered in #26323, and your #26305 seems<br>
more likely to encourage a &quot;pollination&quot; approach rather than dis=
courage<br>
it (&quot;oh, this will be the default option for 25.0, might as well enabl=
e<br>
it now like all the cool kids are&quot;).<br>
<br>
For what it&#39;s worth, my guess is that releasing core with full rbf<br>
support and having you and Murch and others advocating for people to<br>
try it out, will mean that full RBF is usable on mainnet within two<br>
or three months, supported by perhaps 5%-20% hashpower, but probably<br>
still requiring special effort to actually find a peer that can relay<br>
full rbf txs to that hashpower (probably doing an addnode, despite the<br>
privacy implications). Even if that happens, I&#39;m not super confident<br=
>
that it would mean people would actively steal from zeroconf businesses<br>
in any volume, though. It&#39;s not something I&#39;d risk happening to me,=
<br>
but accepting zeroconf from strangers isn&#39;t something I&#39;d risk anyw=
ay.<br>
<br>
Slowing that down from January-ish to May seems like it ought to be a<br>
big win for anyone who has been doing zeroconf, and having it be easy<br>
to find a path to miners when it is supported seems like a big win even<br>
given a cost of a few months delay.<br>
<br>
OTOH, if we&#39;re really not expecting full rbf to be available for many<b=
r>
months, then I would have expected the &quot;disable this for mainnet,<br>
reconsider after the release&quot; PR (#26287) to have gone ahead already.<=
br>
<br>
&gt; Tie-breaking between<br>
&gt; both, I believe I would favor something like #26323 though only post 2=
4.0<br>
&gt; to avoid introducing a bikeshedding precedent in terms of release proc=
ess,<br>
<br>
Doing something like #26323 only after 24.0 is out does nothing to<br>
mitigate whatever immediate risk there is to bitcoin businesses/users...<br=
>
<br>
And if the choice is between &quot;bikeshedding&quot; and &quot;merge a PR,=
 then ignore<br>
feedback that it&#39;s harmful&quot;, I&#39;d much rather the bikeshedding.=
 What&#39;s<br>
the point of having rcs if you&#39;re going to ignore negative feedback?<br=
>
<br>
I mean, if you think the feedback is wrong, that&#39;s different: maybe we<=
br>
shouldn&#39;t care that zeroconf apps are in immediate danger, and maybe<br=
>
bitcoin would be better if any that don&#39;t adapt immediately all die<br>
horribly as a lesson to others not to make similarly bad assumptions.<br>
<br>
But saying &quot;we don&#39;t want them to be in danger&quot; and also refu=
sing to do<br>
anything to avoid it?<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>

--0000000000008c99df05eb5a6cd9--