Hello Antoine,
Thanks for taking the time to answer every email with detailed analysis! I
can
see it's a lot of work. I'll answer inline.
On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard
wrote:
> Personally, I still think deferring full-rbf deployment, while it sounds
> reasonable to let existing
On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> On Thu, 20 Oct 2022 at 23:07, Greg Sanders wrote:
>
> > A large number of coins/users sit on custodial rails and this would
> > essentially encumber protocol developers to those KYC/AML institutions. If
> > Binance
On Thu, Oct 20, 2022 at 12:05:33AM -0400, Peter Todd wrote:
> ...and I checked this with Electrum on Android, which has a handy "Cancel
> Transaction" feature in the UI to easily cancel a payment. Which I did. You
> should have a pending payment from this email, and unsurprisingly I don't have
>
On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
> This is factually incorrect and not required for us to do what we do.
So how do you detect people sending conflicting transactions?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
On Fri, 21 Oct 2022 at 16:01, Greg Sanders wrote:
> Full-rbf is an odd duck, because while it is not a consensus issue, it
> does affect a large % of transactions made by wallets already, contrary to
> most policy changes.
>
Yeah, there are several policy features that are not consensus related
> Yeah, there are several policy features that are not consensus related
but end up de facto setting rules for how bitcoin behaves.
Yes, it's status quo so wallets "just know" not to do them. The fact that
the status quo would be changing is important, in that it may degrade UX
for 0-conf
Hello respected parties of the bitcoin network,
The point, as put forward by Jeremy is, economic rationality sometimes leads to
breaking the ’social contract’ set earlier in history.
Beyond its implications to RBF discussion, following economic rationality,
rather than trying to uphold the
Full-rbf is an odd duck, because while it is not a consensus issue, it does
affect a large % of transactions made by wallets already, contrary to most
policy changes. We have a status quo that is understandable, but
unfortunately long-term incentive incompatible.
It's also a UX issue, not a
On Thu, 20 Oct 2022 at 23:07, Greg Sanders wrote:
> A large number of coins/users sit on custodial rails and this would
> essentially encumber protocol developers to those KYC/AML institutions. If
> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> should this be an issue
On Thu, 20 Oct 2022 at 21:58, Anthony Towns wrote:
> So, what I'm hearing is:
>
> * lightning works great, but is still pretty small
> * zeroconf works great for txs that opt-out of RBF
> * opt-in RBF is a pain for two reasons:
> - people don't like that it's not treated as zeroconf
>
...and the easiest way to avoid Bitcoin being a system that doesn't
arbitrarily
change rules, is to rely on economically rational rules that aren't
likely to
change!
Yes, I think many people on this thread have been making the same point.
This is the basis of the Nash Equilibrium, from
This is factually incorrect and not required for us to do what we do.
On Fri, 21 Oct 2022 at 00:13, Peter Todd wrote:
> On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > >
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these
and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could
Hi Dario,
Thanks for this analysis of full-RBF deployment methods!
The subject was widely discussed at today Bitcoin Core IRC meetings:
https://gnusha.org/bitcoin-core-dev/2022-10-20.log
Personally, I still think deferring full-rbf deployment, while it sounds
reasonable to let existing services
14 matches
Mail list logo