Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Bryan Bishop via bitcoin-dev]

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 pubkey
> for each recipient the user wants to send bitcoin to.
>

Isn't this the same problem but now for copy-pasting pubkeys instead of an
address?

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[rot13maxi via bitcoin-dev]

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 also be the more private 
one). I wanted to throw in another thing you can build with this setup: address 
authentication.

Bitcoin addresses don't (generally) carry any semantic information that humans 
can use at-a-glance to distinguish legitimate addresses from illegitimate 
addresses. There have been instances of clipboard-hijacking malware that have 
used this fact to steal bitcoin -- a user goes to a webpage (or email, or IM or 
whatever), copies an address, and then pastes it into their bitcoin wallet. 
Unbeknownst to them, the clipboard contents have been replaced with an address 
controlled by some bad actor. The wallet just builds the transaction to 
whatever addresses the "user" supplied, and the user is none-the-wiser until 
after the funds have left their wallet.

Now imagine instead that the wallet has some address book with a pubkey for 
each recipient the user wants to send bitcoin to. Alice wants to pay Bob, so 
she clicks "Bob" in her transaction UI. Her wallet goes and asks the address 
server for an address for Bob. The address server picks an unused address, and 
has it signed (depending on the setup, this could be that the address server 
also has the Address Authentication privkey for bob, or it could be that bob 
gets some callback or notification, or that bob has pre-signed a batch of 
addresses. it will depend on the implementation). The address server sends a 
signed blob back to alice that contains an address and a signature proving that 
the address is in fact Bob's. Now Alice's wallet can tell whether or not the 
address it's putting in the transaction output belongs to Bob, even if that 
data was intercepted between the address server and the wallet (this doesn't 
help if the address server is malicious or has been compromised, but that's a 
different problem).

It would be really nice to have a protocol here that can make wallets 
interoperable in fetching fresh addresses from Address Servers and in the 
return schema that can include signatures and other metadata (like optimistic 
expirations, maybe other invoice data?).

Love the conversation so far. Happy to dig into this further with anyone else 
interested :)

Cheers,
rijndael

--- Original Message ---
On Monday, October 3rd, 2022 at 7:01 PM, Ruben Somsen via bitcoin-dev 
 wrote:

> Hi David,
>
> Thanks for the excellent suggestion, that makes the protocol much more 
> elegant and actually increases my optimism about its practicality. Also, 
> interesting observation that there is overlap with BIP78. From the 
> perspective of the recipient it does mean there's a potential privacy 
> reduction when a placeholder transaction goes through (these should perhaps 
> be marked in the wallet?), but I suppose this is still better than no payment 
> at all. I also like your point that it doubles as a way to potentially bridge 
> gaps.
>
> Cheers,
> Ruben
>
> On Mon, Oct 3, 2022 at 12:48 AM David A. Harding  wrote:
>
>> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
>>> An alternative mitigation (more user friendly, but more implementation
>>> complexity) would be to require the sender to reveal their intended
>>> transaction to the server prior to receiving the address[^9]. This is
>>> not a privacy degradation, since the server could already learn this
>>> information regardless. If the transaction doesn't end up getting
>>> sent, any subsequent attempt to reuse one of the inputs should either
>>> be (temporarily) blacklisted or responded to with the same address
>>> that was given out earlier
>>> [...]
>>> [^9]: *This would essentially look like an incomplete but signed
>>> transaction where the output address is still missing.*
>>
>> Hi Ruben,
>>
>> Instead of maintaining a database of inputs that should be blocked or
>> mapped to addresses, have the spender submit to you (but not the
>> network) a valid transaction paying a placeholder address and in return
>> give them a guaranteed unique address. They can then broadcast a
>> transaction using the same inputs to pay the guaranteed unique address.
>> If you don't see that transaction within a reasonable amount of time,
>> broadcast the transaction paying the placeholder address. This makes it
>> cost the same to them whether they use the unique address or not. By
>> placeholder address, I mean an address of yours that's never received a
>> payment but which may have been provided in a previous invoice (e.g. to
>> prevent exceeding the gap limit).
>>
>> In short, what I think I've described is the BIP78 payjoin protocol
>> without any payjoining going on (which is allowed by BIP78). BTCPay
>> already implements BIP78, as do several wallets, and I think it
>> 

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

[yancy via bitcoin-dev]

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 reward of up to 10 + 1 + c, (c < 2, where c is the extra
transactions that fit).


If I'm reading this correctly, Block N was already mined, but the miner 
who mined block N+1 repacks the transactions from block N because they 
have more to gain.  Wouldn't such a situation be resolved in the same 
way as two miners who find a block at a similar time? E.g the network 
will choose depending on when block N+2 is created.



Assume instead your reward is 8, leaving 3+c on the table.


Mining block N+1 with the mempool leads to reward 2+8 = 10, reorging 
leads to 10 + 8 + c?  Wouldn't that leave 8+c?



If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for
them, which is the new one you made as a non-tip miner since you
"shared" some fee.


I'm curious how the "fee sharing" would be organized.  To see if I 
understand, You're asking what would happen if one of the two miners 
incentives (bribes in this case) the next miner (block N+1) to choose 
one of the competing tip miners?



You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require
larger incentive).


Agree.


However, as many have pointed out, perhaps not following the simple
"honest tip mining" strategy is bad for bitcoin, so maybe we should
expect it not to happen often?


The idea that people won't do something because it's "bad for Bitcoin" 
doesn't fit an adversarial model.  Even in the above examples (which I 
think wouldn't expect to happen often), I would argue the network still 
conforms to a Nash Equilibrium without requiring trust.  Although It's 
mostly speculation without some empirical data.


Cheers,
-Yancy

On 2022-10-17 21:10, Jeremy Rubin wrote:


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 the mempool leads to reward 2+1 = 3, reorging
leads to reward of up to 10 + 1 + c, (c < 2, where c is the extra
transactions that fit). Assume instead your reward is 8, leaving 3+c
on the table.

If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for
them, which is the new one you made as a non-tip miner since you
"shared" some fee.

You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require
larger incentive).

However, as many have pointed out, perhaps not following the simple
"honest tip mining" strategy is bad for bitcoin, so maybe we should
expect it not to happen often? Or other strategies to emerge around
selecting transactions so that the next M blocks have a similar fee
profile, as opposed to picking greedily for the next block.

--
@JeremyRubin [1 [1]]

On Sun, Oct 16, 2022 at 3:03 PM  wrote:

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.
It's interesting that Nash Equilibrium isn't mentioned here.  Since
each miner has the option to either contribute to the longest chain
or not, even if the miners know what strategy the other miners will
use, they still wouldn't change their decision to contribute to the
majority.

For example, if I run a shop that takes rain checks, but I sell an
item to a higher bidder who didn't have a hold on the item, that
is
not honest, but it may be selfish profit maximizing.
It would be honest if the store policy said ahead of time they are
allowed to sell rain checks for more in such an occurrence.
Although this is a good example of the difference between honest and
rational.  I think this means it's not a Nash Equilibrium if we
needed to rely on the store owner to be honest.

Satoshi said an honest majority is 

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

[Antoine Riard via bitcoin-dev]

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-RBF proposal has at least tried to bind to best communication
standards towards the community at large. If you think about more community
venues (Reddit, podcast, newsletter, ...) that developers may weigh in when
proposing Core policy changes, we can improve for next time.

About the kernel of the concern I understand, I think the whole discussion
would benefit from clarifications in precising zero-conf security bounds.
Relying only on first-seen and lack of RBF as a solo ground to estimate the
safety of an incoming transaction isn't that robust in a distributed system
like the p2p network. However, building management risks framework on top,
as additional security layers sound a far more compelling approach from a
developer perspective. A year ago, when I initially proposed full-rbf, I
noted a few ideas that could be implemented such as double-spend monitoring
or staked reputation to enhance zero-conf security [1]. For sure, there is
a wide solution space to explore and build on to improve the 0conf flows,
and it would marginally benefit LN, as we have now zero-conf channels [2].

That said, saying RBF causes more problems than it resolves sounds hard to
hold as a line from my perspective. As LN security relies on a reactive
model, where time-sensitive transactions must be included before a given
height to ensure funds safety, the ability to replace-by-fee previous bids
and have them propagating well on the network is fundamental. While I think
this is correct to say that today 0conf might be still a more significant
economic traffic than Lightning, the bitcoin user of tomorrow is likely to
expect both 0conf and Lightning, without caring that much about the
quibbles of the security mechanisms backing them.

Overall, RBF is far from being a "black-and-white" thing, dependending of
the perspective you're coming from, and thanks to everyone for patience in
this discussion.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
[2] https://github.com/lightning/bolts/pull/910

Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For
> the past
> few days we've been reviewing the latest bitcoin core release candidate,
> and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF
> flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to
> the new policies. However, when reviewing the 24.0 release candidate just
> a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately
> turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can
> delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue
> fixing
> the remaining relay policy problems, such as package relay and the RBF
> rules.
> Maybe we could go straight to an opt-out deployment locked by code at a
> certain
> height in the future to give time to everyone and, at the same time, avoid
> a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
> hope
> it helps.
>
> Cheers,
> Dario
>
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known
> by
> many in this list, it's useful to define precisely how they work to
> understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
> least
>   the two biggest bitcoin ATM manufacturers support this: Genesis Coin and

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

[Antoine Riard via bitcoin-dev]

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 miners and relay nodes to support unconditional
> RBF immediately, no matter how much that increases the risk to
> existing businesses that are still accepting unconfirmed txs

To give more context, the initial approach of enabling full RBF through
#25353 + #25600 wasn't making the assumption the enablement itself would
reach agreement of the economic majority or unanimity. Rather, it would
give the tools to node operators to build full-rbf relay paths and as such
to fulfill their applications requirements (e.g lightning dual-funding).
Without denying that such equilibrium would be unstable, it was designed to
remove the responsibility of the Core project itself to "draw a hard line"
on the subject. Moreover, relying on node operators turning on the setting
provides a smoother approach offering time to zero-conf services to react
in consequence.

So the current path definitely belongs more to a 3) approach. While this
way cannot be denied to be a zero-risk deployment for business accepting
unconfirmed transactions, it should be weighed in face of multi-party
contracting protocols encumbering an annoying pinning vector. It sounds to
me that an adequate way to resolve such a "split-risk" situation has been
to adopt a "micro" release practice rather than a "macro" one, namely offer
the options to node operators and let them vote with their respective
economic traffics.

Since Dario's mail, I think we have learnt new data points, a) on the long
term full RBF to align miner incentives is acknowledged and b) a clear
timeline based on e.g a block height is favored over the pollination
deployment.

As such, I think it makes sense to revise the full RBF deployment approach,
concentrating the discussion on the reasonable time buffer we should adopt
before activating full RBF on mainet. A time buffer realistic with respect
to the engineering,
operational and vendoring needs of the zero-conf businesses/applications. I
hope both #26305 and #26323 answer those criterias. Tie-breaking between
both, I believe I would favor something like #26323 though only post 24.0
to avoid introducing a bikeshedding precedent in terms of release process,
and with a longer timeline to be sure we ship 25.0 before the activation
day. Though listening to more feedback and decision factors, if we have
more things to consider.

> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.

Concerning my statement only, it should be re-contextualize with the other
statements calling the zero-conf operators to adapt their services, or
raise concerns, or be proactive at least [0]. On the other hand, from my
perspective, a status quo situation is also unsafe, as we left things like
multi-party coinjoins being DoSed by deanonymizing attackers. So in case of
risk arbitrage situation, as developers, best we can do is be vocal about
it and if possible find a common ground among all stakeholders. And I think
this is what this current thread aims to achieve, which I would say is a
healthy release process.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

Le dim. 16 oct. 2022 à 04:09, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notion
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes over
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  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 

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

[Antoine Riard via bitcoin-dev]

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
question of timeline to allow the zero-conf apps ecosystem to do the
overhaul required.

To recall, my initial motivation to deprecate opt-in RBF over the whole
network is to mitigate a low-cost and easy DoS vector affecting the funding
phase of multi-party contracting protocols:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

As of current, upcoming Bitcoin Core 0.24 release, a `mempoolfullrbf`
setting is introduced defaulting to false. This option allows a node to
accept transaction replace-by-fee without requiring replaceability
signaling. If we assume a reasonable social inertia among Bitcoin Core node
operators, full-rbf transaction-relay paths should be rare. To palliate to
this concern, the introduction of a temporary `NODE_FULL_RBF` service bit
and automated preferential peering is proposed with:

https://github.com/bitcoin/bitcoin/pull/25600

This PR doesn't make the assumption that full-rbf is wished by the majority
of the network of node operators and rather favors an opt-in full-rbf
deployment. The existence of few full-rbf transaction-relay paths and
mining hashrate is sufficient to achieve mitigation of the DoS vector.

As #25600 boosts the deployment of full-rbf transaction-relay paths, and
induces a side-effect of a weakening of zero-conf apps, I can understand
this is not the approach offering the more visibility and predictability to
zero-conf operators.

Since then two more approaches have been proposed, a 1st one turning on by
default `mempoolsetting`, at best to land in 25.0, i.e ~6 months now
following the usual Core release schedule:

https://github.com/bitcoin/bitcoin/pull/26305

A 2nd one making full-rbf by default at a flag day target, 1st May 2023,
aimed to land in 0.24, and as such giving a clear time point to zero-conf
node operators now.

A third option proposed has been to withdraw `mempoolfullrbf` setting for
0.24, now withdrawn by its author:

https://github.com/bitcoin/bitcoin/pull/26287

While in theory, the release process about new policy changes should stay
flexible to correct the unforeseen impacts of policy changes, in the
present case the implications on zero-conf services have been raised early
on when the changes were brought in Bitcoin Core, i.e 4 months ago.
Communication has been posted on this venue to invite zero-conf node
operators to express concerns at that time:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

On a procedural point, I think this is a reasonable standard, navigating in
an area where there are not that many precedents about the deprecation of a
Core policy rule.

Asking to the wider community of zero-conf node operators, among all the
approaches, what has the most likes and what other decision-making factors
should be considered. It is especially interesting if a 6 month time buffer
from now is sufficient for the zero-conf applications to upgrade, and if
not what are the concrete engineering or operational bottlenecks.

Best,
Antoine

Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For
> the past
> few days we've been reviewing the latest bitcoin core release candidate,
> and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF
> flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to
> the new policies. However, when reviewing the 24.0 release candidate just
> a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately
> turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can
> delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue
> fixing
> the remaining relay policy problems, such as package relay and the RBF
> rules.
> Maybe we could go straight to an opt-out deployment locked by code at a
> certain
> height in the future to give time to everyone and, at the same time, avoid
> a
> huge mempool divergence event?
>
> Below is 

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

[Jeremy Rubin via bitcoin-dev]

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 the mempool leads to reward 2+1 = 3, reorging leads
to reward of up to 10 + 1 + c, (c < 2, where c is the extra transactions
that fit). Assume instead your reward is 8, leaving 3+c on the table.

If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for them,
which is the new one you made as a non-tip miner since you "shared" some
fee.

You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require larger
incentive).


However, as many have pointed out, perhaps not following the simple "honest
tip mining" strategy is bad for bitcoin, so maybe we should expect it not
to happen often? Or other strategies to emerge around selecting
transactions so that the next M blocks have a similar fee profile, as
opposed to picking greedily for the next block.


--
@JeremyRubin 


On Sun, Oct 16, 2022 at 3:03 PM  wrote:

> 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.
>
>
> It's interesting that Nash Equilibrium isn't mentioned here.  Since each
> miner has the option to either contribute to the longest chain or not, even
> if the miners know what strategy the other miners will use, they still
> wouldn't change their decision to contribute to the majority.
>
>
> For example, if I run a shop that takes rain checks, but I sell an
> item to a higher bidder who didn't have a hold on the item, that is
> not honest, but it may be selfish profit maximizing.
>
>
> It would be honest if the store policy said ahead of time they are allowed
> to sell rain checks for more in such an occurrence.  Although this is a
> good example of the difference between honest and rational.  I think this
> means it's not a Nash Equilibrium if we needed to rely on the store owner
> to be honest.
>
>
> Satoshi said an honest majority is required for the chain to be
> extended. Honest is not really defined though. Honesty, in my
> definition, is that you follow a pre specified rule, rational or not.
>
>
> My take is that "rational" is probably a better word than honest.  In
> terms of a Nash Equilibrium, each participant is simply trying to maximize
> their outcome and honesty doesn't matter (only that participants are
> rational).
>
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior.
> This is maybe a good idea because, in theory, if the honest behavior
> is rational then we can make a weaker assumption of selfishness
> maximizing a parameter.
>
>
> I'm curious, can RBF can be described by a Nash Equilibrium?  If yes, then
> it also shouldn't matter if participants are honest?
>
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms of
> properties of Bitcoin, as well as pathways to weakening the
> assumptions without compromising the behaviors users expect the
> network to have.  An "extended white paper" if you will.
>
>
> White paper 1.1 :D
>
>
> A last reflection is that Bitcoin is specified with an honest majority
> assumption, but also has a rational dishonest minority assumption over
> both endogenous (rewards) and exogenous (electricity) costs. Satoshi
> did not suggest, at least as I read it, that Bitcoin works with an
> rational majority assumption. (If anyone thinks these three are
> similar properties you can make some trivial counterexamples)
>
>
> My take is the opposite unless I'm missing something.  Participants are
> always incentivized to choose the rational solution (Not to waste
> electricity on a minority chain).
>
> Cheers,
> -Yancy
>
> On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:
>
> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining
> representation 

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

[Jeremy Rubin via bitcoin-dev]

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, such as:

1) Many Keys deleted one time at the start, all parties seem to have an
exogenous interest in not having the keys, as well as an endogenous one
(e.g., trusted setup ceremonies for ZCash, all parties seem to love
privacy, but also if anyone thinks you have your key maybe they rubber hose
you)
2) Keys should be deleted, but only "in play" for some amount of time
(Bitcoin NG maybe, statechains after the coin does a withdrawal, PoS with
checkpoints)
3) "Keys" should be deleted, but can only cause mild or local harms /
resolvable (Lightning, both eltoo and traditional, old transactions are
"Keys")
4) Keys must be deleted for all time (proof of work if done as leader
election

In particular, I think the honest behavior assumptions are OK as long as
they are reasonably time bounded and observable. For example, in
transaction selection, assuming "honest behavior" may be acceptable because
if the property is not true, it doesn't fundamentally brick the system or
cause mass outage, but it does cause an annoyance and is observable.
Further, agents may have a rationalization for following the honest policy
even above their pointwise interest in profit maximizing, if they think it
makes their overall participation more valuable. This is because it is an
infinite game and not finite, the most effective strategies aren't always
doing to be next-step profit maximizing (for those new to these concepts,
http://www.econ.uiuc.edu/~hrtdmrt2/Teaching/GT_2015_19/L12.pdf is a decent
primer). The example of deleting keys is interesting, because you don't
need to make your defection observable. But for transaction selection, it
absolutely is.


Ultimately, I think the reason why (some) systems do the cop-out of "honest
majority rules" --> "secure outcome" is because of a belief that there is
an "existential unknown proof" that there is an infinite game that can be
described where this should be the dominant strategy for all players,
whether defined or not. However, one must be incredibly careful with such
assumptions of an unknown existential game to which that is the dominant
strategy to not abuse them to ex-falso-quod-libet themselves into a corner
(Bertrand Russel is the Pope) if such a game does not actually exist. It's
obviously much better to actually prove the incentive compatibility against
an explicit game with explicitly stated assumptions for this reason (can
include exogenous details like "wanting number-go-up", "have a 5 year
hardware investment", or "belief that 0conf working required for adoption").

I (somewhat) suspect that things like the 0Conf safety assumptions are in
this category where one must be careful, because I think there might not be
a game where they are secure, so it leads to being able to prove false. But
I also understand why others might think such a game would exist, so
therein the debate.

Best,

Jeremy
--
@JeremyRubin 


On Mon, Oct 17, 2022 at 11:51 AM Russell O'Connor 
wrote:

> 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
> stipulating their own honest majority or supermajority requirement.  For
> example, a proof of stake blockchain might require as a rule that users
> securely delete their signing keys after a period of time, and prove their
> blockchain secure under these rules.  They then argue that so long as the
> "honest" majority follows this rule, then there is no risk of
> reorganization.  If enough users don't delete their signing keys, well
> their honest majority assumption is violated, so anything goes.
>
> The thing is that it is most certainly in each user's interest to *not*
> delete their signing keys.   Each user has strictly more power and options
> available by keeping their keys and not deleting them.  This rule violation
> is undetectable, at least until it is too late and a coalition decides to
> try to collaborate for a reorg to their advantage.
>
> It is not reasonable to build a distributed pseudonymous system built on
> arbitrary rules and then simply define your system to be secure by fiat.
> Users need an incentive to follow the rules of the system or it just won't
> work.  In particular, the rules ought to form a Nash Equilibrium, and this
> is violated by, for example, a requirement that users delete their signing
> keys.  If Bitcoin relied on users acting against their own interest to
> function, I doubt Bitcoin would be in operation today.  Certainly I would
> have no 

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

[Russell O'Connor via bitcoin-dev]

>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
stipulating their own honest majority or supermajority requirement.  For
example, a proof of stake blockchain might require as a rule that users
securely delete their signing keys after a period of time, and prove their
blockchain secure under these rules.  They then argue that so long as the
"honest" majority follows this rule, then there is no risk of
reorganization.  If enough users don't delete their signing keys, well
their honest majority assumption is violated, so anything goes.

The thing is that it is most certainly in each user's interest to *not*
delete their signing keys.   Each user has strictly more power and options
available by keeping their keys and not deleting them.  This rule violation
is undetectable, at least until it is too late and a coalition decides to
try to collaborate for a reorg to their advantage.

It is not reasonable to build a distributed pseudonymous system built on
arbitrary rules and then simply define your system to be secure by fiat.
Users need an incentive to follow the rules of the system or it just won't
work.  In particular, the rules ought to form a Nash Equilibrium, and this
is violated by, for example, a requirement that users delete their signing
keys.  If Bitcoin relied on users acting against their own interest to
function, I doubt Bitcoin would be in operation today.  Certainly I would
have no interest in it.

While it doesn't really matter, I do believe Satoshi was also aware that
the rules cannot just be arbitrary, with no incentive to follow them.
After all, he did note that it was designed to be in the miner's self
interest to build upon the longest (most work) chain, even if that point
ended up being rather involved.  That is to say, I don't think that an
"honest" (i.e rule following) majority is meant to be taken as an
assumption, rather it is something that ought to be a consequence of the
design.

Anyhow, the above is simply a comment on "honest majority", and I'm not
trying to make a specific claim about RBF here, though I do have my
opinions and I do see how it is related.

On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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.
>
> There are multiple behaviors one can describe as honest, and economically
> rational or optimizing is not necessarily rational.
>
> For example, if I run a shop that takes rain checks, but I sell an item to
> a higher bidder who didn't have a hold on the item, that is not honest, but
> it may be selfish profit maximizing.
>
> Satoshi said an honest majority is required for the chain to be extended.
> Honest is not really defined though. Honesty, in my definition, is that you
> follow a pre specified rule, rational or not.
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior. This is
> maybe a good idea because, in theory, if the honest behavior is rational
> then we can make a weaker assumption of selfishness maximizing a parameter.
>
> However, Satoshi did not particularly bound what aspects of honesty are
> important for the network, because there isn't a spec defining exactly what
> is honest or not. And also as soon as people are honest, you can rely on
> that assumption for good effect.
>
> And sometimes, defining an honest behavior can be creating a higher
> utility system because most people are "law abiding citizens" who might not
> be short term rational. For example, one might expect that miners would be
> interested in making sure lightning closes are "accurate" because
> increasing the utility of lightning is good for Bitcoin, even if it is
> irrational.
>
> It 

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

[Greg Sanders via bitcoin-dev]

 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 have sketched out the sane design space for the transition, so now
it's time to choose how we want to spend our energy and time on this.

I do think patch complexity is a real concern, which
means fullrbf-signalling PR has a harder road to deployment and gets push
back from fullrbf-default-now folks who correctly argue this. It seems
useful to "prove a point" on the nature of these schemes, but not much else.

Personally I have no qualms with kicking back flag-day-fullrbf another
release cycle and 6 additional months to obviate the need for a 24.0
backport(however small!) and to give a bit more time to weigh choices.
People can begin testing with their node software on an opt-in basis(but
not the required ~10% of nodes), 25.0+ nodes will flag-day, then a year
from now the community can start testing if miners have picked up said
changes.

Speaking to no one in particular, there's no virtue in dragging on the
discussion to "prove a point" to "merchants"/"Core devs" when we could be
spending our time more wisely fixing the many other issues with our mempool
and wallet ecosystem.

Best,
Greg

On Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notion
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes over
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  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 miners and relay nodes to support unconditional
> RBF immediately, no matter how much that increases the risk to
> existing businesses that are still accepting unconfirmed txs
>
> I think Antoine gave a pretty decent rationale for why we shouldn't
> indefinitely continue with conditional RBF in [0] [1] -- it makes it
> easy to disrupt decentralised pooling protocols, whether that be for
> establishing lightning channels or coinjoins or anything else.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> It's also an unstable equilibrium -- if everyone does first-seen-is-final
> at the mempool level, everything is fine; but it only takes a few
> defectors to start relaying and mining full RBF txs to spoil zeroconf
> for everyone -- so even if it were desirable to maintain it forever,
> it's probably not actually possible to maintain it indefinitely.
>
> If so, that leaves the choice between (2) and (3). You might argue
> that there's a 4th option: ignore the problem and think about it later;
> but to me that seems like it will just eventually result in outcome (3).
>
>
> At least a few people are already running full RBF relay nodes [2] [3]
> [4], and there's a report that non-signalling RBF txs are now getting
> mined [5] when they weren't a few months ago [6]. I wasn't able to
> confirm the latter to my satisfaction: looking at mempool.observer, the
> non-RBF signalling conflicting txs don't seem to have been consistently
> paying a higher feerate, so I couldn't rule out the possibility that
> the difference might just be due to inconsistent relaying.
>
> [2] https://twitter.com/murchandamus/status/1552488955328831492
> [3] https://twitter.com/LukeDashjr/status/977211607947317254
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
>
> It seems to me that the best approach for implementing (3) would be
> to change the default for -mempoolfullrbf to true immediately, which
> is both what Knots has been doing for years, and what #26305 proposes
> [7].  So from seeing what people are actually *doing*, I could easily
> be convinced that (3) 

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

[John Carvalho via bitcoin-dev]

Simply, 0conf acceptance can be monitored and enforced by the merchant and
exposure to doublespends can be both mitigated and limited in size per
block. It is less expensive to be double-spent occasionally than to have a
delayed checkout experience. Responsible 0conf acceptance is both rational
and trusting.

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

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

Now RBF just kinda haunts us as the establishment keeps baking it deeper
and deeper into Bitcoin, despite almost no one using it, and despite it
having negative consequences on more popular use cases.

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


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