npub1ap…608ff

Last Notes

2023-06-09 13:00:06 UTC

- reply

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

2023-06-07 22:52:03 UTC

- reply

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

2023-06-07 18:29:48 UTC

- reply

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

2023-06-07 18:27:48 UTC

- reply

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

2023-06-07 18:26:21 UTC

- reply

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

2023-06-07 18:24:19 UTC

- reply

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

2023-06-07 18:20:19 UTC

- reply

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