chore(release): nextnet 0.49.0-rc.0 #5315
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Description --- Updates to the new tari-crypto version. Motivation and Context --- Have access to the `from_vec` functionality for `CommitmentSignature`. How Has This Been Tested? --- <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- Update tari crypto dependency version to v0.16.8. Motivation and Context --- How Has This Been Tested? --- Run `cargo build` <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
…ari-project#5238) Description --- Derives and uses domain-separated ECDH shared secret for burnt output commitment mask and encrypted value. Motivation and Context --- Previously, the DAN layer can claim the burnt output and deposit it into an account. However, the mask and value were known only to the L1 wallet, meaning that the claimed funds could not be spent. The PR uses an ECDH shared secret and allows the DAN wallet to derive the shared secret in the same way that it does for any other confidential transfer. The console wallet will generate $H(k.A)$ where $A$ is the claim key provided by the user and $k$ is a blinding factor generated using the console wallet's seed key. Usually, this will be the key that owns the account component (ref: tari-project/tari-dan#425). The public blinding factor (`reciprocal_claim_public_key`) is returned to the `burn_tari` caller and is passed to the `ClaimBurn` instruction, which in turn, 'mints' the <commitment, reciprocal_claim_public_key, encrypted_value> ConfidentailResource tuple. NOTE: Burns UTXOs _are not_ recoverable because the wallet cannot determine the mask/decrypt the value without the original claim_public_key which is not stored on-chain. How Has This Been Tested? --- Existing cucumber test for burn execute part of the code modified in this PR, however test coverage needs to be improved <!-- Does this include a breaking change? If so, include this line as a footer --> BREAKING CHANGE: `burn_tari` GRPC response changed (re-add proto to POSTman if you use that).
…t#5232) Description --- Introduces necessary trait bounds to the `BalancedBinaryMerkleProof` struct. Motivation and Context --- In order to update the Tari DAN layer repo to make use of BMTs, we need that the current struct `BalancedBinaryMerkleProof` derives certain trait bounds, namely `#[derive(Clone, PartialEq, Eq, Deserialize, Serialize)]`. How Has This Been Tested? --- Run `cargo build`. <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- Fixes the default options text in the provided default config
Description --- - Adds confidential claim data to chain when burn_tari is invoked with claim_public_key set. - Updates output recovery in wallet to recover burnt outputs Motivation and Context --- Claim key is required for mask and value recovery of burnt funds on L2. Unfortunately, since burnt outputs are not part of the utxo set, the wallet does not receive these outputs when recovering. Resolving this is out of scope for this PR. How Has This Been Tested? --- Manually: normal wallet recovery OK. Resync base node OK. <!-- Does this include a breaking change? If so, include this line as a footer --> BREAKING CHANGE: Not database or network breaking, but a chain split will occur if a burnt utxo with the claim public key set is broadcast and some nodes have not upgraded.
Description --- Refactor contacts and the contact service out of the wallet crate and into it's own crate to be included anywhere needed. Motivation and Context --- Wallet doesn't need to manage contacts, and we'll want contacts for other applications so having it as it's own crate makes it portable. How Has This Been Tested? --- ~Entirely untested. I haven't run this code, only trusting the compiler. Do not merge.~ Tested manually by running the wallet. Many failing tests caught and corrected via CI.
Description Release 1.68 of rust has changed the default for NDK - https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html Targeted Android build using cross container tagged edge over latest. Motivation and Context Fix libwallet build for Android. How Has This Been Tested? Build locally and in local fork
…i-project#5245) Description --- - derives encryption key using DH shared spend key - use consensus hasher to ensure consistent hash preimages - recovered blinding factor is the shared key, so logic updated not to calculate another Diffie-Helman from the claim key Motivation and Context --- Mask and encrypted value key derivation currently should match confidential claims and transfers on the DAN layer. ``` shared_key = DH(claim_pubkey, spend_key) shared_mask = dan_mask_kdf(shared_key) commitment = commit(shared_mask, value) shared_value_encryption_key = dan_encrypted_value_kdf(shared_mask, commitment) encrypted_value = encrypt(shared_value_encryption_key, value) ``` How Has This Been Tested? --- Tested that claims work on the DAN <!-- Does this include a breaking change? If so, include this line as a footer --> BREAKING CHANGE: Burn with claim mask and encrypted value key derivation has changed. Existing burnt funds are not claimable on the DAN.
Description --- Fail to compile on 32-bit architectures Motivation and Context --- 32-bit architectures are untested. Depending on the application, it may not compile already or there could be various classes of bugs (overflows, crashes, etc). This PR explicitly fails compilation to 32-bit targets for all applications. How Has This Been Tested? --- CI <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- This commit does a naive character replacement on the string path just before we do the path injection. Motivation and Context --- log4rs expects the paths to be in a unix format regardless of the system it's running on. When we started doing the dynamic injecting of the base path windows systems injected using a windows format, which mixed with the unix format. Resulting in strings that looked liked this: `C:\\brianp\.tari\config/log/base-node/network.log` when log4rs wants the final format to be like this: `C://brianp/.tari/config/log/base-node/network.log` How Has This Been Tested? --- Manually on Hansie's windows machine Co-authored-by: hansieodendaal 39146854+hansieodendaal@users.noreply.github.com
…ct#5235) Description --- Fix mislabelled transaction builder checks for change params Motivation and Context --- Previous code just checked the private nonce 3 times ```rust Self::check_value("Change script", &self.private_nonce, &mut message); Self::check_value("Change input data", &self.private_nonce, &mut message); Self::check_value("Change script private key", &self.private_nonce, &mut message); ``` None of the change builder fields are required. How Has This Been Tested? --- N/A Change has no effect on builder behaviour <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
…ri-project#5227 (tari-project#5246) Description --- Now wallet revalidates all transactions included in the wallet on startup. tari-project#5227 Motivation and Context --- Outputs fetched from a fully synced node could be invalidated by the transaction validator, e.g. wallet has normal outputs, fully validated, but at some point become invalidated when the wallet is trying to negotiate with another, not yet fully synced node that doesn't recognise said output due to not reaching its height at the moment. So, the code was already there but not yet used in the startup process. How Has This Been Tested? --- manually <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
Description --- This creates a new genesis block for Esmeralda How Has This Been Tested? --- Unit tests Breaking Changes --- - [] None - [x] Requires data directory on base node to be deleted - [x] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> New genesis block, resets the chain
### ⚠ BREAKING CHANGES * **wallet:** ensure burn shared keys and hashes match dan layer (5245) * add claim public key to OutputFeatures (5239) * reset esmeralda (5247) ### Features * add claim public key to OutputFeatures ([5239](tari-project#5239)) ([3e7d82c](tari-project@3e7d82c)) * reset esmeralda ([5247](tari-project#5247)) ([aa2a3ad](tari-project@aa2a3ad)) ### Bug Fixes * added transaction revalidation to the wallet startup sequence [5227](tari-project#5227) ([5246](tari-project#5246)) ([7b4e2d2](tari-project@7b4e2d2)) * immediately fail to compile on 32-bit systems ([5237](tari-project#5237)) ([76aeed7](tari-project@76aeed7)) * **wallet:** correct change checks in transaction builder ([5235](tari-project#5235)) ([768a0cf](tari-project@768a0cf)) * **wallet:** ensure burn shared keys and hashes match dan layer ([5245](tari-project#5245)) ([024ce64](tari-project@024ce64)) * windows path format in log4rs files ([5234](tari-project#5234)) ([acfecfb](tari-project@acfecfb))
Description --- Fixes the build for the `wallet.h` file How Has This Been Tested? --- manual Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
## [0.49.0-pre.2](tari-project/tari@v0.49.0-pre.1...v0.49.0-pre.2) (2023-03-16) ### Bug Fixes * ffi hot fix ([5251](tari-project#5251)) ([9533e40](tari-project@9533e40)) ## [0.49.0-pre.1](tari-project/tari@v0.49.0-pre.0...v0.49.0-pre.1) (2023-03-15)
Description
---
Reduces debug log in scanner from WARN to DEBUG
Reduces `select_utxos selection criteria: {}` log to DEBUG
Motivation and Context
---
Lots of false warning messages in cucumber logs
```
07:51 WARN Last scanned block found at height 30 (Header Hash: a55cf603f5cdad623e7e2355535d79d1af02c7c6f04ca7b5e44dd113bd0d9d5a)
07:51 WARN Last scanned block found at height 32 (Header Hash: 676377e924ea94afdd2297607b10c0aeb1c8ad4e93d57f27fdb3842cd0ae8e1b)
07:51 WARN Last scanned block found at height 33 (Header Hash: 3697fc22292f1eeb828c83bfa5281542cbfc3996b06985209ff1a7edfd2fd8be)
WARN select_utxos selection criteria: filter: Standard, ordering: Default
```
How Has This Been Tested?
---
N/A
What process can a PR reviewer use to test or verify this change?
---
Less warning messages in CI
Breaking Changes
---
- [x] None
- [ ] Requires data directory on base node to be deleted
- [ ] Requires hard fork
- [ ] Other - Please specify
<!-- Does this include a breaking change? If so, include this line as a
footer -->
<!-- BREAKING CHANGE: Description what the user should do, e.g. delete a
database, resync the chain -->
Description
---
Fixes the wallet sending out `/ip4/0.0.0.0` as its address to a
base_node as its address
Motivation and Context
---
`0.0.0.0` is a local address and when connecting to the a base_node the
base_node rejects the wallet with:
`InvalidMultiaddr("Non-global IP addresses are invalid")`
How Has This Been Tested?
---
Manual
Breaking Changes
---
- [x] None
- [ ] Requires data directory on base node to be deleted
- [ ] Requires hard fork
- [ ] Other - Please specify
<!-- Does this include a breaking change? If so, include this line as a
footer -->
<!-- BREAKING CHANGE: Description what the user should do, e.g. delete a
database, resync the chain -->
## [0.49.0-pre.3](tari-project/tari@v0.49.0-pre.2...v0.49.0-pre.3) (2023-03-20) ### Bug Fixes * reduce warn log to debug in utxo scanner ([5256](tari-project#5256)) ([3946641](tari-project@3946641)) * wallet sending local address out to network ([5258](tari-project#5258)) ([6bfa6f9](tari-project@6bfa6f9))
Description --- Reverts and freezes `wasm-pack@0.10.3` due to an apparent upstream issue. Fixes (at least temporarily) [issue 5261](tari-project#5261). Motivation and Context --- There's an apparent issue with the `wasm-pack` Node.js module at the 0.11.0 version that breaks CI operations (and which [also affects](tari-project/tari-crypto#174) `tari-crypto`). While an [earlier PR](tari-project#5258) disabled this CI, it seems unnecessary and somewhat risky not to have these tests. Reverting to the 0.10.3 version is at least a temporary fix. How Has This Been Tested? --- With the fix, CI should pass. What process can a PR reviewer use to test or verify this change? --- Run the equivalent commands locally, and ensure that CI passes with the change. Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify
Description Add TestNet for tagged releases for binaries and package builds Motivation and Context Split out the different networks when build on GitHub Co-authored-by: Stan Bondi <sdbondi@users.noreply.github.com>
Description --- Clarifies the docs on version updates. Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify
…t#5252 (tari-project#5263) Description --- - Network and client APP_VERSION_NUMBER is now stored when wallet is initialized. - Added FFI function `wallet_get_network_and_version` that returns the `network` and `version` of the client that has last accessed the wallet database. Motivation and Context --- For debugging purposes on the client (e.g. Mobile) How Has This Been Tested? --- manually --------- Co-authored-by: SW van Heerden <swvheerden@gmail.com> Co-authored-by: stringhandler <mikethetike@tari.com>
## [0.49.0-pre.4](tari-project/tari@v0.49.0-pre.3...v0.49.0-pre.4) (2023-03-24) ### Features * added FFI function `wallet_get_network_and_version` [5252](tari-project#5252) ([tari-project#5263](tari-project#5263)) ([4b09b59](tari-project@4b09b59))
Description --- Update readme to include recommended versions for each network. Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> --------- Co-authored-by: stringhandler <stringhandler@gmail.com>
…-project#5282) Description --- Changes the challenges of all signatures to not be `Hash(Key||Nonce||Feat_1||Feat_2||..||Feat_x) `but rather `Hash(Key||Nonce||Hash(Feat_1||Feat_2||..||Feat_x))` Adds the version to the kernel signature as this is currently not checked. Motivation and Context --- This is done because hardware devices need to sign all the data they need to be sent over to the hardware device to be signed. If we have to send all the features over this becomes quite significant in bytes. This is now changed to only send the `message` field as a single 32-byte array and this still comments to all the features. The kernel version is technically malleable as the version is not committed to in the signature, this is now fixed. How Has This Been Tested? --- All tests pass What process can a PR reviewer use to test or verify this change? --- Make sure all chain signatures are changed. Adds version to Kernel signature Breaking Changes --- Change all chain signature challenges: Kernel, Script, Metadata - [x] None - [x] Requires data directory on base node to be deleted - [x] Requires hard fork - [x] Other - Please specify Complete chain reset. <!-- Does this include a breaking change? If so, include this line as a footer --> BREAKING CHANGE: Complete chain reset
We currently use a tagged version of `tari_crypto` and `tari_utilities`, this is useful when there are many changes to those crates and we want to use a specific version, but with the `tari_dan` crates also using them, it means the libraries must all be updated at the same time. Using `crates.io` versions means that the end applications will be able to choose a version that works, adhering to semver rules
Description --- Resets the dates for the following networks: Esmeralda: Today Nextnet: April 14th Stagenet: Jun 14 Motivation and Context --- For Nextnet and Stagenet these are the dates when these changes come into effect. Esmeralda had a new Gen block as of PR tari-project#5282 How Has This Been Tested? --- Unit tests What process can a PR reviewer use to test or verify this change? --- Breaking Changes --- - [x] None - [x] Requires data directory on base node to be deleted - [x] Requires hard fork - [x] Other - Please specify New Gen block, requires network reset <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> Co-authored-by: Cayle Sharrock <CjS77@users.noreply.github.com>
Description --- - Updated the igor genesis block to contain a faucet with revealed values - Added a new range-proof option for the genesis block sanity test Motivation and Context --- - Evaluating faucet with revealed values How Has This Been Tested? --- - Unit test demonstrating the range proof for each output in the faucet - Performed system-level testing to demonstrate that the igor blockchain works properly - 2x base nodes, 2x wallets, 1x SHA3 miner, 1x merge mining proxy, 1x XMRig miner. What process can a PR reviewer use to test or verify this change? --- Perform system-level testing Breaking Changes --- - [ ] None - [x] Requires data directory on base node to be deleted - [ ] Requires hard fork - [x] Other - New genesis block. BREAKING CHANGE: The chain has to be restarted - delete the blockchain database and resync the chain --------- Co-authored-by: stringhandler <mikethetike@tari.com> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
…roject#5109 (tari-project#5257) Description --- Extra function argument to `wallet_create` FFI. tari-project#5109 Motivation and Context --- Giving mobile app more information about the active base node connection. How Has This Been Tested? --- --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: stringhandler <stringhandler@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Aaron Feickert <66188213+AaronFeickert@users.noreply.github.com> Co-authored-by: C.Lee Taylor <47312074+leet4tari@users.noreply.github.com> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
PR tari-project#4942 added a row to the tx detail view, but did not increase the size of the box. As a result, the maturity is cut off. This PR makes the detail box one row wider, and adjusts the minimum size of the tx box to be 8 (this is the absolute minimum -- accounting for headers and one each of pending and completed txs). Fixes tari-project#5289 ``` Tari Console Wallet────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Transactions │ Send │ Receive │ Contacts │ Network │ Events │ Log │ Notifications │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ┌Balance────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │Available: 0 µT (Time Locked: 0 µT) Pending Incoming: 0 µT Pending Outgoing: 0 µT │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ Up↑/Down↓ select Tx (C) cancel selected pending Txs (A) show/hide mining (R) rebroadcast Txs (Esc) exit list ┌Completed (T)ransactions (0) ──────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Source/Destination Address Amount/Token Mined At (Local) Status │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ┌Transaction Details────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │TxID: │ │Source Address: │ │Destination address: │ │Direction: │ │Amount: │ │Fee: │ │Status: │ │Message: │ │Mined At (Local): │ │Imported At (Local): │ │Excess: │ │Confirmations: │ │Mined Height: │ │Maturity: │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ Base Node Status - Chain Tip: #12365 Synced. Latency 562 ms Connected Base Node ID: 99999903f5951fa1ca9505c3c2 ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Network: stagenet Version: 0.49.0-pre.5 LeftArrow: Previous Tab Tab/RightArrow: Next Tab F10/Ctrl-Q: Quit ```
Description --- Moves the key_manager_services to key_manager_create Motivation and Context --- Currently, all transactions are built by supplying private keys to the constructor. The wallet implements a Key_manager_service that safely constructs the private key but this is then passed around in code to where it is used to sign transactions etc. We want to refactor this, that the code only ask for a signature and not a private key. This means the private key generation should happen where core can access it. This will be refactored in a future PR. This is part of allowing support of Hardware devices in the future. How Has This Been Tested? --- Unit tests and manual tx sending Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [x] Other - Please specify Requires data directory to be deleted on the wallet <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> BREAKING CHANGE: Requires data directory to be deleted on the wallet because it changes how the wallet database structure looks.
## [0.49.0-pre.6](tari-project/tari@v0.49.0-pre.5...v0.49.0-pre.6) (2023-04-05) ### ⚠ BREAKING CHANGES * move key manager service to key_manager (5284) * add igor faucet (5281) * reset dates for networks (5283) ### Features * add igor faucet ([5281](tari-project#5281)) ([bfc92fd](tari-project@bfc92fd)) * added auxiliary callback to push base node state changes [5109](tari-project#5109) ([tari-project#5257](tari-project#5257)) ([b7f7d31](tari-project@b7f7d31)) * move key manager service to key_manager ([5284](tari-project#5284)) ([d50ed02](tari-project@d50ed02)) * reset dates for networks ([5283](tari-project#5283)) ([d6342a4](tari-project@d6342a4)) ### Bug Fixes * resize transaction tab windows ([5290](tari-project#5290)) ([bd95a85](tari-project@bd95a85)), closes [tari-project#4942](tari-project#4942) [tari-project#5289](tari-project#5289) [#12365](https://github.com/tari-project/tari/issues/12365)
…ect#5294) Description add TARI_NETWORK env support in GHA docker builds Motivation and Context Support ```TARI_NETWORK``` env selection from git tag in docker builds How Has This Been Tested? Build locally and in local fork Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- Added extended mask recovery where the proof may contain a minimum value promise > 0 Motivation and Context --- See [tari-project#5297](tari-project#5297) How Has This Been Tested? --- What process can a PR reviewer use to test or verify this change? --- Unit test `fn test_output_rewinding_bulletproofs()` expanded to cater for mask recovery with minimum value promise > 0 Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- Fixed RPC transaction proto conversion Motivation and Context --- With the RPC conversion `minimum_value_promise` was zeroed instead of assigned See tari-project#5295 How Has This Been Tested? --- What process can a PR reviewer use to test or verify this change? --- Run a system-level test to submit a transaction via gRPC to a base node where an output has `minimum_value_promise != 0` and then mine the transaction Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- This PR is for reflective purposes regarding feature gating at compile time. See tari-project#5135 for more info. This PR as it stands is to be used as an example of a network _type_ based feature gate at compile time. It allows setting an ENVVAR for the network with conditional compilation for features. The feature sets can be imported across any crate in the project easily and then used with the `#[cfg(tari_feature_...)]` attribute macro. I've also introduced a secondary commit for binaries to perform a quick network check against itself to ensure the intended network is supported by the binary. This check is made non-invasive (not conditionally compiling possible network) as that method of check ends up being much more tedious. Motivation and Context --- We want some features on some networks, but maybe not all. How Has This Been Tested? --- Manually What process can a PR reviewer use to test or verify this change? --- Compile a binary with a set network `TARI_NETWORK=nextnet cargo build --release --bin tari_base_node` then run the binary with a test network as a parameter: `./tari_base_node --network esme` and receive an error: ``` The application exited because of an internal network error. The network esmeralda is invalid for this binary built for NextNet ``` *Please note* That running the binary will cause the build to default to the test network _always_. Meaning this will not work: ``` $ TARI_NETWORK=nextnet cargo build --release --bin tari_base_node $ cargo run --release --bin tari_base_node --network nextnet ``` The second command `cargo run` will re-build the binary, and without the `TARI_NETWORK` env set the binary will default to a test binary. In development if you want to call run and connect to a non test network you need to also pass the TARI_NETWORK envvar instead of the `--network` flag. `TARI_NETWORK=nextnet cargo run --bin tari_base_node --release -- --network nextnet` Breaking Changes --- - [x] None --------- Co-authored-by: Cayle Sharrock <CjS77@users.noreply.github.com> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
…ari-project#5291) Description --- This PR does two jobs (sorry). Mostly because they're dependent tasks. - Add `--network` to the miners for simple setting switches - Add the network into the data directory path Motivation and Context --- This can be used to help select the default ports of communication for the base node and wallet, and also easily keeping network id's and folders separate. How Has This Been Tested? --- Manually What process can a PR reviewer use to test or verify this change? --- Run a base node, wallet, and miner. Set a base directory path as something like `-b ./data/mytest` and the network to igor `--network igor` and watch in amazement as the data directory `./data/mytest/igor/` is created to store information. Closes tari-project#5272 Closes tari-project#5273 Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> --------- Co-authored-by: SW van Heerden <swvheerden@gmail.com>
Description --- Adds paging to the utxo stream to handle the large amount of faucet utxos Motivation and Context --- See: tari-project#5299 How Has This Been Tested? --- unit tests Fixes: tari-project#5299 What process can a PR reviewer use to test or verify this change? --- See PR tari-project#5298 Breaking Changes --- Changes request service - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- removes unused dependencies via `cargo machete` How Has This Been Tested? --- ran cargo machete All unit tests cargo build --all-features Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- Add dan wallet daemon config part. Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
Description --- This commit make a simple switch to define Network::default differently for the different bins compiled for different networks. Motivation and Context --- Making us one step closer to smarter defaults, and one click, out of the box. How Has This Been Tested? --- Manually What process can a PR reviewer use to test or verify this change? --- Compile the bin with `TARI_NETWORK=...` then validate the bin uses the correct default Fixes: tari-project#5310 Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
Description --- Add traits that are needed in tari-dan for merged mmr proof. Breaking Changes --- - [x] None - [ ] Requires data directory on base node to be deleted - [ ] Requires hard fork - [ ] Other - Please specify <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain --> Co-authored-by: SW van Heerden <swvheerden@gmail.com>
Description --- Add flow and manifest code template types Motivation and Context --- Composing templates into a single wasm is not always practical. This change allows users to wire together multiple templates using a flow or manifest How Has This Been Tested? --- locally <!-- Does this include a breaking change? If so, include this line as a footer --> <!-- BREAKING CHANGE: Description what the user should do, e.g. delete a database, resync the chain -->
## [0.50.0-pre.0](tari-project/tari@v0.49.0-pre.6...v0.50.0-pre.0) (2023-04-12) ### ⚠ BREAKING CHANGES * add paging to utxo stream request (5302) ### Features * add extended mask recovery ([5301](tari-project#5301)) ([23d882e](tari-project@23d882e)) * add network name to data path and --network flag to the miners ([5291](tari-project#5291)) ([1f04beb](tari-project@1f04beb)) * add other code template types ([5242](tari-project#5242)) ([93e5e85](tari-project@93e5e85)) * add paging to utxo stream request ([5302](tari-project#5302)) ([3540309](tari-project@3540309)) * add wallet daemon config ([5311](tari-project#5311)) ([30419cf](tari-project@30419cf)) * define different network defaults for bins ([5307](tari-project#5307)) ([2f5d498](tari-project@2f5d498)) * feature gates ([5287](tari-project#5287)) ([72c19dc](tari-project@72c19dc)) * fix rpc transaction conversion ([5304](tari-project#5304)) ([344040a](tari-project@344040a))
ghpbot-tari-project
added
the
CR-too_long
ghpbot-tari-project
added
the
P-acks_required
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Rolling out development to NextNet.
Motivation and Context
Keeping things fresh.
How Has This Been Tested?
Well it will be, that's for sure.
What process can a PR reviewer use to test or verify this change?
Breaking Changes