I did find a webpage offering torrent downloads of the bitcoin database, but it was discontinued and only an old database was available. That could have solved the synchronization issue in a few hours...
Synchronization is NOT simply downloading the blocks... everything needs to be verified. Otherwise, the main tenet "Don't trust, verify" is broken. The large disk thrashing is likely your machine reading/writing chainstate info. You can also achieve a relatively good speed increase by moving the "chainstate" onto a high speed storage device like an SSD. Have a read of this: https://en.bitcoin.it/wiki/Splitting_the_data_directory |
|
|
|
...so my wallet and the blockchain are kept on an external 250Gb Samsung SSD. It is a while since I synchronised this, and I decided to bring it up to date.
Are you pruning? If not, you're on a bit of a fool's errand trying to sync everything to a 250Gb drive!!?!  Given that the current size of Blockchain on it's own is currently larger than that (nevermind the chainstate and other assorted data files), you're going to run out of room before it finishes syncing. |
|
|
|
Thanks. Could you share the .dll or I guess this is probably not recommended as required trust that it is not malicious?
Of course I can share it... http://www.mediafire.com/file/g51c9e0wt39axt3/libsecp256k1-0.dll/fileBut as you rightly point out, it does require that you trust that this file is not malicious. All I did was run the script from the Electrum github, which appears to clone the "secp256k1" git repository from Bitcoin Core and then compile it for your chosen platform. SCARY WARNING: For the record, I accept no responsibility if you choose to use this file. I have not extensively tested it... USE AT YOUR OWN RISK. |
|
|
|
Far too many people on DT these days with itchy trigger fingers  Simply voicing an opinion (albeit a fairly naive one), shouldn't result in a user getting tagged... red or otherwise. If they had continued to "shill" for SetupVPN by continually posting the same stuff regarding SetupVPN and actively promoting it etc after being educated that this particularly VPN service is not great, then I could probably understand a tag. But to come out swinging with a trust rating based on a single post, and a simple hunch that this is an alt account with absolutely zero proof is inappropriate in my opinion. I'm glad the rating was at least downgraded to a neutral... I still don't agree with the wording though. |
|
|
|
That "anomoly" is perfectly normal... I am however still a little confused as to the number of block files that your node has... a quick very non-scientific survey of other full node users indicates that other nodes seem to be around the same 1975ish "blk.dat" file count as my node. So, I'm wondering if there is some sort of weird issue with your Bitcoin Core install and/or data files that could be causing issues with ArmoryDB?  Which then leads to a "need to redownload the blockchain" solution If you have the time (and disk space)... perhaps you could try shutting down Bitcoin Core (and Armory), backing up your current "blocks" and "chainstate" dirs from the Bitcoin Core datadir and then deleting the contents of "blocks" and "chainstate" (once you've backed them up of course!) and then restarting Bitcoin Core and letting it sync from scratch. I'm honestly not sure what else to try at this point |
|
|
|
So from this rather small dataset... everyone seems to be within 1 or 2 blk files of my node. Which is sort of what I figured they would be. so the number between each synced node might be slightly different.
That's what I was expecting... but not 800 blk files different! Any one have any ideas why a node would be carrying 100gigs worth of extra data? |
|
|
|
Attempting to help a user having some issues with Armory wallet... Noticed in his debug logs that he has 2750+ blk/rev files in his Bitcoin Core "blocks" folder. I only have 1970+... That is to say, "blk01974.dat" I know that all nodes have "unique" blk/rev files so you can't interchange individual files (you have to swap ALL of them)... but is it "normal"™ that this user has nearly 800 more 130meg files than my node?!?? That's around 100 gigs of extra data! I'm trying to rule this out as the possible cause of the issues the user is having (wrong chain? ). So, if you are running a full node, can you please comment below what the highest numbered "blk".dat file that you currently have is. |
|
|
|
I see you got a response and closed the issue... but I can't see to make it work with the instructions given. I've posted on the github issue, but not sure if "closed" issues get notifications or not: I added in the .dll as specified and it still doesn't work, so I hacked some debug into the ecc_fast.py file (where it attempts to load the .dll) and I get this: E:\electrum-master>C:\Users\HCP\AppData\Local\Programs\Python\Python38\python.exe run_electrum
C:\Users\HCP\AppData\Local\Programs\Python\Python38\lib\site-packages\aiohttp\helpers.py:107: DeprecationWarning: "@coroutine" decorator is deprecated since Python 3.8, use "async def" instead
def noop(*args, **kwargs): # type: ignore
E | ecc_fast | LibPath: E:\electrum-master\electrum\libsecp256k1-0.dll
WARNING: [WinError 193] %1 is not a valid Win32 application
E | ecc_fast | LibPath: libsecp256k1-0.dll
WARNING: [WinError 193] %1 is not a valid Win32 application
E | ecc_fast | libsecp256k1 library failed to load
Error: Failed to load libsecp256k1.
E:\electrum-master>
So, I'm not sure the .dll is being created properly...
EDIT: Turns out I didn't have the correct compiler installed on the Ubuntu VM (that build-wine docker container that you use for generating the Windows installers has a lot of extra stuff I guess!) sudo apt-get install gcc-mingw-w64
Is required for the "GNU C compiler for MinGW-w64"... which is what is required to generate the 64bit Windows DLL. Once I had that installed, I used the: GCC_TRIPLET_HOST="x86_64-w64-mingw32" ./contrib/make_libsecp256k1.sh
and it generated the correct .dll I copied that over to the Windows box, putting it in my "inner electrum" directory... and then Electrum starts up from the Python sources just fine! |
|
|
|
|
This whole debate looks very much like the "Pro-Guns vs Anti-Guns" debate...
Guns have legitimate uses
Guns can be used for non-legitimate purposes
Trust Ratings have legitimate uses
Trust Ratings can be used for "non-legitimate" purposes
From where I sit, the issue is NOT the Trust Rating system... The real issue is the way some people are using it... People misuse/abuse things in life all the time, but it doesn't make the thing "bad" per se.
Are there not methods to deal with users who are misusing trust? That is to say, exclusions/DT 'voting' etc? Perhaps it is these methods of "checks and balances" that need to be examined and/or modified if they are not proving effective.
|
|
|
|
So I did some digging and yes, it is possible to extract the seed (and bruteforce the PIN) from the KeepKey... https://blog.kraken.com/post/3245/flaw-found-in-keepkey-crypto-hardware-wallet/https://blog.kraken.com/post/3248/flaw-found-in-keepkey-crypto-hardware-wallet-part-2/But like the Trezor... if you have a (strong) passphrase set, you should be "OK" Enable Your BIP39 Passphrase with the KeepKey Client
- This passphrase is a bit clunky to use in practice but is not stored on the device and therefore isn’t vulnerable to this attack.
I've not used a KeepKey, with it's "native UI" or Electrum... so I'm not sure exactly how "clunky" it is to use a passphrase with this device... with the Trezor ONE it's relatively simple... if somewhat vulnerable to keylogging. Any KeepKey owners can comment? Do you put it in with the device or via the computer keyboard like Trezor One? |
|
|
|
I don't see any technically reason as to why you can't search through addresses generated by an HD wallet looking for a desired vanity address and/or "sequence". However, given how many addresses one generally needs to generate to find desired vanity addresses, you'll probably find that your derivation paths for the individual addresses will have outrageous gaps in them: For instance: bc1qxx1xxx m/44'/0'/0'/435433 bc1qxx2xxx m/44'/0'/0'/357234931 etc etc... This would make restoring from the HD wallet seed ridiculously difficult unless you had some way to track the individual derivation paths. You might even find that the "next" address in the "sequence" was actually generated previously in a "lower" derivation path value... I doubt you'll ever find such a sequence where derivation paths are also in sequence (While I'd guess the probability of such a sequence existing is non-zero, I'd also guess it was very very very small  ) So, I'd think it would be less hassle (both in generating and restoring) to simply find the individual addresses you're after the "normal" way (eg. VanityGen)... and then import those individual private keys into the wallet of your choice. Convincing the wallet to use those addresses as your "change" address on the other hand... For most wallets, not an easy thing... But I know Bitcoin Core allows you to specify a "custom change address" if you have "coin control" enabled:  |
|
|
|
What's weird is 3.3.8 is launching directly through Python 3.8 and the "Video Device" in the Preferences is blank.
It's not that weird... that "video device" is for webcams and such for scanning QR Codes... it's nothing to do with your display adapter  Also, you might want to check your Windows Updates and see what updates, if any, were installed recently (about the time you changed the display adapter/driver). It sounds like a Windows Update has broken something. Possibly something is interfering with the libraries used in "pre-compiled" binaries, but the raw python is unaffected. Also, have you checked the Event Viewer for any logs? |
|
|
|
I assume that the KeepKey, being based on the same hardware as Trezor, suffers from the same security vulnerability as the Trezor devices (voltage glitching to extract seed)? |
|
|
|
What wallet did you create the 12 word seed mnemonic in? web based wallet Not quite the information I had hoped for. Can you be more specific about which web wallet you used? Was it blockchain.info/com or something else? If you can't (or don't want to) tell which website it is, perhaps you can browse the help and/or support sections of the website and see if they have any info regarding how to "recover" the wallet and/or use the 12 word backup. If you see mention of BIP39 (or possibly BIP32 or BIP44), then odds are good you will be able to restore your wallet in some of the more common wallets (Electrum, Mycelium, Coinomi, Exodus etc)... Or maybe you could even contact the website support and ask them. |
|
|
|
How strange... I don't have another node to compare with, so I can't say for certain if it is a problem or not... but I wouldn't think that was likely to be an issue. It'll just be the amount of info the node is storing in block files... do you have transaction indexing turned on perchance? Did you get a chance to restart everything? Is the DB working OK? also... you should also see new blocks showing in armorylog.txt if it's working OK 2020-02-19 17:31:33 (INFO) -- ArmoryQt.py:4959 - New Block! : 618033
2020-02-19 17:31:33 (INFO) -- ArmoryQt.py:4967 - Current block number: 618033
2020-02-19 17:32:31 (INFO) -- ArmoryQt.py:4959 - New Block! : 618034
2020-02-19 17:32:31 (INFO) -- ArmoryQt.py:4967 - Current block number: 618034
2020-02-19 17:41:53 (INFO) -- ArmoryQt.py:4959 - New Block! : 618035
2020-02-19 17:41:53 (INFO) -- ArmoryQt.py:4967 - Current block number: 618035 But that will only happen once all the initial scanning has finished. |
|
|
|
In Armory-Qt terms: "dbdir" is where Armory will put it's custom databases "datadir" is where Armory will look for/store settings and .conf files etc. Have you read the Armory "pathing" documentation? It explains it all a lot better than I can. As for the timeout, it's not a "deliberate" thing... more just the DB process "dies" silently Theoretically, if Bitcoin Core is running and syncing and ArmoryDB is working "properly", it should reflect in dbLog.txt when new blocks arrive and are then processed by ArmoryDB... ...
-INFO - 16:38:42.031: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #571130
-INFO - 16:45:32.437: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #571131
-INFO - 16:47:40.703: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #571132
-INFO - 16:49:42.094: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #571133
...
|
|
|
|
|
Person A agrees to sell Person B a widget for X BTC.
Person A then takes 3 weeks to ship the widget because "reasons"
Widget arrives damaged
Person B wants a refund/compensation.
Person A says no and points to their "shipped at buyers risk" clause on their listing.
Given this somewhat simple scenario, should Person B create:
Flag? Type 1, 2 or 3?
Trust Rating? Positive, Neutral or Negative?
Both?
I'm fairly confident, that in spite of your conviction that the answer to this could be clearly set by a few "objective" standards... different users would have different opinions and valid reasoning for using every single of those options if they were Person B.
The "inviolable truth" is that trust is subjective. That much is clearly evidenced by looking at the way the trust system is currently being used. Some users think people who buy/sell accounts are not trustworthy. Some do not. Some users think that people who enrol multiple accounts in the same campaigns are not trustworthy. Some do not. Some users think that people who like lemons are not trustworthy. Some do not. Some users think that the trust system should be used exclusively for "trading". Some do not.
If trust wasn't subjective, then everyone would think/act the same way and everyone would agree on all of this... and they clearly do not agree. Hence the large amount of conflict and disagreements. Sadly, it's just the way humans* are. ¯\_(ツ)_/¯
I admire your tenacity in attempting to "fix" the system according to your beliefs/ideas... but did it ever occur to you, that not everyone shares the same belief system as you? You may not agree with someone else's opinion, but they are still entitled to it... and currently, they're also entitled to express those opinions via the trust system.
* and cats, foxes, robots, attack helicopters and whatever else people want to identify as
|
|
|
|
A mnemonic is simply a way to encode a large number into a more "human readable" form. This helps prevent transcription errors when writing it down for backup purposes etc. The large number being encoded is generally used as a "seed" from which private keys are then generated in a deterministic fashion. With 12 words, we can encode a 128 bit (+4bit checksum) number... 24 words = 256bits (+8bit checksum). I'm not terribly familiar with the underlying workings of ETH, so I'm not sure if there is a key that exists for 0x0 address... if there isn't a valid key, then no mnemonic would give you the seed that would generate it (as the key doesn't exist!). If say one person magically finds the mnemonic for 0x0, if they increase the wallet path will that give them access to 0x0000000000000000000000000000000000000001?
That's not how the derivation of addresses from a seed works. It doesn't create addresses in a logical "sequence order" like that... if you did actually have a mnemonic that generated 0x0, the next address is most likely going to be nowhere near that in terms of "numbering". In any case, 0x0 might not even be the first address derived from your mnemonic/seed... it could be the 10th... or the 100th... or the 143498543957036534th |
|
|
|
Nothing looks obviously wrong with those logs... My guess is that it is just the ArmoryDB process taking so long to do the initial sync that it times out and stops responding? Although, having said that, one thing that looked out of place to me: -INFO - 15:15:08.672: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2748
#2748 seems like a large number of block files... currently, my Bitcoin Core node only has #1971 (each file is around 130megs) If you look in your "F:\BitCoin\Blocks" folder... what is the highest numbered file? should be named something like: "blk0xxxx.dat" Anyway, I'd recommend NOT doing rescans and such if possible. As that will just make it sit for hours rescanning all the blocks again. At this point, I'd recommend that you simply shut everything down and restart the PC (to ensure any zombie processes are killed). Once you've restarted, then run Bitcoin Core and wait until it is fully synced, then start Armory. |
|
|
|
|
Show Posts
