Merge remote-tracking branch 'upstream/main' into mpt

.ci-config/rippled.cfg

@@ -170,3 +170,11 @@ fixNFTokenRemint
 # 2.0.0 Amendments
 XChainBridge
 DID
+# 2.2.0-b3 Amendments
+fixNFTokenReserve
+fixInnerObjTemplate
+fixAMMOverflowOffer
+PriceOracle
+fixEmptyDID
+fixXChainRewardRounding
+fixPreviousTxnID

.github/workflows/nodejs.yml

@@ -4,7 +4,7 @@
 name: Node.js CI
 
 env:
-  RIPPLED_DOCKER_IMAGE: rippleci/rippled:2.0.0-b4
+  RIPPLED_DOCKER_IMAGE: rippleci/rippled:2.2.0-b3
 
 on:
   push:

.vscode/settings.json

@@ -39,7 +39,7 @@
         "enable": true
     },
     "editor.codeActionsOnSave": {
-        "source.fixAll.eslint": true
+        "source.fixAll.eslint": "explicit"
     },
     "files.insertFinalNewline": true,
     "files.trimFinalNewlines": true,

APPLICATIONS.md

@@ -58,6 +58,10 @@ Warning: Use at your own risk.
 
   XRP Ledger explorer, API, metrics, and analytics using a graph database that is synchronized live with the XRPL.
 
+- **[XRPLWin](https://xrplwin.com)**
+
+  XRP Ledger and Xahau explorer, Hooks explorer, metrics, and analytics using a XWA backend that is synchronized live with the XRPL and Xahau.
+
 ## Data monitoring
 
 - **[zerptracker](https://zerptracker.com)**

CONTRIBUTING.md

@@ -90,7 +90,7 @@ This should be run from the `xrpl.js` top level folder (one above the `packages`
 ```bash
 npm run build
 # sets up the rippled standalone Docker container - you can skip this step if you already have it set up
-docker run -p 6006:6006 --interactive -t --volume $PWD/.ci-config:/opt/ripple/etc/ --platform linux/amd64 rippleci/rippled:2.0.0-b3 /opt/ripple/bin/rippled -a --conf /opt/ripple/etc/rippled.cfg
+docker run -p 6006:6006 --interactive -t --volume $PWD/.ci-config:/opt/ripple/etc/ --platform linux/amd64 rippleci/rippled:2.2.0-b3 /opt/ripple/bin/rippled -a --conf /opt/ripple/etc/rippled.cfg
 npm run test:browser
 ```
 

MIGRATION.md

@@ -2,12 +2,15 @@
 
 In xrpl.js 3.0, we've made significant improvements that result in a 60% reduction in bundle size for browser applications. We've also eliminated the need for polyfills with minimal disruption to existing code. This was achieved by replacing node-specific dependencies with ones that are compatible with browsers.
 
-The main change you'll notice is the update replacing `Buffer` with `Uint8Array` across the board. This was done since browsers don't support `Buffer`. Fortunately, this transition is relatively straightforward, as `Buffer` is a subclass of `Uint8Array`, meaning in many circumstances `Buffer` can be directly replaced by `Uint8Array`. The primary difference is that `Buffer` has additional helper functions. We've listed the affected client library functions below in the `Uint8Array` section for your reference.
+The two main changes you'll notice are:
+* A breaking change to `Wallet` object creation, to use a more performant algorithm by default. See [here](#8-wallet-functions-default-to-ed25519-instead-of-secp256k1-signing-algorithm) for details.
+* Replacing `Buffer` with `Uint8Array` across the board. This was done since browsers don't support `Buffer`. Fortunately, this transition is relatively straightforward, as `Buffer` is a subclass of `Uint8Array`, meaning in many circumstances `Buffer` can be directly replaced by `Uint8Array`. The primary difference is that `Buffer` has additional helper functions. We've listed the affected client library functions below in the `Uint8Array` section for your reference.
 
 This migration guide also applies to:
-`ripple-address-codec` 4.3.1 -> 5.0.0
-`ripple-binary-codec` 1.11.0 -> 2.0.0
-`ripple-keypairs` 1.3.1 -> 2.0.0
+- `ripple-address-codec` 4.3.1 -> 5.0.0
+- `ripple-binary-codec` 1.11.0 -> 2.0.0
+- `ripple-keypairs` 1.3.1 -> 2.0.0
+- `xrpl-secret-numbers` 0.3.4 -> `@xrplf/secret-numbers` 1.0.0
 
 # Why update to 3.0?
 
@@ -229,9 +232,27 @@ This was done to remove a hard dependency on `https-proxy-agent` when running
    authorization: 'authorization'
  }`
 
-### 8. Bug fix: Setting an explicit `algorithm` when generating a wallet works now
+### 8. `Wallet` functions default to `ed25519` instead of `secp256k1` signing algorithm
 
-`Wallet.generate()` and `Wallet.fromSeed` were ignoring the `algorithm` parameter. This means that if you were manually specifying `algorithm` in any `Wallet` constructors, you may generate a different `Wallet` keypair when upgrading to 3.0. In that case to get the same generated wallets as before, don’t specify the `algorithm` parameter.
+In previous releases of this library, `Wallet.generate()` and `Wallet.fromSeed` were ignoring the `algorithm` parameter. Instead, the algorithm was assumed from the seed provided; if it started with `sEd`, it would use `ed25519`, and otherwise it would use `secp256k1`. However, seeds do not actually have algorithms; a seed starting with `s...` can still use the `ed25519` algorithm.
+
+With 3.0, we updated the default signing algorithm used by the `Wallet` object to always be `ed25519` in order to default to the higher-performance algorithm. This is a breaking change to all functions used to generate a Wallet, so if you have a pre-existing XRPL account that you're using to generate a specific Wallet using older versions of xrpl.js, you may need to specify that you are using `secp256k1` as the algorithm to decode your private key / seed / etc to get the same behavior as before. See below for specifically how to update your code.
+
+If you are creating new accounts each time (ex. via `Client.fundWallet` or `Wallet.generate`), you do not need to specify the signing algorithm.
+
+**Before**
+```
+Wallet.fromSeed('s...')
+Wallet.fromEntropy(entropy)
+deriveKeyPair(seed="s...")
+```
+
+**After**
+```
+Wallet.fromSeed(seed='s...',algorithm: 'ecdsa-secp256k1')
+Wallet.fromEntropy(entropy, opts={algorithm: 'ecdsa-secp256k1'})
+deriveKeypair(seed='s...', opts={ algorithm: 'ecdsa-secp256k1' }) (ripple-keypairs)
+```
 
 ### 9. `AssertionError` → `Error`