PyBitmessage does not wait for "verack" and has non specified timeout. #662

New Issue

2014-04-30T14:57:32+02:00

Thomas-Astade commented

2014-04-30 14:57:32 +02:00

(Migrated from github.com)

I found a (small) bug in PyBitmessage Version 0.4.2 (or in the protocol specification)

Bug description:

The protocol specification states:
... No futher communication is possible until both peers have exchanged their version.

But PyBitmessage Version 0.4.2 sends an "addr" or an "inv"

message, without having received my "verack" (I'm sure I've not send it because I've not yet implemented it)

It's not a "showstopper" type of bug. But as PyBitmessage is assumed to be the "reference implementation" we should clearify what's the correct behaviour. Maybe the "verack" message is optional? Than this should be mentioned in the protocol specification.

In addition to that, PyBitmessage closes the connection after 20 seconds. That looks like a type of "timeout". Why? There is none specified (maybe we should specify one).

Trace:

First run:

Message type Version:
127.0.0.1:36271 -> 127.0.0.1:8444
0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0x000010: 00 00 00 7f 0e 80 43 17 00 00 00 02 00 00 00 00 ......C.........
0x000020: 00 00 00 01 00 00 00 00 53 60 e8 23 00 00 00 00 ........S`.#....
0x000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0x000040: 01 00 00 7f fc 20 00 00 00 00 00 00 00 01 00 00 ..... ..........
0x000050: 00 00 00 00 00 00 00 00 ff ff 01 00 00 7f af 8d ................
0x000060: e2 2b a4 e2 64 b6 ad 16 2c 68 74 74 70 73 3a 2f .+..d...,https:/
0x000070: 2f 67 69 74 68 75 62 2e 63 6f 6d 2f 54 68 6f 6d /github.com/Thom
0x000080: 61 73 2d 41 73 74 61 64 65 2f 62 69 74 6d 65 73 as-Astade/bitmes
0x000090: 73 61 67 65 64 01 01                            saged..         
expect a message of size: 24
Received Message:
0x000000: e9 be b4 d9 76 65 72 61 63 6b 00 00 00 00 00 00 ....verack......
0x000010: 00 00 00 00 cf 83 e1 35                         .......5        
expect a message of size: 127
Received Message:
0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0x000010: 00 00 00 67 1d df c0 28 00 00 00 02 00 00 00 00 ...g...(........
0x000020: 00 00 00 01 00 00 00 00 53 60 e8 23 00 00 00 00 ........S`.#....
0x000030: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ff ff ................
0x000040: 7f 00 00 01 8d af 00 00 00 00 00 00 00 01 00 00 ................
0x000050: 00 00 00 00 00 00 00 00 ff ff 7f 00 00 01 20 fc .............. .
0x000060: 8d b3 73 9e f3 19 67 b1 14 2f 50 79 42 69 74 6d ..s...g../PyBitm
0x000070: 65 73 73 61 67 65 3a 30 2e 34 2e 32 2f 01 01    essage:0.4.2/.. 
expect a message of size: 63
Received Message:
0x000000: e9 be b4 d9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0x000010: 00 00 00 27 9c cb ff 00 01 00 00 00 00 53 60 e8 ...'.........S`.
0x000020: 28 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 (...............
0x000030: 00 00 00 00 00 00 00 ff ff 4d bf 34 58 20 fc    .........M.4X . 


Next run:

Message type Version:
127.0.0.1:37291 -> 127.0.0.1:8444
0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0x000010: 00 00 00 7f 24 04 31 3a 00 00 00 02 00 00 00 00 ....$.1:........
0x000020: 00 00 00 01 00 00 00 00 53 60 ee ba 00 00 00 00 ........S`......
0x000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0x000040: 01 00 00 7f fc 20 00 00 00 00 00 00 00 01 00 00 ..... ..........
0x000050: 00 00 00 00 00 00 00 00 ff ff 01 00 00 7f ab 91 ................
0x000060: a0 ff 0e a0 99 74 2d 95 2c 68 74 74 70 73 3a 2f .....t-.,https:/
0x000070: 2f 67 69 74 68 75 62 2e 63 6f 6d 2f 54 68 6f 6d /github.com/Thom
0x000080: 61 73 2d 41 73 74 61 64 65 2f 62 69 74 6d 65 73 as-Astade/bitmes
0x000090: 73 61 67 65 64 01 01                            saged..         
expect a message of size: 24
Received Message:
0x000000: e9 be b4 d9 76 65 72 61 63 6b 00 00 00 00 00 00 ....verack......
0x000010: 00 00 00 00 cf 83 e1 35                         .......5        
expect a message of size: 127
Received Message:
0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0x000010: 00 00 00 67 1e f8 8e 49 00 00 00 02 00 00 00 00 ...g...I........
0x000020: 00 00 00 01 00 00 00 00 53 60 ee ba 00 00 00 00 ........S`......
0x000030: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ff ff ................
0x000040: 7f 00 00 01 91 ab 00 00 00 00 00 00 00 01 00 00 ................
0x000050: 00 00 00 00 00 00 00 00 ff ff 7f 00 00 01 20 fc .............. .
0x000060: 8d b3 73 9e f3 19 67 b1 14 2f 50 79 42 69 74 6d ..s...g../PyBitm
0x000070: 65 73 73 61 67 65 3a 30 2e 34 2e 32 2f 01 01    essage:0.4.2/.. 
expect a message of size: 89
Received Message:
0x000000: e9 be b4 d9 69 6e 76 00 00 00 00 00 00 00 00 00 ....inv.........
0x000010: 00 00 00 41 63 1f 9c 6c 02 58 18 4c a5 ef 61 c6 ...Ac..l.X.L..a.
0x000020: 90 90 52 03 9f 57 1d 56 3a 93 fa a6 45 3a 36 2c ..R..W.V:...E:6,
0x000030: e8 2b 90 bf b4 61 86 a5 29 da e5 66 b4 9b 38 85 .+...a..)..f..8.
0x000040: 31 c3 76 01 f1 35 11 66 a2 41 02 d6 ba 56 41 26 1.v..5.f.A...VA&
0x000050: 18 ec 96 40 fa d5 3b ef 25                      ...@..;.%       

```]

I found a (small) bug in PyBitmessage Version 0.4.2 (or in the protocol specification) Bug description: The protocol specification states: ... No futher communication is possible until both peers have exchanged their version. But PyBitmessage Version 0.4.2 sends an "addr" or an "inv" message, without having received my "verack" (I'm sure I've not send it because I've not yet implemented it) It's not a "showstopper" type of bug. But as PyBitmessage is assumed to be the "reference implementation" we should clearify what's the correct behaviour. Maybe the "verack" message is optional? Than this should be mentioned in the protocol specification. In addition to that, PyBitmessage closes the connection after 20 seconds. That looks like a type of "timeout". Why? There is none specified (maybe we should specify one). Trace: `````` First run: Message type Version: 127.0.0.1:36271 -> 127.0.0.1:8444 0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version..... 0x000010: 00 00 00 7f 0e 80 43 17 00 00 00 02 00 00 00 00 ......C......... 0x000020: 00 00 00 01 00 00 00 00 53 60 e8 23 00 00 00 00 ........S`.#.... 0x000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................ 0x000040: 01 00 00 7f fc 20 00 00 00 00 00 00 00 01 00 00 ..... .......... 0x000050: 00 00 00 00 00 00 00 00 ff ff 01 00 00 7f af 8d ................ 0x000060: e2 2b a4 e2 64 b6 ad 16 2c 68 74 74 70 73 3a 2f .+..d...,https:/ 0x000070: 2f 67 69 74 68 75 62 2e 63 6f 6d 2f 54 68 6f 6d /github.com/Thom 0x000080: 61 73 2d 41 73 74 61 64 65 2f 62 69 74 6d 65 73 as-Astade/bitmes 0x000090: 73 61 67 65 64 01 01 saged.. expect a message of size: 24 Received Message: 0x000000: e9 be b4 d9 76 65 72 61 63 6b 00 00 00 00 00 00 ....verack...... 0x000010: 00 00 00 00 cf 83 e1 35 .......5 expect a message of size: 127 Received Message: 0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version..... 0x000010: 00 00 00 67 1d df c0 28 00 00 00 02 00 00 00 00 ...g...(........ 0x000020: 00 00 00 01 00 00 00 00 53 60 e8 23 00 00 00 00 ........S`.#.... 0x000030: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ff ff ................ 0x000040: 7f 00 00 01 8d af 00 00 00 00 00 00 00 01 00 00 ................ 0x000050: 00 00 00 00 00 00 00 00 ff ff 7f 00 00 01 20 fc .............. . 0x000060: 8d b3 73 9e f3 19 67 b1 14 2f 50 79 42 69 74 6d ..s...g../PyBitm 0x000070: 65 73 73 61 67 65 3a 30 2e 34 2e 32 2f 01 01 essage:0.4.2/.. expect a message of size: 63 Received Message: 0x000000: e9 be b4 d9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........ 0x000010: 00 00 00 27 9c cb ff 00 01 00 00 00 00 53 60 e8 ...'.........S`. 0x000020: 28 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 (............... 0x000030: 00 00 00 00 00 00 00 ff ff 4d bf 34 58 20 fc .........M.4X . Next run: Message type Version: 127.0.0.1:37291 -> 127.0.0.1:8444 0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version..... 0x000010: 00 00 00 7f 24 04 31 3a 00 00 00 02 00 00 00 00 ....$.1:........ 0x000020: 00 00 00 01 00 00 00 00 53 60 ee ba 00 00 00 00 ........S`...... 0x000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................ 0x000040: 01 00 00 7f fc 20 00 00 00 00 00 00 00 01 00 00 ..... .......... 0x000050: 00 00 00 00 00 00 00 00 ff ff 01 00 00 7f ab 91 ................ 0x000060: a0 ff 0e a0 99 74 2d 95 2c 68 74 74 70 73 3a 2f .....t-.,https:/ 0x000070: 2f 67 69 74 68 75 62 2e 63 6f 6d 2f 54 68 6f 6d /github.com/Thom 0x000080: 61 73 2d 41 73 74 61 64 65 2f 62 69 74 6d 65 73 as-Astade/bitmes 0x000090: 73 61 67 65 64 01 01 saged.. expect a message of size: 24 Received Message: 0x000000: e9 be b4 d9 76 65 72 61 63 6b 00 00 00 00 00 00 ....verack...... 0x000010: 00 00 00 00 cf 83 e1 35 .......5 expect a message of size: 127 Received Message: 0x000000: e9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version..... 0x000010: 00 00 00 67 1e f8 8e 49 00 00 00 02 00 00 00 00 ...g...I........ 0x000020: 00 00 00 01 00 00 00 00 53 60 ee ba 00 00 00 00 ........S`...... 0x000030: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ff ff ................ 0x000040: 7f 00 00 01 91 ab 00 00 00 00 00 00 00 01 00 00 ................ 0x000050: 00 00 00 00 00 00 00 00 ff ff 7f 00 00 01 20 fc .............. . 0x000060: 8d b3 73 9e f3 19 67 b1 14 2f 50 79 42 69 74 6d ..s...g../PyBitm 0x000070: 65 73 73 61 67 65 3a 30 2e 34 2e 32 2f 01 01 essage:0.4.2/.. expect a message of size: 89 Received Message: 0x000000: e9 be b4 d9 69 6e 76 00 00 00 00 00 00 00 00 00 ....inv......... 0x000010: 00 00 00 41 63 1f 9c 6c 02 58 18 4c a5 ef 61 c6 ...Ac..l.X.L..a. 0x000020: 90 90 52 03 9f 57 1d 56 3a 93 fa a6 45 3a 36 2c ..R..W.V:...E:6, 0x000030: e8 2b 90 bf b4 61 86 a5 29 da e5 66 b4 9b 38 85 .+...a..)..f..8. 0x000040: 31 c3 76 01 f1 35 11 66 a2 41 02 d6 ba 56 41 26 1.v..5.f.A...VA& 0x000050: 18 ec 96 40 fa d5 3b ef 25 ...@..;.% ```] ``````

Atheros1 commented

2014-04-30 21:28:04 +02:00

(Migrated from github.com)

I think that this can fairly be categorized as a bug. I've fixed it. inv and addr messages now won't be shared before the connection is fully established. "connection is fully established" is defined as having sent and received veracks. Incoming inv and addr messages are already ignored if the connection is not fully established.

If the connection is not fully established then the timeout is 20 seconds; this is what I considered to be the maximum reasonable time it might take to connect through Tor. A long timeout here is bad because it slows down bootstrapping. After the connection is fully established then the timeout is raised to 10 minutes.

I think that this can fairly be categorized as a bug. I've fixed it. inv and addr messages now won't be shared before the connection is fully established. "connection is fully established" is defined as having sent and received veracks. Incoming inv and addr messages are already ignored if the connection is not fully established. If the connection is not fully established then the timeout is 20 seconds; this is what I considered to be the maximum reasonable time it might take to connect through Tor. A long timeout here is bad because it slows down bootstrapping. After the connection is fully established then the timeout is raised to 10 minutes.

This repo is archived. You cannot comment on issues.