Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-13 📝 Original message:> All adopted BIPs to date ...

📅 Original date posted:2017-02-13
📝 Original message:> 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://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
Isn't it the same there?
Once BIP151 is implemented, it would make sense to bump the protocol
version, but this needs to be done once this has been
implemented/deployed. Or do I make a mistake somewhere?
>
> As for DOS, waste of bandwidth is not something to be ignored. If a peer
> is flooding a node with addr message the node can manage it because it
> understands the semantics of addr messages. If a node is required to
> allow any message that it cannot understand it has no recourse. It
> cannot determine whether it is under attack or if the behavior is
> correct and for proper continued operation must be ignored.
How do you threat any other not known message types? Any peer can send
you any type of message anytime. Why would your implementation how you
threat unknown messages be different for messages specified in BIP151?


</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170213/310f938e/attachment.sig>;