profile
viewpoint

enriquez/ECPhoneNumberFormatter 147

NSFormatter subclass for formatting phone numbers.

enriquez/coinpocketapp.com 85

Bitcoin wallet that stores Bitcoin in your browser.

enriquez/ezpz-tooltip 27

jquery tooltip plugin

enriquez/ezpz-hint 23

A simple jQuery plugin for showing a text field's label inside the textbox itself. The hint disappears when it is given focus, and appears again if the inputted text is empty. Typically used for search and login forms.

enriquez/april_oneil 6

April O'Neil is a reporter for Facebook's xctool

enriquez/bringing-vim-to-the-people 5

An lo, on the fourth day he did step down from the mountain, and with him VIM did follow . . . .

enriquez/chocolate-meat 4

Mephisto Theme. Simple two column layout built with Blueprint CSS

enriquez/ActiveBraintree 2

ActiveRecord-like classes for working with Braintree

pull request commentbitcoin/bitcoin

wallet: check for non-representable CFeeRates (0-0.0009 sat/vB)

Invalid amount


...which is not a great error message, as it indicates neither which argument is invalid, nor why.

Maybe I should improve this.

jonatack

comment created time in 21 minutes

pull request commentbitcoin/bitcoin

wallet: check for non-representable CFeeRates (0-0.0009 sat/vB)

fee_rate=0.000000001

error code: -3
error message:
Invalid amount

...which is not a great error message, as it indicates neither which argument is invalid, nor why.

To stay close enough to not be negatively surprising, while providing better feedback, how about:

fee_rate=0.00000001

error code: -3
error message:
Invalid amount for fee_rate of 1e-08 (must be at least 0.001 sat/vB)

This is close to these similar error messages:

Invalid amount for -paytxfee=<amount>: '%s' (must be at least %s) Invalid amount for -maxtxfee=<amount>: '%s' (must be at least the minrelay fee of %s to prevent stuck transactions) Invalid amount for -fallbackfee=<amount>: '%s' Invalid amount for -%s=<amount>: '%s

jonatack

comment created time in 30 minutes

pull request commentbitcoin/bitcoin

wallet: check for non-representable CFeeRates (0-0.0009 sat/vB)

fee_rate=0.000000001

fee_rate=0.0009999999
error code: -3
error message:
Invalid amount

...which is not a great error message, as it indicates neither which argument is invalid, nor why.

To stay close enough to not be negatively surprising, while providing better feedback, how about:

fee_rate=0.00000001

error code: -3
error message:
Invalid amount for fee_rate of 1e-08 (must be at least 0.001 sat/vB)
jonatack

comment created time in 32 minutes

issue commentbitcoin/bitcoin

wallet: Can't Access System Volume Information

The Bitcoin Core software uses stock standard win32 API's to access the Windows file system. I think the main issue here is how the software ended up trying to access the System Volume Information directory in the first place. That directory isn't meant to be directly accessed by applications.

If you still have it could you paste a copy of your bitcoin.conf file (with any sensitive info removed)?

Linrono

comment created time in 41 minutes

pull request commentbitcoin/bitcoin

AppVeyor CI fixes for Visual Studio 2019 16.8.1 image

@MarcoFalke as a follow on to your comment here this PR should reduce the appveyor build times by approximately 20 minutes. From around 65 to around 45.

The reduction is down to building the Qt libraries without msvc compiler optimisations. As mentioned above, removing the optimisations was to help with ABI compatibility. The build time reduction was a welcome side effect.

sipsorcery

comment created time in an hour

pull request commentbitcoin/bitcoin

Support make src/bitcoin-node

@ryanofsky right, I was reviewing #19160 but didn't want to add this noise there. Maybe I should add bitcoin-gui too? others?

Sure, more consistency is more better

promag

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

wallettool: add parameter to create descriptors wallet

 static void SetupWalletToolArgs(ArgsManager& argsman)     argsman.AddArg("-datadir=<dir>", "Specify data directory", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);     argsman.AddArg("-wallet=<wallet-name>", "Specify wallet name", ArgsManager::ALLOW_ANY | ArgsManager::NETWORK_ONLY, OptionsCategory::OPTIONS);     argsman.AddArg("-debug=<category>", "Output debugging information (default: 0).", ArgsManager::ALLOW_ANY, OptionsCategory::DEBUG_TEST);+    argsman.AddArg("-descriptors", "Create descriptors wallet. Only for create", ArgsManager::ALLOW_BOOL, OptionsCategory::OPTIONS);

In commit "wallettool: add param to create descriptors wallet" (345e88eecf1b28607d5da3af38e19794a8a115ce)

It would be good to have enforcement in ExecuteWalletToolFunc that option is only allowed for create command so existing "info" and "salvage" commands don't start accepting but ignoring this option now, and so future commands like "createfromdump" don't start accepting it in the future. Something like the following should be sufficient for now (could generalize later):

if (gArgs.IsArgSet("-descriptors") && command != "create") {
   tfm::format(std::cerr, "Invalid parameter %s\n", "-descriptors");
   return false;
}
S3RK

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

wallettool: add parameter to create descriptors wallet

 static void WalletToolReleaseWallet(CWallet* wallet)     delete wallet; } -static void WalletCreate(CWallet* wallet_instance)+static void WalletCreate(CWallet* wallet_instance, uint64_t wallet_creation_flags) {     LOCK(wallet_instance->cs_wallet);      wallet_instance->SetMinVersion(FEATURE_HD_SPLIT);+    wallet_instance->AddWalletFlags(wallet_creation_flags); -    // generate a new HD seed-    auto spk_man = wallet_instance->GetOrCreateLegacyScriptPubKeyMan();-    CPubKey seed = spk_man->GenerateNewSeed();-    spk_man->SetHDSeed(seed);+    if (!wallet_instance->IsWalletFlagSet(WALLET_FLAG_DESCRIPTORS)) {+        auto spk_man = wallet_instance->GetOrCreateLegacyScriptPubKeyMan();+        spk_man->SetupGeneration(false);+    } else {+        wallet_instance->SetupDescriptorScriptPubKeyMans();+    }

re: https://github.com/bitcoin/bitcoin/pull/20365#discussion_r524855811

@ryanofsky @achow101 thanks for the advice and the reference. I'll start working on the refactoring in separate PR as I think it's better not to mix things up.

I've extended functional tests to cover for the new parameter. Any comments on this PR?

Looks good!

S3RK

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

test: run mempool_expiry.py even with wallet disabled

 class MempoolExpiryTest(BitcoinTestFramework):     def set_test_params(self):         self.num_nodes = 1+        self.setup_clean_chain = True -    def skip_test_if_missing_module(self):-        self.skip_if_no_wallet()+    def trigger_mempool_expiry(self):+        """Broadcasts an unrelated transaction as the expiry of the transactions in the mempool is only checked+        when a new transaction is added to the mempool."""+        try:+            self.wallet.send_self_transfer(from_node=self.nodes[0])+        except JSONRPCException:+            pass      def test_transaction_expiry(self, timeout):-        """Tests that a transaction expires after the expiry timeout and its-        children are removed as well."""+        """Tests that a transaction expires after the expiry timeout and its children are removed as well."""         node = self.nodes[0]+        self.wallet = MiniWallet(node)++        # Add enough mature utxos to the wallet so that all txs spend confirmed coins.+        self.wallet.generate(2)+        node.generate(100)          # Send a parent transaction that will expire.-        parent_address = node.getnewaddress()-        parent_txid = node.sendtoaddress(parent_address, 1.0)+        parent_txid = self.wallet.send_self_transfer(from_node=node)['txid']+        parent_utxo = self.wallet.get_utxo(txid=parent_txid)+        independent_utxo = self.wallet.get_utxo()          # Set the mocktime to the arrival time of the parent transaction.         entry_time = node.getmempoolentry(parent_txid)['time']         node.setmocktime(entry_time) -        # Create child transaction spending the parent transaction-        vout = find_vout_for_address(node, parent_txid, parent_address)-        inputs = [{'txid': parent_txid, 'vout': vout}]-        outputs = {node.getnewaddress(): 0.99}-        child_raw = node.createrawtransaction(inputs, outputs)-        child_signed = node.signrawtransactionwithwallet(child_raw)['hex']--        # Let half of the timeout elapse and broadcast the child transaction.-        half_expiry_time = entry_time + int(60 * 60 * timeout/2)+        # Let half of the timeout elapse.+        half_expiry_time = entry_time + 3600 * timeout // 2

Ah yeah, I did too much extra stuff in this PR. I'm gonna undo all this unrelated style/refactor stuff. Will undo the string formatting changes as well

mjdietzx

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

test: run mempool_expiry.py even with wallet disabled

 class MempoolExpiryTest(BitcoinTestFramework):     def set_test_params(self):         self.num_nodes = 1+        self.setup_clean_chain = True -    def skip_test_if_missing_module(self):-        self.skip_if_no_wallet()+    def trigger_mempool_expiry(self):+        """Broadcasts an unrelated transaction as the expiry of the transactions in the mempool is only checked+        when a new transaction is added to the mempool."""+        try:+            self.wallet.send_self_transfer(from_node=self.nodes[0])+        except JSONRPCException:

There's a minor problem here, re the unrelated transaction part of @0xB10C's explanation. With MiniWallet if we don't do any extra bookkeeping in this test, and just do self.wallet.send_self_transfer(from_node=node) to trigger the mempool update, the (now expired) utxo will be spent. So this send_self_transfer will throw test_framework.authproxy.JSONRPCException: mempool full (-26)

We'd need to ensure that we don't spend one of the expired UTXOs when we want to trigger_mempool_expiry if we don't catch the Exception. ie:

node.setmocktime(expiry_time)
# Broadcasts an unrelated transaction as the expiry of the transactions in the mempool is only checked when a new transaction is added to the mempool.
new_utxo = self.wallet.get_utxo(txid=independent_txid)
new_txid = self.wallet.send_self_transfer(from_node=self.nodes[0], utxo_to_spend=new_utxo)['txid']
# parent_txid has now been evicted from the mempool.

Because the mempool is still updated if send_self_transfer fails, I thought it was cleaner to catch the Exception rather than have extra logic (that's unrelated to what we're testing) to ensure we're not spending expired UTXOs in this trigger.

Maybe I need to add a comment along these lines in the except: pass to make this clear? I'm realizing this is more confusing than I thought

mjdietzx

comment created time in 3 hours

pull request commentbitcoin/bitcoin

RPC: Tolerate invalid rpcauth options

Release notes updated, debug msg changed, and tests updated.

luke-jr

comment created time in 3 hours

pull request commentbitcoin/bitcoin

RPC: Tolerate invalid rpcauth options

Concept ACK, you have to update test/functional/rpc_users.py.

luke-jr

comment created time in 3 hours

pull request commentbitcoin/bitcoin

Support make src/bitcoin-node

@ryanofsky right, I was reviewing #19160 but didn't want to add this noise there. Maybe I should add bitcoin-gui too? others?

promag

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

RPC: Tolerate invalid rpcauth options

 static bool InitRPCAuthentication()                 g_rpcauth.push_back(fields);             } else {                 LogPrintf("Invalid -rpcauth argument.\n");
                LogPrintf("Ignoring invalid -rpcauth argument.\n");
luke-jr

comment created time in 3 hours

Pull request review commentbitcoin/bitcoin

RPC: Tolerate unknown parameters, but with clear warning/errors

 static bool InitRPCAuthentication()         for (const std::string& rpcauth : gArgs.GetArgs("-rpcauth")) {             std::vector<std::string> fields;             boost::split(fields, rpcauth, boost::is_any_of(":$"));-            if (fields.size() == 3) {+            if (fields.size() >= MIN_RPCAUTH_VALUES) {                 g_rpcauth.push_back(fields);+                if (fields.size() > MAX_RPCAUTH_VALUES) {+                    LogPrintf("Unrecognised -rpcauth parameters for username '%s'. User will not be able to authenticate.\n", SanitizeString(fields[0]));+                }             } else {                 LogPrintf("Invalid -rpcauth argument.\n");                 return false;

#20550

luke-jr

comment created time in 3 hours

PR opened bitcoin/bitcoin

RPC: Tolerate invalid rpcauth options

By tolerating unknown extra rpcauth parameters (and ignoring the rpcauth), we can ensure a limited forward compatibility by not forcing users to downgrade their config file to switch back to older versions (perhaps temporarily).

Same as #20548, but without the additional effort to explain the situation at runtime.

+0 -1

0 comment

1 changed file

pr created time in 4 hours

PR opened bitcoin/bitcoin

Support make src/bitcoin-node

Feel free to close if its something we want to avoid.

+6 -0

0 comment

2 changed files

pr created time in 4 hours

Pull request review commentbitcoin/bitcoin

RPC: Tolerate unknown parameters, but with clear warning/errors

 static bool InitRPCAuthentication()         for (const std::string& rpcauth : gArgs.GetArgs("-rpcauth")) {             std::vector<std::string> fields;             boost::split(fields, rpcauth, boost::is_any_of(":$"));-            if (fields.size() == 3) {+            if (fields.size() >= MIN_RPCAUTH_VALUES) {                 g_rpcauth.push_back(fields);+                if (fields.size() > MAX_RPCAUTH_VALUES) {+                    LogPrintf("Unrecognised -rpcauth parameters for username '%s'. User will not be able to authenticate.\n", SanitizeString(fields[0]));+                }             } else {                 LogPrintf("Invalid -rpcauth argument.\n");                 return false;

I think you are overcomplicating this. No need for a +53-7 patch when this line could be removed in a -1+0 patch to achieve the same user experience

luke-jr

comment created time in 4 hours

pull request commentbitcoin/bitcoin

Periodically make block-relay connections and sync headers

Am re-testing with added logging on a node, re-review tomorrow or Friday.

sdaftuar

comment created time in 4 hours

PR opened bitcoin/bitcoin

RPC: Tolerate unknown parameters, but with clear warning/errors

By tolerating unknown extra rpcauth parameters (and ignoring the rpcauth), we can ensure a limited forward compatibility by not forcing users to downgrade their config file to switch back to older versions (perhaps temporarily).

To avoid any possible confusion, a message is still printed at startup, and returned as part of the error message if the user attempts to authenticate using the correct username/password.

+53 -7

0 comment

2 changed files

pr created time in 4 hours

pull request commentbitcoin/bitcoin

Disable and fix tests for when BDB is not compiled

Starting to look at this but can the description be updated to maybe strip out the references to old PRs and say what behavior change this PR is implementing? What happens with test runner currently, and what happens after this PR? What happens running individual BDB tests currently, and what happens after?

Updated the OP.

I'm used to test runner showing a table of all tests Passed or Failed or Skipped. Here, it seems like in the absence of BDB some tests are partially skipped so I would expect to see some new Passed (partial) status instead of plain Passed. Or to avoid this, I'd expect these tests to be split and run twice with --legacy-wallet and --descriptors, so there is never any partially passed test only fully passed or fully skipped.

We already have tests which are "partial" as some parts are not tested if the wallet is not compiled. If we do want to have a "partial" indicator for tests where we disable components based on compiled support, then I think it should be done in a followup.

I'm also confused about why some code is looking at self.options.descriptors, and other code is calling self.get_use_descriptors(). And self.get_use_descriptors() is using self.options.descriptors internally but there is also self.options.descriptors = self.get_use_descriptors() so some kind of caching or recursive dependency? This might be worth simplifying or explaining some place.

This is a holdover from a previous iteration. I've removed the extra uses of self.get_use_descriptors() and just use self.options.descriptors. The purpose and behavior of self.get_use_descriptors is described in the OP.

achow101

comment created time in 4 hours

issue openedbitcoin/bitcoin

Please split the `-msghand` thread into multiple threads.

It seems when using good storage that this thread act as bottleneck in a way that other threads are waiting completion from it a the cpu level when performing initial full node synchronisation.

As a result, Bitcoin is mostly single threaded in that case (the -msghand thread take 100% of a single core leaving other cores idle even on a core duo cpu).

This what currently prevents syncing a full node with -txindex in less than 1 hour.

created time in 4 hours

pull request commentbitcoin/bitcoin

Init script for debian/ubuntu

Yes indeed there is already a script for systemd but this script is intended to be used on RedHat operating systems and is not compatible with Debian/Ubuntu that's why I created this new one.

It seems I mis-read your message. You mean that the current bitcoind.service in the repo is intended to be used on RedHat operating systems, right? I didn't run it on RedHat, but on Ubuntu it works just fine for me. What errors do you encounter?

echo083

comment created time in 4 hours

issue commentCocoaPods/CocoaPods

error while pod install

Hello @dnkoutso ,

I had the same issue, I just run export LANG=en_US.UTF-8 and finally it works!. 👍🏽

savanpanara

comment created time in 4 hours

issue commentbitcoin/bitcoin

Wrong `time` when importing transactions with `rescanblockchain ` RPC command

As a specter user, I had the same problem with multiple incorrect date across several wallet.

I've look at the Bitcoin Core code and the function ComputeSmartTime in wallet.cpp attire my attention. The algorithm try to search for the best time between the received one, the block time one and a smart one wich is produced by a lot of time corrections. This ComputeSmartTime method is conceived with a real time approach in mind. The technique used to determine the smart version of the time is based on the hypothesis that you can't discover transactions in the wrong order. And if you suppose that transcations can be discovered in the wrong order, the lastestEntry variable is going to be wrong for every transactions discovered after and be the exact same date. That's exactly what I saw in my Bitcoin Core wallet, a lot of transactions with the exact same date, which is incorrect.

I've not found yet a simple example where transactions could be dicovered in the wrong order, but I'm looking for a case where you start with a small rescan and after a larger one. To be more precise : if you rescan only the latest part of the history (2020 year only), and proceed to a larger rescan after (full rescan), every transaction before 2020 will be noted in 2020 du to the lastEntry constraint in nTimeSmart = std::max(latestEntry, std::min(blocktime, latestNow));

When you think about it, in a rescanning scenario, the blocktime is the only exploitable time. The received one means nothing and you can't find a better value.

That's why I've patched the problem like this :

add a rescanning_old_block boolean to ComputeSmartTime In case of rescanning_old_block don't use anything else than blocktime. propagate this boolean in the methods hierarchy to differenciate realtime incoming transactions with rescanning case. I'm currently testing my patch. Tests cases stay all green. If everything is repaired in my wallets, I'll submit this little patch in another comment to get feedback on it.

ben-kaufman

comment created time in 4 hours

pull request commentbitcoin/bitcoin

Init script for debian/ubuntu

What OP means please?

"original post", i.e. pull request description.

echo083

comment created time in 4 hours

pull request commentbitcoin/bitcoin

rpc: Validate -rpcauth arguments

Might make sense to have a -strict option for those that wish to have clean configurations.

promag

comment created time in 4 hours

Pull request review commentbitcoin/bitcoin

test: apply strict verification flags for transaction tests and assert backwards compatibility

 BOOST_AUTO_TEST_CASE(tx_valid)             BOOST_CHECK(state.IsValid());              PrecomputedTransactionData txdata(tx);-            for (unsigned int i = 0; i < tx.vin.size(); i++)-            {-                if (!mapprevOutScriptPubKeys.count(tx.vin[i].prevout))-                {-                    BOOST_ERROR("Bad test: " << strTest);-                    break;-                }+            std::vector<unsigned int> verify_flags = ParseScriptFlags(test[2].get_str()); -                CAmount amount = 0;-                if (mapprevOutValues.count(tx.vin[i].prevout)) {-                    amount = mapprevOutValues[tx.vin[i].prevout];-                }-                unsigned int verify_flags = ParseScriptFlags(test[2].get_str());-                const CScriptWitness *witness = &tx.vin[i].scriptWitness;-                BOOST_CHECK_MESSAGE(VerifyScript(tx.vin[i].scriptSig, mapprevOutScriptPubKeys[tx.vin[i].prevout],-                                                 witness, verify_flags, TransactionSignatureChecker(&tx, i, amount, txdata), &err),-                                    strTest);-                BOOST_CHECK_MESSAGE(err == SCRIPT_ERR_OK, ScriptErrorString(err));+            // Do not use TrimFlags() in the main test in order to detect invalid verifyFlags combination in the test file.+            if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, ~verify_flags[0], txdata, strTest, /* expect_valid */ true))+                BOOST_ERROR("Tx unexpectedly failed: " << strTest);+            // Check that flags are maximal: transaction should fail if any unset flags are set.+            for (size_t i = 0; i < mapFlagNames.size(); i++)+            {+                // Backwards compatibility: Removing a flag should not invalidate a valid transaction+                unsigned int flags = TrimFlags(~(verify_flags[0] | (1U << i)));+                if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, flags, txdata, strTest, /* expect_valid */ true))+                    BOOST_ERROR("Tx unexpectedly failed with flag " << ToString(i) << " unset: " << strTest);+                // Backwards compatibility: Removing some random flags should not invalidate a valid transaction+                flags = TrimFlags(~(verify_flags[0] | (unsigned int)InsecureRandBits(mapFlagNames.size())));+                if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, flags, txdata, strTest, /* expect_valid */ true))+                    BOOST_ERROR("Tx unexpectedly failed with random flags " << ToString(flags) << ": " << strTest);+            }+            for (size_t f = 1; f < verify_flags.size(); f++)+            {

https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#clang-format-diffpy

glozow

comment created time in 4 hours

pull request commentbitcoin/bitcoin

wallet: check for non-representable CFeeRates (0-0.0009 sat/vB)

It would be confusing if 0.00000001 and 0.000000001 produced different error messages

jonatack

comment created time in 5 hours

Pull request review commentbitcoin/bitcoin

test: apply strict verification flags for transaction tests and assert backwards compatibility

 BOOST_AUTO_TEST_CASE(tx_valid)             BOOST_CHECK(state.IsValid());              PrecomputedTransactionData txdata(tx);-            for (unsigned int i = 0; i < tx.vin.size(); i++)-            {-                if (!mapprevOutScriptPubKeys.count(tx.vin[i].prevout))-                {-                    BOOST_ERROR("Bad test: " << strTest);-                    break;-                }+            std::vector<unsigned int> verify_flags = ParseScriptFlags(test[2].get_str()); -                CAmount amount = 0;-                if (mapprevOutValues.count(tx.vin[i].prevout)) {-                    amount = mapprevOutValues[tx.vin[i].prevout];-                }-                unsigned int verify_flags = ParseScriptFlags(test[2].get_str());-                const CScriptWitness *witness = &tx.vin[i].scriptWitness;-                BOOST_CHECK_MESSAGE(VerifyScript(tx.vin[i].scriptSig, mapprevOutScriptPubKeys[tx.vin[i].prevout],-                                                 witness, verify_flags, TransactionSignatureChecker(&tx, i, amount, txdata), &err),-                                    strTest);-                BOOST_CHECK_MESSAGE(err == SCRIPT_ERR_OK, ScriptErrorString(err));+            // Do not use TrimFlags() in the main test in order to detect invalid verifyFlags combination in the test file.+            if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, ~verify_flags[0], txdata, strTest, /* expect_valid */ true))+                BOOST_ERROR("Tx unexpectedly failed: " << strTest);+            // Check that flags are maximal: transaction should fail if any unset flags are set.+            for (size_t i = 0; i < mapFlagNames.size(); i++)+            {+                // Backwards compatibility: Removing a flag should not invalidate a valid transaction+                unsigned int flags = TrimFlags(~(verify_flags[0] | (1U << i)));+                if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, flags, txdata, strTest, /* expect_valid */ true))+                    BOOST_ERROR("Tx unexpectedly failed with flag " << ToString(i) << " unset: " << strTest);+                // Backwards compatibility: Removing some random flags should not invalidate a valid transaction+                flags = TrimFlags(~(verify_flags[0] | (unsigned int)InsecureRandBits(mapFlagNames.size())));+                if (!CheckTxScripts(tx, mapprevOutScriptPubKeys, mapprevOutValues, flags, txdata, strTest, /* expect_valid */ true))+                    BOOST_ERROR("Tx unexpectedly failed with random flags " << ToString(flags) << ": " << strTest);+            }+            for (size_t f = 1; f < verify_flags.size(); f++)+            {

oops 😅 thanks for advice @jonatack

glozow

comment created time in 5 hours

more