The only other things I could think might cause something like that, would be: 1. Your Bitcoin Core node is pruned or 2. Your Bitcoin Core block data is corrupted Maybe @goatpig can shed some light on this specific error though... it's not something that I have personally encountered, nor have I seen any other users with this specific error. It might be some weird Windows 8.1 "quirk"  |
|
|
|
ok... so, what you want to do it find the most recent "send" transaction that is in the "encrypted" wallet... then right click the transaction and select "copy transaction id":  Once you have that TransactionID, you can lookup the transaction on a blockexplorer like blockchain.com, blockchair.com, blockstream.info, blockcypher.com etc... For this example, I'll use blockchain.com. Lets say that our TransactionID is: 8868a53fdf818ce4dda050b9e5992d9a61e3fe3da754b68b521e48acc94406bbWe put that into blockchain.com and we see this:  We can see on the right hand side, the "output" addresses: - 1ETCkqqVd4CTffmZJyL3R18eGbVb44EXbU- 3EEJFjZURxShNr2AoJtbfcvCB749yzP7LPWhat you want to do is check all of the output addresses that you see for your transaction using the getaddressinfo command... on both the unencrypted and the encrypted wallet.dat's... So, for our example transaction, we want to use the following commands on both the old and new wallet.dat's: getaddressinfo 1ETCkqqVd4CTffmZJyL3R18eGbVb44EXbU
getaddressinfo 3EEJFjZURxShNr2AoJtbfcvCB749yzP7LP
If my theory is correct, on the old unecrypted wallet.dat... all of the output addresses will say "ismine:false" like this: getaddressinfo 1ETCkqqVd4CTffmZJyL3R18eGbVb44EXbU
{
"address": "1ETCkqqVd4CTffmZJyL3R18eGbVb44EXbU",
"scriptPubKey": "76a914938e43764d6068ff631f3d98d582d4e9e718c88a88ac",
"ismine": false,
"solvable": false,
"iswatchonly": false,
"isscript": false,
"iswitness": false,
"ischange": false,
"labels": [
]
}
and this: getaddressinfo 3EEJFjZURxShNr2AoJtbfcvCB749yzP7LP
{
"address": "3EEJFjZURxShNr2AoJtbfcvCB749yzP7LP",
"scriptPubKey": "a914898c095b5b02d8a3f736f6cf872c5f97c5eccefc87",
"ismine": false,
"solvable": false,
"iswatchonly": false,
"isscript": true,
"iswitness": false,
"ischange": false,
"labels": [
]
}
However, when you check the addresses on the "new" encrypted wallet.dat... one of those addresses will display as "ismine: true" (and most likely "ischange: true" as well)... like this: getaddressinfo 3EEJFjZURxShNr2AoJtbfcvCB749yzP7LP
{
"address": "3EEJFjZURxShNr2AoJtbfcvCB749yzP7LP",
"scriptPubKey": "a914898c095b5b02d8a3f736f6cf872c5f97c5eccefc87",
"ismine": true,
"solvable": false,
"iswatchonly": false,
"isscript": true,
"iswitness": false,
"ischange": true,
"labels": [
]
}
|
|
|
|
getaddressinfo (need to find the last change address and put here?)
Correct... just try ALL of the output addresses associated with the last "send" transaction (or two) that you see in your "old" unencrypted backup wallet.dat If my theory is correct... both addresses (for each send transaction) will show "ismine: false" when you use the getaddressinfo command on your old unencrypted wallet.dat, which would indicate that it is missing the "change" address keys.  Then try using getaddressinfo on the "encrypted" VM wallet.dat using those same output addresses. Again, if my theory is correct, one of the output addresses should show "ismine: true" to indicate that the encrypted wallet does have the "change" address keys. It doesn't really help you recover the keys... but at least it will explain why your transactions are the same, but your balances are different... and it will confirm that you'll be unable to recover all the coins using your old unencrypted wallet.dat. |
|
|
|
Personally... I run " electrs". (see also: https://bitcointalk.org/index.php?topic=4589797.0) I have found that it is, more or less, a happy medium between EPS and ElectrumX... it's small enough that the setup and resource requirements are relatively small compared with say ElectrumX (initial sync is ~1.5 hours, storage is maybe 10% of Bitcoin Core requirements), but it also has enough features/usability that it isn't quite as constrained as EPS... (ie. you can easily add new wallets to Electrum, import new private keys etc and it doesn't bat an eyelid... or require reconfiguring) I actually run it on Ubuntu under WSL (windows subsytem for linux) and it is able to read the block data from my Windows based Bitcoin Core node. My Windows based Electrum client is then able to connect to electrs using the --oneserver option... et voilà... my own "personal" (and extensible) Electrum server, connected to my own "personal" Bitcoin Core node. |
|
|
|
gpg: Bonne signature de « Thomas Voegtlin (https://electrum.org) <thomasv@electrum.org> » [inconnu]
gpg: alias « ThomasV <thomasv1@gmx.de> » [inconnu]
gpg: alias « Thomas Voegtlin <thomasv1@gmx.de> » [inconnu]
This is the important part... it is indicating that you have a "Bonne" signature... If you had seen a message about a "Bad" signature, then you should be concerned... because it meant the signature in the downloaded file did not match with ThomasV's signature! The warning you see simply means that you have not personally trusted ThomasV's signature yet... but that's not actually required to be able to confirm the actual signature as "Bonne" or "Bad"  |
|
|
|
By default, EPS runs with a very specific set of addresses (you have to configure each address you want to know about, or provide a master public key etc)... so it only maintains an index of those addresses and their associated transactions. If you then add new addresses into Electrum (not covered by the ones already provide to EPS or generated from the master public key)... then EPS needs to be updated with these new addresses, so it can then get that address info from your node. This often means "rescanning" with EPS several times to get updated info... EPS can be a bit "problematic" like that if you think you're going to be adding new wallets to Electrum from time to time |
|
|
|
That's a new one on me... sounds like it could be some sort of either "out of disk space" error or a Windows permissions type issue... are you running Bitcoin Core and Armory as an administrator? How much free space is left on the device? Also, is your Windows 8.1 32bit or 64bit? |
|
|
|
When you clicked send, did you get any sort of error message at all? If the transaction was not broadcast correctly, it should really having given you some sort of error message to explain why it was rejected. A "too low fee" at the moment would not prevent the transaction from being broadcast... the mempool min fee rate is 1 sat/vbyte... which is also the minimum possible transaction fee rate. So, at worst, your transaction would just be "stuck"... but would still be in the mempool. So, either your wallet file itself is not "synced" (even though your node might be fully synced with all blocks downloaded)... and it needs to be rescanned. Try using the rescanblockchain command on the console... note that this could take an hour or 2 to complete and will likely render Bitcoin Core "unusable" while it is rescanning the wallet file. And you may need to rescan each wallet file individually. |
|
|
|
So i use the --dumpwallet command on the recoveredwallet into wallet.txt?
I'd try Bitcoin Core first... nothing to lose, easiest way to go about it. Just make a copy of the .dat file... then try opening it with Bitcoin Core... just be prepared to wait while it rescans the blockchain looking for transactions. Note this is NOT redownloading the blocks (assuming your node is NOT pruned), it just has to scan the block data. and then how do i import those into a wallet of my choice.
Really depends on what wallet you want to import it too... But the --dumpwallet command should give you the private keys in WIF format... assuming that you include the --passphrase parameter when dumping the wallet. For Bitcoin Core, you just use the importprivkey command on the console in Bitcoin Core (make sure to set rescan to false until you import the last key, otherwise it will run rescan every. single. time.  ) Or you can look up one of the many many many guides on how to import private keys into Electrum... Like this one: https://bitcoinelectrum.com/importing-your-private-keys-into-electrum/Google is your friend. |
|
|
|
You need to do so in the exact order. As you've said, the script is hashed and changing the order also changes the hash. That is why we rely on the redeem script. Oh, okay, thanks. So electrum doesn't sort them ascendingly. Actually... it does... and it doesn't...  Electrum uses "lexicographical ordering" as per BIP45: https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#cosigner-index But, because it is an HD version of Multisig... the ordering is of the "purpose keys'" of each co-signer (m/45') and is used to determine the co-signer index of each party, which then determines the order of the individual public keys when combining them to create an "address" script... this may result in individual scripts where the public keys are not ordered lexicographically. As opposed to a "non-HD" multisig, where the combined public keys would (should?) always be lexicographically ordered. |
|
|
|
|
a recovered_wallet.dat may or may not open with Bitcoin Core... theoretically, it should be compatible, so you should be able to open it directly... but it's possible that pywallet is not creating it in a format that Bitcoin Core can handle.
In which case, dumping the private keys out of it, then importing those into the wallet of your choice would be a viable solution.
Note that Electrum would enable you to import and scan the keys in a matter of minutes, whereas rescanning in Bitcoin Core could take hours. Neither guarantees that the "keys" found are actually going to contain any coins.
|
|
|
|
My Bitcoin Core is fully synced and I tried opening this wallet but get stuck on "Opening Wallet. Not sure what do next.
It's likely that Bitcoin Core was "rescanning" your "new" wallet with all the recovered keys in it... it will be starting from basically block 0... and this can take several hours to complete. Check the debug.log in your Bitcoin Core datadir... you should hopefully see a bunch of debug lines like this: ...
2021-05-19T05:59:34Z [default_wallet] Still rescanning. At block 538973. Progress=0.525272
2021-05-19T06:00:34Z [default_wallet] Still rescanning. At block 544471. Progress=0.538657
2021-05-19T06:01:34Z [default_wallet] Still rescanning. At block 550317. Progress=0.555550
2021-05-19T06:02:34Z [default_wallet] Still rescanning. At block 555563. Progress=0.571671
2021-05-19T06:03:34Z [default_wallet] Still rescanning. At block 561564. Progress=0.590429
...
It should also give you an idea how how quickly it is syncing... note that the progress value is from 0 to 1.0, where 1.0 == 100%... so in the lines above... the last line was at just over 59% complete
I'm in the same boat as this guy. Except things are shuffled in the wallet. I can find ke and y1 and na and me but pywallet leads to the same error. Also don't remember getting that windows error. I did try --recover but no keys or possible wallets were found. Any ideas what command to try or where to proceed next?
Sounds like a corrupted recovery... or possibly the text editor you're using is formatting the binary data in a really weird way... what text editor did you use? I'd recommend Notepad++ If Pywallet isn't able to find any keys to recover, then it's possible the recovered wallet is too badly damaged or the data has been overwritten on disk, so it wasn't able to find anything resembling a wallet.dat. It can be a bit "hit and miss"... so maybe try different recovery software... or maybe raw image the drive then try scanning the raw image for the hex markers for wallet.dat fields/private keys etc |
|
|
|
I hope you will get it someday.
You just need to dig a little bit deeper pull it apart and reassemble it in a slightly altered way.
Are you being deliberately obtuse? or am I just missing something obvious? I honestly have no idea what you're talking about when you say that "you can do it"... do what exactly? The script takes the raw encrypted "mkey" hex, breaks it down into the actual key, the salt, the iterations etc... then prompts for the wallet passphrase... then decrypts the master key... then uses that decrypted master key to decrypt a given "ckey" record (note that the pubkey part of the "ckey" is required as it is used to form the "IV" for the encrypted private key) So why do I need to dig a little bit deeper? What needs pulling apart? What does the script not currently do, that you think it should? |
|
|
|
Have you tried creating a separate "descriptor" wallet that uses the xpub (and appropriate derivation path)? This should enable you to create a "watching-only" wallet that uses the underlying xpub+derivation path to generate and ultimately monitor addresses. Regardless, you will need to do one rescan of the current blockchain for it to pick up all the transactions that are already associated with the addresses generated... but once the initial rescan is complete, it should just work as normal. As the addresses will be automatically generated (defaults to generating 1000, if a higher/lower limit is not specified), then you should not need to rescan again. Also, having it in a separate wallet file means you won't affect or "pollute" your current wallet file with the watching only data.
EDIT: I have tested this today, and it works... but a couple of important notes: - Bitcoin Core only accepts xpubs (and xprvs)... not ypubs/yprvs nor zpubs/zprvs... I used the converter here: https://jlopp.github.io/xpub-converter/ (open source) - The xpubs provided by Trezor Suite are at the Account level (ie. m/44'/0'/0' or m/49'/0'/0' etc) - You will need a separate wallet for each Trezor "account"... otherwise, your balances/transactions will be all mixed. - I'm not sure if you can specify receive and change in the same descriptor... i just imported them as two descriptors... one marked external (receive) and one marked internal (change) - for the P2SH-P2WPKH (nested segwit) Trezor accounts... the descriptor format should be: sh(wpkh(xpub_long_string_here/0/*))#CHECKSUM
sh(wpkh(xpub_long_string_here/1/*))#CHECKSUM
- You can calculate the CHECKSUM value for each descriptor by using getdescriptorinfo command. Note that each descriptor will have a unique checksum. - you can import both "receive" and "change" descriptors at the same time: importdescriptors '[{"desc":"sh(wpkh(xpub_long_string_here/0/*))#CHECKSUM","active":true,"timestamp":1514764800,"internal":false},{"desc":"sh(wpkh(xpub_long_string_here/1/*))#CHECKSUM","active":true,"timestamp":1514764800,"internal":true}]'
This will mean you only need to do one rescan. - For the timestamps, I used https://www.epochconverter.com/ I went back in the account history, then picked a date that was at least a few days before the first transaction showing in the account history (I picked 1st Jan 2018)... and converted that to "unix epoch" format. The timestamp isn't strictly necessary... but it can reduce the rescan time by a significant amount if you have only used your wallet for a couple of years as it starts the rescan from around the timestamp, rather than at block 0 (the default value). - I did a quick "get new receive address" test and both Trezor Suite and Bitcon Core showed the same receive address as the first "unused" address But obviously, Bitcoin Core will allow you to get multiple "new" receive addresses. So, there could be a potential "gap limit" issue if you were to generate too many receive address in Bitcoin Core and then receive coins to one of those address past the Trezor Suite gap limit (I'm not sure what this limit actually is) |
|
|
|
Most likely a "block max age" or an "assumed block size" issue... have a read of this: https://bitcointalk.org/index.php?topic=5309100.msg56085433#msg56085433... In this tutorial I will not explain how to make our own genesis block, because we want to achieve something simple. Anyone who takes it more seriously can search and learn how it is done. Thus, we need to change the value of nMaxTipAge in validation.cpp: Multiply it with a big number like 10000. int64_t nMaxTipAge = DEFAULT_MAX_TIP_AGE * 10000; In consensus/consensus.h we need to change COINBASE_MATURITY which means how "deep" a block must be for the miner to spend its reward. In bitcoin it is 100, that is, someone who will mine 1 block must wait 100 blocks to spend its coins. We can give it any value, I will put it equal with 3: static const int COINBASE_MATURITY = 3; Finally, we need to change these two lines of chainparams.cpp: m_assumed_blockchain_size = 1;
m_assumed_chain_state_size = 1; ... and maybe this: https://bitcointalk.org/index.php?topic=5283684.20I know when I was experimenting when trying to help BlackHatCointer, that I had issues with getting the 2nd box to pick up new blocks that were being mined... I can't remember exactly what was needed to get it working... but I believe it was a combination of the max tip age and the assumed blockchain size. |
|
|
|
I'm not sure about the old old versions of Bitcoin Core/QT... but the newer ones definitely carry a warning to let you know that when you add encryption to a wallet.dat, as soon as the encrypted wallet is "used", old unencrypted backups will become "useless":  I hope it isn't a huge loss
Wallets like Electrum have the option in settings to not use change addresses. This helps make backup a lot more simple, but you give up a certain amount of financial privacy in doing so. Still, change addresses are a tricky thing for people to comprehend and I would advise new users who don’t comprehend the way change addresses work to take advantage of features that will keep your coins from ending up at change addresses. Even if you manage your change addresses properly, you’d have to constantly be backing them up in order to keep from losing your funds in the event of a hard drive crash.
That isn't really an issue with a wallet like Electrum... all addresses (receive and change) are recoverable from the seed. So, as long as you still have the seed, you can recover everything. The same applies to a wallet like Bitcoin Core... the issue here is that the OP effectively changed the "seed" by adding encryption to the wallet (rendering old unencrypted backups useless)... and then lost/forgot the passphrase to the wallet... effectively removing their access to the seed/private keys required to access the change addresses. This isn't really a "change" address issue, per se... it's a lost passphrase problem. |
|
|
|
Perhaps you can add this also then you can do it from Crypto.Cipher import AES
I'm not sure what you mean by this? That is one of the first things the script attempts to do... it checks to see if pycrypto is installed, if so then it sets up the "crypter" to use that... otherwise it tries OpenSSL, if that fails, then it tries to use "slowaes" and if that fails it prints an error message and exits. |
|
|
|
How hard would it be for jackjack or someone to create a standalone tool to decrypt private keys, if the correct hex strings and passphrase were inputted? Not that I'm implying he should, as he seems to be a very busy person. But If you can search out the required info with a hex editor, it would be a very flexible tool for fragmented wallet files.
Probably not very difficult... because it didn't take me too long to bang this out: https://keybase.pub/hcp/python/core_decrypter.pyIt's pretty rough... but basically, if you can feed it an "encrypted master key" (or decrypted master key), "encrypted private key" and matching "public key"... it will prompt for wallet passphrase and then attempt to decrypt the master key... then use that to decrypt the private key before outputting the Address+WIF. I've run some tests on some newly generated wallet.dat data... and the master key/priv key/pub key data from the code example in joric's post that I linked to earlier... and it seems to be working OK. As per the comment at the top of the script, it borrows very heavily from the "Proof of Concept" code from joric's post.... full credit to them!
NOTES: - Python 2.7x compatible only for now... if there is enough interest, I'll see if I can make it Python3 compatible. - requires a couple of libraries that you'll likely already have installed if you've been using PyWallet etc (ie. pycrypto, ecdsa etc)... if Python moans at you about modules not being found then install them with pip
- (For now) The encrypted master key needs to be the full 66/67 bytes (132/134 hex chars) of the mkey record in the wallet.dat... This should be of the form: "30" - 48 byte data record indicator "48 bytes worth of encrypted master key" "08" - 8 byte data record indicator "8 bytes worth of salt" "4 bytes worth of method" - should be 0 (ie. 00000000) "4 bytes worth of iterations" - in Little Endian (ie. 1fb80000 ==> 0x0000b8f1 ==> 47345) "00" - 1 byte end of record indicator (optional) for example: 3008adc5605413b38a04979bf465d0cff826a25c2c8812e582241477052c6d45c11b27690ba3bf2c1da144600789c2baaa08d8659791be653e15000000001760030000
3008adc5605413b38a04979bf465d0cff826a25c2c8812e582241477052c6d45c11b27690ba3bf2c1 da144600789c2baaa08d8659791be653e15000000001760030000
This modified version of the walletinfo.py script (original here) will output the "full mkey" from a wallet.dat: https://keybase.pub/hcp/python/walletinfo.pyUsage: python walletinfo.py wallet.dat
otherwise, you'll have to do some hexediting of the wallet.dat file to find the data you need... have fun with that I am also considering modifying the script so you can supply the "parsed" master key data (ie. encrypted key, salt, iterations etc) individually... I guess it depends on what is the most likely format of the hex data extracted from the wallet.dat file.
On subsequent runs for private keys from the same wallet.dat (ie. encrypted with the same master key), you can just use the "decrypted master key" that is output instead of using the "encrypted" master key + walletpassphrase Example: C:\core_decrypter>C:\Python27\python.exe core_decrypter.py --enc_mkey 3008ADC5605413B38A04979BF465D0CFF826A25C2C8812E582241477052C6D45C11B27690BA3BF2C1DA144600789C2BAAA08D8659791BE653E150000000017600300 BF1356ABEEB7FD2C7CD6757BA4B459AF64D62A3855592B24F685F642D7143D7F6725230C8B8D9B65D42DA5634DDA9A73 020016BE1AFB579AB2EF6F57220E8946B0653FD5B883E09D70A7825F17C3B07F3D
Enter wallet passphrase:
Keys successfully decrypted:
decrypted mkey: 84d1f2f2380eb3a089ea256b851553ebfbc95555eb11b28a9eaaa7eeb97db4d6
--------------------------------------------------------------
uncomp addr: 13y8obG15gqVBmuRzD7HnokyVqGhQJZBfC
uncomp WIF : 5JXMD129XHcfpWF8hrzKG7eW4zDwZtuQ82gkwfMLz9aQRTxvsrh
--------------------------------------------------------------
comp addr : 15V1kJedt9CJDsEYCofuvfWTyapqJPW4C9
comp WIF : KzLxBy64cgLSLg5P1MdybiLXJba7rC6H42SUxGGoDErSNtSKCJKP
--------------------------------------------------------------
C:\core_decrypter>
On the next run, you can just use the "decrypted mkey" that was displayed: 84d1f2f2380eb3a089ea256b851553ebfbc95555eb11b28a9eaaa7eeb97db4d6
... and remove the --enc_mkey flag from the commandline: C:\core_decrypter>C:\Python27\python.exe core_decrypter.py 84d1f2f2380eb3a089ea256b851553ebfbc95555eb11b28a9eaaa7eeb97db4d6 ba946bb7db1a98e628d1a93104369d7cbb7a4cba9c9705223a2c7891bdc888a8b1019c27d2c17b28728513a51ba54f1e 0200cc635c13471b913e22bbe568711c19fd7bcb7449a9f09885f9ca53aff3cc6e
Keys successfully decrypted:
decrypted mkey: 84d1f2f2380eb3a089ea256b851553ebfbc95555eb11b28a9eaaa7eeb97db4d6
--------------------------------------------------------------
uncomp addr: 1K3p8CZCRZoKuXtzzawYs2LmKuN1uV2jvd
uncomp WIF : 5JsNBq7rwGPqp1jZLSgawvtusp3E47c2PjPex2QgK4Mhj4Bneuv
--------------------------------------------------------------
comp addr : 1CVQVAeTCPhNUCcVsmSqrZoXWQCksbmgmc
comp WIF : L1sJWoPHQWwpSWEqipMiqSt8PGcpck9b9L6zVsDWWhpNkErSrJwf
--------------------------------------------------------------
C:\core_decrypter>
NOTE that there is no "wallet passphrase" prompt!
If the walletpassphrase is not correct or the hex data is corrupt/incorrect, you will see a warning like this: C:\core_decrypter>C:\Python27\python.exe core_decrypter.py --enc_mkey 3008ADC5605413B38A04979BF465D0CFF826A25C2C8812E582241477052C6D45C11B27690BA3BF2C1DA144600789C2BAAA08D8659791BE653E150000000017600300 BF1356ABEEB7FD2C7CD6757BA4B459AF64D62A3855592B24F685F642D7143D7F6725230C8B8D9B65D42DA5634DDA9A73 020016BE1AFB579AB2EF6F57220E8946B0653FD5B883E09D70A7825F17C3B07F3D
Enter wallet passphrase:
WARNING!!!
WARNING!!! - computed public keys DO NOT match, passphrase is probably incorrect or hex data is corrupt
WARNING!!!
C:\core_decrypter>
The script calculates the pubkey from the decrypted privkey, then compares to the user supplied "hex pub key". If both the calculated compressed and uncompressed pubkeys do not match the user provided pubkey, then either the wallet passphrase was incorrect (resulting in a bad master key decrypt) or the priv/pub key hex data could be corrupt/incorrect.
Wallet passphrase for the examples above: password123 Partial Pywallet dump (with encrypted privkeys): keys": [
{
"addr": "15V1kJedt9CJDsEYCofuvfWTyapqJPW4C9",
"compressed": true,
"encrypted_privkey": "bf1356abeeb7fd2c7cd6757ba4b459af64d62a3855592b24f685f642d7143d7f6725230c8b8d9b65d42da5634dda9a73",
"pubkey": "020016be1afb579ab2ef6f57220e8946b0653fd5b883e09d70a7825f17c3b07f3d",
"reserve": 1
},
{
"addr": "1CVQVAeTCPhNUCcVsmSqrZoXWQCksbmgmc",
"compressed": true,
"encrypted_privkey": "ba946bb7db1a98e628d1a93104369d7cbb7a4cba9c9705223a2c7891bdc888a8b1019c27d2c17b28728513a51ba54f1e",
"pubkey": "0200cc635c13471b913e22bbe568711c19fd7bcb7449a9f09885f9ca53aff3cc6e",
"reserve": 1
},
{
"addr": "1JSo3zCQ8xaj9oGgfts8DMATtQ5ptnwigk",
"compressed": true,
"encrypted_privkey": "65207b28be9d6b142837e192797cc782e3c8f868fddb2fb901895dd4115c6bc1367c0787544f48bc631ec7e8fa0ebb51",
"pubkey": "02020828662e18c691abd0ca216d655c576bbbac560a8852e7aafb42acb76ed9b9",
"reserve": 1
},
|
|
|
|
The problem is that USDT is available on Omni (ie. Bitcoin blockchain), Ethereum (as ERC20 tokens), EOS, Tron and other layers: Tether tokens exist as digital tokens built on bitcoin (Omni and Liquid Protocol), Ethereum, EOS, Tron, Algorand, SLP and OMG blockchains.
It would appear that CoinList only support Tether as ERC20 tokens... I apologise for the situation but unfortunately these have not arrived to your account because you have deposited the funds to an address CoinList does not own. We currently do not have Omni support.
BTC deposits are to be made via the Bitcoin network and USDT deposits via the ERC20 network.
-> because you have deposited the funds to an address CoinList does not own! This is my BTC address on their exchange not an unknown
one
Exactly... as far as CoinList are concerned, it is a BTC only address... they do not have the facilities to be able to recover any Omni tokens associated with BTC addresses as they have no Omni support. To recover your coins, they would need to export the BTC private key associated with the deposit address you used, then import that into an Omni compatible wallet and then transfer the USDT to an Omni address of your choosing. Exporting the private key for a single address from within their "wallet" likely comes with a whole bunch of security issues... and potentially puts other funds at risk. Unless CoinList are willing to do that, or implement Omni support within their system... it would appear that your funds are going to remain in "limbo" |
|
|
|
|
Show Posts
