On Reddit there is a lot of talk about public keys being easily crackable in the near future due to the advancement of Quantum computing.
Many wallets such as Electrum use Deterministic keys, so one seed can create hundreds of addresses and if you know the private key of 1 address you can easily derive the private keys of the addresses remaining in the wallet.
So lets say some individual with 1000 BTC in their wallet, never reuses the same address, each transaction change goes to a brand new change address. However since the keys are deterministic can't someone find the private key of the unspend address since they can easily follow the trail and crack the public key of a spent transaction and use that to find all the wallets BTC address and change addresses?
No, that is not how HD wallets work. The private keys are not derived in a chain one after the other. They are all derived from a master private key. It is a tree structure, not a linked list. This means that if the master private key is discovered, then all of the private keys in the wallet are known. However if only 1 child private key is known, then no other private keys can be derived. The only caveat to that is if non-hardened derivation were used and the master public key were known then the master private key can be derived and from there the rest of the child private keys. This does not require any sort of quantum computing at all either. |
|
|
|
I read that drivel. I assumed since they are signaling for 2x that this was the usual empty threat. Are they doubling down on this garbage?
I have no idea. I just wanted to point out that there are many more forking possibilities at the end of July/beginning of August. |
|
|
|
Part of Segwit2x is BIP 91. BIP 91 specifies that once it activates (requires 80% signalling on Bit 4 for a period of 336 blocks), all blocks must signal for segwit on Bit 1 so that segwit activates via the current BIP 141 deployment.
Clowns... why even bother? There's also Bitmain's UAHF too. That means that there are now a large number of possible chain forks. |
|
|
|
I can't send Bitcoins with Electrum, because it won't recognise the other address as valid, while i know for certain it is.
Are you sure that the address is valid? Are you absolutely sure that you are entering it in correctly? If you enter the address on a block explorer, does it give you an error or give you a page with info about the address? I heard this could be the case, because i still use an old address, that starts with 1. Could this be the case? If it is, what can i do now?
No, those addresses are not old and are still used. That is not your problem. |
|
|
|
As for how this mess will unfold, I haven't really paid attention to it. If the SegWit2x side is actually signaling BIP9 SW activation, then neither BIP148 nor 0.13.1+ Core nodes will fork off come August first. They will fork later when the SW2x side tries to HF the block size however, whenever that is.
Part of Segwit2x is BIP 91. BIP 91 specifies that once it activates (requires 80% signalling on Bit 4 for a period of 336 blocks), all blocks must signal for segwit on Bit 1 so that segwit activates via the current BIP 141 deployment. Then later they will fork to 8 MB block weight (2 MB legacy block size) after block 485218. Of course this can all only be found out by looking at their code and pull requests as they have no documentation to speak of, AFAIK. Serious off-topic question: Post chain-split, if I send coins to myself and the transaction is relayed to all chains, then it is very likely that the transactions will confirm in different block numbers on the different chains. Will that be enough to split the coins so they can be disentangled?
No. The only way to avoid replay to have the transaction ids that create your outputs to be different. Transactions that confirm on both chains, regardless of block height, will still have the same txid and thus are still vulnerable to transaction replay. |
|
|
|
Perhaps itr might be better if I uninstall everything I have done so far and start over,
I have other wallet.dat files which I need to get keys from so this route would be the best option
This is a guide you published in Dec 2015, please can you review it and add any changes?
Sure. Go to https://www.python.org/downloads/ and download python 2.7.11. Run the installer and it will install python. Make sure that when you get to the "Customize features" screen you scroll down and click the dropdown next to "Add python.exe to path" Select "Will be installed on local hard drive" then you can continue. Then download this file: https://github.com/downloads/jackjack-jj/pywallet/PWI_0.0.3.exe (just click the link) Run the program and have it extract to whatever folder you want. Follow the wizard. Once it finishes, go to that folder. If you do not see a file named pywallet.py, double click the file named install.bat. A command prompt will appear briefly and then disappear. Once it is gone, you should now see the pywallet.py file. In the folder where pywallet.py is located, make sure that nothing is selected. Then do Shift + Right Click and in the menu that pops up select "Open command window here". In the window that pops up, type pywallet.py --dumpwallet > wallet.txt This command will dump everything from the wallet to a file in the same folder called wallet.txt. If you have a passphrase on the wallet, add the option --passphrase <passphrase> to the command after pywallet.py and --dumpwallet. Make sure there are spaces between them all. If the directory where your wallet is located is not the Bitcoin default, then you will also need the --datadir=<path to directory> option also added in in the same manner as the passphrase. |
|
|
|
Hi achow101,
my re-indexing went fine until about a year of blocks left. The "fatal error..." message stated popping up and the client shuts down. Here is the log from the debug:
Corruption: block checksum mismatch
2017-06-23 01:03:39 *** System error while flushing: Database corrupted
2017-06-23 01:31:39 Failed to connect best blockFailed to open mempool file from disk. Continuing anyway.
This usually means that you have a corrupted block on disk. The only way to fix that would be to delete the entire blockchain and let it fully sync from scratch. |
|
|
|
|
What is "it"? Did whatever you fork have gitian properly setup? If you changed anything, did you also change the gitian descriptors as well? If not, then gitian will not work.
|
|
|
|
I did that, now the ArmoryDB.exe started again and showing these command lines:
<../DatabaseBuilder.cpp:268> parsed block file #38
<../DatabaseBuilder.cpp:268> parsed block file #40
<../DatabaseBuilder.cpp:268> parsed block file #42
and so on..
It stopped at
<../DatabaseBuilder.cpp:268> parsed block file #48
That's supposed to happen, but it should continue with some other stuff and with more block files. Is Bitcoin Core running? Is it synced? What does ArmoryQt show? Just to get it right: If I use an RaPi as a coldwallet to sign tx, that are made with a watch-only hot-wallet on my online pc, just the online-version has to be up-to-date, right? The RaPi can stay 0.93 forever, correct? I guess i cant use the advantages of segwit transactions then, but thats not so important for long-term holdings.
So long as the unsigned transaction format does not change and you don't use any of the new script types and signing requirements don't change, then yes, that is fine. |
|
|
|
Thanks for your reply, I still don't understand the problem though. The array consists of 80 bytes all being of value 0x00. This should be the same regardless of byte order, shouldn't it?
EDIT: I don't know really why, but I tested the byte order just to be sure... as expected it doesn't make a difference for the byte array in question.
It has nothing to do with what you initialized the array with nor with anything that you passed into the function. The endianness has to do with the output of the hash function. The output is different because Bitcoin uses little endian byte order for basically everything, so the output of the hash function will be in little endian byte order. However most other SHA256 implementations will output in big endian byte order so you will need to reverse the hash from other implementations in order to get the little endian byte order that Bitcoin uses. |
|
|
|
|
The hashes that Bitcoin uses are double SHA256 hashes. The hashes are also usually in Little Endian byte order. So your second attempt with the double hash is actually correct, but with the wrong byte order. You need to byte swap your result to be in the right ordering.
|
|
|
|
Spent most of the afternoon trying to research then follow JJ's pywallet approach which you suggested. I found one of your very detailed and step by step posts on how to go about the whole dl process and thought... hey... even I can do this. but as I confidently opened up cmd and typed in ez_setup.py I was met with: 'ez_setup.py is not recognized as an internal or external command, operable program or batch file.' uninstalled everything and started again, making double sure I followed your instructions and downloaded the correct files but same again.
You need to install python 2 and when you install it, make sure that it is added to the path (I think there is an option for that in the installer). Then when you want to run any of the python scripts, you need to do |
|
|
|
|
IIRC the IP to IP transaction system would have you enter an IP address and then your node would send a message to that IP address asking it for a public key. The node at that IP address would then send back to your node the public key. Then that public key is used to create a Pay-To-Public-Key output in a transaction. The transactions themselves are the same transactions that we are familiar with today, just that instead of the receiver telling you an address, the nodes would do it themselves. This obviously has some privacy implications and likely some vulnerabilities so it was removed.
|
|
|
|
Segwit2x is basically segwit but blocksize will be 2MB, whereas normal segwit you could turn it from 1 to 4MB ?
No. Segwit2x is segwit but makes the base block size (which is completely irrelevant thing anyways) 2 MB. This means that the theoretical maximum block size will be 8 MB. The block weight (which is the actual thing that matters for consensus rules) will be 8000000 (8 MB). Why does Segwit2x only need 80% minerpower whereas Segwit needs 95% ?
Because that is the percentage of the hashrate that the creators of segwit2x were able to convince to agree to deploy segwit2x. Segwit is 95% because it is following the BIP 9 deployment specifications which recommends 95%. Since it is a consensus rule change, we want have a percentage of hashrate supporting the change as close to consensus as possible (consensus being 100%) to avoid chain splitting. |
|
|
|
|
The wallet files themselves and the paper backups should all be compatible with the latest Armory software.
|
|
|
|
How can I fix the DB error?
What is the error? Can you post the dbLog.txt file? I do not know where to find dbLog.txt But a command window opens, directory: C:/Program Files /Armory/ArmoryDB.exe It says in the last line: ERROR - <../lmdb_wrapper.cpp:433> DB version mismatch. Use another dbdir! That error is standard when upgrading from Armory 0.93.3 to anything more recent. Go to the Armory data directory (default on Windows is C:/Users/<your username>/AppData/Roaming/Armory). In that folder there should be a folder named databases. Either delete it or rename it. Then start Armory. |
|
|
|
Are you sure that you are synced? What block height does Armory report in the bottom righthand corner of the window?
Connected (60750 blocks) You are nowhere near synced. The blockchain currently has 472327 blocks. |
|
|
|
How can I fix the DB error?
What is the error? Can you post the dbLog.txt file? |
|
|
|
|
Are you sure that you are synced? What block height does Armory report in the bottom righthand corner of the window?
|
|
|
|
|
You will not be able to use 0.93.3 on with segwit2x. Segwit2x is a hard fork and the clients that support it will be introducing things that are incompatible with Armory 0.93.3, namely segwit. If you want to use Armory after segwit2x activates (or on the segwit2x chain if there is a chain split), you will need to upgrade to at least Armory 0.95.1.
|
|
|
|
|
Show Posts
