Discovery/addr packets (was: Service bits for pruned nodes)



Summary:

The issue of delays in finding a peer that will accept an incoming connection on Android phones has been raised. However, it is unlikely to be due to regular nodes not caring about responding to SPV nodes quickly, as remote nodes do not have any special code that knows what kind of client is connecting. The issue may lie with overloaded seeds or general delays in bringing up a 3G data link from idle.Jeff's seed was removed in git master a few weeks ago because it was often serving nodes that were full, which should speed things up a bit. There are many other ways to optimize performance beyond having fresh seeds, such as the Android app supporting putting Bluetooth MAC addresses in URLs served via QRcode/NFC. This means that the sending side can provide the receiving side with a transaction via a local Bluetooth socket, eliminating the need to wait for P2P bringup on the send side.In a typical merchant scenario, the receive side is more likely to have WiFi access and is more likely to be talking to the network frequently, so its list of IPs gathered from addr packets would be fresher. It can do P2P bringup whilst the user is confirming/signing/uploading on the sending side, overlapping the two and buying precious seconds. These methods can help improve the efficiency of connecting to peers on Android phones.


Updated on: 2023-06-06T16:06:00.644027+00:00