I don't think changing the 'change address' setting will cause transaction timeout nor that message. Also, the message isn't about the issue but the reason why Armory can't display the cause of the timeout. For now, try to add server=1 to your bitcoin.conf file in Bitcoin Core's data directory. For the transaction, you can also try to broadcast the raw transaction though other methods like directly with Bitcoin Core's console ( sendrawtransaction) or some blockexporers ( blockstream). If any of those rejected it, it will come with an error which will tell what went wrong. To get the 'raw transaction ( hex)' of the transaction that you want to send: - Create a transaction "normally", but instead of clicking the "Send!" button below, tick "create unsigned" instead.
- Click "Continue" and you'll be presented with an unsigned transaction data that looks like this:
=====TXSIGCOLLECT-3gg5Z8fX======================================
AQAAAPq/tdoAAAAAAf1aAQEA..... - Click "Copy to Clipboard", then click "Continue"; Paste the previously copied data there and it will show that it's 'unsigned'.
- Click "Sign", "Continue" then type your passphrase to sign the transaction.
- Lastly, it will display "All Signatures Valid!"; with that, you can now click "Copy Raw Tx (Hex)" to get the raw transaction.
The data that you've copied should only contain the characters 0~9 and A-F, try to paste it on a blank text document.
You can use that to broadcast the transaction through the options I've given above.
Note: for the features to appear, Armory should be in Advanced user mode or higher ( User->Advanced). |
|
|
|
root@RémiM:~# python2.7 core_decrypter.py?dl=1.1
-snip-
root@RémiM:~# pip install base58
Requirement already satisfied: base58 in /usr/local/lib/python3.9/dist-packages (2.1.1)
can you help please? Thanks
everytime i try i get thiis
Pip is installing base58 to Python 3.9 while you're using Python 2.7 for core_decrypter.py. Try to specify the python version when using pip. |
|
|
|
Second, is this token listed on Kucoin? because if it's not listed on kucoin, how come you sent it to kucoin? as it appears according to your story, he is not yet listed.
It's possible in scenarios when the native coin has the same address format as the token. For example: Let's say he'd intended to send ETH to his deposit address 0x012345.... but instead sent an ERC20 ETH Token to it, the exchange will not credit that deposit if they do not support the token but the transaction will proceed since the address can receive the token. This is his relevant reply: /index.php?topic=5409166.msg60720089#msg60720089 |
|
|
|
without providing the argument to compile with GPU capabilities. -snip-
it still throws errors. Tried the release and master branch. IMHO the bug is not in the GPU/Cuda part but somewhere else ?
I think you should start with the compiler or other requirement, see if you satisfied the required versions, specially gcc since you already tried the release which should work without an issue, also compiled without CUDA. Other that that, I have no other comment since I can't reproduce it. |
|
|
|
The backup phrase from the security setting is a BIP39 seed and can be imported to any wallet that supports BIP39,
the user has to know the correct derivation path of each wallet to restore each though.
For bitcoin, blockchain.com derivation path was m/44'/0'/0'/0/0 before, which is for legacy addresses. But now, it is m/84'/0'/0'/0/0 which is native segwit. Blockchain.com follow the standard derivation path, the seed phrase should be easy to import on other standard BIP39 wallets. You may need to remove the address index ( last "/0") from those derivation paths because it points to the first address instead of the whole wallet. Anyways, by saying " each wallet", I mean each subsequent wallets aside from " private key wallet". Each of those additional wallets' derivation path should be at account index 1 and above, most of their users aren't aware of that. |
|
|
|
Just tried this. No luck! I also tried using all the available codes for my GPU which I got with
-snip-
You also tried it without a -gpu parameter and it still produced an invalid WIF PrvKey and address... Anyways, have you tried to compile the source code from vanitysearch's releases instead of the master branch? I think the best course of action is to support the existing issue in GitHub by adding more info. The developer may need it to fix the issue. |
|
|
|
According to the output on the second search while omitting the GPU flag it shows only "Number of CPU thread used" = 1 and no hint about GPU. But the error is still there, the calculation is wrong.
Hmm, that's weird since I'm not experiencing that using Vanitysearch v1.19 ( release). Here's the result of ./vanitysearch -check command: GetBase10() Results OK
Add() Results OK : 666.667 MegaAdd/sec
Mult() Results OK : 44.209 MegaMult/sec
Div() Results OK : 5.368 MegaDiv/sec
ModInv()/ModExp() Results OK
ModInv() Results OK : 531.457 KiloInv/sec
IntGroup.ModInv() Results OK : 9.421 MegaInv/sec
ModMulK1() Results OK : 39.186 MegaMult/sec
ModSquareK1() Results OK : 47.253 MegaSqr/sec
ModInv() Cost : 88.9 S
ModMulK1order() Results OK : 6.737 MegaMult/sec
ModSqrt() Results OK !
Check Generator :OK
Check Double :OK
Check Add :OK
Check GenKey :OK
Adress : 15t3Nt1zyMETkHbjJTTshxLnqPzQvAtdCe OK!
Adress : 1BoatSLRHtKNngkdXEeobR76b53LETtpyT OK!
Adress : 1Test6BNjSJC5qwYXsjwKVLvz7DpfLehy OK!
Adress : 16S5PAsGZ8VFM1CRGGLqm37XHrp46f6CTn OK!
Adress : 1Tst2RwMxZn9cYY5mQhCdJic3JJrK7Fq7 OK!
Adress : 3CyQYcByvcWK8BkYJabBS82yDLNWt6rWSx OK!
Adress : 31to1KQe67YjoDfYnwFJThsGeQcFhVDM5Q OK!
Adress : bc1q6tqytpg06uhmtnhn9s4f35gkt8yya5a24dptmn OK!
Check Calc PubKey (full) 1ViViGLEawN27xRzGrEhhYPQrZiTKvKLo :OK
Check Calc PubKey (even) 385cR5DM96n1HvBDMzLHPYcw89fZAXULJP:OK
Check Calc PubKey (odd) 18aPiLmTow7Xgu96msrDYvSSWweCvB9oBA:OK
GPUEngine: CudaGetDeviceCount CUDA driver version is insufficient for CUDA runtime version 35 A quick test using your command: ./vanitySearch -stop 1cit: PubAddress: 1citZrQ1cZ5Hhx62v4uzv5rVHvv84hCUc
Priv (WIF): p2pkh:L2yxjxkwLKAoanYJ7f5SE2z82UVoPmGQdksjyWdsBGDn3dwLHasP
Priv (HEX): 0xABF38C98E8F446012CA1C5F40D8E96761DE1E2F10A1B06A8A642316F20EB04B6 WIF private key and address are valid and correct. Have you compiled directly from the master branch? If so, try to build from the 'releases tags' instead, specifically v1.19 ( link). The issue may have been introduced by the last few commits after Aug 10, 2020. |
|
|
|
-snip-One more example with legacy address ... $ sudo ./VanitySearch -stop -t 4 -gpu 1citbo
VanitySearch v1.19
Difficulty: 15318045009
Search: 1citbo [Compressed]
Start Fri Aug 26 02:33:37 2022
Base Key: 2E1FCD8E1F65964ACDC032650D63817355259952D4CBD2C8CD2A5C577B49E882
Number of CPU thread: 4
GPU: GPU #0 NVIDIA GeForce RTX 3070 Laptop GPU (40x128 cores) Grid(320x128)
[1661.79 Mkey/s][GPU 1635.34 Mkey/s][Total 2^33.63][Prob 58.0%][60% in 00:00:00][Found 0]
PubAddress: 1citboYAWtgbJCySZe8C7U7y36cxGfZUZ
Priv (WIF): p2pkh:L5NB8KdCFkL7q8ZTAKAuHHeJhsP41XoJijqtuiZrXJffMEfzwaZy
Priv (HEX): 0xF30DBBB1FFF76EBF9741202CCE4676B6258ACCAF648C040844D9796F239AD998 <--- is correct
What's wrong here? Any clues?Anyway. I hope this post can help other like-minded Linux users to get VanitySearch run on latest GNU/Linux version with CUDA support. If you have failed like I did, you can try this little tutorial shown here which in my case is related to Ubuntu 22.04 Jammy Jellyfish with Nvidia CUDA running. I wish you success and keep my fingers crossed. Thanks and good luck!!! Just like the result in your vanitySearch -check command, the checksum here is also invalid. The first four Bytes of SHA256[SHA256(80F30DBBB1FFF76EBF9741202CCE4676B6258ACCAF648C040844D9796F239AD99801)] should be: 0xA3B0A194while the invalid WIF private key has: 0x6B4E251C, so it didn't pass the checksum. Same with the address, 1citboYAWtgbJCySZe8C7U7y36cxGfZUZ has an invalid checksum of 0xB071873EThe first four Bytes of SHA256[SHA256(0006C186C1421FF64024B3FC356AF312061DE52688)] should be: 0x054A4884
Someone has reported a similar issue ( also using a GPU): https://github.com/JeanLucPons/VanitySearch/issues/124BTW, I'm not experiencing this when only using CPU. |
|
|
|
-snip-
It's very possible because it's centralized wallet. The restore backup they provide only works on their own platform since they disabled the privatekey import feature. You are only reserved access keys to the platform, not access to bitcoins completely (you are not the owner of your bitcoins). Only Blockchain(dot)com's 'Trading Account' and 'Exchange' are the centralized part, the other wallets ( which is the topic) are non-custodial. The backup phrase from the security setting is a BIP39 seed and can be imported to any wallet that supports BIP39, the user has to know the correct derivation path of each wallet to restore each though. |
|
|
|
So Blockchain.info/com wallet now requires you to get your account verified (but only in order to do currency exchanges, bank account transactions etc)
However I noticed that in their mobile app it became impossible to send or receive the payment without this verification
When I select send option, for example, I get the "Select Country of Residence" screen, and below a warning:
"Why do you need this?" "Righ now, digital currency conversions are only available in select countries"
The account verification ( KYC) will straight ask for the full address alongside with other information, perhaps that " Country of Residence" is just to verify that you're not in a crypto-restricted country and it may not proceed to ask further personal info. I don't see that pop-up by the way. If you're fine with that ( disclosing your country of residence) then, you can proceed ( if it asks for more info, cancel it). If not, you can export your backup phrase to another wallet to use your funds without logging in to blockchain.com. |
|
|
|
I have a noob doubt, if the hard fork of the BTC and the BCH was on Aug 1 of 2017, how is possible to see transaction in BCH currency before this date ????
You can search the TXID of the transaction in your screenshot on both Bitcoin and Bitcoin Cash blockchains ( used the same blockexplorer): As you can see, it's exactly the same as the one in Bitcoin's blockchain ( disregarding the address format) because of what's explained in the first reply of this thread. This is also why there are " forked coins". I don't undertand nothing
If so, why ask? |
|
|
|
What do you have in your bitcoin.conf file or command line parameters? Because AFAIK, Bitcoin Core wont work if you set its datadir to a NAS due to leveldb incompatibility. I don't know how you managed to make it work before but try to set only the " blocksdir" to your NAS and leave the " datadir" to your local disk. There surely must be some other detail(s) some of you could find for me to not expect the bitcoin core software to work and give up on the question I asked?
Feels like you already expecting an answer and just want to make sure... |
|
|
|
-snip-
I'm not sure you explain it poorly or confused between term "node" and "server" when the context is Bitcoin wallet. When people say "networking device", they usually refer to device such as router, switch or wifi receiver. Obviously you can't run Bitcoin full node on such device. I also thought that he's talking about networking instead of Bitcoin and got suspicious on his activity after browsing through his post history. After a few searches, I found out that his post is suspiciously similar to this answer from a Q&A website ( prob. paraphrased). from this page: state-true-or-false-nodes-and-servers-have-the-same-function |
|
|
|
It turns out that Green Wallet DOES have coin control (at least the desktop version, have not checked the web version). It's just not well documented, nor easy to find. But, you can manually select UTXOs to send as you work through doing the transaction.
The older versions already have the necessary coin-control options but for some reason, those were grayed-out ( unclickable). Maybe that's what made you think that it's missing that feature. But yeah, the latest versions' coin control options are now working properly, excluding freeze/unfreeze coin feature. BTW, Blockstream Green isn't a web wallet, this should be in " Bitcoin->Dev & Tech Discussion->Wallet software" board. |
|
|
|
Now i get the error
ERROR parsing wallet.dat, type b'mkey'
-snip-
but i foudn this on github
I found a lazier fix that won't cause errors: just don't parse the settings.
You mean this specific comment: link? If so, the OP's issue about type setting error isn't related to the type b'mkey' error that you're getting. You can try to open a new issue in that repository since I haven't found any duplicate and I can't reproduce it. |
|
|
|
-snip-
But everytime I get to add the password it says : segmentation fault.
How can i make it work?
From which version of pywallet was it? Because in my tests, I haven't encountered a 'seg fault' error by using the master branch of: https://github.com/jackjack-jj/pywallet/tree/masterTested in Python v2.7.17. Do not download from the releases tag, it's the old version from 2011. |
|
|
|
-snip-
How can i figure out the private keys from these information please?
If you've provided the passphrase, the WIF private keys will be listed under the " keys" json array ( usually above that master key array). It contains " addr", " compressed", " encrypted_privkey" down to " secret", the one that you're looking for are the " sec" above secret, which is the WIF prvKey of the address above it. But if you see this line: The wallet is encrypted but no passphrase is used Then there'll be no WIF keys listed there. |
|
|
|
-snip- But the problem I have is the windows. I am using windows 7 not 8. so what shall do?
Since you've mentioned that this thread already helped you, then what's the current issue? ( since you didn't mentioned it) This thread BTW is about synchronizing two Electrum wallets between different systems, it's quite not about " creating electrum on PC". |
|
|
|
Can you export private key if you are not able to login to the wallet but have the wallet.aes.json file?
Only if you know the wallet's password at the time when you extracted the " wallet.aes.json" file. The " aes" in the wallet file's name suggests that it's encrypted; and since it's basically a static copy of the wallet, its password wont change after you changed your password in their website/app. For private key export, you have some choices: - [1] their "My Wallet Backup Decrypt Tool" [link] which outputs BASE58 privKey (missing checksum, have to be converted to WIF prvKey),
- [2] BTCRecover [link] (needs command line knowledge)
- [3] or import it to their import wallet page and export your private key by following the OP (not recommended).
|
|
|
|
|
Show Posts
