You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a getheaders message contains a malformed start block hash then the namecoin client responds with sending a headers message containing 2001 headers. It should send out 2000 headers oder less, though.
The client reacts correctly, however, if the stop block hash is invalid or set to zero.
I haven't looked at the code but if there is some memory allocation involved then preparing 1 header to many may cause a buffer overflow or similar. But even if it is save, it can break a recipient's application which expects 2000 headers at most.
Clients as old as namecoind 0.3.5x show this behaviour as well as a freshly compiled Namecoin-Qt (latest commit). This bug doesn't exist in the current Bitcoin clients (tested by sending a malformed getheaders message to a 0.9.1 client; yields precisely 2000 headers).
The text was updated successfully, but these errors were encountered:
If a getheaders message contains a malformed start block hash then the namecoin client responds with sending a headers message containing 2001 headers. It should send out 2000 headers oder less, though.
The client reacts correctly, however, if the stop block hash is invalid or set to zero.
I haven't looked at the code but if there is some memory allocation involved then preparing 1 header to many may cause a buffer overflow or similar. But even if it is save, it can break a recipient's application which expects 2000 headers at most.
Clients as old as namecoind 0.3.5x show this behaviour as well as a freshly compiled Namecoin-Qt (latest commit). This bug doesn't exist in the current Bitcoin clients (tested by sending a malformed getheaders message to a 0.9.1 client; yields precisely 2000 headers).
The text was updated successfully, but these errors were encountered: