IRC meeting summary for 2016-05-12

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• General BIP process and issues
• RPC long poll notifications

Compact Block Relay BIP and general BIP process

background

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.

meeting comments

The BIP9 deployment document talked about in last weeks meeting has been made.

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.

meeting conclusion

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

background

Long polling or similar protocols would enable an easy and secure way to add remote GUI and remote wallets to Core over the internet.

meeting comments

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.

meeting conclusion

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.

Comic relief

kanzure    have we received an overview from sipa yet about areas of segwit that he feels should be most thoroughly reviewed
sipa       kanzure: no, sorry
kanzure    can we get 10 volunteers to heckle sipa about this?

Participants

Disclaimer

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.