Bitcoinverlust durch Hardfork

[Fred]

Hallo zusammen!

 

Ich lese und verfolge seit einigen Monaten die Entwicklung des Bitcoin und habe mich nun entschlossen auch zu investieren.

 

Nachdem ich endlich Bitcoin Core installiert und syncronisiert habe wollte ich eigenltich direkt loslegen.

Jedoch kam nun die Diskussion um den kommenden Hardfork auf 2mb mit dem neuem Client Bitcoin classic auf.

 

Meine Frage nun: Habe ich , als Ottonormalverbraucher, irgendwelche Einschränkungen? Falls sich der neue Client durchsetzt, bleiben alle Bitcoins erhalten? Können sie gefahrlos übertragen werden? Wie wird, technisch gesehen, die Übertragung statt finden?

 

Um ein paar erklärende, beruhigende Worte wäre ich sehr dankbar.

 

Viele Grüße,

 

Fred

[azu393]

ich lass mal ganz dreist nur den link hier liegen.

 

https://en.bitcoin.it/wiki/Hardfork

[Fred]

das ging ja fix, dankeschön.

 

Daraus schließe ich mal, das soweit sich nachhaltig ein Client durchsetzen wird, alles problemlos transferiert werden kann. Aber was passiert in der Zeit bis dieser Prozess stattgefunden hat? Das wird sicher einige Tage(Wochen) in Anspruch nehmen?

[azu393]

das hier ist sicher auch gut für dich:

http://bitcoinblog.de/2016/01/18/wir-sind-uns-einig-dass-man-mehr-transaktionen-durchlassen-muss-aber-die-blockgroesse-zu-erhoehen-ist-einfach-keine-effiziente-loesung/

[Axiom0815]

Wenn Du schon jetzt Bitcoins gekauft hast, kannst du dich beruhigt zurück lehnen und zusehen, wer gewinnt.

Deine Bitcoins sind in beiden Varianten ("Gabel") dabei.

[Fred]

Noch habe ich sie nicht -  das ist ja das Problem

 

Wann ist dieser Entscheidungsprozess zu erwarten? Ich bin doch etwas skeptisch.

[Christoph Bergmann]

Hallo Fred, schön, dass hier noch jemand einen Bitcoin Client laufen lässt!

 

Zu deiner Frage bekommst du von mir dieselbe Antwort: Solange deine Coins vor der Hardfork eingetrudelt sind, können sie gar nicht verloren gehen, da das, was dein Client macht - private Schlüssel für Adressen verwalten - später funktionieren wird, egal welche chain sich durchsetzt.

 

D.h.: Coins, die vor einer hardfork auf deinem Clienten liegen, gehören nachher dir, egal was passiert.

 

Zur Sicherheit würde ich jedoch die wallet.dat exportieren.

 

Ich selbst behaupte sogar, dass man auch während der hardfork problemlos Bitcoins überweisen kann. Sie kommen dann eben zu verschiedenen Zeitpunkten in die verschiedenen Chains, werden aber von beiden erfasst. Wenn man während der Fork hingegen Coins empfängt, gibt es die Möglichkeit, dass man den Coin nur auf der einen Chain erhalten hat. Das könnte in die Hose gehen (hier sollte man eventuell einen blockexplorer nutzen!).

 

Eine sinnvolle Alternative für eine Hardfork ist m. e. Bitcoin Unlimited. Das ist eine Art Aufsatz für Bitcoin Core, der dir die Möglichkeit gibt, selbst die maximale blockgröße zu wählen und die Fähigkeit hat, mehrere chains gleichzeitig zu beobachten und Inkonsistenzen zu melden. Das könnte für den Fall einer Hardfork nützlich sein (und macht es dir darüber hinaus möglich, mit derselben Software für diesen oder jenen Teil der Fork zu stimmen).

[boardfreak]

"...Eine sinnvolle Alternative für eine Hardfork ist m. e. Bitcoin Unlimited. Das ist eine Art Aufsatz für Bitcoin Core, der dir die Möglichkeit gibt, selbst die maximale blockgröße zu wählen..." - ich hingegen halte classic als auch unlimited für flickwerk - der bitpayansatz ist imho das einzig wahre da die software eigenständig die blockgröße anpasst - das einzige worüber sich dabei streiten lässt ist anhand welcher genauen parameter und formeln dies geschehen soll - sobald es es darüber jedoch einen konsens gibt ist die blocksizedebatte vom tisch - im schlimmsten fall müssten dann nur noch irgendwann in weiter zukunft falls es wirklich doch so sein sollte dass die gewählten parameter und formeln doch nicht ausreichen um die blöcke vorm verstopfen zu bewahren diese durch einen erneuten konsens angepasst werden - das wäre aber nur der worst case und nur sehr unwahrscheinlich denn ich glaube nicht dass mit der bitpaylösung der blocksizemist in zukunft überhaupt nochmal aufgewärmt werden müsste sondern endgültig abgehakt wäre

[Axiom0815]

Die Lösung von BitPay ist die (zur Zeit) vernünftigste. http://bitcoinblog.de/2016/01/08/bitpay-experimentiert-mit-eigenem-ansatz-fuer-blockgroesse/

Da haben mal welche echt nachgedacht!

 

Bitcoin Classic ist erst einmal ein Schritt um denn meisten Konsens zu erhalten, dass man erhöhen kann.

 

Bei der Blockgrößenerhöhung ist nicht nur das Problem "Blockgröße" primär zu beachten, sondern auch die gegenseitig vernetzten Nodes. Mit steigender Größe wird hier die Datenlast potenzial größer. Hier müssten dann auch neue Ansätze her.

 

Ein K.O. Kriterium haben wir ja schon mit 53 GB Blockchain erreicht. Wer den Client neu aufsetzt benötigt "ewig". Bei schlechter Internetanbindung, z.B. über Handy, eine Unmöglichkeit.

Bearbeitet 19. Januar 2016 von Axiom0815

[azu393]

Ein K.O. Kriterium haben wir ja schon mit 53 GB Blockchain erreicht. Wer den Client neu aufsetzt benötigt "ewig". Bei schlechter Internetanbindung, z.B. über Handy, eine Unmöglichkeit.

 

wer eine full node betreiben möchtw wird sich daran nicht stören.... die 53gb sind selbst mit "normalen" dsl 16000 in guten 7 stunden fertig... sofern man diese via bootstrap bekommt....

 

der trend wird meiner meinung nach eher zu online wallets gehen -> nur ein nerd wird sich die 53gb laden.... der mainstream braucht das nicht und kann damit meiner meinung nach auch nicht sauber umgehen...

[Christoph Bergmann]

wo gibt es denn das bootstrap?

[BTC-Hunter]

Sorry noch eine Frage dazu:

 

Ich benutze Electrum. Mein Electrum ist auf "Autoconnect" eingestellt und verbindet sich beim Start über einen Server mit der Blockchain. Ich vermute mal, dass es dann an dem Betreiber des Servers liegt, welchen Zweig er nach einem Hardfork unterstützt. Jetzt habe ich beobachtet, dass die Server immer mal wechseln können.

 

Wenn der Hardfork dann durchgeführt wurde, kann es sein, dass ich dann mal mit dem einen Zweig und mal mit dem anderen verbunden werde?

 

Die beiden Zweige sind doch nach dem Hardfork voneinander getrennt, da nicht kompatibel oder?

[Christoph Bergmann]

Sorry noch eine Frage dazu:

 

Ich benutze Electrum. Mein Electrum ist auf "Autoconnect" eingestellt und verbindet sich beim Start über einen Server mit der Blockchain. Ich vermute mal, dass es dann an dem Betreiber des Servers liegt, welchen Zweig er nach einem Hardfork unterstützt. Jetzt habe ich beobachtet, dass die Server immer mal wechseln können.

 

Wenn der Hardfork dann durchgeführt wurde, kann es sein, dass ich dann mal mit dem einen Zweig und mal mit dem anderen verbunden werde?

 

Die beiden Zweige sind doch nach dem Hardfork voneinander getrennt, da nicht kompatibel oder?

 

 

Mit einer "Light-Wallet" bist du in der Hardfork-Frage passiv - du kannst nur machen, was die Wallet-Entwickler machen.

[Gast]

vergessen

Bearbeitet 27. Februar 2016 von Gast

[...]

Mit einer "Light-Wallet" bist du in der Hardfork-Frage passiv - du kannst nur machen, was die Wallet-Entwickler machen.

 

Hm. Kann ich nicht heutzutage mich schon mit einem Electrumserver meiner Wahl verbinden, der auch schon 2 MB Bloecke bedienen koennte?

AFAIK ist Electrum aus Nutzersicht da frei. Aber bin mir nicht sicher.

[Axiom0815]

wo gibt es denn das bootstrap?

 

https://www.coinforum.de/topic/4606-blockchain-größe/#entry75231

[Axiom0815]

Sorry noch eine Frage dazu:

 

Ich benutze Electrum. Mein Electrum ist auf "Autoconnect" eingestellt und verbindet sich beim Start über einen Server mit der Blockchain. Ich vermute mal, dass es dann an dem Betreiber des Servers liegt, welchen Zweig er nach einem Hardfork unterstützt. Jetzt habe ich beobachtet, dass die Server immer mal wechseln können.

 

Wenn der Hardfork dann durchgeführt wurde, kann es sein, dass ich dann mal mit dem einen Zweig und mal mit dem anderen verbunden werde?

 

Die beiden Zweige sind doch nach dem Hardfork voneinander getrennt, da nicht kompatibel oder?

 

Hallo.

 

Electrum ist ein SPV-Client, also er hält nicht selbst die Blockchain, sondern fragt die Informationen ab.

Somit ist man immer davon abhängig, was der "Gebende" an Informationen vorhält. Man hat selbst keinen Einfluss.

 

Was man aber machen kann ist, selbst Servern aus einer Liste auszuwählen oder eigene eintragen. Trotzdem bleibt man abhängig von den Serverinformationen.

Inoffiziell wird in der "Electrum-Szene" noch auf die Lösung gesetzt, Stein und Bein am Core festzuhalten. Würde ich aber nicht darauf wetten, so was kann schnell umschlagen.

 

Als Lösung für dieses Problem kann man sein eigenen Full-Node betreiben und dann ein Electrum-Server selbst ran hängen. Dann hat man wieder alles selbst in der Hand. Die Server gibt es als Python- oder Java-Variante.

 

Aber wie sagt man so schön, es wird nicht so heiz gegessen, wie es gekocht wird. Also mal zurück lehnen und abwarten.

Die Strategie von mindestens 75% hat den Vorteil, dass dann sofort eine dominierende Lösung geschaffen wird und viele dann auch diesen Weg gehen.

 

PS: Was die Core-Entwickler so leise neben bei machen (im großen Geschrei um die Blockgröße) beunruhigt mich. So ist der Bloom Filters  jetzt bei Bitcoind optional einstellbar. Jetzt noch mit Default ON.

Es impliziert aber die Möglichkeit diesen auf OFF zu stellen und somit SPV-Clients auszusperren.

Mindestens wenn dann die Sidechain und Clients dafür kommen, könnte man den Default-Wert auf OFF stellen und somit die "ungeliebte Kongruenz" aussperren.

Und wieder einmal scheint es keinen zu interessieren. Das betrifft dann zum Beispiel die beliebte Wallet Bitcoin von Andreas Schildbach. 

Electrum ist da außen vor, weil es eine eigene Server-Infrastruktur gibt. Aber eben mit den Datenschutzproblem...

 

Axiom

Bearbeitet 21. Januar 2016 von Axiom0815

[Christoph Bergmann]

https://www.coinforum.de/topic/4606-blockchain-größe/#entry75231

 

Hmm ... d.h. du verschickst bei Bedarf die bootstrap.dat selbst, und wer dann ein bittorrent-Programm hat, kann die Kette so runterladen?

[Axiom0815]

Ja, kann ich machen. Verteilt auf zwei BD.

 

bittorrent... weis nicht ob das noch aktuell ist.