Re: [bitcoin-dev] Reminder on the Purpose of BIPs

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

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

ACK adding Kalle. On Fri, Apr 23, 2021 at 4:36 AM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ACK adding Kalle. > > Kalle is a qualified reviewer / editor and well suited for this role. > -- > @JeremyRubin >

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

und 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

Re: [bitcoin-dev] Proposal for new "disabletx" p2p 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 (

[bitcoin-dev] BIP 155 (addrv2) update - spec and Bitcoin Core v0.21 implementation

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

Re: [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

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 numb

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

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

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

> 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 wrote: > Following discussion on this mailing list, support for BIP 61 REJECT >

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

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 messa

[bitcoin-dev] Burying CSV and segwit soft fork activations

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 activate

Re: [bitcoin-dev] Taproot proposal

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

[bitcoin-dev] BIP16 enforcement change in V0.16

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 check