zmq: Add jsonblock, jsontx #14876

These changes allow ZMQ to publish its updates for txs and blocks as human-readable JSON, as opposed to in the raw Bitcoin format. Output data corresponds to verbosity level 1.

Closes #14873

Have you seen #11614?

@promag Thanks for showing me that - I hadn't seen it.

I think the prior discussion is great; I value these changes for the same reasons as @astanway:

• Swift / Objective-C doesn't have a transaction or block parsing library available; I would like to avoid custom code involving varint, etc. This "portability" concern will almost certainly appear again.
• I am using @fanquake's CoreRPC for an iOS project. ZMQ is a nice complement, and I can use it to determine the chaintip update event, but would much prefer it in a deserialized format. Assuming I don't want to "roll my own" parser:
• No unnecessary roundtrip from an additional RPC call (getblock)

Perhaps there is a bit of bias in the prior discussion, since experts @luke-jr and @dcousens dismissed it as "easy to implement". I think there is an important question raised:

However, if ease of application development is not a priority for the project, then sure - happy to close.

The tradeoffs seem to favor having an option for JSON, since we already serve JSON over RPC.

I don't think JSON and ZMQ is a good combination. The formatting overhead for JSON kind of defeats the purpose of a low-latency networking system like ZMQ.

I don't disagree it could be useful for some cases though.

@laanwj That was also my thought on seeing the PR title.

I hear the response - fair enough. What could be done next / instead? Any room for it to be optional or are we marking it 'bad practice'?

I hear the response - fair enough. What could be done next / instead?

If performance isn't important, otherwise you'd be using a client-side decoding library, but you're using zmq as a notification mechanism, why is the extra roundtrip to call getblock or decoderawtransaction such a problem?

A small performance hit in-transit would cost less and be more reliable than two (1 zmq 1 rpc) networking events, I guess was my reasoning. The duplicate call would mean more transferred data in total than zmq with JSON formatting. I'm only interested in the latest block's stats.

Implementing parsing on clients makes the most sense, agreed.

hashblock is all I really needed. hashtx, rawtx, and decoderawtransaction got me mixed up in unneeded possibilities.

This might sound useless or even confusing, but for symmetry, we could consider decoderawblock as an RPC. There is already submitblock whose interface seemingly makes more sense for bitcoind, as it checks its existence against the block db unavoidably, but doesn't return a JSON representation of the block.

A defensive check could also be added regarding the max expected size of rawblock and rawtx.

I agree with @laanwj about JSON probably not being something we should have in conjunction with ZMQ.

I think a path for having JSON push notification would be the RPC long polling feature. A first step could be: #13262 (outdated)

I agree with @jonasschnelli. @ch4ot1c don't forget that at the moment zmq notifications happen on the "main" thread. RPC is handled on a thread pool.

As there is no agreement to do this I'm closing this PR