Nun, ein Beitrag zu diesem Thema ist bereits im Bitcoin Genesis Block verewigt. Im Prinzip wurden und werden die Banken unter anderem aus diesem Grund ebenfalls dauerhaft von uns gerettet. Es ist jedem dort klar, dass eine Einlagensicherung selbst bei kleineren Problemen nicht mehr greifen würde. Die üblichen Folgen kann man in ersten Ansätzen in Malta, Griechenland und Indien beobachten. Wobei Indien nur ein kleiner unwichtiger Feldtest ist, dem kein echtes Finanzproblem zugrunde liegt.

Ich kann im Augenblick einen Block verifizieren und die absolute Aussage treffen, dass er korrekt ist. Mit BU kann ich das nicht mehr, da korrekt im Ernstfall nur noch eine relative Aussage bezüglich der aktuellen Gruppierungen mit der jeweils maximalen Blockgrösse ist. Der Markt muss dann aussortieren oder auch nicht, ob es mit mehreren Zweigen weitergeht oder ob bestimmte Zweige sterben.

Die Verifikation wird hier durch die Hoffnung auf vernünftiges Handeln aller Beteiligter ersetzt. Eine zweifelhafte Annahme, die meiner Meinung nach bereits durch die aktuelle Entwicklung wiederlegt wurde.

Wenn aber der Kurs weiterhin am Steigen ist, warum sollte man dann die BTC in EUR wechseln? Ich rede explizit nicht vom Einkaufen. Ich nutze meine BTC selbstverständlich auch zum Einkaufen und profitiere damit auch von einer Wertsteigerung. Ich würde allerdings meine BTC nicht einfach so in EUR umtauschen, wenn ich nicht die EUR dringend sofort benötige.

Das stimmt nicht ganz, da die Knoten auch noch ihre gewünschte und maximal aktzeptierte Blockgrösse mitteilen. Diese Information ist nicht vertrauenswürdig (= kann falsch sein), dient aber als Basis zur Berechnung der maximalen Blockgrösse. BU heisst nicht, dass der Client beliebige Blockgrössen aktzeptiert!

Es gibt keine technische Möglichkeit, auf Basis einer unsicheren Information, sicher eine überall aktzeptierte maximale Blockgrösse zu errechnen!


Nein, das ist bisher eben nicht Bitcoin (s.o.). Bisher basiert Bitcoin auf vollständiger Verifikation und nicht darauf, dass das System erst mal zerfällt (Split) und der Markt danach den Gewinner aussortiert.


BU erlaubt es dem Node-Betreiber eben nicht (ebensowenig wie Core), Relay und Aktzeptanz sauber zu konfigurieren. Die einzige (zusätzliche) Entscheidung, die der Node-Betreiber hat ist die maximal aktzeptierte Blocksize. Ist diese kleiner als der nächste Block, ist er raus. Im Nachgang kann dann der berühmte Markt aussortieren, ob er für immer raus ist oder ob sich eine oder mehrere Mehrheiten finden. Keine guten Voraussetzungen für ein(sic) Geldsystem.

Ich denke nicht, dass der Platrzbedarf ständig steigt, habe es aber nicht überprüft. Nach dem was ich auf dem Smartphone habe, ist die Wallet das geringste Problem. Der grösste Speicherfresser (Flash und RAM) ist bei mir das Navi (OsmAnd), und zwar nicht nur die Offline-Karten selbst.

Ja, lässt sich aber wohl nicht vermeiden. Solange Lücken (egal ob im Systemdesign, Protokoll oder in der Implementierung) da sind, werden diese auch genutzt. Andere Beispiele: "Stresstest", Mempool Exhaustion, Transaction Malleability, ...

Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.

Besser als die Angriffe auf BU Knoten wäre eine Abstimmung mit den vom Bitcoin-Design vorgesehenen Mitteln: Jeder Knoten verifiziert Blöcke und Transaktionen und entscheidet eigenständig über die Aktzeptanz und die Weiterleitung. Das ist die Kernfunktion des System, daher sollte diese Funktion auch genutzt werden.

Die Wallet ist mit CM 13.1 auf das Gerät gekommen, dürfte also etwas älter als ein Jahr sein. Ich habe allerdings regelmässig Updates aufgespielt, sodass gerade die neueste Version läuft. Mit der Wallet habe ich in der Grössenordnung 50-100 Transaktionen durchgeführt.

Ja, wobei ich das als Notlösung sehe, wenn gar nichts anderes mehr geht.


Gibt keins und die Methode ist sicher nicht konsensfähig. Ausserdem sind noch mehr Optionen das allerletzte was man gerade benötigt. Es liegen genug ernsthafte Optionen auf dem Tisch (segwit, 2-8MB Hard-Fork), die die aktuellen Probleme lösen, teilweise sehr gut getestet wurden, kein grosses Risiko bringen und die Arbeitsteilung / das Systemverhalten nicht ändern.

Was genau an Metadate abgelegt wird weiss ich nicht, aber viel kann es nicht sein. Meine Wallet benötigt aktuell ca. 15MB Flash und 600kB RAM.

Das bringt als Nachweis gar nichts, da so ein Video leicht zu fälschen ist. Es muss eine Kennung auf der eingehenden Überweisung sein, auf die der Sender keinen Einfluss hat und die den Charakter der Bareinzahlung klar erkennbar macht. Ein Verrechnungskonto der Senderbank könnte sowas sein - so wie ich die Banken kenne, werden sie Auskünfte aber "aus Datenschutzgründen" ablehnen.

Kann der Empfänger die Barüberweisung immer eindeutig erkennen?

Viel besser. Auf dem Papier der Paper-Wallet finden sich die Private Keys. Die gehen das Finanzamt überhaupt nichts an, ausser Du willst Dir das Geld klauen lassen!

Mit den sich daraus ergebenden Public Keys, kann jeder über die Blockchain nachvollziehen, dass Du die BTC dort seit 2013 liegen hast. Wenn Du also jemandem die Public Keys mitteilst, kann er die Haltedauer problemlos überprüfen. Die Private Keys teilst Du niemandem und unter keinen Umständen mit! Auch nicht dem Finanzamt.


Bei einem sehr hohen Geldeingang geht sowieso erst mal eine Meldung an die Behörden raus. Ob daraufhin etwas passiert hängt von den Umständen ab. Bei mir haben Überweisungen im 6-stelligen Bereich noch nicht zu Rückfragen geführt, obwohl die Transaktionen definitiv eine Meldung angestossen haben. Wenn Du normalerweise kaum Einnahmen hast und plötzlich ein 100 Mio EUR Geldeingang gemeldet wird, könnte es anders aussehen.

Wie dem auch sein, die Behörden werden schon sich bei Dir melden, wenn sie etwas wissen wollen. Wenn Du dann alles sauber und plausibel erklären kannst, ist das üblicherweise absolut ausreichend. Wenn das nicht reicht, kannst Du im nächsten Schritt sogar einen eindeutigen Nachweise über die Blockchain führen. Besser geht es eigentlich kaum noch.

Das ist doch der bereits der perfekte Nachweis! (Auch wenn der Sachbearbeiter damit eventuell nichts anfangen kann)

Allerdings wirst Du zu 99% gar nicht in die Verlegenheit kommen, etwas nachweisen zu müssen, ausser Du legst es darauf an.

I'm fine with segwit + 2MB. I do not support transferring more control to miners by giving them a voting mechanism to decide about the future rules. Some of them currently show us their malicious behavior. We should not reward this by giving them more control.

Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben. Vor allem nicht, da manche Poolbetreiber gerade zeigen wie bösartig und schädlich sie schon mit den aktuellen Rechten umgehen (SPV Mining, Nutzung der Miningleistung zur Blockade der weiteren Entwicklung, Malleated TX).

Ich finde diese Methode nicht gut, da der Nutzer offensichtlich von diesem "Feature" überrascht wurde. Ähnliches gab es auch mal bei Multibit HD und ich habe immer von dessen Nutzung abgeraten. Wenn man Geld von den Nutzern haben möchte (was natürlich valide ist), dann sollte man es offen einfordern.

Um die Abwicklung sicherzustellen, hilft Multisig Escrow (Treuhandabwicklung).

Gegen eine (sehr viel spätere) Rückforderung seitens der der Bank / eines (geschädigten) Kontoinhabers hilft das allerdings nichts. Hier kann man nur das Risiko durch Prüfung verschiedener Quellen und anderen Massnahmen minimieren(nicht ausschliessen!). Mögliche Verifikationen wären ein Telefongespräch (Festnetz, idealerweise mit Telefonbucheintrag), ein EMail Kontakt mit eigener Domain und der passenden eingetragenen Adresse, ein festgelegter eindeutiger Verwendungszweck für die Überweisung, Trennung des Geschäfts in mehrere Geschäfte mit zeitlichem Abstand, Bewertung von anderen Nutzern (Web of Trust Ansätze), eine CACert signierte Nachricht mit Realnamen im Zertifikat, eine Plausibilitätsprüfung aller vorliegenden Informationen und viele weitere Möglichkeiten.

Banken sind leider völlig unzuverlässige Geschäftspartner. Aus Bitcoin-Sicht sind Bankgeschäfte nicht ernstzunehmen, da eine saubere Abwicklung nicht sichergestellt werden kann. Man kann es als Glücksspiel sehen, welches oft (aber nicht immer) gutgehen kann.

Yes. Maybe the better solution would be changing the mining algorithm to get rid of the hostile pool operators. 4000 Nodes should be enough to mine future blocks.

If you are right here, this is the most important problem to solve. Which means with the next hard-fork, the mining algorithm has to be changed!

I would prefer a mining algorithm requiring the UTXO entries and the block entries for every round of the algorithm. This would definitely prevent pooled mining and cheap ASICs.

Das wäre eine mögliche Erklärung. Wenn die BTC Halter ihre BTC nicht billig hergeben wollen und die Käufer nicht auf den Kauf verzichten mögen, dann bleiben nur höhere Kurse als Ausweg übrig.

Die letzten Peaks und die Kursreaktion darauf zeigen für mich an, dass viele BTC Halter gerade nicht mehr bereit sind, ihre BTC für jeden Preis herzugeben. Blöde Situation, wenn man unbedingt kaufen möchte...