diff --git a/configure.ac b/configure.ac
index 85ea415d1..a90ec9bbf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,7 @@ define(_CLIENT_VERSION_MAJOR, 0)
define(_CLIENT_VERSION_MINOR, 21)
define(_CLIENT_VERSION_REVISION, 2)
define(_CLIENT_VERSION_BUILD, 0)
-define(_CLIENT_VERSION_RC, 7)
+define(_CLIENT_VERSION_RC, 0)
define(_CLIENT_VERSION_IS_RELEASE, true)
define(_COPYRIGHT_YEAR, 2022)
define(_COPYRIGHT_HOLDERS,[The %s developers])
diff --git a/doc/litecoin-release-notes/release-notes-0.21.2.md b/doc/litecoin-release-notes/release-notes-0.21.2.md
new file mode 100644
index 000000000..c3eb1c8cd
--- /dev/null
+++ b/doc/litecoin-release-notes/release-notes-0.21.2.md
@@ -0,0 +1,120 @@
+Litecoin Core version 0.21.2 is now available from:
+
+ .
+
+This is the largest update ever, providing full node, wallet, and mining support for MWEB.
+
+Please report bugs using the issue tracker at GitHub:
+
+
+
+To receive security and update notifications, please subscribe to:
+
+
+
+
+How to upgrade:
+==============
+
+Firstly, thank you for running Litecoin Core and helping secure the network!
+
+As you’re running an older version of Litecoin Core, shut it down. Wait until it’s completely shut down - which might take a few minutes for older versions - then follow these simple steps:
+For Windows: simply run the installer
+For Mac: copy over to `/Applications/Litecoin-Qt`
+For Linux: copy cover `litecoind`/`litecoin-qt`.
+
+NB: upgrading directly from an ‘end of life’ version of Litecoin Core is possible, but it might take a while if the data directory needs to be migrated. Old wallet versions of Litecoin Core are generally supported.
+
+
+Compatibility:
+==============
+
+Litecoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.10+, Windows 7 and newer. It’s not recommended to use Litecoin Core on unsupported systems.
+
+Litecoin Core should also work on most other Unix-like systems, but is not as frequently tested on them.
+
+MWEB fields added to BlockIndex, and block serialization format has changed. Downgrading to older versions is unsafe.
+
+If upgrading to 0.21.2 *after* MWEB has activated, you must resync to download MWEB blocks.
+
+Notable changes
+===============
+
+Consensus changes
+-----------------
+
+- This release implements the proposed MWEB consensus rules
+ ([LIP002](https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki),
+ [LIP003](https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki), and
+ [LIP004](https://github.com/litecoin-project/lips/blob/master/lip-0004.mediawiki))
+
+P2P and network changes
+-----------------------
+
+- A new service flag, NODE_MWEB (1 << 24), was added to signal to peers that the node supports MWEB.
+ When connected peers both advertise this capability, they are expected to provide all MWEB data when
+ sharing transactions, blocks, and compact blocks with each other.
+
+- Nodes now announce compact block version 3 support, informing peers that they can provide MWEB data
+ in compact blocks.
+
+
+Updated RPCs
+------------
+
+- `getblockheader` now returns an additional `mweb_header` field containing
+ all of the MWEB header data, and an `mweb_amount` field containing the total
+ number of coins pegged-in to the MWEB after applying the block.
+
+- `getblock` now returns an additional `mweb` field containing MWEB header info,
+ and all of the inputs, outputs, and kernels in the MWEB block.
+
+- Added `mwebweight`, `descendantmwebweight`, `ancestormwebweight`, and `mweb`
+ fields to `getrawmempool`, `getmempoolancestors`, `getmempooldescendants`,
+ and `getmempoolentry`.
+
+- Added new fields to describe MWEB transaction inputs, outputs, and kernels
+ for `getrawtransaction`.
+
+Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
+
+New settings
+------------
+
+- Added "fMWEBFeatures" option for enabling the new "Advanced MWEB Features"
+ control.
+
+Wallet Database
+---------------
+
+- Added "mweb_coin" type which stores MWEB coins and their derived keys.
+
+- Added CHDChain version 4 which includes an MWEB key index counter and
+ the stealth address scan key.
+
+- Added CKeyMetadata version 14 which includes the MWEB key index.
+
+- Added FEATURE_MWEB = 210000 minimum database version.
+
+Wallet RPC changes
+------------------
+
+- Added 'listwallettransactions' which matches the transaction list display values.
+
+GUI changes
+-----------
+
+- Added an "Advanced MWEB Features" control for testing. It’s only available
+ when the "-debug" argument is supplied, and the option is turned on in the
+ settings dialog.
+
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- [The Bitcoin Core Developers]
+- DavidBurkett
+- hectorchu
+- losh11
\ No newline at end of file
diff --git a/doc/release-notes.md b/doc/release-notes.md
index e778b75a6..c3eb1c8cd 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,203 +1,120 @@
-0.21.1 Release Notes
-====================
+Litecoin Core version 0.21.2 is now available from:
-Bitcoin Core version 0.21.1 is now available from:
+ .
-
-
-This minor release includes various bug fixes and performance
-improvements, as well as updated translations.
+This is the largest update ever, providing full node, wallet, and mining support for MWEB.
Please report bugs using the issue tracker at GitHub:
-
+
To receive security and update notifications, please subscribe to:
-
+
-How to Upgrade
+
+How to upgrade:
==============
-If you are running an older version, shut it down. Wait until it has completely
-shut down (which might take a few minutes in some cases), then run the
-installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
-or `bitcoind`/`bitcoin-qt` (on Linux).
+Firstly, thank you for running Litecoin Core and helping secure the network!
-Upgrading directly from a version of Bitcoin Core that has reached its EOL is
-possible, but it might take some time if the data directory needs to be migrated. Old
-wallet versions of Bitcoin Core are generally supported.
+As you’re running an older version of Litecoin Core, shut it down. Wait until it’s completely shut down - which might take a few minutes for older versions - then follow these simple steps:
+For Windows: simply run the installer
+For Mac: copy over to `/Applications/Litecoin-Qt`
+For Linux: copy cover `litecoind`/`litecoin-qt`.
-Compatibility
+NB: upgrading directly from an ‘end of life’ version of Litecoin Core is possible, but it might take a while if the data directory needs to be migrated. Old wallet versions of Litecoin Core are generally supported.
+
+
+Compatibility:
==============
-Bitcoin Core is supported and extensively tested on operating systems
-using the Linux kernel, macOS 10.14+, and Windows 7 and newer. Bitcoin
-Core should also work on most other Unix-like systems but is not as
-frequently tested on them. It is not recommended to use Bitcoin Core on
-unsupported systems.
+Litecoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.10+, Windows 7 and newer. It’s not recommended to use Litecoin Core on unsupported systems.
-From Bitcoin Core 0.22.0 onwards, macOS versions earlier than 10.14 are no
-longer supported. Additionally, Bitcoin Core does not yet change appearance
-when macOS "dark mode" is activated.
+Litecoin Core should also work on most other Unix-like systems, but is not as frequently tested on them.
+
+MWEB fields added to BlockIndex, and block serialization format has changed. Downgrading to older versions is unsafe.
+
+If upgrading to 0.21.2 *after* MWEB has activated, you must resync to download MWEB blocks.
Notable changes
===============
-## Taproot Soft Fork
+Consensus changes
+-----------------
-Included in this release are the mainnet and testnet activation
-parameters for the taproot soft fork (BIP341) which also adds support
-for schnorr signatures (BIP340) and tapscript (BIP342).
+- This release implements the proposed MWEB consensus rules
+ ([LIP002](https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki),
+ [LIP003](https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki), and
+ [LIP004](https://github.com/litecoin-project/lips/blob/master/lip-0004.mediawiki))
-If activated, these improvements will allow users of single-signature
-scripts, multisignature scripts, and complex contracts to all use
-identical-appearing commitments that enhance their privacy and the
-fungibility of all bitcoins. Spenders will enjoy lower fees and the
-ability to resolve many multisig scripts and complex contracts with the
-same efficiency, low fees, and large anonymity set as single-sig users.
-Taproot and schnorr also include efficiency improvements for full nodes
-such as the ability to batch signature verification. Together, the
-improvements lay the groundwork for future potential
-upgrades that may improve efficiency, privacy, and fungibility further.
+P2P and network changes
+-----------------------
-Activation for taproot is being managed using a variation of BIP9
-versionbits called Speedy Trial (described in BIP341). Taproot's
-versionbit is bit 2, and nodes will begin tracking which blocks signal
-support for taproot at the beginning of the first retarget period after
-taproot’s start date of 24 April 2021. If 90% of blocks within a
-2,016-block retarget period (about two weeks) signal support for taproot
-prior to the first retarget period beginning after the time of 11 August
-2021, the soft fork will be locked in, and taproot will then be active
-as of block 709632 (expected in early or mid November).
+- A new service flag, NODE_MWEB (1 << 24), was added to signal to peers that the node supports MWEB.
+ When connected peers both advertise this capability, they are expected to provide all MWEB data when
+ sharing transactions, blocks, and compact blocks with each other.
-Should taproot not be locked in via Speedy Trial activation, it is
-expected that a follow-up activation mechanism will be deployed, with
-changes to address the reasons the Speedy Trial method failed.
+- Nodes now announce compact block version 3 support, informing peers that they can provide MWEB data
+ in compact blocks.
-This release includes the ability to pay taproot addresses, although
-payments to such addresses are not secure until taproot activates.
-It also includes the ability to relay and mine taproot transactions
-after activation. Beyond those two basic capabilities, this release
-does not include any code that allows anyone to directly use taproot.
-The addition of taproot-related features to Bitcoin Core's wallet is
-expected in later releases once taproot activation is assured.
-
-All users, businesses, and miners are encouraged to upgrade to this
-release (or a subsequent compatible release) unless they object to
-activation of taproot. If taproot is locked in, then upgrading before
-block 709632 is highly recommended to help enforce taproot's new rules
-and to avoid the unlikely case of seeing falsely confirmed transactions.
-
-Miners who want to activate Taproot should preferably use this release
-to control their signaling. The `getblocktemplate` RPC results will
-automatically be updated to signal once the appropriate start has been
-reached and continue signaling until the timeout occurs or taproot
-activates. Alternatively, miners may manually start signaling on bit 2
-at any time; if taproot activates, they will need to ensure they update
-their nodes before block 709632 or non-upgraded nodes could cause them to mine on
-an invalid chain. See the [versionbits
-FAQ](https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/) for
-details.
-
-
-For more information about taproot, please see the following resources:
-
-- Technical specifications
- - [BIP340 Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
- - [BIP341 Taproot: SegWit version 1 spending rules](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)
- - [BIP342 Validation of Taproot scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)
-
-- Popular articles;
- - [Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin](https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin)
- - [What do Schnorr Signatures Mean for Bitcoin?](https://academy.binance.com/en/articles/what-do-schnorr-signatures-mean-for-bitcoin)
- - [The Schnorr Signature & Taproot Softfork Proposal](https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/)
-
-- Development history overview
- - [Taproot](https://bitcoinops.org/en/topics/taproot/)
- - [Schnorr signatures](https://bitcoinops.org/en/topics/schnorr-signatures/)
- - [Tapscript](https://bitcoinops.org/en/topics/tapscript/)
- - [Soft fork activation](https://bitcoinops.org/en/topics/soft-fork-activation/)
-
-- Other
- - [Questions and answers related to taproot](https://bitcoin.stackexchange.com/questions/tagged/taproot)
- - [Taproot review](https://github.com/ajtowns/taproot-review)
Updated RPCs
------------
-- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
- being implemented, behavior for all RPCs that accept addresses is changed when
- a native witness version 1 (or higher) is passed. These now require a Bech32m
- encoding instead of a Bech32 one, and Bech32m encoding will be used for such
- addresses in RPC output as well. No version 1 addresses should be created
- for mainnet until consensus rules are adopted that give them meaning
- (e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
- Once that happens, Bech32m is expected to be used for them, so this shouldn't
- affect any production systems, but may be observed on other networks where such
- addresses already have meaning (like signet).
+- `getblockheader` now returns an additional `mweb_header` field containing
+ all of the MWEB header data, and an `mweb_amount` field containing the total
+ number of coins pegged-in to the MWEB after applying the block.
-0.21.1 change log
-=================
+- `getblock` now returns an additional `mweb` field containing MWEB header info,
+ and all of the inputs, outputs, and kernels in the MWEB block.
-### Consensus
-- #21377 Speedy trial support for versionbits (ajtowns)
-- #21686 Speedy trial activation parameters for Taproot (achow101)
+- Added `mwebweight`, `descendantmwebweight`, `ancestormwebweight`, and `mweb`
+ fields to `getrawmempool`, `getmempoolancestors`, `getmempooldescendants`,
+ and `getmempoolentry`.
-### P2P protocol and network code
-- #20852 allow CSubNet of non-IP networks (vasild)
-- #21043 Avoid UBSan warning in ProcessMessage(…) (practicalswift)
+- Added new fields to describe MWEB transaction inputs, outputs, and kernels
+ for `getrawtransaction`.
-### Wallet
-- #21166 Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (achow101)
-- #21083 Avoid requesting fee rates multiple times during coin selection (achow101)
+Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
-### RPC and other APIs
-- #21201 Disallow sendtoaddress and sendmany when private keys disabled (achow101)
+New settings
+------------
-### Build system
-- #21486 link against -lsocket if required for `*ifaddrs` (fanquake)
-- #20983 Fix MSVC build after gui#176 (hebasto)
+- Added "fMWEBFeatures" option for enabling the new "Advanced MWEB Features"
+ control.
-### Tests and QA
-- #21380 Add fuzzing harness for versionbits (ajtowns)
-- #20812 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
-- #20740 fuzz: Update FuzzedDataProvider.h from upstream (LLVM) (practicalswift)
-- #21446 Update vcpkg checkout commit (sipsorcery)
-- #21397 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
-- #21081 Fix the unreachable code at `feature_taproot` (brunoerg)
-- #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101)
-- #21571 Make sure non-IP peers get discouraged and disconnected (vasild, MarcoFalke)
-- #21489 fuzz: cleanups for versionbits fuzzer (ajtowns)
+Wallet Database
+---------------
-### Miscellaneous
-- #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa)
+- Added "mweb_coin" type which stores MWEB coins and their derived keys.
+
+- Added CHDChain version 4 which includes an MWEB key index counter and
+ the stealth address scan key.
+
+- Added CKeyMetadata version 14 which includes the MWEB key index.
+
+- Added FEATURE_MWEB = 210000 minimum database version.
+
+Wallet RPC changes
+------------------
+
+- Added 'listwallettransactions' which matches the transaction list display values.
+
+GUI changes
+-----------
+
+- Added an "Advanced MWEB Features" control for testing. It’s only available
+ when the "-debug" argument is supplied, and the option is turned on in the
+ settings dialog.
-### Documentation
-- #21384 add signet to bitcoin.conf documentation (jonatack)
-- #21342 Remove outdated comment (hebasto)
Credits
=======
Thanks to everyone who directly contributed to this release:
-- Aaron Clauson
-- Andrew Chow
-- Anthony Towns
-- Bruno Garcia
-- Fabian Jahr
-- fanquake
-- Hennadii Stepanov
-- Jon Atack
-- Luke Dashjr
-- MarcoFalke
-- Pieter Wuille
-- practicalswift
-- randymcmillan
-- Sjors Provoost
-- Vasil Dimov
-- W. J. van der Laan
-
-As well as to everyone that helped with translations on
-[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
+- [The Bitcoin Core Developers]
+- DavidBurkett
+- hectorchu
+- losh11
\ No newline at end of file
diff --git a/src/consensus/consensus.h b/src/consensus/consensus.h
index 24e3022ce..3783183b7 100644
--- a/src/consensus/consensus.h
+++ b/src/consensus/consensus.h
@@ -8,11 +8,12 @@
#include
#include
+#include
/** The maximum allowed size for a serialized block, in bytes (only for buffer size limits) */
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** MWEB: The maximum size of an MWEB block is just over 11 MB, plus 4 MB for a full segwit block. Add a ~1 MB buffer just to be safe. */
-static const unsigned int MAX_BLOCK_SERIALIZED_SIZE_WITH_MWEB = 16'000'000;
+static const unsigned int MAX_BLOCK_SERIALIZED_SIZE_WITH_MWEB = MAX_BLOCK_SERIALIZED_SIZE + mw::MAX_BLOCK_BYTES;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
diff --git a/src/interfaces/wallet.cpp b/src/interfaces/wallet.cpp
index 705137c68..2b8d7f6ed 100644
--- a/src/interfaces/wallet.cpp
+++ b/src/interfaces/wallet.cpp
@@ -195,7 +195,7 @@ public:
auto output_type = OutputType::BECH32;
auto reserve_dest = std::make_shared(m_wallet.get(), output_type);
- if (reserve_dest->GetReservedDestination(dest, true)) {
+ if (reserve_dest->GetReservedDestination(dest, false)) {
return reserve_dest;
}
diff --git a/src/libmw/include/mw/consensus/Params.h b/src/libmw/include/mw/consensus/Params.h
index 1d133d76a..43728f89f 100644
--- a/src/libmw/include/mw/consensus/Params.h
+++ b/src/libmw/include/mw/consensus/Params.h
@@ -10,6 +10,23 @@ MW_NAMESPACE
/// Consensus parameters
/// Any change to these will cause a hardfork!
///
-static constexpr std::size_t MAX_BLOCK_WEIGHT = 21'000;
+static constexpr size_t BYTES_PER_WEIGHT = 42;
+
+static constexpr size_t BASE_KERNEL_WEIGHT = 2;
+static constexpr size_t STEALTH_EXCESS_WEIGHT = 1;
+static constexpr size_t KERNEL_WITH_STEALTH_WEIGHT = BASE_KERNEL_WEIGHT + STEALTH_EXCESS_WEIGHT;
+
+static constexpr size_t BASE_OUTPUT_WEIGHT = 17;
+static constexpr size_t STANDARD_OUTPUT_FIELDS_WEIGHT = 1;
+static constexpr size_t STANDARD_OUTPUT_WEIGHT = BASE_OUTPUT_WEIGHT + STANDARD_OUTPUT_FIELDS_WEIGHT;
+
+static constexpr size_t MAX_NUM_INPUTS = 50'000;
+static constexpr size_t INPUT_BYTES = 196;
+
+static constexpr std::size_t MAX_BLOCK_WEIGHT = 200'000; // Nodes won't accept blocks over this weight
+static constexpr std::size_t MAX_MINE_WEIGHT = 20'000; // Miners won't create blocks over this weight. Non-consensus
+static constexpr size_t MAX_BLOCK_BYTES = 180 + (3 * 5) + // 180 bytes per header and 5 bytes each for input, output, and kernel vec size
+ (MAX_NUM_INPUTS * INPUT_BYTES) + // 50k inputs at 196 bytes each (ignoring extradata)
+ (MAX_BLOCK_WEIGHT * 60); // Ignoring inputs, no tx component is ever more than 60 bytes per unit of weight
END_NAMESPACE
\ No newline at end of file
diff --git a/src/libmw/include/mw/consensus/Weight.h b/src/libmw/include/mw/consensus/Weight.h
index 604e53c37..98a39e4d6 100644
--- a/src/libmw/include/mw/consensus/Weight.h
+++ b/src/libmw/include/mw/consensus/Weight.h
@@ -8,22 +8,6 @@
class Weight
{
public:
- static constexpr size_t BYTES_PER_WEIGHT = 42;
-
- static constexpr size_t BASE_KERNEL_WEIGHT = 2;
- static constexpr size_t STEALTH_EXCESS_WEIGHT = 1;
- static constexpr size_t KERNEL_WITH_STEALTH_WEIGHT = BASE_KERNEL_WEIGHT + STEALTH_EXCESS_WEIGHT;
-
- static constexpr size_t BASE_OUTPUT_WEIGHT = 17;
- static constexpr size_t STANDARD_OUTPUT_FIELDS_WEIGHT = 1;
- static constexpr size_t STANDARD_OUTPUT_WEIGHT = BASE_OUTPUT_WEIGHT + STANDARD_OUTPUT_FIELDS_WEIGHT;
-
- static constexpr size_t MAX_NUM_INPUTS = 50'000;
- static constexpr size_t INPUT_BYTES = 196;
- static constexpr size_t MAX_MWEB_BYTES = 180 + (3 * 5) + // 180 bytes per header and 5 bytes each for input, output, and kernel vec size
- (MAX_NUM_INPUTS * INPUT_BYTES) + // 50k inputs at 196 bytes each (ignoring extradata)
- (mw::MAX_BLOCK_WEIGHT * 60); // Ignoring inputs, no tx component is ever more than 60 bytes per unit of weight
-
static size_t Calculate(const TxBody& tx_body)
{
size_t input_weight = std::accumulate(
@@ -57,7 +41,7 @@ public:
static bool ExceedsMaximum(const TxBody& tx_body)
{
- return tx_body.GetInputs().size() > MAX_NUM_INPUTS || Calculate(tx_body) > mw::MAX_BLOCK_WEIGHT;
+ return tx_body.GetInputs().size() > mw::MAX_NUM_INPUTS || Calculate(tx_body) > mw::MAX_BLOCK_WEIGHT;
}
static size_t CalcInputWeight(const std::vector& extra_data)
@@ -71,7 +55,7 @@ public:
const std::vector& extra_data = {})
{
// Kernels with a stealth excess cost extra.
- size_t base_weight = has_stealth_excess ? KERNEL_WITH_STEALTH_WEIGHT : BASE_KERNEL_WEIGHT;
+ size_t base_weight = has_stealth_excess ? mw::KERNEL_WITH_STEALTH_WEIGHT : mw::BASE_KERNEL_WEIGHT;
return base_weight + ExtraBytesToWeight(pegout_script.size()) + ExtraBytesToWeight(extra_data.size());
}
@@ -82,7 +66,7 @@ public:
const std::vector& extra_data = {})
{
// Kernels with a stealth excess cost extra.
- size_t base_weight = has_stealth_excess ? KERNEL_WITH_STEALTH_WEIGHT : BASE_KERNEL_WEIGHT;
+ size_t base_weight = has_stealth_excess ? mw::KERNEL_WITH_STEALTH_WEIGHT : mw::BASE_KERNEL_WEIGHT;
size_t pegout_weight = std::accumulate(
pegouts.begin(), pegouts.end(), (size_t)0,
@@ -97,13 +81,13 @@ public:
// Outputs have a weight of 'BASE_OUTPUT_WEIGHT' plus 2 weight for standard fields, and 1 weight for every 'BYTES_PER_WEIGHT' extra_data bytes
static size_t CalcOutputWeight(const bool standard_fields, const std::vector& extra_data = {})
{
- size_t base_weight = standard_fields ? STANDARD_OUTPUT_WEIGHT : BASE_OUTPUT_WEIGHT;
+ size_t base_weight = standard_fields ? mw::STANDARD_OUTPUT_WEIGHT : mw::BASE_OUTPUT_WEIGHT;
return base_weight + ExtraBytesToWeight(extra_data.size());
}
private:
static size_t ExtraBytesToWeight(const size_t extra_bytes)
{
- return (extra_bytes + (BYTES_PER_WEIGHT - 1)) / BYTES_PER_WEIGHT;
+ return (extra_bytes + (mw::BYTES_PER_WEIGHT - 1)) / mw::BYTES_PER_WEIGHT;
}
};
\ No newline at end of file
diff --git a/src/libmw/src/wallet/TxBuilder.cpp b/src/libmw/src/wallet/TxBuilder.cpp
index dc64ff2d8..c7997bea1 100644
--- a/src/libmw/src/wallet/TxBuilder.cpp
+++ b/src/libmw/src/wallet/TxBuilder.cpp
@@ -52,7 +52,7 @@ mw::Transaction::CPtr TxBuilder::BuildTx(
.Sub(kernel_offset)
.Total();
- // MW: TODO - This is only needed for peg-ins or when no change
+ // MW: FUTURE - This is only needed for peg-ins or when no change
SecretKey stealth_blind = SecretKey::Random();
// Create the kernel
diff --git a/src/libmw/test/tests/consensus/Test_Weight.cpp b/src/libmw/test/tests/consensus/Test_Weight.cpp
index 65c032eb3..ec894489e 100644
--- a/src/libmw/test/tests/consensus/Test_Weight.cpp
+++ b/src/libmw/test/tests/consensus/Test_Weight.cpp
@@ -60,50 +60,50 @@ static std::vector CreateKernels(const size_t plain_kernels, const size_
BOOST_AUTO_TEST_CASE(ExceedsMaximum)
{
- BOOST_CHECK(Weight::MAX_NUM_INPUTS == 50'000);
- BOOST_CHECK(Weight::BASE_KERNEL_WEIGHT == 2);
- BOOST_CHECK(Weight::KERNEL_WITH_STEALTH_WEIGHT == 3);
- BOOST_CHECK(Weight::BASE_OUTPUT_WEIGHT == 17);
- BOOST_CHECK(Weight::STANDARD_OUTPUT_WEIGHT == 18);
- BOOST_CHECK(Weight::BYTES_PER_WEIGHT == 42);
- BOOST_CHECK(mw::MAX_BLOCK_WEIGHT == 21'000);
+ BOOST_CHECK(mw::MAX_NUM_INPUTS == 50'000);
+ BOOST_CHECK(mw::BASE_KERNEL_WEIGHT == 2);
+ BOOST_CHECK(mw::KERNEL_WITH_STEALTH_WEIGHT == 3);
+ BOOST_CHECK(mw::BASE_OUTPUT_WEIGHT == 17);
+ BOOST_CHECK(mw::STANDARD_OUTPUT_WEIGHT == 18);
+ BOOST_CHECK(mw::BYTES_PER_WEIGHT == 42);
+ BOOST_CHECK(mw::MAX_BLOCK_WEIGHT == 200'000);
- // 1,000 outputs + 1,000 stealth kernels = 21,000 Weight
+ // 10,000 outputs + 10,000 plain kernels = 200,000 Weight
{
- std::vector inputs(Weight::MAX_NUM_INPUTS);
- std::vector