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

[Peter Todd via bitcoin-dev]

On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin wrote:
> The difference between honest majority and longest chain is that the
> longest chain bug was something acknowledged by Satoshi & patched
> https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420
> .
> 
> 
> OTOH, we have more explicit references that the honest majority really
> should be thought of as good guys vs bad guys... e.g.

The point is Satoshi got a lot of very fundamental stuff wrong. Bringing up
what Satoshi wrote now, almost 14 years later, misleads less-technical readers
into thinking our understanding of Bitcoin is still based on that early,
incorrect, understanding.

Incidentally, you realize that it was _Satoshi_ who added RBF to Bitcoin with
nSequence replacements. My contribution was to fix that obviously broken design
with fee-based RBF (with nSequence a transaction could be replaced up to 4
billion times, using essentially unlimited P2P bandwidth; it was a terrible
idea).

> I do think the case can be fairly made for full RBF, but if you don't grok
> the above maybe you won't have as much empathy for people who built a
> business around particular aspects of the Bitcoin network that they feel
> are now being changed. They have every right to be mad about that and make
> disagreements known and argue for why we should preserve these properties.

Those people run mild sybil attacks on the network in their efforts to
"mitigate risk" by monitoring propagation; fundamentally doing so is
centralizing and unfair, as only a small number of companies can do that
without DoS attacking the P2P network. It's pretty obvious that reliance to
zeroconf is harmful to Bitcoin, and people trying to do that have repeatedly
taken big losses when their risk mitigations turned out to not work. Their only
right to be mad comes from the 1st Ammendment.

> As someone who wants for Bitcoin to be a system which doesn't arbitrarily
> change rules based on the whims of others, I think it important that we can
> steelman and provide strong cases for why our actions might be in the
> wrong, so that we make sure our justifications are not only well-justified,
> but that we can communicate them clearly to all participants in a global
> value network.

...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!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Peter Todd via bitcoin-dev]

On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg Sanders wrote:
> I don't doubt the use case(it's why I opened the issue!). I didn't want the
> proposal to die in case people found it odd that 61, 62, 63, but not 64
> bytes ended up being broadcast able.
> 
> Perhaps this is not an issue, especially since this isn't a consensus
> change like the Great Consensus Cleanup. Willing to change my proposal and
> PR if people have no strong objections.

I think it's fine if we only restrict 64 bytes. We have a specific reason to do
that and it's ok if we just tell people that. Only fairly-technical use-cases
are affected anyway.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Greg Sanders via bitcoin-dev]

I don't doubt the use case(it's why I opened the issue!). I didn't want the
proposal to die in case people found it odd that 61, 62, 63, but not 64
bytes ended up being broadcast able.

Perhaps this is not an issue, especially since this isn't a consensus
change like the Great Consensus Cleanup. Willing to change my proposal and
PR if people have no strong objections.

Greg

On Thu, Oct 20, 2022, 7:21 PM Peter Todd  wrote:

> On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > Hello fellow Bitcoiners,
> >
> > After looking at some fairly exotic possible transaction types, I ran
> into
> > the current policy limit requiring transactions to be 85 non-witness
> > serialized bytes. This was introduced as a covert fix to policy fix
> > for CVE-2017-12842. Later the real motivation was revealed, but the
> > "reasonable" constant chosen was not.
> >
> > I'd like to propose relaxing this to effectively the value BlueMatt
> > proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> > allow a single input, single output transaction with 4 bytes of OP_RETURN
> > padding, rather than padding out 21 bytes to get to p2wpkh size.
> >
> > The alternative would be to also allow anything below 64 non-witness
> bytes,
> > but this seems fraught with footguns for a few bytes gain.
>
> What footguns exactly? Spending a single input to OP_RETURN with no
> payload is
> a valid use to get rid of dust in the UTXO set.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy Rubin via bitcoin-dev]

The difference between honest majority and longest chain is that the
longest chain bug was something acknowledged by Satoshi & patched
https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420
.


OTOH, we have more explicit references that the honest majority really
should be thought of as good guys vs bad guys... e.g.
>
> Thanks for bringing up that point.
> I didn't really make that statement as strong as I could have. The
> requirement is that the good guys collectively have more CPU power than any
> single attacker.
> There would be many smaller zombie farms that are not big enough to
> overpower the network, and they could still make money by generating
> bitcoins. The smaller farms are then the "honest nodes". (I need a better
> term than "honest") The more smaller farms resort to generating bitcoins,
> the higher the bar gets to overpower the network, making larger farms also
> too small to overpower it so that they may as well generate bitcoins too.
> According to the "long tail" theory, the small, medium and merely large
> farms put together should add up to a lot more than the biggest zombie farm.
> Even if a bad guy does overpower the network, it's not like he's instantly
> rich. All he can accomplish is to take back money he himself spent, like
> bouncing a check. To exploit it, he would have to buy something from a
> merchant, wait till it ships, then overpower the network and try to take
> his money back. I don't think he could make as much money trying to pull a
> carding scheme like that as he could by generating bitcoins. With a zombie
> farm that big, he could generate more bitcoins than everyone else combined.
> The Bitcoin network might actually reduce spam by diverting zombie farms
> to generating bitcoins instead.
> Satoshi Nakamoto



There is clearly a notion that Satoshi categorizes good guys / bad guys as
people interested in double spending and people who aren't.

Sure, Satoshi's writings don't *really* matter in the context of what
Bitcoin is / can be, and I've acknowledged that repeatedly. For you to call
it misleading is more misleading than for me to quote from it!

There's a reason I'm citing it. To not read the original source material
that pulled the community together is to make one ignorant around why there
is resistance to something like RBF. This is because there are still
elements of the community who expect the rules that good-phenotype node
operators run to be the ones maximally friendly to resolving transactions
on the first seen basis, so that there aren't double spends. This is a view
which you can directly derive from these early writings around what one
should expect of node operators.

The burden rests on the community, who has undertaken a project to adopt a
different security model from the original "social contract" generated by
the early writings of Satoshi, to demonstrate why damaging one group's
reliance interest on a property derived from the honest majority assumption
is justified.

I do think the case can be fairly made for full RBF, but if you don't grok
the above maybe you won't have as much empathy for people who built a
business around particular aspects of the Bitcoin network that they feel
are now being changed. They have every right to be mad about that and make
disagreements known and argue for why we should preserve these properties.
As someone who wants for Bitcoin to be a system which doesn't arbitrarily
change rules based on the whims of others, I think it important that we can
steelman and provide strong cases for why our actions might be in the
wrong, so that we make sure our justifications are not only well-justified,
but that we can communicate them clearly to all participants in a global
value network.

--
@JeremyRubin 


On Thu, Oct 20, 2022 at 3:28 PM Peter Todd  wrote:

> On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev
> wrote:
> > The Bitcoin white paper says:
> >
> > The proof-of-work also solves the problem of determining representation
> in
> > majority decision
> > making. If the majority were based on one-IP-address-one-vote, it could
> be
> > subverted by anyone
> > able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.
> > The majority
> > decision is represented by the longest chain, which has the greatest
> > proof-of-work effort invested
> > in it. If a majority of CPU power is controlled by honest nodes, the
> honest
> > chain will grow the
> > fastest and outpace any competing chains. To modify a past block, an
> > attacker would have to
> > redo the proof-of-work of the block and all blocks after it and then
> catch
> > up with and surpass the
> > work of the honest nodes. We will show later that the probability of a
> > slower attacker catching up
> > diminishes exponentially as subsequent blocks are added.
> >
> >
> > This, Satoshi (who doesn't really matter anyways I 

Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction

[Peter Todd via bitcoin-dev]

On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev wrote:
> Hello fellow Bitcoiners,
> 
> After looking at some fairly exotic possible transaction types, I ran into
> the current policy limit requiring transactions to be 85 non-witness
> serialized bytes. This was introduced as a covert fix to policy fix
> for CVE-2017-12842. Later the real motivation was revealed, but the
> "reasonable" constant chosen was not.
> 
> I'd like to propose relaxing this to effectively the value BlueMatt
> proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> allow a single input, single output transaction with 4 bytes of OP_RETURN
> padding, rather than padding out 21 bytes to get to p2wpkh size.
> 
> The alternative would be to also allow anything below 64 non-witness bytes,
> but this seems fraught with footguns for a few bytes gain.

What footguns exactly? Spending a single input to OP_RETURN with no payload is
a valid use to get rid of dust in the UTXO set.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
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

[Peter Todd via bitcoin-dev]

On Tue, Oct 18, 2022 at 05:00:45PM +1000, Anthony Towns via bitcoin-dev wrote:
> 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.

FWIW I'm not aware of any zeroconf accepting businesses where exploiting double
spends can be done without significant legal risk. Bitrefill has significant
legal risk, because pretty much everything you buy with Bitrefill can be traced
to your real world identity. ATMs have less risk. But I haven't seen an ATM
that accepts BTC without a confirmation in many years. Nor have I found a
non-KYC/AML in-person currency exchange service that would accept funds without 
a
confirmation (yes, I've had to wait 30 mins to get my cash before!). And all
the anonymous crypto-exchange websites like FixedFloat require a confirmation.

I have found AML/KYC in-person currency exchange services that would accept
zero conf. But of course, they had sufficient details on me to just call the
police if I double-spent them.

In practice, there are very few people who are actually affected by zeroconf
going away.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wrote:
> 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.

My OpenTimestamps calendars all use RBF for optimal fee discovery. The fact is,
about 95% of OTS transactions mined are replacements rather than originals. I
also took a quick look, and found examples of replacements mined by Foundry
USA, AntPool, F2Pool, Binance Pool, ViaBTC, SlushPool, Luxor, MARA Pool, and
Poolin. That's at least 97.21% of all hashing power supporting opt-in RBF.

Are you claiming that almost all hashing power is irrational?

> 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.

Electrum *literally* has an undo button, implemented with RBF. I've used it a
half dozen times, and it's worked every time.

> 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?

Has anyone _ever_ implemented a node that rejects blocks containing
double-spends? I don't believe the code to reject such blocks even exists. Note
that it should: that's a terrible idea that could lead to sever consensus
problems.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev wrote:
> The Bitcoin white paper says:
> 
> The proof-of-work also solves the problem of determining representation in
> majority decision
> making. If the majority were based on one-IP-address-one-vote, it could be
> subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.
> The majority
> decision is represented by the longest chain, which has the greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes, the honest
> chain will grow the
> fastest and outpace any competing chains. To modify a past block, an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and then catch
> up with and surpass the
> work of the honest nodes. We will show later that the probability of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
> 
> 
> This, Satoshi (who doesn't really matter anyways I guess?) claimed that for
> Bitcoin to function properly you need a majority honest nodes.

Satoshi also made a very fundamental mistake: the whitepaper and initial
Bitcoin release chooses the *longest* chain, rather than the most work chain.
Longest chain is totally broken.

What Satoshi said in the whitepaper is completely irrelevant and quoting it in
circumstances like this is IMO misleading.


Anyway, obviously we should always try to make systems that work properly with
an economically rational majority, rather than the much more risky honest
majority. Economically rational is a better security guarantee. And whenever
possible we should go even further, using the standard computationally
infeasible guarantees (as seen in our EC signature schems), or even,
mathematically impossible (1+1=2).

It's notable how in ethereum land, their smart contract schemes have lead to
significant effort in economically rational MEV optimization, at a significant
cost to decentralization (eg majority of blocks are now OFAC compliant).
There's no reason why Bitcoin should be fundamentally any different in the long
run.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
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

[Peter Todd via bitcoin-dev]

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:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet with a good
> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > > where opt-in rbf vs fullrbf policies make any difference at all?
> > Sort of. But yes once this starts being abused systemically we will have to
> > do something else w RBF payments, such as crediting the amount in BTC to a
> > custodial account. But this option isn't available to your normal payment
> > processor type business.
> 
> So, what I'm hearing is:
> 
>  * lightning works great, but is still pretty small
>  * zeroconf works great for txs that opt-out of RBF

It's important to note that the businesses that say "zeroconf works great" for
them, appear to be achieving that by sybil attacking the network to measure
propagation. That's not sustainable nor decentralized, as only a small number
of companies can do that without causing a lot of harm to Bitcoin by using up
inbound slots. We've gone through this before with "zeroconf guarantee"
services, and the end result is not good.

It's in our interests to make sure those companies stop doing that, and no new
companies start.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Tue, Oct 18, 2022 at 10:30:26AM -0400, Russell O'Connor via bitcoin-dev 
wrote:
> It is most certainly the case that one can construct situations where not
> mining on the tip is going to be the prefered strategy.  But even if that
> happens on occasion, it's not like the protocol immediately collapses,
> because mining off the tip is indistinguishable from being a high latency
> miner who simply didn't receive the most work block in time.  So it is more

I don't believe that's a good argument.

A sufficiently large high latency miner who doesn't receive the most work block
in time would cause huge disruptions to the network, potentially causing other
miners to be unprofitable. I even gave a talk on this a few years back, on how
if Bitcoin mining in space becomes profitable, it'll cause enormous problems
due to the slow speed of light.

> of a question of how rare does it need to be, and what can we do to reduce
> the chances of such situations arising (e.g. updating our mining policy to
> leave some transactions out based on current (and anticipated) mempool
> conditions, or (for a sufficiently capitalized miner) leave an explicit,
> ANYONECANSPEND transaction output as a tip for the next miner to build upon
> mined blocks.)

...at which point the large miners are likely to be significantly more
profitable than small miners, because they can collect more fees. That's a
disaster.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
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

[Peter Todd via bitcoin-dev]

On Wed, Oct 19, 2022 at 03:17:51AM +, alicexbt via bitcoin-dev wrote:
> > 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").
> 
> Even I noticed this since I don't recall the developers of the 3 main 
> coinjoin implementations that are claimed to be impacted by opt-in RBF making 
> any remarks.

FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.
He gave me permission to republish our conversation:

> Hey, I wanted to know if you had any comments on full-rbf re: wasabi?

Doesn't really affect us, afaik
The cj doesn't signal rbf right now
And I guess it's a DoS vector if any input double spent will be relayed 
after successful signing
But we have way bigger / cheaper DoS vectors that don't get "exploited"
So probably doesn't matter
Wasabi client handles replacements / reorgs gracefully, so should be alright
We don't yet "use" rbf in the sense of fee bumping tx, but we should / will 
eventually

I haven't asked Joinmarket yet. But the impact on their implementation should
be very similar.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
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

[Eloy via bitcoin-dev]

There is obviously an alternative approach to the issue.

If we like opt-in RBF and would like to keep opt out RBF 0CONF working, we 
could add another option to punish those nodes that replace transactions. That 
is, a miner that publishes a block with a NO RBF, that is replaced (that is 
easy to check for a full node) could stop propagation of that block (so it have 
less chances to win). That would make the network decide when it is the time to 
deploy RBF.

It seems obvious for me that most devs prefer full RBF to force users to use 
centralized stuff (that is why the full RBF option is there already on core), 
but just wanted to make that clear that there is always a way to enforce a 
policy (read to keep zero conf working).

Regards.

El 20 de octubre de 2022 18:07:07 ART, Greg Sanders via bitcoin-dev 
 escribió:
>> If it were growing in line with lightning capacity in BTC, per
>bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>getting from 15% to 80% would then be about 8 years.
>
>I'd caution against any metrics-based approach like this, unless it's
>simply used for ballparking potential adoption curves to set a a timeframe
>people can live with.
>
>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 at all for reasoning about a path forward?
>
>Hoping to be wrong,
>Greg
>
>
>
>On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > > If someone's going to systematically exploit your store via this
>> > > mechanism, it seems like they'd just find a single wallet with a good
>> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>> > Sort of. But yes once this starts being abused systemically we will have
>> to
>> > do something else w RBF payments, such as crediting the amount in BTC to
>> a
>> > custodial account. But this option isn't available to your normal payment
>> > processor type business.
>>
>> 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
>> - the risk of fiat/BTC exchange rate changes between
>>   now and when the tx actually confirms is worrying
>>   even if it hasn't caused real problems yet
>>
>> (Please correct me if that's too far wrong)
>>
>> Maybe it would be productive to explore this opt-in RBF part a bit
>> more? ie, see if "we" can come up with better answers to some question
>> along the lines of:
>>
>>  "how can we make on-chain payments for goods priced in fiat work well
>>   for payees that opt-in to RBF?"
>>
>> That seems like the sort of thing that's better solved by a collaboration
>> between wallet devs and merchant devs (and protocol devs?), rather than
>> just one or the other?
>>
>> Is that something that we could talk about here? Or maybe it's better
>> done via an optech workgroup or something?
>>
>> If "we'll credit your account in BTC, then work out the USD coversion
>> and deduct that for your purchase, then you can do whatever you like
>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>> should just roll with that design, but make it more decentralised: have
>> the initial payment setup a lightning channel between the customer and
>> the merchant with the BTC (so it's not custodial), but do some magic to
>> allow USD amounts to be transferred over it (Taro? something oracle based
>> so that both parties are confident a fair exchange rate will be used?).
>>
>> Maybe that particular idea is naive, but having an actual problem to
>> solve seems more constructive than just saying "we want rbf" "but we
>> want zeroconf" all the time?
>>
>> (Ideally the lightning channels above would be dual funded so they could
>> be used for routing more generally; but then dual funded channels are
>> one of the things that get broken by lack of full rbf)
>>
>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>> create
>> > > two conflicting txs in advance, one paying the merchant, one paying
>> > > yourself, connect to many peers, relay the one paying the merchant to
>> > > the merchant, and the other to everyone else.
>> > > I'm just basing this off Peter Todd's stuff from years ago:
>> > >
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>> > >
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>> > Yeah, I know the list still 

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

[yancy via bitcoin-dev]

I had one other idea on the topic.  Namely, in the last section 
"calculation", Satoshi talks more about what he/she/they consider to be 
bad actors.  The idea that someone is not doing "tip mining" does not 
mean they are dishonest.


We consider the scenario of an attacker trying to generate an alternate 
chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open 
to arbitrary changes, such
as creating value out of thin air or taking money that never belonged 
to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes 
will never accept a block
containing them. An attacker can only try to change one of his own 
transactions to take back

money he recently spent.


It seems to me that there's a distinction in the game theoretics between 
"not tip mining" and actively being a bad actor (changing a past 
transaction signed by yourself).


I rewrote the "AttackerSuccessProbability" C function in Rust for fun:
https://github.com/yancyribbens/attacker-success-probability-rust

Cheers,
-Yancy

On 2022-10-18 18:27, Jeremy Rubin via bitcoin-dev wrote:


I think the issue with


I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority is
only considered an assumption because even if following the rules
were clearly the 100% dominant strategy, this doesn't prove that the
majority is honest, since mathematics cannot say what is happening
in the real world at any given time.  Still, we must have a reason
to think that the majority would be honest, and that reasoning
should come from an argument that the rule set is incentive
compatible.


epistemically is that even within the game that you prove the dominant
strategy, you can't be certain that you've captured (except maybe
through clever use of exogenous parameters, which reduces to the same
thing as % honest) the actual incentives of all players. For example,
you would need to capture the existence of large hegemonic governments
defending their legacy currencies by attacking bitcoin.

I think we may be talking past each other if it is a concern /
valuable exercise to decrease the assumptions that Bitcoin rests on to
make it more secure than it is as defined in the whitepaper. That's an
exercise of tremendous value. I think my point is that those things
are aspirational (aspirations that perhaps we should absolutely
achieve?) but to the extent that we need to fix things like the fee
market, selfish mining, mind the gap, etc, those are modifying Bitcoin
to be secure (or more fair is perhaps another way to look at it) in
the presence of deviations from a hypothesized "incentive compatible
Bitcoin", which is a different thing that "whitepaper bitcoin". I
think that I largely fall in the camp -- as evidenced by some past
conversations I won't rehash -- that all of Bitcoin should be
incentive compatible and we should fix it if not. But from those
conversations I also learned that there are large swaths of the
community who don't share that value, or only share it up to a point,
and do feel comfortable resting on honest majority assumptions at one
layer of the stack or another. And I think that prior / axiom is a
pretty central one to debug or comprehend when dealing with, as is
happening now, a fight over something that seems obviously not
incentive compatible.

--
@JeremyRubin [1 [1]]

On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
 wrote:

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
 wrote:

However, what *is* important about what Satoshi wrote is that it
is sort of the "social contract" of what Bitcoin is that we can
all sort of minimally agree to. This makes it clear, when we try
to describe Bitcoin with differing assumptions than in the
whitepaper, what the changes are and why we think the system might
support those claims. But if we can't prove the new description
sound, such as showing tip mining to be rational in a fully
adversarial model, it doesn't mean Bitcoin doesn't work as
promised, since all that was promised originally is functioning
under an honest majority. Caveat Emptor!
I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority is
only considered an assumption because even if following the rules
were clearly the 100% dominant strategy, this doesn't prove that the
majority is honest, since mathematics cannot say what is happening
in the real world at any given time.  Still, we must have a reason
to think that the majority would be honest, and that reasoning
should come from an argument that the rule set is incentive
compatible.

The stability of mining, 

Re: [bitcoin-dev] Batch validation of CHECKMULTISIG using an extra hint field

[ZmnSCPxj via bitcoin-dev]

Good morning Mark,

> The idea is simple: instead of requiring that the final parameter on the 
> stack be zero, require instead that it be a minimally-encoded bitmap 
> specifying which keys are used, or alternatively, which are not used and must 
> therefore be skipped. Before attempting validation, ensure for a k-of-n 
> threshold only k bits are set in the bitfield indicating the used pubkeys (or 
> n-k bits set indicating the keys to skip). The updated CHECKMULTISIG 
> algorithm is as follows: when attempting to validate a signature with a 
> pubkey, first check the associated bit in the bitfield to see if the pubkey 
> is used. If the bitfield indicates that the pubkey is NOT used, then skip it 
> without even attempting validation. The only signature validations which are 
> attempted are those which the bitfield indicates ought to pass. This is a 
> soft-fork as any validator operating under the original rules (which ignore 
> the “dummy” bitfield) would still arrive at the correct pubkey-signature 
> mapping through trial and error.

That certainly seems like a lost optimization opportunity.

Though if the NULLDATA requirement is already a consensus rule then this is no 
longer a softfork, existing validators would explicitly check it is zero?

> One could also argue that there is no need for explicit k-of-n thresholds now 
> that we have Schnorr signatures, as MuSig-like key aggregation schemes can be 
> used instead. In many cases this is true, and doing key aggregation can 
> result in smaller scripts with more private spend pathways. However there 
> remain many use cases where for whatever reason interactive signing is not 
> possible, due to signatures being pre-calculated and shared with third 
> parties, for example, and therefore explicit thresholds must be used instead. 
> For such applications a batch-validation friendly CHECKMULTISIG would be 
> useful.

As I understand it, MuSig aggregation works on n-of-n only.

There is an alternative named FROST recently, that supports k-of-n, however, 
MuSig aggregation works on pre-existing keypairs, and if you know the public 
keys, you can aggregate the public keys without requiring participation with 
the privkey owners.

For FROST, there is a Verifiable Secret Sharing process which requires 
participation of the n signer set.
My understanding is that it cannot use *just* pre-existing keys, the privkey 
owners will, after the setup ritual, need to store additional data (tweaks to 
apply on their key depending on who the k are, if my vague understanding is 
accurate).
The requirement of having a setup ritual (which does not require trust but does 
require saving extra data) to implement k-of-n for k < n is another reason some 
protocol or other might want to use explicit `OP_CHECKMULTISIG`.

(I do have to warn that my knowledge of FROST is hazy at best and the above 
might be wildly inaccurate.)

Regards,
ZmnSCPxj
___
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

[Greg Sanders via bitcoin-dev]

> If it were growing in line with lightning capacity in BTC, per
bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
getting from 15% to 80% would then be about 8 years.

I'd caution against any metrics-based approach like this, unless it's
simply used for ballparking potential adoption curves to set a a timeframe
people can live with.

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 at all for reasoning about a path forward?

Hoping to be wrong,
Greg



On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet with a good
> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > > where opt-in rbf vs fullrbf policies make any difference at all?
> > Sort of. But yes once this starts being abused systemically we will have
> to
> > do something else w RBF payments, such as crediting the amount in BTC to
> a
> > custodial account. But this option isn't available to your normal payment
> > processor type business.
>
> 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
> - the risk of fiat/BTC exchange rate changes between
>   now and when the tx actually confirms is worrying
>   even if it hasn't caused real problems yet
>
> (Please correct me if that's too far wrong)
>
> Maybe it would be productive to explore this opt-in RBF part a bit
> more? ie, see if "we" can come up with better answers to some question
> along the lines of:
>
>  "how can we make on-chain payments for goods priced in fiat work well
>   for payees that opt-in to RBF?"
>
> That seems like the sort of thing that's better solved by a collaboration
> between wallet devs and merchant devs (and protocol devs?), rather than
> just one or the other?
>
> Is that something that we could talk about here? Or maybe it's better
> done via an optech workgroup or something?
>
> If "we'll credit your account in BTC, then work out the USD coversion
> and deduct that for your purchase, then you can do whatever you like
> with any remaining BTC from your on-chain payment" is the idea, maybe we
> should just roll with that design, but make it more decentralised: have
> the initial payment setup a lightning channel between the customer and
> the merchant with the BTC (so it's not custodial), but do some magic to
> allow USD amounts to be transferred over it (Taro? something oracle based
> so that both parties are confident a fair exchange rate will be used?).
>
> Maybe that particular idea is naive, but having an actual problem to
> solve seems more constructive than just saying "we want rbf" "but we
> want zeroconf" all the time?
>
> (Ideally the lightning channels above would be dual funded so they could
> be used for routing more generally; but then dual funded channels are
> one of the things that get broken by lack of full rbf)
>
> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
> create
> > > two conflicting txs in advance, one paying the merchant, one paying
> > > yourself, connect to many peers, relay the one paying the merchant to
> > > the merchant, and the other to everyone else.
> > > I'm just basing this off Peter Todd's stuff from years ago:
> > >
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
> > >
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> > Yeah, I know the list still rehashes a single incident from 10 years ago
> to
> > declare the entire practice as unsafe, and ignores real-world data that
> of
> > the last million transactions we had zero cases of this successfully
> > abusing us.
>
> I mean, the avenue above isn't easy to exploit -- you have to identify
> the merchant's node so that they get the bad tx, and you have to connect
> to many peers so that your preferred tx propogates to miners first --
> and probably more importantly, it's relatively easy to detect -- if the
> merchant has a few passive nodes that the attacker doesn't know about
> it, and uses those to watch for attempted doublespends while it tries
> to ensure the real tx has propogated widely. So it doesn't surprise me
> at all that it's not often attempted, and even less often successful.
>
> > > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > > payments.
> > > So, based on last 

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

[David A. Harding via bitcoin-dev]

On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via 
bitcoin-dev wrote:

AJ previously wrote:
> presumably that makes your bitcoin
> payments break down as something like:
>5% txs are on-chain and seem shady and are excluded from zeroconf
>   15% txs are lightning
>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>   60% txs are on-chain and seem fine for zeroconf
Numbers are right. [...]


[...]

So the above suggests 25% of payments already get a sub-par experience 
[...]

going full rbf would bump that from 25% to 85%, which would be pretty
terrible.


Is it worth considering incremental steps between opt-in only (BIP125) 
and replace anything full RBF?  For example, in addition to opt-in RBF 
rules, treat any transaction with a txid ending in `0x1` as replacable?  
I assume 1/16th (6.25%) of transactions would match that pattern (some 
of which already opt-in to RBF, so the net effect would be smaller).  
This would have the following advantages:


1. We could see if miners are willing to enable unsignaled RBF at all

2. We could gather more evidence on how the change affects zeroconf 
businesses and everyday users, hopefully without requiring they make 
immediate and huge changes


3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding 
their txids, at least until full RBF is accomplished


4. We can increase the percentage of transactions subject to unsignaled 
RBF in later releases of Bitcoin Core, steadily moving the system 
towards full RBF without any sudden leaps (assuming nobody builds a 
successful relay and mining network with less restrictive replacement 
rules)


I don't think this directly helps solve the problems with non-replacable 
transactions suffered by contract protocols since any adversary can 
opt-out of this scheme by grinding their txid, but I do think there's an 
advantage in transitioning slowly when people are still depending on 
previous behaviors.


Thanks,

-Dave
___
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

[Anthony Towns via bitcoin-dev]

On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> > If someone's going to systematically exploit your store via this
> > mechanism, it seems like they'd just find a single wallet with a good
> > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > where opt-in rbf vs fullrbf policies make any difference at all?
> Sort of. But yes once this starts being abused systemically we will have to
> do something else w RBF payments, such as crediting the amount in BTC to a
> custodial account. But this option isn't available to your normal payment
> processor type business.

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
- the risk of fiat/BTC exchange rate changes between
  now and when the tx actually confirms is worrying
  even if it hasn't caused real problems yet

(Please correct me if that's too far wrong)

Maybe it would be productive to explore this opt-in RBF part a bit
more? ie, see if "we" can come up with better answers to some question
along the lines of:

 "how can we make on-chain payments for goods priced in fiat work well
  for payees that opt-in to RBF?"

That seems like the sort of thing that's better solved by a collaboration
between wallet devs and merchant devs (and protocol devs?), rather than
just one or the other?

Is that something that we could talk about here? Or maybe it's better
done via an optech workgroup or something?

If "we'll credit your account in BTC, then work out the USD coversion
and deduct that for your purchase, then you can do whatever you like
with any remaining BTC from your on-chain payment" is the idea, maybe we
should just roll with that design, but make it more decentralised: have
the initial payment setup a lightning channel between the customer and
the merchant with the BTC (so it's not custodial), but do some magic to
allow USD amounts to be transferred over it (Taro? something oracle based
so that both parties are confident a fair exchange rate will be used?).

Maybe that particular idea is naive, but having an actual problem to
solve seems more constructive than just saying "we want rbf" "but we
want zeroconf" all the time?

(Ideally the lightning channels above would be dual funded so they could
be used for routing more generally; but then dual funded channels are
one of the things that get broken by lack of full rbf)

> > I thought the "normal" avenue for fooling non-RBF zeroconf was to create
> > two conflicting txs in advance, one paying the merchant, one paying
> > yourself, connect to many peers, relay the one paying the merchant to
> > the merchant, and the other to everyone else.
> > I'm just basing this off Peter Todd's stuff from years ago:
> > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
> > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> Yeah, I know the list still rehashes a single incident from 10 years ago to
> declare the entire practice as unsafe, and ignores real-world data that of
> the last million transactions we had zero cases of this successfully
> abusing us.

I mean, the avenue above isn't easy to exploit -- you have to identify
the merchant's node so that they get the bad tx, and you have to connect
to many peers so that your preferred tx propogates to miners first --
and probably more importantly, it's relatively easy to detect -- if the
merchant has a few passive nodes that the attacker doesn't know about
it, and uses those to watch for attempted doublespends while it tries
to ensure the real tx has propogated widely. So it doesn't surprise me
at all that it's not often attempted, and even less often successful.

> > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > payments.
> > So, based on last year's numbers, presumably that makes your bitcoin
> > payments break down as something like:
> >5% txs are on-chain and seem shady and are excluded from zeroconf
> >   15% txs are lightning
> >   20% txs are on-chain but signal rbf and are excluded from zeroconf
> >   60% txs are on-chain and seem fine for zeroconf
> Numbers are right. Shady is too strong a word,

Heh, fair enough.

So the above suggests 25% of payments already get a sub-par experience,
compared to what you'd like them to have (which sucks, but if you're
trying to reinvent both money and payments, maybe isn't surprising). And
going full rbf would bump that from 25% to 85%, which would be pretty
terrible.

> RBF is a strictly worse UX as proven by anyone
> accepting bitcoin payments at scale.

So let's make it better? Building bitcoin businesses on the lie that
unconfirmed txs are safe and won't be replaced is going to bite us
eventually; focussing on trying to push that back indefinitely is just
going to make everyone 

[bitcoin-dev] Analysis of full-RBF deployment methods

[Dario Sneidermanis via bitcoin-dev]

Hello list,

Given that the release of 24.0 is upon us and there is little time to make a
complex decision regarding the deployment method of full-RBF, we've
documented
the different alternatives and their trade-offs. I hope this helps get to
the
best possible deployment!

Gist: https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee

# Current deployment options

1. Antoine's PR #26305: leave 24.0 as is, and merge opt-out in 25.0 or
later.
2. Marco's PR #26287: revert opt-in full-RBF in 24.0, and give more time to
   figure out what's next.
3. Marco's PR #26287 + Antoine's PR #26305: revert opt-in full-RBF in 24.0,
and
   merge opt-out in 25.0 or later.
4. Marco's PR #26287 + Anthony's PR #26323 (just the date commitment):
revert
   opt-in full-RBF in 24.0, and commit in 25.0 or later to a later date for
   opt-out activation.
5. Anthony's PR #26323: revert opt-in full-RBF in 24.0, and commit in 24.0
to a
   later date for opt-out activation.

Notice that once full-RBF is fully deployed, having a config option to
disable
it is mostly a foot gun: you will only hurt yourself by missing some
transactions. Maybe options 4 and 5 could remove the flag altogether
instead of
making it opt-out.

There are a few more options, but I don't think they would reasonably have
any
consensus, so I trimmed them down to make it easier to process.


# Dimensions of analysis

1. Zero-conf apps immediately affected

If we leave the flag for full-rbf in 24.0, zero-conf apps could be
immediately affected. More specifically, as Anthony explained much more
clearly [0], they would be in danger as soon as a relatively big mining
pool operator enables the full-RBF flag.

It turns out that the class of apps that could be immediately affected
(ie.
apps that were directly or indirectly relying on the first-seen policy
in an
adversarial setting) is larger than zero-conf apps, as exposed by Sergej
[1]. Namely, the apps committing to an exchange rate before on-chain
funds
are sent/finalized would start offering a free(ish) american call
option.

2. Predictable deployment date

Committing to an activation date for full-rbf on the social layer (eg.
"we'll merge the opt-out flag in 25.0") has the benefit of being
flexible in
the event of new data points but becomes less predictable (both for
applications and for full-rbf proponents).

Committing to an activation date for full-rbf on the code has the
benefit
that once node operators start deploying the code, the date is set in
stone,
and we can reason about when full-RBF will be fully deployed and usable.

3. Code complexity

Handling the commitment to a date in the code introduces further code
complexity. In particular, it's a deployment mechanism that, as far as I
know, hasn't been tried before, so we should be careful.

4. Smooth deployment

Full-RBF deployment has two distinct phases when analyzing the adoption
in
the transaction relaying layer. First, there will be multiple disjoint
connected components of full-RBF nodes. Eventually, we'll get to a
single(ish) connected component of full-RBF nodes.

The first deployment phase is a bit chaotic and difficult to reason
about:
nobody can rely on full-RBF actually working; if it coincides with a
high-fees scenario, we'll get a big mempool divergence event, causing
many
other issues and unreliability in the relaying and application layers.

I'm calling smooth deployment to a deployment that minimizes the first
phase, eg. by activating full-RBF simultaneously in as many
transaction-relaying nodes as possible.

5. Time to figure out the right deployment

Figuring out the right deployment method and timeline to activate
full-rbf
might be more time-consuming than what we are willing to wait for the
stable
release of 24.0. Decoupling the protection to zero-conf apps from
choosing a
deployment method and an activation date for opt-out might be a good
idea.

I'm probably forgetting some dimensions here, but it may be enough to grasp
the
trade-offs between the different approaches.


# Comparison

Gist:
https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee#comparison

# Timeline for full-RBF activation

If we make some UX trade-offs, Muun can be production ready with the
required
changes in 6 months. Having more time to avoid those trade-offs would be
preferable, but we can manage.

The larger application ecosystem may need a bit more time since they might
not
have the advantage of having been working on the required changes for a
while
already. Ideally, there should be enough time to reach out to affected
applications and let them make time to understand the impact, design
solutions,
implement them, and deploy them.

Finally, if a smooth deployment (as previously defined) is desired, we can
lock
an activation date in the code and give relaying nodes enough time to
upgrade
before activation. 

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

[Sergej Kotliar via bitcoin-dev]

It's a good idea in theory, the issue is that most wallets and services
bitcoin users use today to send bitcoin don't use solutions to that. So we
end up with "you need to use X wallet to buy stuff", which is equivalent to
"you need to use a Lightning wallet to buy stuff"

On Thu, 20 Oct 2022 at 16:14, Ruben Somsen  wrote:

> Hi,
>
> There is a reasonable tradeoff one can make to get eventual settlement
> assurance prior to confirmation: lock up the funds with a counterparty in a
> 2-of-2 multisig with a timelock back to the owner. As long as the timelock
> has not expired and the recipients trust the counterparty not to sign
> double spends, transactions that are spent from this multisig can be
> considered instant. In cases where the counterparty and the recipient are
> the same person, this solution is trustless. Since merchant purchases tend
> to be low-value, the counterparty risk (facilitating double spends) seems
> acceptable. GreenAddress provided such a service in 2015 or so, but the
> idea got abandoned.
>
> Personally, I find this solution much more tenable than relying on
> spurious network assumptions about what will be propagated and mined.
>
> Best regards,
> Ruben
>
>
>
> On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, 20 Oct 2022 at 09:22, Anthony Towns  wrote:
>>
>>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > The
>>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> > (it's actually quite easily managed),
>>>
>>> You mean "it's quite easily managed, provided the transaction doesn't
>>> opt-in to rbf", right? At least, that's what I understood you saying last
>>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>>> matter what other trustworthy signals you might see:
>>>
>>>   https://twitter.com/ziggamon/status/1435863691816275970
>>>
>>> (rbf txs seem to have increased from 22% then to 29% now)
>>>
>>
>> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
>> are something other than consumer purchases, and most consumer purchases
>> can't do RBF
>>
>>
>>> > it's FX risk as the merchant must
>>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> > some transactions lose money to FX and others earn money - that evens
>>> out
>>> > in the end.
>>>
>>> > But if there is an _easily accessible in the wallet_ feature to
>>> > "cancel transaction" that means it will eventually get systematically
>>> > abused. A risk of X% loss on many payments that's easy to
>>> systematically
>>> > abuse is more scary than a rare risk of losing 100% of one occasional
>>> > payment. It's already possible to execute this form of abuse with
>>> opt-in
>>> > RBF,
>>>
>>> If someone's going to systematically exploit your store via this
>>> mechanism, it seems like they'd just find a single wallet with a good
>>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>>> where opt-in rbf vs fullrbf policies make any difference at all?
>>>
>>
>> Sort of. But yes once this starts being abused systemically we will have
>> to do something else w RBF payments, such as crediting the amount in BTC to
>> a custodial account. But this option isn't available to your normal payment
>> processor type business.
>>
>> Also worth keeping in mind that sometimes "opportunity makes the thief".
>> Currently only power-user wallet have that feature and their market share
>> is relatively small, mainly electrum stands out. But if this is available
>> to all users everywhere then it will start being abused and we'll have to
>> then direct all payments to custodial account, or some other convoluted
>> solution.
>>
>>
>>> It's not like existing wallets that don't let you set RBF will suddenly
>>> get a good UX for replacing transactions just because they'd be relayed
>>> if they did, is it?
>>>
>>> > To successfully fool (non-RBF)
>>> > zeroconf one needs to have access to mining infrastructure and
>>> probability
>>> > of success is the % of hash rate controlled.
>>>
>>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>>> two conflicting txs in advance, one paying the merchant, one paying
>>> yourself, connect to many peers, relay the one paying the merchant to
>>> the merchant, and the other to everyone else.
>>>
>>> I'm just basing this off Peter Todd's stuff from years ago:
>>>
>>>
>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>>
>>>
>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>>
>>>
>>
>> Yeah, I know the list still rehashes a single incident from 10 years ago
>> to declare the entire practice as unsafe, and ignores real-world data that
>> of the last million transactions we had zero cases of this successfully
>> abusing us.
>>
>>
>>> > Currently Lightning is somewhere around 15% 

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

[Ruben Somsen via bitcoin-dev]

Hi,

There is a reasonable tradeoff one can make to get eventual settlement
assurance prior to confirmation: lock up the funds with a counterparty in a
2-of-2 multisig with a timelock back to the owner. As long as the timelock
has not expired and the recipients trust the counterparty not to sign
double spends, transactions that are spent from this multisig can be
considered instant. In cases where the counterparty and the recipient are
the same person, this solution is trustless. Since merchant purchases tend
to be low-value, the counterparty risk (facilitating double spends) seems
acceptable. GreenAddress provided such a service in 2015 or so, but the
idea got abandoned.

Personally, I find this solution much more tenable than relying on spurious
network assumptions about what will be propagated and mined.

Best regards,
Ruben



On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, 20 Oct 2022 at 09:22, Anthony Towns  wrote:
>
>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > The
>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> > (it's actually quite easily managed),
>>
>> You mean "it's quite easily managed, provided the transaction doesn't
>> opt-in to rbf", right? At least, that's what I understood you saying last
>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>> matter what other trustworthy signals you might see:
>>
>>   https://twitter.com/ziggamon/status/1435863691816275970
>>
>> (rbf txs seem to have increased from 22% then to 29% now)
>>
>
> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
> are something other than consumer purchases, and most consumer purchases
> can't do RBF
>
>
>> > it's FX risk as the merchant must
>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> > some transactions lose money to FX and others earn money - that evens
>> out
>> > in the end.
>>
>> > But if there is an _easily accessible in the wallet_ feature to
>> > "cancel transaction" that means it will eventually get systematically
>> > abused. A risk of X% loss on many payments that's easy to systematically
>> > abuse is more scary than a rare risk of losing 100% of one occasional
>> > payment. It's already possible to execute this form of abuse with opt-in
>> > RBF,
>>
>> If someone's going to systematically exploit your store via this
>> mechanism, it seems like they'd just find a single wallet with a good
>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>> where opt-in rbf vs fullrbf policies make any difference at all?
>>
>
> Sort of. But yes once this starts being abused systemically we will have
> to do something else w RBF payments, such as crediting the amount in BTC to
> a custodial account. But this option isn't available to your normal payment
> processor type business.
>
> Also worth keeping in mind that sometimes "opportunity makes the thief".
> Currently only power-user wallet have that feature and their market share
> is relatively small, mainly electrum stands out. But if this is available
> to all users everywhere then it will start being abused and we'll have to
> then direct all payments to custodial account, or some other convoluted
> solution.
>
>
>> It's not like existing wallets that don't let you set RBF will suddenly
>> get a good UX for replacing transactions just because they'd be relayed
>> if they did, is it?
>>
>> > To successfully fool (non-RBF)
>> > zeroconf one needs to have access to mining infrastructure and
>> probability
>> > of success is the % of hash rate controlled.
>>
>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>> two conflicting txs in advance, one paying the merchant, one paying
>> yourself, connect to many peers, relay the one paying the merchant to
>> the merchant, and the other to everyone else.
>>
>> I'm just basing this off Peter Todd's stuff from years ago:
>>
>>
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>
>>
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>
>>
>
> Yeah, I know the list still rehashes a single incident from 10 years ago
> to declare the entire practice as unsafe, and ignores real-world data that
> of the last million transactions we had zero cases of this successfully
> abusing us.
>
>
>> > Currently Lightning is somewhere around 15% of our total bitcoin
>> payments.
>>
>> So, based on last year's numbers, presumably that makes your bitcoin
>> payments break down as something like:
>>
>>5% txs are on-chain and seem shady and are excluded from zeroconf
>>   15% txs are lightning
>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>   60% txs are on-chain and seem fine for zeroconf
>>
>
> Numbers are right. Shady is too strong a word, it's mostly transactions
> 

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

[Sergej Kotliar via bitcoin-dev]

On Thu, 20 Oct 2022 at 03:37, Antoine Riard  wrote:

> Hi Sergej,
>
> Thanks for the insightful posting, especially highlighting the FX risk
> which was far from being evident on my side!
>
> I don't know in details the security architecture of Bitrefill zeroconf
> acceptance system, though from what I suppose there is at least a set of
> full-nodes well-connected across the p2p network, on top of which some
> mempools reconciliation is exercised
> and zeroconf candidate sanitize against. While I believe this is a
> far-more robust deployment against double-spend attempts, there is still
> the ability for a sophisticated attacker to "taint" miner mempools, and
> from then partition judiciously the transaction-relay network to game such
> distributed mempool monitoring system. There is also the possibility of an
> attacker using some "divide-and-conquer" transaction broadcast algorithm to
> map Bitrefill monitoring point, though as far as I'm aware such algorithm
> has not been discussed. I agree with all of that, easier said than done.
>

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 implement more
of the countermeasures as appropriate to the abuse that has happened in the
wild.


> On the efficacy of RBF, I understand the current approach of assuming
> "manual" RBFing by power users ill UX thinking. I hope in the future to
> have automatic fee-bumping implemented by user wallets, where a fee-bumping
> budget and a confirmation preference are pre-defined for all payments, and
> the fee-bumping logic "simply" enforcing the user policy, ideally based on
> historical mempool data. True fact: we don't have such logic in consumer
> wallets today.
>

In deed. And the vast majority of bitcoin users don't even have access to
any RBF functionality today, so we're not even seeing gradual development
of these things yet. I think this fact needs to be taken into account when
designing breaking changes to bitcoin policy. Had these things been in
place and widely used the conversation would have been much easier.

Fundamentally, my view is that all the UX problems related to RBF alone are
sufficient of an issue to hold off on rolling out these upgrades for the
foreseeable future and think of other ways of solving the pinning issue and
other issues w the current policy. Might be that it's just a fundamental
goal conflict that different people want different behavior but I remain
optimistic for creative solutions from both sides. UX issues are soft as
opposed to theoretical attack vectors which are hard and binary, we need
find a way to weigh "even though it doesn't happen it can theoretically be
hacked" against "many users find it confusing and stressful" which is not a
trivial assessment to do.

All that said, I learn to converge that as a community we would be better
> off to weigh deeper the risks/costs between 0confs applications and
> contracting protocols in light of full-rbf.
>

In deed. And as you wrote in a different message, I agree that it's
unfortunate that there isn't more interaction between the mailing list and
services and companies using this stuff day-to-day. Not that it's anyone's
fault in particular, let's try from all sides to find more ways to create
more interaction on these topics. I've pinged a few colleagues that work on
payments in the space and hope they will chime in more in this forum!

All the best,
Sergej


> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about the
>> zero-conf (I'll get to that) but there is an even bigger danger called the
>> american call option, which risks endangering the entirety of BIP21 "Scan
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF would
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens out
>> in the end. But if there is an _easily accessible in the wallet_ feature to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

So it doesn't look like I'm ignoring a good question:

No solid noninteractive ideas, unless we get some very flexible sighash
softfork. Interactively, I think you can get collaborative fee bumps under
the current consensus regime and ephemeral anchors. The child will just be
built with inputs from different people.

On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne 
wrote:

> I'm also very happy to see this proposal, since it gets us closer to
> having a mechanism that allows the contribution to feerate in an
> "unauthenticated" way, which seems to be a very helpful feature for vaults
> and other contracting protocols.
>
> One possible advantage of the sponsors interface -- and I'm curious for
> your input here Greg -- is that with sponsors, assuming we relaxed the "one
> sponsor per sponsoree" constraint, multiple uncoordinated parties can
> collaboratively bump a tx's feerate. A simple example would be a batch
> withdrawal from an exchange could be created with a low feerate, and then
> multiple users with a vested interest of expedited confirmation could all
> "chip in" to raise the feerate with multiple sponsor transactions.
>
> Having a single ephemeral output seems to create a situation where a
> single UTXO has to shoulder the burden of CPFPing a package. Is there some
> way we could (possibly later) amend the ephemeral anchor interface to allow
> for this kind of collaborative sponsoring? Could you maybe see "chained"
> ephemeral anchors that would allow this?
>
>
> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Excellent proposal and I agree it does capture much of the spirit of
>> sponsors w.r.t. how they might be used for V3 protocols.
>>
>> The only drawbacks I see is they don't work for lower tx version
>> contracts, so there's still something to be desired there, and that the
>> requirement to sweep the output must be incentive compatible for the miner,
>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>> The Ephemeral UTXO concept can be a consensus rule (see
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>> a cleanup one can punt.
>>
>> One question I have is if V3 is designed for lightning, and this is
>> designed for lightning, is there any sense in requiring these outputs for
>> v3? That might help with e.g. anonymity set, as well as potentially keep
>> the v3 surface smaller.
>>
>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > does that effectively mark output B as unspendable once the child gets
>>> confirmed?
>>>
>>> Not at all. It's a normal spend like before, since the parent has been
>>> confirmed. It's completely unrestricted, not being bound to any
>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>
>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Hi Greg,

 Thank you very much for sharing your proposal!

 I think there's one thing about the second part of your proposal that
 I'm missing. Specifically, assuming the scenario of a v3 transaction with
 three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
 transaction spends A and OP_TRUE, does that effectively mark output B as
 unspendable once the child gets confirmed? If so, isn't the implication
 therefore that to safely spend a transaction with an ephemeral anchor, all
 outputs must be spent? Thanks!

 Best,
 Arik

 On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:

 Hello Everyone,

 Following up on the "V3 Transaction" discussion here
 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
 , I would like to elaborate a bit further on some potential follow-on work
 that would make pinning severely constrained in many setups].

 V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
 under some constraints[0]. This means that when a replacement is to be made
 and propagated, it costs the expected amount of fees to do so. This is a
 great start. What's left in this subset of pinning is *package limit*
 pinning. In other words, a fee-paying transaction cannot enter the mempool
 due to the existing mempool package it is being added to already being too
 large in count or vsize.

 Zooming into the V3 simplified scenario for sake of discussion, though
 this problem exists in general today:

 V3 transactions restrict the package limit of a V3 package to one
 parent and one child. If the parent transaction includes two outputs which
 can be immediately spent by separate parties, this allows one party to
 disallow a spend from the other. In Gloria's proposal 

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

[Sergej Kotliar via bitcoin-dev]

On Thu, 20 Oct 2022 at 09:22, Anthony Towns  wrote:

> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > The
> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> > (it's actually quite easily managed),
>
> You mean "it's quite easily managed, provided the transaction doesn't
> opt-in to rbf", right? At least, that's what I understood you saying last
> time; ie that if the tx signals rbf, then you just don't do zeroconf no
> matter what other trustworthy signals you might see:
>
>   https://twitter.com/ziggamon/status/1435863691816275970
>
> (rbf txs seem to have increased from 22% then to 29% now)
>

Yeah. Our share of RBF is a bit lower than that as many RBF transactions
are something other than consumer purchases, and most consumer purchases
can't do RBF


> > it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> > some transactions lose money to FX and others earn money - that evens out
> > in the end.
>
> > But if there is an _easily accessible in the wallet_ feature to
> > "cancel transaction" that means it will eventually get systematically
> > abused. A risk of X% loss on many payments that's easy to systematically
> > abuse is more scary than a rare risk of losing 100% of one occasional
> > payment. It's already possible to execute this form of abuse with opt-in
> > RBF,
>
> If someone's going to systematically exploit your store via this
> mechanism, it seems like they'd just find a single wallet with a good
> UX for opt-in RBF and lowballing fees, and go to town -- not something
> where opt-in rbf vs fullrbf policies make any difference at all?
>

Sort of. But yes once this starts being abused systemically we will have to
do something else w RBF payments, such as crediting the amount in BTC to a
custodial account. But this option isn't available to your normal payment
processor type business.

Also worth keeping in mind that sometimes "opportunity makes the thief".
Currently only power-user wallet have that feature and their market share
is relatively small, mainly electrum stands out. But if this is available
to all users everywhere then it will start being abused and we'll have to
then direct all payments to custodial account, or some other convoluted
solution.


> It's not like existing wallets that don't let you set RBF will suddenly
> get a good UX for replacing transactions just because they'd be relayed
> if they did, is it?
>
> > To successfully fool (non-RBF)
> > zeroconf one needs to have access to mining infrastructure and
> probability
> > of success is the % of hash rate controlled.
>
> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
> two conflicting txs in advance, one paying the merchant, one paying
> yourself, connect to many peers, relay the one paying the merchant to
> the merchant, and the other to everyone else.
>
> I'm just basing this off Peter Todd's stuff from years ago:
>
>
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>
>

Yeah, I know the list still rehashes a single incident from 10 years ago to
declare the entire practice as unsafe, and ignores real-world data that of
the last million transactions we had zero cases of this successfully
abusing us.


> > Currently Lightning is somewhere around 15% of our total bitcoin
> payments.
>
> So, based on last year's numbers, presumably that makes your bitcoin
> payments break down as something like:
>
>5% txs are on-chain and seem shady and are excluded from zeroconf
>   15% txs are lightning
>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>   60% txs are on-chain and seem fine for zeroconf
>

Numbers are right. Shady is too strong a word, it's mostly transactions
with very low fee, or high purchase amount, or many dependent unconfirmed
transactions, stuff like that. In some cases we do a human assessment of
the support ticket and often just pass them through.


> > This is very much not nothing, and all of us here want Lightning to grow,
> > but I think it warrants a serious discussion on whether we want Lightning
> > adoption to go to 100% by means of disabling on-chain commerce.
>
> If the numbers above were accurate, this would just mean you'd go from 60%
> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>

Point is that RBF transactions are unsafe even when waiting for a
confirmation, which Peter Todd trivially proved in the reply next to this.
The reliable solution is to reject all RBF payments and direct those users
to custodial accounts. There are other variants to solve this with varying
degree of convolutedness. RBF is a strictly worse UX as proven by anyone
accepting bitcoin payments at scale.


> > For me
> > personally it would be an easier discussion to have when Lightning is at
> > 

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

[Anthony Towns via bitcoin-dev]

On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),

You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At least, that's what I understood you saying last
time; ie that if the tx signals rbf, then you just don't do zeroconf no
matter what other trustworthy signals you might see:

  https://twitter.com/ziggamon/status/1435863691816275970

(rbf txs seem to have increased from 22% then to 29% now)

> it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end.

> But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF,

If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good
UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all? 

It's not like existing wallets that don't let you set RBF will suddenly
get a good UX for replacing transactions just because they'd be relayed
if they did, is it?

> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled.

I thought the "normal" avenue for fooling non-RBF zeroconf was to create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.

I'm just basing this off Peter Todd's stuff from years ago:

https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/

https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py

> Currently Lightning is somewhere around 15% of our total bitcoin payments.

So, based on last year's numbers, presumably that makes your bitcoin
payments break down as something like:

   5% txs are on-chain and seem shady and are excluded from zeroconf
  15% txs are lightning
  20% txs are on-chain but signal rbf and are excluded from zeroconf
  60% txs are on-chain and seem fine for zeroconf

> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce.

If the numbers above were accurate, this would just mean you'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.

> For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions.

Can you extrapolate from the numbers you've seen to estimate when that
might be, given current trends? Or perhaps when fine-for-zeroconf txs
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
work the same in a fullrbf world.

> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. 

To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look
better in comparison", but as a "making lightning work well is a bunch
of hard problems, here's the next thing we need in order to beat the
next problem".

> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.

I