Im on a windows laptop now and downloaded the bitcoin.org wallet app but it just created a new wallet. I want to know how i can recover my other wallet with the seed i have. Thanks!
Unless you are more specific about the actual wallet app that you downloaded and installed, no one will be able to help you recover with the seed. "bitcoin.org" do not have a wallet app... they list a few "recommended" wallets: https://bitcoin.org/en/choose-your-wallet?step=5&platform=windowsOut of the list for Windows desktop wallets, which one did you choose?   |
|
|
|
If you installed Armory using the .deb in Ubuntu... it should have put the following in your /usr/bin/ folder:  Assuming that /usr/bin is in your path, then, as you've already discovered, you simply run "ArmoryDB" to start the DB service:  To start "ArmoryQT", you simply run "armory" from the terminal:  Note: to get this running on my Ubuntu 18.04 VM (Oracle Virtual Box), I had to use the "noasm" GCC 4.9 version: Armory 0.96.5 Ubuntu/Debian 64-bit with GCC 4.9The GCC 7.2 version gave me "Illegal instruction (core dumped)" errors and the GUI would not start:  |
|
|
|
The Trezor Model T generates 12-word seed phrase.
It generates 12 words by default... but as I understand it, you can override that and select 24 words if you want, but it requires using the "trezorctl" commandline tools In fact both devices are able to use 12, 18 or 24 word seeds. source: https://wiki.trezor.io/Recovery_seed#Recovery_seed_and_Trezor |
|
|
|
Nevermind the fact that September, October, November and December are not the 7th, 8th, 9th and 10th months of the year!  Those old geezers have some explaining to do! #OCD  |
|
|
|
I know everyone focuses on the "balance"... but what about the transaction history? Was there anything showing in the history? |
|
|
|
Thanks that helps. The issue I am still having is that when a address sends btc and I look at the scriptsig and extract the last 130 hex characters and enter it it the tools suggested in this thread it doesn't have any relation to the address or it's an invalid public key.
As a worked example... have a look at this recent tranasction: https://www.blockchain.com/btc/tx/bee2768770f68a31543eda6fd40da75e4432f434cf8c3312497cdeebb4a2ac6cIf we look at the sigscript: 47304402200c794238b992fbdda63b1606edc07c5b48a29e003e7cf9d4894baa7baf3b063b022012ed8593d439dc05e3639d60434028e8b0a2207a139ec58bf5e719e019f09485012102ebb666614f5faff4aa43e5f1be868ebc5f1be67c8553924410d8d0111a9912d2 Firstly we try the final 130 chars: 8593d439dc05e3639d60434028e8b0a2207a139ec58bf5e719e019f09485012102ebb666614f5faff4aa43e5f1be868ebc5f1be67c8553924410d8d0111a9912d2 Doesn't begin with "04", so it's not an uncompressed key... not surprising, given that it is a relatively recent transaction and most legacy addresses used today will be using "compressed" keys. Then we try the final 66: 02ebb666614f5faff4aa43e5f1be868ebc5f1be67c8553924410d8d0111a9912d2 "02", so it's likely a compressed public key... if we put that into the Address tool I listed earlier, we can see it outputs:  Which matches the bitcoin address from the transaction:  NOTE: This tool was not designed for "compressed" keys... it will complain that it has an "invalid public key length":  But it will still generate the correct address.
Now, let's look at this much older transaction: https://www.blockchain.com/btc/tx/b9d69463c500b81dc2ff600d0b528b15fb816c4dab11e424151de0bcbea7f26fThe sigscript of the first input is: 473044022018c35ebde490ca56f6d073a20ec3199f461ee9c99d2c020fdecd8711bdb9cc5802205fd0ce0f61ee2566cafd4254bc1d34a4fcf02d2a55c281a0a95a8c332bff2443014104f52193d56ffda6ef5fbc3b4ada7768c347321f47f1a999b0ca9b8374d8228275ee2c1ecf45c718538288667ad367f97a00116bd0630c76cc01f26161ce70057a The last 130 chars are: 04f52193d56ffda6ef5fbc3b4ada7768c347321f47f1a999b0ca9b8374d8228275ee2c1ecf45c718538288667ad367f97a00116bd0630c76cc01f26161ce70057a Starts with 04... quite likely an uncompressed public key... So, feeding that into the tool:  And we can see the address checks out:  |
|
|
|
You don't need to burn disks to run a live linux distro. Nowadays, we use USB flash drives. They are reusable, smaller and more handy. And they even can store more than 4GB already!  Which would be a great idea, except his hardware doesn't support booting from USB... As an aside, I decided that I am going to configure my old Win XP, to be a duel boot with ubuntu. Sadly, the hardware does not support boot from USB and I don't own a DVD burner. So I ordered a cheap one off of ebay and will have to try to install the os after that arrives.
It still doesn't cease to amaze me the lengths people will go to, to keep old hardware ticking along... There is a point where it's just easier (and often cheaper) to simply purchase something a bit more modern |
|
|
|
I apologize for letting this go way beyond the scope of my original question. But, I am intrigued by this and I want to learn more.
I feel ya... it's why I've been delving into these PSBTs and trying to decode them by hand in a text editor I completely understand your response. 2 inputs = 2 maps, 2 outputs = 2 maps. But, you created the transaction and know what to expect. How does a person, or algorithm decode this if they have no prior knowledge of the transaction.
All PSBT's must contain the unsigned transaction as part of the global map, which comes first. So, my "theory" is that you need to decode that transaction to identify the number of inputs/outputs involved. That then allows you to "assume" what the following maps are going to be, knowing that the order is: "Global - Inputs - Outputs" My confusion is with the data types that duplicate the values from the other scope.
Scope Type Values Name BIP Number
Input 0 PSBT_IN_NON_WITNESS_UTXO BIP 174
Input 1 PSBT_IN_WITNESS_UTXO BIP 174
Input 2 PSBT_IN_PARTIAL_SIG BIP 174
Output 0 PSBT_OUT_REDEEM_SCRIPT BIP 174
Output 1 PSBT_OUT_WITNESS_SCRIPT BIP 174
Output 2 PSBT_OUT_BIP32_DERIVATION BIP 174
Do I need to also look at the format of the data to determine which scope it belongs to? Or, am I guaranteed that each map will contain at least one data type value which is unique across both Input and Output and I can use that to determine which scope the map belongs to?
Yeah, I know what you mean... it's weird seeing the same "Type" value for both Inputs and Outputs and trying to determine which one it is... that confused the hell out of me until I figured out that the unsigned transaction must be included and must be the first item. So you can derive the number of inputs/outputs from that unsigned tx and then process the rest of the maps. |
|
|
|
Presumably, the first map after the Global map is an Input map. And the last map in the transaction is an Output map. But, what about the maps in-between? How can we tell if it an input map or an output map?
Each input in the transaction has to have a matching input map... so 2 inputs = 2 input maps... 2 outputs = 2 output maps. So, I think you actually need to decode the raw transaction, and work out how many inputs/outputs you have. Here is the full breakdown of the psbt that I had earlier (showing the different keys/values etc): Raw PSBT HEX: 70736274ff0100a002000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00000100df0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00220602636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c0c6b163ff90100000022000000000100e20200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800220602029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c380c6b163ff901000000150000000022020206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece707795930c6b163ff9010000002b000000002202033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc3510c6b163ff9000000000000000000
Split PSBT HEX: 70736274 - Magic Bytes
ff - Global Separator
01 - Key Length = 1 byte
00 - Key Data = 00 -> Unsigned Transaction
a0 - Value length = a0 bytes = 160 bytes
02000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00
00 - Separator
INPUT MAP #1 Starts here!
01 - Key length = 1 byte
00 - Key Data = 00 -> PSBT_IN_NON_WITNESS_UTXO
df - Value length = df bytes = 446 bytes
0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00
22 - Key Length = 34 bytes
0602636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c - Key Data
=> 06 - PSBT_IN_BIP32_DERIVATION
=> 2636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c - Public Key
0c - Value Length = 12 bytes
6b163ff90100000022000000 - Value Data
=> 6b163ff9 - Master Key Fingerprint
=> 0100000022000000 = Derivation path 01000000\22000000 (little endian!) => m\1\34
00 - Separator
INPUT MAP #2 starts here!
01 - Key Length = 1 byte
00 - Key Data == 00 -> PSBT_IN_NON_WITNESS_UTXO
e2 - Value length = e2 bytes = 452 bytes
0200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800
22 - key length = 34 bytes
0602029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c38 - Key Data
=> 06 - PSBT_IN_BIP32_DERIVATION
=> 02029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c38 - Public Key
0c - value length = 12 bytes
6b163ff90100000015000000 - Value Data
=> 6b163ff9 - Master Key Fingerprint
=> 0100000015000000 = Derivation Path 01000000\15000000 (little endian!) => m\1\21
00 - separator
Output Map #1 starts here!
22 - key length = 34 bytes
020206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece70779593 - Key Data
=> 02 - PSBT_OUT_BIP32_DERIVATION
=> 0206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece70779593 - Public Key
0c - value length = 12 bytes
6b163ff9010000002b000000 - Value Data
=> 6b163ff9 - Master Key Fingerprint
=> 010000002b000000 = Derivation Path 01000000\2b000000 (little endian!) => m\1\43
00 - Separator
Output Map #2 starts here!
22 - Key length = 34 bytes
02033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc351 - Key data
=> 02 - PSBT_OUT_BIP32_DERIVATION
=> 033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc351 - Public Key
0c - value length = 12 bytes
6b163ff90000000000000000 - Value Data
=> 6b163ff9 - Master Key Fingerprint
=> 0000000000000000 = Derivation Path 00000000\00000000 => m\0\0
00 - Separator
NOTE: I had an issue with some other PSBT that I was trying to "decode" manually... the "length" values are in "compact sized unsigned int" form... ie. if the "length" is > 252, it'll actually be displayed as 3 bytes... starting "fd"... and in little endian!!?! so "fd0201" (the example I was looking at) actually means 0x0102 == 258 bytes  |
|
|
|
Just posting snippets of debug output doesn't exactly help without some context.  What exactly have you tried when you got that output? Is that just the output from running ArmoryDB.exe manually? What happened when you tried to run ArmoryQT? Did it start at all? |
|
|
|
|
I would say the answers to #1 and #2 are both: "Most likely not"... I suspect that fake website is designed to either steal Stellar "secret keys" by tricking users into connecting and opening the wallet using that key to connect and/or steal coins by simply getting users to send their coins to a fake "staking" service.
As you connected with the Nano S, the keys will not have been exposed as they are secured within the secure element in the device... and no wallet (or website) is able to extract them. This is the advantage of the hardware wallet... your keys cannot be compromised unless you explicitly type them into the website (or fake app) as they cannot be extract from the device.
|
|
|
|
Ok I think I have found how to do that now. How about a method to do the reverse (turn uncompressed public key into address)?
This online tool will do it for you: https://gobittest.appspot.com/AddressJust ignore the box labelled "0 - Private ECDSA Key"... and put the public key in the box labelled "1 - Public ECDSA Key" and then press "Send"... it'll show you the step by step guides and the address at the bottom... but the method is basically the same as BlackHatCoiner posted above: 1 - Public ECDSA Key 044F355BDCB7CC0AF728EF3CCEB9615D90684BB5B2CA5F859AB0F0B704075871AA385B6B1B8EAD809CA67454D9683FCF2BA03456D6FE2C4ABE2B07F0FBDBB2F1C1
2 - SHA-256 hash of 1 34D7F0FE7AFE22D2BE114044D87F928C7F9044B0F104696E51594890F38CCD15
3 - RIPEMD-160 Hash of 2 E4E517EE07984A4000CD7B00CBCB545911C541C4
4 - Adding network bytes to 3 00E4E517EE07984A4000CD7B00CBCB545911C541C4
5 - SHA-256 hash of 4 A3FEB7F37B0EC2B6C7E8B7F8C24C5A2F57FAD84BD56861EE5872B335C9F720D0
6 - SHA-256 hash of 5 532576DD2D179AD8377DEC7EA13D447D1345A857AA5A904B4ED4AC67B5888B75
7 - First four bytes of 6 8 - Adding 7 at the end of 4 00E4E517EE07984A4000CD7B00CBCB545911C541C4532576DD
9 - Base58 encoding of 8 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
|
|
|
|
It's unlikely that making a manual transaction will work... the issue is the "old" 100kb transaction size limit... it's now a "weight" limit of 400000. /** The maximum weight for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000;
Weight / 4 = size... so 400000 / 4 = 100000 bytes or 100kb... Your transaction is 156kb... it's simply too large to be relayed. Whether you try and create this transaction using Electrum or doing it manually, it'll still be refused by most, if not all, nodes. Your best bet will be to use "coin control" in Electrum... use "View -> Show Coins" and try selecting in groups of 100 and send them back to yourself with a low fee... once you have done that with the 1060 "small value" UTXOs, you'll be left with around 10-11 "larger value" UTXOs... Have a read of this: Fees are low, use this opportunity to Consolidate your small inputs!NOTE: fees are super low, but they are fairly low at the time of writing this... it'll still cost you more if you need fast confirmation at the moment as a "next block fee rate" is currently around 6-10 sats/byte... otherwise, if you create the consolidation transactions with 1 sat/byte, you'll be waiting hours, if not days, for confirmation... as there are like 50 blocks worth of unconfirmed 1 sat/byte transactions at the moment. |
|
|
|
I am able to follow what you are saying. However, I am still a little confused about the rest of your transaction. The specification at https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#cite_note-6 says the PSBT should have 3 sets of key-value maps. (Global, input, and output). Your transaction appears to have 5 sets of maps. ... I also decided to look at the example I first started with. I found it contained one extra set of key-value maps. Do you know what this extra data is used for? You can have multiple input and output key-value maps... Looking at the data (and what Bitcoin Core outputs when I used decodepsbt with that, they appear to be BIP32 derivation info for outputs (pubkey, master_fingerprint and path etc)
It's a hex format and how did you get the parse error it should be work unless you create an unsigned transaction which is not yours?
...
If you create an unsigned transaction from a watch-only wallet(Electrum 4.0.9) it should look like this.
*snip*
It's a hex transaction you need to copy that thing to a notepad to transfer it to the offline machine and paste that thing into your offline wallet(Electrum 2.9.0).
Do it again by exporting the unsigned transaction and use "copy to clipboard" and paste it to notepad to transfer it to the offline machine then repeat the procedure above.
That doesn't work any longer, and hasn't for a while (changed in 4.0.1 - https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L123)... Electrum has moved away from it's old "custom" unsigned transaction format and it is no longer supported. Electrum is now using "Partially Signed Bitcoin Transaction" PSBT format. Using "copy to clipboard" now gives a Base64 encoded "PSBT"... As noted in the release notes: * Partially Signed Bitcoin Transactions (PSBT, BIP-174) are supported
(#5721). The previous Electrum partial transaction format is no
longer supported, i.e. this is an incompatible change. Users should
make sure that all instances of Electrum they use to co-sign or
offline sign, are updated together.
|
|
|
|
|
It would depend entirely on your network setup and the way the OSes/firewalls on the PCs are configured...
|
|
|
|
If you want to sell the whole thing (coin+balance) then sell it the same way you'd sell any other physical item... Ebay, craigslist, the collectibles section here on Bitcointalk etc... If you're just wanting to cash out the BTC, then Ebay isn't an option. You'd need to expose the private key on the coin, import that into a wallet and then send the balance to an exchange. For a wallet I would suggest Electrum or Wasabi... can't really comment on exchanges as there are a number of issues around location/country etc. |
|
|
|
why is this slow as hell? It's generally a function of CPU/storage device/network... Note that your computer isn't just "downloading" 350 gigs... it has to process and validate all the transactions/blocks that it receives as well. This is disk/CPU heavy. If your hardware is not great (ie. HDD instead of SSD, older CPUs etc, low RAM), that will slow things down. looking for ways to bypass the sync process for bitcoin core.
The only way to do this is to get a copy of the blockchain data from a fully synced node from a trusted source. If you really don't want to wait and don't need to be running a full node, then switch to a lightweight "SPV" wallet like Electrum or Wasabi. |
|
|
|
A suggestion I read is that your seed might be 2FA. So try to create a new Electrum wallet, choose 2FA, and import the seed. See if that recovers the funds.
Unlikely to be an issue... Electrum automatically detects the seed "type"... it'll tell you right on the seed entry screen what the seed type is. If you initially select "Standard" wallet and then enter a "2FA" seed, it'll automatically switch to recovering a 2FA wallet. If I had to guess, I would guess that it's a BIP39 seed and derivation path issue... or possibly a multisig? @duemay, does your old address start with a "1" or a "3"? |
|
|
|
bitcoinfees.earn is notorious for grossly over estimating the required fee.
I concur... your best options are jochen-hoenicke.de and mempool.space... in my opinion, those 2 sites give the best overall view of what is currently happening with regards to network activity and fees etc. |
|
|
|
I have an old multibit.key file that I'm trying to import into Electrum.
...
Alternatively, is there a way to unencrypt it without using Multibit Classic?
The guide that I wrote earlier as linked by ranochigo above is your best bet without Multibit Classic. I will just add that unless you know what password was used to encrypt that .key file (and/or have a very good idea of the length of the password and whether it was UPPER/lower/numbers/symbols etc) then your chances of decrypting that .key are virtually zero. |
|
|
|
|
Show Posts
