Zum BU-Bug: Der ist ein Hinweis darauf, dass das Development Team dahinter überfordert ist. Er ist aber kein Beweis, dass die Idee größerer Blöcke insgesamt falsch ist.
Die Richtung, mehr Transaktionen in einen Block zu bekommen halte ich für richtig. Das geht aber nicht über eine Abstimmung, basierend auf manipulierbaren Informationen. Ich würde das vom Scaling-Vorschlag als solchen trennen, aber eigentlich könnte ich es mir sogar voll offiziell als Option im GUI vorstellen, bei der jeder die Softfork-Optionen "abstellen" kann, die er nicht möchte. Oder auch eine zu hohe Blockgröße (bei einem dynamischen Block-Voting-System wie bei BIP 100). Den Minern wird dadurch signalisiert, was ökonomisch sinnvoll für sie ist. Müsste man aber tatsächlich erst mal testen.
Mit der aktuellen System-Architektur ist eine automatisierte Anpassung der Blockgrösse nicht möglich, ohne die Entscheidungsgewalt zu verändern. Daher halte ich nichts davon, Automatismen einzubauen die nahelegen, eine automatisierte Anpassung wäre möglich. Eine andere Idee wäre ein Proof-of-Stake-basiertes Wahlsystem (ohne natürlich PoS als Konsensmechanismus für Blöcke einzuführen). In dem Fall hätten allerdings wohl derzeit die Exchanges die Macht, die im aktuellen Wahlsystem die Miner haben.
Davon halte ich nichts. Warum sollte der Anteil bestimmten Teilnehmern mehr Stimmrecht verleihen? Weshalb sollte jemand mit grösserem Anteil eher dafür qualifiziert sein, eine Entscheidung zu treffen? Übrigens haben die Miner aktuell keine Macht in dieser Richtung. Es gibt schlicht kein Wahlsystem für Hard-Forks in der Architektur. Die Miner bzw. das ganze System lebt vom Handeln aller Teilnehmer. Der erste grobe Fehler ist, anzunehmen eine Rolle im System hätte hier eine höhere Entscheidungsgewalt. Saubere Änderungen erfordern einen Konsens oder - falls dies unmöglich ist - einen Split.
|
|
|
Für mich heisst das Fazit Multisig-Escrow und daneben - in vernünftigem Rahmen - den Geschäftspartner auf Plausibilität prüfen. Bei grösseren Summen notfalls das Geschäft in mehreren Schritten abwickeln, falls sich Unsicherheiten nicht ausräumen lassen. Wenn alle Stricke reissen, dann verzichtet man eben auf das Geschäft.
|
|
|
Sind diese Regeln nur noch relativ gültig, dann müssen alle alternativen Zweige verfolgt werden. Passiert dies nicht, können Transaktionen unerwünscht im falschen Zweig landen, bis "der Markt" das Problem gelöst hat. ETH hat demonstriert wie schnell dieser Markt das Problem löst (Hint: bis heute ist es ungelöst).
wieso ungelöst? jeder hat bekommen was er will, oder? Nein. Manche Börsenkunden haben verloren, Transaktionen sind auf auf dem falschen Zweig gelandet. Die Probleme wurden bis heute nicht zufriedenstellen gelöst. Ignorieren ist keine Lösung. Proof of Work? BU Nodes folgen immer der längsten chain.
Sie folgen der längsten gültigen Chain!
|
|
|
Egal ob erlaubt oder nicht, Banken fordern das Geld definitv bei solchen Überweisungen zurück und drohen mit Anwälten (mein eigener Fall mit der Postbank). Wie es dann weitergeht, wenn man trotzdem nicht zahlt, kann ich allerdings nicht mit Gewissheit sagen, denke aber nicht, dass die so schnell aufgeben.
Ich denke man kann aus dem aktuellen Fall der Bausparkassen extrapolieren, dass die Banken sich die Rückforderung höchstrichterlich absegnen lassen, sollte dies im grossen Stil passieren. Banken sind systemrelevant - Du nicht!
|
|
|
"korrekt" nach welchen Regeln?
Derzeit: Block <= 1MB: Wird von Allen akzeptiert Block > 1MB: Wird von Allen abgelehnt Richtig! Sind diese Regeln nur noch relativ gültig, dann müssen alle alternativen Zweige verfolgt werden. Passiert dies nicht, können Transaktionen unerwünscht im falschen Zweig landen, bis "der Markt" das Problem gelöst hat. ETH hat demonstriert wie schnell dieser Markt das Problem löst (Hint: bis heute ist es ungelöst).
|
|
|
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.
|
|
|
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.
Was verstehst du unter "vollständiger Verifikation"? Das verstehe ich nicht so ganz. 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.
|
|
|
Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.
Das BU Design ist das Bitcoin Design. Jeder kann auch den core-code nehmen und das blocksize limit rauseditieren. Daß Bitcoin funktioniert basiert nicht auf der Unmöglichkeit dies zu tun. 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! Es geht auch nicht um eine Abstimmung. Es geht darum den Minern die Sicherheit zu signalisieren (auf rein technischer Ebene), daß Ihre blocks auf zustimmung stossen (oder auch nicht). Diese technische Ebene ist aber nicht die einzige Ebene die die Miner beachten müssen: Sie haben die Aufgabe und auch das starke Eigen-Interesse nach solchen Regeln zu minen, daß die größtmögliche Ökonomische Mehrheit die chain akzeptiert. Das findet nicht nur auf der Netzwerk-Protokoll-Ebene (blocksize limit) statt, sonder auch auf der Ebene der monetären Parameter: wenn sie beispielsweise das coin limit auf 42 millionen erhöhen, dann findet das die ökonomische Mehrheit voraussichtlich nicht gut. Wenn sie drauf beharren, dann gibt es einen Split (UASF, PoW-Change, minority fork oder was auch immer) und der Markt regelt den Rest. Ganz schnell crasht der Preis dieses "Bitcoin 42". Also werden die Miner soetwas nicht tun. Sie werden versuchen einen Chain zu bauen, die den größtmöglichen Wert hat. Ich finde darin kann man Vertrauen haben. Funktioniert bisher blendend. Das ist Bitcoin.
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. 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.
Ja genau, und BU vereinfacht dem Node-Betreiber die Änderung einiger der relevanten Regeln für diese "Akzeptanz und Weiterleitung". Das ist kein Fehlerhaftes Design sondern "benutzerfreundlich" 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.
|
|
|
Deshalb wäre dein Patchvorschlag (dass Full Nodes Blöcke, die für "unerwünschte" Entscheidungen voten, zurückhalten können) keine schlechte Idee, um ein wirksames Korrektiv durch die anderen Full-Nodes für den Fall zu erhalten, dass sich die Miner vom Mehrheitswillen entfernen.
Ja, wobei ich das als Notlösung sehe, wenn gar nichts anderes mehr geht. Hast du schon mal an ein BIP gedacht (oder gibt es schon eins)?
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.
|
|
|
Der Käufer kann eine Barüberweisung statt einer normalen Überweisung machen. Allerdings muss er dafür zu einer Filiale und das kostet auch ein wenig. Aber so wärs wohl sicher.
Kann der Empfänger die Barüberweisung immer eindeutig erkennen? Na klar: der Absender sollte/musste in der Bank ein Video drehen und dann mit Yutube verlinkten 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.
|
|
|
Der Käufer kann eine Barüberweisung statt einer normalen Überweisung machen. Allerdings muss er dafür zu einer Filiale und das kostet auch ein wenig. Aber so wärs wohl sicher.
Kann der Empfänger die Barüberweisung immer eindeutig erkennen?
|
|
|
Ok aber ich hab da ja nur ein Papier in der Hand. Es steht zwar ein Datum drauf. Aber das kann man ja ganz einfach fälschen. Ich dachte eher ich muss mir das Paper Wallet irgendwo beglaubigen lassen?
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. Wie meinst du das ich nicht in Verlegenheit kommen werde was nachweisen zu müssen? Es ist ja aktuell ein recht hoher Betrag. Wenn ich nun plötzlich tausende Euros auf meinem Girokonto habe will doch das Finanzamt sicher was vom Kuchen sofern ich nicht nachweisen kann wie und was.
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.
|
|
|
2013 habe ich alle auf ein Paper Wallet überwiesen. Seit dem liegen diese dort.
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).
|
|
|
|