Nostr notes by John Newbery [ARCHIVE]

📅 Original date posted:2020-05-05 📝 Original message: There ...

2023-06-09T13:00:06Z

In reply to nevent1q…afsn
_________________________

📅 Original date posted:2020-05-05
📝 Original message:
There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:

- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
- people might build products that depend on altruistic nodes serving data,
which is unsustainable
- maybe at some point in the future, light clients will need to pay for
services

The choice isn't between people using light clients or not. People already
use light clients. The choice between whether we offer them a light client
technology that is better or worse for privacy and scalability.

The arguments for why BIP 157 is better than the existing light client
technologies are available elsewhere, but to summarize:

- they're unique for a block, which means they can easily be cached.
Serving a filter requires no computation, just i/o (or memory access for
cached filter/header data) and bandwidth. There are plenty of other
services that a full node offers that use i/o and bandwidth, such as
serving blocks.
- unique-for-block means clients can download from multiple sources
- the linked-headers/filters model allows hybrid approaches, where headers
checkpoints can be fetched from trusted/signed nodes, with intermediate
headers and filters fetched from untrusted sources
- less possibilities to DoS/waste resources on the serving node
- better for privacy

> The intention, as I understood it, of putting BIP157 directly into
bitcoind was to essentially force all `bitcoind` users to possibly service
BIP157 clients

Please. No-one is forcing anyone to do anything. To serve filters, a node
user needs to download the latest version, set `-blockfilterindex=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
P2P. This is an optional, off-by-default feature.

Regards,
John

On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning ariard and luke-jr
>
>
> > > Trust-minimization of Bitcoin security model has always relied first
> and
> > > above on running a full-node. This current paradigm may be shifted by
> LN
> > > where fast, affordable, confidential, censorship-resistant payment
> services
> > > may attract a lot of adoption without users running a full-node.
> >
> > No, it cannot be shifted. This would compromise Bitcoin itself, which for
> > security depends on the assumption that a supermajority of the economy is
> > verifying their incoming transactions using their own full node.
> >
> > The past few years has seen severe regressions in this area, to the point
> > where Bitcoin's future seems quite bleak. Without serious improvements
> to the
> > full node ratio, Bitcoin is likely to fail.
> >
> > Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> > and should be actively avoided. BIP 157 improves privacy of fn-less
> usage,
> > while providing no real benefits to full node users (compared to more
> > efficient protocols like Stratum/Electrum).
> >
> > For this reason, myself and a few others oppose merging support for BIP
> 157 in
> > Core.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>
> The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> fullnode to get BIP157 service.
> This is supposed to improve to the situation relative to e.g. Electrum,
> where there are far fewer Electrum servers than fullnodes.
>
> Of course, as ariard computes, deploying BIP157 could lead to an effective
> DDoS on the fullnode network if a large number of BIP157 clients arise.
> Though maybe this will not occur very fast? We hope?
>
> It seems to me that the thing that *could* be done would be to have
> watchtowers provide light-client services, since that seems to be the major
> business model of watchtowers, as suggested by ariard as well.
> This is still less than ideal, but maybe is better than nothing.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/be23bd38/attachment-0001.html>;

📅 Original date posted:2015-12-23 📝 Original message: Hi ...

2023-06-09T12:45:30Z

In reply to nevent1q…slj4
_________________________

📅 Original date posted:2015-12-23
📝 Original message:
Hi all,

I've created a gist describing this idea here:
https://gist.github.com/jonnynewbs/a8ac4d7d27cb74c5b486 with images.

I recently watched Joseph Poon's presentation at the scaling bitcoin HK
conference. He argued that there's a natural tendency *away* from hubs and
centralization in lightning network, because a hub needs to hold bitcoin in
reserve for each payment channel:

image 1:

In this example Hector has tied up 40 bitcoin in order to open channels
with 4 nodes. He needs to place his bitcoin in those channels in order to
have enough liquidity to route payments through the channels. If all the
bitcoin in the channel had been fronted by the nodes, he wouldn't be able
to route payments.

In this example Alice tries to pay Bob through Hector, but Hector's channel
to Bob is depleted on Hector's side so he can't pay:

image 2:

The velocity of money through each of those channels is going to be low, so
Hector's profit opportunity to charge transfer fees on those channels is
low compared to the time that he's tying up his assets.

I started thinking about why it was that Hector would actually need to tie
up those funds. A properly-functioning hub should always have a net balance
of zero - all outflows from the hub are matched by inflows from another
node, so if the hub is working properly, it should always be solvent. Why
then does it necessarily need to hold a reserve for each node it connects
to?

Imagine someone wanted to create a hub in lightning *without* tying up
funds in lots of channels. One way he might start thinking about it:

1. Create some metatoken/coloured coin on top of bitcoin. Lets call it
Hectorcoin.
2. Open channels to different nodes, where the node provides the bitcoin
for the channel, and the hub provides Hectorcoins in the other direction.
The hub would only need to provide a negligable amount of actual bitcoin
value with Hectorcoins encoded on top of that small input.
3. If the channel gets closed and the node is net positive (ie in the
channel the bitcoin they initially provided plus some Hectorcoin), the node
can 'sell' the Hectorcoin back to the hub for bitcoin.

Hector's network would initially look like this. Bitcoin are in black,
Hectorcoin are in bold green:

image 3:

Transactions flow through the hub, and eventually Alice is 10 'bitcoin' up.
Hector hasn't sent her 10 real bitcoin through the channel, but 10
Hectorcoin. The network now might look like this:

image 4:

Note that Hector's balace of (Bitcoin + Hectorcoin) always remains 40.

Alice now wants to cash out her channel. She closes the channel as normal,
and then presents the Hectorcoin to Hector in exchange for actual bitcoin.
At this point either:

- Hector is holding enough bitcoin in reserve to pay out to Alice; or
- Hector doesn't hold enough bitcoin in reserve (In this scenario Hector
has a temporary *liquidity* issue, but remains *solvent*). He therefore
needs to close down his channels to Dan and Claire to free up his bitcoin
tied up in those channels.

This basic example requires counterparty trust in Hector. That's because
there's no way to prove that he actually holds enough bitcoin in his
reserves/channels to pay out in exchange for Hectorcoin *unless* those
coins are provable locked up somewhere (eg a multisig), which defeats the
whole purpose - he's trying to avoid tying up value. However, many people
might consider the efficiency and connectedness of dealing with a hub to be
a worthwhile trade-off on balance.

Hector might think about improving his hub by:

- somehow providing a proof that his net position is zero and so he's
provably solvent. That would eliminate the risk of a hub going rogue,
extracting coins from the network and becoming insolvent
- Having some way for Alice to automatically exchange Hectorcoin for that
value without asking Hector's permission.

Both of those things feel like they're possible, but perhaps someone
smarter than I am can comment on whether they actually are.

I'm not suggesting that this is the way we want to go, but thought it was
interesting enough to share. Interested to hear people's thoughts.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151223/2f9e7486/attachment.html>;

📅 Original date posted:2021-04-27 📝 Original message:ACK. ...

2023-06-07T22:52:13Z

In reply to nevent1q…kccf
_________________________

📅 Original date posted:2021-04-27
📝 Original message:ACK. These seem like very reasonable next steps.

On Mon, Apr 26, 2021 at 8:43 PM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > In general, I think its time we all agree the BIP process has simply
> failed
> > and move on. Luckily its not really all that critical and proposed
> protocol
> > documents can be placed nearly anywhere with the same effect.
>
> I recommend:
>
> 1. We add additional BIP editors, starting with Kalle Alm (if there are
> no continuing significant objections).
>
> 2. We seek Luke Dashjr's resignation as BIPs editor.
>
> 3. We begin treating protocol documents outside the BIPs repository as
> first-class BIP documentation.
>
> The first recommendation permits continued maintenance of existing BIPs
> plus gives the additional maintainers an opportunity to rebuild the
> credibility of the repository.
>
> The second recommendation addresses the dissatisfaction of many BIP
> authors and potential authors with the current editor, which I think
> will discourage many of them from making additional significant
> contributions to the repository. It also seems to me to be a better use
> of Luke's talents and interests for him to focus on protocol research
> and review rather than procedurally checking whether a bunch of
> documents are well formed.
>
> The third recommendation provides an escape hatch for anyone, such as
> Matt, who currently thinks the process has failed, or for anyone who
> comes to that same conclusion in the future under a different editing
> team. My specific recommendations there are:
>
> a. Anyone writing protocol documentation in the spirit of the BIP
> process can post their idea to this mailing list like we've always
> done and, when they've finished collecting initial feedback, they can
> assign themselves a unique decentralized identifier starting with
> "bip-". They may also define a shorter alias that they encourage
> people to use in cases where the correct document can be inferred
> from context. E.g.,
>
> bip-wuille-taproot (bip-taproot)
> bip-towns-versionbits-min-activation-height (bip-vbmah)
> bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
>
> b. The author then publishes the document to any place they'd like,
> although
> they are strongly encouraged to make any document source available
> under an open license to ensure others can create their own
> modifications.
>
> c. Implementations of BIPs, whether original repository BIPs or
> decentralized BIPs, link to the BIPs they implement to ensure
> researchers and developers can find the relevant protocol
> documentation. E.g.,
>
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
>
> (It may also be advisable for implementations to mirror copies of
> the BIPs they implement so later modifications to the document
> don't confuse anyone. For this reason, extremely liberal
> licensing of BIP documents is encouraged.)
>
> d. To help maintain quality and consistency between documentation, the
> BIP editors provide a BIP document template, guidelines similar to
> the existing BIP2, and an easy-to-run format linter.
>
> I think this decentralized BIPs alternative also helps address some
> longstanding problems with the BIPs system: that many casual Bitcoin
> users and developers think of documents in the BIPs repo as
> authoritative and that there are some development teams (such as for LN)
> that have already abandoned the BIPs process because, in part, they want
> complete control over their own documentation.
>
> The recommendations above were developed based on conversations I had
> with a few stakeholders in the BIPs process, but I did not attempt a
> comprehensive survey and I certainly don't claim to speak for anyone
> else. I hope the recommendations are satisfactory and I look forward to
> your feedback.
>
> Thanks,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210427/274ceb28/attachment.html>;

📅 Original date posted:2021-04-23 📝 Original message:ACK ...

2023-06-07T22:52:03Z

In reply to nevent1q…seut
_________________________

📅 Original date posted:2021-04-23
📝 Original message:ACK adding Kalle.

On Fri, Apr 23, 2021 at 4:36 AM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> ACK adding Kalle.
>
> Kalle is a qualified reviewer / editor and well suited for this role.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
>> assist in merging PRs into the bips git repo.
>>
>> Since there is no explicit process to adding BIP editors, IMO it should
>> be
>> fine to use BIP 2's Process BIP progression:
>>
>> > A process BIP may change status from Draft to Active when it achieves
>> > rough consensus on the mailing list. Such a proposal is said to have
>> > rough consensus if it has been open to discussion on the development
>> > mailing list for at least one month, and no person maintains any
>> > unaddressed substantiated objections to it.
>>
>> A Process BIP could be opened for each new editor, but IMO that is
>> unnecessary. If anyone feels there is a need for a new Process BIP, we
>> can go
>> that route, but there is prior precedent for BIP editors appointing new
>> BIP
>> editors, so I think this should be fine.
>>
>> Please speak up soon if you disagree.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/8b232111/attachment.html>;

📅 Original date posted:2021-03-02 📝 Original ...

2023-06-07T18:29:50Z

In reply to nevent1q…p8z7
_________________________

📅 Original date posted:2021-03-02
📝 Original message:Antoine,

Nothing in my proposal below precludes introducing a more comprehensive
feature negotiation mechanism at some later date. The only changes I'm
proposing are to Bitcoin Core's policy for how it treats its peer
connections.

> If we don't want to introduce a new message and
> corresponding code changes, it would be wise at least to extract VERSION's
> `fRelay` and how Core handles it in its own BIP.

I believe this is what BIP 60 does, or did you have something else in
mind?

> Explicit addr-relay negotiation will offer more
> flexibility

I agree!

> (and more hygienic code paths rather than triggering data
> structures initialization in few different locations).

Not sure what you mean by hygienic here. This seems like a code style
preference.

> Given inbound connections might be attacker-controlled and tx-relay
opt-out
> signaling is also attacker-controlled, wouldn't this give a bias toward an
> attacker in occupying our inbound slots ? Compared to honest inbound
peers,
> which in average are going to be full-relay.

Sorry - I meant that Bitcoin Core should allow a certain number of
inbound peers that do not relay txs. This would be in addition to the
full-relay inbound peers.

John

On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi John,
>
> > I think a good counter-argument against simply using `fRelay` for this
> > purpose is that we shouldn't reuse a protocol feature designed for one
> > function to achieve a totally different aim. However, we know that nodes
> > on the network have been using `fRelay` to disable transaction relay
> > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
> > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
> > later (when block-relay-only connections were introduced), so using
> > `fRelay` to disable transaction relay is now de facto part of the p2p
> > protocol.
>
>
> I don't think this is good practice ecosystem-wise. To understand tx-relay
> opt-out from peers correctly, a _non_ Bitcoin Core client has to implement
> the `fRelay` subset of BIP37, but ignore the wider part around FILTER*
> messages. Or implement those messages, only to disconnect peers sending
> them, thus following BIP111 requirements.
>
> Thus, future developers of bitcoin software have the choice between
> implementing a standard in a non-compliant way or implementing p2p messages
> for a light client protocol in a way of deprecation ? Even further, an
> interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
> the filter is set prevents a client being flooded with traffic in the brief
> window of time") would make it okay to send TX messages to your inbound
> block-relay-only peers. And that your client shouldn't be disconnected for
> such behavior.
>
> On the long-term, IMHO, better to have a well-defined standard with a
> clean negotiation mechanism rather than relying on code specifics of a
> given Bitcoin client. If we don't want to introduce a new message and
> corresponding code changes, it would be wise at least to extract VERSION's
> `fRelay` and how Core handles it in its own BIP.
>
> > I think a better approach would be for Bitcoin Core to only relay addr
> > records to an inbound peer if it has previously received an `addr` or
> > `addrv2` message from that peer, since that indicates definitively that
> > the peer actively gossips `addr` records. This approach was first
> > suggested by AJ in the original block-relay-only PR[15].
>
> If a node is willingly to opt-out from addr-relay from one of its inbound
> peers, how is it supposed to do ? Of course, you can drop such messages on
> the floor, your peer is just going to waste bandwidth for nothing. IIRC
> from past irc p2p meetings, we're really unclear about what a
> good-propagation-and-privacy-preserving addr-relay strategy should look
> like. Note, that distrusting your inbound peers with your addr-relay might
> be a sane direction. Explicit addr-relay negotiation will offer more
> flexibility (and more hygienic code paths rather than triggering data
> structures initialization in few different locations).
>
> > - update the inbound eviction logic to protect more inbound peers which
> > do not have transaction relay data structures.
>
> Given inbound connections might be attacker-controlled and tx-relay
> opt-out signaling is also attacker-controlled, wouldn't this give a bias
> toward an attacker in occupying our inbound slots ? Compared to honest
> inbound peers, which in average are going to be full-relay.
>
> Cheers,
> Antoine
>
>
>
> Le lun. 1 mars 2021 à 16:07, John Newbery via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi Suhas,
>>
>> Thank you for this proposal. I agree with your aims, but I think a new
>> P2P message isn't necessary to achieve them.
>>
>> # Motivation
>>
>> There are two distinct (but interacting) motivations:
>>
>> 1. Allow a node to accept more incoming connections which will only be
>> used for block propagation (no transaction relay or addr gossip),
>> while minimizing resource requirements.
>>
>> 2. Prevent `addr` gossip messages from being sent to peers which will
>> 'black hole' those addrs (i.e. not relay them further).
>>
>> These motivations interact because if we simply increase the number of
>> block-relay-only connections that nodes make without making any
>> allowance for the fact those connections won't gossip addr records, then
>> we'll increase the number of addr black holes and worsen addr gossip.
>>
>> # Using fRelay=false to signal no transaction relay.
>>
>> `fRelay` is an optional field in the `version` message. There are three
>> BIPs concerned with `fRelay`:
>>
>> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>> that they must not relay transactions over the connection until a
>> `filteradd` message has been received.
>>
>> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>> how widely this BIP has been adopted by implementations.
>>
>> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>> bloom filters are served by this node. According to this BIP, "If a
>> node does not support bloom filters but receives a "filterload",
>> "filteradd", or "filterclear" message from a peer the node should
>> disconnect that peer immediately."
>>
>> Within Bitcoin Core:
>>
>> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
>> filters.
>>
>> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
>> include the `fRelay` flag in `version` messages that it sends. Bitcoin
>> Core will tolerate the `fRelay` field being present or absent in any
>> `version` message that it receives[6].
>>
>> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that
>> point on, a Bitcoin Core node would disconnect peers that sent it
>> `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
>> peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
>> was extended to disconnect any peer that sends a `filter*` message,
>> regardless of its version (in general, a 'polite disconnect' for any
>> peer that requests an unsupported service is probably the best
>> behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
>> filters was disabled by default, due to potential denial-of-service
>> attacks being possible against nodes which serve bloom filters on
>> public connections.
>>
>> - PR 6993[10] (merged in November 2015) started reusing the `fRelay`
>> field for the new `-blocksonly` mode. If Bitcoin Core is started with
>> `-blocksonly` configured, then it includes `fRelay=false` in all of
>> the `version` messages it sends. In PR 15759[11] (merged in September
>> 2019), this usage of `fRelay` to permanently disable tx relay was
>> extended for use by the new block-relay only connection type.
>>
>> The net effect is that `fRelay` is already being used to indicate that
>> transactions should not be relayed over a connection. In the motivation
>> for your BIP, you write:
>>
>> > The low-bandwidth / minimal-resource nature of these connections is
>> > currently known only by the initiator of the connection; this is
>> > because the transaction relay field in the version message is not a
>> > permanent setting for the lifetime of the connection. Consequently, a
>> > node receiving an inbound connection with transaction relay disabled
>> > cannot distinguish between a peer that will never enable transaction
>> > relay (as described in BIP 37) and one that will...
>>
>> However, as AJ points out in his response [12], the Bitcoin Core node
>> _does_ know whether transaction relay can be supported as soon as the
>> `version` message is received:
>>
>> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
>> > message (either explicitly or by not setting fRelay), or you enable it
>> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a
>> > disconnect if bloom filters aren't supported. Bloom filter support is
>> > (optionally?) indicated via a service bit (BIP 111), so you could
>> > assume you know whether they're supported as soon as you receive the
>> > VERSION line.
>>
>> i.e. if Bitcoin Core node is running under normal configuration with
>> bloom filters disabled for public connections (which is both the default
>> setting and highly recommended due to DoS concerns), then as soon as it
>> receives a `version` message with `fRelay=false`, it can be sure that
>> there will never be any transaction relay with that peer. If the peer
>> later tries to enable transaction relay by sending a `filterload`
>> message, then the node will disconnect that peer immediately.
>>
>> In summary, we can continue using the `fRelay` field to indicate that
>> no transaction relay can happen for the entire lifetime of the
>> connection. Bitcoin Core can postpone allocating resources for
>> transaction relay data structures until after the version message has
>> been received to minimize resource usage for incoming block-relay-only
>> connections. A rough implementation is here[13]. Obviously, a node that
>> has been configured to serve bloom filters on public connections would
>> not be able to take advantage of this and accept additional incoming
>> block-relay-only peers, but I think that's fine - we already discourage
>> that configuration.
>>
>> I think a good counter-argument against simply using `fRelay` for this
>> purpose is that we shouldn't reuse a protocol feature designed for one
>> function to achieve a totally different aim. However, we know that nodes
>> on the network have been using `fRelay` to disable transaction relay
>> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
>> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>> later (when block-relay-only connections were introduced), so using
>> `fRelay` to disable transaction relay is now de facto part of the p2p
>> protocol.
>>
>> # Preventing addr black holes
>>
>> Addresses of potential peers are gossiped around the p2p network using
>> `addr` messages. When a Bitcoin Core node learns of a new `addr` record,
>> it will relay that record to one or two of its peers, chosen at
>> random[14]. The idea is that eventually the `addr` record will reach
>> most of the nodes on the network.
>>
>> If there are too many nodes on the network that receive `addr` records
>> and do not relay those records on to their peers (termed _addr black
>> hole_ nodes), then propagation of those `addr` records suffers -- any
>> individual `addr` record is unlikely to reach a large proportion of
>> nodes on the network.
>>
>> Since a motivation for block-relay-only connections is to protect
>> against eclipse attacks and thwart network topology analysis, Bitcoin
>> Core will not relay `addr` records on those connections, and will ignore
>> any `addr` record received over those connections. Therefore, increasing
>> the number of block-relay-only connections without changing the `addr`
>> gossip logic is likely to increase the prevalence of addr black holes,
>> and negatively impact addr propagation. This is why BIP 338 includes:
>>
>> > It is RECOMMENDED that a node that has sent or received a disabletx
>> > message to/from a peer not send any of these messages to the peer:
>> >
>> > - addr/getaddr
>> > - addrv2 (BIP 155)
>>
>> I think a better approach would be for Bitcoin Core to only relay addr
>> records to an inbound peer if it has previously received an `addr` or
>> `addrv2` message from that peer, since that indicates definitively that
>> the peer actively gossips `addr` records. This approach was first
>> suggested by AJ in the original block-relay-only PR[15].
>>
>> An advantage of this approach is that it will improve addr propagation
>> immediately and without any change to the P2P protocol, and will prevent
>> sending `addr` records to all addr black holes (such as light clients),
>> not just incoming block-relay-only connections.
>>
>> # Conclusion
>>
>> We can increase the permitted number of inbound block-relay-only peers
>> while minimizing resource requirement _and_ improving addr record
>> propagation, without any changes to the p2p protocol required.
>>
>> I propose that for Bitcoin Core version 22.0:
>>
>> - only initialize the transaction relay data structures after the
>> `version` message is received, and only if fRelay=true and
>> `NODE_BLOOM` is not offered on this connection.
>> - only initialize the addr data structures for inbound connections when
>> an `addr`, `addrv2` or `getaddr` message is received on the
>> connection, and only consider a connection for addr relay if its addr
>> data structures are initialized.
>> - update the inbound eviction logic to protect more inbound peers which
>> do not have transaction relay data structures.
>>
>> Then, in version 23.0:
>>
>> - modestly increase the number of outbound block-relay-only connections.
>>
>> John
>>
>> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
>> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
>> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
>> [4] https://github.com/bitcoin/bitcoin/pull/1795
>> [5] https://github.com/bitcoin/bitcoin/pull/2763
>> [6]
>> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
>> [7] https://github.com/bitcoin/bitcoin/pull/6579
>> [8] https://github.com/bitcoin/bitcoin/pull/7708
>> [9] https://github.com/bitcoin/bitcoin/pull/16152
>> [10] https://github.com/bitcoin/bitcoin/pull/6993
>> [11] https://github.com/bitcoin/bitcoin/pull/15759
>> [12]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
>> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
>> [14]
>> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
>> [15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>>
>> > Hi,
>> >
>> > I'm proposing the addition of a new, optional p2p message to allow
>> peers to communicate that they do not want to send or receive (loose)
>> transactions for the lifetime of a connection.
>> >
>> > The goal of this message is to help facilitate connections on the
>> network over which only block-related data (blocks/headers/compact
>> blocks/etc) are relayed, to create low-resource connections that help
>> protect against partition attacks on the network. In particular, by adding
>> a network message that communicates that transactions will not be relayed
>> for the life of the connection, we ease the implementation of software that
>> could have increased inbound connection limits for such peers, which in
>> turn will make it easier to add additional persistent block-relay-only
>> connections on the network -- strengthening network security for little
>> additional bandwidth.
>> >
>> > Software has been deployed for over a year now which makes such
>> connections, using the BIP37/BIP60 "fRelay" field in the version message to
>> signal that transactions should not be sent initially. However, BIP37
>> allows for transaction relay to be enabled later in the connection's
>> lifetime, complicating software that would try to distinguish inbound peers
>> that will never relay transactions from those that might.
>> >
>> > This proposal would add a single new p2p message, "disabletx", which
>> (if used at all) must be sent between version and verack. I propose that
>> this message is valid for peers advertising protocol version 70017 or
>> higher. Software is free to implement this BIP or ignore this message and
>> remain compatible with software that does implement it.
>> >
>> > Full text of the proposed BIP is below.
>> >
>> > Thanks,
>> > Suhas
>> >
>> > ---------------------------------------------------
>> >
>> > <pre>
>> > BIP: XXX
>> > Layer: Peer Services
>> > Title: Disable transaction relay message
>> > Author: Suhas Daftuar <sdaftuar at chaincode.com>
>> > Comments-Summary: No comments yet.
>> > Comments-URI:
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2020-09-03
>> > License: BSD-2-Clause
>> > </pre>
>> >
>> > ==Abstract==
>> >
>> > This BIP describes a change to the p2p protocol to allow a node to tell
>> a peer
>> > that a connection will not be used for transaction relay, to support
>> > block-relay-only connections that are currently in use on the network.
>> >
>> > ==Motivation==
>> >
>> > For nearly the past year, software has been deployed[1] which initiates
>> > connections on the Bitcoin network and sets the transaction relay field
>> > (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
>> > transaction relay from occurring on the connection. Additionally, addr
>> messages
>> > received from the peer are ignored by this software.
>> >
>> > The purpose of these connections is two-fold: by making additional
>> > low-bandwidth connections on which blocks can propagate, the robustness
>> of a
>> > node to network partitioning attacks is strengthened. Additionally, by
>> not
>> > relaying transactions and ignoring received addresses, the ability of an
>> > adversary to learn the complete network graph (or a subgraph) is
>> reduced[2],
>> > which in turn increases the cost or difficulty to an attacker seeking
>> to carry
>> > out a network partitioning attack (when compared with having such
>> knowledge).
>> >
>> > The low-bandwidth / minimal-resource nature of these connections is
>> currently
>> > known only by the initiator of the connection; this is because the
>> transaction
>> > relay field in the version message is not a permanent setting for the
>> lifetime
>> > of the connection. Consequently, a node receiving an inbound
>> connection with
>> > transaction relay disabled cannot distinguish between a peer that will
>> never
>> > enable transaction relay (as described in BIP 37) and one that will.
>> Moreover,
>> > the node also cannot determine that the incoming connection will ignore
>> relayed
>> > addresses; with that knowledge a node would likely choose other peers to
>> > receive announced addresses instead.
>> >
>> > This proposal adds a new, optional message that a node can send a peer
>> when
>> > initiating a connection to that peer, to indicate that connection
>> should not be
>> > used for transaction-relay for the connection's lifetime. In addition,
>> without
>> > a current mechanism to negotiate whether addresses should be relayed on
>> a
>> > connection, this BIP suggests that address messages not be sent on
>> links where
>> > tx-relay has been disabled.
>> >
>> > ==Specification==
>> >
>> > # A new disabletx message is added, which is defined as an empty
>> message where pchCommand == "disabletx".
>> > # The protocol version of nodes implementing this BIP must be set to
>> 70017 or higher.
>> > # If a node sets the transaction relay field in the version message to
>> a peer to false, then the disabletx message MAY also be sent in response to
>> a version message from that peer if the peer's protocol version is >=
>> 70017. If sent, the disabletx message MUST be sent prior to sending a
>> verack.
>> > # A node that has sent or received a disabletx message to/from a peer
>> MUST NOT send any of these messages to the peer:
>> > ## inv messages for transactions
>> > ## getdata messages for transactions
>> > ## getdata messages for merkleblock (BIP 37)
>> > ## filteradd/filterload/filterclear (BIP 37)
>> > ## mempool (BIP 35)
>> > # It is RECOMMENDED that a node that has sent or received a disabletx
>> message to/from a peer not send any of these messages to the peer:
>> > ## addr/getaddr
>> > ## addrv2 (BIP 155)
>> > # The behavior regarding sending or processing other message types is
>> not specified by this BIP.
>> > # Nodes MAY decide to not remain connected to peers that send this
>> message (for example, if trying to find a peer that will relay
>> transactions).
>> >
>> > ==Compatibility==
>> >
>> > Nodes with protocol version >= 70017 that do not implement this BIP,
>> and nodes
>> > with protocol version < 70017, will continue to remain compatible with
>> > implementing software: transactions would not be relayed to peers
>> sending the
>> > disabletx message (provided that BIP 37 or BIP 60 has been
>> implemented), and while
>> > periodic address relay may still take place, software implementing this
>> BIP
>> > should not be disconnecting such peers solely for that reason.
>> >
>> > Disabling address relay is suggested but not required by this BIP, to
>> allow for
>> > future protocol extensions that might specify more carefully how
>> address relay
>> > is to be negotiated. This BIP's recommendations for software to not
>> relay
>> > addresses is intended to be interpreted as guidance in the absence of
>> any such
>> > future protocol extension, to accommodate existing software behavior.
>> >
>> > Note that all messages specified in BIP 152, including blocktxn and
>> > getblocktxn, are permitted between peers that have sent/received a
>> disabletx
>> > message, subject to the feature negotiation of BIP 152.
>> >
>> > ==Implementation==
>> >
>> > TBD
>> >
>> > ==References==
>> >
>> > # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759
>> implemented this functionality] since version 0.19.0.1, released in
>> November 2019.
>> > # For example, see
>> https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and
>> https://arxiv.org/pdf/1812.00942.pdf.
>> >
>> > ==Copyright==
>> >
>> > This BIP is licensed under the 2-clause BSD license.
>>
>> On Wed, Jan 6, 2021 at 4:35 PM Suhas Daftuar via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi,
>>>
>>> I'm proposing the addition of a new, optional p2p message to allow peers
>>> to communicate that they do not want to send or receive (loose)
>>> transactions for the lifetime of a connection.
>>>
>>> The goal of this message is to help facilitate connections on the
>>> network over which only block-related data (blocks/headers/compact
>>> blocks/etc) are relayed, to create low-resource connections that help
>>> protect against partition attacks on the network. In particular, by adding
>>> a network message that communicates that transactions will not be relayed
>>> for the life of the connection, we ease the implementation of software that
>>> could have increased inbound connection limits for such peers, which in
>>> turn will make it easier to add additional persistent block-relay-only
>>> connections on the network -- strengthening network security for little
>>> additional bandwidth.
>>>
>>> Software has been deployed for over a year now which makes such
>>> connections, using the BIP37/BIP60 "fRelay" field in the version message to
>>> signal that transactions should not be sent initially. However, BIP37
>>> allows for transaction relay to be enabled later in the connection's
>>> lifetime, complicating software that would try to distinguish inbound peers
>>> that will never relay transactions from those that might.
>>>
>>> This proposal would add a single new p2p message, "disabletx", which (if
>>> used at all) must be sent between version and verack. I propose that this
>>> message is valid for peers advertising protocol version 70017 or higher.
>>> Software is free to implement this BIP or ignore this message and remain
>>> compatible with software that does implement it.
>>>
>>> Full text of the proposed BIP is below.
>>>
>>> Thanks,
>>> Suhas
>>>
>>> ---------------------------------------------------
>>>
>>> <pre>
>>> BIP: XXX
>>> Layer: Peer Services
>>> Title: Disable transaction relay message
>>> Author: Suhas Daftuar <sdaftuar at chaincode.com>
>>> Comments-Summary: No comments yet.
>>> Comments-URI:
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 2020-09-03
>>> License: BSD-2-Clause
>>> </pre>
>>>
>>> ==Abstract==
>>>
>>> This BIP describes a change to the p2p protocol to allow a node to tell a peer
>>> that a connection will not be used for transaction relay, to support
>>> block-relay-only connections that are currently in use on the network.
>>>
>>> ==Motivation==
>>>
>>> For nearly the past year, software has been deployed[1] which initiates
>>> connections on the Bitcoin network and sets the transaction relay field
>>> (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
>>> transaction relay from occurring on the connection. Additionally, addr messages
>>> received from the peer are ignored by this software.
>>>
>>> The purpose of these connections is two-fold: by making additional
>>> low-bandwidth connections on which blocks can propagate, the robustness of a
>>> node to network partitioning attacks is strengthened. Additionally, by not
>>> relaying transactions and ignoring received addresses, the ability of an
>>> adversary to learn the complete network graph (or a subgraph) is reduced[2],
>>> which in turn increases the cost or difficulty to an attacker seeking to carry
>>> out a network partitioning attack (when compared with having such knowledge).
>>>
>>> The low-bandwidth / minimal-resource nature of these connections is currently
>>> known only by the initiator of the connection; this is because the transaction
>>> relay field in the version message is not a permanent setting for the lifetime
>>> of the connection. Consequently, a node receiving an inbound connection with
>>> transaction relay disabled cannot distinguish between a peer that will never
>>> enable transaction relay (as described in BIP 37) and one that will. Moreover,
>>> the node also cannot determine that the incoming connection will ignore relayed
>>> addresses; with that knowledge a node would likely choose other peers to
>>> receive announced addresses instead.
>>>
>>> This proposal adds a new, optional message that a node can send a peer when
>>> initiating a connection to that peer, to indicate that connection should not be
>>> used for transaction-relay for the connection's lifetime. In addition, without
>>> a current mechanism to negotiate whether addresses should be relayed on a
>>> connection, this BIP suggests that address messages not be sent on links where
>>> tx-relay has been disabled.
>>>
>>> ==Specification==
>>>
>>> # A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
>>> # The protocol version of nodes implementing this BIP must be set to 70017 or higher.
>>> # If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
>>> # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
>>> ## inv messages for transactions
>>> ## getdata messages for transactions
>>> ## getdata messages for merkleblock (BIP 37)
>>> ## filteradd/filterload/filterclear (BIP 37)
>>> ## mempool (BIP 35)
>>> # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
>>> ## addr/getaddr
>>> ## addrv2 (BIP 155)
>>> # The behavior regarding sending or processing other message types is not specified by this BIP.
>>> # Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions).
>>>
>>> ==Compatibility==
>>>
>>> Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
>>> with protocol version < 70017, will continue to remain compatible with
>>> implementing software: transactions would not be relayed to peers sending the
>>> disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
>>> periodic address relay may still take place, software implementing this BIP
>>> should not be disconnecting such peers solely for that reason.
>>>
>>> Disabling address relay is suggested but not required by this BIP, to allow for
>>> future protocol extensions that might specify more carefully how address relay
>>> is to be negotiated. This BIP's recommendations for software to not relay
>>> addresses is intended to be interpreted as guidance in the absence of any such
>>> future protocol extension, to accommodate existing software behavior.
>>>
>>> Note that all messages specified in BIP 152, including blocktxn and
>>> getblocktxn, are permitted between peers that have sent/received a disabletx
>>> message, subject to the feature negotiation of BIP 152.
>>>
>>> ==Implementation==
>>>
>>> TBD
>>>
>>> ==References==
>>>
>>> # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
>>> # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
>>>
>>> ==Copyright==
>>>
>>> This BIP is licensed under the 2-clause BSD license.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/ff7e2b23/attachment-0001.html>;

📅 Original date posted:2021-03-01 📝 Original message:Hi ...

2023-06-07T18:29:48Z

In reply to nevent1q…4pa5
_________________________

📅 Original date posted:2021-03-01
📝 Original message:Hi Suhas,

Thank you for this proposal. I agree with your aims, but I think a new
P2P message isn't necessary to achieve them.

# Motivation

There are two distinct (but interacting) motivations:

1. Allow a node to accept more incoming connections which will only be
used for block propagation (no transaction relay or addr gossip),
while minimizing resource requirements.

2. Prevent `addr` gossip messages from being sent to peers which will
'black hole' those addrs (i.e. not relay them further).

These motivations interact because if we simply increase the number of
block-relay-only connections that nodes make without making any
allowance for the fact those connections won't gossip addr records, then
we'll increase the number of addr black holes and worsen addr gossip.

# Using fRelay=false to signal no transaction relay.

`fRelay` is an optional field in the `version` message. There are three
BIPs concerned with `fRelay`:

- BIP 37[1] introduced the `fRelay` field to indicate to the recipient
that they must not relay transactions over the connection until a
`filteradd` message has been received.

- BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
how widely this BIP has been adopted by implementations.

- BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
bloom filters are served by this node. According to this BIP, "If a
node does not support bloom filters but receives a "filterload",
"filteradd", or "filterclear" message from a peer the node should
disconnect that peer immediately."

Within Bitcoin Core:

- PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
filters.

- Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
include the `fRelay` flag in `version` messages that it sends. Bitcoin
Core will tolerate the `fRelay` field being present or absent in any
`version` message that it receives[6].

- PR 6579[7] (merged in August 2015) implemented BIP 111. From that
point on, a Bitcoin Core node would disconnect peers that sent it
`filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
was extended to disconnect any peer that sends a `filter*` message,
regardless of its version (in general, a 'polite disconnect' for any
peer that requests an unsupported service is probably the best
behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
filters was disabled by default, due to potential denial-of-service
attacks being possible against nodes which serve bloom filters on
public connections.

- PR 6993[10] (merged in November 2015) started reusing the `fRelay`
field for the new `-blocksonly` mode. If Bitcoin Core is started with
`-blocksonly` configured, then it includes `fRelay=false` in all of
the `version` messages it sends. In PR 15759[11] (merged in September
2019), this usage of `fRelay` to permanently disable tx relay was
extended for use by the new block-relay only connection type.

The net effect is that `fRelay` is already being used to indicate that
transactions should not be relayed over a connection. In the motivation
for your BIP, you write:

> The low-bandwidth / minimal-resource nature of these connections is
> currently known only by the initiator of the connection; this is
> because the transaction relay field in the version message is not a
> permanent setting for the lifetime of the connection. Consequently, a
> node receiving an inbound connection with transaction relay disabled
> cannot distinguish between a peer that will never enable transaction
> relay (as described in BIP 37) and one that will...

However, as AJ points out in his response [12], the Bitcoin Core node
_does_ know whether transaction relay can be supported as soon as the
`version` message is received:

> [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
> message (either explicitly or by not setting fRelay), or you enable it
> later with FILTERLOAD or FILTERCLEAR, both of which will cause a
> disconnect if bloom filters aren't supported. Bloom filter support is
> (optionally?) indicated via a service bit (BIP 111), so you could
> assume you know whether they're supported as soon as you receive the
> VERSION line.

i.e. if Bitcoin Core node is running under normal configuration with
bloom filters disabled for public connections (which is both the default
setting and highly recommended due to DoS concerns), then as soon as it
receives a `version` message with `fRelay=false`, it can be sure that
there will never be any transaction relay with that peer. If the peer
later tries to enable transaction relay by sending a `filterload`
message, then the node will disconnect that peer immediately.

In summary, we can continue using the `fRelay` field to indicate that
no transaction relay can happen for the entire lifetime of the
connection. Bitcoin Core can postpone allocating resources for
transaction relay data structures until after the version message has
been received to minimize resource usage for incoming block-relay-only
connections. A rough implementation is here[13]. Obviously, a node that
has been configured to serve bloom filters on public connections would
not be able to take advantage of this and accept additional incoming
block-relay-only peers, but I think that's fine - we already discourage
that configuration.

I think a good counter-argument against simply using `fRelay` for this
purpose is that we shouldn't reuse a protocol feature designed for one
function to achieve a totally different aim. However, we know that nodes
on the network have been using `fRelay` to disable transaction relay
since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
later (when block-relay-only connections were introduced), so using
`fRelay` to disable transaction relay is now de facto part of the p2p
protocol.

# Preventing addr black holes

Addresses of potential peers are gossiped around the p2p network using
`addr` messages. When a Bitcoin Core node learns of a new `addr` record,
it will relay that record to one or two of its peers, chosen at
random[14]. The idea is that eventually the `addr` record will reach
most of the nodes on the network.

If there are too many nodes on the network that receive `addr` records
and do not relay those records on to their peers (termed _addr black
hole_ nodes), then propagation of those `addr` records suffers -- any
individual `addr` record is unlikely to reach a large proportion of
nodes on the network.

Since a motivation for block-relay-only connections is to protect
against eclipse attacks and thwart network topology analysis, Bitcoin
Core will not relay `addr` records on those connections, and will ignore
any `addr` record received over those connections. Therefore, increasing
the number of block-relay-only connections without changing the `addr`
gossip logic is likely to increase the prevalence of addr black holes,
and negatively impact addr propagation. This is why BIP 338 includes:

> It is RECOMMENDED that a node that has sent or received a disabletx
> message to/from a peer not send any of these messages to the peer:
>
> - addr/getaddr
> - addrv2 (BIP 155)

I think a better approach would be for Bitcoin Core to only relay addr
records to an inbound peer if it has previously received an `addr` or
`addrv2` message from that peer, since that indicates definitively that
the peer actively gossips `addr` records. This approach was first
suggested by AJ in the original block-relay-only PR[15].

An advantage of this approach is that it will improve addr propagation
immediately and without any change to the P2P protocol, and will prevent
sending `addr` records to all addr black holes (such as light clients),
not just incoming block-relay-only connections.

# Conclusion

We can increase the permitted number of inbound block-relay-only peers
while minimizing resource requirement _and_ improving addr record
propagation, without any changes to the p2p protocol required.

I propose that for Bitcoin Core version 22.0:

- only initialize the transaction relay data structures after the
`version` message is received, and only if fRelay=true and
`NODE_BLOOM` is not offered on this connection.
- only initialize the addr data structures for inbound connections when
an `addr`, `addrv2` or `getaddr` message is received on the
connection, and only consider a connection for addr relay if its addr
data structures are initialized.
- update the inbound eviction logic to protect more inbound peers which
do not have transaction relay data structures.

Then, in version 23.0:

- modestly increase the number of outbound block-relay-only connections.

John

[1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
[2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
[4] https://github.com/bitcoin/bitcoin/pull/1795
[5] https://github.com/bitcoin/bitcoin/pull/2763
[6]
https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
[7] https://github.com/bitcoin/bitcoin/pull/6579
[8] https://github.com/bitcoin/bitcoin/pull/7708
[9] https://github.com/bitcoin/bitcoin/pull/16152
[10] https://github.com/bitcoin/bitcoin/pull/6993
[11] https://github.com/bitcoin/bitcoin/pull/15759
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html
[13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
[14]
https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
[15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757

> Hi,
>
> I'm proposing the addition of a new, optional p2p message to allow peers
to communicate that they do not want to send or receive (loose)
transactions for the lifetime of a connection.
>
> The goal of this message is to help facilitate connections on the network
over which only block-related data (blocks/headers/compact blocks/etc) are
relayed, to create low-resource connections that help protect against
partition attacks on the network. In particular, by adding a network
message that communicates that transactions will not be relayed for the
life of the connection, we ease the implementation of software that could
have increased inbound connection limits for such peers, which in turn will
make it easier to add additional persistent block-relay-only connections on
the network -- strengthening network security for little additional
bandwidth.
>
> Software has been deployed for over a year now which makes such
connections, using the BIP37/BIP60 "fRelay" field in the version message to
signal that transactions should not be sent initially. However, BIP37
allows for transaction relay to be enabled later in the connection's
lifetime, complicating software that would try to distinguish inbound peers
that will never relay transactions from those that might.
>
> This proposal would add a single new p2p message, "disabletx", which (if
used at all) must be sent between version and verack. I propose that this
message is valid for peers advertising protocol version 70017 or higher.
Software is free to implement this BIP or ignore this message and remain
compatible with software that does implement it.
>
> Full text of the proposed BIP is below.
>
> Thanks,
> Suhas
>
> ---------------------------------------------------
>
> <pre>
> BIP: XXX
> Layer: Peer Services
> Title: Disable transaction relay message
> Author: Suhas Daftuar <sdaftuar at chaincode.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2020-09-03
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP describes a change to the p2p protocol to allow a node to tell a
peer
> that a connection will not be used for transaction relay, to support
> block-relay-only connections that are currently in use on the network.
>
> ==Motivation==
>
> For nearly the past year, software has been deployed[1] which initiates
> connections on the Bitcoin network and sets the transaction relay field
> (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
> transaction relay from occurring on the connection. Additionally, addr
messages
> received from the peer are ignored by this software.
>
> The purpose of these connections is two-fold: by making additional
> low-bandwidth connections on which blocks can propagate, the robustness
of a
> node to network partitioning attacks is strengthened. Additionally, by
not
> relaying transactions and ignoring received addresses, the ability of an
> adversary to learn the complete network graph (or a subgraph) is
reduced[2],
> which in turn increases the cost or difficulty to an attacker seeking to
carry
> out a network partitioning attack (when compared with having such
knowledge).
>
> The low-bandwidth / minimal-resource nature of these connections is
currently
> known only by the initiator of the connection; this is because the
transaction
> relay field in the version message is not a permanent setting for the
lifetime
> of the connection. Consequently, a node receiving an inbound connection
with
> transaction relay disabled cannot distinguish between a peer that will
never
> enable transaction relay (as described in BIP 37) and one that will.
Moreover,
> the node also cannot determine that the incoming connection will ignore
relayed
> addresses; with that knowledge a node would likely choose other peers to
> receive announced addresses instead.
>
> This proposal adds a new, optional message that a node can send a peer
when
> initiating a connection to that peer, to indicate that connection should
not be
> used for transaction-relay for the connection's lifetime. In addition,
without
> a current mechanism to negotiate whether addresses should be relayed on a
> connection, this BIP suggests that address messages not be sent on links
where
> tx-relay has been disabled.
>
> ==Specification==
>
> # A new disabletx message is added, which is defined as an empty message
where pchCommand == "disabletx".
> # The protocol version of nodes implementing this BIP must be set to
70017 or higher.
> # If a node sets the transaction relay field in the version message to a
peer to false, then the disabletx message MAY also be sent in response to a
version message from that peer if the peer's protocol version is >= 70017.
If sent, the disabletx message MUST be sent prior to sending a verack.
> # A node that has sent or received a disabletx message to/from a peer
MUST NOT send any of these messages to the peer:
> ## inv messages for transactions
> ## getdata messages for transactions
> ## getdata messages for merkleblock (BIP 37)
> ## filteradd/filterload/filterclear (BIP 37)
> ## mempool (BIP 35)
> # It is RECOMMENDED that a node that has sent or received a disabletx
message to/from a peer not send any of these messages to the peer:
> ## addr/getaddr
> ## addrv2 (BIP 155)
> # The behavior regarding sending or processing other message types is not
specified by this BIP.
> # Nodes MAY decide to not remain connected to peers that send this
message (for example, if trying to find a peer that will relay
transactions).
>
> ==Compatibility==
>
> Nodes with protocol version >= 70017 that do not implement this BIP, and
nodes
> with protocol version < 70017, will continue to remain compatible with
> implementing software: transactions would not be relayed to peers sending
the
> disabletx message (provided that BIP 37 or BIP 60 has been implemented),
and while
> periodic address relay may still take place, software implementing this
BIP
> should not be disconnecting such peers solely for that reason.
>
> Disabling address relay is suggested but not required by this BIP, to
allow for
> future protocol extensions that might specify more carefully how address
relay
> is to be negotiated. This BIP's recommendations for software to not relay
> addresses is intended to be interpreted as guidance in the absence of any
such
> future protocol extension, to accommodate existing software behavior.
>
> Note that all messages specified in BIP 152, including blocktxn and
> getblocktxn, are permitted between peers that have sent/received a
disabletx
> message, subject to the feature negotiation of BIP 152.
>
> ==Implementation==
>
> TBD
>
> ==References==
>
> # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759
implemented this functionality] since version 0.19.0.1, released in
November 2019.
> # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf
and https://arxiv.org/pdf/1812.00942.pdf.
>
> ==Copyright==
>
> This BIP is licensed under the 2-clause BSD license.

On Wed, Jan 6, 2021 at 4:35 PM Suhas Daftuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm proposing the addition of a new, optional p2p message to allow peers
> to communicate that they do not want to send or receive (loose)
> transactions for the lifetime of a connection.
>
> The goal of this message is to help facilitate connections on the network
> over which only block-related data (blocks/headers/compact blocks/etc) are
> relayed, to create low-resource connections that help protect against
> partition attacks on the network. In particular, by adding a network
> message that communicates that transactions will not be relayed for the
> life of the connection, we ease the implementation of software that could
> have increased inbound connection limits for such peers, which in turn will
> make it easier to add additional persistent block-relay-only connections on
> the network -- strengthening network security for little additional
> bandwidth.
>
> Software has been deployed for over a year now which makes such
> connections, using the BIP37/BIP60 "fRelay" field in the version message to
> signal that transactions should not be sent initially. However, BIP37
> allows for transaction relay to be enabled later in the connection's
> lifetime, complicating software that would try to distinguish inbound peers
> that will never relay transactions from those that might.
>
> This proposal would add a single new p2p message, "disabletx", which (if
> used at all) must be sent between version and verack. I propose that this
> message is valid for peers advertising protocol version 70017 or higher.
> Software is free to implement this BIP or ignore this message and remain
> compatible with software that does implement it.
>
> Full text of the proposed BIP is below.
>
> Thanks,
> Suhas
>
> ---------------------------------------------------
>
> <pre>
> BIP: XXX
> Layer: Peer Services
> Title: Disable transaction relay message
> Author: Suhas Daftuar <sdaftuar at chaincode.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2020-09-03
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP describes a change to the p2p protocol to allow a node to tell a peer
> that a connection will not be used for transaction relay, to support
> block-relay-only connections that are currently in use on the network.
>
> ==Motivation==
>
> For nearly the past year, software has been deployed[1] which initiates
> connections on the Bitcoin network and sets the transaction relay field
> (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
> transaction relay from occurring on the connection. Additionally, addr messages
> received from the peer are ignored by this software.
>
> The purpose of these connections is two-fold: by making additional
> low-bandwidth connections on which blocks can propagate, the robustness of a
> node to network partitioning attacks is strengthened. Additionally, by not
> relaying transactions and ignoring received addresses, the ability of an
> adversary to learn the complete network graph (or a subgraph) is reduced[2],
> which in turn increases the cost or difficulty to an attacker seeking to carry
> out a network partitioning attack (when compared with having such knowledge).
>
> The low-bandwidth / minimal-resource nature of these connections is currently
> known only by the initiator of the connection; this is because the transaction
> relay field in the version message is not a permanent setting for the lifetime
> of the connection. Consequently, a node receiving an inbound connection with
> transaction relay disabled cannot distinguish between a peer that will never
> enable transaction relay (as described in BIP 37) and one that will. Moreover,
> the node also cannot determine that the incoming connection will ignore relayed
> addresses; with that knowledge a node would likely choose other peers to
> receive announced addresses instead.
>
> This proposal adds a new, optional message that a node can send a peer when
> initiating a connection to that peer, to indicate that connection should not be
> used for transaction-relay for the connection's lifetime. In addition, without
> a current mechanism to negotiate whether addresses should be relayed on a
> connection, this BIP suggests that address messages not be sent on links where
> tx-relay has been disabled.
>
> ==Specification==
>
> # A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
> # The protocol version of nodes implementing this BIP must be set to 70017 or higher.
> # If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
> # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
> ## inv messages for transactions
> ## getdata messages for transactions
> ## getdata messages for merkleblock (BIP 37)
> ## filteradd/filterload/filterclear (BIP 37)
> ## mempool (BIP 35)
> # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
> ## addr/getaddr
> ## addrv2 (BIP 155)
> # The behavior regarding sending or processing other message types is not specified by this BIP.
> # Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions).
>
> ==Compatibility==
>
> Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
> with protocol version < 70017, will continue to remain compatible with
> implementing software: transactions would not be relayed to peers sending the
> disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
> periodic address relay may still take place, software implementing this BIP
> should not be disconnecting such peers solely for that reason.
>
> Disabling address relay is suggested but not required by this BIP, to allow for
> future protocol extensions that might specify more carefully how address relay
> is to be negotiated. This BIP's recommendations for software to not relay
> addresses is intended to be interpreted as guidance in the absence of any such
> future protocol extension, to accommodate existing software behavior.
>
> Note that all messages specified in BIP 152, including blocktxn and
> getblocktxn, are permitted between peers that have sent/received a disabletx
> message, subject to the feature negotiation of BIP 152.
>
> ==Implementation==
>
> TBD
>
> ==References==
>
> # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
> # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
>
> ==Copyright==
>
> This BIP is licensed under the 2-clause BSD license.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/d31013b0/attachment-0001.html>;

📅 Original date posted:2020-12-10 📝 Original message:Hi ...

2023-06-07T18:27:48Z

In reply to nevent1q…kw42
_________________________

📅 Original date posted:2020-12-10
📝 Original message:Hi folks,

BIP 155 was proposed[1] in Feb 2019 by Wladimir van der Laan as a way of
gossipping longer node addresses over the Bitcoin P2P network, primarily
to support torv3 and other networks.

In the time since that initial mailing list post, several changes have
been made to the proposal. Discussion has been held on the BIPs repo[2],
and (for implementation issues) the Bitcoin Core repo[3].

This email summarizes the changes. Readers should refer to BIP 155[4]
for the full specification.

### Specification changes

1. The `time` field in the `addrv2` message is now stored as a fixed
length uint32 instead of a variable-length compact size.

2. The `addr` field may be up to a maximum of 512 bytes (4096 bits)
instead of 32 bytes (256 bits) for compatibility with future address
formats.

3. Clients now SHOULD gossip addresses for known networks (even if they
can't connect to those networks). They SHOULD NOT gossip addresses
for unknown networks. They SHOULD also ignore addresses for known
networks that are different from the address length for that network
specified in BIP 155.

4. New network IDs MUST be reserved in a BIP document.

5. Support for `addrv2` is not dependent on a p2p protocol version.
A new message type `sendaddrv2` is introduced to signal support
for addrv2. To signal support for addrv2, this message MUST be sent
after the initial version message is sent and before the verack
message is sent.

### Implementation detail

During testing of the Bitcoin Core implementation, it was found that
another Bitcoin implementation would disconnect from peers on receipt of
an unknown message[5]. I believe that to be an incorrect interpretation
of the Bitcoin p2p protocol. The original v0.1 Satoshi client (and all
Bitcoin Core versions derived from it) have always explicitly ignored
unknown message types as a mechanism to extend the p2p protocol[6]. This
property allows p2p implementions to permissionlessly deploy opt-in
extensions to the protocol.

As a pragmatic step to prevent those implementations from being
disconnected from v0.21 Bitcoin Core nodes, this initial version will
_only_ send sendaddrv2 messages to peers on p2p protocol version 70016
and higher. This behaviour may be reverted in future, at which point
Bitcoin Core would send sendaddrv2 messages to all peers during the
version/verack handshake.

Thanks to everyone who has contributed to the addrv2
spec/implementation.

John

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016687.html
[2] https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&type=Issues
[3] https://github.com/bitcoin/bitcoin/pull/20564
[4] https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
[5] https://github.com/btcsuite/btcd/issues/1661
[6] https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/main.cpp#L2035-L2039
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201210/b6445a1c/attachment.html>;

📅 Original date posted:2020-08-21 📝 Original ...

2023-06-07T18:26:21Z

In reply to nevent1q…3x59
_________________________

📅 Original date posted:2020-08-21
📝 Original message:Pieter,

Thanks for the illuminating write-up. There seem to be two questions here,
one technical and one process:

1. Is changing to even tie-breaker for R the correct choice technically? I
can't comment on the performance characteristics of using a square/even
tie-breaker and I'll assume the numbers you give are correct. An enormous
benefit that you don't mention (but Nadav and Lloyd do) is that
standardizing to a single tie-breaker for R points and public keys is much
simpler to explain and much easier for implementers and developers to
understand. I've explained the taproot proposals to many people through the
optech workshops and bitdevs meetups, and people are invariably confused by
which type of tie-breaker to use where. Absent a large performance benefit
for having different tiebreakers, I think this alone is good reason to
standardize to one tie-breaker.

2. Is it too late in the process to change? No. We're building things to
last years, hopefully decades. We should measure a hundred times and cut
once. A benefit of the long lead time of taproot is that as we get more
information, we can improve the proposal. Let's do that here. Nadav and
Lloyd have both written alternative implementations of taproot and are
happy to make this change. Presumably if this was going to cause serious
pain for any other implementer/developer they would have raised objections
by now.

Summary: We should change the proposal and implementation to use even
tie-breakers everywhere.

John #notoquadraticresiduetiebreakers Newbery

On Wed, Aug 12, 2020 at 7:49 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello all,
>
> The current BIP340 draft[1] uses two different tiebreakers for conveying
> the Y coordinate of points: for the R point inside signatures squaredness
> is used, while for public keys evenness is used. Originally both used
> squaredness, but it was changed[2] for public keys after observing this
> results in additional complexity for compatibility with existing systems.
>
> The reason for choosing squaredness as tiebreaker was performance: in
> non-batch signature validation, the recomputed R point must be verified to
> have the correct sign, to guarantee consistency with batch validation.
> Whether the Y coordinate is square can be computed directly in Jacobian
> coordinates, while determining evenness requires a conversion to affine
> coordinates first.
>
> This argument of course relies on the assumption that determining whether
> the Y coordinate is square can be done more efficiently than a conversion
> to affine coordinates. It appears now that this assumption is incorrect,
> and the justification for picking the squaredness tiebreaking doesn't
> really exist. As it comes with other trade-offs (it slows down signing, and
> is a less conventional choice), it would seem that we should reconsider the
> option of having the R point use the evenness tiebreaker (like public keys).
>
> It is late in the process, but I feel I owe this explanation so that at
> least the possibility of changing can be discussed with all information. On
> the upside, this was discovered in the context of looking into a cool
> improvement to libsecp256k1[5], which makes things faster in general, but
> specifically benefits the evenness variant.
>
>
> # 1. What happened?
>
> Computing squaredness is done through the Jacobi symbol (same inventor,
> but unrelated to Jacobian coordinates). Computing evenness requires
> converting points to affine coordinates first, and that needs a modular
> inverse. The assumption that Jacobi symbols are faster to compute than
> inverses was based on:
>
> * A (possibly) mistaken belief about the theory: fast algorithms for both
> Jacobi symbols and inverses are internally based on variants of the same
> extended GCD algorithm[3]. Since an inverse needs to extract a full big
> integer out of the transition steps made in the extgcd algorithm, while the
> Jacobi symbol just extracts a single bit, it had seemed that any advances
> applicable to one would be applicable to the other, but inverses would
> always need additional work on top. It appears however that a class of
> extgcd algorithms exists (LSB based ones) that cannot be used for Jacobi
> calculations without losing efficiency. Recent developments[4] and a
> proposed implementation in libsecp256k1[5] by Peter Dettman show that using
> this, inverses in some cases can in fact be faster than Jacobi symbols.
>
> * A broken benchmark. This belief was incorrectly confirmed by a broken
> benchmark[6] in libsecp256k1 for the libgmp-based Jacobi symbol calculation
> and modular inverse. The benchmark was repeatedly testing the same constant
> input, which apparently was around 2.5x faster than the average speed. It
> is a variable-time algorithm, so a good variation of inputs matters. This
> mistake had me (and probably others) convinced for years that Jacobi
> symbols were amazingly fast, while in reality they were always very close
> in performance to inverses.
>
>
> # 2. What is the actual impact of picking evenness instead?
>
> It is hard to make very generic statements here, as BIP340 will hopefully
> be used for a long time, and hardware advancements and algorithmic
> improvements may change the balance. That said, performance on current
> hardware with optimized algorithms is the best approximation we have.
>
> The numbers below give the expected performance change from squareness to
> evenness, for single BIP340 validation, and for signing. Positive numbers
> mean evenness is faster. Batch validation is not impacted at all.
>
> In the short term, for block validation in Bitcoin Core, the numbers for
> master-nogmp are probably the most relevant (as Bitcoin Core uses
> libsecp256k1 without libgmp, to reduce consensus-critical dependencies).
> If/when [5] gets merged, safegcd-nogmp will be what matters. On a longer
> time scale, the gmp numbers may be more relevant, as the Jacobi
> implementation there is certainly closer to the state of the art.
>
> * i7-7820HQ: (verify) (sign)
> - master-nogmp: -0.3% +16.1%
> - safegcd-nogmp: +6.7% +17.1%
> - master-gmp: +0.6% +7.7%
> - safegcd-gmp: +1.6% +8.6%
>
> * Cortex-A53: (verify) (sign)
> - master-nogmp: -0.3% +15.7%
> - safegcd-nogmp: +7.5% +16.9%
> - master-gmp: +0.3% +4.1%
> - safegcd-gmp: 0.0% +3.5%
>
> * EPYC 7742: (verify) (sign)
> - master-nogmp: -0.3% +16.8%
> - safegcd-nogmp: +8.6% +18.4%
> - master-gmp: 0.0% +7.4%
> - safegcd-gmp: +2.3% +7.8%
>
> In well optimized cryptographic code speedups as large as a couple percent
> are difficult to come by, so we would usually consider changes of this
> magnitude relevant. Note however that while the percentages for signing
> speed are larger, they are not what is unexpected here. The choice for the
> square tiebreaker was intended to improve verification speed at the cost of
> signing speed. As it turns out that it doesn't actually benefit
> verification speed, this is a bad trade-off.
>
>
> # 3. How big a change is it
>
> * In the BIP:
> - Changing both invocations of `has_square_y` to `has_even_y`.
> - Changing the `lift_x_square_y` invocation to `lift_x_even_y`.
> - Applying the same change to the test vector generation code, and the
> resulting test vectors.
> * In the libsecp256k1:
> - An 8-line patch to the proposed BIP340 implementation[7]: see [8]
> * In Bitcoin Core:
> - Similarly small changes to the Python test reimplementation[9]
> * Duplicating these changes in other draft implementations that may
> already exist.
> * Review for all the above.
>
>
> # 4. Conclusion
>
> We discovered that the justification for using squaredness tiebreakers in
> BIP340 is based on a misunderstanding, and recent developments show that it
> may in fact be a somewhat worse choice than the alternative. It is a
> relatively simple change to address this, but that has be weighed against
> the impact of changing the standard at this stage.
>
> Thoughts?
>
>
> # 5. References
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017639.html
> [3] https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm
> [4] https://gcd.cr.yp.to/safegcd-20190413.pdf
> [5] https://github.com/bitcoin-core/secp256k1/pull/767
> [6] https://github.com/bitcoin-core/secp256k1/pull/797
> [7] https://github.com/bitcoin-core/secp256k1/pull/558
> [8]
> https://github.com/sipa/secp256k1/commit/822311ca230a48d2c373f3e48b91b2a59e1371d6
> [9] https://github.com/bitcoin/bitcoin/pull/17977
>
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200821/52fd57bc/attachment-0001.html>;

📅 Original date posted:2020-05-05 📝 Original message:There ...

2023-06-07T18:24:19Z

In reply to nevent1q…6rcy
_________________________

📅 Original date posted:2020-05-05
📝 Original message:There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:

- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
- people might build products that depend on altruistic nodes serving data,
which is unsustainable
- maybe at some point in the future, light clients will need to pay for
services

The choice isn't between people using light clients or not. People already
use light clients. The choice between whether we offer them a light client
technology that is better or worse for privacy and scalability.

The arguments for why BIP 157 is better than the existing light client
technologies are available elsewhere, but to summarize:

- they're unique for a block, which means they can easily be cached.
Serving a filter requires no computation, just i/o (or memory access for
cached filter/header data) and bandwidth. There are plenty of other
services that a full node offers that use i/o and bandwidth, such as
serving blocks.
- unique-for-block means clients can download from multiple sources
- the linked-headers/filters model allows hybrid approaches, where headers
checkpoints can be fetched from trusted/signed nodes, with intermediate
headers and filters fetched from untrusted sources
- less possibilities to DoS/waste resources on the serving node
- better for privacy

> The intention, as I understood it, of putting BIP157 directly into
bitcoind was to essentially force all `bitcoind` users to possibly service
BIP157 clients

Please. No-one is forcing anyone to do anything. To serve filters, a node
user needs to download the latest version, set `-blockfilterindex=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
P2P. This is an optional, off-by-default feature.

Regards,
John

On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning ariard and luke-jr
>
>
> > > Trust-minimization of Bitcoin security model has always relied first
> and
> > > above on running a full-node. This current paradigm may be shifted by
> LN
> > > where fast, affordable, confidential, censorship-resistant payment
> services
> > > may attract a lot of adoption without users running a full-node.
> >
> > No, it cannot be shifted. This would compromise Bitcoin itself, which for
> > security depends on the assumption that a supermajority of the economy is
> > verifying their incoming transactions using their own full node.
> >
> > The past few years has seen severe regressions in this area, to the point
> > where Bitcoin's future seems quite bleak. Without serious improvements
> to the
> > full node ratio, Bitcoin is likely to fail.
> >
> > Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> > and should be actively avoided. BIP 157 improves privacy of fn-less
> usage,
> > while providing no real benefits to full node users (compared to more
> > efficient protocols like Stratum/Electrum).
> >
> > For this reason, myself and a few others oppose merging support for BIP
> 157 in
> > Core.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>
> The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> fullnode to get BIP157 service.
> This is supposed to improve to the situation relative to e.g. Electrum,
> where there are far fewer Electrum servers than fullnodes.
>
> Of course, as ariard computes, deploying BIP157 could lead to an effective
> DDoS on the fullnode network if a large number of BIP157 clients arise.
> Though maybe this will not occur very fast? We hope?
>
> It seems to me that the thing that *could* be done would be to have
> watchtowers provide light-client services, since that seems to be the major
> business model of watchtowers, as suggested by ariard as well.
> This is still less than ideal, but maybe is better than nothing.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200505/be23bd38/attachment-0001.html>;

📅 Original date posted:2019-10-18 📝 Original message:> ...

2023-06-07T18:21:14Z

In reply to nevent1q…pwz2
_________________________

📅 Original date posted:2019-10-18
📝 Original message:> Is there a NODE_* bit we can use to pick peers that support this (useful!)
feature?

No. BIP 61 has no mechanism for advertising that a node will send REJECT
messages.

On Wed, Oct 16, 2019 at 12:43 PM John Newbery <john at johnnewbery.com> wrote:

> Following discussion on this mailing list, support for BIP 61 REJECT
> messages was not removed from Bitcoin Core in V0.19. The behaviour in that
> upcoming release is that REJECT messages are disabled by default and can be
> enabled using the `-enablebip61` command line option.
>
> Support for REJECT messages will be removed entirely in Bitcoin Core
> V0.20, expected for release in mid 2020. The PR to remove support was
> merged into Bitcoin Core's master branch this week.
>
> Adoption of new Bitcoin Core versions across reachable nodes generally
> takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows
> that although v0.18 was released in May 2019, there are still several
> hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.
> Software that currently use REJECT messages from public nodes for
> troubleshooting issues therefore have plenty of time to transition to one
> of the methods listed by Marco in the email above.
>
> John
>
> On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>> "version" messages from a network peer when the message could not be
>> accepted.
>>
>> This feature is toggled by the `-enablebip61` command line option and has
>> been
>> disabled by default since Bitcoin Core version 0.18.0 (not yet released
>> as of
>> time of writing). Nodes on the network can not generally be trusted to
>> send
>> valid ("reject") messages, so this should only ever be used when
>> connected to a
>> trusted node. At this time, I am not aware of any software that requires
>> this
>> feature, and I would like to remove if from Bitcoin Core to make the
>> codebase
>> slimmer, easier to understand and maintain. Let us know if your
>> application
>> relies on this feature and you can not use any of the recommended
>> alternatives:
>>
>> * Testing or debugging of implementations of the Bitcoin P2P network
>> protocol
>> should be done by inspecting the log messages that are produced by a
>> recent
>> version of Bitcoin Core. Bitcoin Core logs debug messages
>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>> (`-debuglogfile=<debug.log>`).
>>
>> * Testing the validity of a block can be achieved by specific RPCs:
>> - `submitblock`
>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>> potentially invalid POW
>>
>> * Testing the validity of a transaction can be achieved by specific RPCs:
>> - `sendrawtransaction`
>> - `testmempoolaccept`
>>
>> * Wallets should not use the absence of "reject" messages to indicate a
>> transaction has propagated the network, nor should wallets use "reject"
>> messages to set transaction fees. Wallets should rather use fee
>> estimation
>> to determine transaction fees and set replace-by-fee if desired. Thus,
>> they
>> could wait until the transaction has confirmed (taking into account the
>> fee
>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>> transaction announcement by other network peers to check for
>> propagation.
>>
>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
>> there are
>> valid concerns about its removal.
>>
>> Marco
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191018/947d583d/attachment-0001.html>;

📅 Original date posted:2019-10-16 📝 Original ...

2023-06-07T18:21:13Z

In reply to nevent1q…a9d3
_________________________

📅 Original date posted:2019-10-16
📝 Original message:Following discussion on this mailing list, support for BIP 61 REJECT
messages was not removed from Bitcoin Core in V0.19. The behaviour in that
upcoming release is that REJECT messages are disabled by default and can be
enabled using the `-enablebip61` command line option.

Support for REJECT messages will be removed entirely in Bitcoin Core V0.20,
expected for release in mid 2020. The PR to remove support was merged into
Bitcoin Core's master branch this week.

Adoption of new Bitcoin Core versions across reachable nodes generally
takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows
that although v0.18 was released in May 2019, there are still several
hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.
Software that currently use REJECT messages from public nodes for
troubleshooting issues therefore have plenty of time to transition to one
of the methods listed by Marco in the email above.

John

On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191016/4664e5b3/attachment.html>;

📅 Original date posted:2019-08-16 📝 Original message:Once a ...

2023-06-07T18:20:19Z

In reply to nevent1q…vcel
_________________________

📅 Original date posted:2019-08-16
📝 Original message:Once a consensus change has been activated and buried by sufficient work,
we consider the height of that change to be historic fact. The exact
activation method is no longer of practical interest. In some cases the
cause of activation is not even decidable. For example, we know that segwit
activated at height 481,824 but it's debatable whether that was due to BIP
9 version bits signaling, BIP 148 UASF, or a combination of the two.

In such cases, we can significantly simplify the implementation by
hard-coding the activation height. This was done for the 3 ISM soft forks
(BIPs 34, 66 and 65) in BIP 90 [1] [2]. P2SH and segwit script enforcement
were backdated to the genesis block (with the exception of for one block)
for similar code simplification reasons [3] [4].

'Burying' deployments in this way provides a number of benefits:

1. consensus code is simplified and implementers can avoid writing and
testing code paths that are no longer relevant.
2. a hard-coded activation height is far easier to review and re-implement
than complex deployment activation logic.
3. using a non-contextual check (in this case a hard-coded constant) can
provide performance and code structure benefits (eg reducing lock
contention on blockchain data).

Bitcoin Core PR 16060 [5] was recently merged, which buries the CSV and
segwit activation heights to 419328 and 481824 respectively.

It is technically possible for this to be a non-backwards compatible
change. In the event of a re-org below the BIP9 segwit LOCKED_IN height,
this change _could_ cause a chainsplit between pre-0.19 nodes and 0.19
nodes. Such a re-org would require re-doing over 93% of the total work ever
committed to Bitcoin mining (chainwork is 0x7eb6a652531c5ad6a4b8e9 at
height 481824 compared to 0x07d75b9d25fb6602be2b51c6 at height 590393). To
quote from BIP90:

> The occurrence of such a reorg that would cause the activating block to
be disconnected would raise fundamental concerns about the security
assumptions of Bitcoin, a far bigger issue than any non-backwards
compatible change.

> So while this proposal could theoretically result in a consensus split,
it is extremely unlikely, and in particular any such circumstances would be
sufficiently damaging to the Bitcoin network to dwarf any concerns about
the effects of this proposed change.

(See the 'Considerations' section of BIP 90 for more details).

Cheers,
John

[1] https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
[2] https://github.com/bitcoin/bitcoin/pull/8391
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015588.html
[4] https://github.com/bitcoin/bitcoin/pull/11739
[5] https://github.com/bitcoin/bitcoin/pull/16060
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190816/c439614c/attachment.html>;

📅 Original date posted:2019-05-22 📝 Original message:Hi, ...

2023-06-07T18:18:03Z

In reply to nevent1q…cyz9
_________________________

📅 Original date posted:2019-05-22
📝 Original message:Hi,

> A Taproot output is a SegWit output [...] with
> version number 1, and a 33-byte witness program whose first byte is 0 or
1.

Given a secret key k and public key P=(x,y), a signer with the knowledge of
k
can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding
the
y value of the public key therefore adds no security. As an alternative to
providing the y value of the taproot output key Q when constructing the
taproot
output, the signer can provide it when signing. We can also restrict the y
value
of the internal key P to be even (or high, or a quadratic residue). That
gives
us 4 options for how to set the y signs for P and Q.

1. Q sign is explictly set in the witness program, P sign is explicitly set
in the control block
=> witness program is 33 bytes, 32 possible leaf versions (one for each
pair of 0xc0..0xff)
2. Q sign is explictly set in the witness program, P sign is implicitly even
=> witness program is 33 bytes, 64 possible leaf versions (one for each
0xc0..0xff)
3. Q sign is explictly set in the control block, P sign is explicitly set
in the control block
=> witness program is 32 bytes, 16 possible leaf versions (one for each
4-tuple of 0xc0..0xff)
4. Q sign is explictly set in the control block, P sign is implicitly even
=> witness program is 32 bytes, 32 possible leaf versions (one for pair
of 0xc0..0xff)

The current proposal uses (1). Using (3) or (4) would reduce the size of a
taproot output by one byte to be the same size as a P2WSH output. That means
that it's not more expensive for senders compared to sending to P2WSH.

(Credit to James Chiang for suggesting omitting the y sign from the public
key and
to sipa for pointing out the 4 options above)

> (native or P2SH-nested, see BIP141)

I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
segwit
v0 for compatibility reasons. Most wallets/exchanges/services now support
sending
to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and
that
will be even more true if Schnorr/Taproot activate in 12+ months time.

On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello everyone,
>
> Here are two BIP drafts that specify a proposal for a Taproot
> softfork. A number of ideas are included:
>
> * Taproot to make all outputs and cooperative spends indistinguishable
> from eachother.
> * Merkle branches to hide the unexecuted branches in scripts.
> * Schnorr signatures enable wallet software to use key
> aggregation/thresholds within one input.
> * Improvements to the signature hashing algorithm (including signing
> all input amounts).
> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
> batch validation.
> * Tagged hashing for domain separation (avoiding issues like
> CVE-2012-2459 in Merkle trees).
> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
> upgradable pubkey types.
>
> The BIP drafts can be found here:
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
> specifies the transaction input spending rules.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
> specifies the changes to Script inside such spends.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> is the Schnorr signature proposal that was discussed earlier on this
> list (See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
> )
>
> An initial reference implementation of the consensus changes, plus
> preliminary construction/signing tests in the Python framework can be
> found on https://github.com/sipa/bitcoin/commits/taproot. All
> together, excluding the Schnorr signature module in libsecp256k1, the
> consensus changes are around 520 LoC.
>
> While many other ideas exist, not everything is incorporated. This
> includes several ideas that can be implemented separately without loss
> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
> which we're working on as an independent proposal.
>
> The document explains basic wallet operations, such as constructing
> outputs and signing. However, a wide variety of more complex
> constructions exist. Standardizing these is useful, but out of scope
> for now. It is likely also desirable to define extensions to PSBT
> (BIP174) for interacting with Taproot. That too is not included here.
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190522/74fc5f35/attachment-0001.html>;

📅 Original date posted:2018-01-23 📝 Original message:The ...

2023-06-07T18:10:13Z

In reply to nevent1q…5ala
_________________________

📅 Original date posted:2018-01-23
📝 Original message:The upcoming v0.16 release contains a slight change to the way that BIP16
is enforced, by basing activation on block height instead of block time.
This brings BIP 16 enforcement in line with BIP 34, BIP 66 and BIP 65.

This has no impact on consensus since BIP 16 was activated before the last
checkpoint and is buried under >300,000 blocks.

I've written up the changes in the BIP style below, although I don't think
this necessarily requires a full BIP. BIP 16 enforcement will likely change
again with https://github.com/bitcoin/bitcoin/pull/11739 in the next
bitcoin core release, so a formal proposal for this as a BIP will quickly
be superseded.

<pre>
BIP: ??
Layer: Consensus
Title: Buried Deployments (P2SH)
Author: John Newbery <john at chaincode.com>
Comments-Summary: No comments yet
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2018-01-22
License: CC-0
</pre>

==Abstract==

Enforce BIP 16 consensus rules based on block height rather than block time.

==Background==

BIP 16 was deployed via a hardcoded flag day consensus rule change. Prior
to the date of the consensus rule change being fixed, the miners signaled
readiness for the change by placing the string "/P2SH/" in the scriptSig of
the coinbase transaction txIn. The rule change was originally intended to
come into effect on 15 Feb 2012, but due to lack of miner signaling, the
activation date was pushed back to April 1st 2012. See [
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki The BIP 16
specification] for full details on the deployment method. The final
activation method was via a hardcoded block time of 1333238400 (April 1st
2012).

Now that the chain has long since passed the block at which the P2SH
consensus rule was activated, we can (as a simplification) replace the
trigger mechanism by caching the block height at which those consensus
rules became enforced.

==Motivation==

Activating the BIP 16 consensus change based on block time has several
disadvantages:

* The consensus change can be activated and later deactivated in the same
chain (since block time is not necessarily monotonically increasing).
* It is less flexible for constructing test chains for testing P2SH and
other soft fork activation

The flag day activation mechanism for code deployments was deprecated in
favor of [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
IsSuperMajority] deployments, and later by [
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki version
bits] deployments.

BIP 34, BIP 65, and BIP 66 deployments were later 'buried' by [
https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90] with
simple height checks. This simplification of the consensus rules reduced
the technical debt associated with deployment of those consensus changes.

This BIP changes the BIP 16 activation method to also be a 'buried'
deployment, activating at the block height that BIP 16 actually activated.
For the mainnet chain, this is block height 173805.

==Considerations==

Just as for the buried BIP 34, BIP 65 and BIP 66 deployments, it is
technically possible for this to be a non-backwards compatible change. For
example, if an alternate chain were created in which block height 173805
was reached after April 1st 2012, and a block with height <173805 but block
time after April 1st 2012 included an invalid P2SH spend, older software
would see that chain as invalid, but newer software implementing this
change would not.

See [https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90]
for justification of why this class of change is acceptable. As of January
2018, BIP 16 is buried by over 300,000 blocks. BIP 16 activation is also
protected by checkpoints (the most recent of which is at height 295000).

==Specification==

The BIP 16 activation height is set to 173805.

To determine whether to enforce BIP 16 on a given block, we just compare
the height of the block being validated with the stored activation height:

// Start enforcing P2SH (BIP16)
if (pindex->nHeight >= consensusparams.BIP16Height) {
flags |= SCRIPT_VERIFY_P2SH;
}

See the implementation for additional details.

==Implementation==

https://github.com/bitcoin/bitcoin/commit/18e071841e83044b47aa45c3e98c0796a407d445

==Acknowledgements==

Thanks to Russ Yanofsky, Marco Falke and Suhas Daftuar for suggestions and
feedback.

==Copyright==

This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/79e117ee/attachment-0001.html>;