As the idea got positive feedback, I've written the BIP.
The draft is available here:
https://github.com/bitcoin/bips/pull/856
Am 17.10.19 um 15:23 schrieb Marco Falke via bitcoin-dev:
> I also like the "bitcoin invoice address" term by Chris. Invoice is a
> common term and easily translatable int
As this is a P2P protocol change it should be exposed as a version increment
(and a BIP), not just as a conditional service. If the intent is to retain this
protocol indefinitely, exposing it conditionally, then a service bit would make
sense, but it remains a protocol change.
BIP61 is explicit
Hi, I need a co-author for this BIP:
https://github.com/bitcoin/bips/pull/856
See the reasons mentioned by Marco Falke
pEpkey.asc
Description: application/pgp-keys
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfo
> 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
>
On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-dev wrote:
> As this is a P2P protocol change it should be exposed as a version
> increment (and a BIP) [...]
>
> BIP61 is explicit:
>
> “All implementations of the P2P protocol version 70,002 and later
> should support the reject
