>> This indeed is not ideal for compatibility checks, but increases security.
> The issue I raised is that it is not backward compatible. It sounds like
> you agree but consider it a fair trade. My suggesting was that the BIP
> be updated to reflect the lack of compatibility.
It's still backward c
On 02/13/2017 03:14 AM, Jonas Schnelli wrote:
>>> Look at feefilter BIP 133
>>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
>>> or sendheaders BIP130
>>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
>>> Isn't it
Sorry, I'm still missing it...
So your claim is that a) ignoring incoming messages of a type you do not
recognize is bad, and thus b) we should be disconnecting/banning peers which
send us messages we do not recognize (can you spell out why? Anyone is free to
send your host address messages/tran
On 02/13/2017 02:16 AM, Matt Corallo wrote:
> For the reasons Pieter listed, an explicit part of our version
handshake and protocol negotiation is the exchange of otherwise-ignored
messages to set up optional features.
Only if the peer is at the protocol level that allows the message:
compact blo
On 02/13/2017 03:11 AM, Matt Corallo wrote:
> I believe many, if not all, of those messages are sent irrespective of
> version number.
In the interest of perfect clarity, see your code:
https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1372-L1403
Inside of the VERACK handle
On 02/13/2017 02:07 AM, Jonas Schnelli via bitcoin-dev wrote:
>> All adopted BIPs to date have followed this
>> pattern. This is not the same and it is not helpful to imply that it is
>> just following that pattern.
>
> Look at feefilter BIP 133
> (https://github.com/bitcoin/bips/blob/master/bip-0
>> Look at feefilter BIP 133
>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
>> or sendheaders BIP130
>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
>> Isn't it the same there?
> No. This is what I was referring
I believe many, if not all, of those messages are sent irrespective of version
number.
In any case, I fail to see how adding any additional messages which are ignored
by old peers amounts to a lack of backward compatibility.
On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil
wrote:
>On
For the reasons Pieter listed, an explicit part of our version handshake and
protocol negotiation is the exchange of otherwise-ignored messages to set up
optional features.
Peers that do not support this ignore such messages, just as if they had
indicated they wouldn't support it, see, eg BIP 1
> All adopted BIPs to date have followed this
> pattern. This is not the same and it is not helpful to imply that it is
> just following that pattern.
Look at feefilter BIP 133
(https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
or sendheaders BIP130
(https://g
On 02/13/2017 12:47 AM, Pieter Wuille wrote:
> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
>
> The BIP151 proposal states:
>
> > This proposal is backward compatible. Non-supporting peers will ignore
> the encinit messages.
>
> This statement is incorrect. Sending cont
On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
The BIP151 proposal states:
> This proposal is backward compatible. Non-supporting peers will ignore
the encinit messages.
This statement is incorrect. Sending content that existing nodes do not
The BIP151 proposal states:
> This proposal is backward compatible. Non-supporting peers will ignore
the encinit messages.
This statement is incorrect. Sending content that existing nodes do not
expect is clearly an incompatibility. An implementation that ignores
invalid content leaves itself wid
13 matches
Mail list logo
