Would Bitcoin be more secure against extremely powerful computing tech with more words in the dictionary list, a larger number of seed words and perhaps a longer BTC address/privkey? Say a seed had 50 words instead of 12 or 24 and Bitcoin addresses or seeds had at least one more character. Would it be more secure against bruteforcing or high computing power?

As others have outlined you're on the right track.  There are some risks to what your proposing if your intention is to keep the coin in a hot wallet.  If your goal is to redeem the entire value of the coin and convert it to fiat you can avoid an additional transaction fee by sweeping the funds directly into your exchange wallet.  To do so, use a bitcoin address you obtain from your exchange to create a watch-only wallet; File>New/Restore>Next> then select "Import bitcoin address or private keys."

After the wallet has been created and you've confirmed the validity of the address you can sweep the funds directly to your exchange; Wallet>Private Keys>Sweep.

Thanks for all your replies.

I tried but couldn't find anything. I also tried the other bytes in the linked post. I found some results for "defaultkey" but what follows the string is "site-packages/route.py". I guess it's from some other apps and not what a normal wallet.dat file contains?

Yes, I first tried some data recovery tools such as disk genius. I couldn't find any file named "wallet.dat" and got thousands of unnamed files which are impractical to go through manually.

Thank you very much. I tried this software. I looked for .db files and couldn't find anything. Looking for other types of files yields some results. I wonder if I should look for all types and turn on options like "brute force"?

We'll absolutely implement automatic withdrawals before we launch! It will take some time as we have a lot of improvements on the to-do list, but we'll get there.


Typo is fixed, thanks for letting us know.


Ongoing P&L is one of the next items in our to-do list. I think it might be done next week.

How can the tabs be more intuitive? I see you had a bad time testing our exchange and you don't like it, but negative feedback is sometimes as useful as positive ones.

Visual triggers in the chart are a great idea! We'll add to the to-do list.

What do you mean by store and reload settings? Have you tried reordering components and they went back to default positions?

I understand we don't have the best UX in the world right now but please understand that we are in testing mode. We are absolutely not ready for production, and we know that!


We are actually working right now on a hybrid non-custodial model in which order matching is centralized but funds remain secure in a smart contract. It will in a way be very similar to a channel. Check out this post that I've made on the Ethereum Research forum: High-frequency trading and the MEV auction debate.


What happened when you tried to close your profitable position? If you found a bug when trying to close your position please let us know!

Regardless of the fact that you really didn't like our platform, your feedback has been helpful, so please share your BTC address here and we'll sending you a tip.

Yes. You said:


But OP is getting wallet.dat password mixed up with private key (ckey) encryption. They are using two different algorithms/concepts.

The AES-256-CBC is a cipher that is used inside the PBKDF2 derivation, along with the SHA512 hash function. You can't just do a KDF without a hash function and a cipher to go with it. It is even referencing number of rounds and nDerivation method inside SetKeyFromPassphrase:


Notice how there's only an nDerivationMethod of 0. According to achow's comment in the thread I linked this stands for SHA-512 derivation function.


As you can see, the password has never been encrypted anywhere, that's why it makes no sense to talk about extracting the encrypted password, because there is no encrypted password, only AES keys generated from the password.

Even these are not stored in the file, only a bunch of constant values along with the salt separated by dollar sign $ to make up the bitcoin wallet hash (which I sometimes [wrongly] call PBKDF2 hash)

The password generates the encryption keys, that's also the reason why wallet.dat files have one of the slowest keys/second cracking time, versus regular AES256CBC (in the KDF this function + the hashing is repeated several hundred times!)

You must be referring to the wallet.dat hash of the password (and not the wallet's encrypted private keys, which do use AES-256-CBC), which looks similar to this:


Hashing a password in a wallet.dat is done using PBKDF2, and the SHA512 is merely a hash function used on a chunk of data within the many HMAC functions invoked in the PBKDF2 hash. So, you are not looking for a SHA512 hash, you want the PBKDF2 hash, which looks like the one I quoted above.

This hash can be obtained using the script bitcoin2john.py which is available on Github at https://raw.githubusercontent.com/magnumripper/JohnTheRipper/bleeding-jumbo/run/bitcoin2john.py .

// Copyright (c) 2009-2019 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#include <wallet/crypter.h>

#include <crypto/aes.h>
#include <crypto/sha512.h>
#include <util/system.h>

#include <vector>

int CCrypter::BytesToKeySHA512AES(const std::vector<unsigned char>& chSalt, const SecureString& strKeyData, int count, unsigned char *key,unsigned char *iv) const
{
    // This mimics the behavior of openssl's EVP_BytesToKey with an aes256cbc
    // cipher and sha512 message digest. Because sha512's output size (64b) is
    // greater than the aes256 block size (16b) + aes256 key size (32b),
    // there's no need to process more than once (D_0).

    if(!count || !key || !iv)
        return 0;

    unsigned char buf[CSHA512::OUTPUT_SIZE];
    CSHA512 di;

    di.Write((const unsigned char*)strKeyData.data(), strKeyData.size());
    di.Write(chSalt.data(), chSalt.size());
    di.Finalize(buf);

    for(int i = 0; i != count - 1; i++)
        di.Reset().Write(buf, sizeof(buf)).Finalize(buf);

    memcpy(key, buf, WALLET_CRYPTO_KEY_SIZE);
    memcpy(iv, buf + WALLET_CRYPTO_KEY_SIZE, WALLET_CRYPTO_IV_SIZE);
    memory_cleanse(buf, sizeof(buf));
    return WALLET_CRYPTO_KEY_SIZE;
}

bool CCrypter::SetKeyFromPassphrase(const SecureString& strKeyData, const std::vector<unsigned char>& chSalt, const unsigned int nRounds, const unsigned int nDerivationMethod)
{
    if (nRounds < 1 || chSalt.size() != WALLET_CRYPTO_SALT_SIZE)
        return false;

    int i = 0;
    if (nDerivationMethod == 0)
        i = BytesToKeySHA512AES(chSalt, strKeyData, nRounds, vchKey.data(), vchIV.data());

    if (i != (int)WALLET_CRYPTO_KEY_SIZE)
    {
        memory_cleanse(vchKey.data(), vchKey.size());
        memory_cleanse(vchIV.data(), vchIV.size());
        return false;
    }

    fKeySet = true;
    return true;
}

bool CCrypter::SetKey(const CKeyingMaterial& chNewKey, const std::vector<unsigned char>& chNewIV)
{
    if (chNewKey.size() != WALLET_CRYPTO_KEY_SIZE || chNewIV.size() != WALLET_CRYPTO_IV_SIZE)
        return false;

    memcpy(vchKey.data(), chNewKey.data(), chNewKey.size());
    memcpy(vchIV.data(), chNewIV.data(), chNewIV.size());

    fKeySet = true;
    return true;
}

bool CCrypter::Encrypt(const CKeyingMaterial& vchPlaintext, std::vector<unsigned char> &vchCiphertext) const
{
    if (!fKeySet)
        return false;

    // max ciphertext len for a n bytes of plaintext is
    // n + AES_BLOCKSIZE bytes
    vchCiphertext.resize(vchPlaintext.size() + AES_BLOCKSIZE);

    AES256CBCEncrypt enc(vchKey.data(), vchIV.data(), true);
    size_t nLen = enc.Encrypt(vchPlaintext.data(), vchPlaintext.size(), vchCiphertext.data());
    if(nLen < vchPlaintext.size())
        return false;
    vchCiphertext.resize(nLen);

    return true;
}

bool CCrypter::Decrypt(const std::vector<unsigned char>& vchCiphertext, CKeyingMaterial& vchPlaintext) const
{
    if (!fKeySet)
        return false;

    // plaintext will always be equal to or lesser than length of ciphertext
    int nLen = vchCiphertext.size();

    vchPlaintext.resize(nLen);

    AES256CBCDecrypt dec(vchKey.data(), vchIV.data(), true);
    nLen = dec.Decrypt(vchCiphertext.data(), vchCiphertext.size(), vchPlaintext.data());
    if(nLen == 0)
        return false;
    vchPlaintext.resize(nLen);
    return true;
}

bool EncryptSecret(const CKeyingMaterial& vMasterKey, const CKeyingMaterial &vchPlaintext, const uint256& nIV, std::vector<unsigned char> &vchCiphertext)
{
    CCrypter cKeyCrypter;
    std::vector<unsigned char> chIV(WALLET_CRYPTO_IV_SIZE);
    memcpy(chIV.data(), &nIV, WALLET_CRYPTO_IV_SIZE);
    if(!cKeyCrypter.SetKey(vMasterKey, chIV))
        return false;
    return cKeyCrypter.Encrypt(*((const CKeyingMaterial*)&vchPlaintext), vchCiphertext);
}

bool DecryptSecret(const CKeyingMaterial& vMasterKey, const std::vector<unsigned char>& vchCiphertext, const uint256& nIV, CKeyingMaterial& vchPlaintext)
{
    CCrypter cKeyCrypter;
    std::vector<unsigned char> chIV(WALLET_CRYPTO_IV_SIZE);
    memcpy(chIV.data(), &nIV, WALLET_CRYPTO_IV_SIZE);
    if(!cKeyCrypter.SetKey(vMasterKey, chIV))
        return false;
    return cKeyCrypter.Decrypt(vchCiphertext, vchPlaintext);
}

bool DecryptKey(const CKeyingMaterial& vMasterKey, const std::vector<unsigned char>& vchCryptedSecret, const CPubKey& vchPubKey, CKey& key)
{
    CKeyingMaterial vchSecret;
    if(!DecryptSecret(vMasterKey, vchCryptedSecret, vchPubKey.GetHash(), vchSecret))
        return false;

    if (vchSecret.size() != 32)
        return false;

    key.Set(vchSecret.begin(), vchSecret.end(), vchPubKey.IsCompressed());
    return key.VerifyPubKey(vchPubKey);
}