You can check the destination address by double clicking on the transaction in the "History" tab. You should see at least one address in "Outputs".
NOTE: Any address in "Outputs" that is highlighted in Green or Yellow is yours... anything that has no highlight colour is an "external" address. So, check for the address in "Outputs" that has no highlight colour... it should be the deposit address on the Exchange. |
|
|
|
I did not create a multisig wallet, my wallet is a standard wallet. The one that is multisig I think it is only the one of the market since it serves as an intermediary between the buyer and the seller (by sequestering the buyer's payment while waiting for him to receive his package, before to give the money to the seller).
On this marketplace, when I find an item that I like, I buy it by making a payment, normally. Except that the payment I made does not go directly to the seller, it is sequestered by the marketplace and will only be given to the seller when I have declared that I have received my package. It is exactly the same principle as on the Vinted platform. Except that this is in bitcoins. I don't have any waalet on this marketplace.
And suddenly, since the seller canceled my purchase, the marketplace wants to return my payment by giving me an encrypted transaction and asking me to sign it (since my payment apparently was on a multisig wallet, that of marketplace), then broadcast it.
Likewise, if my purchase had been accepted by the seller, the marketplace would have sent a transaction to the seller, asking him to sign it and then broadcast it for himself.
The payment in bitcoin is unlocked thanks to 2 signatures: that of the market and mine in the event of a refund, OR that of the market and the seller in the event of a successful sale.
Right, so the Marketplace is essentially acting as Escrow... and creating 2-of-3 MultiSig addresses between the buyer, the seller and themselves. That's actually not a bad way of setting it up... That isn't an address... it is a "transactionID"... you'd need to look that transaction up on a blockexplorer to see which addresses were involved... however, given your info below, I don't think it is required to solve your problem, as I think I figured out what the issue is  As you can imagine, I do not have access to the private key associated with the multisig address which is used as input, as long as I do not recognize the address in imput on the transaction.
And when I configured my account on the marketplace, I was asked to enter a Bitcoin public key for multisig; there, I entered the public key linked to the reception address which I also entered.
A-HA! The golden piece of information... If you provided the public key for the "reception address" (ie. the address you are trying to get refunded to "bc1qr95w...w7") then you should definitely be able to sign the transaction provided by the marketplace. The screenshot shows that it is a 2-of-3, that already has 1 signature attached, so it would appear that they have indeed signed it already. I was trying to figure out what the issue was, and then noted this part in one of your previous messages: 2- I go to the "sign" menu: the market tells me "Paste here the transaction and your private key which belongs to the public key you used. Click on" Submit "to sign the transaction with your key";
I therefore paste the transaction then I will look for my private key on Electrum by right clicking on the reception address which I use for this transaction, I have to enter my password and there I obtain the private key which belongs to the public key used. I copy this private key, paste it on coinb.in to the dedicated location then I click submit and that's where it crashes, I get the following error message: "There is a problem with one or more of your inputs, please check and try again ". By having a quick experiment with Electrum and coinb.in Multisigs... I think I know what the problem is... when you view your Private Key in Electrum, it includes the "script_type" at the beginning of the private key... so it shows as something like this: p2wpkh:LPVqjAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxDB
 However, coinb.in doesn't know how to deal with that script_type prefix...  so when you copy the private key from Electrum... DO NOT copy the "p2wpkh:" part at the front... you ONLY want to copy the text AFTER the ":". In my example, it would be: LPVqjAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxDB
If you use just THAT part of the private key, you should be able to use the "Sign" functionality on coinb.in, which will successfully add the 2nd required signature, and output a fully signed transaction. You should then be able to broadcast that transaction to the network using the "Broadcast" page on coinb.in.   |
|
|
|
Installed Ubuntu on a VirtualBox and followed your instructions down to the letter. It worked.
Thank you so much HCP - you went above and beyond here. Legend.
Really appreciated.
Awesome, glad you got it sorted... I wish I had know about this "-md md5" business a couple of years ago when the whole multibit shutting down thing kicked off. There were a lot of people struggling with various multibit backup files and "incorrect password" issues... I now suspect that this might also be the reason why the openssl method did not work for a lot of people back then.  |
|
|
|
It's like password and passphrase etc... without context it's not possible to know if it is: - wallet password - Bitcoin Coin wallet.dat "passphrase" - BIP39 passphrase The various wallet developers don't help either by using different terms for the same things... and/or the same terms to mean different things! |
|
|
|
Question:
If I need to send bitcoin from this Electrum wallet I just created, do I need only the seed phrase to do so? No need to know the private key for instance? Basically, considering I know only the steps above, which is only the seed phrase, master public key and the address, is it sufficient enough to be able to move and have access to my coins and that is all I need to know?
Correct, you only need the seed mnemonic (aka 12 words)... When you restore the wallet from seed, it should automatically find the transaction(s) and balance etc... you can then create and sign transactions as required as the seed mnemonic will enable you to restore all the necessary private keys to be able to do so. Can anyone better or correct the steps above? Am I missing something? Is there something else I need to be doing? Or does everything sound OK?
eciate your inputs.
The only note I would make is that by creating the seed mnemonic in Electrum, you will be effectively "tied" to Electrum to restore your wallet, as Electrum seed mnemonics are not BIP39 compatible. That isn't necessarily a "bad thing"™, it's just something to be aware of. |
|
|
|
|
With the cookie file, you can control the access to the cookie file by setting the appropriate read permissions on the file. The .cookie is automatically created when the bitcoind daemon starts, and is deleted when the daemon stops.
bitcoin-cli should automagically find the .cookie file by looking in the default datadir when you execute it locally (assuming you left it as default)... otherwise, you can also specify the datadir using the -datadir option.
You can also use rpcallowip setting to restrict access to RPC to the localhost only for added protection.
|
|
|
|
The second one - openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-keys-YYYY-MM-DD -out bitcoin-wallet-keys-YYYY-MM-DD-decrypted . Using the Gitbash terminal on Windows, this command just returns nothing. No error, but nothing happens it just sits on the next line and there is no output file created in the directory. Am I doing something wrong here?
I am not overly familiar with "git bash", but I don't think you can use "general" Linux commands with it... it seems to be a "git" specific terminal emulator, ie. it's really only designed for working with "git" and not with general unix/linux shell commands.  You'd either need to setup something like Cygwin and use openssl with that, refer: https://www.ssl.com/how-to/install-openssl-on-windows-with-cygwin/or Install/Setup the Windows Subsystem for Linux (WSL) and install a linux distro like Ubuntu, refer: https://ubuntu.com/wslAlso, I downloaded the oldest Bitcoin Wallet APK that I could find from the app github ( version v3.11). I installed it on the Bluestacks Android Emulator and then created an encrypted "wallet-keys" export file... after mucking around in Ubuntu (in WSL) trying to decrypt this export with "openssl", I found a stackexchange comment that indicated that "old versions of OpenSSL" used a different hash function when generating the encrypt/decrypt key from the user entered passphrase... essentially, they moved from MD5 to SHA-256 by default: Why do I get errors when trying to decrypt 1.0.2 data with 1.1.0?
A message digest is used to create the encrypt/decrypt key from a human-entered passphrase. In OpenSSL 1.1.0 we changed from MD5 to SHA-256. We did this as part of an overall change to move away from the now-insecure and broken MD5 algorithm. If you have old files, use the "-md md5" flag to decrypt them.
(NOTE: I suspect this is also why newer versions of the app cannot read older backup files!) So, by adding the "-md md5" flag to the command, the decrypt (of "old" files) works: openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-keys-YYYY-MM-DD -out bitcoin-wallet-keys-YYYY-MM-DD-decrypted -md md5
For reference, here is my "test" data... Contents of my bitcoin-wallet-keys file: U2FsdGVkX19z6mv24j7b4xi3wJz77mt7uYVNdyh4OwBTuQ0dESxIAW58AfW+4Ik9asXc3SV1X3lM
6R1uHe/ulIjYv5Bkylv4ZtWPYnM5Jl6TMRWX1Q+7cCFBt3BKMdVLNCV8OcGofEs23XhWLT/j/YoH
C+0PfcS21mNjF0u42PVa9BJYBx4JfHSvwx0R3GjubszONRp+XRZZoJnU0Re7BzT+OELp8VLJfobO
HQ1sfwg=
Can be downloaded here: https://keybase.pub/hcp/bitcoin-wallet-keys-2020-11-17commandline: openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-keys-2020-11-17 -out bitcoin-wallet-keys-2020-11-17-decrypted -md md5
Contents of the generated "out" file # KEEP YOUR PRIVATE KEYS SAFE! Anyone who can read this can spend your Bitcoins.
L4oyNUNUhDPx5Vd3eShN8Q3fc7MeMxcGQA4WseU8Ys6Ebs7y8FKx 2020-11-17T05:08:03Z
|
|
|
|
Curiously, your debug said it was rescanning from block 374599 (~15th Sept 2015)2020-11-15T22:31:31Z [btc-wallet.dat] Rescanning last 282497 blocks (from block 374599)...
but then said it was actually starting the scanning from block hash: 2020-11-15T22:31:31Z [btc-wallet.dat] Rescan started from block 0000000000000000005fb267cc42dc8630668db3cd1f6a484374fbb4a5ccfc22...
Which is actually block 505160, from ~20th January 2018It's possible that it might not have correctly scanned everything it needed to find your "btc-wallet.dat" transactions. You could try forcing a rescan using the rescanblockchain command in the console window in the GUI... Note that this will likely take 2+ hours given the previous rescan took 90minutes). If it still doesn't find any transaction history/balance after a full rescan, then it's highly likely that you have the "wrong" wallet.dat... That is to say, the "wallet.dat" file that you encrypted/backed up in 2018 was not the wallet.dat file that Bitcoin Core was actually using and/or that had your bitcoin balance |
|
|
|
Are you making those RPC calls from the same machine or are they being initiated from across the network? If it's local, you might be better off not using the user/password option and simply using the .cookie file authentication. If it's a network request, you can use the "rpcauth" option which stores a "username:SALT$HASH" in your bitcoin.conf so that your password will still be "unknown" if the bitcoin.conf gets compromised. Refer: https://bitcoin.stackexchange.com/questions/46782/rpc-cookie-authentication |
|
|
|
I don't see what that thread has to do with "character encoding"? All I see in that thread is a user who claims they know their passphrase 110% and that it doesn't unlock their wallet? The exotic character sets add even more variations. It would be nice if someone could offer certainty about whether this is even a possibility. Because I think it's strange that the passphrase stopped working in 2015. I actually can't remember if I could ever unlock it using that phrase, but I do remember bitcoin-qt being buggy as all hell. frustrating me enough to the point I backed up the wallet.dat and removed the software and blockchain files. Does the passphrase that you believe that you used contain characters with accents and/or symbols etc? Also, do you still have an "original" copy/backup of your 2015 wallet.dat file that you have NOT attempted to open with a newer version of Bitcoin Core? When you open wallet.dat files in newer versions of Bitcoin Core, the wallet file gets updated/modified. It might be helpful if you still have the old version of the wallet.dat to (make copies of) and "experiment" with. You could try getting an old version of Bitcoin Core/QT from here: https://bitcoin.org/bin/ and seeing if it is able to open the old versions of your wallet.dat file and test whether the passphrase works on the old copies. If it does, you could try and dump all your private keys and then import those keys into a new version of Bitcoin Core (or a completely different wallet like Electrum etc) to recover your funds. Again, be sure to make copies of the wallet.dat and experiment on the copies, not the original! |
|
|
|
Without your old wallet.dat, you will not be able to access your old coins. So, do you have your old wallet.dat from 2009 backed up somewhere? If you don't, then you will not have access to any BTC. |
|
|
|
It is a tragedy that the message signing feature in Bitcoin Core is broken because it can no longer create an address that it can use for signing.
What do you mean that the message signing feature in Bitcoin Core is broken? You can easily create addresses that it can use to sign messages... on the console use the getnewaddress command and pass it the "legacy" parameter as the address_type: getnewaddress "label" "address_type"
for instance: getnewaddress "staked address" "legacy"
That will generate a "1-type" legacy address (with the label "staked address") that you can use to sign messages... giving it a meaningful label will also make it easier to find in your "address book" from the "Sign Message" screen. |
|
|
|
Yeah that was my thinking, I'm continuing to try a couple of python scripts, I'll report back on my findings but i'm almost certain its long gone.
Out of curiousity, what python scripts are you trying to use to scan the recovered data? I was curious about why pywallet didn't see the actual proper copy of a wallet.dat on a fresh harddisk
I'm not sure if something changed in the file format of newer wallet.dat's that prevents PyWallet from being able to detect them or if it's just unreliable... but like I said, I've sometimes had issues with it detecting a wallet.dat file which I know is there. |
|
|
|
Sure, but the checksum is still included when turning your seed phrase in to your seed number and then in to your master private keys, individual private keys, and addresses. If your wallet does not verify the checksum and lets you proceed with an incorrect checksum, then it will generate a different wallet than the same seed with the correct checksum.
Exactly... a lot of people don't seem to understand that the bits encoded in the BIP39 mnemonic are not actually your "seed" as such... it's just "entropy"... So, you don't generate a seed and then encode it into a mnemonic. You randomly generate the entropy and then encode that entropy into the mnemonic... then you derive the actual seed by using the PBKDF2 function, using the mnemonic and BIP39 passphrase as the "password" and "salt" parameters respectively. Obviously, if your mnemonic is "different" because the last word changes (ie. your mnemonic still encodes the same entropy, but has a wrong checksum), the output of the PBKDF2 function will also be different (as the input changed), and you'll end up with a different seed and therefore a different wallet. |
|
|
|
In that case, depending on the use-case, you could potentially use the device without networking (ie. no wifi, no sim) as a sort of airgapped device. It would be able to scan QR codes etc. However, I'm not sure if there are any mobile wallets that are configured for "offline" use like that tho... and possibly none that will work on "Jellybean"... Depending on the device, you might be able to find a version of LineageOS (or some other custom ROM) that would at least get you onto a slightly newer version of Android which might mean you can run one of the newer wallets... obviously, there are risks associated with custom ROMs etc, but probably less risky than attempting to use Android 4.3  Might be a fun "project", just to see if you can get it to work... but not sure I'd use it for much more than "spare change". |
|
|
|
I will try putting the keys into something like electrum directly. The reason i doubted they were keys is that they all follow the same pattern at the start and end of the 32byte string, whereas other example i've seen they are very much random, more like the strings which were found at the end of the search.
Yeah, it would not be very common that they all start and end with the same bytes... it's not impossible, just quite unlikely. the only software which comes up with anything is Recuva, but it recovers .dat files which are 32gigs! maybe i should look closer at them with pywallet perhaps
32 gigs??!?  Yeah, they're not likely to be wallet.dat files then... I've never seen a wallet file grow to more than a few megabytes at the most. Mind you, i've not really seen ANY files that are 32gigs in size except for cloned disk images etc. |
|
|
|
I am not sure what "quickformatted" means, but its name implies that references to all the files have been removed, and the allocation for disk space for your files has been removed. If this is true (or something close to true), you can use file recovery software to recover the wallet files.
If it's a Windows "Quick Format", then it means that the partition/file tables are reset, but the disk is neither "zeroed" (ie. all bits set to 0) nor is it scanned for bad sectors. Since Windows Vista, a "full" format (ie. the non quick format) option would actually zero the disk in addition to scanning for bad sectors. Obviously, zero writing a full disk can take a while, so most people tend to opt for "Quick Format" (unless they're purposely trying to remove all the data). refer: https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/format-command-not-write-zeros-to-diskThe upshot of this "quick format" behaviour is that the chances of data recovery are a lot higher if a "quick format" was done, as the underlying data is not immediately overwritten by the format procedure... it is only overwritten if new data is subsequently written to the disk in the sectors where the old data was stored. |
|
|
|
This whole situation is very confusing... Nothing that is happening here appears to be "normal"??!? I don't know of any sites that require that you create a multisig to deposit your coins, and therefore require that you sign your own withdrawal transactions?!?! NotATether, in fact I don't have the public btc key of the market, all I have from the market is the encrypted transaction (and signed by the market apparently) that he asks me to sign in turn and then I will get a new signed transaction (by the market and by me) that I must broadcast. The market tells me to do this on Coinb.in, by following the procedure below:
There should not be any need for you to sign anything to receive coins from the "market". You should be able to provide a bitcoin address and they should be able to create/sign/broadcast a transaction that sends coins to that address. Simple. So, it appears that this "market" is using some sort of very complicated wallet setup... Can you please explain the "cancelled transaction" that lead to the requirement for a "refund". Do you have an account on this "market" that has a wallet feature? ie. you login, and can generate deposit addresses etc? 1- I go to Coinb.in, menu "verify" (at the top); there I paste the encrypted transaction that they provided to me, then I click on "submit" ... There the decrypted transaction appears with the input address, the output address (one of my Electrum reception addresses), the amount of the transaction, 1 script for each input/output ...
It appears that they have created a partially signed transaction and given it to you... do you recognise the "input address" shown when you "verify" this transaction on Coinb.in? It *should* be somehow related to your account on the "market". NOTE: It will not have anything to do with your Electrum wallet or addresses. 2- I go to the "sign" menu: the market tells me "Paste here the transaction and your private key which belongs to the public key you used. Click on" Submit "to sign the transaction with your key";
I therefore paste the transaction then I will look for my private key on Electrum by right clicking on the reception address which I use for this transaction, This is where you are going wrong... you should NOT be using the private key for the "reception address"... it must be one of the private keys associated with the multisig address that is being used as the input. When you first setup your account on this Market, were you asked to enter a public key at all? |
|
|
|
I read somewhere on this forum to delete the content of the databases of Armory C:\users\stobor\appdata\roaming\armory\databases Which I did .... and then Armory started to work normally. Found all the bits and pieces of Bitcoin again However the ArmoryDB in the dos window is unchanged and stiill looking at a not existing path for the blocks as mentioned earlier https://pastebin.com/2VPVSyMp How to correct this? ArmoryDB in the dos window? Are you running ArmoryDB manually for some reason? It should automatically run as a hidden process in the background when you run the Armory GUI. In any case, it looks like it isn't getting the correct path to your Bitcoin blocks folder... which is odd, because your original Armorylog file ( https://pastebin.com/6dT3D7a4), showed that it was being set OK: 2020-11-11 13:09:20 (INFO) -- ArmoryQt.py:1872 - setSatoshiPaths
2020-11-11 13:09:20 (INFO) -- ArmoryQt.py:1891 - Setting satoshi datadir = M:\BTC\blocks
I would suggest that you shut everything down, then restart the PC to ensure that there are not any "ghost" ArmoryDB processes running in the background... then run Bitcoin Core (and let it fully sync), then start Armory. If you're still having issues, post your latest versions of the armory log files. |
|
|
|
I reset the Ledger using the 12 word option (do I need to do the 24 word option?)
Ledger devices usually use a 24 word seed mnemonic... why did you select 12 words? and where did these 12 words come from? or are you saying that you reset the device and just created 12 new words? The fact that you reset the device is a little disconcerting if you don't have the original 24 words that would have been generated when you setup your device when you first got it!!?! |
|
|
|
|
Show Posts
