Search content
Sort by
Showing 19 of 19 results by Wolf
@Igotcha:
Im Gegensatz zu dir sehe ich Bitcoin nicht nur als Bargeldersatz, sondern als universelles und grenzenloses Zahlungssystem. Es sollte eine Alternative für Bargeldzahlungen, Banküberweisungen und Wertanlage sein. In diesem Sinne muss dann aber auch ein Bitcoin Client universell und mit allem nötigen Funktionsumfang ausgestattet und für "Dummy Benutzer" handhabbar sein. Nur so kann man die "Massen" gewinnen und die Akzeptanz erhöhen.
Ich habe alle Hochachtung vor den Entwicklern von Open Source Lösungen, die der Gemeinschaft viel Arbeit und Fachwissen unentgeltlich zur Verfügung stellen. Aber ich meine auch, dass langsam die Zeit gekommen ist, wo Benutzerfreundlichkeit, umfassende Funktionalität, ansprechendes Design und durchdachte Menüführung mehr Beachtung geschenkt werden muss. Anderenfalls bleiben wir in der Phase des Proof-of-concept stecken. In der Vergangenheit habe ich massenhaft solche Projekte nach anfänglichem Hype wieder in der Bedeutungslosigkeit verschwinden sehen, weil sich einfach niemand die Mühe gemacht hat, eine gute technische Lösung für den "normalen Benutzer" anzupassen und zu Ende zu entwickeln.
Im Gegensatz zu dir sehe ich Bitcoin nicht nur als Bargeldersatz, sondern als universelles und grenzenloses Zahlungssystem. Es sollte eine Alternative für Bargeldzahlungen, Banküberweisungen und Wertanlage sein. In diesem Sinne muss dann aber auch ein Bitcoin Client universell und mit allem nötigen Funktionsumfang ausgestattet und für "Dummy Benutzer" handhabbar sein. Nur so kann man die "Massen" gewinnen und die Akzeptanz erhöhen.
Ich habe alle Hochachtung vor den Entwicklern von Open Source Lösungen, die der Gemeinschaft viel Arbeit und Fachwissen unentgeltlich zur Verfügung stellen. Aber ich meine auch, dass langsam die Zeit gekommen ist, wo Benutzerfreundlichkeit, umfassende Funktionalität, ansprechendes Design und durchdachte Menüführung mehr Beachtung geschenkt werden muss. Anderenfalls bleiben wir in der Phase des Proof-of-concept stecken. In der Vergangenheit habe ich massenhaft solche Projekte nach anfänglichem Hype wieder in der Bedeutungslosigkeit verschwinden sehen, weil sich einfach niemand die Mühe gemacht hat, eine gute technische Lösung für den "normalen Benutzer" anzupassen und zu Ende zu entwickeln.
Abgesehen davon, dass die Kunden von SilkRoad und meine Oma (der Herr hab sie seelig) wenig gemeinsam haben.
Ich sehe den bitcoin-qt mehr als proof-of-concept denn als durchdachte, bedienerfreundliche und (für Nur-Benutzer) verständliche Applikation.
Um Akzeptanz für Bitcoin zu erzeugen reicht es nicht, täglich ein paar neue Internetangebote aufzulisten, die Bitcoin akzeptieren. Es braucht eine Lösung, die alle Bezahlvorgänge ermöglicht (wenn gewünscht auch mit sicherem Beleg), die mindestens so einfach und durchschaubar ist, wie die Brieftasche zu öffnen und einen Schein auf den Tisch zu legen. Wenns dann auch noch sicherer und billiger ist, als eine Banküberweisung, wird es von der breiten Masse akzeptiert werden.
Wir lassen den Thread jetzt einfach mal laufen und schauen, was es dazu noch für andere Meinungen gibt.
Ich sehe den bitcoin-qt mehr als proof-of-concept denn als durchdachte, bedienerfreundliche und (für Nur-Benutzer) verständliche Applikation.
Um Akzeptanz für Bitcoin zu erzeugen reicht es nicht, täglich ein paar neue Internetangebote aufzulisten, die Bitcoin akzeptieren. Es braucht eine Lösung, die alle Bezahlvorgänge ermöglicht (wenn gewünscht auch mit sicherem Beleg), die mindestens so einfach und durchschaubar ist, wie die Brieftasche zu öffnen und einen Schein auf den Tisch zu legen. Wenns dann auch noch sicherer und billiger ist, als eine Banküberweisung, wird es von der breiten Masse akzeptiert werden.
Wir lassen den Thread jetzt einfach mal laufen und schauen, was es dazu noch für andere Meinungen gibt.
Ich wollte jetzt auch nicht den bitcoin-qt über den Haufen werfen. Mir geht es darum, die Funktionalität zur Diskussion zu stellen. Grundsätzlich glaube ich, die Akzeptanz einer technischen Lösung (egal ob Bitcoin oder was anderes) hängt wesentlich davon ab, ob man rechtzeitig den "unbedarften" Benutzern ein durchschaubares Handling bietet. Wir wollen doch keine abgehobene Kleingruppe von Bitcoin- Enthusiasten bleiben.
Ich bin schon lange im IT-Geschäft (fast 40 Jahre). Ich habe zugesehen, wie UNIX/Linux wegen ihrer abgehobenen Fangemeinde von Techis keinen Fuß auf den Boden bekommen haben, während andere (M$, Apple) mit "idiotensicheren" Systemen den Markt erobert haben. (Das soll keine Bewertung irgendeines Betriebssystem sein!).
Ich fürchte momentan einfach, dass das mit Bitcoin auch so gehen könnte, weil keiner sich aufrafft, mal einen Client benutzerfreundlich und logisch/verständlich zu Ende zu entwickeln.
Ich bin schon lange im IT-Geschäft (fast 40 Jahre). Ich habe zugesehen, wie UNIX/Linux wegen ihrer abgehobenen Fangemeinde von Techis keinen Fuß auf den Boden bekommen haben, während andere (M$, Apple) mit "idiotensicheren" Systemen den Markt erobert haben. (Das soll keine Bewertung irgendeines Betriebssystem sein!).
Ich fürchte momentan einfach, dass das mit Bitcoin auch so gehen könnte, weil keiner sich aufrafft, mal einen Client benutzerfreundlich und logisch/verständlich zu Ende zu entwickeln.
Stell Dir einfach mal meine Oma vor. Die kann vielleicht noch bezahlen. Aber was weiß die denn von einer Trasaktions-ID? Die braucht einen Beleg, wo draufsteht, ich habe an diese Adresse soundsoviel bezahlt. Wenns einer nicht glaubt, kann ich das hier beweisen.
Ich stelle mir einfach einen Benutzer vor, der gerne einen Zahlungsbeleg hätte, ohne gleich seinen Bitcoin-Client vorzeigen zu müssen. Dem außerdem die (meiner Meinung nach viel zu rudimentäre) Signaturfunktion des Client zu undurchsichtig und kompliziert ist.
Zu kompliziert? Für den Programmierer vielleicht, aber nicht für den Anwender. Und die wollen wir doch, oder?
Zur Notwendigkeit empfehle ich diesen Thread:
https://bitcointalk.org/index.php?topic=187663.0
Der hat mich auf die Idee gebracht.
Zur Notwendigkeit empfehle ich diesen Thread:
https://bitcointalk.org/index.php?topic=187663.0
Der hat mich auf die Idee gebracht.
Ausgangssituation: Ein "Nomalbenutzer" (kein Techi) will als Zahlungsabsender eine Zahlung an eine öffentlich bekannte Bitcoin Adresse tätigen. So eine Adresse könnte z.B. ein Spendenkonto, ein Gruppenkauf, ein Zugang zu einem Informationsangebot (Micropayment) oder ein anderes Angebot im Netz sein, bei dem er vom Verkäufer/Anbieter keine individuelle Zahlungsadresse erhalten hat. Der Zahlungsabsender möchte beweisen können, dass er die Zahlung getätigt hat. Dem Anbieter soll es möglich sein, die Zahlung einer Person (dem Zahlungsabsender) zuzuordnen, z.B. um das Angebot freizuschalten, eine Spendenquittung auszustellen, die Ware zu liefern oder dergleichen.
Bisher habe ich nur die Möglichkeit gefunden, die Zahlung in der Blockchain zu lokalisieren, dann eine Nachricht an den Anbieter mit der Absenderadresse der Zahlung zu signieren und dem Anbieter diese Information zu senden (z.B. per E-Mail). Der Anbieter prüft die Signatur und findet die Transaktion an Hand der Transaktions-ID in seinem Zahlungseingang bzw. in der Blockchain.
Dieses Verfahren ist weder dem Käufer noch dem Anbieter wirklich zuzumuten. Es erfordert viel zuviel Kenntnisse über die Details einer Bitcoin Transaktion und ist viel zu fehleranfällig.
Lösungsvorschlag (z.B. beim bitcoin-qt client):
1. beim Zahlungsabsender (Ausgabe eines Zahlungsbelegs):
- nach erfolgter Zahlung wählt er aus seiner Transaktionsliste die betreffende Zahlung aus,
- der Bitcoin Client kennt die Trandaktions-ID, den Zahlbetrag, die Empfangsadresse und die Adresse, von der gesendet wurde,
- der Bitcoin Client bietet einen Dialog an, in dem diese Werte schon enthalten sind und ermöglicht in einem Textfeld die Eingabe weiterer Informationen (Lieferadresse, Zahlungsgrund, oder was auch sonst noch gewünscht ist),
- in diesem Dialog könnten vier Button/Menüeinträge zur Verfügung stehen:
a. "Zahlbeleg signieren" -- die gesamte Nachricht wird mit dem zur Absenderadresse gehörenden privaten Schlüssel signiert und die Signatur der Nachricht hinzugefügt,
b. "Zahlbeleg unverschlüsselt drucken" -- es wird ein entsprechender Beleg gedruckt,
c. "Zahlbeleg verschlüsseln" -- die signierte Nachricht wird mit der Empfangsadresse verschlüsselt,
b. "Zahlbeleg senden" mit entsprechenden Untermenüs:
I. "per Mail senden" -- es wird eine E-Mail generiert, in die noch der Empfänger eingetragen werden muss, bevor sie versendet wird,
II. "QR-Code erzeugen" -- der Zahlungsabsender entscheidet, wie er dem Anbieter den QR-Code zustellt (drucken und per Post senden oder was auch immer),
III. "in Zwischenablage kopieren" -- die verschlüsselte und signierte Nachricht kommt in die Zwischenablage und wird von dort aus vom Zahlungsabsender beliebig weiter verwendet.
2. beim Zahlungsenmpfänger (Zuordnung eines Zahlungsbelegs):
- er erhält vom Zahlungsabsender die Nachricht und liest sie in den Bitcoin-Client ein (z.B. QR-Code, Zwischenablage),
- der Bitcoin-Client versucht die Nachricht zu entschlüsseln indem er nacheinander seine geheimen Schlüssel anwendet,
- gelingt das, überprüft er seine Transaktionsliste, ob die angegebene Transaktion eingegangen ist und prüft die Signatur der Nachricht,
- ist die Signatur gültig, zeigt er dem Zahlungsenmpfänger die vollständige Nachricht einschl. einer Bestätigung der Gültigkeit an,
- außerdem ermöglicht er, die gesamte Nachricht in die Zwischenablage zu kopieren, damit sie weiter verarbeitet werden kann.
Nach meiner Ansicht hat der Bitcoin-Client jeweils alle Informationen (Adressen, Schlüssel, Transaktions-ID, Zahlbetrag) die er benötigt. Damit könnte der Vorgang auf beiden Seiten "narrensicher" automatisiert werden.
Was sagt Ihr dazu? Könnte das gehen?
Bisher habe ich nur die Möglichkeit gefunden, die Zahlung in der Blockchain zu lokalisieren, dann eine Nachricht an den Anbieter mit der Absenderadresse der Zahlung zu signieren und dem Anbieter diese Information zu senden (z.B. per E-Mail). Der Anbieter prüft die Signatur und findet die Transaktion an Hand der Transaktions-ID in seinem Zahlungseingang bzw. in der Blockchain.
Dieses Verfahren ist weder dem Käufer noch dem Anbieter wirklich zuzumuten. Es erfordert viel zuviel Kenntnisse über die Details einer Bitcoin Transaktion und ist viel zu fehleranfällig.
Lösungsvorschlag (z.B. beim bitcoin-qt client):
1. beim Zahlungsabsender (Ausgabe eines Zahlungsbelegs):
- nach erfolgter Zahlung wählt er aus seiner Transaktionsliste die betreffende Zahlung aus,
- der Bitcoin Client kennt die Trandaktions-ID, den Zahlbetrag, die Empfangsadresse und die Adresse, von der gesendet wurde,
- der Bitcoin Client bietet einen Dialog an, in dem diese Werte schon enthalten sind und ermöglicht in einem Textfeld die Eingabe weiterer Informationen (Lieferadresse, Zahlungsgrund, oder was auch sonst noch gewünscht ist),
- in diesem Dialog könnten vier Button/Menüeinträge zur Verfügung stehen:
a. "Zahlbeleg signieren" -- die gesamte Nachricht wird mit dem zur Absenderadresse gehörenden privaten Schlüssel signiert und die Signatur der Nachricht hinzugefügt,
b. "Zahlbeleg unverschlüsselt drucken" -- es wird ein entsprechender Beleg gedruckt,
c. "Zahlbeleg verschlüsseln" -- die signierte Nachricht wird mit der Empfangsadresse verschlüsselt,
b. "Zahlbeleg senden" mit entsprechenden Untermenüs:
I. "per Mail senden" -- es wird eine E-Mail generiert, in die noch der Empfänger eingetragen werden muss, bevor sie versendet wird,
II. "QR-Code erzeugen" -- der Zahlungsabsender entscheidet, wie er dem Anbieter den QR-Code zustellt (drucken und per Post senden oder was auch immer),
III. "in Zwischenablage kopieren" -- die verschlüsselte und signierte Nachricht kommt in die Zwischenablage und wird von dort aus vom Zahlungsabsender beliebig weiter verwendet.
2. beim Zahlungsenmpfänger (Zuordnung eines Zahlungsbelegs):
- er erhält vom Zahlungsabsender die Nachricht und liest sie in den Bitcoin-Client ein (z.B. QR-Code, Zwischenablage),
- der Bitcoin-Client versucht die Nachricht zu entschlüsseln indem er nacheinander seine geheimen Schlüssel anwendet,
- gelingt das, überprüft er seine Transaktionsliste, ob die angegebene Transaktion eingegangen ist und prüft die Signatur der Nachricht,
- ist die Signatur gültig, zeigt er dem Zahlungsenmpfänger die vollständige Nachricht einschl. einer Bestätigung der Gültigkeit an,
- außerdem ermöglicht er, die gesamte Nachricht in die Zwischenablage zu kopieren, damit sie weiter verarbeitet werden kann.
Nach meiner Ansicht hat der Bitcoin-Client jeweils alle Informationen (Adressen, Schlüssel, Transaktions-ID, Zahlbetrag) die er benötigt. Damit könnte der Vorgang auf beiden Seiten "narrensicher" automatisiert werden.
Was sagt Ihr dazu? Könnte das gehen?
What is your username on the Linux machine. You should change "miner" to your login in this line: tar xf /home/miner/AMD-APP-SDK-v2.8-lnx64.tgz in case your name is not "miner".
@antares
Vielen Dank. Ich fasse mal zusammen:
- Über den Blockexplorer kann man das Guthaben einer Adresse feststellen, aber nicht das Guthaben eines Wallet;
- Man signiert mit dem Private Key und prüft die Signatur mit dem Public Key = Bitcoin-Adresse;
- Wozu man signiert und wie man die Signatur prüft geht aus dem bitcoin-qt noch nicht eindeutig hervor;
- Der Bitcoin-qt client ist diesbezüglich noch nicht ganz fertig/verständlich/für Benutzer verwendbar (das wird sicher noch ;-)
Und nun noch eine Annahme von mir (bitte sofort widersprechen, falls es nicht stimmt):
Ein Wallet hat nur einen Private Key aus dem beliebig viele Public Keys = Adressen abgeleitet werden können. Somit wäre es gleichgültig, mit welcher der betreffenden Adressen die Signatur geprüft wird.
Wenn das stimmt, ist die Anordnung der Funktion "Nachricht signieren" innerhalb des Menüs "Bitcoins empfangen" mit Auswahl einer Adresse unlogisch/irreführend.
Vielen Dank. Ich fasse mal zusammen:
- Über den Blockexplorer kann man das Guthaben einer Adresse feststellen, aber nicht das Guthaben eines Wallet;
- Man signiert mit dem Private Key und prüft die Signatur mit dem Public Key = Bitcoin-Adresse;
- Wozu man signiert und wie man die Signatur prüft geht aus dem bitcoin-qt noch nicht eindeutig hervor;
- Der Bitcoin-qt client ist diesbezüglich noch nicht ganz fertig/verständlich/für Benutzer verwendbar (das wird sicher noch ;-)
Und nun noch eine Annahme von mir (bitte sofort widersprechen, falls es nicht stimmt):
Ein Wallet hat nur einen Private Key aus dem beliebig viele Public Keys = Adressen abgeleitet werden können. Somit wäre es gleichgültig, mit welcher der betreffenden Adressen die Signatur geprüft wird.
Wenn das stimmt, ist die Anordnung der Funktion "Nachricht signieren" innerhalb des Menüs "Bitcoins empfangen" mit Auswahl einer Adresse unlogisch/irreführend.
> Dann kannst du eine Nachricht wie zBsp "Ich, Vorname Nachname habe 100 BTC an die Adresse 1abc... überwiesen" erstellen und mit einer Absenderadresse der entsprechenden Transaktion signieren.
Auch das ist mir unklar! Ich bekomme in meinem Client z.B. den Button "Nachricht signieren" nur im Menü "Bitcoins empfangen". Da sind natürlich gar keine Absenderadressen drin?!?!
Es scheint mir also eher so zu sein, dass ich einem eventuellen Absender von Bitcoins "beweisen" kann, dass die Adresse, an die er senden soll tatsächlich mir gehört und diese nicht durch einen eventuellen Angreifer bei der Übermittlung auf dessen Empfangsadresse geändert wurde.
Und überhaupt: Was wird denn dabei eigentlich signiert? Die Adresse, die ich dabei ausgewählt habe, oder die Nachricht im Nachrichtenfeld, oder beides??? Oder wird die ausgewählte Adresse zum Signieren der Nachricht verwendet? Glaube ich eher nicht. Es macht offensichtlich nur Sinn, die Nachricht mit dem geheimen Schlüssel zu signieren. Davon gibt es aber in einem Wallet nach meinem Verständnis nur einen; warum also zum Signieren eine Empfangsadresse auswählen?
Kopfkraz!!!
Auch das ist mir unklar! Ich bekomme in meinem Client z.B. den Button "Nachricht signieren" nur im Menü "Bitcoins empfangen". Da sind natürlich gar keine Absenderadressen drin?!?!
Es scheint mir also eher so zu sein, dass ich einem eventuellen Absender von Bitcoins "beweisen" kann, dass die Adresse, an die er senden soll tatsächlich mir gehört und diese nicht durch einen eventuellen Angreifer bei der Übermittlung auf dessen Empfangsadresse geändert wurde.
Und überhaupt: Was wird denn dabei eigentlich signiert? Die Adresse, die ich dabei ausgewählt habe, oder die Nachricht im Nachrichtenfeld, oder beides??? Oder wird die ausgewählte Adresse zum Signieren der Nachricht verwendet? Glaube ich eher nicht. Es macht offensichtlich nur Sinn, die Nachricht mit dem geheimen Schlüssel zu signieren. Davon gibt es aber in einem Wallet nach meinem Verständnis nur einen; warum also zum Signieren eine Empfangsadresse auswählen?
Kopfkraz!!!
> Nun kann A die signatur verifizieren, und zb im Blockexplorer nachschlagen, dass die Addresse von B tatsächlich die coins enthält.
Kannst du das bitte nochmal genauer erklären? Für mich liest sich das so, als könne man anhand der Signatur über den Blockexplorer ermitteln, wie viele Bitcoins der Betreffende (B) in seinem Wallet hat.
Kannst du das bitte nochmal genauer erklären? Für mich liest sich das so, als könne man anhand der Signatur über den Blockexplorer ermitteln, wie viele Bitcoins der Betreffende (B) in seinem Wallet hat.
Ich habe das mit dem Signieren einer Nachricht (bitcoin-qt) noch nicht verstanden. Ich finde es auch völlig unzureichend erklärt im Client.
Also ich kann eine Empfangs-Adresse auswählen, dort eine Nachricht hinzufügen und das dann signieren. Ja und dann???
Was mache ich mit der "Nachricht". Wer bekommt die? Wie kann er diese Signatur überprüfen? Wie bekomme ich diese Nachricht überhaupt zu einem möglichen Empfänger?
Ich könnte mir vorstellen, dass ich die Adresse, die Nachricht und die Signatur einzeln in eine E-Mail kopieren und dann an jemand senden soll, von dem ich Bitcoins erwarte. Aber wenn das so ist, warum kann ich dann nicht alles zusammen in die Zwischenablage kopieren? Das scheint mir noch völlig unausgegoren zu sein. Oder verstehe ich da etwas falsch?
Und was soll die Warnung bedeuten, dass man "nicht ungewollt" etwas signieren soll?? Was könnte das denn sein?
Also ich kann eine Empfangs-Adresse auswählen, dort eine Nachricht hinzufügen und das dann signieren. Ja und dann???
Was mache ich mit der "Nachricht". Wer bekommt die? Wie kann er diese Signatur überprüfen? Wie bekomme ich diese Nachricht überhaupt zu einem möglichen Empfänger?
Ich könnte mir vorstellen, dass ich die Adresse, die Nachricht und die Signatur einzeln in eine E-Mail kopieren und dann an jemand senden soll, von dem ich Bitcoins erwarte. Aber wenn das so ist, warum kann ich dann nicht alles zusammen in die Zwischenablage kopieren? Das scheint mir noch völlig unausgegoren zu sein. Oder verstehe ich da etwas falsch?
Und was soll die Warnung bedeuten, dass man "nicht ungewollt" etwas signieren soll?? Was könnte das denn sein?
Hallo,
ich spiele gerade ein bisschen mit dem electrum thin client (https://bitcointalk.org/index.php?topic=50936.0). Bisher habe ich einen Client auf einer VM und einen Server auf einer anderen VM funktionierend am laufen. Außerdem läuft ein Tor-Relay in einer dritten VM. Mein Ziel ist es, den electrum server als tor hidden service einzurichten und dann vom electrum client darauf zu verbinden. Leider ist es mir bisher nicht gelungen, dem electrum client beizubringen, wie er sich über einen socks proxy (tor) zum server verbinden kann. Kann mir jemand sagen, wo man das evtl. einstellen kann oder ob es da einen Patch für den client gibt?
ich spiele gerade ein bisschen mit dem electrum thin client (https://bitcointalk.org/index.php?topic=50936.0). Bisher habe ich einen Client auf einer VM und einen Server auf einer anderen VM funktionierend am laufen. Außerdem läuft ein Tor-Relay in einer dritten VM. Mein Ziel ist es, den electrum server als tor hidden service einzurichten und dann vom electrum client darauf zu verbinden. Leider ist es mir bisher nicht gelungen, dem electrum client beizubringen, wie er sich über einen socks proxy (tor) zum server verbinden kann. Kann mir jemand sagen, wo man das evtl. einstellen kann oder ob es da einen Patch für den client gibt?
Zu 1.: OK. Die Bitcoins werden also "aus dem Verkehr" gehen. Dadurch steigt der Wert der verbleibenden BTC. Preise können dann eben im Extremfall mit "Millibitcoins" oder "Mikrobitcoins" angegeben werden.
Aber nochmal zum "Blockketten-Problem": Wie wird den nun sichergestellt, dass bei großer Handelstätigkeit nicht irgendwann einmal sehr speicherintensive Ketten entstehen? Das würde doch dann zu sehr langen Ladezeiten des Clients (zumindest bei der ersten Initialisierung) führen. Ich hatte den folgenden Text so interpretiert, dass ältere Transaktionen gelöscht werden, wenn eine BitCoin ausreichend oft bestätigt wurde. Ich weiß allerdings nicht so genau, was ein "Merkle Tree" ist. Werde da nochmal nachlesen.
---- Zitat aus "Bitcoin: A Peer-to-Peer Electronic Cash System" (Satoshi Nakamoto) ----
7.
Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space. To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.
---- Ende ----
Aber nochmal zum "Blockketten-Problem": Wie wird den nun sichergestellt, dass bei großer Handelstätigkeit nicht irgendwann einmal sehr speicherintensive Ketten entstehen? Das würde doch dann zu sehr langen Ladezeiten des Clients (zumindest bei der ersten Initialisierung) führen. Ich hatte den folgenden Text so interpretiert, dass ältere Transaktionen gelöscht werden, wenn eine BitCoin ausreichend oft bestätigt wurde. Ich weiß allerdings nicht so genau, was ein "Merkle Tree" ist. Werde da nochmal nachlesen.
---- Zitat aus "Bitcoin: A Peer-to-Peer Electronic Cash System" (Satoshi Nakamoto) ----
7.
Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space. To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.
---- Ende ----
Ich glaube, ich habe inzwischen schon einigermaßen verstanden, wie BitCoin funktioniert. Es waren da zunächst einige Fragen aufgetaucht. Z.B. warum die Blockchain nicht unendlich groß wird, wenn sehr viele Transaktionen stattfinden. So wie ich es verstanden habe, werden ältere Transaktionen automatisch gelöscht, wenn sie ausreichend bestätigt/verifiziert sind, sodass nur der initiale Block und die letzten Transaktionen enthalten bleiben. Ist das richtig so?
Aber eine Frage treibt mich immer noch um: Was passiert eigentlich, wenn jemand seine "wallet.dat" komplett verliert (kein Backup hat) mit den darin enthaltenen BitCoins. Er kann sie ja dann nicht mehr ausgeben (und ein anderer auch nicht). Wenn nun irgendwann einmal alle 21 Mio BitCoins "gemined" sind, müssten es dann nicht durch solche Verluste nach und nach immer weniger werden?
Aber eine Frage treibt mich immer noch um: Was passiert eigentlich, wenn jemand seine "wallet.dat" komplett verliert (kein Backup hat) mit den darin enthaltenen BitCoins. Er kann sie ja dann nicht mehr ausgeben (und ein anderer auch nicht). Wenn nun irgendwann einmal alle 21 Mio BitCoins "gemined" sind, müssten es dann nicht durch solche Verluste nach und nach immer weniger werden?