[bitcoin-dev] The Pinning & Replacement Problem Set

[John Carvalho via bitcoin-dev]

Good morning,

All layers and technologies "on" Bitcoin will fail in situations where
miners misbehave or the blocks & mempool remain consistently, overly full.
Consider this as a "law" of Bitcoin/blockchains.

In hindsight (for you, not me) it was very unwise to start messing with
mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought
a fragile harmony and utility to Bitcoin, which we were lucky to have for
as long as we could.

The engineers intentionally broke this. Mempoofullrbf washes away the
ability for users to express their intent on whether to pin or replace a
transaction, and now Lightning has BOTH pinning and replacement problems.
You could argue this was inevitable. The point here is that layers have
mempool and miner problems.

Core has a few choices here, as I see it:

1. They can try to revert mempoolfullrbf and re-establish first-seen
policy. Hard to say whether this would work, or whether it would be
enough...

2. They can create additional policies that are enforced by default that
allow people to flag how they want their txn handled, as in, a "pin this"
vs "replace this" aspect to every txn. This is probably the best option, as
it allows miners to know what people want and give it to them. This is
utility, thus incentive-compatible.

3. Remove all policy and let the market evolve to deal with the chaos.
Which is similar to the next option: do nothing.

4. Do nothing and allow a fractured mempool environment to evolve where
large businesses form private contracts with miners and pools to support
their own unsupported policies, so they can provide better experiences to
customers and users.

5. Invent some miracle magical crypto cure that I am not capable of
imagining at this time.

I disclaim some ignorance to details of how other mempool research might
affect these options and problems, but I am skeptical the dynamics
discussed here can be removed entirely.

--John Carvalho
CEO, Synonym.to 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

[John Carvalho via bitcoin-dev]

Why wasn't this solution put in place back then? Are there problems with
the design?

While I still think there are unhealthy side-effects of Full-RBF (like more
doublespending at unknowing merchants, after years of FSS protection) I
think discussion of this FSS-RBF feature is worth considering.

--
John Carvalho
CEO, Synonym.to 


On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz  wrote:

> Thank you for bringing that to my attention, apologies for not being aware
> of it.
>
> First-seen-safe replace-by-fee as detailed here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
> by Peter Todd  seems to be a very suitable option and route
> which balances FullRBF while retaining  the significant 0-conf use case.
>
> This would seem like a good way forward.
>
>
>
> 
>
>
>
> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman 
> wrote:
>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)

[John Carvalho via bitcoin-dev]

Zman,

Price Theory simply explains the relationship between supply & demand. Your
post makes some logical leaps in that you are implying that demand follows
supply, which of course is not true, nor is that a claim of Price Theory.
If Bitcoin has less utility, it will have less demand, regardless of
whether it is well-optimized to allow for capacity saturation.

I do agree that there is an optimal state, and that such state is not
likely to be at the maximum price, because price maximization is exclusive.
(Whether I deem any of this as "reasonable," as you say, is irrelevant
other than whether I personally, subjectively choose to participate.)

The optimal state (most fees earned), would surely be a result of the most
value provided (per blockspace, per time period). While we must do our best
to make sure txns have the smallest footprint, and that people have ways to
pay a fee proportional to their time preference, there is always a maximum
quantity of demand willing to pay any given fee. My arguments express how
zero-conf currently creates added demand for blockspace, by
merchants/consumers, and additionally, demand for *next-block* inclusion
(maximum time preference) due to merchants qualifying fee rates to be
eligible for zero-conf acceptance.

So, me saying that RBF is fee-minimization, which you have conceded, is
apt, in that we should probably not trade off something like zero-conf
utility (demand) for something like mempoolfullrbf (blanket replaceability
that overrides status quo use cases).

Your statement of "If more people could use RBF onchain, more people would
use Bitcoin and increase the value to miners." is not economically rational
unless you truly can prove that supply creates demand. This is observably
false, as blocks are not full.

Also, you stated "Unfortunately many 0-conf acceptors outright reject
opt-in-RBF, despite the improved discovery of the optimum price, and thus
there is a need for full-RBF to improve price discovery of blockspace when
such acceptors are too prevalent." This is also irrational and incorrect.
First, merchants do not "outright reject" opt-in RBF, they simply make the
customer wait 1 conf. Second, full-rbf has no positive effect on price
discovery for blockspace if it results in less people using Bitcoin for
actual trade.

~John



It is helpful to remember that the fees are a price on confirmation.
> And in economics, there is a "price theory":
>
> * As price goes down, demand goes up.
> * As price goes up, net-earning-per-unit goes up.
>
> The combination of both forces causes a curve where *total* earnings vs
> price has a peak somewhere, an "optimum price", and that peak is *unlikely*
> to be at the maximum possible price you might deem reasonable.
> And this optimum price may very well be *lower* than the prevailing market
> price of a good.
>
> Thus, saying "RBF is actually a fee-minimization feature" neglects the
> economics of the situation.
> If more people could use RBF onchain, more people would use Bitcoin and
> increase the value to miners.
>
> Rather than a fee-minimization feature, RBF is really an optimization to
> *speed up* the discovery of the optimum price, and is thus desirable.
>
> Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite
> the improved discovery of the optimum price, and thus there is a need for
> full-RBF to improve price discovery of blockspace when such acceptors are
> too prevalent.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol

[John Carvalho via bitcoin-dev]

es trying to thrive and provide
> services to their customers. Unfortunately there are occasionally scenarios
> where trade-offs have to be weighed up and decisions have to be made where
> some people aren't happy. You may disagree but I'm a lot more comfortable
> delegating responsibility for policy defaults to those who have worked full
> time in this area for years than say consensus changes where I think we all
> have a responsibility to ensure suboptimal or worse harmful changes aren't
> made to the consensus rules. I thought your input on the CTV discussion
> earlier in the year was really positive for example. On this topic though I
> think you could do with doing some more reading as there is *a lot*​ of
> past discussion. I'm sure those who work in this area full time would be
> happy to answer any questions you have if you do.
>
> Thanks
> Michael
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html
> [1]:
> https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> As we debate mempoolfullrbf, and I familiarize myself with related PRs
> from engineers trying to reign in all of the possible behaviors that make
> it inconsistent, I can’t help but think about how I see people using the
> term “incentive-compatible” and how it seems to be awfully presumptive.
>
> The idea that a single Bitcoin transaction can be “incentive-compatible”
> by simply restricting it to having a higher fee or fee rate is theoretical,
> likely narrow, and not totally objective. RBF is inherently a
> fee-minimization tool, which as a concept, as I understand
> “incentive-compatibility” to be about miners in this context, makes RBF to
> be anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If
> miners, and the mempool, are prioritizing for the smallest txns with the
> highest fees, over the longest acceptable amount of time, this may conflict
> with extra-mempool behaviors that result in more txns per block / per
> lifetime.
>
> If this isn’t making sense yet, let me summarize by how such a problem
> would express: a per-transaction fee-minimized, fully replaceable mempool
> as policy, that appears to always require the highest fee per txn, but
> ultimately includes less txns per block and less fees per lifetime.
> Basically, less use cases, less users, less txns — all to enforce a
> misunderstood theory and predictive speculation of what people want out of
> the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don’t need to do
> anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective. So
> why are we pursuing it? Why do we even have RBF? Why are we trying to clean
> up all of the mess RBF creates with more and more code? If bidding is
> already accepted as incentive-compatible, and Bitcoin already allows
> setting a fee, then replacement requires no special code at all.
>
> I would think a holistic definition of what is incentive-compatible would
> be something more like what is “market compatible” and enables the
> complementary goals & incentives of every user in the system to make it
> thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately
> miners would be incentivized to do what users want, up to the point of
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design,
> express? Well, I think the idea of txns being able to signal intent and
> desired behavior is more interesting (more useful) than a mempool that
> overrides all intent with RBF, and possibly more incentive-compatible than
> mempoolfullrbf as concept.
>
> Since we can’t be sure what the market wants, but we can be sure that the
> more users we have, making the most possible txns, at the highest possible
> prices, will yield the most valuable Bitcoin, and thus the most hashpower,
> we could entertain giving users the most ways to express their intent, the
> most flexibility.
>
> The most basic design would be to simply have no mempool policy at all,
> and let market incentives emerge on their own, but we have a status quo to
> consider, and most users do not have the technical expertise to express
> their

[bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol

[John Carvalho via bitcoin-dev]

As we debate mempoolfullrbf, and I familiarize myself with related PRs from
engineers trying to reign in all of the possible behaviors that make it
inconsistent, I can’t help but think about how I see people using the term
“incentive-compatible” and how it seems to be awfully presumptive.

The idea that a single Bitcoin transaction can be “incentive-compatible” by
simply restricting it to having a higher fee or fee rate is theoretical,
likely narrow, and not totally objective. RBF is inherently a
fee-minimization tool, which as a concept, as I understand
“incentive-compatibility” to be about miners in this context, makes RBF to
be anti-incentives; miners are fee maximizers.

Miners want the most fees per block, and per lifetime, do they not? If
miners, and the mempool, are prioritizing for the smallest txns with the
highest fees, over the longest acceptable amount of time, this may conflict
with extra-mempool behaviors that result in more txns per block / per
lifetime.

If this isn’t making sense yet, let me summarize by how such a problem
would express: a per-transaction fee-minimized, fully replaceable mempool
as policy, that appears to always require the highest fee per txn, but
ultimately includes less txns per block and less fees per lifetime.
Basically, less use cases, less users, less txns — all to enforce a
misunderstood theory and predictive speculation of what people want out of
the system and what miners will do about it.

Simply, we probably want designs that fill blocks, and we don’t need to do
anything at all to facilitate bidding on a use case like replacement.

Bidding does not require protocol enforcement, it is miner-subjective. So
why are we pursuing it? Why do we even have RBF? Why are we trying to clean
up all of the mess RBF creates with more and more code? If bidding is
already accepted as incentive-compatible, and Bitcoin already allows
setting a fee, then replacement requires no special code at all.

I would think a holistic definition of what is incentive-compatible would
be something more like what is “market compatible” and enables the
complementary goals & incentives of every user in the system to make it
thrive.

It has been shown that users control Bitcoin (UASF) and thus ultimately
miners would be incentivized to do what users want, up to the point of
inability or loss. Correct?

So, in contrast, how would the opposite, a user-compatible design, express?
Well, I think the idea of txns being able to signal intent and desired
behavior is more interesting (more useful) than a mempool that overrides
all intent with RBF, and possibly more incentive-compatible than
mempoolfullrbf as concept.

Since we can’t be sure what the market wants, but we can be sure that the
more users we have, making the most possible txns, at the highest possible
prices, will yield the most valuable Bitcoin, and thus the most hashpower,
we could entertain giving users the most ways to express their intent, the
most flexibility.

The most basic design would be to simply have no mempool policy at all, and
let market incentives emerge on their own, but we have a status quo to
consider, and most users do not have the technical expertise to express
their own policies with misc patches and hacks of their Bitcoin Core
software.

I know this is a bit of a high-level abstract perspective, but I think it
is important to respect such dynamics when making smaller decisions. It
certainly is not our charge to prioritize what miners want any more than
any other user type, nor is it within our ability to predict the future or
fully model incentives of all players across all use cases.

I know some of you may scoff at my bias for use cases like zero-conf, but
what I am trying to convey is a possible folly in active management,
speculation, and misapplied game theory that may permeate many Bitcoin Core
decisions and designs, even beyond the mempoolrbf / zero-conf debate.

So, what to do?

—

John Carvalho
CEO, Synonym.to
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 91, Issue 5

[John Carvalho via bitcoin-dev]

Antoine,


> In the direction of removing the current option from Bitcoin Core, I think
> the prerequisite to address are the qualification of enough economic flows
> at risk and the presence of a sizable loss in miners income.


Are such prerequisites for feature removal published somewhere? I don't see
any reason why removing a controversial change should be harder than adding
one. Generally, it is impossible to definitively attribute any change in
network condition to one thing in such a complex system, and also difficult
to know how much time is required to express negative effects. The whole
argument here is to prevent disruption of the status quo that has lasted
the whole history of Bitcoin, to avoid taking a speculative risk that
full-RBF, at the expense of zero-conf, is maybe better for miners... or
something.

Further, I feel the mempoolfullrbf feature was rushed through while this
controversy was growing, specifically to attempt to achieve this imaginary
protection of "sorry, that ship has sailed" which indicates an agenda that
is counter to greater social consensus and status quo. We should not
incentivize such behavior further by allowing this sort of feature
sainthood.

Beyond that, I think there is still the open question if we (we, as the
> Bitcoin protocol development community, with all its stakeholders) should
> restrain user choice in policy settings in the name of preserving mining
> income and established use-case stability.


Removing the mempoolfullrbf feature is the opposite of restraining user
choice.

First, any incentivized user can still create and distribute patches for
any given mempool policy, regardless of whether we remove the feature from
Core, but it is important to note that extremely few have felt the need to
do so in the past.

Second, the very debate here is about how it is mempoolfullrbf that removes
the user choice of zero-conf services. With a first-seen policy in place,
users have *more* options, and Bitcoin is thus more useful, and thus more
valuable to everyone. This is evident in that the feature of full-rbf is
that it overrides any ability for users to signal intent of how they wish
their transaction to be handled by nodes and miners. This is useful info to
miners, as they make more money by facilitating use cases than by
fee-minimizers painting everything as RBF. User-signaling is a useful
feature for the mempool, full-RBF removes that feature.

Third, when Bitcoin Core adds special support for specific policies, it
positions itself as a political authority and influencer. It is not Core's
place to support one subjective policy more than another, particularly when
it conflicts with years of status quo and breaks the current user space,
and likely resulting in more doublespent user experiences.

To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].


I am particularly skeptical that users sending Bitcoin to themselves
(coinjoin) could ever be more incentive-compatible than fast-paced commerce
& priority competition. I am also skeptical that mempoolfullrbf actually
solves LN risks any better than opt-in RBF by default by LN implementations
and wallets.

Further, zero-conf support reduces friction for LN adoption by allowing us
to make instant, seamless UX within wallets when onboarding, rebalancing,
and splicing.

--
John Carvalho
CEO, Synonym.to 



>
> Date: Fri, 2 Dec 2022 17:35:39 -0500
> From: Antoine Riard 
> To: Bitcoin Protocol Discussion
> 
> Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in
> immediate   danger
> Message-ID:
> <
> calzpt+hffwy4xecnzj3xlqnaumpedjrwvncsra3vsgqfuxn...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Daniel,
>
> >From my understanding of GAP600, you're operating a zero-conf risk
> analysis
> business, which is integrated and leveraged by payment processors/liquidity
> providers and merchants. A deployment of fullrbf by enough full-node
> operators and a subset of the mining hashrate would lower the cost of
> double-spend attack by lamda users, therefore increasing the risk exposure
> of your users. This increased risk exposure could lead you to alter the
> acceptance of incoming zero-conf transactions, AFAICT in a similar
> reasoning as exposed by Bitrefill earlier this year [0].
>
> About the statistics you're asking for considerations, few further
> questions, on those 1.5M transactions per month, a) how many are
> Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
> are excluded from zeroconf due to factor

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)

[John Carvalho via bitcoin-dev]

>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case.


If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.

It's always been the risk of getting double-spent out of hundreds or
> thousands of bitcoins that's worth seriously worrying about, which is much
> more the kind of attack a determined attacker is able to carry out.


The risk exposure to merchants providing zero-conf acceptance as a service
is finite, capped by their risk-tolerance, and capped by the current block
exposure. Merchants cap their exposure to be an amount worth less than the
value of this service.

It is highly inefficient and difficult for a miner to pull off an
industry-wide attack across diverse merchants to capture the current
maximum exposure in any given block, not to mention the enormous surface
area of legal risk across jurisdictions...

I don't think zero-conf opponents properly grasp that the risk exposure is
exact and perfectly, trustlessly manageable. I would like the opportunity
to spec the methods Bitrefill, Synonym, and most such merchants, use to
make it standard practice, as it is cheaper for merchants and more
convenient to Bitcoin consumers when merchants behave this way.

As has been pointed out by may others before, full RBF is aligned with
> miner (and user) economic incentives


This is a theory, not a fact. I can refute this theory by pointing out
several aspects:

1.  RBF is actually a fee-minimization feature that allows users to game
the system to spend the *least* amount in fees that correlates to their
time-preference. Miners earn less when fees can be minimized (obviously).
This feature also comes at an expense (albeit small) to nodes providing
replacement service and propagation.

2. Miners care about max fees per block, not slightly increased fees on a
minority % of incidentally replaced txns when they happen to need it. They
want the most txns for the highest price per *block*. In order to qualify
for zero-conf acceptance, merchants require that the fee rate match or
exceed an amount that makes the txn likely to be included in the very next
block. This creates a priority competition from users with high
time-preference. This creates not only more fees for miners, but more txns
from more people using the chain for commerce. This is evidenced by stats
provided recently to this mailing list, but here are more numbers from
Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282

3. Miners ultimately want what users want, as more users = more txns = more
fees = higher BTC price. For all of Bitcoin's history, more users have
wanted zero-conf than replacements. This is evidenced by first-seen policy
thriving for years without disruption (until engineers actively disrupted
it, using fallible theories as justification). This is also evidenced by
the UASF battle where miners capitulated to providing the type of blocks
that users demanded, to avoid uncertainty.

4. A replaceable mempool is inherently less valuable than a first-seen
policy mempool in that Bitcoin is ultimately a ledger for a *payments*
system where people are trying to pay and be paid with certainty. A
full-RBF system would result in more real-world doublespends to existing
merchants and p2p commerce, as it is impossible to fully teach all aspects
of Bitcoin dynamics to users, particularly when they have enjoyed many
years of first-seen behavior as status quo.

Zero-conf and first-seen policies are clearly more
incentive-compatible than RBF outright for these reasons.

The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement


Many zero-conf proponents work on the bleeding edge of supporting
Lightning, including myself. Lightning is not risk-free and the base layer
should not be assuming it as a primary dependency for commercial payments.
The UX and complexity of supporting Lightning is still considerable,
adoption is still very low, and there are many unsolved attack vectors and
risks that remain untested due to Lightning's low prevalence.

Further, zero-conf is also useful as a tool in improving Lightning
onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers
are only as good as the base layer, everything else is a tradeoff.

Bitcoin core 24 with the full RBF option is already out in the wild at
> around 5%+ of running nodes and growing, so it's too late to kill it.


This is pure speculation. If Bitcoin Core publishes an update without the
mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on
the vine as users opt into the latest versions more and more, as evidenced
by all older versions decreasing in usage over time. The incentive to run
old versions, just to be able to force non-RBF txns to be treated as RBF,
is lower than the incentive and likelihood of updating. Frankly

Re: [bitcoin-dev] On mempool policy consistency

[John Carvalho via bitcoin-dev]

Anthony,

I took the time to read your whole post. Despite a diplomatic tone, I find
your takeaways from all your references to remain conveniently biased for
protecting the plan of RBF via passive aggression.

You show multiple examples where, when I read them, I assume the next thing
you will say will be "so we really should stop trying to impose optional
features, particularly when they affect existing use cases" but instead you
persist.

The problem is that RBF has already been an option for years, and anyone
that wants to use it can. Any escalation in Bitcoin Core code to support it
more deeply, or by default, is basically an unfair advantage to force the
market to do what it already has decided not to.

If wallets want to default to RBF, they can already do so, as evidenced by
Green Wallet (which I stopped using because it breaks the UX at Bitrefill).

Instead of Core devs admitting RBF is a minority use case, you seem to be
proposing that the market should now be obligated to prove it can defeat
RBF in a stronger form if it really wants to prove other use cases. This is
oppressive, dark-pattern design. We all know that Core has little ability
to sense the market, and the market has little ability to express itself to
Core. The idea that the market can always downvote or defeat a feature or
new complexity proposal is idealistic and unrealistic.

Superficial features should be decided at the surface (app level) not in
the protocol or node.

The default answer to ALL proposals is "No." Changes need to win market
acceptance, not get special access through Core devs baking them deeper and
deeper into the protocol and policies until everyone is forced into a new
design.

As I mentioned before, this behavior, if we are lucky, will result in more
mempool types, more implementations, and a more-difficult to modify
protocol, but ALL feature changes, default settings that make decisions for
users, and even all scaling changes, are speculative risks with
unpredictable outcomes.

I urge the culture of Core to respect these dynamics and become much more
conservative with proposing change. Please focus on efficiencies, bugs,
cleanup, reducing overhead, etc.

The current RBF movement feels like Core is strong-arming and shoe-horning
in a change that the market is not actually asking for. It is okay to leave
things as they are. It is okay if RBF remains a niche feature. It is not
okay for a small group of RBF-interested engineers to make commercial
Bitcoin use cases worse.

Let us realize the Bitcoin we already have. We already have a largely
unexplored canvas of taproot, lightning, UX, etc.

I expect the things I do with Bitcoin today to work FOREVER.

--
John Carvalho
CEO, Synonym.to 



> Date: Thu, 27 Oct 2022 09:52:10 +1000
> From: Anthony Towns 
> To: Bitcoin Protocol Discussion
> 
> Subject: [bitcoin-dev] On mempool policy consistency
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
>
> Hi *,
>
> TLDR: Yes, this post is too long, and there's no TLDR. If it's any
> consolation, it took longer to write than it does to read?
>
> On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> > I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folks
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - p

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)

[John Carvalho via bitcoin-dev]

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.

RBF assurances are optionally enforced by miners, and can be assisted by
node mempool policies. It is not reliable to expect replaceable payments to
be enforced in a system designed to enforce integrity of payments. RBF is
both irrational and trusting.

RBF is a whim of a feature where engineers made the mistake of thinking a
hack that basically incentivizes rollbacks and uncertainty might be useful
because we can pretend Bitcoin has an undo button, and we can pretend to
game the fee market by low-balling rates until txns get in.

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.

Miners serve full nodes. What is more likely, a node set that prefers
blocks with replaced txns, or a node set that rejects blocks with replaced
txns?


--
John Carvalho
CEO, Synonym.to 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[John Carvalho via bitcoin-dev]

Peter,

Your argument is totally hypocritical and loses when comparing quantities.

Enforcing RBF is observably more "harmful to Bitcoin" (whatever that
means...) when it tries to "risk-manage propagation" of replacements, as
there more Bitcoiners that want to mutually utilize 0conf than users that
want to replace transactions.

Spending bitcoin is a use case, so replacing txns reduces utility and makes
commitments less certain.

No one here arguing for 0conf is suggesting reorgs, so please do not
sensationalize with claims of reorgs or "harm."

Take note that it is RBF proponents that have changed Bitcoin code and seek
to continue to change Bitcoin, RBF that seeks to reduce commercial utility
-- but 0conf proponents are not asking for changes to Bitcoin, not
suggesting soft or hard forks, etc. We are asking you to stop breaking
things by adding features for minority speculative interests.

-John

On Fri, Oct 14, 2022 at 5:04 PM Peter Todd  wrote:

> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
> wrote:
> > In support of Dario's concern, I feel like there is a degree of
> gaslighting
> > happening with the advancement of RBF somehow being okay, while merchants
> > wanting to manage their own 0conf risk better being not okay.
>
> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
> Connecting to large numbers of nodes to try to risk-manage propagation
> _is_ an
> attack, albeit a mild one. Everyone doing that is very harmful; only a few
> merchants being able to do it is very unfair/centralized.
>
> ...and of course, in the past this has lead to merchants trying to make
> deals
> with miners directly, even going as far as to suggest reorging out
> double-spends. I don't need to explain why that is obviously extremely
> harmful.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-- 
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[John Carvalho via bitcoin-dev]

Erik, I am fully aware of Lightning and have a been a proponent and builder
of it since it was launched, including getting Bitfinex to support LN,
building a RN LDK implementation in our upcoming app, etc, but frankly LN
has nowhere near the adoption of onchain payments for commerce, and LN
complexity, reliability, maintenance and overhead are real obstacles for
merchants.

One of your links is to Muun, who started this thread!

There is no practicality in a merchant saying they accept bitcoin, but not
onchain, or in having many checkout and customer service versions for many
bitcoin payment methods.

Merchants accepting base layer bitcoin is one if the most important types
of adoption there is.

-John

On Fri, Oct 14, 2022 at 6:29 PM Erik Aronesty  wrote:

> Also, lightning works fine and is readily available in convenient mobile
> apps used by millions of people, or in .   So the need for a 0conf has been
> mitigated by other solutions for fast payments with no need for a trust
> relationship.  And for people that don't like mobile risks, core lightning
> and other solutions are now easily installed and configured for use in fast
> payments.
>
> some references:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
>> wrote:
>> > In support of Dario's concern, I feel like there is a degree of
>> gaslighting
>> > happening with the advancement of RBF somehow being okay, while
>> merchants
>> > wanting to manage their own 0conf risk better being not okay.
>>
>> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
>> Connecting to large numbers of nodes to try to risk-manage propagation
>> _is_ an
>> attack, albeit a mild one. Everyone doing that is very harmful; only a few
>> merchants being able to do it is very unfair/centralized.
>>
>> ...and of course, in the past this has lead to merchants trying to make
>> deals
>> with miners directly, even going as far as to suggest reorging out
>> double-spends. I don't need to explain why that is obviously extremely
>> harmful.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[John Carvalho via bitcoin-dev]

In support of Dario's concern, I feel like there is a degree of gaslighting
happening with the advancement of RBF somehow being okay, while merchants
wanting to manage their own 0conf risk better being not okay.

The argument against 0conf acceptance seems to be "miners can facilitate
doublespends anyway, and are incentivized to do so if the fees are higher"
as this is just how Bitcoin works.

But RBF proponents seem to be taking what is actually a much rarer, and
less useful, use case of replacing txns that lowball feerates, or actually
undoing/doublespending previously signed payments... and threaten the use
case of onchain bitcoin being useful at the point-of-sale for merchants and
consumers.

I can tell you right now where this leads. It leads to miners, merchants
and consumers creating alternative fee mechanisms and trusted/exclusive
mempools where first-seen txns are respected.

The truth is that doublespending is not a certain process, and in many
commercial situations, too risky to attempt without real-world consequences.

0conf payment acceptance comes with highly *manageable* risks, which means
that if best practices and methods are used by merchants, and *gasp*
advanced by engineers with better tools and specs, that we can have fast
and valuable commercial payments with merchants that meet user
expectations. In fact, we may even be able to do so with less complexity
than Lightning and with similar results and overhead...

That said, we are (myself and a group of builders and merchants) moving
forward with demonstrating, protecting, and advancing this use case,
to contrast the trend of making the mempool less predictable and easier to
replace.

RBF causes more problems than it resolves, and if your argument is that
0conf was never safe, then mine is that RBF was never needed. We should not
pretend that the mempool is enforceable for either cause, and should
respect that incentives will always prevail eventually.

To me, use cases for spending Bitcoin are more important to protect than
features for pretending you can enforce mempool behaviors or pretending you
can reliably provide replacement features.

If anyone is interested in research, specs, and tools and assisting our
group, you can contact me directly, or join the public chat at
https://t.me/bitcoinandlightningspecs

Thanks,

--
John Carvalho
CEO, Synonym.to 

>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho via bitcoin-dev]

roportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn’t even
> increase, given the white market blessing which so many seem to want.
>
>
> But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>
>
> e
>
>
> On Jul 7, 2022, at 14:11, Erik Aronesty  wrote:
>
>
>
> The relationship between block size and fees is not remotely linear.   In
> a restricted environment, the fee rewards are much higher.
>
>
> **the ones moving more sats will win the top spots and will pay as much as
> is reasonable**
>
>
> Smaller blocks produce better security for the network both in validation,
> and in fees.
>
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
>
> With a bidding war for space, larger transactions will pay much higher
> rates.   There have been a number of papers written on this but you can
> concoct a trivial example to prove it.
>
>
>
>
> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil  wrote:
>
>
>
> It’s not clear how reducing block size changes the fee aspect of the block
> reward. Assuming half the space implies twice the fee per avg tx the reward
> remains constant.
>
>
> Any additional cost of processing more or less bytes would not matter,
> because of course this is just a cost that gets nulled out by difficulty —
> average profit (net income) is the cost of capital.
>
>
> The reason for smaller vs. larger blocks is to ensure that individuals can
> afford to validate. That’s a threshold criteria.
>
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it  cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
>
> e
>
>
> On Jul 7, 2022, at 10:37, Erik Aronesty  wrote:
>
>
>
> > > We should not imbue real technology with magical qualities.
>
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
>
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
>
> Changes to inflation are, very likely, off the table.
>
>
>
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
> >> Billy,
> >>
> >> Proof of work and the difficulty adjustment function solve literally
> >> everything you are talking about already.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > power. In the event of a chain split, the difficulty adjustment function
> does
> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
> &

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho via bitcoin-dev]

Billy,

Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.

Bitcoin does not need active economic governanance by devs or meddlers.

Please stop spamming this list with this nonsensical thread.

Love,

John


On Thu, Jul 7, 2022 at 1:00 PM <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. Re: Bitcoin covenants are inevitable (Billy Tetrud)
>
>
> --
>
> Message: 1
> Date: Wed, 6 Jul 2022 17:46:15 -0700
> From: Billy Tetrud 
> To: vju...@gazeta.pl,  Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
>  3g...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @Corey
>
> >  Currently there is zero feedback in the Bitcoin system between what we
> might think is the optimum amount of security and what actually exists.
>
> I basically agree with this. The pedantic part of my mind does want to
> point out that the link between block subsidy and bitcoin's price does
> actually give somewhat of a feedback loop, in that the higher the price,
> the more valuable bitcoin is as a whole (at least as viewed by the active
> market), and therefore the more investment in security is appropriate.
> However, in the long run when the subsidy reduces to insignificance, we
> basically lose this link. And even with this link, it's not very direct.
> Fees retain only a little bit of this behavior, because presumably a more
> valuable bitcoin is more valuable to spend, but the link to security is
> very tenuous there.
>
> > There is also zero agreement on how much security would constitute such
> an optimum.
>
> This is really step 1. We need to generate consensus on this long before
> the block subsidy becomes too small. Probably in the next 10-15 years. I
> wrote a paper
> 
> that uses a framework for thinking about how much security bitcoin might
> need. The concept is that we should figure out what bitcoin's bottlenecks
> are, and figure out the minimum requirements we want to place on running a
> node based on how many (public) nodes we think we need and what percentage
> of machines out there are likely to run a node. The goals I chose to
> explore in that paper are totally up for debate, and I think its an
> important debate to have. But they are basically a first stab at setting up
> what we would need to determine optimum security. I would very much
> appreciate your review of that part of the paper, Corey.
>
> > Figuring out how much security is needed, or even better, figuring out a
> way to have a market mechanism to answer that question, will be an
> important project.
>
> My thoughts on this are that we will need to periodically make some
> software change to adjust a *target amount of investment in security*,
> because the components of bitcoin's blockchain security are not all
> predictable. Many unpredictable things factor into bitcoin's security (eg
> miner behavior, pools, how many people generally run public nodes on their
> own, what features require running public nodes, value of bitcoin, etc.
>
> The primary mechanism we have to change how much security we have is to
> change the block size, which changes how much fees miners can collect each
> block. This isn't a linear thing. Its probably a parabola with a peak,
> where at that peak, making the block either smaller and larger would both
> reduce total fees paid. This is because when blocksize is higher, more
> transactions (and thus more fees) can be collected, but at the same time
> average fees will be lower. The pull of those two forces should define that
> parabola.
>
> So my suggestion here would be that we should target a certain amount of
> security and have programmatic adjustments to the block size in order to
> stay near enough to the parabolic maximum so that we pay miners enough to
> give us sufficient blockchain security. Conversely, it should also attempt
> to minimize how much "extra" security we pay for. It would be wasteful to
> pay 3 times as much for 3 times the security we actually need. Such a thing
> is a very real form of devaluation that basically represents a tax on
> bitcoin and users of bitcoin. And its very possible for the position of
> this parabol

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho via bitcoin-dev]

Core development is not a hackathon project.

None of the quoted following items are features or responsibilities of the
Bitcoin software, nor Core developers.

Quoted:
"- Developers can build interesting projects with real demand in market.
- Students learn Sapio and not just solidity.
- Better tooling could be available for application developers.
- Maybe we see bitcoin developer hackathons in different countries.
- Demand for block space might increase, it wont be just exchanges and
coinjoin.
- Funding of bitcoin developers and projects might improve. Wont need to
convince a few people for grants."

Whether you are a child or an attacker, none of us should care, but CTV,
nor any change to Bitcoin software, will never be justifiable simply
because you and some of your friends think it is totally cool and might
make more people like you or give your friends funding.

Please stop making noise about CTV, this is not a place for spamming.

--
John Carvalho



On Sat, Jun 4, 2022 at 1:00 PM <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:

>
> Date: Fri, 03 Jun 2022 18:39:34 +
> From: alicexbt 
> To: Bitcoin Protocol Discussion
> 
> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
>
>  protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
> Note: This email is an opinion and not an attack on bitcoin
>
> Covenants on bitcoin will eventually be implemented with a soft fork. CTV
> is the easiest and best possible way OP_TX looks good as well. Apart from
> the technical merits, covenants will improve a few other things:
>
> - Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to
> convince a few people for grants.
>
> **Why covenants are not contentious?**
>
> Some people may write paragraphs about CTV being contentious, spread
> misinformation and do all types of drama, politics etc. on social media but
> there are zero technical NACKs for CTV. We have discussed other covenant
> proposals in detail on mailing list and IRC meetings with an open minded
> approach.
>
> All the developers that participated in the discussion are either okay
> with CTV or OP_TX or covenants in general.
>
> **How and when should covenants be implemented in Bitcoin?**
>
> I don't think we should wait for years anticipating a proposal that
> everyone will agree on or argue for years to pretend changes are hard in
> Bitcoin. We should improve the review process for soft fork BIPs and share
> honest opinions with agreement, disagreement on technical merits.
>
> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything
> else being used if that improves Bitcoin. Covenants implemented in Bitcoin
> before the next cycle would provide opportunity for developers to build
> interesting things during the bear market. Ossification supporters also
> believe there is some window that will close soon, maybe doing changes
> considering each case individually will be a better approach. CTV is not a
> rushed soft fork, less people followed the research and it was not
> mentioned on social media repeatedly by the respected developers like other
> soft forks.
>
> /dev/fd0
>
>
> Sent with Proton Mail secure email.
>
>
> --
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Working Towards Consensus

[John Carvalho via bitcoin-dev]

>
> > The path to consensus is to propose things that everyone needs.
> If there's an insight here, it isn't clear what it is to me. As stated,
> this is something I can only 100% disagree with. Its possible that
> literally nothing about bitcoin is something that "everyone needs". Its
> pretty clear that not "everyone needs" taproot. Its even questionable
> whether "everyone needs" bitcoin. Are you really saying that no change
> should be added to bitcoin unless it is something literally all bitcoin
> users are currently asking for, or maybe just will want to use sometime
> soon? The majority of bitcoin users don't even custody their own funds, so
> practically all features are something those users aren't using. If you
> want to convince people of whatever argument you're making, you're going to
> have to get a little more specific and rather less hyperbolic.


Billy, the insight is quite simple: it is easier to get everyone to agree
when everyone has something to gain. Taproot getting activated is not proof
of a sound consensus process, it is proof that most users are either
apathetic or trusting in the developers that initiated it being activated.
This is a dangerous dynamic to lean on. I'm not trying to convince anyone
of anything, I'm trying to provide insight into Bitcoin's dynamics and
qualities so as to save everyone some time. Take it or leave it, but I'm
confident about how things will play out within this model.

> Designers (engineers) solve problems with designs, but when they
> speculate and lead the process, they create problems instead.
> How do you expect any improvement to ever happen to bitcoin if designers
> can't design things unless end-users have asked for it. Every good product
> designer knows that users do not know how to design products. Users have
> problems, designers create solutions. Companies that have implemented
> features that users directly ask for end up with awful bloated confusing
> products. Surely this isn't what you're suggesting we do in bitcoin, right?


I do not "expect" improvement by any other means than is typical in life:
competition and adaptation in response to an adverse and changing
environment. Designers can design whatever they please, they just need to
understand the dynamics at play and the risks they are taking in that they
are likely to waste their own time, and others, if they miss the mark on
providing for the greater good. Anyone can be a designer, like anyone can
be a Bitcoin user. Engineers are only special if their specialization
allows them to solve a problem faster than someone else might. Why are you
talking about companies and bloat while I am speaking about being
conservative?

> Seek simplicity and efficiency, not complication.
> This is an extraordinarily ironic thing to say to Jeremy Rubin, who
> designed CTV with exactly that in mind. It is an incredibly simple opcode
> that doesn't allow recursive covenants or various other things that people
> have been worried about in the past about covenants. I'm 99% confident that
> there is no simpler, more efficient, and less complicated covenant opcode
> than CTV that can even possibly be designed. The only one on par is
> TXHASH+CSFS and that has more complex implications than CTV.


No, you're ironic in thinking that adding complication to Bitcoin's base
layer is somehow a means of valuing simplicity. I don't know who you are,
and since you and Jeremy have no reputation with me, I have no reason to
care about your "99%" confidence in something that I cannot distinguish
from an attack and have no personal need for. This is how trust and
incentives work!

There are MANY people out there that would like more complex, more powerful
> covenants. "The market" is  in fact demanding it. And yet because we must
> move carefully in Bitcoin, CTV is a compromise that focuses on simplicity
> and incremental change rather than radical change. Do you really disagree
> that CTV was intended to be as simple as possible and achieves that goal?


Speaking for myself, and likely the great majority of the market: "Don't
know, don't care." Your self-ascribed ability to assess the market is
objectively overconfident because we all know there is no way to
confidently measure this market by polling or analysis, and that most of
this market does not even know CTV exists, and the portion that does know
of CTV is barely competent enough to audit or bless it. That is just
reality.

> There is simply no urgency or problem that any of the proposed soft fork
> features are trying to address.
> That is pretty subjective, and very debatable. But ignoring the
> debatableness of it, why is urgency even necessary for an improvement to
> bitcoin? Should we wait until a problem is urgent to fix it? Or should we
> get ahead of it so we don't risk making hasty mistakes?


What is necessary is demand. All forms of scale and complexity come at a
cost to Bitcoin users. That cost is only offset AFTER the feature has
reached saturati

Re: [bitcoin-dev] Working Towards Consensus

[John Carvalho via bitcoin-dev]

Jeremy,

The path to consensus is to propose things that everyone needs. Demand
comes from the market, not the designers.

Designers (engineers) solve problems with designs, but when they speculate
and lead the process, they create problems instead. Bitcoin is not a place
for speculative feature additions. Bitcoin cannot afford a culture of
additive features no one is asking for. Bitcoin thrives in a culture of
"NO." Rejection of change is Bitcoin's primary feature.

There is NO HOPE of EVER getting the majority of Bitcoin users to be able
to grasp, audit, and meaningfully consent to complicated new features, nor
to assess how they may interact with existing features in undesirable ways
or affect Bitcoin's incentive structure. To ignore this is a selfish
egomania that too many devs succumb to. The public already trusts Core devs
more than they probably should, and it is unwise to lean on that trust.

You are of course welcome to try and research and document all of the
details about how this plays out in practice, but you will fail to specify
a path to approval or any sort of clear governance structure for ensuring
that speculative features get into Bitcoin. You will seek and only see a
bias that allows you to get what YOU want. Until you focus on what everyone
wants, you will not reach consensus on anything.

Bitcoin changes should solve obvious problems and provide easy wins on
optimization, security, and privacy. Seek simplicity and efficiency, not
complication.

We have yet to saturate usage of the features we have added already in the
past 5 years. Use those. It is becoming apparent over time that many
features can be accomplished off-chain, or without a blockchain, or by
merely anchoring into currently available bitcoin transaction types.

There is simply no urgency or problem that any of the proposed soft fork
features are trying to address. This includes APO, CTV, sidechain
proposals, etc, etc.

Your aggression to your purpose is the antithesis of consensus, as it
indicates your incentives are external to it.

--
John Carvalho
CEO, Synonym.to 


On Mon, May 2, 2022 at 3:43 AM <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. Re: What to do when contentious soft fork activations are
>   attempted (Billy Tetrud)
>2. Working Towards Consensus (Jeremy Rubin)
>
>
> --
>
> Message: 1
> Date: Sun, 1 May 2022 14:14:29 -0500
> From: Billy Tetrud 
> To: alicexbt ,  Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] What to do when contentious soft fork
> activations are attempted
> Message-ID:
> <
> cagppwdb-t4ob0nkv7o5k9yhdqjtmag1qlqm1jjn9fqmontp...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 alicexbt
>
> We of course want knowledgeable bitcoiners who aren't knowledgeable about a
> certain proposal to be skeptical. But what we don't want is for that
> natural skepticism-from-ignorance to be interpreted as opposition, or
> really a strong signal of any kind. Any thoughts from ignorance, whether
> self-aware or not, should be given small weight. It seems the vast majority
> of push back has been this kind of skepticism from ignorance. And to a
> certain degree I think we want to give time for understanding to those who
> have not participated in the first, second, third, etc round of discussion
> on a proposal. It may not be reasonable to say "you had the last 2 years of
> time to voice your concern".
>
> Now that CTV is being taken seriously as a proposal, we probably should
> give the community who is finally taking a serious look at it time to
> understand, get their questions answered, and come to terms with it. This
> is not to say that CTV as a technology or proposal has been rushed, or has
> not had enough work put into it, but rather that the community as a whole
> has not paid enough attention to it for long enough.
>
> The wrong approach is: "how do I yell more loudly next time I see something
> I'm uncomfortable with?" The right approach is to educate those who aren't
> educated on the proposal and gather consensus on what people think when
> they understand enough about it to contribute to that consensus. If you
> care about consensus, you should respect the consensus process and be ok
> with consensus being not your preferred outcome. If you don't