1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 11:08:05 +01:00

Improve specification of transport protocols

This commit is contained in:
Ben 2024-03-07 21:52:29 +01:00
parent 72bfc4d01b
commit abe08e4b5f

View file

@ -30,7 +30,7 @@ The Stratum wire protocol defines a way to access the blockchain without having
Stratum wire protocol was introduced by Marek Palatinus in late 2011 and early 2012. It was a language independent alternative for the Python-based protocol in early versions of Electrum, created by Thomas Voegtlin. The Stratum wire protocol made it possible to create compatible servers which Electrum could connect to, but it also made it possible to write alternative clients.
Later in 2012, Marek Palatinus introduced Stratum also for mining pools: The Stratum mining protocol, as defined in [[bip-0044.mediawiki|BIP 44]].
Later in 2012, Marek Palatinus introduced Stratum also for mining pools: The Stratum mining protocol, as defined in [[bip-0041.mediawiki|BIP 41]].
==Specification: Data Format==
@ -38,27 +38,39 @@ Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0
Additionally, it is a convention to give all Stratum methods in the <code>method</code> property a name in the following form: <code><service>.<method></code>, where <code><service></code> is allowed to have dots and <code><method></code> isn't. For example, the the value <code>blockchain.block.subscribe</code>.
Note: In JSON-RPC 1.0, the <code>param</code> property is an array, so everything should be passed in the right order. In JSON-RPC 2.0, also named parameters are allowed. In that case, the parameter names that are documented should be used. If not, the method can fail. It is maybe also possible that a specific method (or server) only does support <code>params</code> being an array, because it doesn't know how to handle the named ones, even if it supports JSON-RPC 2.0.
''Note: In JSON-RPC 1.0, the <code>param</code> property is an array, so everything should be passed in the right order. In JSON-RPC 2.0, also named parameters are allowed. In that case, the parameter names that are documented should be used. If not, the method can fail. It is maybe also possible that a specific method (or server) only does support <code>params</code> being an array, because it doesn't know how to handle the named ones, even if it supports JSON-RPC 2.0.''
==Specification: Transport Protocols==
It is possible to send JSON-RPC messages over different transport protocols, like TCP and HTTP. It is also possible to protect these protocols with SSL/TLS.
TODO:
* Websocket
* Websocket over SSL/TLS
* HTTP
* HTTP over SSL/TLS
===TCP===
Stratum over a TCP connection. Every JSON-RPC message is send on a single line, ending with a line-feed (\n). Line-feeds inside the JSON should be encoded as usual. Both client and server can initiate a request on which the other side could respond with a result or an error.
Stratum over a TCP connection. Every JSON-RPC message is send on a single line, ending with a line-feed (<code>\n</code>). Line-feeds inside the JSON should be encoded as usual. Both client and server can initiate a request on which the other side could respond with a result or an error.
Default port: 50001
===TCP over SSL/TLS===
Stratum over a TCP connection with SSL/TLS. Just the same as TCP, but with SSL/TLS enabled.
Stratum over a TCP connection with SSL/TLS. Just the same as normal TCP, but with SSL/TLS enabled.
Default port: 50002
===HTTP===
Stratum over an HTTP connection.
===HTTP over SSL/TLS===
Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but with SSL/TLS enabled.
===WebSocket===
Stratum over a WebSocket connection.
===WebSocket over SSL/TLS===
Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSocket, but with SSL/TLS enabled.
==Specification: Commands==