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
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.
-
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 o
-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
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
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
>
> 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 d
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
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
tures 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
> > happeni
n.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, whi
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
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.
>
>
>
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
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 to
>
> > 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 cle
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 ad
17 matches
Mail list logo
