From 47ca202e1f9d9d31a4e4b807f8dbb5584038a663 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 7 Mar 2024 16:26:28 +0100 Subject: [PATCH 01/32] Write initial draft of BIP 40 --- README.mediawiki | 6 ++--- bip-0040.mediawiki | 65 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+), 3 deletions(-) create mode 100644 bip-0040.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 43e60a4093..8616edb6b0 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -210,12 +210,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Proposed |- -| 40 +| [[bip-0040.mediawiki|40]] | API/RPC | Stratum wire protocol -| Marek Palatinus +| Marek Palatinus, Ben van Hartingsveldt | Standard -| BIP number allocated +| Draft |- | 41 | API/RPC diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki new file mode 100644 index 0000000000..fb09b66ce4 --- /dev/null +++ b/bip-0040.mediawiki @@ -0,0 +1,65 @@ +
+  BIP: 40
+  Layer: Applications
+  Title: Stratum wire protocol
+  Author: Marek Palatinus 
+          Ben van Hartingsveldt 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0040
+  Status: Draft
+  Type: Standards Track
+  Created: 2024-03-07
+  License: PD
+
+ +==Abstract== + +This document describes the Stratum wire protocol used in clients such as Electrum, and which also laid the foundation for the Stratum mining protocol, used in many Bitcoin pools. + +The specification is intended to set a standard for connections between clients and servers in which the client is able to request data without having to download the full blockchain. + +The specification consists of three parts. In the first part, the data format is defined. In the second part, the possible transport protocols (including encapsulation) are described. In the third part, the available methods are documented. + +==Motivation== + +Many clients want to give users access to the Bitcoin ecosystem. However, for specific reasons not every user is able to download the full blockchain to their machine. + +The Stratum wire protocol defines a way to access the blockchain without having it downloaded. For example, a client can request both the genesis block and the latest block with the same latency, because the server does synchronize and index all blocks for us. + +==History== + +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]]. + +==Specification: Data Format== + +Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed. Rules of that version apply accordingly. + +Additionally, it is a convention to give all Stratum methods in the `method` property a name in the following form: `.`, where `` is allowed to have dots and `` isn't. For example, the the value `blockchain.block.subscribe`. + +Note: In JSON-RPC 1.0, the `param` 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 `params` 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. + +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. + +==Specification: Commands== + +TODO \ No newline at end of file From 914fb7c40cc0f34cf78b123c2be97a724bc8fe7f Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 7 Mar 2024 16:38:43 +0100 Subject: [PATCH 02/32] Fix inline code --- bip-0040.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index fb09b66ce4..8afbefe07f 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -36,9 +36,9 @@ Later in 2012, Marek Palatinus introduced Stratum also for mining pools: The Str Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed. Rules of that version apply accordingly. -Additionally, it is a convention to give all Stratum methods in the `method` property a name in the following form: `.`, where `` is allowed to have dots and `` isn't. For example, the the value `blockchain.block.subscribe`. +Additionally, it is a convention to give all Stratum methods in the method property a name in the following form: ., where is allowed to have dots and isn't. For example, the the value blockchain.block.subscribe. -Note: In JSON-RPC 1.0, the `param` 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 `params` 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 param 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 params 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== From 72bfc4d01bdd6c9336843effe458c254bd97bd37 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 7 Mar 2024 18:28:42 +0100 Subject: [PATCH 03/32] Allow public domain --- scripts/buildtable.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl index 292f1ee5b0..7442e9b938 100755 --- a/scripts/buildtable.pl +++ b/scripts/buildtable.pl @@ -87,7 +87,7 @@ 'OPL' => undef, 'PD' => undef, ); -my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152); +my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 40 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152); my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121); my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173 327); From abe08e4b5f82e8cb63cbb2b957566f2ea03771f8 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 7 Mar 2024 21:52:29 +0100 Subject: [PATCH 04/32] Improve specification of transport protocols --- bip-0040.mediawiki | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 8afbefe07f..ba182edeb0 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -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 method property a name in the following form: ., where is allowed to have dots and isn't. For example, the the value blockchain.block.subscribe. -Note: In JSON-RPC 1.0, the param 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 params 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 param 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 params 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 (\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. 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== From a5aee5bd6c5187be2cc5792212ddc2a61594fa4c Mon Sep 17 00:00:00 2001 From: Ben Date: Tue, 19 Mar 2024 09:58:44 +0100 Subject: [PATCH 05/32] Add letters and default ports --- bip-0040.mediawiki | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index ba182edeb0..73511337c6 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -48,22 +48,30 @@ It is possible to send JSON-RPC messages over different transport protocols, lik 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. -Default port: 50001 +* Default port: 50001 +* Letter: t ===TCP over SSL/TLS=== Stratum over a TCP connection with SSL/TLS. Just the same as normal TCP, but with SSL/TLS enabled. -Default port: 50002 +* Default port: 50002 +* Letter: s ===HTTP=== Stratum over an HTTP connection. +* Default port: 8081 +* Letter: h + ===HTTP over SSL/TLS=== Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but with SSL/TLS enabled. +* Default port: 8082 +* Letter: g + ===WebSocket=== Stratum over a WebSocket connection. From 8658be8faaceec8bb7fc9a917bf29553e2dd8799 Mon Sep 17 00:00:00 2001 From: Ben Date: Tue, 19 Mar 2024 11:14:46 +0100 Subject: [PATCH 06/32] Add more information about WebSockets --- bip-0040.mediawiki | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 73511337c6..7167078e55 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -46,7 +46,7 @@ It is possible to send JSON-RPC messages over different transport protocols, lik ===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 (including batch messages) is send on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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 * Letter: t @@ -74,12 +74,21 @@ Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but ===WebSocket=== -Stratum over a WebSocket connection. +Stratum over a WebSocket connection. Every JSON-RPC message (including batch messages) is sent encapsulated in a WebSocket message and therefore line-feeds are not needed. Still, 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: 8083This is extended specification information of the Stratum protocol to make it more complete. This information will not be found in any code or specification before this BIP. +* Letter: w ===WebSocket over SSL/TLS=== Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSocket, but with SSL/TLS enabled. +* Default port: 8084 +* Letter: u + ==Specification: Commands== -TODO \ No newline at end of file +TODO + +==References== + \ No newline at end of file From e13def41e5cfd73346dbd451d135250a1e744662 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 10:46:56 +0100 Subject: [PATCH 07/32] Add information about WebSocket subprotocol --- bip-0040.mediawiki | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 7167078e55..326cc8cd2c 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -76,9 +76,21 @@ Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but Stratum over a WebSocket connection. Every JSON-RPC message (including batch messages) is sent encapsulated in a WebSocket message and therefore line-feeds are not needed. Still, 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: 8083This is extended specification information of the Stratum protocol to make it more complete. This information will not be found in any code or specification before this BIP. +* Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP. * Letter: w +====Subprotocol==== + +In a WebSocket upgrade request, it is possible to use the Sec-WebSocket-Protocol header to let the WebSocket server know which subprotocol is desired to send over the connection. For Stratum, the value stratum is registered. The use of this header is optional. If the server supports the use of this subprotocol too, it will let the client know by sending a Sec-WebSocket-Protocol header back. If the server doesn't send a subprotocol back, the connection will continue without using one. Use of this feature is fully backwards compatible. + +====Example==== + + +new WebSocket('ws://stratum.example.com:8083',['stratum']); // Open WebSocket with using a subprotocol + +new WebSocket('ws://stratum.example.com:8083'); // Open WebSocket without using a subprotocol + + ===WebSocket over SSL/TLS=== Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSocket, but with SSL/TLS enabled. From e2807713e036f8604de3ed580734c0da98f814bf Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 12:01:45 +0100 Subject: [PATCH 08/32] Add information about HTTP polling --- bip-0040.mediawiki | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 326cc8cd2c..b6ee573a6b 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -60,11 +60,25 @@ Stratum over a TCP connection with SSL/TLS. Just the same as normal TCP, but wit ===HTTP=== -Stratum over an HTTP connection. +Stratum over an HTTP connection. When communicating over HTTP, there 2 possible options: polling and pushing. In both cases, the request and response have a Content-Type header with the value application/stratum. Like in the TCP transport, the messages have to end with a line-feed (\n). It is possible to send more messages in one HTTP request or response. It could be possible that a request or response also has a Content-MD5 header, so it is possible for the receiver to detect any modifications to the content. It is up to clients and servers how to handle upon a mismatch. A suggestion for a client would be to retry the command. A suggestion for a server would be to return a 400 error (or return a 200 error with a JSON-RPC error message). * Default port: 8081 * Letter: h +====Session==== + +Because it is not sure if an HTTP connection will stay open, it is highly possible that messages will be sent over multiple connections. To keep track of the same "session", cookies are used. If a client sends a request with a cookie, the servers knows exactly which session is used and which notifications to send. + +====HTTP Poll==== + +When polling, an empty HTTP POST request is sent with application/stratum in the Content-Type header. + +If no error occurred, the server will respond with a 200 status code and with application/stratum in the Content-Type header. If there are one or more notifications, the body will contain those notifications. Else, the body will be empty. + +====HTTP Push==== + +TODO + ===HTTP over SSL/TLS=== Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but with SSL/TLS enabled. @@ -79,17 +93,19 @@ Stratum over a WebSocket connection. Every JSON-RPC message (including batch mes * Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP. * Letter: w -====Subprotocol==== +====Subprotocol==== In a WebSocket upgrade request, it is possible to use the Sec-WebSocket-Protocol header to let the WebSocket server know which subprotocol is desired to send over the connection. For Stratum, the value stratum is registered. The use of this header is optional. If the server supports the use of this subprotocol too, it will let the client know by sending a Sec-WebSocket-Protocol header back. If the server doesn't send a subprotocol back, the connection will continue without using one. Use of this feature is fully backwards compatible. ====Example==== - -new WebSocket('ws://stratum.example.com:8083',['stratum']); // Open WebSocket with using a subprotocol +
+  // Open WebSocket with using a subprotocol
+  new WebSocket('ws://stratum.example.com:8083',['stratum']);
 
-new WebSocket('ws://stratum.example.com:8083'); // Open WebSocket without using a subprotocol
-
+  // Open WebSocket without using a subprotocol
+  new WebSocket('ws://stratum.example.com:8083');
+
===WebSocket over SSL/TLS=== From 83647b1b208be0dd7f782c20fd53b1ff4b67c797 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 14:09:36 +0100 Subject: [PATCH 09/32] Improve text --- bip-0040.mediawiki | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index b6ee573a6b..cdeb1f3b5b 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -60,7 +60,9 @@ Stratum over a TCP connection with SSL/TLS. Just the same as normal TCP, but wit ===HTTP=== -Stratum over an HTTP connection. When communicating over HTTP, there 2 possible options: polling and pushing. In both cases, the request and response have a Content-Type header with the value application/stratum. Like in the TCP transport, the messages have to end with a line-feed (\n). It is possible to send more messages in one HTTP request or response. It could be possible that a request or response also has a Content-MD5 header, so it is possible for the receiver to detect any modifications to the content. It is up to clients and servers how to handle upon a mismatch. A suggestion for a client would be to retry the command. A suggestion for a server would be to return a 400 error (or return a 200 error with a JSON-RPC error message). +Stratum over an HTTP connection. When communicating over HTTP, there 2 possible options: polling and pushing. In both cases, the request and response have a Content-Type header with the value application/stratum. Like in the TCP transport, the messages have to end with a line-feed (\n). It is possible to send more messages in one HTTP request or response. + +It could be possible that a request or response also has a Content-MD5 header, so it is possible for the receiver to detect any modifications to the content. It is up to clients and servers how to handle upon a mismatch. A suggestion for a client would be to retry the command. A suggestion for a server would be to return a 400 error (or return a 200 error with a JSON-RPC error message). * Default port: 8081 * Letter: h @@ -71,9 +73,9 @@ Because it is not sure if an HTTP connection will stay open, it is highly possib ====HTTP Poll==== -When polling, an empty HTTP POST request is sent with application/stratum in the Content-Type header. +When polling, an HTTP POST request is sent with application/stratum in the Content-Type header. In the body, there could be one or more messages. If the body is empty, the client just wants to check for notifications. -If no error occurred, the server will respond with a 200 status code and with application/stratum in the Content-Type header. If there are one or more notifications, the body will contain those notifications. Else, the body will be empty. +If no error occurred, the server will respond with a 200 status code and with application/stratum in the Content-Type header. If there are one or more notifications or other messages, the body will contain those messages. Else, the body will be empty. ====HTTP Push==== @@ -88,7 +90,7 @@ Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but ===WebSocket=== -Stratum over a WebSocket connection. Every JSON-RPC message (including batch messages) is sent encapsulated in a WebSocket message and therefore line-feeds are not needed. Still, 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 WebSocket connection. When using WebSockets the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send more JSON-RPC messages in one WebSocket message. Every JSON-RPC message should and with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP. * Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP. * Letter: w From 3d217b09b89b6151aadf130d11d1758f4a060d77 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 14:30:06 +0100 Subject: [PATCH 10/32] Add note --- bip-0040.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index cdeb1f3b5b..475a9c5072 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -44,6 +44,8 @@ Additionally, it is a convention to give all Stratum methods in the method 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. +''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to support all coins ever listed in SLIP-44. For IPv4, you need all IPv4 addresses that exist, even the invalid ones, so a suggestion is to only use the server only for coins you really need.'' + ===TCP=== Stratum over a TCP connection. Every JSON-RPC message (including batch messages) is send on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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. @@ -90,7 +92,7 @@ Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but ===WebSocket=== -Stratum over a WebSocket connection. When using WebSockets the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send more JSON-RPC messages in one WebSocket message. Every JSON-RPC message should and with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP. +Stratum over a WebSocket connection. When using WebSockets, the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send more JSON-RPC messages in one WebSocket message. Every JSON-RPC message should end with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP. * Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP. * Letter: w From c82a2a11b7ef1a8eb06bf5b8b87097812848609b Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 17:07:05 +0100 Subject: [PATCH 11/32] Add information about HTTP Push --- bip-0040.mediawiki | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 475a9c5072..37525ea001 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -44,7 +44,7 @@ Additionally, it is a convention to give all Stratum methods in the method 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. -''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to support all coins ever listed in SLIP-44. For IPv4, you need all IPv4 addresses that exist, even the invalid ones, so a suggestion is to only use the server only for coins you really need.'' +''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to hypothetically support all coins ever listed in SLIP-44. For IPv4, you would need all IPv4 addresses that exist to do the same, even the invalid ones, so a suggestion is to only use the server only for coins you really need. Also, other ports could possibly be used and in that case, a /16 IP block with all 65536 TCP ports in use will be enough to support all coins. However, because using non-standard ports is not user-friendly, this is also not recommended.'' ===TCP=== @@ -71,7 +71,9 @@ It could be possible that a request or response also has a Content-MD5STRATUM_SESSION is used. If a client sends a request with a cookie, the servers knows exactly which session is used and which notifications to send. + +Servers could send the Stratum-Session-Timeout header to tell the client when a session with the same session id will be seen as a new session by the server. The header contains a number that indicates how many seconds are left. This is different from Expires or Max-Age parameters of the Set-Cookie header, that indicate when a cookie (not necessarily a session) should have been expired by the client. For backwards compatibility, a X-Session-Timeout header with the same value should be sent in those requests too. ====HTTP Poll==== @@ -81,7 +83,9 @@ If no error occurred, the server will respond with a 200 status code and with Stratum-Callback-URL header. This will let the server send notifications using the callback URL without the client needing to send HTTP poll requests in with a very small interval. To disable HTTP Push mode, a regular HTTP poll request should be sent with an additional empty Stratum-Callback-URL header. For backwards compatibility, a X-Callback-URL header with the same value should be sent in those requests too. + +The callback URL will be called when there are notifications. This request is an HTTP POST request with a Content-Type header and a Stratum-Session-ID header. The Stratum-Session-ID contains the same id as the STRATUM_SESSION cookie. This makes it possible to use the callback URL for multiple sessions. The response is of the callback URL is expected to be empty, so any response body will likely be ignored. For backwards compatibility, a X-Session-ID header with the same value should be sent in those requests too. ===HTTP over SSL/TLS=== From 805559f695e209644145014124a9c8c38411fdfb Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 21:15:06 +0100 Subject: [PATCH 12/32] Add two methods --- bip-0040.mediawiki | 44 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 37525ea001..0acd3be426 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -73,7 +73,7 @@ It could be possible that a request or response also has a Content-MD5STRATUM_SESSION is used. If a client sends a request with a cookie, the servers knows exactly which session is used and which notifications to send. -Servers could send the Stratum-Session-Timeout header to tell the client when a session with the same session id will be seen as a new session by the server. The header contains a number that indicates how many seconds are left. This is different from Expires or Max-Age parameters of the Set-Cookie header, that indicate when a cookie (not necessarily a session) should have been expired by the client. For backwards compatibility, a X-Session-Timeout header with the same value should be sent in those requests too. +Servers could send the Stratum-Session-Timeout header to tell the client when a session with the same session id will be seen as a new session by the server. The header contains a number that indicates how many seconds are left. This is different from Expires or Max-Age parameters of the Set-Cookie header, that indicate when a cookie (not necessarily a session) should have been expired by the client. For backwards compatibility, a X-Session-Timeout header with the same value should be sent in those requests too. ====HTTP Poll==== @@ -83,9 +83,9 @@ If no error occurred, the server will respond with a 200 status code and with Stratum-Callback-URL header. This will let the server send notifications using the callback URL without the client needing to send HTTP poll requests in with a very small interval. To disable HTTP Push mode, a regular HTTP poll request should be sent with an additional empty Stratum-Callback-URL header. For backwards compatibility, a X-Callback-URL header with the same value should be sent in those requests too. +HTTP Poll is the default mode when connecting with a server over HTTP. To get the session in HTTP Push mode, a client should send a regular HTTP Poll request with an additional Stratum-Callback-URL header. This will let the server send notifications using the callback URL without the client needing to send HTTP poll requests in with a very small interval. To disable HTTP Push mode, a regular HTTP poll request should be sent with an additional empty Stratum-Callback-URL header. For backwards compatibility, a X-Callback-URL header with the same value should be sent in those requests too. -The callback URL will be called when there are notifications. This request is an HTTP POST request with a Content-Type header and a Stratum-Session-ID header. The Stratum-Session-ID contains the same id as the STRATUM_SESSION cookie. This makes it possible to use the callback URL for multiple sessions. The response is of the callback URL is expected to be empty, so any response body will likely be ignored. For backwards compatibility, a X-Session-ID header with the same value should be sent in those requests too. +The callback URL will be called when there are notifications. This request is an HTTP POST request with a Content-Type header and a Stratum-Session-ID header. The Stratum-Session-ID contains the same id as the STRATUM_SESSION cookie. This makes it possible to use the callback URL for multiple sessions. The response is of the callback URL is expected to be empty, so any response body will likely be ignored. For backwards compatibility, a X-Session-ID header with the same value should be sent in those requests too. ===HTTP over SSL/TLS=== @@ -124,7 +124,43 @@ Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSoc ==Specification: Commands== -TODO +===Service: Blockchain Address=== + +* Service name: blockchain.address + +====Method: Get History==== + +* Method name: get_history + +{| +! +! Name +! Value +|- +! Method +| colspan="2" | blockchain.address.get_history +|- +! Param [0] +| +| +|} + +====Method: Subscribe==== + +* Method name: subscribe + +{| +! +! Name +! Value +|- +! Method +| colspan="2" | blockchain.address.subscribe +|- +! Param [0] +| +| +|} ==References== \ No newline at end of file From ec52ae132126fe6ba8b33d94cf3f835dd1964084 Mon Sep 17 00:00:00 2001 From: Ben Date: Thu, 21 Mar 2024 22:35:25 +0100 Subject: [PATCH 13/32] Improve commands --- bip-0040.mediawiki | 93 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 81 insertions(+), 12 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 0acd3be426..f58c322217 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -133,16 +133,28 @@ Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSoc * Method name: get_history {| -! -! Name -! Value +! [Request] +! Type +! Example +! Description |- ! Method -| colspan="2" | blockchain.address.get_history +| colspan="3" | blockchain.address.get_history |- ! Param [0] -| -| +| string +| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L +| The address to get the history of. +|- +! [Response] +! Type +! Example +! Description +|- +! Result +| array +| +| The history of the a blockchain address. |} ====Method: Subscribe==== @@ -150,16 +162,73 @@ Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSoc * Method name: subscribe {| -! -! Name -! Value +! [Request] +! Type +! Example +! Description |- ! Method -| colspan="2" | blockchain.address.subscribe +| colspan="3" | blockchain.address.subscribe |- ! Param [0] -| -| +| string +| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L +| The address to subscribe to. +|} + +===Service: Client=== + +* Service name: client + +====Method: Version==== + +Send the version of the client to the server. This command doesn't expect a response. + +* Method name: version + +{| +! [Request] +! Type +! Example +! Description +|- +! Method +| colspan="3" | client.version +|- +! Params [0] +| string +| 0.41 +| The client version. +|} + +===Service: Server=== + +* Service name: server + +====Method: Banner==== + +A command to get the server banner. + +* Method name: banner + +{| +! [Request] +! Type +! Example +! Description +|- +! Method +| colspan="3" | server.banner +|- +! [Response] +! Type +! Example +! Description +|- +! Result +| string +| Welcome to Electrum! +| The server banner. |} ==References== From 84f851926e5085f10cae777219621f2c13059374 Mon Sep 17 00:00:00 2001 From: Ben van Hartingsveldt Date: Mon, 6 May 2024 23:26:45 +0200 Subject: [PATCH 14/32] Process editorial feedback --- bip-0040.mediawiki | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index f58c322217..2976329d3c 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -24,47 +24,47 @@ The specification consists of three parts. In the first part, the data format is Many clients want to give users access to the Bitcoin ecosystem. However, for specific reasons not every user is able to download the full blockchain to their machine. -The Stratum wire protocol defines a way to access the blockchain without having it downloaded. For example, a client can request both the genesis block and the latest block with the same latency, because the server does synchronize and index all blocks for us. +The Stratum wire protocol defines a way to access the blockchain without having it downloaded. For example, a client can request both the genesis block and the latest block with the same latency, because the server synchronizes and indexes all the blocks for us. ==History== -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. +The Stratum wire protocol was introduced by Marek Palatinus in late 2011 and early 2012. It was a language-independent alternative to the Python-based protocol in early versions of Electrum, created by Thomas Voegtlin. The Stratum wire protocol made it possible to create compatible servers that 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-0041.mediawiki|BIP 41]]. +Later in 2012, Marek Palatinus introduced Stratum for mining pools as well: The Stratum mining protocol, as defined in [[bip-0041.mediawiki|BIP 41]]. ==Specification: Data Format== -Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed. Rules of that version apply accordingly. +Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed, according to their respective rules. -Additionally, it is a convention to give all Stratum methods in the method property a name in the following form: ., where is allowed to have dots and isn't. For example, the the value blockchain.block.subscribe. +Additionally, it is a convention to give all Stratum methods in the method property a name in the following form: ., where is allowed to have dots and isn't. For example, the value blockchain.block.subscribe. -''Note: In JSON-RPC 1.0, the param 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 params 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 param property is an array, so everything should be passed in the right order. In JSON-RPC 2.0, named parameters are also allowed. In that case, only the parameter names that are documented should be used; otherwise, the method can fail. It is maybe also possible that a specific method (or server) only supports params as an array, because it doesn't know how to handle named params, 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. -''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to hypothetically support all coins ever listed in SLIP-44. For IPv4, you would need all IPv4 addresses that exist to do the same, even the invalid ones, so a suggestion is to only use the server only for coins you really need. Also, other ports could possibly be used and in that case, a /16 IP block with all 65536 TCP ports in use will be enough to support all coins. However, because using non-standard ports is not user-friendly, this is also not recommended.'' +''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to hypothetically support all coins ever listed in SLIP-44. For IPv4, you would need all IPv4 addresses that exist to do the same, even the invalid ones, so a suggestion is to only use the server for coins you really need. Also, other ports could possibly be used, and in that case, a /16 IP block with all 65536 TCP ports in use will be enough to support all coins. However, because using non-standard ports is not user-friendly, this is also not recommended.'' ===TCP=== -Stratum over a TCP connection. Every JSON-RPC message (including batch messages) is send on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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 (including batch messages) is sent on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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 * Letter: t ===TCP over SSL/TLS=== -Stratum over a TCP connection with SSL/TLS. Just the same as normal TCP, but with SSL/TLS enabled. +Stratum over a TCP connection with SSL/TLS: the same as normal TCP, but with SSL/TLS enabled. * Default port: 50002 * Letter: s ===HTTP=== -Stratum over an HTTP connection. When communicating over HTTP, there 2 possible options: polling and pushing. In both cases, the request and response have a Content-Type header with the value application/stratum. Like in the TCP transport, the messages have to end with a line-feed (\n). It is possible to send more messages in one HTTP request or response. +Stratum over an HTTP connection. When communicating over HTTP, there 2 possible options: polling and pushing. In both cases, the request and response have a Content-Type header with the value application/stratum. Like in the TCP transport, the messages have to end with a line-feed (\n). It is possible to send multiple messages in one HTTP request or response. -It could be possible that a request or response also has a Content-MD5 header, so it is possible for the receiver to detect any modifications to the content. It is up to clients and servers how to handle upon a mismatch. A suggestion for a client would be to retry the command. A suggestion for a server would be to return a 400 error (or return a 200 error with a JSON-RPC error message). +A request or response may contain a Content-MD5 header to allow the receiver to detect any modification to the content. It is up to clients and servers how to handle a mismatch. A suggestion for a client would be to retry the command. A suggestion for a server would be to return a 400 error (or return a 200 error with a JSON-RPC error message). * Default port: 8081 * Letter: h @@ -73,30 +73,30 @@ It could be possible that a request or response also has a Content-MD5STRATUM_SESSION is used. If a client sends a request with a cookie, the servers knows exactly which session is used and which notifications to send. -Servers could send the Stratum-Session-Timeout header to tell the client when a session with the same session id will be seen as a new session by the server. The header contains a number that indicates how many seconds are left. This is different from Expires or Max-Age parameters of the Set-Cookie header, that indicate when a cookie (not necessarily a session) should have been expired by the client. For backwards compatibility, a X-Session-Timeout header with the same value should be sent in those requests too. +Servers could send the Stratum-Session-Timeout header to tell the client when a session with the same session id will be seen as a new session by the server. The header contains a number that indicates how many seconds are left. This is different from Expires or Max-Age parameters of the Set-Cookie header that indicate when a cookie (not necessarily a session) should have been expired by the client. For backwards compatibility, a X-Session-Timeout header with the same value should be sent in those requests, too. ====HTTP Poll==== -When polling, an HTTP POST request is sent with application/stratum in the Content-Type header. In the body, there could be one or more messages. If the body is empty, the client just wants to check for notifications. +When polling, an HTTP POST request is sent with application/stratum in the Content-Type header. In the body, there could be one or more messages. If the body is empty, the client only wants to check for notifications. -If no error occurred, the server will respond with a 200 status code and with application/stratum in the Content-Type header. If there are one or more notifications or other messages, the body will contain those messages. Else, the body will be empty. +If no error occurred, the server will respond with a 200 status code and with application/stratum in the Content-Type header. If there are one or more notifications or other messages, the body will contain those messages. Otherwise, the body will be empty. ====HTTP Push==== -HTTP Poll is the default mode when connecting with a server over HTTP. To get the session in HTTP Push mode, a client should send a regular HTTP Poll request with an additional Stratum-Callback-URL header. This will let the server send notifications using the callback URL without the client needing to send HTTP poll requests in with a very small interval. To disable HTTP Push mode, a regular HTTP poll request should be sent with an additional empty Stratum-Callback-URL header. For backwards compatibility, a X-Callback-URL header with the same value should be sent in those requests too. +HTTP Poll is the default mode when connecting with a server over HTTP. To get the session in HTTP Push mode, a client should send a regular HTTP Poll request with an additional Stratum-Callback-URL header. This will let the server send notifications using the callback URL without the client needing to send HTTP poll requests with a very small interval. To disable HTTP Push mode, a regular HTTP poll request should be sent with an additional empty Stratum-Callback-URL header. For backwards compatibility, a X-Callback-URL header with the same value should be sent in those requests too. -The callback URL will be called when there are notifications. This request is an HTTP POST request with a Content-Type header and a Stratum-Session-ID header. The Stratum-Session-ID contains the same id as the STRATUM_SESSION cookie. This makes it possible to use the callback URL for multiple sessions. The response is of the callback URL is expected to be empty, so any response body will likely be ignored. For backwards compatibility, a X-Session-ID header with the same value should be sent in those requests too. +The callback URL will be called when there are notifications. This request is an HTTP POST request with a Content-Type header and a Stratum-Session-ID header. The Stratum-Session-ID contains the same id as the STRATUM_SESSION cookie. This makes it possible to use the callback URL for multiple sessions. The response of the callback URL is expected to be empty, so any response body will likely be ignored. For backwards compatibility, a X-Session-ID header with the same value should be sent in those requests too. ===HTTP over SSL/TLS=== -Stratum over an HTTP connection with SSL/TLS. Just the same as normal HTTP, but with SSL/TLS enabled. +Stratum over an HTTP connection with SSL/TLS: the same as normal HTTP, but with SSL/TLS enabled. * Default port: 8082 * Letter: g ===WebSocket=== -Stratum over a WebSocket connection. When using WebSockets, the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send more JSON-RPC messages in one WebSocket message. Every JSON-RPC message should end with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP. +Stratum over a WebSocket connection. When using WebSockets, the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send multiple JSON-RPC messages in one WebSocket message. Every JSON-RPC message should end with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP. * Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP. * Letter: w @@ -117,7 +117,7 @@ In a WebSocket upgrade request, it is possible to use the Sec-WebSocket-Pr ===WebSocket over SSL/TLS=== -Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSocket, but with SSL/TLS enabled. +Stratum over a WebSocket connection with SSL/TLS: the same as normal WebSocket, but with SSL/TLS enabled. * Default port: 8084 * Letter: u @@ -154,7 +154,7 @@ Stratum over a WebSocket connection with SSL/TLS. Just the same as normal WebSoc ! Result | array | -| The history of the a blockchain address. +| The history of the blockchain address. |} ====Method: Subscribe==== From 0cdfcb5d2edd36874512ecd70032faf2530fdba7 Mon Sep 17 00:00:00 2001 From: Ben van Hartingsveldt Date: Mon, 6 May 2024 23:58:14 +0200 Subject: [PATCH 15/32] Add IANA considerations --- bip-0040.mediawiki | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 2976329d3c..3364414386 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -231,5 +231,19 @@ A command to get the server banner. | The server banner. |} +==IANA Considerations== + +===Media Type Registration=== + +IANA maintains the registry of Media Types [BCP13] at . + +This document serves as the specification for the media type "application/stratum". It has been registered with IANA. + +===WebSocket Subprotocol=== + +IANA maintains the registry of WebSocket Subprotocol Names at . + +This document serves as the specification for the subprotocol "stratum". It has been registered with IANA. + ==References== \ No newline at end of file From 19a39e2e5be2c684ee64fe201049a3d108c212d9 Mon Sep 17 00:00:00 2001 From: Ben van Hartingsveldt Date: Tue, 7 May 2024 00:07:40 +0200 Subject: [PATCH 16/32] Fix links --- bip-0040.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index 3364414386..cfd2b4cc0a 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -235,13 +235,13 @@ A command to get the server banner. ===Media Type Registration=== -IANA maintains the registry of Media Types [BCP13] at . +IANA maintains the registry of Media Types [https://www.rfc-editor.org/info/bcp13 BCP13] at http://www.iana.org/assignments/media-types. This document serves as the specification for the media type "application/stratum". It has been registered with IANA. ===WebSocket Subprotocol=== -IANA maintains the registry of WebSocket Subprotocol Names at . +IANA maintains the registry of WebSocket Subprotocol Names at https://www.iana.org/assignments/websocket. This document serves as the specification for the subprotocol "stratum". It has been registered with IANA. From 1cf59837c73025cd7dc68e3d09e63b56c868eff4 Mon Sep 17 00:00:00 2001 From: Ben van Hartingsveldt Date: Tue, 7 May 2024 00:46:54 +0200 Subject: [PATCH 17/32] Add information about service vendor --- bip-0040.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index cfd2b4cc0a..dd8c6fd4f3 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -36,7 +36,9 @@ Later in 2012, Marek Palatinus introduced Stratum for mining pools as well: The Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed, according to their respective rules. -Additionally, it is a convention to give all Stratum methods in the method property a name in the following form: ., where is allowed to have dots and isn't. For example, the value blockchain.block.subscribe. +Additionally, it is a convention to give all Stratum methods in the method property a name that meets the following EBNF notation: method ::= serviceType ("[" serviceVendor "]")? "." methodName, where serviceType and serviceVendor allowed to have dots and methodName isn't. For example, the values blockchain.block.subscribe and blockchain.block[Electrum].subscribe. + +The service vendor is optional. However, multiple vendors can define the same service type, so the service vendor is introduced to distinguish them. If the service vendor is absent, the default service type is executed. ''Note: In JSON-RPC 1.0, the param property is an array, so everything should be passed in the right order. In JSON-RPC 2.0, named parameters are also allowed. In that case, only the parameter names that are documented should be used; otherwise, the method can fail. It is maybe also possible that a specific method (or server) only supports params as an array, because it doesn't know how to handle named params, even if it supports JSON-RPC 2.0.'' From 2f620f54ecf29a30924002e0448916d1eef97b11 Mon Sep 17 00:00:00 2001 From: Ben van Hartingsveldt Date: Tue, 7 May 2024 01:10:27 +0200 Subject: [PATCH 18/32] Fix layer --- bip-0040.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki index dd8c6fd4f3..a4dc9b11b4 100644 --- a/bip-0040.mediawiki +++ b/bip-0040.mediawiki @@ -1,6 +1,6 @@ 
   BIP: 40
-  Layer: Applications
+  Layer: API/RPC
   Title: Stratum wire protocol
   Author: Marek Palatinus 
           Ben van Hartingsveldt 
@@ -36,7 +36,7 @@ Later in 2012, Marek Palatinus introduced Stratum for mining pools as well: The
 
 Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed, according to their respective rules.
 
-Additionally, it is a convention to give all Stratum methods in the method property a name that meets the following EBNF notation: method ::= serviceType ("[" serviceVendor "]")? "." methodName, where serviceType and serviceVendor allowed to have dots and methodName isn't. For example, the values blockchain.block.subscribe and blockchain.block[Electrum].subscribe.
+Additionally, it is a convention to give all Stratum methods in the method property a name that meets the following EBNF notation: method ::= serviceType ("[" serviceVendor "]")? "." methodName, where serviceType and serviceVendor are allowed to have dots and methodName isn't. For example, the values blockchain.block.subscribe and blockchain.block[Electrum].subscribe.
 
 The service vendor is optional. However, multiple vendors can define the same service type, so the service vendor is introduced to distinguish them. If the service vendor is absent, the default service type is executed.
 
@@ -235,17 +235,17 @@ A command to get the server banner.
 
 ==IANA Considerations==
 
-===Media Type Registration===
+===Media Type===
 
 IANA maintains the registry of Media Types [https://www.rfc-editor.org/info/bcp13 BCP13] at http://www.iana.org/assignments/media-types.
 
 This document serves as the specification for the media type "application/stratum". It has been registered with IANA.
 
-===WebSocket Subprotocol===
+===WebSocket Subprotocol Name===
 
 IANA maintains the registry of WebSocket Subprotocol Names at https://www.iana.org/assignments/websocket.
 
-This document serves as the specification for the subprotocol "stratum". It has been registered with IANA.
+This document serves as the specification for the subprotocol name "stratum". It has been registered with IANA.
 
 ==References==
 
\ No newline at end of file

From b5a9b1021646852b1f836a6d74eb4609ca563b70 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Fri, 10 May 2024 21:40:08 +0200
Subject: [PATCH 19/32] Add IANA consideration for HTTP fields

---
 bip-0040.mediawiki | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index a4dc9b11b4..5a06bb6441 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -235,6 +235,12 @@ A command to get the server banner.
 
 ==IANA Considerations==
 
+===HTTP Field===
+
+IANA maintains the registry of HTTP Fields at https://www.iana.org/assignments/http-fields.
+
+This document serves as the specification for the HTTP fields "Stratum-Session-ID", "Stratum-Session-Timeout" and "Stratum-Callback-URL".
+
 ===Media Type===
 
 IANA maintains the registry of Media Types [https://www.rfc-editor.org/info/bcp13 BCP13] at http://www.iana.org/assignments/media-types.

From 19cf44793911807b284c910048a992b553649db5 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Fri, 10 May 2024 22:33:23 +0200
Subject: [PATCH 20/32] Add example commands

---
 bip-0040.mediawiki | 109 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 108 insertions(+), 1 deletion(-)

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index 5a06bb6441..2179d8362b 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -203,6 +203,113 @@ Send the version of the client to the server. This command doesn't expect a resp
 | The client version.
 |}
 
+===Service: Example===
+
+This service is an example service. It doesn't have any other purpose than testing.
+
+* Service name: example
+* Service vendor: Stratum
+
+====Method: Hello World====
+
+Ask the server to send a "Hello world!" back.
+
+* Method name: hello_world
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.hello_world
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Hello world!
+| The "Hello world" text.
+|}
+
+====Method: Ping====
+
+Ping the server and get a pong back with the same text.
+
+* Method name: ping
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.ping
+|-
+! Params [0] (payload)
+| mixed
+| 12345678
+| The ping text.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Hello world!
+| The "Hello world" text.
+|}
+
+====Method: Synchronous====
+
+Ask the server to run a synchronous command for a specific amount of seconds.
+
+* Method name: synchronous
+
+====Method: Throw Exception====
+
+Ask the server throw exception.
+
+* Method name: throw_exception
+
+====Method: Throw Signed Exception====
+
+Ask the server throw signed exception.
+
+* Method name: throw_signed_exception
+
+===Service: Example Publish-Subscribe===
+
+This service is an example service. It doesn't have any other purpose than testing.
+
+* Service name: example.pubsub
+* Service vendor: Stratum
+
+====Method: Subscribe====
+
+Subscribe on an event.
+
+* Method name: subscribe
+
+====Method: Time Event====
+
+The time event that gets emitted.
+
+* Method name: time_event
+
+====Method: Unsubscribe====
+
+Unsubscribe from an event.
+
+* Method name: unsubscribe
+
 ===Service: Server===
 
 * Service name: server
@@ -251,7 +358,7 @@ This document serves as the specification for the media type "application/stratu
 
 IANA maintains the registry of WebSocket Subprotocol Names at https://www.iana.org/assignments/websocket.
 
-This document serves as the specification for the subprotocol name "stratum". It has been registered with IANA.
+This document serves as the specification for the WebSocket subprotocol name "stratum". It has been registered with IANA.
 
 ==References==
 
\ No newline at end of file

From 6e26691db936b22a1e59a5972ca9a9e4aea70b33 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Fri, 10 May 2024 23:49:57 +0200
Subject: [PATCH 21/32] Add example pub/sub commands

---
 bip-0040.mediawiki | 132 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 131 insertions(+), 1 deletion(-)

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index 2179d8362b..fdfee9fa4f 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -273,18 +273,83 @@ Ask the server to run a synchronous command for a specific amount of seconds.
 
 * Method name: synchronous
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.synchronous
+|-
+! Params [0] (how_long)
+| int (or a string or a float that can be casted to an int)
+| 123
+| The time to run.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Request finished in 123 seconds
+| A string that tells that the command has finished running.
+|}
+
 ====Method: Throw Exception====
 
 Ask the server throw exception.
 
 * Method name: throw_exception
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.throw_exception
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Error
+| object
+| {"code":-1,"data":"Some traceback","message":"Some error"}
+| The error object.
+|}
+
 ====Method: Throw Signed Exception====
 
-Ask the server throw signed exception.
+Ask the server throw exception in a signed JSON-RPC object.
 
 * Method name: throw_signed_exception
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.throw_exception
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Error
+| object
+| {"code":-1,"data":"Some traceback","message":"Some error"}
+| The error object.
+|}
+
 ===Service: Example Publish-Subscribe===
 
 This service is an example service. It doesn't have any other purpose than testing.
@@ -298,18 +363,83 @@ Subscribe on an event.
 
 * Method name: subscribe
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.subscribe
+|-
+! Params [0] (period)
+| int
+| 12
+| Period to wait for next emission.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| ...
+| ...
+| ...
+|}
+
 ====Method: Time Event====
 
 The time event that gets emitted.
 
 * Method name: time_event
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.time_event
+|-
+! Params [0]
+| ...
+| ...
+| ...
+|}
+
 ====Method: Unsubscribe====
 
 Unsubscribe from an event.
 
 * Method name: unsubscribe
 
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.unsubscribe
+|-
+! Params [0] (subscription_key)
+| string
+| some-subscription-key
+| The subscription key of the event subscription.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| some-subscription-key
+| The subscription key of the event subscription.
+|}
+
 ===Service: Server===
 
 * Service name: server

From 73f8ad180a691ded687feffbda37ab37c69050ad Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Sun, 12 May 2024 14:34:33 +0200
Subject: [PATCH 22/32] Move services to seperate file

---
 bip-0040.mediawiki                            | 372 ++----------------
 bip-0040/service-blockchain.address.mediawiki |  52 +++
 bip-0040/service-blockchain.block.mediawiki   |   4 +
 .../service-blockchain.transaction.mediawiki  |   4 +
 bip-0040/service-client.mediawiki             |  25 ++
 bip-0040/service-discovery.mediawiki          |   4 +
 bip-0040/service-example.mediawiki            | 146 +++++++
 bip-0040/service-example.pubsub.mediawiki     |  89 +++++
 bip-0040/service-firstbits.mediawiki          |   4 +
 bip-0040/service-node.mediawiki               |   4 +
 bip-0040/service-server.mediawiki             |  30 ++
 bip-0040/service-wallet.mediawiki             |   4 +
 12 files changed, 392 insertions(+), 346 deletions(-)
 create mode 100644 bip-0040/service-blockchain.address.mediawiki
 create mode 100644 bip-0040/service-blockchain.block.mediawiki
 create mode 100644 bip-0040/service-blockchain.transaction.mediawiki
 create mode 100644 bip-0040/service-client.mediawiki
 create mode 100644 bip-0040/service-discovery.mediawiki
 create mode 100644 bip-0040/service-example.mediawiki
 create mode 100644 bip-0040/service-example.pubsub.mediawiki
 create mode 100644 bip-0040/service-firstbits.mediawiki
 create mode 100644 bip-0040/service-node.mediawiki
 create mode 100644 bip-0040/service-server.mediawiki
 create mode 100644 bip-0040/service-wallet.mediawiki

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index fdfee9fa4f..7be68fc1e9 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -38,7 +38,7 @@ 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 method property a name that meets the following EBNF notation: method ::= serviceType ("[" serviceVendor "]")? "." methodName, where serviceType and serviceVendor are allowed to have dots and methodName isn't. For example, the values blockchain.block.subscribe and blockchain.block[Electrum].subscribe.
 
-The service vendor is optional. However, multiple vendors can define the same service type, so the service vendor is introduced to distinguish them. If the service vendor is absent, the default service type is executed.
+The service vendor is optional. However, multiple vendors can define the same service type, so the service vendor is introduced to distinguish them. If the service vendor is absent, the default service type is executed. It is up to the server implementer which service vendor is the default.
 
 ''Note: In JSON-RPC 1.0, the param property is an array, so everything should be passed in the right order. In JSON-RPC 2.0, named parameters are also allowed. In that case, only the parameter names that are documented should be used; otherwise, the method can fail. It is maybe also possible that a specific method (or server) only supports params as an array, because it doesn't know how to handle named params, even if it supports JSON-RPC 2.0.''
 
@@ -124,351 +124,31 @@ Stratum over a WebSocket connection with SSL/TLS: the same as normal WebSocket,
 * Default port: 8084
 * Letter: u
 
-==Specification: Commands==
-
-===Service: Blockchain Address===
-
-* Service name: blockchain.address
-
-====Method: Get History====
-
-* Method name: get_history
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | blockchain.address.get_history
-|-
-! Param [0]
-| string
-| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
-| The address to get the history of.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| array
-|
-| The history of the blockchain address.
-|}
-
-====Method: Subscribe====
-
-* Method name: subscribe
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | blockchain.address.subscribe
-|-
-! Param [0]
-| string
-| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
-| The address to subscribe to.
-|}
-
-===Service: Client===
-
-* Service name: client
-
-====Method: Version====
-
-Send the version of the client to the server. This command doesn't expect a response.
-
-* Method name: version
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | client.version
-|-
-! Params [0]
-| string
-| 0.41
-| The client version.
-|}
-
-===Service: Example===
-
-This service is an example service. It doesn't have any other purpose than testing.
-
-* Service name: example
-* Service vendor: Stratum
-
-====Method: Hello World====
-
-Ask the server to send a "Hello world!" back.
-
-* Method name: hello_world
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.hello_world
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| Hello world!
-| The "Hello world" text.
-|}
-
-====Method: Ping====
-
-Ping the server and get a pong back with the same text.
-
-* Method name: ping
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.ping
-|-
-! Params [0] (payload)
-| mixed
-| 12345678
-| The ping text.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| Hello world!
-| The "Hello world" text.
-|}
-
-====Method: Synchronous====
-
-Ask the server to run a synchronous command for a specific amount of seconds.
-
-* Method name: synchronous
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.synchronous
-|-
-! Params [0] (how_long)
-| int (or a string or a float that can be casted to an int)
-| 123
-| The time to run.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| Request finished in 123 seconds
-| A string that tells that the command has finished running.
-|}
-
-====Method: Throw Exception====
-
-Ask the server throw exception.
-
-* Method name: throw_exception
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.throw_exception
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Error
-| object
-| {"code":-1,"data":"Some traceback","message":"Some error"}
-| The error object.
-|}
-
-====Method: Throw Signed Exception====
-
-Ask the server throw exception in a signed JSON-RPC object.
-
-* Method name: throw_signed_exception
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.throw_exception
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Error
-| object
-| {"code":-1,"data":"Some traceback","message":"Some error"}
-| The error object.
-|}
-
-===Service: Example Publish-Subscribe===
-
-This service is an example service. It doesn't have any other purpose than testing.
-
-* Service name: example.pubsub
-* Service vendor: Stratum
-
-====Method: Subscribe====
-
-Subscribe on an event.
-
-* Method name: subscribe
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.pubsub.subscribe
-|-
-! Params [0] (period)
-| int
-| 12
-| Period to wait for next emission.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| ...
-| ...
-| ...
-|}
-
-====Method: Time Event====
-
-The time event that gets emitted.
-
-* Method name: time_event
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.pubsub.time_event
-|-
-! Params [0]
-| ...
-| ...
-| ...
-|}
-
-====Method: Unsubscribe====
-
-Unsubscribe from an event.
-
-* Method name: unsubscribe
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | example.pubsub.unsubscribe
-|-
-! Params [0] (subscription_key)
-| string
-| some-subscription-key
-| The subscription key of the event subscription.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| some-subscription-key
-| The subscription key of the event subscription.
-|}
-
-===Service: Server===
-
-* Service name: server
-
-====Method: Banner====
-
-A command to get the server banner.
-
-* Method name: banner
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | server.banner
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| Welcome to Electrum!
-| The server banner.
-|}
+==Specification: Services==
+
+On top of Stratum, some services are defined. They are listed below, grouped by vendor.
+
+===Vendor: Stratum===
+
+* [[bip-0040/service-discovery.mediawiki|Discovery]]
+* [[bip-0040/service-example.mediawiki|Example]]
+* [[bip-0040/service-example.pubsub.mediawiki|Example Publish-Subscribe]]
+
+===Vendor: Electrum===
+
+* [[bip-0040/service-blockchain.address.mediawiki|Blockchain Address]]
+* [[bip-0040/service-blockchain.block.mediawiki|Blockchain Block]]
+* [[bip-0040/service-blockchain.transaction.mediawiki|Blockchain Translation]]
+* [[bip-0040/service-node.mediawiki|Node]]
+* [[bip-0040/service-wallet.mediawiki|Wallet]]
+
+===Vendor: blockchain.info===
+
+* [[bip-0040/service-firstbits.mediawiki|Firstbits]]
+
+===Vendor: firstbits.com===
+
+* [[bip-0040/service-firstbits.mediawiki|Firstbits]]
 
 ==IANA Considerations==
 
diff --git a/bip-0040/service-blockchain.address.mediawiki b/bip-0040/service-blockchain.address.mediawiki
new file mode 100644
index 0000000000..5237c57bd3
--- /dev/null
+++ b/bip-0040/service-blockchain.address.mediawiki
@@ -0,0 +1,52 @@
+=Service: Blockchain Address=
+
+* Service type: blockchain.address
+* Service vendor: Electrum
+
+==Method: Get History==
+
+* Method name: get_history
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | blockchain.address.get_history
+|-
+! Param [0]
+| string
+| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
+| The address to get the history of.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+|
+| The history of the blockchain address.
+|}
+
+==Method: Subscribe==
+
+* Method name: subscribe
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | blockchain.address.subscribe
+|-
+! Param [0]
+| string
+| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
+| The address to subscribe to.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.block.mediawiki b/bip-0040/service-blockchain.block.mediawiki
new file mode 100644
index 0000000000..d9ace44a2b
--- /dev/null
+++ b/bip-0040/service-blockchain.block.mediawiki
@@ -0,0 +1,4 @@
+=Service: Blockchain Block=
+
+* Service type: blockchain.block
+* Service vendor: Electrum
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.transaction.mediawiki b/bip-0040/service-blockchain.transaction.mediawiki
new file mode 100644
index 0000000000..1708235c2f
--- /dev/null
+++ b/bip-0040/service-blockchain.transaction.mediawiki
@@ -0,0 +1,4 @@
+=Service: Blockchain Transaction=
+
+* Service type: blockchain.transaction
+* Service vendor: Electrum
\ No newline at end of file
diff --git a/bip-0040/service-client.mediawiki b/bip-0040/service-client.mediawiki
new file mode 100644
index 0000000000..d614546768
--- /dev/null
+++ b/bip-0040/service-client.mediawiki
@@ -0,0 +1,25 @@
+=Service: Client=
+
+* Service type: client
+* Service vendor: ???
+
+==Method: Version==
+
+Send the version of the client to the server. This command doesn't expect a response.
+
+* Method name: version
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | client.version
+|-
+! Params [0]
+| string
+| 0.41
+| The client version.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-discovery.mediawiki b/bip-0040/service-discovery.mediawiki
new file mode 100644
index 0000000000..a843f22af8
--- /dev/null
+++ b/bip-0040/service-discovery.mediawiki
@@ -0,0 +1,4 @@
+=Service: Discovery=
+
+* Service type: discovery
+* Service vendor: Stratum
\ No newline at end of file
diff --git a/bip-0040/service-example.mediawiki b/bip-0040/service-example.mediawiki
new file mode 100644
index 0000000000..266abfe6e5
--- /dev/null
+++ b/bip-0040/service-example.mediawiki
@@ -0,0 +1,146 @@
+=Service: Example=
+
+This service is an example service. It doesn't have any other purpose than testing.
+
+* Service type: example
+* Service vendor: Stratum
+
+==Method: Hello World==
+
+Ask the server to send a "Hello world!" back.
+
+* Method name: hello_world
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.hello_world
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Hello world!
+| The "Hello world" text.
+|}
+
+==Method: Ping==
+
+Ping the server and get a pong back with the same text.
+
+* Method name: ping
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.ping
+|-
+! Params [0] (payload)
+| mixed
+| 12345678
+| The ping text.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Hello world!
+| The "Hello world" text.
+|}
+
+==Method: Synchronous==
+
+Ask the server to run a synchronous command for a specific amount of seconds.
+
+* Method name: synchronous
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.synchronous
+|-
+! Params [0] (how_long)
+| int (or a string or a float that can be casted to an int)
+| 123
+| The time to run.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Request finished in 123 seconds
+| A string that tells that the command has finished running.
+|}
+
+==Method: Throw Exception==
+
+Ask the server throw exception.
+
+* Method name: throw_exception
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.throw_exception
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Error
+| object
+| {"code":-1,"data":"Some traceback","message":"Some error"}
+| The error object.
+|}
+
+==Method: Throw Signed Exception==
+
+Ask the server throw exception in a signed JSON-RPC object.
+
+* Method name: throw_signed_exception
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.throw_exception
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Error
+| object
+| {"code":-1,"data":"Some traceback","message":"Some error"}
+| The error object.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-example.pubsub.mediawiki b/bip-0040/service-example.pubsub.mediawiki
new file mode 100644
index 0000000000..ca1fd21da8
--- /dev/null
+++ b/bip-0040/service-example.pubsub.mediawiki
@@ -0,0 +1,89 @@
+=Service: Example Publish-Subscribe=
+
+This service is an example service. It doesn't have any other purpose than testing.
+
+* Service type: example.pubsub
+* Service vendor: Stratum
+
+==Method: Subscribe==
+
+Subscribe on an event.
+
+* Method name: subscribe
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.subscribe
+|-
+! Params [0] (period)
+| int
+| 12
+| Period to wait for next emission.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| ...
+| ...
+| ...
+|}
+
+==Method: Time Event==
+
+The time event that gets emitted.
+
+* Method name: time_event
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.time_event
+|-
+! Params [0]
+| ...
+| ...
+| ...
+|}
+
+==Method: Unsubscribe==
+
+Unsubscribe from an event.
+
+* Method name: unsubscribe
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | example.pubsub.unsubscribe
+|-
+! Params [0] (subscription_key)
+| string
+| some-subscription-key
+| The subscription key of the event subscription.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| some-subscription-key
+| The subscription key of the event subscription.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-firstbits.mediawiki b/bip-0040/service-firstbits.mediawiki
new file mode 100644
index 0000000000..d13f23f01e
--- /dev/null
+++ b/bip-0040/service-firstbits.mediawiki
@@ -0,0 +1,4 @@
+=Service: Firstbits=
+
+* Service type: firstbits
+* Service vendor: blockchain.info and firstbits.com
\ No newline at end of file
diff --git a/bip-0040/service-node.mediawiki b/bip-0040/service-node.mediawiki
new file mode 100644
index 0000000000..938759fb4b
--- /dev/null
+++ b/bip-0040/service-node.mediawiki
@@ -0,0 +1,4 @@
+=Service: Node=
+
+* Service type: node
+* Service vendor: Electrum
\ No newline at end of file
diff --git a/bip-0040/service-server.mediawiki b/bip-0040/service-server.mediawiki
new file mode 100644
index 0000000000..bb26664194
--- /dev/null
+++ b/bip-0040/service-server.mediawiki
@@ -0,0 +1,30 @@
+=Service: Server=
+
+* Service type: server
+* Service vendor: ???
+
+==Method: Banner==
+
+A command to get the server banner.
+
+* Method name: banner
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | server.banner
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Welcome to Electrum!
+| The server banner.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-wallet.mediawiki b/bip-0040/service-wallet.mediawiki
new file mode 100644
index 0000000000..22ab6c37b4
--- /dev/null
+++ b/bip-0040/service-wallet.mediawiki
@@ -0,0 +1,4 @@
+=Service: Wallet=
+
+* Service type: wallet
+* Service vendor: Electrum
\ No newline at end of file

From 2787db0163a6a4c032a556cfd92fd38f3ee70a57 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Sun, 12 May 2024 15:50:43 +0200
Subject: [PATCH 23/32] Add information about discovery service

---
 bip-0040/service-blockchain.address.mediawiki |   4 +-
 bip-0040/service-discovery.mediawiki          | 113 +++++++++++++++++-
 2 files changed, 114 insertions(+), 3 deletions(-)

diff --git a/bip-0040/service-blockchain.address.mediawiki b/bip-0040/service-blockchain.address.mediawiki
index 5237c57bd3..379953bd32 100644
--- a/bip-0040/service-blockchain.address.mediawiki
+++ b/bip-0040/service-blockchain.address.mediawiki
@@ -16,7 +16,7 @@
 ! Method
 | colspan="3" | blockchain.address.get_history
 |-
-! Param [0]
+! Params [0]
 | string
 | 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
 | The address to get the history of.
@@ -45,7 +45,7 @@
 ! Method
 | colspan="3" | blockchain.address.subscribe
 |-
-! Param [0]
+! Params [0]
 | string
 | 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
 | The address to subscribe to.
diff --git a/bip-0040/service-discovery.mediawiki b/bip-0040/service-discovery.mediawiki
index a843f22af8..188d528344 100644
--- a/bip-0040/service-discovery.mediawiki
+++ b/bip-0040/service-discovery.mediawiki
@@ -1,4 +1,115 @@
 =Service: Discovery=
 
 * Service type: discovery
-* Service vendor: Stratum
\ No newline at end of file
+* Service vendor: Stratum
+
+==Method: List Services==
+
+* Method name: list_services
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | discovery.list_services
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+| ["discovery","example","example.pubsub"]
+| The services that are implemented by the server.
+|}
+
+==Method: List Vendors==
+
+* Method name: list_vendors
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | discovery.list_vendors
+|-
+! Params [0] (service_type)
+| string
+| firstbits
+| The service you want all the vendors of.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+| ["blockchain.info","firstbits.com"]
+| The vendors of the requested service.
+|}
+
+==Method: List Methods==
+
+* Method name: list_methods
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | discovery.list_methods
+|-
+! Params [0] (service_name)
+| string
+| firstbits[firstbits.com]
+| The service name (eventually including a service vendor in square brackets).
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+| ["create","resolve"]
+| The methods of the requested service.
+|}
+
+==Method: List Params==
+
+* Method name: list_params
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | discovery.list_params
+|-
+! Params [0] (method)
+| string
+| firstbits[firstbits.com].create
+| The full method name, including the service name (and possibly the service vendor in square brackets).
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+| ["Some method help text",[ ["address","string","String containing full Bitcoin address."] ]].
+| The parameters of the requested method.
+|}
\ No newline at end of file

From 40bc7213f7098a99c49394fb6198b5a32371fff9 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Sun, 12 May 2024 23:26:08 +0200
Subject: [PATCH 24/32] Improve service documentation

---
 bip-0040/service-discovery.mediawiki |   2 +-
 bip-0040/service-firstbits.mediawiki |  60 +++++++++-
 bip-0040/service-node.mediawiki      |  74 +++++++++++-
 bip-0040/service-wallet.mediawiki    | 173 ++++++++++++++++++++++++++-
 4 files changed, 305 insertions(+), 4 deletions(-)

diff --git a/bip-0040/service-discovery.mediawiki b/bip-0040/service-discovery.mediawiki
index 188d528344..e875abf6eb 100644
--- a/bip-0040/service-discovery.mediawiki
+++ b/bip-0040/service-discovery.mediawiki
@@ -110,6 +110,6 @@
 |-
 ! Result
 | array
-| ["Some method help text",[ ["address","string","String containing full Bitcoin address."] ]].
+| ["Some method help text",[ ["address","string","String containing full Bitcoin address."] ]]
 | The parameters of the requested method.
 |}
\ No newline at end of file
diff --git a/bip-0040/service-firstbits.mediawiki b/bip-0040/service-firstbits.mediawiki
index d13f23f01e..361cfd7d51 100644
--- a/bip-0040/service-firstbits.mediawiki
+++ b/bip-0040/service-firstbits.mediawiki
@@ -1,4 +1,62 @@
 =Service: Firstbits=
 
 * Service type: firstbits
-* Service vendor: blockchain.info and firstbits.com
\ No newline at end of file
+* Service vendor: blockchain.info and firstbits.com
+
+==Method: Create==
+
+* Method name: create
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | firstbits.create
+|-
+! Params [0] (address)
+| string
+| 1MarekMKDKRb6PEeHeVuiCGayk9avyBGBB
+| The address.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| 
+| The firstbits string.
+|}
+
+==Method: Resolve==
+
+* Method name: resolve
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | firstbits.resolve
+|-
+! Params [0] (firstbits)
+| string
+| 1MarekM
+| The address.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| 
+| The address.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-node.mediawiki b/bip-0040/service-node.mediawiki
index 938759fb4b..6d5e661564 100644
--- a/bip-0040/service-node.mediawiki
+++ b/bip-0040/service-node.mediawiki
@@ -1,4 +1,76 @@
 =Service: Node=
 
 * Service type: node
-* Service vendor: Electrum
\ No newline at end of file
+* Service vendor: Electrum
+
+==Method: Get Banner==
+
+* Method name: get_banner
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | node.get_banner
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| Dummy banner
+| The banner.
+|}
+
+==Method: Get Peers==
+
+* Method name: get_peers
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | node.get_peers
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| array
+| [ {"hostname":"","trusted":true,"weight":0,"ipv4":"1.2.3.4","ipv6":"2001:db8:85a3:8d3:1319:8a2e:370:7348"} ]
+| An array of peers.
+|}
+
+==Method: Stop==
+
+* Method name: stop
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | node.stop
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| True when the server will be stopped.
+|}
\ No newline at end of file
diff --git a/bip-0040/service-wallet.mediawiki b/bip-0040/service-wallet.mediawiki
index 22ab6c37b4..83a55564bf 100644
--- a/bip-0040/service-wallet.mediawiki
+++ b/bip-0040/service-wallet.mediawiki
@@ -1,4 +1,175 @@
 =Service: Wallet=
 
+This service has never been properly defined. It is therefore not standardized and may be removed.
+
 * Service type: wallet
-* Service vendor: Electrum
\ No newline at end of file
+* Service vendor: Electrum
+
+==Method: Import Seed==
+
+* Method name: import_seed
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.import_seed
+|-
+! Params [0] (seed)
+| string
+| update stomach couch actress cart dose coral slice frozen settle alarm boost
+| The seed.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| Unknown
+|}
+
+==Method: Add Public Key==
+
+* Method name: add_pubkey
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.add_pubkey
+|-
+! Params [0] (pubkey)
+| string
+| Unknown
+| The public key.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| Unknown
+|}
+
+==Method: Remove Public Key==
+
+* Method name: remove_pubkey
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.remove_pubkey
+|-
+! Params [0] (pubkey)
+| string
+| Unknown
+| The public key.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| Unknown
+|}
+
+==Method: Create transaction==
+
+* Method name: create_transaction
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.create_transaction
+|-
+! Params [0] (address)
+| string
+| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
+| The address.
+|-
+! Params [1] (amount)
+| Unknown
+| Unknown
+| The amount.
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string
+| 
+| Unknown
+|}
+
+==Method: Save==
+
+* Method name: save
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.save
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| Unknown
+|}
+
+==Method: Load==
+
+* Method name: load
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | wallet.load
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| boolean
+| true
+| Unknown
+|}
\ No newline at end of file

From 05e11947bd6b96191750a187450902b008c0e1aa Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Mon, 13 May 2024 00:02:13 +0200
Subject: [PATCH 25/32] Improve blockchain service documentation

---
 bip-0040/service-blockchain.address.mediawiki | 22 +++++++++++++++-
 bip-0040/service-blockchain.block.mediawiki   | 26 ++++++++++++++++++-
 .../service-blockchain.transaction.mediawiki  | 26 ++++++++++++++++++-
 bip-0040/service-wallet.mediawiki             |  2 +-
 4 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/bip-0040/service-blockchain.address.mediawiki b/bip-0040/service-blockchain.address.mediawiki
index 379953bd32..2f61af5769 100644
--- a/bip-0040/service-blockchain.address.mediawiki
+++ b/bip-0040/service-blockchain.address.mediawiki
@@ -32,6 +32,10 @@
 | The history of the blockchain address.
 |}
 
+==Method: Get Balance==
+
+* Method name: get_balance
+
 ==Method: Subscribe==
 
 * Method name: subscribe
@@ -49,4 +53,20 @@
 | string
 | 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
 | The address to subscribe to.
-|}
\ No newline at end of file
+|}
+
+==Method: Unsubscribe==
+
+* Method name: unsubscribe
+
+==Method: Get Memory Pool==
+
+* Method name: get_mempool
+
+==Method: Get Proof==
+
+* Method name: get_proof
+
+==Method: List Unspent==
+
+* Method name: listunspent
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.block.mediawiki b/bip-0040/service-blockchain.block.mediawiki
index d9ace44a2b..4b0e1330b8 100644
--- a/bip-0040/service-blockchain.block.mediawiki
+++ b/bip-0040/service-blockchain.block.mediawiki
@@ -1,4 +1,28 @@
 =Service: Blockchain Block=
 
 * Service type: blockchain.block
-* Service vendor: Electrum
\ No newline at end of file
+* Service vendor: Electrum
+
+==Method: Subscribe==
+
+* Method name: subscribe
+
+==Method: Unsubscribe==
+
+* Method name: unsubscribe
+
+==Method: Get Block Number==
+
+* Method name: get_blocknum
+
+==Method: Get Chunk==
+
+* Method name: get_chunk
+
+==Method: Get Header==
+
+* Method name: get_header
+
+==Method: Ping==
+
+* Method name: ping
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.transaction.mediawiki b/bip-0040/service-blockchain.transaction.mediawiki
index 1708235c2f..094dcb1e64 100644
--- a/bip-0040/service-blockchain.transaction.mediawiki
+++ b/bip-0040/service-blockchain.transaction.mediawiki
@@ -1,4 +1,28 @@
 =Service: Blockchain Transaction=
 
 * Service type: blockchain.transaction
-* Service vendor: Electrum
\ No newline at end of file
+* Service vendor: Electrum
+
+==Method: Subscribe==
+
+* Method name: subscribe
+
+==Method: Unsubscribe==
+
+* Method name: unsubscribe
+
+==Method: Guess Fee==
+
+* Method name: guess_fee
+
+==Method: Broadcast==
+
+* Method name: broadcast
+
+==Method: Get==
+
+* Method name: get
+
+==Method: Get Merkle==
+
+* Method name: get_merkle
\ No newline at end of file
diff --git a/bip-0040/service-wallet.mediawiki b/bip-0040/service-wallet.mediawiki
index 83a55564bf..8a637d6efe 100644
--- a/bip-0040/service-wallet.mediawiki
+++ b/bip-0040/service-wallet.mediawiki
@@ -1,6 +1,6 @@
 =Service: Wallet=
 
-This service has never been properly defined. It is therefore not standardized and may be removed.
+This service has never been properly defined. It is therefore not standardized and may be removed.
 
 * Service type: wallet
 * Service vendor: Electrum

From 16b6d5c5d3257bdd9edf6abcf97d3e0b60591f84 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Tue, 21 May 2024 21:16:01 +0200
Subject: [PATCH 26/32] Apply suggestions

---
 bip-0040.mediawiki                 | 2 +-
 bip-0040/service-example.mediawiki | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index 7be68fc1e9..e6b88994d9 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -138,7 +138,7 @@ On top of Stratum, some services are defined. They are listed below, grouped by
 
 * [[bip-0040/service-blockchain.address.mediawiki|Blockchain Address]]
 * [[bip-0040/service-blockchain.block.mediawiki|Blockchain Block]]
-* [[bip-0040/service-blockchain.transaction.mediawiki|Blockchain Translation]]
+* [[bip-0040/service-blockchain.transaction.mediawiki|Blockchain Transaction]]
 * [[bip-0040/service-node.mediawiki|Node]]
 * [[bip-0040/service-wallet.mediawiki|Wallet]]
 
diff --git a/bip-0040/service-example.mediawiki b/bip-0040/service-example.mediawiki
index 266abfe6e5..098cdc31f1 100644
--- a/bip-0040/service-example.mediawiki
+++ b/bip-0040/service-example.mediawiki
@@ -95,7 +95,7 @@ Ask the server to run a synchronous command for a specific amount of seconds.
 
 ==Method: Throw Exception==
 
-Ask the server throw exception.
+Ask the server to throw an exception.
 
 * Method name: throw_exception
 
@@ -121,7 +121,7 @@ Ask the server throw exception.
 
 ==Method: Throw Signed Exception==
 
-Ask the server throw exception in a signed JSON-RPC object.
+Ask the server to throw an exception in a signed JSON-RPC object.
 
 * Method name: throw_signed_exception
 

From 4cf8985789d9ff3e24d446364f6db9f6156e7a69 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Mon, 25 Nov 2024 22:04:36 +0100
Subject: [PATCH 27/32] Improve sentences

---
 bip-0040.mediawiki | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index e6b88994d9..cb6cf706cf 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -32,6 +32,10 @@ The Stratum wire protocol was introduced by Marek Palatinus in late 2011 and ear
 
 Later in 2012, Marek Palatinus introduced Stratum for mining pools as well: The Stratum mining protocol, as defined in [[bip-0041.mediawiki|BIP 41]].
 
+==ExtensionThis is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP.==
+
+This BIP has some extended specification information that isn't found in the older, legacy specifications. For backwards compatibility, it is recommended to implement the legacy specification information too, which is also described in this specification.
+
 ==Specification: Data Format==
 
 Stratum leverages [https://www.jsonrpc.org/ JSON-RPC]. Both versions 1.0 and 2.0 are allowed, according to their respective rules.
@@ -46,11 +50,11 @@ The service vendor is optional. However, multiple vendors can define the same se
 
 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.
 
-''Note: Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to hypothetically support all coins ever listed in SLIP-44. For IPv4, you would need all IPv4 addresses that exist to do the same, even the invalid ones, so a suggestion is to only use the server for coins you really need. Also, other ports could possibly be used, and in that case, a /16 IP block with all 65536 TCP ports in use will be enough to support all coins. However, because using non-standard ports is not user-friendly, this is also not recommended.''
+''Note: Implementers may write servers that support multiple coins, assuming that those coins all use the same port (e.g. 50001). Because HTTP and WebSockets support virtual hosting (Host header or :authority pseudo-header), it is possible to create a server on a single IP address that supports multiple coins by checking the domain name. The same is the case for the transport protocols with SSL/TLS when SNI is used. On plain TCP, virtual hosting is not possible. A similar experience can be reached by using multiple IP addresses. For IPv6, a network of /96 would be enough to hypothetically support all coins ever listed in SLIP-44. For IPv4, you would need all IPv4 addresses that exist to do the same, even the invalid ones, so a suggestion is to only use the server for coins you really need. Also, other ports could possibly be used, and in that case, a /16 IP block with all 65536 TCP ports in use will be enough to support all coins. However, because using non-standard and non-default ports is not user-friendly, this is also not recommended.''
 
 ===TCP===
 
-Stratum over a TCP connection. Every JSON-RPC message (including batch messages) is sent on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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 (including batch messages) is sent on a single line, ending with a line-feed (\n), so \r\n is also allowed. 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. Below, the default ports of Stratum for Bitcoin are defined. Other coins can define other default ports.
 
 * Default port: 50001
 * Letter: t
@@ -100,7 +104,7 @@ Stratum over an HTTP connection with SSL/TLS: the same as normal HTTP, but with
 
 Stratum over a WebSocket connection. When using WebSockets, the JSON-RPC messages (including batch messages) are encapsulated in a WebSocket message. It is also possible to send multiple JSON-RPC messages in one WebSocket message. Every JSON-RPC message should end with a line-feed (\n). Both client and server can initiate a message request on which the other side could respond with a result or an error, like Stratum over TCP.
 
-* Default port: 8083This is extended specification information of the Stratum wire protocol to make it more complete. This information will not be found in any code or specification before this BIP.
+* Default port: 8083
 * Letter: w
 
 ====Subprotocol====

From 1936b498035796619253be1a2b8d29ab49466a31 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Tue, 26 Nov 2024 11:45:26 +0100
Subject: [PATCH 28/32] Improve documents of Stratum methods

---
 bip-0040/service-discovery.mediawiki      | 38 ++++++++++++++++++++---
 bip-0040/service-example.mediawiki        | 10 +++---
 bip-0040/service-example.pubsub.mediawiki | 32 ++++++++++++-------
 3 files changed, 60 insertions(+), 20 deletions(-)

diff --git a/bip-0040/service-discovery.mediawiki b/bip-0040/service-discovery.mediawiki
index e875abf6eb..15114e1bf1 100644
--- a/bip-0040/service-discovery.mediawiki
+++ b/bip-0040/service-discovery.mediawiki
@@ -22,7 +22,7 @@
 ! Description
 |-
 ! Result
-| array
+| array of strings
 | ["discovery","example","example.pubsub"]
 | The services that are implemented by the server.
 |}
@@ -51,7 +51,7 @@
 ! Description
 |-
 ! Result
-| array
+| array of strings
 | ["blockchain.info","firstbits.com"]
 | The vendors of the requested service.
 |}
@@ -80,7 +80,7 @@
 ! Description
 |-
 ! Result
-| array
+| array of strings
 | ["create","resolve"]
 | The methods of the requested service.
 |}
@@ -111,5 +111,35 @@
 ! Result
 | array
 | ["Some method help text",[ ["address","string","String containing full Bitcoin address."] ]]
-| The parameters of the requested method.
+| The help text and parameters of the requested method.
+|-
+! Result [0] (help_text)
+| string
+| Some method help text
+| The help text of requested method.
+|-
+! Result [1] (params)
+| array of arrays
+| [ ["address","string","String containing full Bitcoin address."] ]
+| The parameters of requested method.
+|-
+! Result [1][index] (params[index])
+| array of arrays
+| ["address","string","String containing full Bitcoin address."]
+| The parameter at position index of requested method.
+|-
+! Result [1][index][0]
+| string
+| address
+| The name of the parameter at position index of requested method.
+|-
+! Result [1][index][1]
+| string
+| string
+| The type of the parameter at position index of requested method.
+|-
+! Result [1][index][2]
+| string
+| string
+| The description of the parameter at position index of requested method.
 |}
\ No newline at end of file
diff --git a/bip-0040/service-example.mediawiki b/bip-0040/service-example.mediawiki
index 098cdc31f1..d4439e16b5 100644
--- a/bip-0040/service-example.mediawiki
+++ b/bip-0040/service-example.mediawiki
@@ -49,7 +49,7 @@ Ping the server and get a pong back with the same text.
 ! Params [0] (payload)
 | mixed
 | 12345678
-| The ping text.
+| The ping payload.
 |-
 ! [Response]
 ! Type
@@ -57,9 +57,9 @@ Ping the server and get a pong back with the same text.
 ! Description
 |-
 ! Result
-| string
-| Hello world!
-| The "Hello world" text.
+| mixed
+| 12345678
+| The pong payload, same as the ping payload.
 |}
 
 ==Method: Synchronous==
@@ -132,7 +132,7 @@ Ask the server to throw an exception in a signed JSON-RPC object.
 ! Description
 |-
 ! Method
-| colspan="3" | example.throw_exception
+| colspan="3" | example.throw_signed_exception
 |-
 ! [Response]
 ! Type
diff --git a/bip-0040/service-example.pubsub.mediawiki b/bip-0040/service-example.pubsub.mediawiki
index ca1fd21da8..77af2bc027 100644
--- a/bip-0040/service-example.pubsub.mediawiki
+++ b/bip-0040/service-example.pubsub.mediawiki
@@ -31,9 +31,19 @@ Subscribe on an event.
 ! Description
 |-
 ! Result
-| ...
-| ...
-| ...
+| array
+| ["example.pubsub.time_event", "some-subscription-key"]
+| The subscription information.
+|-
+! Result [0] (event)
+| string
+| example.pubsub.time_event
+| The subscription event name. In this case, it is example.pubsub.time_event.
+|-
+! Result [1] (subscription_key)
+| string
+| some-subscription-key
+| The subscription key of the event subscription.
 |}
 
 ==Method: Time Event==
@@ -43,7 +53,7 @@ The time event that gets emitted.
 * Method name: time_event
 
 {|
-! [Request]
+! [Notification]
 ! Type
 ! Example
 ! Description
@@ -51,10 +61,10 @@ The time event that gets emitted.
 ! Method
 | colspan="3" | example.pubsub.time_event
 |-
-! Params [0]
-| ...
-| ...
-| ...
+! Params [0] (t)
+| int
+| 1231006505
+| The time when the time event was emitted.
 |}
 
 ==Method: Unsubscribe==
@@ -83,7 +93,7 @@ Unsubscribe from an event.
 ! Description
 |-
 ! Result
-| string
-| some-subscription-key
-| The subscription key of the event subscription.
+| boolean
+| true
+| True if subscription is removed from session, false if failed.
 |}
\ No newline at end of file

From bbad8a0a0ca518232c87702892e2c7c83df44676 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Tue, 26 Nov 2024 12:09:26 +0100
Subject: [PATCH 29/32] Fix type and description

---
 bip-0040/service-discovery.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0040/service-discovery.mediawiki b/bip-0040/service-discovery.mediawiki
index 15114e1bf1..9ad91eb12b 100644
--- a/bip-0040/service-discovery.mediawiki
+++ b/bip-0040/service-discovery.mediawiki
@@ -124,7 +124,7 @@
 | The parameters of requested method.
 |-
 ! Result [1][index] (params[index])
-| array of arrays
+| array
 | ["address","string","String containing full Bitcoin address."]
 | The parameter at position index of requested method.
 |-
@@ -140,6 +140,6 @@
 |-
 ! Result [1][index][2]
 | string
-| string
+| String containing full Bitcoin address.
 | The description of the parameter at position index of requested method.
 |}
\ No newline at end of file

From 387af0f819e85c5212048b3cf9214ff70af79891 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Tue, 26 Nov 2024 12:22:22 +0100
Subject: [PATCH 30/32] Add examples to Firstbits methods

---
 bip-0040/service-firstbits.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0040/service-firstbits.mediawiki b/bip-0040/service-firstbits.mediawiki
index 361cfd7d51..c440597116 100644
--- a/bip-0040/service-firstbits.mediawiki
+++ b/bip-0040/service-firstbits.mediawiki
@@ -28,7 +28,7 @@
 |-
 ! Result
 | string
-| 
+| 1marekm
 | The firstbits string.
 |}
 
@@ -47,7 +47,7 @@
 |-
 ! Params [0] (firstbits)
 | string
-| 1MarekM
+| 1marekm
 | The address.
 |-
 ! [Response]
@@ -57,6 +57,6 @@
 |-
 ! Result
 | string
-| 
+| 1MarekMKDKRb6PEeHeVuiCGayk9avyBGBB
 | The address.
 |}
\ No newline at end of file

From db5ed7530c524d4247a2477cc461804562f59430 Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Wed, 27 Nov 2024 22:09:10 +0100
Subject: [PATCH 31/32] Improve documentation of server commands

---
 bip-0040/service-client.mediawiki       | 25 -------
 bip-0040/service-node.mediawiki         | 76 ---------------------
 bip-0040/service-server.mediawiki       | 87 ++++++++++++++++++++++++-
 bip-0040/service-server.peers.mediawiki | 10 +++
 4 files changed, 96 insertions(+), 102 deletions(-)
 delete mode 100644 bip-0040/service-client.mediawiki
 delete mode 100644 bip-0040/service-node.mediawiki
 create mode 100644 bip-0040/service-server.peers.mediawiki

diff --git a/bip-0040/service-client.mediawiki b/bip-0040/service-client.mediawiki
deleted file mode 100644
index d614546768..0000000000
--- a/bip-0040/service-client.mediawiki
+++ /dev/null
@@ -1,25 +0,0 @@
-=Service: Client=
-
-* Service type: client
-* Service vendor: ???
-
-==Method: Version==
-
-Send the version of the client to the server. This command doesn't expect a response.
-
-* Method name: version
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | client.version
-|-
-! Params [0]
-| string
-| 0.41
-| The client version.
-|}
\ No newline at end of file
diff --git a/bip-0040/service-node.mediawiki b/bip-0040/service-node.mediawiki
deleted file mode 100644
index 6d5e661564..0000000000
--- a/bip-0040/service-node.mediawiki
+++ /dev/null
@@ -1,76 +0,0 @@
-=Service: Node=
-
-* Service type: node
-* Service vendor: Electrum
-
-==Method: Get Banner==
-
-* Method name: get_banner
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | node.get_banner
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| Dummy banner
-| The banner.
-|}
-
-==Method: Get Peers==
-
-* Method name: get_peers
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | node.get_peers
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| array
-| [ {"hostname":"","trusted":true,"weight":0,"ipv4":"1.2.3.4","ipv6":"2001:db8:85a3:8d3:1319:8a2e:370:7348"} ]
-| An array of peers.
-|}
-
-==Method: Stop==
-
-* Method name: stop
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | node.stop
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| True when the server will be stopped.
-|}
\ No newline at end of file
diff --git a/bip-0040/service-server.mediawiki b/bip-0040/service-server.mediawiki
index bb26664194..b616488de2 100644
--- a/bip-0040/service-server.mediawiki
+++ b/bip-0040/service-server.mediawiki
@@ -1,7 +1,13 @@
 =Service: Server=
 
 * Service type: server
-* Service vendor: ???
+* Service vendor: Electrum
+
+==Method: Add Peer==
+
+A command to add the node to the peer list.
+
+* Method name: add_peer
 
 ==Method: Banner==
 
@@ -27,4 +33,83 @@ A command to get the server banner.
 | string
 | Welcome to Electrum!
 | The server banner.
+|}
+
+==Method: Cache==
+
+A command to get the server cache size.
+
+* Method name: cache
+
+==Method: Debug==
+
+* Method name: debug
+
+==Method: Donation Address==
+
+A command to get the server donation address.
+
+* Method name: donation_address
+
+==Method: Features==
+
+A command to get the server features.
+
+* Method name: features
+
+==Method: Info==
+
+A command to get information about the active sessions.
+
+* Method name: info
+
+==Method: Load==
+
+A command to get the server load.
+
+* Method name: load
+
+==Method: Peers==
+
+A event to announce peers.
+
+* Method name: peers
+
+==Method: Ping==
+
+A command to ping the server.
+
+* Method name: ping
+
+==Method: Stop==
+
+A command to stop the server.
+
+* Method name: stop
+
+==Method: Version==
+
+A command to set the client version, get the server version and negotiate the protocol version.
+
+* Method name: version
+* Introduced in: 0.1
+
+{|
+! [Request]
+! Type
+! Example
+! Description
+|-
+! Method
+| colspan="3" | server.version
+|-
+! [Response]
+! Type
+! Example
+! Description
+|-
+! Result
+| string or array
+| Welcome to Electrum!
+| The server banner.
 |}
\ No newline at end of file
diff --git a/bip-0040/service-server.peers.mediawiki b/bip-0040/service-server.peers.mediawiki
new file mode 100644
index 0000000000..1d93a48003
--- /dev/null
+++ b/bip-0040/service-server.peers.mediawiki
@@ -0,0 +1,10 @@
+=Service: Server Peers=
+
+* Service type: server.peers
+* Service vendor: Electrum
+
+==Method: Subscribe==
+
+A command to get current peers.
+
+* Method name: subscribe
\ No newline at end of file

From 996724fe79b18d4c6f2aaeb094260f3e028ab41c Mon Sep 17 00:00:00 2001
From: Ben van Hartingsveldt 
Date: Wed, 27 Nov 2024 22:31:02 +0100
Subject: [PATCH 32/32] Add remaining Stratum services

---
 bip-0040.mediawiki                            |   8 +-
 bip-0040/service-blockchain.headers.mediawiki |   8 +
 bip-0040/service-blockchain.mediawiki         |  12 ++
 .../service-blockchain.numblocks.mediawiki    |   8 +
 bip-0040/service-blockchain.utxo.mediawiki    |   8 +
 bip-0040/service-wallet.mediawiki             | 175 ------------------
 6 files changed, 42 insertions(+), 177 deletions(-)
 create mode 100644 bip-0040/service-blockchain.headers.mediawiki
 create mode 100644 bip-0040/service-blockchain.mediawiki
 create mode 100644 bip-0040/service-blockchain.numblocks.mediawiki
 create mode 100644 bip-0040/service-blockchain.utxo.mediawiki
 delete mode 100644 bip-0040/service-wallet.mediawiki

diff --git a/bip-0040.mediawiki b/bip-0040.mediawiki
index cb6cf706cf..78166cd61b 100644
--- a/bip-0040.mediawiki
+++ b/bip-0040.mediawiki
@@ -137,14 +137,18 @@ On top of Stratum, some services are defined. They are listed below, grouped by
 * [[bip-0040/service-discovery.mediawiki|Discovery]]
 * [[bip-0040/service-example.mediawiki|Example]]
 * [[bip-0040/service-example.pubsub.mediawiki|Example Publish-Subscribe]]
+* [[bip-0040/service-server.mediawiki|Server]]
+* [[bip-0040/service-server.peers.mediawiki|Server Peers]]
 
 ===Vendor: Electrum===
 
+* [[bip-0040/service-blockchain.mediawiki|Blockchain]]
 * [[bip-0040/service-blockchain.address.mediawiki|Blockchain Address]]
 * [[bip-0040/service-blockchain.block.mediawiki|Blockchain Block]]
+* [[bip-0040/service-blockchain.headers.mediawiki|Blockchain Headers]]
+* [[bip-0040/service-blockchain.numblocks.mediawiki|Blockchain Number of Blocks]]
 * [[bip-0040/service-blockchain.transaction.mediawiki|Blockchain Transaction]]
-* [[bip-0040/service-node.mediawiki|Node]]
-* [[bip-0040/service-wallet.mediawiki|Wallet]]
+* [[bip-0040/service-blockchain.utxo.mediawiki|Blockchain Unspent Transaction Output]]
 
 ===Vendor: blockchain.info===
 
diff --git a/bip-0040/service-blockchain.headers.mediawiki b/bip-0040/service-blockchain.headers.mediawiki
new file mode 100644
index 0000000000..891836e389
--- /dev/null
+++ b/bip-0040/service-blockchain.headers.mediawiki
@@ -0,0 +1,8 @@
+=Service: Blockchain Headers=
+
+* Service type: blockchain.headers
+* Service vendor: Electrum
+
+==Method: Subscribe==
+
+* Method name: subscribe
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.mediawiki b/bip-0040/service-blockchain.mediawiki
new file mode 100644
index 0000000000..480739772b
--- /dev/null
+++ b/bip-0040/service-blockchain.mediawiki
@@ -0,0 +1,12 @@
+=Service: Blockchain=
+
+* Service type: blockchain
+* Service vendor: Electrum
+
+==Method: Estimate Fee==
+
+* Method name: estimatefee
+
+==Method: Relay Fee==
+
+* Method name: relayfee
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.numblocks.mediawiki b/bip-0040/service-blockchain.numblocks.mediawiki
new file mode 100644
index 0000000000..8a4f8604c7
--- /dev/null
+++ b/bip-0040/service-blockchain.numblocks.mediawiki
@@ -0,0 +1,8 @@
+=Service: Blockchain Number of Blocks=
+
+* Service type: blockchain.numblocks
+* Service vendor: Electrum
+
+==Method: Subscribe==
+
+* Method name: subscribe
\ No newline at end of file
diff --git a/bip-0040/service-blockchain.utxo.mediawiki b/bip-0040/service-blockchain.utxo.mediawiki
new file mode 100644
index 0000000000..bcc3166fb8
--- /dev/null
+++ b/bip-0040/service-blockchain.utxo.mediawiki
@@ -0,0 +1,8 @@
+=Service: Blockchain Unspent Transaction Output=
+
+* Service type: blockchain.utxo
+* Service vendor: Electrum
+
+==Method: Get Address==
+
+* Method name: get_address
\ No newline at end of file
diff --git a/bip-0040/service-wallet.mediawiki b/bip-0040/service-wallet.mediawiki
deleted file mode 100644
index 8a637d6efe..0000000000
--- a/bip-0040/service-wallet.mediawiki
+++ /dev/null
@@ -1,175 +0,0 @@
-=Service: Wallet=
-
-This service has never been properly defined. It is therefore not standardized and may be removed.
-
-* Service type: wallet
-* Service vendor: Electrum
-
-==Method: Import Seed==
-
-* Method name: import_seed
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.import_seed
-|-
-! Params [0] (seed)
-| string
-| update stomach couch actress cart dose coral slice frozen settle alarm boost
-| The seed.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| Unknown
-|}
-
-==Method: Add Public Key==
-
-* Method name: add_pubkey
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.add_pubkey
-|-
-! Params [0] (pubkey)
-| string
-| Unknown
-| The public key.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| Unknown
-|}
-
-==Method: Remove Public Key==
-
-* Method name: remove_pubkey
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.remove_pubkey
-|-
-! Params [0] (pubkey)
-| string
-| Unknown
-| The public key.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| Unknown
-|}
-
-==Method: Create transaction==
-
-* Method name: create_transaction
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.create_transaction
-|-
-! Params [0] (address)
-| string
-| 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
-| The address.
-|-
-! Params [1] (amount)
-| Unknown
-| Unknown
-| The amount.
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| string
-| 
-| Unknown
-|}
-
-==Method: Save==
-
-* Method name: save
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.save
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| Unknown
-|}
-
-==Method: Load==
-
-* Method name: load
-
-{|
-! [Request]
-! Type
-! Example
-! Description
-|-
-! Method
-| colspan="3" | wallet.load
-|-
-! [Response]
-! Type
-! Example
-! Description
-|-
-! Result
-| boolean
-| true
-| Unknown
-|}
\ No newline at end of file