I usually dont bother when I get errors like this: You have to turn on javascript and cookies support in browser to visit this site.
Для посещения этого сайта необходима поддержка javacript и cookies Вашим браузером
ddos-guard.net
|
|
|
|
|
There are a few cases where you need to redownload all data, yes. They are not common though. If you want to be prepared, make regular backups of the entire folder. A bootstrap.dat would not be verified, copied the folder includes all verified data (and your wallet.dat).
|
|
|
|
-snip-
Ach ja, betreffend Speed bin ich mit 1Gbit/s synchron angeschlossen. Das was so lange dauert, ist (meines Wissens) das Verifizieren aller Transaktionen innerhalb der Blcke? (Bitte korrigiert mich, wenn ich das falsch sehe).
-snip-
Yop, bei den kleinen Kisten ist die CPU die Bremse. Kann man aber ggf. auf nem "richtigen" Rechner verifizieren und dann kopieren. |
|
|
|
Understood, wow, that's quite demanding, particularly for people running wallets on mobile devices. How do applications like Breadwallet manage to deal with all this data on an iPhone, for example?
They dont, breadwallet is not a full node. Most wallets are not, they rely on others running full nodes to get the data they need. I dont know exactly how breadwallet works, but common ways are either special servers (e.g. Electrum) that run a full node or directly query full nodes for data (e.g. multibit). |
|
|
|
Danke fr die Erklrung, jetzt werd ich mir auch mal einen Node aufbauen und schau mal was ich am besten fr eine Hardware nehme...
Mein jetziger Server ist zu "klein", also mehr als 1 CPU Kern, 2 GB RAM und 100GB SSD/HDD sollten es schon sein. Fr den Hausgebrauch tut es vermutlich ein alter 2 Kern Laptop mit 4 GB RAM und ner ausreichend groen Festplatte. Mit der nchsten Version von core (0.12) sollen ein paar Optionen kommen um den Bedarf an Arbeitsspeicher beschrnken zu knnen, kann also durchaus sein das 2GB RAM reichen. |
|
|
|
Hi All, I'm running the 0.11.2 Bitcoin core distribution on MacOS, compiled from source.
For a while I had txindex=1 in the configuration file to learn more about the protocol and stuff. Yesterday I removed that, deleted the _blocks_ directory and restarted the daemon with -reindex, expecting _blocks_ to be recreated to be much smaller than the previous >60 Gb, thanks to ignoring all parts of the blockchains that aren't relevant to my wallet. This morning the process has finished and it still is >60 Gb! Am I doing something wrong?
Thanks,
G.
No, currently the blockchain is that big. txindex=1 will increase the size of the database your wallet keeps track of, not the size of the blocks the data in said database is based on. If you dont run a wallet you can reduce the size with prune=. If you use the node as a wallet you have to wait for 0.12 to run a pruned wallet. |
|
|
|
Thanks for correcting me! I guess if I took even a few seconds to research I would have come across this  What you had in mind is 1MiB[1] not 1MB. Sadly its common to use 1MB for both, which means almost anyone is confused with what 1MB actually means (1million bytes or 1024 2 bytes) [1] https://en.wikipedia.org/wiki/Mebibyte |
|
|
|
Das "high priority" von blockchain.info heit auch nicht wirklich was. Fee ist aber ok, sollte maximal n paar Stunden dauern. Ich hab die TX mal angeschoben, wenn jmd. mitschubsen will:
-tx-
Wie meinst du das, ich hab da angeschoben ? Ich hab die TX ber meinen Node nochmal ins Netzwerk geschickt. Da Tobisus schrieb Netzwerk Ausbreitung 0% (Sehr schlecht) kann das helfen. Die TX kann nur besttigt werden wenn sie ein Miner bekommen hat. Die "vergessen" aber gerne mal TX die zu lange unbesttigt sind. Bei anderen Knoten im Netzwerk ist das hnlich. Da kann es dann helfen einfach nochmal alle dran zu erinnern, dass es noch was zu besttigen gibt. Bitcoin core macht das z.B. bei eigenen, ausgehenden TX automatisch alle 30 Minuten. Fr schwere Flle (also sehr geringe Gebhren oder andere Probleme) mach ich das dann oft auch fr andere mit nem kleinen script/cronjob. Wer keinen Netzwerkknoten betreibt kann ber diverse Interfaces[1] mithelfen. Es reicht aber nicht die TX-ID, sondern man braucht die "rohe" Transaktion. Die findet man z. B. bei blockchain.info indem man hinten an die URL der TX ?format=hex hngt. Also z.B. -> https://blockchain.info/de/tx/86d317b25f1f55e8e23c6587d8e8fcb92d838a8aa90237ac0425b774013cbd05-> https://blockchain.info/de/tx/86d317b25f1f55e8e23c6587d8e8fcb92d838a8aa90237ac0425b774013cbd05?format=hex[1] https://en.bitcoin.it/wiki/Transaction_broadcasting |
|
|
|
-snip-
If a third party knows several addresses from the same electrum wallet, can he associate them with eachother, meaning that can he prove it that those addresses belong to the same wallet , without knowing the master pub key of course?
So if they know A , B ,C addresses that are in the same wallet, can he prove that A B C are derived from the same master public key without knowing the master pub key?
Maybe, if the addresses are spend linked, yes. If not, not. Spend linked means that you use coins you received on A, B and C to create a single transaction. E.g. this TX -> https://blockchain.info/tx/dfb7be5a382e2575e52c7c09289c5eb04f9acecb117c54ae0921ce014977cb90links 1ASFyXYMd7ffy5AFyoGnvQpc9dmxcN4438 to 1EQA6THR6wCgV8ZeuoZiVqEAMGb9S5sKJT This method is not perfect as we two could create a TX together to fool people (usually called "CoinJoin" or "SharedCoin"), but its commonly accepted as "proof" when finding connections between addresses, at least here in the forum.
Dont let anyone get your wallet file, which you should do anyway to avoid brute force attacks on your private keys.
Interesting but what if it's an electrum watch-only address. The watch only is derived from the pub key, however it doesnt contain the private key. So they can still obtain the pub key if you watch your money from a watch only wallet, and that can hurt your privacy. AFAIK a watch only wallet isnt protected by the password, so yes. A watch only wallet getting stolen would compromise your privacy, but not your coins. |
|
|
|
i can confirm received payment from Unitaco.com campaign. Payments are made through their website, and withdraw is without problems.
also this campaign now is closed for new participants
They received the payment but it was a bit late and that's why it is the asterisk, also PNYC has more priority rather than CFNP If they out again today, Im fine with moving them to CFNP. Payment of the 2nd period of unitaco has been sent to our unitaco account, juts withdrew it and received it instantly to my own address. So I think it is the right time to change it to CFNP  done -> http://pastebin.com/ihQDFmm6 |
|
|
|
Hallo liebes Forum.
Ich habe was die Einrichtung und Synchronisierung von bitcoin core angeht ein paar Probleme bzw. Fragen.
Ich verwende Bitcoin Core Version 0.11.2 unter Debian 8.3.
Zum Einen habe ich das Problem dass die Synchronisierung mittlerweile so langsam abluft, dass die eigentlich nicht stattfindet. Angezeigt wird mir dass ich 1 Jahr und 31 Wochen im Rckstand sei, und seit diesem Fortschritt beschrnkt sich die Geschwindigkeit des Downloads auf zwischen 10 kiB/s und maximal 80 kiB/s. Dieser Zustand ist seit 21 Stunden unverndert.
Wie ist die CPU bzw. Festplatten Auslastung? Zum Anderen stellt sich mir folgende Frage: Selbst wenn dieser Download nur mit 10 kiB/s weiterluft, irgend wann wird er auch dann fertiggestellt sein. Was aber tun, wenn ich nun beispielsweise mein System neu aufsetze, oder Bitcoin Core auch auf einem anderen PC nutzen will..? Muss ich dann jedes mal diesen, doch recht unkomfortablen, Akt ber mich ergehen lassen, oder gibt es eine Mglichkeit die heruntergeladenen Dateien zu exportieren und diese dann in einer neuen Umgebung wieder zu importieren?
Mit freundlichem Gru,
melissengeist (=
Die Daten sind (per default) in ~/.bitcoin gespeichert. Du kannst bei einem Umzug den Ordner (ca. 60GB zur Zeit) einfach vollstndig kopieren und ihn danach wieder an der selben Stelle einfgen. Das wichtigste dabei ist wohl die Datei in der deine privaten Schlssel sind die wallet.dat und der blocks Ordner in dem die runtergeladenen Blcke gespeichert sind. Alles kopieren schadet aber auch nicht. |
|
|
|
Das "high priority" von blockchain.info heit auch nicht wirklich was. Fee ist aber ok, sollte maximal n paar Stunden dauern. Ich hab die TX mal angeschoben, wenn jmd. mitschubsen will: 010000000674ae422e145e51af823c075e9d714d390e3bc291094fd5d1e0dba27834e1abf5000000006b483045022100d6fa72431ab31c899fabafd9871fed643522133283418916339a7cf465c0360c022011bea468668d5c5e4b9bcb2f794c00fd8ec83ba01e84fb21c715336d3953b37f0121033ac38458c6f9eb24b9798c40808a48023e872b5bcd77fe42d3ec2fccba2fb8a7feffffffe6ad7aceee8aa13d3123c2c711c61b2c3d2960e2d95028dc448c60de1db86f06000000006a47304402207dcb09e7292a17944660b5745441706269e127467a34d8cb3f640f3c4d6f695e02200a37a9b573aab9e35634dea149e1d60cabc2527f26e6614319c1182b47349bd501210322c423b655ec23aca2e28d0de4dca23c7f1ab9e5103ac0921cd83e61544ae9fffeffffff5c3c3a769b57257552ef4873be7a0099d1c1e34013f8486ab230c3c2980d8df3010000006b483045022100c21f1ac99a80cf26a3a7fbb6acd0797893b50d00d3840a1167ff6527b019fd9102205f6c47af67e8d01fb5f9ce4cd0877567b53d46a51ce03258511c4fc6194ff4dc012102481c96c73408bc7642c918ee4ba02ad815a54fc4ac3c5e53d88ec6b4acf31a03feffffff6f1107caccd5586bef49a8b3eb4c5500dced59ef29fdc2e549b2e024a752e598100000006b483045022100cb817ad0d402218429bf2efb546f7ec19113d5fe5947adf485290c544792b530022038368170c263725bcef75349483a071be0edd12624e8617a446b9a8793ccaa62012102bf958bfef7dbdf66206ed04cf08c0c0248127a8392a1805338f51388e79da0eefefffffffa60455e7cfaa980fa43d131f7156e3702f1f85d885926fcae48d398e59927fe010000006a4730440220307ac4717a2b4fbfde9b9aa6a8067299eb2102c58d711a2abee73d4d654d14800220287d6bd9e32876664e745c53a3bf4ab176bf84cd23c6395f1791482295d493c401210359d6414dbcb5f00cb69e9bace65e6f7dc9fa08bcf523bc4aba89bf2522a8610afeffffff9a70398d41903c85ba98559944227175d8e374c9ac0e4fa35129a34c25c31ef1000000006a47304402206b634ec04f1ebf8875c2b4ece182d2556786a2069a85fb20155aedd408fef62302200fb37521d3e98327567871fb0a0f0ec03076ff7a0e14312a0f3310d1cba9ce380121033e5cf2763e81b8dab5328ed0310c8444e01b88c9caf89fd65f1d7ade931a1a9ffeffffff02b002cd02000000001976a9146e7242f2ac430d28015e6193011002985a8007d688ac5c591100000000001976a914a10e4fee59d779ce703803d8c7aa515d5423bb2088ac28080600 |
|
|
|
From the other persons thread that asked today: Copy and paste = permanent.
Just to make you aware: Its not only the account that is banned, its you as a person that is banned. This includes all past or future accounts. If they are discovered they will be banned. You may talk about your ban here as a sole exception. |
|
|
|
Its more common that not the actual block files are corrupted but rather the database. If the blockfiles are corrupted you can usually delete the file in question to avoid redownloading everything. Which file is corrupted can be found in the debug.log. At least thats the overal experience from users reporting in tech support, its certainly possible that your case is different, but I guess you just deleted all files without trying other options first.
Thanks for the additional explanation, I didn't know the debug.log would show the corrupted file. When core crashes on me there is no indication in the log at all what happened, it always looks like the program is running fine if you just looked at the debug log, but next time corruption strikes I'll try your method, thanks. If there is no entry in the debug.log you might have to look at OS log files to find the reason for the crash. Lets hope its not needed. |
|
|
|
If one third party person knows a BTC address that is part of an electrum wallet, can he generate the other bitcoin addresses in that wallet based on that one address?
No. What if he knows multiple addresses, can he derive all addresses from that info?
No. Or only the master public key can generate the addresses?
Yes. How to keep the master public key hidden, so that nobody can know the addresses in that wallet? (because it's not protected like the private key)
Dont let anyone get your wallet file, which you should do anyway to avoid brute force attacks on your private keys. |
|
|
|
You missed the important metric IMHO, at least for the last few days.
Someone did mention this on IRC if I recall correctly. It seems like another attempted attack on the network? I dont have details either, just saw it on twitter earlier. IRC? #bitcoin? (answer per PM is prefered to not derail the thread with it). |
|
|
|
#1 reasonable fee, check. Currently estimatefee 1 -> 0.00044328 the TX in question 0.0002 per 2053 so ~0.00009742 estimatefee 15 -> 0.00007770 estimatefee 14 -> 0.00010533 Should thus confirm after ~14-15 blocks according to core. #2 no dust outputs, check. #3 no unconfirmed inputs, check. Should be confirmed in a few hours, I gave it a push. If anyone wants to help, here is the raw TX. 010000000b7c7f817fffcb511e578936a6b73e6c1809ae3cc5b35da4e5f3ed3fb1d4bbced8240000008a47304402205c3b505608aa2d3406368bd60c6e100ac3772152258392693a2de8987094c1e602204af269215bd2c3544f546177d42f81498e7d1ee203905982e8b1b5a08eb78958014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff1ee97cdc500e32a686c2a27ac45c5a140ca05fd964d73492674a1dd5744aa3d49f0c00008a47304402205b577cf966eb969916e8df2b4e0ef747e4a1122ccb3f770713b921d83d17d73202206c2c8599a9c8d94f60157fe42e487b4fa715d117fe5cb4da54fbf7a5c98abeb7014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff62809e670d242ccea70e81e7217a183a8cb6f35d6293e916f0af3614ee12a6faa60c00008b483045022100a21f111f395cc01218298bb552ff0d6c52666d0eccf24c9387f409db48366d3b02201d94261a35787fbff255b09452caf5f6de9f14a6bdc69e7439c807c40d97bd82014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffffaf18251bad88ca34b2e6f82d2d092da3df84cd4e1951c5b525b3ad8af68844e1010000008a473044022023193893c7f5ee46739bfc6cb6425cc3b4d64e6b32271cad706d811adcfbae520220172051d18dac6eb5e6098c8d2c2f1851f04f024069cb35eabdf633f39fdbd0ab014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff29ae4bf020f47584e6b858aa6bb8be030883f8c596b238cf273e32c25e1fc48f920d00008a473044022034e2b94f612a72123133d6dd99f419dc4131b612af3fac4f207a8a7c58023951022031e3fdabc0a40677b728cd25bc9d7295716f31ece5e45ace60d8e063d0d8695d014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff8fec49c027961c67963b8cdde9afe1c4d6e874fa6c7115f3703569020e8ac36d010000008b483045022100c870ac4defbe8b3d779555a2303b959397caabeb1ea99142f1b877c5e9efb39602200c4c796bb0777cc7a5cb3e55ae14fd81822a89d805b3308fa609d453243c6b46014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffffbc4fa4d298e0e0037066079117bd7b0dd6697a7014ece0bd701598eae61358ef200000008b483045022100c66880417f782a9bbf6e3e282eaa1658c57382b609360353b694bdc7668f885a02205449ea559a7244043c79ca50f1c1b774c9921a6b7349f64f0b44926f4b202415014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff4f14eea513138426aab584fbcf524fe243329ac233d098ac4c82f10b80ede458010000008a4730440220592eaf7442a4336b315cab97e451bf58b6292b96ee92f86c41c4212d5641681a022033a3471bdcf2fc2a34c2fb6f6cfe390601b18ad2ff87ecea0a08bec1397641bd014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffffc45614e425690c7e581fb47fcffb65a0a3a61c86b882a18e2b1c2cf85187e8e6010000008b483045022100dcc8ea0d921fe5b6e6e556b33a1504598f9191d3b81c674d225e7a70e62ba58a02200e5f356b4e658af872e7a23b89264be6193c2dd34de55a493ab4238352b82d72014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff2f2ad9ba5ce752ceb8f75701399b356a451f761a46cf69213a4da407b2103f53010000008b483045022100ed89319d8bd27f20cdfbf250481c1f2eca4cade02ef02b22352db88a662019d802200afb7e378b4ca9ff4ea6fb7dbe2d7ffa5528b86e290aaec483fe1c166a85dbe3014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff2c24e3c47ef90e5dcb3a65a21cafc9f857c83af13e5184e61c2da318c16c8beb010000008b4830450221009a04b3484e9f23ab971b633c0b1264db7ac8bddac7b17e596bc401034549799c02202083cacdfd108c587b148414104dcd2fc3b4694f537aad284a4fdf7e58bccaee014104160d9b73ad553e38fb8e469700af8ab89e2d4e34bd5f450775bdd69199f96f34b6183b34044659f66891d925f080758b1c0dd8809c4fa95575dd169b6595960fffffffff02c068ad10000000001976a91470c735cb47fb02ba9b205b7a42cf77465c175e7d88acc78f1b05000000001976a914c1525ff6ca960773a033a330b4674c6e91dff8f588ac00000000
|
|
|
|
Its not the 50GB that are corrupted and you dont need to redownload anything.
Uh, what? Once the blockchain is corrupt core has to redownload the whole thing again. I actually have to delete everything in my bitcoin folder or core simply crashes right away again. Provide some explanation for your statement, please. Its more common that not the actual block files are corrupted but rather the database. If the blockfiles are corrupted you can usually delete the file in question to avoid redownloading everything. Which file is corrupted can be found in the debug.log. At least thats the overal experience from users reporting in tech support, its certainly possible that your case is different, but I guess you just deleted all files without trying other options first. |
|
|
|
You missed the important metric IMHO, at least for the last few days.  |
|
|
|
|
Show Posts
