đź“… Original date posted:2020-08-21
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
lf-lists at mattcorallo.com [ARCHIVE] /
npub1fn…lmg4s
2023-06-07 18:26:28
in reply to nevent1q…5s5d
Author Public Key
npub1fnct80cl770m0jjvqp5s2e2txzaqvn6p2a2dnq4uaar7vjfk7srq3lmg4sSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:26:28Event JSON
{
"id": "986598267314d1e32a55a11cfb0a036bd4cbd65c78422b6f66cc91562e0ba927",
"pubkey": "4cf0b3bf1ff79fb7ca4c006905654b30ba064f415754d982bcef47e64936f406",
"created_at": 1686162388,
"kind": 1,
"tags": [
[
"e",
"43edfd73733fa9cb455dfd9022ab700e39020c27283a7e2f0343a8c6fb631001",
"",
"root"
],
[
"e",
"8d2b2a1bce61b0840ac99c1dfcd856254cea0e5d67b6931c81ad676f89d8c824",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2020-08-21\n📝 Original message: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 :)\n\nMatt\n\n\n\u003e On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote:\n\u003e\u003e In thinking about the mechanism used there, I thought it would be helpful to\n\u003e\u003e codify in a BIP the idea that Bitcoin network clients should ignore unknown\n\u003e\u003e messages received before a VERACK. A draft of my proposal is available here\n\u003e\u003e [2].\n\u003e \n\u003e Rather than allowing arbitrary messages, maybe it would make sense to\n\u003e have a specific feature negotiation message, eg:\n\u003e \n\u003e VERSION ...\n\u003e FEATURE wtxidrelay\n\u003e FEATURE packagerelay\n\u003e VERACK\n\u003e \n\u003e with the behaviour being that it's valid only between VERSION and VERACK,\n\u003e and it takes a length-prefixed-string giving the feature name, optional\n\u003e additional data, and if the feature name isn't recognised the message\n\u003e is ignored.\n\u003e \n\u003e If we were to support a \"polite disconnect\" feature like Jeremy suggested,\n\u003e it might be easier to do that for a generic FEATURE message, than\n\u003e reimplement it for the message proposed by each new feature.\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "c759d9831355c5b6a0c55b671e53df93dd7ed2229239bab7b3ddef501b481fb7294cd8df0e528e29b5a6a409ab29349fbcd41dd5cbe65c63f396144ca62590be"
}