Merge branch 'master' into dimitris/subnet-id

.github/workflows/check-cddl-candid.yml

@@ -13,7 +13,7 @@ jobs:
         docker run --rm -v $PWD/spec/_attachments:/workdir ghcr.io/anweiss/cddl-cli:0.9.1 compile-cddl --cddl /workdir/requests.cddl
     - name: Check candid files
       run: |
-        curl -L https://github.com/dfinity/candid/releases/download/2023-05-26/didc-linux64 -o didc
+        curl -L https://github.com/dfinity/candid/releases/download/2023-07-25/didc-linux64 -o didc
         chmod +x didc
         ./didc check spec/_attachments/http-gateway.did
         ./didc check spec/_attachments/ic.did

spec/_attachments/ic.did

@@ -180,7 +180,9 @@ service ic : {
 
   // bitcoin interface
   bitcoin_get_balance: (get_balance_request) -> (satoshi);
+  bitcoin_get_balance_query: (get_balance_request) -> (satoshi) query;
   bitcoin_get_utxos: (get_utxos_request) -> (get_utxos_response);
+  bitcoin_get_utxos_query: (get_utxos_request) -> (get_utxos_response) query;
   bitcoin_send_transaction: (send_transaction_request) -> ();
   bitcoin_get_current_fee_percentiles: (get_current_fee_percentiles_request) -> (vec millisatoshi_per_byte);
 

spec/index.md

@@ -2092,6 +2092,22 @@ A `get_utxos_request` without the optional `filter` results in a request that co
 
 The recommended workflow is to issue a request with the desired number of confirmations. If the `next_page` field in the response is not empty, there are more UTXOs than in the returned vector. In that case, the `page` field should be set to the `next_page` bytes in the subsequent request to obtain the next batch of UTXOs.
 
+### IC method `bitcoin_get_utxos_query` {#ic-bitcoin_get_utxos_query}
+
+This method is identical to [`bitcoin_get_utxos`](#ic-bitcoin_get_utxos), but exposed as a query.
+
+:::note
+
+This query is only accessible in non-replicated mode. Calls in replicated mode are rejected.
+
+:::
+
+:::warning
+
+The response of a query comes from a single replica, and is therefore not appropriate for security-sensitive applications.
+
+:::
+
 ### IC method `bitcoin_get_balance` {#ic-bitcoin_get_balance}
 
 Given a `get_balance_request`, which must specify a Bitcoin address and a Bitcoin network (`mainnet` or `testnet`), the function returns the current balance of this address in `Satoshi` (10^8 Satoshi = 1 Bitcoin) in the specified Bitcoin network. The same address formats as for [`bitcoin_get_utxos`](#ic-bitcoin_get_utxos) are supported.
@@ -2102,6 +2118,22 @@ The optional `min_confirmations` parameter can be used to limit the set of consi
 
 Given an address and the optional `min_confirmations` parameter, `bitcoin_get_balance` iterates over all UTXOs, i.e., the same balance is returned as when calling [`bitcoin_get_utxos`](#ic-bitcoin_get_utxos) for the same address and the same number of confirmations and, if necessary, using pagination to get all UTXOs for the same tip hash.
 
+### IC method `bitcoin_get_balance_query` {#ic-bitcoin_get_balance_query}
+
+This method is identical to [`bitcoin_get_balance`](#ic-bitcoin_get_balance), but exposed as a query.
+
+:::note
+
+This query is only accessible in non-replicated mode. Calls in replicated mode are rejected.
+
+:::
+
+:::warning
+
+The response of a query comes from a single replica, and is therefore not appropriate for security-sensitive applications.
+
+:::
+
 ### IC method `bitcoin_send_transaction` {#ic-bitcoin_send_transaction}
 
 Given a `send_transaction_request`, which must specify a `blob` of a Bitcoin transaction and a Bitcoin network (`mainnet` or `testnet`), several checks are performed: