Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 27. (Read 185830 times)

1. Also SegWit2x ist BIP91. Richtig? Mit durchschnittlich Minimum 85% HashPower. (Heute fast 92%)
Start 21. Juli, 23 Juli aktiv. (erste Hürde, sehr wahrscheinlich eintreffend)

2. Das wäre denn immer noch die originale Chain. Richtig?

Miner die am minen verdienen wollen, müssten ab dann, 23.Juli oder 29Juli, SegWit-Blöcke machen.



Ab hier BIP 141 wird es etwas unklar für mich.

Wenn das denn über 95% sind, Ist das BIP 141 von Core auch OK. Nur weiß ich nicht ab wann dass denn unumkehrbar aktiviert ist. 31.Juli? (zweite Hürde, Daumen drücken)
Falls das mit den 95% zutrifft ist UASF nicht mehr nötig bzw. schon erfüllt. Richtig?


UAHF  von Bitmain, versuch ich später mal verstehen.
Jetzt gehe ich erstmal zu d5000 seiner Erklärung rüber. Denn werd ich mal sehen ob ich nicht irgend etwas "dummpeinliches" gerade geschrieben habe.
 


edit: verstehe ich also in etwa wie d5000 unter beschrieben hat.
und MoinCoin auch.
Ich bin erstmal sehr zuversichtlich.

Es gibt da auf Deutsch tatsächlich nur sehr wenig. Ich habe mich also mal dran versucht: 1. August, Chainsplit, UASF, Segwit2x, BIP148 und Co. - einfach erklärt. Ist erst mal eine grobe Übersicht. Kommentare und Verbesserungsvorschläge sind willkommen!

Hab da jetzt noch nicht so geschaut, aber denke sobald es soweit ist, wird es genug Anleitungen geben. Die ersten Tage danach würde ich auch erstmal keine Coins versenden.

Electrum plant ne Independence Wallet mit dem nächsten Release 2.9. Sollte jetzt eigentlich bald erscheinen
https://twitter.com/ElectrumWallet/status/881522191506038784

Gibt es eigentlich irgendwo eine Übersicht wann was kommen soll und das es genau bedeutet?
Und eine einfache Anleitung wie man bei einem Split mit dem Ledger und Paperwallets umgehen kann?

Da ist nicht nur UASF BIP148 gemeint, was von Luke-Jr gepushed wird, sondern auch der UAHF (haha was für ein Euphemismus) von Bitmain.
Das heißt es könnte kurzfristig 3 verschiedene Bitcoins geben - Das alte Bitcoin - BIP148 Bitcoin - Bitmain Bitcoin.
Das alte Bitcoin existiert nur, solange es mehr Hashpower als BIP148 hätte.

Aber vorher kommt ja der BIP91 ähnliche Teil von Segwit2x. Das heißt, wenn sich die Miner tatsächlich am 21. Juli anfangen den BIP91 Teil von BTC1/Segwit2x zu signalisieren und der am 23. Juli (bzw. spätestens am 29. Juli) dann in den "Lock In" Zustand übergeht, passiert am 01. August überhaupt kein Split.

Schöne Timeline:
http://imgur.com/WDhWkHx

Also ich warte jetzt erstmal die 10 Tage ab.

sofu hat drüben im anderen faden einen link geteilt.

was soll das bedeuten? https://bitcoin.org/en/alert/2017-07-12-potential-split Welcher mögliche Split soll da gemeint sein? UASF?



edit
hier eine meinung von Dr. Julian Hosp https://www.youtube.com/watch?v=e98fPPVoFeY Massiver Bitcoin Crash am 1. August? Segwit, Segwit2X, UASF, BIP148 - Was ist das alles?

Kleiner Nachtrag:
Das HF Bit wird laut Jeff Garzik nicht genutzt, damit Lite-Wallets nicht upgedated werden müssen.

Folge davon ist, dass diese Wallets auch keine einfache Möglichkeit haben auszuwählen, welchen Fork sie nutzen wollen.
An der Stelle will man sich wohl den Hard Fork sparen und nutzt aus Sicht eines Lite-Wallets einen nicht feststellbaren Soft Fork.

Falls der Hard Fork auch in der Hashrate kontrovers wird heißt das, dass das Lite Wallet zwischen den Chains hin und herspringen könnte.
Wer Lite-Wallets nutzt, sollte also die Tage nach dem Hard Fork lieber keine Transaktionen machen, soweit er nicht sicher auswählen kann, welche Chain er benutzt.


Quellen:
https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000096.html
https://github.com/btc1/bitcoin/pull/46

Ja Testnet5 synchronisiert auch ohne Probleme wieder mit dem btc1 Client, nachdem der Block jetzt entsprechend den in dem Testnet5 gültigen Hard Fork-Regeln von btc1/Segwit2x neu gemined wurde.

An dem Tag an dem der HF kommt würden die Pool-Betreiber auch hoffentlich wachsam sein und könnten innerhalb von wenigen Minuten eingreifen. Die Situation im Testnet5 mit sehr wenig Hashpower ist schon etwas anders. Vor allem, weil es meines Wissens im Gegensatz zum Mainnet bei dem Hard Fork keine festen Regeln gab, wann der Hard Fork zu erwarten war. Vertrauensbildende Maßnahmen sehen natürlich anders aus.

Absolut richtig - Weil alte Clients den Block ebenso als ungültig ansehen würden, bietet ein erzwungen gesetzes MSB / HF-Bit zum Zeitpunkt des HFs eine einfachere Möglichkeit für Wipe-Out Protection, als ein erzwungener großer Block, bei dem man von äußeren Zuständen abhängig ist.

Einziger Vorteil ist, dass man sich bei dem HF sicher sein kann, dass alle die mitgehen tatsächlich für mindestens einen Block lang Blöcke größer als 1 MB auch unterstützt haben.

Danke schon mal für die Rückmeldung MoinCoin!


Habe mich jetzt etwas durch den Bandwurmthread des "Bugs" gelesen und komme inzwischen zur gleichen Schlussfolgerung.


Im Bug-Thread wurde eben behauptet, die ">1MB-Block-als-Forksignal" Vorgehensweise würde for "wipe outs" schützen - also verhindern, dass sich der 2MB-Fork "reorganisiert" und zugunsten des <1MB-Forks georphaned wird. Würde das  Most Significant Version Bit diesen Schutz auch bieten?


Miner, die nur halbherzig für Segwit2x sind/waren, wären die kritische Gruppe. Muss man halt beobachten.

Ich ebenfalls. Ist sehr lehrreich und dazu sehr objektiv geschrieben, trotz klar bestimmter Positionen.
Mein Respekt für soviel Diskussionsdisziplin!

Jap, dem schliesse ich mich auch an!
Und ausserdem ein Lob an alle die hier so ausführlich und sachlich diskutieren. Ich lese hier gerne mit!!! 

Danke.


Dem möchte ich mich auch anschließen.

Genau -> Segwit2x nutzt den in BIP 91 beschriebenen Prozess um Segwit BIP 141 mit 100% zu aktivieren.
Wenn alles nach Zeitplan läuft, dann werden die Blöcke alle kompatibel zu:

• Den alten Regeln (Bitcoin Core 0.12 / Bitcoin Unlimited & Co.)
• Segwit BIP 141 über BIP 9 Aktivierung mit 95%
• Segwit2x über einen BIP 91 Prozess
• UASF BIP148

Das heißt, dass die Blöcke alle zuvor genannten Regeln (BIPs) befolgen müssen - die BIP 148 Regeln werden praktisch nebenbei mit befolgt, dafür sorgt BIP 91, wenn es rechtzeitig aktiviert wird.

Wenn Segwit2x um den ?24. rum startet und um den ?27. rum fix ist/würde. Wird Segwit2x ja 100% erreichen? Weil die "anderen" nicht Segwit2x Miner, sich selbst rausschmeissen?
Und wenn ja, ist BIP 141 auch durch, weil 95% überschritten?

Danke erstmal für die positiven Rückmeldungen  

Kann mir nicht vorstellen, dass das ein echter Showstopper ist.
Die Lösung bei Segwit2x ist eben alles andere als elegant, auch weil die Miner wohl manuell eingreifen müssen um gültige Blöcke minen zu können.

Zur Not steht die Blockchain eben mal ein paar Minuten, falls der Mempool leer ist.
Grundsätzlich lässt sich der Mempool ja schon vor dem kritischen Block füllen. Bitmain oder Roger Ver werden die dafür anfallenden Gebühren wohl kaum stören.

Einfach das Most Significant Version Bit (manchmal auch Hardfork Bit genannt) zu setzen ist sicherlich einfacher und eleganter, weil das nur von der Blockhöhe und keinen anderen Zuständen abhängig ist.
Im Mainnet kommt der kritische Zeitpunkt ja erst ungefähr gegen Ende Oktober, wenn ich das richtig im Kopf hab.

Leute, die jetzt schon überzeugt sind, dass sie den Hard Fork nicht mitgehen sind jetzt eben noch etwas mehr darin bestärkt.
Leute die unentschieden waren - wer weiß, wie sich das bei denen auswirkt.
Leute, die den Hard Fork unbedingt durchziehen wollen wird das wohl kaum abhalten, am wenigsten solche Miner, welche den Hard Fork unbedingt wollen und dafür auch mal 10 Minuten Verdienstausfall in Kauf nehmen werden.

Dem schließe ich mich an! Hab viel gelernt

Wie schätzt ihr diesen Bug, der heute bei Segwit2x entdeckt wurde, ein? -ck meinte, es könnte ein "Showstopper" sein (also einer von der Art, der gefixt werden _muss_). Andere meinen, es wäre nicht mal ein Bug.

Könnte aber auch für den Kursrutscher heute verantwortlich sein.

Jedenfalls geht es darum, dass Segwit2x beim Hardfork einen Block verlangt, der größer als 1 MB ist - dann gelten, so weit ich das verstehe, die neuen Regeln. Das Problem wäre, dass wenn beim HF-Zeitpunkt nicht genug Transaktionen im Mempool sind, die Blockchain erst mal "stehenbleibt" - das ist wohl im Testnet passiert.

Aber würde sich das nicht nach einer Zeitlang selbst regeln, d.h. dann dauert es eben halt mal ne Stunde bis zum nächsten Block? Oder würde das bedeuten, dass die Nicht-HF-Miner dann wieder Vorteile hätten, d.h. auch mit deutlich weniger Hashrate immer einen gültigen Block produzieren könnten und das ganze Spiel ginge von vorne los?

@MoinCoin: Meine Hochachtung, dass du hier regelmässig deine enormen technischen Kenntnisse teilst und die Skaling-Debatte analysierst. Deine Beträge sind immer äußerst lesenswert.

Weil es keine standardisierte Software gibt - es ist einfach für eine normale Person nicht nutzbar und leider gibt es momentan Nur Payment Channels in eine Richtung und nur mit begrenzter Lebensdauer, da OP_CSV meist nur genauso wie OP_CLTV einsetzbar ist, dank der Malleability.

Aber bis sich das ändert, ist es ja nur eine Frage der Zeit.

Ich hab nie gesagt, dass Bitcoin Schrott ist.
Bitcoin macht eben das gut, wofür es designed wurde.
Und Bitcoin könnte auch noch viel mehr, als wir aktuell nutzen (und was Satoshi bestimmt auch wollte - Malleability war sicherlich nicht absichtlich), wenn die Voraussetzungen durch Technologien, wie Segwit geschaffen werden.

Die Diebstähle von Mt Gox und Bitfinex waren ja auch keine direkte Schwachstelle in Bitcoin - aber Bitcoin unterstützt das leider nun mal On-Chain nicht, deswegen wurde das immer über das verwundbare zentralisierte Off-Chain gelöst.

Das heißt, wenn wir sowas in Zukunft verhindern wollen, dann brauchen wir eben dezentralisiertes Off-Chain. Selbst wenn LN komplett zentralisiert wäre - wenn der zentrale Hub gehackt wird betrifft das nicht die User - denn es kann nur das Geld geklaut werde, was gerade dem zentralen Hub gehört - der Nutzer behält sein Geld, was er im Channel hatte.
Sowas geht einfach nicht mit On-Chain.

Das wäre schon mal sehr wichtig.
Dann wäre sicherlich noch Weak-Blocks oder sowas wie Bitcoin-NG wichtig, dann haben wir tatsächlich Voraussetzungen, damit wir Blöcke größer als Segwit-2x ohne größere Nachteile verarbeiten können.

War ja sehr praktisch, dass du von 10 mio Usern gesprochen hast.

In Wirklichkeit werden es vermutlich zentralisiertere Strukturen sein, weshalb man weniger Geld vorschießen muss, aber auch mehr Transaktions-Überwachung bekommt.

Payment-Channels sind schon heute möglich. Sind aber auch relativ naheliegenden Gründen ein totaler Flop.

Ich will das ja jetzt nicht unnötig schlecht machen. Ich mag nur dieses "Bitcoin selbst ist Schrott. Erst mit 2nd Layer wird es was" nicht. Bitcoin selbst funktioniert wunderbar und hat noch sehr viel Spielraum. Während mich bisher noch keine 2nb Layer wirklich überzeugt hat. Zumindest nicht im selben Maß, wie mich Bitcoin überzeugt. Auch dass LN im kleinen Maßstab nützlich ist, wie du sagst, ist mir noch sehr zweifelhaft. Ich vermute eher, dass es nur im großen Maßstab nützlich ist.

Pruning, ja, das verlagert das Problem zum Syncen. Damit hätten wir ja schon mal unsere Bottleneck und wissen, worüber wir reden müssen. Syncen. Die ultimative Bottleneck. Wie kann man das Problem lösen?

Jonas Schnelli arbeitet derzeit an einem Model, das ein Node erst das UTXO aufbaut und dann synced, womit man ihn schon mal gut benutzen kann, noch während er synced.

Beim einen geht es um Off-Chain Payments allgemein und zwar eher um Ad-Hoc Payment Channels - Ich hab in dem Beispiel auch nicht von LN geredet, aber wenn man einen neuen Channel aufmacht hat man sowieso nicht das Problem was du beschreibst und könnte dafür auch LN nehmen.

Beim zweiten geht es um eine theoretische Struktur aus einem mathematischen Modell für LN und zwar wenn das LN bereits so weit entwickelt wäre, so dass man kaum noch Off-Chain braucht.

Außerdem ist das 2. Modell nicht optimiert, da es einzig um alleine darum ging zu zeigen, dass z.B. Routing in so einem großen Netz funktionieren kann.
Wir wissen, dass LN technisch gut in kleinen Netzen funktioniert, aber das war der erste Versuch das mal für ein großes Netz zu simulieren.
Es lässt sich daraus aber nicht ableiten, wie viele Bitcoins man tatsächlich für ein Netzwerk in der Größe braucht, oder ob man überhaupt ein Netzwerk in der Größe braucht.
Die benötigten Bitcoins könnten dafür in der Realität durchaus eine ganze Größenordnung weniger sein.

Das LN schon im kleinen Maßstab nützlich sein kann und wir für das Szenario die technischen Grundlagen bereits haben, stellt das ja überhaupt nicht in Frage.
Das andere Szenario ist eigentlich nur für den Fall interessant, ob es möglich ist mit den bisherigen Blockgrößen dauerhaft auszukommen, wovon ich nicht überzeugt bin.


Und klar, wir haben ja genug über Pruning geschrieben.
Pruning funktioniert - allerdings wenn wirklich viele Leute anfangen zu prunen bei 1 TB / Jahr, dann wird es innerhalb kurzer Zeit extrem schwer überhaupt eine neue Node syncen zu können.
Also bevor wir Pruning ernsthaft in der Masse nutzen wollen bitte Clients mit funktionierenden UTXO Commitments oder andere Technologien die ein syncen wieder sicher möglich machen.

Du kannst einen Effizienzgewinn um einen beliebigen Faktor ja auch nutzen um die entsprechende Anzahl mehr Leute in das Netzwerk zu holen.
Wenn man keinen Vorteil hat das auf der Blockchain zu settlen als Nutzer und es funktionierende Alternativen gibt, dann bleibt es einfach verschwendete Bandbreite und Blockspace.

Es gibt auch nicht nur neue Anwendungszwecke durch Kapazitäts Gewinne bei Off-Chain Transaktionen, sondern eben auch neue Einsatzzwecke durch eine höhere Sicherheit in manchen Anwendungsszenarien (siehe mein Börsen Beispiel). Es ergibt daher auf jeden Fall Sinn das weiter zu verfolgen.

Du kannst mit Off-Chain Transaktionen ohne Probleme Beträge von 0,01 ct und noch viel kleinere Beträge überweisen, also viele Services dann extrem genau abrechnen, während das auf einer Blockchain ohne Blockgrößenbeschränkung, aber mit Fee zur Spamcontrol nicht möglich ist, da wir auch dann noch mehrere cent Gebühr pro Transaktion haben werden. Oder wie wäre das für Online-Kasinos? Da könntest du mehrere Transaktionen pro Minute (wenn man will auch pro Sekunde) pro Benutzer problemlos verarbeiten, während das On-Chain einfach nicht skaliert.

Edit:
Hatte als ich 10 Mio als Beispiel genommen und nicht die 10 M Challenge im Kopf - die Zahl hatte ich einfach nur so gewählt - alle Gemeinsamkeiten sind zufällig, ist eben eine einfache Zahl zum Rechnen