Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-20 🗒️ Summary of this message: A proposal to ...
📅 Original date posted:2023-02-20
🗒️ Summary of this message: A proposal to simplify the implementation of short ids in Bitcoin by negotiating a different short id mapping table without needing a mechanism for re-negotiating.
📝 Original message:On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns <aj at erisian.com.au> wrote:
> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > > I think it's probably less complex to close some of the doors?
> > > 2) are short ids available/meaningful to send prior to VERACK being
> > > completed?
> > > Ah, I hadn't considered this nuance. If we don't care about them being available before VERACK negotiation, then it may be possible to introduce a way to negotiate a different short id mapping table without needing a mechanism for re-negotiating.
>
> I think you still need/want two negotiation steps -- once to tell each
> other what tables you know about, once to choose a mutually recognised
> table and specify any additions.
Right, I wasn't talking about how many steps/messages the negotiation takes. I just meant that if all negotiation of the mapping table happens just once (before VERACK) and that negotiation itself happens without use of short commands, then there is no need for re-negotiating short commands after they are already in use. Nothing concrete, but I can imagine that that may simplify some implementations.
Cheers,
--
Pieter
🗒️ Summary of this message: A proposal to simplify the implementation of short ids in Bitcoin by negotiating a different short id mapping table without needing a mechanism for re-negotiating.
📝 Original message:On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns <aj at erisian.com.au> wrote:
> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > > I think it's probably less complex to close some of the doors?
> > > 2) are short ids available/meaningful to send prior to VERACK being
> > > completed?
> > > Ah, I hadn't considered this nuance. If we don't care about them being available before VERACK negotiation, then it may be possible to introduce a way to negotiate a different short id mapping table without needing a mechanism for re-negotiating.
>
> I think you still need/want two negotiation steps -- once to tell each
> other what tables you know about, once to choose a mutually recognised
> table and specify any additions.
Right, I wasn't talking about how many steps/messages the negotiation takes. I just meant that if all negotiation of the mapping table happens just once (before VERACK) and that negotiation itself happens without use of short commands, then there is no need for re-negotiating short commands after they are already in use. Nothing concrete, but I can imagine that that may simplify some implementations.
Cheers,
--
Pieter