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
AJ,
Thanks for the latest PR and discussion, even if we know we're all (very,
very, very) tired of it running almost 10 years now. I think we're close to
a resolution, (2), or (3) as you note.
As ariard notes in
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we
seem to hav
>From my limited academic interactions, people generally take the "honest"
to mean following the rules (regardless of how bad it is for you to follow
those rules). This has in turn led to some blockchain designs based on
their own absurd set of rules, and simply waiving away their issues by
stipul
Good points, Russell.
I think maybe for that particular property, one can partition the types of
rules one can put into the "honest rules" without compromising the system.
For example, your "keys deleted" property is one that is surely bad, but it
can be broken down into a many different buckets,
Building on the most work chain is perhaps not rational in many normal
circumstances that can come up today under the stated reference strategy:
1) Take highest paying transactions that fit
2) Mine on tips
E.g., suppose:
Block N: Fees = 10, reward = 1
Mempool: Fees = 2
Mining block N+1 with th
Hi Dario,
Sorry for the latency in reply to the reaction about the full-rbf setting
I've initially pushed in 0.24, TABConf week has been a busy one.
>From my understanding, there is no disagreement from Muun wallet about the
gradual deployment of full-rbf by Bitcoin Core nodes, this is more a
que
Hi AJ,
> 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 mine
Hi John,
I hear your worry about RBF issuing concerns for 0conf acceptance
merchants. I don't think it has been denied in the first communication of
this opt-in rbf proposal back in June. Merchants/0confs builders have been
invited to bring voices to the surface at that time [0]. So this new
full-
Hi Jeremy,
Thanks for the reply. I do find the semantics of mempool and block org
interesting (although there's a lot on the topic I don't know).
E.g., suppose:
Block N: Fees = 10, reward = 1
Mempool: Fees = 2
Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
leads to re
Hi all,
I'm working on a light wallet and have been kicking around a really similar
idea (we already have a hosted component that knows the user's xpub, why not
provide an endpoint that can vend fresh receive addresses to senders and try to
make the easy-path for sending bitcoin to our users al
On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unbeknownst to them, the clipboard contents have been replaced with an
> address controlled by some bad actor.
>
[snip]
> Now imagine instead that the wallet has some address book with a pu
11 matches
Mail list logo
