You cannot make a multisig wallet from the same seeds and still call it multisig. I think the OP already has 3 different seeds... When they said: Is it possible to create multiple 2of3 mutlisig adresses from the same three BIP39 seeds?
I think they mean they have: BIP39Seed1 BIP39Seed2 BIP39Seed3 And want to know if they can create multiple multisigs from those 3 seeds... as has already been stated, if you create a MultiSig using Electrum, it will create a MultiSig "HD" wallet which generates unlimited multisig addresses. I don't think it stops you from creating a wallet using the same seed for all co-signers though.
It actually does:  You cannot use a seed (or master public key) more than once when trying to create a multisig in Electrum... it'll definitely reject it. |
|
|
|
It's possible that you're importing the private as the wrong "script type"... Does the BTC address that you used from Electrum start with a "1", a "3" or "bc1"?  After you import the private key to Electron Cash, what does the address start with? |
|
|
|
|
As I said, the latest "runs" are showing that Armory is not spawning ArmoryDB... there is most likely a zombie "ArmoryDB" process that is stopping things from working correctly.
So you need to either:
- Shut down Armory... kill zombie process with Task Manager... restart Armory
or
- Shut down computer, reboot... start Armory
|
|
|
|
... is there a way to be sure the wallet files have not been corrupted?
... is there the possibility that hascat (or other recovery scripts) is not able to open the wallet even if they find the correct password? hashcat doesn't open the wallet... all it does is "hash" password combinations and compare to the "hash" you already have. If it finds a match, it tells you. Depending on how corrupt the file is, you'll either get incorrect password or invalid file messages. I know my Python multibit recovery scripts will often know if the password on a "corrupt" .key file is incorrect... but if the correct password is supplied it will spit out garbage data instead of the private keys etc... This is because the .key files are just encrypted "text" files. I've tested this by overwriting a few random characters of an encrypted ".key" files and then running the script. .wallet file corruption is a bit different... the file format is a lot more sensitive to corruption as it is a "protobuf" binary file... so any corruption will generally mean that it is not able to be deserialised properly and the script will just crash with a "not a wallet file"-type error. Same with the .wallet.cipher files... it'll generally know if the password to the file encryption is "OK", but then because the "protobuf" is damaged, it'll crash the script. |
|
|
|
The new update didn't make it worse. It always has been like this.  I should have known... honestly, I originally had high hopes for Ledger Live when it was first announced they were removing the Chrome apps and releasing "proper" apps... LL is far from "proper"   |
|
|
|
Here is my latest log file , maybe this helps to find the error. I anonymized some information for privacy reasons.
What seems strange is that it doesn't seem like Armory is spawning ArmoryDB??!? There isn't any line that says: something like: 2019-08-13 08:10:13 (WARNING) -- SDM.pyc:402 - Spawning DB with command: C:\Program Files (x86)\Armory\ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="E:\Bitcoin\blocks" --satoshi-port=8333 --datadir="C:\Users\xxx\AppData\Roaming\Armory\" --dbdir="C:\Users\xxx\AppData\Roaming\Armory\databases"
So, it's possible there is a "zombie" ArmoryDB process running in the background which is screwing things up. Shutdown Armory... then use the Windows Task Manager to kill any "Armory" or "ArmoryDB" tasks that you can find (right click on task in Task Manager -> End task). Alternatively, shut everything down and then restart your computer, that will 100% guarantee that any zombie processes are killed  Then, try running Bitcoin Core+Armory again... if it is still hanging... you'll need to post the contents of your dbLog.txt, as I suspect that it is ArmoryDB that is having issues. |
|
|
|
The only things I can think of that would cause this are: 1. Corrupt data on disk... the easiest (but "longest") fix is to simply delete all the bitcoin core block data and start syncing from scratch again. 2. Out of hard disk space... Bitcoin Core will simply stop syncing if it runs out of harddrive space. 3. Some sort of hardware issue causing data corruption. So, do you actually have enough free space on the disk for the blockchain? It's well over 350+gigs on total storage now... What do you see at the end of the debug.log file when Bitcoin Core stops syncing? Any obvious errors? It would be helpful if you posted the last couple of hundred of lines from debug.log (use pastebin.com to avoid post length limits) |
|
|
|
Yes, it is. You might be right here, so probably as soon as the transaction is confirmed it will stay there.
Basically, I grouped about 30 inputs to 1 watch only output, used 1.5 sat per byte.
It's quite possible the transaction kept getting dropped, then re-added etc... As another user pointed out in another thread... the "mempoolminfee" got bumped up over 2+ sats/byte on several occasions this last week: https://statoshi.info/dashboard/db/memory-pool?from=1609918343354&to=1610523143354 |
|
|
|
It would appear that with the very large number of unconfirmed transactions over the last few days, that the "mempoolminfee" code got triggered... Note that the error you had in Electrum explicitly mentioned "mempool min fee"... and not the usual "min relay fee" etc:  |
|
|
|
|
it's not "sensitive data" insofar that nobody can steal the coins with only the xpubs... but it's sensitive from a "privacy" point of view as anyone with all the xpubs can effectively create a watching-only wallet of your multisig and see all your addresses, transaction history and balances etc.
Each signer, should provide each other signer with their xpub. So each signer should have:
- Their own private seed
- 2xCosigner1 XPub's
So, SignerA will have:
- SeedA
- XPubB
- XPubC
SignerB will have:
- XPubA
- SeedB
- XPubC
and SignerC will have:
- XPubA
- XPubB
- SeedC
|
|
|
|
thanks for posting back, im thinking that i may have pressed export in my default wallet to send them into my wallet-1 which is watching only, because i never even knew that i had a watching only account untill the money had been sent into there.. theres no seed on the watching only, only option i have is to sweep private keys or it says import addresses. is still very confusing to me what to do as it has been stressing me out for atleast a week now What happens if you use the "File -> Open" menu option in Electrum? How many files do you see in the "Wallets" folder? Do you see a "default_wallet" file? If you see a "default_wallet" file, then it would seem that your Electrum is set to open the "wallet_1" wallet on start up (it defaults to opening the last wallet file that you had open)... what happens if you select "default_wallet" and open that? Do you see the same address/funds that you see in "wallet_1"? |
|
|
|
I generally like the idea of activating segwit. Does anything considerably speak against it?
You don't "activate" Segwit... you either use Segwit addresses, or you don't. What about the claiming of BCH and BSV. Anything I have to pay special attention to? How do I split those coins?
To prevent "replay" issues with BCH and BSV, you need to get some small "split" BCH amount from somewhere (easiest way is to purchase some from an exchange)... and you send that BCH to your BCH address... then send the entire amount to a completely new wallet. This way, the transaction cannot possibly be "replayed" on the BSV network, as the small amount from the exchange purchase will not exist on the BSV network (the exchanges will be using already split coins). Once you have confirmed that the "old coins+new coins" transaction on BCH is not showing on your BSV wallet (your coins will be successfully "split"), you'll be able to then send the BSV to a completely new BSV wallet. |
|
|
|
Note: It would be very helpful to see the dbLog.txt file as well as the armorylog.txt file. Do you have Bitcoin Core setup to store the blockchain in a "non-standard" location? If you did, you need to configure Armory to use the same. What is the "datadir" shown as in Bitcoin Core when you use the "Window -> Information" dialog in the GUI? |
|
|
|
When I try to send the bitcoin from Electrum to Coinbase, it is giving me a "Warning: The fee for this transaction seems unusually high. (25.63% of amount)
In Electrum, if you click the "advanced" button after you click "pay"... how many inputs do you see listed? And what is the "Size" listed at the top in "bytes"? |
|
|
|
If it was a MultiBit HD wallet, then the 12 word phrase would not have been recognised by Electrum as the "OLD" keystore type... This means it was an Electrum 12 word phrase and the old Electrum 12 word phrases did not utilise the BIP39 wordlist that MultiBit HD used. They used the list in my previous message. and second wallet showed information
wallet type - standard
script type - P2PKH
seed available-TRUE
keystore type - OLD
lightning - Not available for this wallet
|
|
|
|
"confirmations": 0,
The UTXO you're looking at is from an unconfirmed transaction then? What is the "fee rate" that it was sent with? Perhaps your node is dropping the unconfirmed transaction out of it's mempool due to the fact that there are some 125meg+ worth of unconfirmed transactions at the moment. |
|
|
|
BIP38 ("Passphrase-protected private key") utilises "Scrypt"... which is notoriously "slow" when it comes to attempting to bruteforce it. It was chosen for this very reason  As you can see from the stats on this BIP38 bruteforce tool... it took 337.219 seconds to check 500 passwords! at a speed of roughly 1 passphrase per 0.675 seconds  This bruteforce tool was running at around 0.6s/passphrase during the run in this video. As the video presenter points out "it is not a very fast bruteforcer"... There is also this one: https://github.com/cculianu/brute38 (no idea on the speed) |
|
|
|
I purchased some btc in 2013 and stored them in a multibit wallet. I've since tried to import the wallet to Electrum, but it's a watching-only wallet. I can see the original transactions, however I can't do anything with them. So I'm led to believe the key I have is just the wallet address?
Correct. If you have created a "watching-only" wallet in Electrum, then what you entered was your wallet address... and not the private key. I don't have the seed, and I can't find any files on my old machine relating to wallet.dat etc.
Multibit "Classic" never used seeds. It only generated random private keys. MultiBit "HD" did use seeds. Are they lost, or can they be redeemed through other means?
You will need one of the following: - The private keys - The 12/24 word seed phrase (for HD wallets) - The wallet file (and any wallet file password) Without at least one of those, you will not be able to recover your coins. File types for MultiBit that can be useful to recover private keys or seeds: [walletname].wallet [walletname].wallet.cipher [walletname].key mbhd.wallet.aes |
|
|
|
Is there any log for bitcoin core?
Look for the debug.log file in your ~/.bitcoin directory (as achow101 mentioned, it should be in the same location as where you put your bitcoin.conf file) Also, you'll probably find the contents of this log file are way too long for the character limit for a post here. I'd recommend using a service like https://pastebin.com/ You just need to copy/paste the contents of debug.log to pastebin, then click the "create new paste" button, this will generate a unique URL that you can post here without worrying about character limits for posts |
|
|
|
|
Show Posts
