IRC meeting summary for 2016-05-12
- General BIP process and issues
- RPC long poll notifications
Compact Block Relay BIP and general BIP process
BIP 152: “Compact block relay” is a proposed idea by BlueMatt for decreasing the bandwidth used during block relay by using short transaction IDs for transactions that should be in the mempool of the node. As a side-effect this also results in reducing the block transfer latency.
BIP editor Luke-jr says he’d like people not to ACK/NACK BIPs if they aren’t a listed author of said BIP as the BIP is a document by the authors.
Jonasschnelli proposes to define a rule for how to deal with links to implementations that have implemented the BIP. In BIP32 there are continuously pull requests to add links which serve more as advertisement than anything else. It also opens up the risk for malware if we aren’t monitoring it. The reference implementation can be useful as well as the implementation in other languages, so it’s preferable to link to implementations. Jcorgan proposes to link to an URL and commit hash, to make sure the linked code reflects the implementation.
Adding BIP implementation links is up to the BIP author, in general it should be linked to the actual code, not the product.
RPC long poll notifications
Long polling or similar protocols would enable an easy and secure way to add remote GUI and remote wallets to Core over the internet.
PR #7949 by jonasschnelli is implemententing RPC long poll notifications.
Currently ZeroMQ is used for notifications, but is really only useful for local systems, not for notifications via internet. Jcorgan notes this is possible via CurveZMQ.
ZeroMQ might be too complex to extend much further and is suboptimal to write a remote GUI for as you can’t filter for just wallet transactions, while long polling requires little code changes and has no dependencies. There might be value in keeping Core limited to one interface though.
Another advantage of RPC long polling is the ability to have private notifications secured behind auth. Wumpus wonders if we want private notifications. For a remote wallet GUI you would, however the idea was to attach a wallet, not wallet GUI as the wallet needs to be split from core, he explains. Ideally the node, wallet and GUI should be separated. Sipa is not sure the Core wallet should be providing communication channels at this time.
Another solution would be to provide a tiny deamon that would interact between core and a remote GUI/wallet.
There are many possibilities: multiple notification protocols, only ZeroMQ, only RPC. Opinions diverge dramatically and discussion went on after the meeting. Most seem to agree though the focus should be on the node <-> wallet connection.
Jonasschnelli will add some easy examples for RPC longpolling.
|wumpus||Wladimir van der Laan|
This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.