PC crashed, had to reset it.
Bitcoin now started reindexing, but even there the two error's.
That does not sound healthy. Core is heavy on the CPU while syncing, but a crash shouldnt happen on a stable system. Are you sure there are no other issues under heavily load? Maybe try a p95 stress test[1] or memtest86+ from any(?) linux cd/dvd to make sure its not an CPU/RAM issue. [1] http://www.mersenne.org/download/ |
|
|
|
updated Xotika.TV -> http://pastebin.com/SxFGJ0NyAdded both posts for SebastianJu (the one here and the "old" one in the Xotika.TV thread) as reference |
|
|
|
as far as i know exporting privatekey can only be done one by one through API.
Cant you use bumpwallet? dumpwallet "filename"
Dumps all wallet keys in a human-readable format.
Arguments:
1. "filename" (string, required) The filename
Examples:
> bitcoin-cli dumpwallet "test"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "dumpwallet", "params": ["test"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
It would give you a nice file that you can split by # of lines (mind the header though) and reimport into different wallet files via a short script. |
|
|
|
Haha this sounds more complicated than I thought. Do you know of a guide with step by step instructions? I guess it's probably not worth the 2 cents haha.
You can import them to another wallet. Or, if you really don't want those wallets, you can give the private keys to me  Or make them public, let it be a race  |
|
|
|
What about those HYIP website like Fenix , Pokeram etc. Can we go for them?
Just donate to Tor, at least your coins will be used for good. |
|
|
|
thanks, if that's true.. ..why is nobody providing blocks? these 8 peers provide nothing for 5-10 minutes at a time or more.
Blocks come at 10 minute intervals on average so that could be the data that you are getting. However you should be seeing data for transactions. i'm still 1 year and 18 weeks behind. yesterday i was 1 year and 19 weeks behind. #1 connections are low during the initial sync, thats normal. #2 is your CPU or your disk maxed out? Because if thats the case you might have an answer why you dont get any new blocks. If your machine is busy verifying and writing the blocks it has it can not request more. |
|
|
|
Hey!
Is investing in NEW ponzis a OK thing to do?
No. Obviously talking about the doubling sites that have just gone up. They should pay back the early investors back, right?
No, they might run with the first "investment". Obviously gambling, but is this a ok thing to do? what are the risks?
Thanks,
Its a ponzi, the risks are that you have never an idea where you are in its lifecycle. Thats not gambling, thats driving blindfolded on the freeway in the hopes that you wont hit anyone. |
|
|
|
|
When push comes to shove all I see is darkness for bitcoin. Ripping the network appart can not be in the interest of anyone.
|
|
|
|
As Jet Cash[1] reminded me via PM it might be that anti virus software is causing the corruption. There are some virus signatures in the blockchain, if the anti virus blocks access to the file it would appear for core as if the files are corrupted. You might want to whitelist the folder to rule that out. [1] https://bitcointalk.org/index.php?action=profile;u=698159 |
|
|
|
Eine reine Erhöhung ohne weitere Maßnahmen (siehe deine List oben, insbesondere SegWit und IBLT) bringt natürlich nichts. Mit O(1) block propagation durch IBLT sollte aber wirklich niemand mehr auch nur einen Satoshi liegen lassen. Schneller prüfen ist ja schon fast da (2-3? Wochen). Bis sich da wirklich was ändert (SegWit) ist aber halt noch hin.
Wir reden bei SegWit aber über Monate und nicht über Jahre. Yop, Juni/July 2016 wenn ich mich recht erinnere. Ich sehe da keinen Grund irgendwelche Sachen (XT, Classic, Unlimited) unbedacht zu Pushen. Daneben wären einfache Bitcoin Payment Channels mit der heutigen Script-Sprache schon möglich. Dafür muss man nicht auf LN warten, was sicher noch ein paar Jahre dauern wird.
Ich weiß gar nicht ob LN überhaupt nötig wird. Mit SegWit lässt sich ziemlich sicher CIYAM's AT problemlos integrieren. Dadurch könnten AT-fähig alts als Kanal für die Kleinstzahlungen dienen. Im Gegensatz zu LN ist AT schon fertig und auch schon zwischen mindestens 2 alts implementiert. Ich habs mir aber mit SegWit im Kopf noch nicht wieder angesehen kann also durchaus sein das ich was nicht bedacht habe. Ich sehe das so, dass sich hier ein paar Gestalten per Helikopter-Management als grosse Bitcoin-Führer positionieren wollen. Ich werde denen garantiert nicht blind nachlaufen, solange die Chance besteht durchdachte und zukunftsfähige Lösungen zu bekommen.
Nunja, Bitcoin Unlimited hat schöne Grundgedanken die Node Betreibern mehr Einfluss geben können. Der Code soll allerdings grotig sein und Schnellschüße und rumgemacker sind definitiv fehl am Platz. Ich hoffe stark das sich sinnvolle Ideen durchsetzen werden und nicht nach Personen entschieden wird. Der tatsächliche Knackpunkt dürfte sein, dass die Blöcke durch eine reine Erhöhung der Blockgrösse nicht grösser werden, solange die Miner weiterhin kleine Blöcke erzeugen. Einzelne grössere Blöcke lösen das Problem nicht.
Angeblich können die Chinesen ja 8 MB Blöcke, aber stimmt schon am Limit drehen ohne das es etwas ändert und das am besten noch per Hardfork ist so ungefähr das letzte was Bitcoin braucht. Langfristig wäre es schöner, vom Mining ganz weg zu kommen und Ansätze wie DAG zu verfolgen, bei denen POW durch den erbracht wird, der Transaktionen generiert.
Hab ich wieder was zu lesen, kenn ich nicht. Danke. Edit: Als erste Anlaufstelle -> https://bitcointalk.org/index.php?topic=1177633.0 |
|
|
|
is there someone who can help me with some unconfirmed transfer issues between own wallets at blockchain?? thank you.
50k satoshi reward for the one who will help me seriously
#1 dont hijack threads, open your own in the proper section (probably tech support in your case) #2 tell more about the problem if you want help. |
|
|
|
Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees. Won't it break the ability to accept zero confirmation transactions? As there are currently methods to do so with great certainty that a zero confirmation transaction will go through the next block. And also doesn't this break the core ethos of bitcoin being a pure push system only. I've read the RBF transactions update is being merged into bitcoin core at the next update. Isn't that a little hasty for such a drastic change to the protocol to be brought in so quickly. After it took us a good several months to agree on re-increasing the blocksize.
My limited understanding is that the first transaction needs to raise a flag in order to allow RBF. Merchants that accept 0-conf TX could scan for the flag and wait to deliver their part if it is set. On the other hand I am not sure how ready merchants or even regular wallet implementations are. |
|
|
|
ahh my multibit hd wallet address is dynamic. it changes everytime. i recognise it right now.
what happens to my first address? i give it to some bet coupons. if someone sends btc to my changed (old) address may i take this coins?
Yes, it stays in your wallet and you will be able to spend the coins. |
|
|
|
2 lines:
2016-01-17 10:52:43 ERROR: AcceptToMemoryPool: nonstandard transaction: dust.
quite a few times, same time though.
Thats normal, it just means your node did not accept a transaction because one of the outputs it too small (dust). 2016-01-17 10:52:52 Pre-allocating up to position 0xb00000 in rev00091.dat
Asking for new space in one of the files. Got the errors again, debug.txt says:
2016-01-17 11:16:48 LevelDB read failure: Corruption: block checksum mismatch
2016-01-17 11:16:48 Corruption: block checksum mismatch
2016-01-17 11:16:55 Error reading from database: Database corrupted
The time isn't correct, it's 12:18 when the error occurred..
Update: This is the problem, every time i get the error, this is in debug.txt.
But what is the solution?
Looks like your blocks get corrupted on disk. Do you have other problems with it? Some have made good experience with -reindex. Start core with that common behind to let it rebuild the database from the local blocks. |
|
|
|
i'm installing fresh bitcoind on new server now.
Did you use a 32-bit version by any chance? That would explain the 3GB limit. |
|
|
|
Gleichzeitig sind die Blöcke aber nicht voll.
Deshalb bringt eine stupide Erhöhung der maximalen Blockgrösse vielleicht nicht den gewünschten Erfolg. Wenn die Miner nämlich die Blöcke trotzdem nicht füllen, dann ist nichts gewonnen, ausser dass sich ein paar Deppen profilieren konnten und viele Nutzer nachgewiesen haben, dass sie Dumme Schafe sind die gerne dem nächsten selbsternannten Führer folgen. Off-Chain Transactions (heute schon möglich, Multisig-Escrow ist schon ein winziger Schritt in diese Richtung) und Sub-Chains (bisher nur Theorie) sind die Stichworte für Lösungsansätze. Daneben können auch kleinere Features wie SegWit, IBLT, Pruning und andere zur Verbesserung beitragen. Liegt an der Arroganz und Unfähigkeit mancher Poolbetreiber.
Stichwort: SPV mining
Da die Miner zu einem guten Teil nicht selber die Hashes berechnen, würde ich eher den Betreibern der Hardware die Schuld geben, die ihre Hashleistung verschenken, kein Mitspracherecht haben und teilweise auch noch dafür ein paar Prozent an den Miner bezahlen. Naja größere Blöcke verbreiten sich langsamer im Netzwerk als kleinere. Werden zwei Blöcke gleichzeitig gefunden gewinnt wahrscheinlich der kleinere Block.
Da die meisten Transaktionen im Block bereits im Mempool sind, ist es unnötig, diese nochmals zu übertragen. Daneben muss die Verifikation schneller gehen. Die zweite Verbesserung ist im Bitcoin-Core Github bereits drin, an der ersten wird gearbeitet. Ich sehe schon wir sind da einer Meinung. Miner schießen sich selbst ins Bein wenn sie einschränken was mit Bitcoin überhaupt möglich ist. Eine reine Erhöhung ohne weitere Maßnahmen (siehe deine List oben, insbesondere SegWit und IBLT) bringt natürlich nichts. Mit O(1) block propagation durch IBLT sollte aber wirklich niemand mehr auch nur einen Satoshi liegen lassen. Schneller prüfen ist ja schon fast da (2-3? Wochen). Bis sich da wirklich was ändert (SegWit) ist aber halt noch hin. |
|
|
|
I sent .10 btc to an account yesterday At about 2pm eastern time and when I. Look at my transaction history it still says unconfirmed transaction.
It's been almost 24 hours . Where the he'll are my BITCOIN right now and how do I get then back? I don't have time for this..The account I sent from was blockchain.info wallet.
Please help me out!!
Thank you
Do you have a TX ID for us so we can look at the transaction more closely? It might be just a propagation problem (as in the network does not know about your TX). |
|
|
|
Added Xotika.TV without escrow -> http://pastebin.com/Bh3NW7YBWe can edit that in once its confirmed, if we tag it as "has escrow" its misleading. |
|
|
|
shorena,
danke für Deine Antwort. Das heisst es werden schon Gebühren bezahlt, doch nicht genug für eine Zeitnahe Abarbeitung. Eine Vergrößerung der Blocks wäre eine Lösung, eine Gebührenerhöhung eine andere.
Durch die Gebührenerhöhung würde es jedoch für kleine Läden (Geschäfte die man persönlich aufsuchen kann und nur geringe Beträge bezahlt, für ein Getränk z.B.) die an Endkunden verkaufen uninteressanter ...
Der Versandhandel kann noch eher damit leben, wenn er einige Zeit auf die Überweisung wartet.
Richtig, je höher die Gebühren werden desto weniger macht es Sinn kleine Beträge zu übertragen. Miner priorisieren aber genau nach Gebühr pro Byte. Da man auf die Größe einer Transaktion in Byte in der Regel keinen oder kaum Einfluss hat, bleibt halt nur mehr zu zahlen. Wer weniger Zahlt muss halt warten und hoffen trotzdem an die Reihe zu kommen. Mit einer hohen Gebühr kann man aber immer an den Anfang der Schlangen springen, das heißt bei zu geringer Gebühr kann man auch tagelang auf der unbestätigten Transaktion sitzen. In vielen Fällen wird sie dann einfach vom Netzwerk vergessen und man kann es erneut mit einer höheren Gebühr versuchen. Einige sind der Meinung das ist genau was Bitcoin sein soll, es entwickelt sich ein Gebührenmarkt und Kleinstbeträge werden verdrängt. Ich halte es eher für sinnvoll die Miner mit vielen Transaktionen mit je kleinen Gebühren zu belohnen. |
|
|
|
|
Any clues in the debug.log?
|
|
|
|
|
Show Posts
