I’m pretty sure one can run whatever they want even without a BIP. There is nobody here to do any “allowing”. On the other hand, standards development is tedious for good reason.
Generally speaking, overloading is a primary source of complexity (creating more branches in code and human explanation). Nevertheless this is verack payload, no additional messages are necessary or helpful. e > On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Sure, we could do a new message for negotiation, but there doesn’t seem to > be a lot of reason for it - using the same namespace for negotiation seems > fine too. In any case, this is one of those things that doesn’t matter in the > slightest, and if one person volunteers to write a BIP and code, no reason > they shouldn’t just decide and be allowed to run with it. Rough consensus and > running code, as it were :) > > Matt > > >>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev >>> wrote: >>> In thinking about the mechanism used there, I thought it would be helpful to >>> codify in a BIP the idea that Bitcoin network clients should ignore unknown >>> messages received before a VERACK. A draft of my proposal is available here >>> [2]. >> >> Rather than allowing arbitrary messages, maybe it would make sense to >> have a specific feature negotiation message, eg: >> >> VERSION ... >> FEATURE wtxidrelay >> FEATURE packagerelay >> VERACK >> >> with the behaviour being that it's valid only between VERSION and VERACK, >> and it takes a length-prefixed-string giving the feature name, optional >> additional data, and if the feature name isn't recognised the message >> is ignored. >> >> If we were to support a "polite disconnect" feature like Jeremy suggested, >> it might be easier to do that for a generic FEATURE message, than >> reimplement it for the message proposed by each new feature. >> >> Cheers, >> aj >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
