joho

Das Lightning-Netzwerk ist sicher eine tolle Erfindung. Meiner Meinung nach ist es aber kein Ersatz für die sehr bald fällige Erhöhung der Blockgröße. Zum einen kommt es dafür zu spät. Es hängt ja zum einen von den noch zu programmierenden Softforks ab. Zum anderen müssen Wallets, Dienstanbieter, Exchanges, etc das unterstützen und die Software dafür ist zum größten Teil noch nicht geschrieben. Es wird noch viele Monate dauern, eventuell noch Jahre bis es wirklich nutzbar ist. Zum anderen reicht die aktuelle Kapazität auch mit LN nicht aus. Es heißt immer, man kann 1000 Transaktionen in einer Lightning-Transaktion zusammenfassen, aber welcher private Nutzer hat schon regelmäßig 1000 Transaktionen? Man muss auch bei der ersten Transaktion das Geld für alle Transaktionen auf eine Art Treuhandkonto überweisen, also muss man das Geld zumindest flüssig haben. Was auch oft vergessen wird: die Technik von LN verlangt, dass vorunterschriebene Transaktionen mit fest definierten Gebühren innerhalb von einem Tag sicher akzeptiert werden. Wenn die Kapazität von Bitcoin immer wieder an seiner Grenze stößt ist das nicht gegeben. Zur Frage "Wer betreibt das Netz". Es gibt zum einen das Hub+Spoke-Netzwerk, bei dem man ein Konto bei einem Hub hat (man kann sich einen Hub als Bank vorstellen, aber in der Praxis können das auch Exchanges oder reiche Privatpersonen sein). Die Hubs sind dann untereinander verbunden (Spokes). Das Geld liegt dann immer auf einem Treuhandkonto (2-of-2 multisig-Adresse). Der Hub braucht eine Menge Kapital, denn Geld was auf ein Konto eingezahlt wird, muss bereits vorher auf dem Treuhandkonto gelegen haben, damit die Transaktion durchgeführt werden kann, ohne über die Blockchain zu gehen. Dann gibt es noch die Idee des "Lightning-Netzwerk" bei dem jeder Payment-Channel, der zufällig existiert, genutzt werden kann. Die Idee ist, wenn du einen Payment-Channel zu bitcoin.de hast und eine Person X hat zwei Channel, einen zu bitcoin.de und einen zu btc-e dann kannst du Geld an eine dritte Person, die ein Konto bei btc-e hat überweisen, indem du über bitcoin.de, die Person X und btc-e routest. Funktioniert natürlich nur, wenn alle Payment-Channels genügend Geld von der richtigen Seite reserviert haben und auch alle Zwischenstationen zu dem Zeitpunkt online sind. Gerade letzteres ist aber fraglich, denn wer möchte seine privaten Schlüssel auf einem 24/7 erreichbaren Internetrechner unverschlüsselt liegen lassen, damit andere Personen darüber ihre privaten Zahlungen routen können. Ob das Lightning-Netzwerk im großen Maßstab funktioniert, ist meiner Meinung nach sehr fraglich. Vielleicht funktioniert es, aber man sollte jetzt nicht die Zukunft von Bitcoin allein darauf setzen. Im kleinen Maßstab ist es aber sicher nützlich. Z.B. Paymentchannels zu Bitcoin-Exchanges damit man das Geld immer sicher hat (auch wenn der Exchange pleite geht), aber man trotzdem mal eben schnell eine Order tätigen kann, wenn der Preis springt. Oder um die berüchtigen Satoshi-Dice-Transaktionen von der Blockchain zu bekommen, ohne an Sicherheit zu verlieren.

Hier https://github.com/bitcoinclassic/bitcoinclassic/blob/0.11.2/src/chainparams.cpp#L59 https://github.com/bitcoinclassic/bitcoinclassic/blob/0.11.2/src/main.cpp#L1855 Wenn 750 der letzten 1000 Blöcke das bit für large blocks gesetzt hatten (also deren Miner für große Blöcke gestimmt haben), dann wird die Fork getriggert und exakt 4 Wochen später (entscheidend ist der Zeitstempel in den Blöcken) darf ein Block bis zu 2 MB groß sein.

Du hast vermutlich nicht die Change-Adressen importiert. Wenn du mit bitcoin-core sendest nimmt er immer eine empfangene coin, sendet sie und wenn etwas übrig bleibt, wird der Rest auf eine Change-Adresse übertragen. Diese werden im Client nicht angezeigt, weil man interne Details gerne verbergen will, um den Nutzer nicht zu überfordern. Hat aber zur Folge, dass der Nutzer nicht verstehen kann, was der Client macht. Aber das Problem hast du ja gelöst. Generell ist es eine schlechte Idee private Schlüssel in electrum zu importieren, weil diese nicht durch das Backup des Seeds abgedeckt sind. Dann braucht man ein extra Backup für alle importierten Schlüssel. Wenn du das aber nur vorübergehend machst, weil du von QT nicht senden kannst, ist das okay. Dann solltest du aber irgendwann alles auf die internen Electrum-Adressen übertragen, um wieder Ordnung hineinzubekommen. Welche Fee hast du genommen? Alles unter 0.0001 BTC pro angefangenes kB (knapp 4 cent) ist wohl zur Zeit kritisch. Auch darüber kann es manchmal ein wenig länger dauern, sollte aber durchgehen.

Ist die Adresse 1G5oz4A... eine Empfangsadresse von Electrum? Falls ja, dann müsste electrum den Betrag (0.35 btc) anzeigen und wenn das nicht der Fall ist, ist electrum nicht richtig synchronisiert und du musst die Netzwerkeinstellungen überprüfen. Wenn es keine Adresse von Electrum ist, zu welchem Client/Service gehört die Adresse?

Hmm, welches Programm genau? Wenn es ein bip-39 seed ist, dann: https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt in der bip-39 doku steht, nach welchen Kriterien die Wörter ausgewählt wurden (z.B. so dass die ersten 4 Zeichen das Wort eindeutig festlegen). Es wird eine große Zufallszahl erzeugt (128/256 bit) eine Checksumme angehängt (4/8 bit) und dann daraus 12/24 Wörtern erzeugt (als wäre es eine große Zahl, die zur Basis 2048 dargestellt wird) Man kann nicht seine eigenen Wörter mit einbauen, da sonst der Seed nicht mehr als gültig erkannt wird. Electrum hat ähnlichen Algorithmus, unterscheidet sich aber in Details.

Ja, version muss nach hex, nicht nach binär kodiert werden. 3 als 32-bit hex-Zahl ist 00000003, bzw. 03000000 in Little-Endian. Auch der Prev-Hash ist in Little-Endian angegeben, d.h. der hash ist eigentlich b6ae.............1f050000000000000000 time bits und nonce müssen auch nach little-endian, bei Merkle-Tree-Hash bin ich mir nicht sicher, ob der schon umgedreht ist oder nicht. Diese Little-Endian-Konvention ist schon sehr merkwürdig, aber leider der Standard in Bitcoin. Das führt dazu, dass man die Hex-Zahlen umdrehen muss (wobei immer zwei Hex-Zahlen zusammenbleiben), wenn man Transaktions-IDs oder Block-IDs ausgibt oder einliest.

Ein full-node ist das Programm "bitcoind", das Teil vom Core-Bitcoin client (oder von BitcoinXT) ist. Es ist das Rückgrat des Bitcoinnetzes. Jeder full-node ist gleich und die full-nodes verschicken untereinander die Blöcke und Transaktionen, nachdem sie geprüft haben, dass sie den Regeln des Bitcoinnetzes entsprechen (wobei sie einandern nicht trauen und daher die Regeln immer wieder neu prüfen). Die Blöcke und Transaktionen geben sie dann auch an andere SPV-Clients weiter, oder werden von Webwalletanbietern und Exchanges benutzt um auf die Blockchain zuzugreifen. Theoretisch kann jeder seinen eigenen full-node implementieren, praktisch kann man da aber leicht Fehler machen und einen böse Transaktion akzeptieren oder einen guten Block ablehnen (beides kann fatal sein). Daher wird normalerweise nur die Referenzimplementierung benutzt und man schließt dann einen light-weight node, der nicht alles prüft, an einen full-node, den man selbst kontrolliert. Oder man kann auch auf die Daten des full-node über die sogenannte RPC-Schnittstelle zugreifen und so nach Blöcken oder Transaktionen fragen. Die Referenzimplementierung enthält auch eine Wallet, dies kann man aber auch abschalten. Außerdem enthält sie auch den Code für Solo-Mining. Allerdings ist das eher nebensächlich und nicht Teil des eigentlich full-nodes.

Der 20-Tonner hat allerdings ein Jahr Lieferzeit und es ist abzusehen, dass der Kleintransporter bald nicht mehr ausreicht. Außerdem hat der den gleichen Spritverbrauch wie der 5-Tonner (sofern er nicht voll beladen wird). Ich habe mal die Auslastung der Blöcke für die letzten zwei Jahre angeschaut. Zugegebenermaßen ist das nicht leicht, da stark schwankend. aber in den letzten Jahren ist die Blockgröße irgendwo zwischen 50 und 80 % gewachsen. Wir sind jetzt bei 350 bis 400 kB, in anderthalb bis zwei Jahren sind die Blöcke voll (beim letzten Stresstest zeigte sich, dass im Mittel etwa 800-850 kB pro Block verarbeitet werden können, weil ab und zu leere Blöcke erzeugt werden). Was passiert dann? Erhöhen der Gebühr schafft nicht mehr Platz, aber es schreckt vielleicht genügend Leute ab, Bitcoin zu benutzen, sodass der Rest wieder genug Platz hat. Am Anfang werden es sicher nur die Fountains sein, die eh keiner braucht, aber wenn die weg sind, muss für jeden neuen Bitcoin-User ein alter gehen. Oder es muss mal eben jemand endlich das Lightning-Protokoll implementieren (allerdings wird es bei einer Millionen Nutzer dann trotzdem eng). Es ist sicher nicht ganz so dramatisch wie Mike Hearn in seinen Blogs teilweise schreibt, aber es wird dazu führen, dass einige interessierte Leute nicht Bitcoin nutzen da zu teuer oder lange Transaktionszeiten.

Meine geheime Hoffnung ist ja, dass einer der verbleibenden Core-Entwickler einen vernünftigen Kompromiss im Core implementiert. Nicht BIP-104, da zu schwach, aber irgendwas was zumindest in absehbarer Zukunft 2 MB-Blöcke erlaubt mit moderatem exponentiellen Wachstum, das sich an dem Wachstum der Bandbreite orientiert. Aber es ist nur eine schwache Hoffnung. Wenn kein Miner >1MB-Blöcke produziert, werden weiter alle an der gleichen Chain arbeiten auch nachdem 75 % erreicht sind. Allerdings genügt es, wenn ein Miner spaßeshalber einen größeren Block baut, um die Chain zu splitten. Ich denke das wird sich nicht vermeiden lassen. Wenn Core und XT auseinanderlaufen, würde sofort die Core-Chain komplett ausgelastet sein. Es gibt ja jetzt schon mehr als 300 kB Transaktionen pro 10 Minuten und wenn der Split passiert, hat die Core-Chain nur maximal 25 % Hashleistung, d.h., von den über 1.2 MB Transaktionen pro 40 Minuten würden mehr als 200 kB verworfen werden, zumindest bis zur nächsten Anpassung der Difficulty. Dann dürfte es leicht sein "double-spends" durchzuführen und so seine Coins in Core- und XT-Coins zu splitten (z.B. um sie getrennt voneinander zu verkaufen). Ich denke, dass dann sehr schnell die meisten Transaktionen nur noch zu einer Chain passen. Wieviel Core- und XT-coins dann wert sind, das wage ich nicht vorauszusagen, aber sicher werden sie in der Summe nicht mehr wert sein als ein Bitcoin vor dem Split. Die Miner würden nach der nächsten Anpassung eine kleinere Schwierigkeit haben (es sei denn es wechseln alle auf den gleichen Zweig), so dass es sich wieder ausgleicht. Allerdings kann ein Miner da viel gewinnen oder viel verlieren, je nachdem welche Entscheidung er trifft. Die Frage ist, ob sich die Miner überhaupt darauf einlassen, oder auf Nummer sicher gehen und nicht vorzeitig updaten, wodurch der Split erst gar nicht auftreten kann.

Hallo Jörg hast du die 50GB schon fertig synchronisiert? Wenn nicht, kannst du auch den Private-Key in Electrum importieren. Dazu im Bitcoin client den Private-Key zu einer Adresse anzeigen lassen (fängt mit K,L oder 5 an; auf keinen Fall jemandem anderen verraten oder hier posten). Diesen kann man dann in Electrum importieren. Hast du schon über Backups nachgedacht? Zunächst solltest du ein sicheres Passwort setzen, dass du auf keinen Fall vergisst. Schreib das Passwort ruhig irgendwo auf, aber verwahre den Zettel sicher und nicht als Post-It am Monitor. Dann musst du die wallet.dat regelmäßig sichern. Am Besten das Backup nicht mit der aktuellen Version überschreiben, sondern jedesmal als neue Datei mit Datum sichern (falls die Wallet unbemerkt kaputt geht, hast du immer noch eine ältere funktionierende Kopie). Und natürlich nicht auf dem gleichen Rechner sichern, sondern auf ein oder besser mehrere externe Medien. In die Cloud geht auch, aber nur wenn das Passwort der Wallet sicher genug ist. Bei electrum musst du dir den Wallet Seed (Samen) notieren und dann brauchst du keine Backups mehr zu machen. Wenn du allerdings private Schlüssel importierst, musst du diese separat sichern. Es ist wichtig, dass du den Seed sicher verwahrst aber so, dass er nicht in falsche Hände fällt. Du solltest auch in Electrum ein Passwort setzen, aber das Passwort brauchst du nicht, wenn du die Wallet später wieder aus dem Seed herstellst, also pass auf dass an den Seed keiner rankommt. Es gibt genügend Trojaner, die es auf die Wallets verschiedener Bitcoinclients abgesehen haben. Wenn du ein sicheres Passwort gesetzt hast, verhinderst du zumindest dass jemand mit der gestohlenen Wallet direkt etwas anfangen kann. Allerdings haben die Trojaner auch oft Keylogger, die das Passwort dann abfangen, wenn du es wieder eingibst. Also solltest du vorsichtig sein, was du sonst so auf den Rechner installierst.

Das war sogar mal eine Überlegung von Gavin. Natürlich muss man dann auch die Mining-Belohnung halbieren, damit die Belohnung pro Zeit gleich bleibt. Allerdings ist auch das eine recht kontroverse Änderung und schwierig dafür eine Mehrheit zu begeistern. Um wirklich für Ladengeschäfte tauglich zu sein, müsste man die Blockabstände auf Sekunden reduzieren. Dies führt zu einer wesentlich höheren Orphan-Rate (zwei Miner finden fast gleichzeitig einen Block, bevor sie von dem Block des jeweils anderen erfahren, ein Block muss verworfen werden). Litecoin und Feathercoin zeichnen sich z.B. gerade dadurch aus, dass sie die Blockabstände deutlich verringern, aber für Bitcoin ist das nicht geplant.

Naja, der Bitcoin selbst wurde von halb sovielen Leuten angeschoben (zumindest, wenn Satoshi Nakamoto wirklich nur eine Person ist). Die zwei Personen entscheiden aber nicht, sondern die Miner, die zu BitcoinXT wechseln. Jetzt kann man natürlich argumentieren warum die sechs größten Mining-Pool Besitzer entscheiden dürfen, ob der Fork stattfindet oder nicht (diese haben 75 %). Allerdings werden diese sicherlich auch ihre Entscheidungen davon abhängig machen, ob auch die Exchanges und Verkäufer mitziehen werden. Schließlich verlieren sie 2700 BTC pro Tag wenn sie auf den falschen Fork setzen. Es ist jedem freigestellt den Source-Code zu kopieren und abzuändern. Wenn Satoshi Nakamoto das nicht gewollt hätte, hätte er den Source-Code unter eine andere Lizenz stellen müssen. Aber ich denke, seine Intention war, dass der Source-Code gerade nicht unter einer zentralen Autorität steht. Stattdessen soll jeder ihn anpassen können, wenn er die Mehrheit der Nutzer davon überzeugen kann, zu wechseln. Man kann aber die Frage auch umdrehen: warum sollten drei Leute mit ihrem Veto darüber entscheiden dürfen, dass Bitcoin auf absehbare Zeit die Blockgröße nicht ändert, ganz egal was die Mehrheit der Benutzer will. Ob man BitcoinXT installiert, kann jeder für sich entscheiden. Im Moment hat das noch gar keine Auswirkungen, außer, dass man damit seine Meinung kund tut, dass man BIP101 unterstützt. Wenn es zu einem Fork kommen sollte (was frühestens im Januar passiert), muss man natürlich abwägen, ob man dem Fork folgen will, oder nicht.

Alle Zeilen die mit # anfangen werden ignoriert. Du musst also bei den hervorgehobenen Zeilen die Raute (#) entfernen. Damit die Änderungen wirksam werden, musst du den bitcoin server (bitcoind) neu starten. Und ändere das Passwort Der Service ist glaube ich von außen zugreifbar und man kann darüber die private keys auslesen. Also ein supersicheres Passwort verwenden. Normalerweise muss man das Passwort beim bitcoin-cli nicht angeben, denn der guckt auch in die Datei. Zumindest ist es bei mir unter Linux so.

Die Transaktion wurde nie von einem Miner aufgegriffen. Es gab in den letzten Tagen eine Spamattacke (sehr viele Transaktionen mit normaler bis erhöhter Mininggebühr). Dadurch sind immer noch alle Blöcke voll und man braucht eine etwas höhere Mininggebühr um seine Transaktion bestätigt zu bekommen. Die Hoffnung ist, dass dem Spammer irgendwann das Geld ausgeht, er hat bereits mindestens einen zweistelligen Bitcoinbetrag an Transaktionsgebühren ausgegeben. Der Client zeigt an, ob die Transaktion bestätigt ist und wenn ja wie oft. Eine Bestätigung heißt, dass sie von einem Miner aufgegriffen wurde. Die restlichen Bestätigungen kommen danach recht flott, das heißt dann dass die anderen Miner mit dem ersten Miner einverstanden waren. Wenn die Transaktion nicht innerhalb von ein paar Tagen einmal bestätigt wird, wird sie von dem Bitcoin-Netzwerk wieder vergessen. Dann kann der Sender sie mit erhöhter Gebühr nochmal senden. Er sollte aber darauf achten die selben Coins auszugeben, sonst werden womöglich beide Transaktionen bestätigt, falls doch noch jemand die alte Transaktion hatte.

Naja, die 0.10.x miner sollten ja auch schon 95 % erreicht haben, sonst wäre ja BIP66 nicht verpflichtend geworden. Allerdings vertrauen einige dieser Miner blind anderen, wenn diese einen neueren Block haben, selbst wenn deren eigener full node den Block abgelehnt hat. Dadurch haben sie das Problem erst verursacht. Bei den meisten SPV clients tritt das Problem wohl schon auf, wenn *einer* der verbunden full nodes 0.9.4 oder älter ist, da sie immer dem full node mit der längsten Chain vertrauen. Allerdings ist das Problem insgesamt weniger schlimm als es klingt. Es gab überhaupt erst zwei kurze Zeitintervalle wo es einen Unterschied machte und wahrscheinlich gab es noch nicht einmal eine einzige nur einseitig bestätigte Transaktion. Die vernünftig arbeitenden Miner sollten jetzt wieder die klare Mehrheit haben, seit antpool und f2pool aktualisiert wurden.

Wenn man es noch haltbarer als Papier haben möchte: https://cryptosteel.com/ Eine Stahlwallet für einen private key, BIP38 key oder BIP39 seed. Die sind allerdings noch in der pre-order-Phase und werden wohl ihren ursprünglichen Zeitplan nicht einhalten können. Näheres unter Updates auf der indiegogo-Seite.

Da bereits aus dem Public Key der private Key nicht so leicht berechnet werden kann, kann man beim Versuch eine sichere Paperwallet offline zu berechnen die verbleibenden Schritte auch auf einen unsicheren Computer ausführen. "Nicht so leicht" ist ein Euphemismus; es ist relativ einfach die public keys von ein paar Adressen nachzuschlagen, die über 1000 Bitcoin enthalten, trotzdem hat noch niemand den zugehörigen private key geknackt. Also muss man nur diesen ersten Schritt per Hand machen. Allerdings ist dieser erste Schritt der aufwändigste. Auf meinem Trezor braucht er 37 ms bei 120 MHz. Also 4,5 Millionen Takte. Der Prozessor braucht nur wenige Takte um zwei neunstellige-Zahlen zu addieren, also brauchst du per Hand wahrscheinlich mindestens einige Millionen Sekunden für die Berechnung. Das sind ein paar Wochen. Insgesamt musst du etwa 1000 Multiplikationen von 77-stelligen Zahlen durchführen.

Hmm, man kann zwei Public keys aus einem Private Key erstellen, einen komprimierten und einen unkomprimierten. Im Grunde ist es aber derselbe Key, er hat nur einen anderen Hash und damit eine andere Adresse. Allerdings ist in der Base58-Darstellung des private keys schon kodiert, ob der public key komprimiert oder unkomprimiert werden soll. Sprich jeder wohlgeformte Base58-kodierte Private Key hat genau eine zugehörige Bitcoinadresse. Public Key = private-key * G, wobei G ein fester Punkt auf der elliptischen Kurve ist und * eine Multiplikation insbesondere eine Operation die für die gleichen Eingaben immer das gleiche Ergebnis liefert. Da es aber viel mehr private keys als Adressen gibt, folgt umgekehrt, dass jede Adressen mehrere Private Keys hat. Das ist aber eher theoretisch; praktisch ist es sehr aufwändig zwei private keys mit der gleichen Adresse zu generieren (und es würde auch nichts bringen, man kann das Geld trotzdem nur einmal ausgeben).

Meiner Meinung gibt es keine alternative zur Erhöhung der Blockgröße. Mike Hearn hat in seinem Blog auch schön ausgeführt, was passiert, wenn wir damit bis auf den letzten Drücker warten. Wenn die Blöcke annähernd voll sind, werden Transaktionen Stunden brauchen um akzeptiert zu werden (und Mininggebühren helfen nicht, denn die anderen zahlen ja auch die Gebühren). Schlimmer noch, es wird zu Abstürzen in den Bitcoin-Nodes kommen, weil der Mempool (die nicht bestätigten Transaktionen) überläuft. Eventuell wird es dann ein paar "Spammer" (Fountains, oder täglich in Kleinstmengen auszahlende Miningservices) weniger geben. Aber der Bitcoin könnte durch die langsamen Bestätigungszeiten und häufigeren Ausfällen (wegen mempool-Überlauf) einen größeren Schaden nehmen. Es ist ja jetzt schon knapp. Der nicht kontroverse soft-fork BIP66 läuft seit 3 Monaten und ist noch weit davon entfernt aktiviert zu werden, weil noch zu wenige Miner upgedated haben. Dann wird der Blockgrößen-hard-fork bestimmt ein halbes bis ein Jahr brauchen um aktiviert zu werden und er muss ja noch geschrieben werden. Wer weiß wie viele Transaktionen es in einem Jahr geben wird? Das Argument mit den höheren Mininggebühren verstehe ich wirklich nicht. Wenn man künstlich das Netzwerk auf 4 Transaktionen pro Sekunde hält, wie sollen dann die Miner auf Dauer ihre 800.000 $ pro Tag erhalten, die sie im Moment (dank der "Subvention" von 25 BTC pro Block) bekommen? Will man wirklich mehr als 2 $ pro Überweisung verlangen? Warum sollten die Leute dann noch Bitcoin benutzen? Mehr Mininggebühren können die Miner nur bekommen, wenn es mehr Transaktionen gibt. Der Vorschlag von Gavin ist sinnvoll: 20 MB jetzt und Verdopplung alle zwei Jahre ab dem 1. März 2016. Man kann über die genaue Umsetzung streiten, aber eigentlich haben wir dafür keine Zeit mehr. Es ist ja auch nicht so, dass die Blöcke so groß werden müssen. Die Miner können selbstverständlich ihre eigenen kleineren Limits für ihre Blöcke setzen. Update: Ich sehe gerade, dass die Verdopplung alle zwei Jahre inzwischen vom Tisch ist, weil es da wohl Bedenken gab. Etwas schade, weil wir dann in ein paar Jahren oder Jahrzehnten wieder einen hard-fork brauchen.

Es geht z.B. mit https://bip32jp.github.io/english/index.html oder mit https://dcpos.github.io/bip39/ Bei der ersten gibt es einen Eintrag für Trezor und man kann sich eine Adresse anzeigen lassen. Bei der zweiten Seite muss man auf BIP44 gehen (TREZOR benutzt BIP44) und hat dann unten auf der Seite eine Liste von public/private key. Man kann noch zwischen normalen und change-Adressen wechseln, oder einen anderen Account wählen. Sowas sollte man natürlich nur im Notfall benutzen oder mit einem dummy-Account testen. Die Seite sendet zwar nichts an den Server, aber seid ihr sicher, dass ihr keinen Keylogger auf dem Rechner habt oder der Autor der Seite von heute auf morgen sie doch so ändert, dass alle Keys an ihn gesendet werden? Rein theoretisch müsste man sich die Seite auch speichern und dann offline nutzen können.

Wer es noch nicht mitbekommen hat: Es gab in den letzten zwei Tagen heftige Kritik, weil die Trezor-Entwickler die Firmware unter eine restriktivere Lizenz gestellt hatten. Grund war ein chinesesischer Klon, der eigene Hardware billig verkauft und dafür die Firmware, und die Webseite mit minimalen Anpassungen übernommen hat (was die LGPL ja erlaubt). Die Lizenzänderung hatte zu heftigen Protesten auf reddit geführt, zumal sie durch einen forced-commit auch noch so ausgesehen hat, als wäre sie im August passiert. Die Kritik haben sich die Entwickler zu Herzen genommen und sind komplett zurückgerudert. Trezor-Firmware ist also immer noch/wieder unter LGPLv3. http://satoshilabs.com/news/2015-01-30-trezor-software-license/ Wer schon immer einen Trezor haben wollte, bisher aber vom Preis abgeschreckt ist, kann ihn jetzt (vermutlich nur für kurze Zeit) deutlich günstiger bekommen. Einfach dem Link "buying a Trezor device" auf der obigen Seite folgen. Der Preisnachlass wird erst bei der Bestellung angezeigt (nachdem man auf "buy now" geklickt hat).

Okay, ich habe tatsächlich die neueste Version von Electrum mit Trezor support. Wenn also electrum 2.0 released wird, sollte es funktionieren. Man kann übrigens aus dem Private Key den Public Key berechnen, z.B. mit brainwallet.org. Ob man allerdings auf einer Webseite den Private Key eingeben will, muss man selber wissen, auch wenn die Seite den Key nicht zum Server schicken sollte. Für die Blockchain-Wallet funktioniert es wie du gesagt hast, der Key erscheint dann in einem Popup. Es geht aber auch über die Blockchain.info-Seite für alle Keys, die jemals in einer Transaktion verwendet wurden, z.B. https://blockchain.info/de/tx/dddb6fea42b7345ecc4840bf3dddad131c4fa2b38fc7932df62d871e34fe71af?show_adv=true Also auf eine beliebige Transaktion gehen, die den Key als Input benutzt, dort eventuell "Scripts & coinbase anzeigen" wählen. Die obige Seite zeigt eine Transaktion mit der zufällig gewählten Adresse 19V2LMtcffnjkxjxiR77G58QEEWwMM5mc8. Ganz unten auf der Seite stehen dann die Eingangs- und Ausgangs-Skripte. Die Eingangsskripte enthalten gewöhnlich für jeden Eingang die digitale Unterschrift (304x022...) und den Public Key (02/03/04...). In dem Fall war der Public Key 0260aa6173a0e6b4acf7cf2dadd8f613c4b2e457c5bf4378a0f29026fd71210271.

Der Public Key hat die Form 04 gefolgt von 128 Hex-Zeichen oder 02 oder 03 gefolgt von 64 Hex-Zeichen. Die Adresse ist nur der Hash des Public Key, das ist also nicht ganz dasselbe. Aus der Adresse lässt sich der Public Key nicht ableiten, da die Hashfunktion nicht invertierbar ist. Electrum kann (zumindest in meiner recht neuen selbstkompilierten Version) den Public Key anzeigen: Adress-Tab wählen, dort die Adresse wählen, rechter Mausklick und öffentlicher Schlüssel (bzw. public key) wählen. Mit Blockchain sollte es so gehen wie im Originalposting beschrieben. Was war denn das Problem bzw. die Lösung?

Wenn du deine eigenen Skripte über die Blockchain laufen lassen willst, um irgendwelche Statistiken zu erzeugen oder eine Liste aller Bitcoinadressen zu erzeugen, dann ist es praktisch die Blockchain zu haben. Für den Enduser ist es aber unnötig und bereits jetzt ziemlich unpraktisch. In der Zukunft wird es wahrscheinlich eher schwieriger die gesamte Blockchain zu synchronisieren. Es bringt einen kleinen Sicherheitsvorteil, da du dann sämtliche Transaktionen auf Korrektheit überprüfst und so absolut sichergehen kannst, dass die Überweisung, die du siehst, auch authentisch ist. Das ist aber sehr hypothetisch, da sind Double-Spent-Attacken realistischer. Gegen letztere hilft auch bitcoin-qt nicht. Der Schlüssel zu deinen Bitcoins liegt bei beiden Programmen verschlüsselt auf deinem lokalen Rechner und wird nie ins Internet übertragen. Die Bitcoins sind also auch bei multibit voll unter deiner Kontrolle. Und multibit verbindet sich auch mit mehreren Rechnern und die Daten sind kryptographisch gegen Manipulationen gesichert. Das Bitcoinnetzwerk hat im Moment genügend full clients, sodass es kein Problem ist, wenn jeder Enduser zu einem SPV-Client wie multibit greift. Solange Zahlungsdienstleiter, Börsenbetreiber, Miningpoolbetreiber, etc. weiterhin full clients benutzen.

Wie ja im ersten Posting schon richtig beschrieben, ist im Moment die Vergütung pro Transaktion viel zu hoch (0,07 BTC pro Transaktion, was ja seit heute Morgen "nur" noch 25 EUR pro Transaktion sind). Im Moment wird das durch die neugeschöpften Bitcoins getragen und der Tatsache, dass die Bitcoins so viel wert geworden sind. Aber auf Dauer kann sich das so nicht halten. Es werden wohl zwei Dinge passieren, 1. die Blockchain wird wohl noch deutlich wachsen, vor allem, wenn Bitcoin in Konkurrenz zu anderen Zahlungsdienstleistern treten will, und 2. die Miningvergütung wird wieder abnehmen. Wenn die Miningvergütung abnimmt, lohnen sich eventuell die ASIC-Miner der ersten Generation von den Stromkosten nicht mehr, und würden billig zu haben sein, aber die haben ja eh nur einen Bruchteil der Gesamt-Hashingleistung; da sollten keiner durch große Aufkäufe in die Nähe von 50 % kommen. Die Miner der letzten Generation sollten sich wohl hoffentlich so einpendeln, dass die Miningvergütung zu den Stromkosten und Hardwarekosten (durch Hardwareausfälle) passt. Das ist allerdings Spekulation; da wird sich noch zeigen müssen ob das System der ungeregelten Marktwirtschaft funktionieren kann. Wenn die Blockchain wächst (ich gehe mal grob von 100 GB pro Jahr in ein paar Jahren aus), wird wohl kaum noch ein Bitcoinnutzer einen Fullclient installieren, da er nicht ein halbes Terrabyte downloaden möchte, bevor er loslegen kann. Allerdings ist im Whitepaper dieses Szenario schon erwähnt. Die normalen Nutzer benutzen SPV-Clients, die den Minern vertrauen, die Miner (oder besser gesagt, die Miningpools) dagegen Fullclients, um sich gegenseitig zu kontrollieren. Die Dezentralität ist dann durch die Menge der Miningpools gegeben. Ich beobachte aber im Moment auch ein wenig mit Sorge die Größe der Miningpools. Die beiden größten könnten im Moment eine 51 % Attacke fahren. Ich denke Satoshi hatte wohl eher ein Szenario im Kopf, wo es etwa 100 gleichgroße Miner gibt (Miningpools wurden ja erst später erfunden). Dadurch wäre die Dezentralität dann gegeben. Im Grunde gibt es auch kein Argument, warum man sich unbedingt einem großen Miningpool anschließen sollte. Solange ein Pool groß genug ist, einen Block pro Tag zu finden, sollte ein kleiner Pool keine Nachteile haben. Es braucht auch nicht viele Resourcen um einen neuen Miningpool zu starten; ein Server mit guter Netzanbindung und ausreichen Plattenplatz und Hauptspeicher sollte reichen. Okay, man braucht auch eine Menge Know-How und natürlich ein paar User, die ihre Mining-ASICs zur Verfügung stellen.