Pages:
Author

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

sr. member
Activity: 409
Merit: 286
as Ding ist: Wenn SWIFT oder SEPA ihre Software seit den 80er nicht aktualisiert hätten, so dass allerlei Banken rund um die Welt Systeme aus den 80ern oder 90ern benutzen würden, wäre das System nicht stabil, sondern einfach nur unsicher.

Von den SWIFT-Hacks hast du nichts mitbekommen? Oder sind diese Peanuts eingepreist und gehören zum System?


Oh, ich habe sogar genüßlich darüber geschrieben Smiley

Aber wenn man ehrlich ist, ist der Anteil von gehackten Geldern im Swift System in Relation zum Gesamtvolumen winzig wenn man es mit Bitcoin vergleicht. Daher, ja, Peanuts.

Es wäre allerdings interessant zu wissen, ob Swift die Hacks mit einer rigideren Update-Politik und weniger Abwärtskompatibilität hätten verhindern können. Soweit ich weiß fanden die Hacks in Drittweltländern auf weitgehend ungesicherten Systemen statt.
hero member
Activity: 778
Merit: 531
as Ding ist: Wenn SWIFT oder SEPA ihre Software seit den 80er nicht aktualisiert hätten, so dass allerlei Banken rund um die Welt Systeme aus den 80ern oder 90ern benutzen würden, wäre das System nicht stabil, sondern einfach nur unsicher.

Von den SWIFT-Hacks hast du nichts mitbekommen? Oder sind diese Peanuts eingepreist und gehören zum System?
legendary
Activity: 2702
Merit: 1261
SegWit wird natürlich deutlich komplizierter und bedeutet sehr viel mehr Arbeit bzw. dürfte in einen individuellen Node mit überschaubarem Aufwand unmöglich zu integrieren sein. Eine UASF bedeutet für die individuellen Nodes wesentlich mehr Arbeit als eine 2MB fork und sollte, wenn du das ernst meinst, von dir noch viel mehr bekämpft werden als eine Hardfork.

Tatsächlich halte ich zumindest BIP148 für deutlich zu knapp bemessen. Eine Reaktion seitens der Nutzer halte ich für angemessen, wenn die 3 grossen Miner die Blockade bis zum Ablauf des BIP9 Zeitrahmens nicht aufgeben.

segwit als Soft-Fork bedeutet für Knoten die längerfristig planen müssen kurzfristig erst mal gar keine Arbeit. Die Umstellung kann nach der Aktivierung eingeplant werden und muss nicht unter Zeitdruck geschehen.

Ich kann deinen Kommentar zu Bastelbude, Bitcoin, DAO und Ethereum gut nachvollziehen. Aber wie es aussieht, sehen die Märkte das anders: http://coinmarketcap.com/charts/#dominance-percentage. Die Hardfork hat Ethereum überhaupt nicht geschadet, während die Abwesenheit einer Hardfork Bitcoin, zumindest in Relation zu anderen Kryptowährungen, massiv abgewertet hat. Und einen anderen Indikator als den Markt gibt es nicht. Deine persönliche Meinung, was ein gutes Geldsystem ausmacht, ist fast so irrelevant wie meine (fast, weil du wohl deutlich mehr Coins im Spiel hast).

Glücklicherweise ist das völlig irrelevant. Da ich dezeit keinen Bedarf an Smart-Contracts habe, kann ich Ethereum locker ignorieren. Ob andere Menschen ihr Geld dort rein stecken oder nicht ist deren persönliches Problem. Die Effekte auf den Bitcoin Kurs gibt es sicherlich, aber auch da ist es mir völlig egal, ob der Kurs mit Ethereum bei 2000 EUR/BTC steht oder ohne Ethereum meinetwegen bei 4000 EUR/BTC stehen würde. Insgesammt ist mir durch die Fundamentaldaten klar, dass Ethereum langfristig keine Zukunft hat - weder technisch noch sozial. Trotzdem (oder gerade deshalb) eignet sich das System zum Zocken. Das hat aber langfrsitig keine Bedeutung: Hier im Forum gibt es doch tatsächlich Mitglieder, die auf Ponzi-Systeme und andere Betrügereien zocken und darauf spekulieren, früher als die anderen Opfer auszusteigen zu können.

Und wenn wir eine Hardfork der Datenträger vermieden hätten, würden wir heute weiterhin 5,25" Disketten benutzen.

Und das hat 20-30 Jahre gedauert. Bei den entpsrechenden Schnittstellen hat man übrigens über weite Strecken und so lange das möglich war den MIgartionspfad (erst IDE, dann  SATA) gewählt. Dabei geht es hier nur um ein paar Datenträger, die innerhalb kürzester Zeit umkopiert werden können und die vor allem parallel mit alten Modellen betrieben werden können. An ein globales Geld-System werden andere Anforderungen gestellt. Selbst wenn man extrem Agil ist, sollten daher 2-3 Jahre nachdem das Konzept fest(!) ist drin sein. Wie gesagt, ich habe nicht generell etwas gegen einen Hard-Fork, nur sollte man den nicht a) in wenigen Monaten über's Knie brechen und b) tatsächlich eine sinnvolle Richtung einschlagen und ihn nicht als reines Machtinstrument missbrauchen. Ausserdem sind Soft-Forks bevorzugt. Erst wenn das nicht mehr sinnvoll möglich ist (ECDSA angreifbar, Mining Algorithm Change), ist es an der Zeit über einen Hard-Fork nachzudenken.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
@mezzo
Ich stimme dir weitgehend zu.

Es gibt zudem Übergangslösungen wie Edge-Nodes, die auch Adam Back immer wieder für Segwit angepriesen hat.
Das funktioniert exzellent für Opt-In Soft Forks (Segwit, Extension Blocks), ohne das man seine eigene Software anpassen muss.
Evil Soft Forks (wie ich kürzlich einen beschrieben habe) und Hard Forks können das allerdings unmöglich machen.

Und dann gibt es eben Hard Forks, welche schwieriger zu adaptieren sind und dann gibt es welche die einfacher in die eigene Lösung einzubauen sind.

2 MB gehört sicher zu den einfacheren, aber auch da muss man dann selbst ein Testnet aufziehen. Software entwickelt gerne unvorhergesehene Seiteneffekte, die man überhaupt nicht erwartet hat - und wenn wir Bitcoin nicht zur Trashcoin werden lassen wollen brauch das eben einige Monate, damit alle Teilnehmer eine realistische Chance haben das zu implementieren und sauber zu testen.

Segwit ist zwar bei simpler technischer Betrachtung ein weitaus größere Änderung als ein 2 MB Hard Fork, allerdings kann man sich davon eben komplett abkapseln indem man so eine Edge-Node betreibt, während man bei 2 MB gezwungen wird seine eigene Software anzupassen und komplett neu zu testen.
sr. member
Activity: 409
Merit: 286
Warum Totalverlust?

Die Nodes werden keine neuen Blöcke bekommen, und wenn dahinter ökonomische Aktivität steckt, reicht einmal google aus, um den Grund dafür zu finden und ein Update runterzuladen.

Das versuche ich schon dei ganze Zeit klarzumachen. Es läuft nicht überall ein Knoten von der Stange. Gerade diejenigen, die Bitcoin tatsächlich für ihre geschäftliche Abwicklung nutzen, haben teilweise gepatchten Code oder sogar komplett eigene Software am Laufen. Genau die sind bei den älteren Knoten mit dabei.

Diese Betreiber können nicht einfach etwas runterladen und laufen lassen. Vor allem nicht kurzfristig. Willst Du denen etwa  schnell die Anpassungen nachziehen, testen und in den Produktivbetreib überführen!? Du solltest Dir langsam mal klarmachen, dass Bitcoin nicht mehr das Spielzeug ist, welches Satoshi mit seinen Kumpels einfach unverbindlich nebenbei laufen lässt. Bei einem zuverlässigen Geldsystem möchte man mehr oder weniger willkürliche Brüche (lad mal kurz die neue Software runter, wir machen mal einen Hard-Fork weil unsere Kumpels bei DAO eine Transaktion verbockt haben, ...) nicht haben.

Wenn man die Bastelstube verlässt und sich in einem zuverlässigen Umfeld bewegen möchte, dann muss man Migrationspfade bieten. Bei der jetzigen Infrastruktur (wenige Miner, viele sonstige Nutzer) sind das Soft-Forks. Für eine Bastelbude wäre der aktuelle Kurs bei weitem zu hoch. Aus diesem Grund ist die Bastelbude Ethereum (aka wir machen mal wieder einen Hard-Fork) auch deutlich überbewertet, selbst wenn man die anderen Unzulänglichkeiten und die praktisch nicht vorhandene Nutzung ignoriert.


Verstehe. Wäre interessant zu wissen, wie viele Unternehmen das sind. Eigene Software dürfte heute eher die Ausnahme sein - ich glaube, Mt Gox hatte einen Node in php - da es schwierig ist, den Konsens zu halten. Wenn ich mich richtig erinnere, hat Core damals, als Mt. Gox pleite ging, ein Update für den Client geschrieben, um Malleable Transaktionen besser zu erkennen. In den folgenden Tagen hat fast jede Firma das Update runtergeladen und war sicher.

An sich könnten individuelle Knoten aber relativ einfach der 2MB Fork folgen, indem sie eine Zahl im Code ändern. (nachgeordnete Probleme wie die SigOps können durch Software von der Stange / den Minern gelöst werden und brauchen nicht jeden Node).

SegWit wird natürlich deutlich komplizierter und bedeutet sehr viel mehr Arbeit bzw. dürfte in einen individuellen Node mit überschaubarem Aufwand unmöglich zu integrieren sein. Eine UASF bedeutet für die individuellen Nodes wesentlich mehr Arbeit als eine 2MB fork und sollte, wenn du das ernst meinst, von dir noch viel mehr bekämpft werden als eine Hardfork.

Ich kann deinen Kommentar zu Bastelbude, Bitcoin, DAO und Ethereum gut nachvollziehen. Aber wie es aussieht, sehen die Märkte das anders: http://coinmarketcap.com/charts/#dominance-percentage. Die Hardfork hat Ethereum überhaupt nicht geschadet, während die Abwesenheit einer Hardfork Bitcoin, zumindest in Relation zu anderen Kryptowährungen, massiv abgewertet hat. Und einen anderen Indikator als den Markt gibt es nicht. Deine persönliche Meinung, was ein gutes Geldsystem ausmacht, ist fast so irrelevant wie meine (fast, weil du wohl deutlich mehr Coins im Spiel hast).

Das Ding ist: Wenn SWIFT oder SEPA ihre Software seit den 80er nicht aktualisiert hätten, so dass allerlei Banken rund um die Welt Systeme aus den 80ern oder 90ern benutzen würden, wäre das System nicht stabil, sondern einfach nur unsicher. Oder Windows: Ist zwar nett, dass man Word-Dateien auf Windows 95 ansehen kann. Aber einer FIrma, die heute noch Windows 95 benutzt, sollte man auf keinen Fall Geld geben.

Und wenn wir eine Hardfork der Datenträger vermieden hätten, würden wir heute weiterhin 5,25" Disketten benutzen.

legendary
Activity: 2702
Merit: 1261
Warum Totalverlust?

Die Nodes werden keine neuen Blöcke bekommen, und wenn dahinter ökonomische Aktivität steckt, reicht einmal google aus, um den Grund dafür zu finden und ein Update runterzuladen.

Das versuche ich schon dei ganze Zeit klarzumachen. Es läuft nicht überall ein Knoten von der Stange. Gerade diejenigen, die Bitcoin tatsächlich für ihre geschäftliche Abwicklung nutzen, haben teilweise gepatchten Code oder sogar komplett eigene Software am Laufen. Genau die sind bei den älteren Knoten mit dabei.

Diese Betreiber können nicht einfach etwas runterladen und laufen lassen. Vor allem nicht kurzfristig. Willst Du denen etwa  schnell die Anpassungen nachziehen, testen und in den Produktivbetreib überführen!? Du solltest Dir langsam mal klarmachen, dass Bitcoin nicht mehr das Spielzeug ist, welches Satoshi mit seinen Kumpels einfach unverbindlich nebenbei laufen lässt. Bei einem zuverlässigen Geldsystem möchte man mehr oder weniger willkürliche Brüche (lad mal kurz die neue Software runter, wir machen mal einen Hard-Fork weil unsere Kumpels bei DAO eine Transaktion verbockt haben, ...) nicht haben.

Wenn man die Bastelstube verlässt und sich in einem zuverlässigen Umfeld bewegen möchte, dann muss man Migrationspfade bieten. Bei der jetzigen Infrastruktur (wenige Miner, viele sonstige Nutzer) sind das Soft-Forks. Für eine Bastelbude wäre der aktuelle Kurs bei weitem zu hoch. Aus diesem Grund ist die Bastelbude Ethereum (aka wir machen mal wieder einen Hard-Fork) auch deutlich überbewertet, selbst wenn man die anderen Unzulänglichkeiten und die praktisch nicht vorhandene Nutzung ignoriert.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Der Medium Artikel von Jeff Garzik lässt mich mal hoffen, dass Segwit dann doch über BIP91 und somit kompatibel zu unseren aktuellen Clients und bei schneller Einführung sogar zu den BIP-148 UASF Clients ist.

Der 2 MB Hard Fork lässt sich sowieso nicht erzwingen, wäre momentan aber nicht abgeneigt dem zu folgen.

Finde es gut, dass das ganze wieder etwas offener abläuft und wir nicht mit einem fertigen Backroom Deal abgespeist werden.

Quelle:
https://medium.com/@jgarzik/a-personal-note-to-the-bitcoin-community-c24aa0821ab
https://github.com/btc1/bitcoin/pull/6#issuecomment-305032004

sr. member
Activity: 409
Merit: 286
Mittlerweile ist auch klar, dass die New York Consensus-Gruppe nicht gleich wieder zerfallen wird. An der geleakten Mail aus der Mailing-Liste sieht man, dass sich da feste Strukturen herausbilden. Wahrscheinlich wird da eine neue Bitcoin-Association daraus hervorgehen, bestehend aus den größten Unternehmen, die dann dem neuen Chief Developper Jeff Garzik Vorgaben macht, wie der Referenz-Client weiterentwickelt werden soll.

Nein, aber nein danke!

Es bleiben also rund 1300 Nodes oder 17 Prozent, die auch ein halbes Jahr nach Veröffentlichung eines Upgrades dieses nicht eingespielt haben. Es ist schade, aber etwa in diesem Bereich liegt die Anzahl von Nodes, die vom NY Kompromiss wohl abgehängt werden. Das ist bedauerlich, aber ich gehe davon aus, dass es der kleinere Preis im Vergleich zu einem weiteren Nichtstun ist.

Die Banken machen ein grosses Netzwerkupdate und schliessen die Filialen. Bedauerlich für die 17%, die die neue Infrastruktur nicht nutzen (können). Es ist bedauerlich, aber der Totalverlust für diese 17% ist ein kleiner Preis im Vergleich zum aktuellen technsichen Stillstand in der Bank-IT. Malta und Griechenland war also doch etwas ganz tolles. Bedauerlich für die wenigen, die dabei etwas verloren haben.

Ach ja, es gibt übrigens Migrationspfade (Soft-Forks). Das ist etwas komplett anderes als Nichtstun.


Warum Totalverlust?

Die Nodes werden keine neuen Blöcke bekommen, und wenn dahinter ökonomische Aktivität steckt, reicht einmal google aus, um den Grund dafür zu finden und ein Update runterzuladen.
legendary
Activity: 2702
Merit: 1261
Mittlerweile ist auch klar, dass die New York Consensus-Gruppe nicht gleich wieder zerfallen wird. An der geleakten Mail aus der Mailing-Liste sieht man, dass sich da feste Strukturen herausbilden. Wahrscheinlich wird da eine neue Bitcoin-Association daraus hervorgehen, bestehend aus den größten Unternehmen, die dann dem neuen Chief Developper Jeff Garzik Vorgaben macht, wie der Referenz-Client weiterentwickelt werden soll.

Nein, aber nein danke!

Es bleiben also rund 1300 Nodes oder 17 Prozent, die auch ein halbes Jahr nach Veröffentlichung eines Upgrades dieses nicht eingespielt haben. Es ist schade, aber etwa in diesem Bereich liegt die Anzahl von Nodes, die vom NY Kompromiss wohl abgehängt werden. Das ist bedauerlich, aber ich gehe davon aus, dass es der kleinere Preis im Vergleich zu einem weiteren Nichtstun ist.

Die Banken machen ein grosses Netzwerkupdate und schliessen die Filialen. Bedauerlich für die 17%, die die neue Infrastruktur nicht nutzen (können). Es ist bedauerlich, aber der Totalverlust für diese 17% ist ein kleiner Preis im Vergleich zum aktuellen technsichen Stillstand in der Bank-IT. Malta und Griechenland war also doch etwas ganz tolles. Bedauerlich für die wenigen, die dabei etwas verloren haben.

Ach ja, es gibt übrigens Migrationspfade (Soft-Forks). Das ist etwas komplett anderes als Nichtstun.
sr. member
Activity: 409
Merit: 286
Weil ich der Sache nicht traue. Ich befürchte die 2 MB werden in die Clienten so "reinüberrumpelt" , die 2 MB Hardfork gestartet und Segwit wird weiter verhindert.

Der Hard-Fork benötigt eine Umstellung aller Knoten. segwit wird dagegen mit allen alten Knoten sofort funktionieren. Es gibt auch noch genug Nutzer mit älteren Clients oder Nutzer ohne Core. Nirgendwo wird ein 2MB Hard-Fork einfach so funktionieren, d.h. die Hard-Fork Miner würden damit nur in ihrer eigenen kleinen Welt arbeiten.

Wurden denn bereits alle Nutzer überzeugt, spätestens zum Stichtag ihre Infrastruktur umzustellen?!

Warum setzen eigentlich alle voraus, dass alle ihre Systeme kurzfristig sofort umstellen (können)? Nur weil die eigene Welt direkt am Brett vor dem Kopf endet? Es hat durchaus einen Grund, warum die  komplette Welt nicht sofort und ausschliesslich IPv6, DNSSEC, DANE, SSL und IPSEC spricht. Aus diesem Grund gibt es üblicherweise immer einen Migrationspfad. Nur bei Bitcoin soll das jetzt anders sein?!


https://bitnodes.21.co/nodes/

Von 7300 Nodes sind 5200 bereit für SegWit - etwa ein halbes Jahr, nachdem die erste Version von SegWit herauskam.

Von den restlichen sind fast 700 Unlimited / Classic, haben also bewusst auf SegWit verzichtet.

Es bleiben also rund 1300 Nodes oder 17 Prozent, die auch ein halbes Jahr nach Veröffentlichung eines Upgrades dieses nicht eingespielt haben. Es ist schade, aber etwa in diesem Bereich liegt die Anzahl von Nodes, die vom NY Kompromiss wohl abgehängt werden. Das ist bedauerlich, aber ich gehe davon aus, dass es der kleinere Preis im Vergleich zu einem weiteren Nichtstun ist.

Ein ordentlicher Migrationspfad wäre es gewesen, bereits Anfang / Mitte 2015 eine Hardfork für 2017 einzuspielen, die die Blocksize auf 2 oder 4 MB erhöht. Wenn wir mal jeden Node ab v0.12 inklusive Classic und Unllimited nehmen, wären das etwa 6700. Das heißt, 600 Nodes oder 8 Prozent wären abgehängt. Ganz ohne Verluste geht es offenbar nicht.
full member
Activity: 235
Merit: 100
Ok, Leute,

diesen schönen Artikel von Jeff Garzik nehme ich zum Anlass, meinen UASF-Avatar zu entfernen:
https://medium.com/@jgarzik/a-personal-note-to-the-bitcoin-community-c24aa0821ab

Er versucht, die Core Devs für sich zu gewinnen, befürchtet aber, dass der 2 MB Hardfork sabotiert wird, wenn er Ihnen mit BIP91 entgegen kommt. Schade, dass Greg Maxwell auf Reddit dagegen anschreibt. Das Wesen eines Kompromisses ist hochintelligten Leuten leider oft nicht klar. Wäre schön, wenn ein paar umgängliche Core Devs wie Peter Todd, Peter Wuille, Cory Fields und einige der anonymen Core devs die Gelegenheit nutzen, die Seite zu wechseln.

Mittlerweile ist auch klar, dass die New York Consensus-Gruppe nicht gleich wieder zerfallen wird. An der geleakten Mail aus der Mailing-Liste sieht man, dass sich da feste Strukturen herausbilden. Wahrscheinlich wird da eine neue Bitcoin-Association daraus hervorgehen, bestehend aus den größten Unternehmen, die dann dem neuen Chief Developper Jeff Garzik Vorgaben macht, wie der Referenz-Client weiterentwickelt werden soll.
legendary
Activity: 2702
Merit: 1261
Weil ich der Sache nicht traue. Ich befürchte die 2 MB werden in die Clienten so "reinüberrumpelt" , die 2 MB Hardfork gestartet und Segwit wird weiter verhindert.

Der Hard-Fork benötigt eine Umstellung aller Knoten. segwit wird dagegen mit allen alten Knoten sofort funktionieren. Es gibt auch noch genug Nutzer mit älteren Clients oder Nutzer ohne Core. Nirgendwo wird ein 2MB Hard-Fork einfach so funktionieren, d.h. die Hard-Fork Miner würden damit nur in ihrer eigenen kleinen Welt arbeiten.

Wurden denn bereits alle Nutzer überzeugt, spätestens zum Stichtag ihre Infrastruktur umzustellen?!

Warum setzen eigentlich alle voraus, dass alle ihre Systeme kurzfristig sofort umstellen (können)? Nur weil die eigene Welt direkt am Brett vor dem Kopf endet? Es hat durchaus einen Grund, warum die  komplette Welt nicht sofort und ausschliesslich IPv6, DNSSEC, DANE, SSL und IPSEC spricht. Aus diesem Grund gibt es üblicherweise immer einen Migrationspfad. Nur bei Bitcoin soll das jetzt anders sein?!
sr. member
Activity: 548
Merit: 250
0x3f17f1962B36e491b30A40b2405849e597Ba5FB5
Erste mal hier den Link vor paar wochen gepostet mit 30 %


https://rolandkofler.github.io/flipper/


jetzt lecker verdoppelt schon...da waren meine 250 usd kursziel bis jahresende wohl zu Konservativ  Grin

Bitcoin hat uns die Villa gebracht aber ETH bringt Flugzeuge & Yachten  Grin


Bitcoin gerade im Minus 4 % und ETH 22 % ...aua

Da Flippen die chinesen wohl jetzt heftig heftig ...Vitalik redet ja in China mega konferenzen atm...

FOMO Flippping in China  Roll Eyes



ähm und was für Konferenzen hat Bitcoin gleich nochmal.. Luke gegen Roger  Roll Eyes    Grin

Maxwell gegen Jihan...oder Bergmann gegen die Core Segwit Fanatiker.




Während man vor paar wochen noch für je  5 BTC gemütlich 100-120 ETH bekommen hat´in exodus sind es jetzt nur noch 47 ETH.

Netter Kaufkraftverlust.   


Thank you very much Greg and Luke for doing your Job so perfectly. We Love Blockstream  <3 
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Was ich da technisch beschrieben habe beweist praktisch, dass die den Hard Fork nur um den Hard Fork willen haben wollen, aber es überhaupt nicht notwendig ist um den Speicherplatz für nicht Witness Daten zu schaffen.

Bei so einem Soft Fork müssten eben alle updaten - es werden sogar alle gezwungen zum updaten wenn mehr als 50% Hashing Power / Miner den von mir beschriebenen Soft Fork anwenden würden, den dieser Soft Fork wäre nur pseudo-rückwärtskompatibel.

Dafür würde man technisch sicherstellen können, dass Segwit + 2 MB gleichzeitig kommt.

Und schlechter als bei einem Hard Fork ist man auch nicht, da müssten auch alle updaten.

SPV Clients müssten allerdings zusätzlich die Coinbase TX auswerten (müssen die aber sowieso bei Segwit).

Um sich dagegen zu wehren müsste man einen ziemlich ausgefuxten Soft Fork oder Hard Fork durchführen. Alternativ geht es natürlich den  den 1. Block der den zuvor beschriebenen Soft Fork anwendet explizit hart kodiert im Programmcode als invalid zu markieren.

Unter der Annahme, dass die Mehrheit für Segwit+2MB ist, bzw. das als Kompromiss akzeptiert, wäre das Verfahren allerdings tragbar.
Ansonsten erzeugt man mit so einem "bösen" Soft Fork natürlich schnell einen Krieg (nicht, dass wir sowas ähnliches schon praktisch haben).
legendary
Activity: 1372
Merit: 1014
@Greshamsches Geld, Synthetic Fork oder sowas:

Man könnte sich den HF ja auch schenken und das gleiche als Soft Fork machen, ähnlich wie bei Segwit nur ein bisschen extremer:

Coinbase TX bekommt ein Merkle Tree Commitment für alle Transaktionen.
2 MB Block ist nicht sichtbar für alte Clients - die sehen im Block nur die Coinbase TX.

Man benutzt weiterhin das ganz normale UTXO (im Gegensatz zu Extension Blocks) und et voilà 2 MB Block Size ohne HF.
Automatisch Wipe-Out protection inklusive.

Dieses ewige bestehen auf HF macht mich etwas verrückt - da sitzen doch so viele schlaue Leute  Roll Eyes
Ich verstehe das technische nicht so sehr.
Ich glaube mezzo hatte vor kurzem auch so etwas in der Richtung geschrieben. Hab ich auch so verstanden, technisch geht schon was.


Hardfork ist für mich von Anfang an ein rotes Tuch gewesen.
Ein mal Tabubruch ist für mich Vertrauensverlust.
Am besten Big Blocker ignorieren. Haben bisher nur Boykott,  Streit und Druck gebracht.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
@Greshamsches Geld, Synthetic Fork oder sowas:

Man könnte sich den HF ja auch schenken und das gleiche als Soft Fork machen, ähnlich wie bei Segwit nur ein bisschen extremer:

Coinbase TX bekommt ein Merkle Tree Commitment für alle Transaktionen.
2 MB Block ist nicht sichtbar für alte Clients - die sehen im Block nur die Coinbase TX.
Der Block darf neben der Coinbase TX keine weitere TX haben die sichtbar für alte Clients ist.

Man benutzt weiterhin das ganz normale UTXO (im Gegensatz zu Extension Blocks) und et voilà 2 MB Block Size ohne HF.
Automatisch Wipe-Out protection inklusive, Segwit gleichzeitig aktiv.

Dieses ewige bestehen auf HF macht mich etwas verrückt - da sitzen doch so viele schlaue Leute  Roll Eyes
legendary
Activity: 1372
Merit: 1014
... Warum eigentlich?  Huh
Wenn du dich damit fragst, warum ich danach frage.
Weil ich der Sache nicht traue. Ich befürchte die 2 MB werden in die Clienten so "reinüberrumpelt" , die 2 MB Hardfork gestartet und Segwit wird weiter verhindert.
full member
Activity: 235
Merit: 100
Meiner Meinung nach ist das updaten müssen schon absichtlich.
Ich meine der Mechanismus über BIP91 bzw. BIP148 ist ja bekannt und liegt sogar als Quellcode vor.

Version bit 4 könnte einfach dafür sorgen, dass die Aktivierung über Bit 1 (Standard Segwit BIP141) erzwungen wird (also praktisch wie BIP148, aber ohne Flag Day, sondern Startzeitpunkt eben 2 Wochen, nachdem die 80% erreicht wurden).
Der einzige Nachteil den man dadurch hätte, wäre das Segwit 2 Wochen später käme, weil eben 2 Aktivierungen erfolgen.

Die Big Blocker fürchten natürlich das zu dem Zeitpunkt wo der Hard Fork dann erfolgen soll der Core Client aufgrund seiner Dominanz verhindert, weil viele zu dem Zeitpunkt dann der Meinung sein werden, dass man den 2 MB Hard Fork nicht wirklich braucht.

Ob man damit jetzt aber wirklich weiter kommt? Core könnte auch einen Client der das neue "Frankensegwit" (sorry aber ich finde den Namen so lustig) unterstützt veröffentlichen, ohne den Hard Fork einzubauen.

Würde mich zumindest nicht wundern.

Erst wenn der 2 MB Hard Fork Tag durch ist, wissen wir wirklich was Sache ist.

Immerhin kommt Segwit zuerst, was ich für vernünftig halte, da die Worst-Case und Avg-Case CPU-Laufzeit für einen Segwit Block wesentlich besser sein werden, als ein einfacher 2 MB Hard Fork Block - und so zudem bessere Aussicht auf neue Entwicklungen für Bitcoin Funktionalitäten besteht (Schnorr, LN & Co.).

Schön zusammengefasst, genau so ist es!
full member
Activity: 235
Merit: 100

Hallo Christoph,

jetzt fängst du schon wieder an, mit Expertennamen um dich zu werfen. Wir sind beide Laien auf dem Gebiet. Vor einigen Seiten hast du auf einen Artikel von Sergio Lerner verlinkt als Untermauerung deiner These. Ich habe den Artikel daraufhin inhaltlich aufgeschlüsselt und dargelegt, dass er eben überhaupt nicht das stützt, was du verbreitest.

https://bitcointalksearch.org/topic/m.18914671

Für den Rest habe ich leider keine Zeit, sorry. Du hast dich auch nicht an meine indirekte Bitte gehalten, das Thema Covert AsicBoost nicht schon wieder aufzurollen.


Gruß,
Rakete4



Sorry, solange du mit substanzlosen Anschuldigungen um dich wirfst, werde ich diesen mit Fakten begegnen.

Wenn du Bitmain Asicboost vorwirfst, dann erwarte ich, dass du in der Lage bist, eine Antwort auf alle von mir aufgezählten Fakten zu haben bzw. zumindest ausreichend Gegenargumente zu haben, die diese überwiegen. Ansonsten beteiligst du dich wider besseren Wissen an einer Verleumdung und es wäre besser, mit dem Asicboost-Quatsch aufzuhören und zuzugeben, dass man dich um den Finger gewickelt hast. Wenn du das nicht willst, erwarte ich, wie gesagt, ein Statement von dir zu den von mir dargestellten Punkten.


Man kann die Verwendung von Covert AsicBoost durch einen Miner nicht mathematisch "beweisen", das liegt in der Natur von Covert AsicBoost. Deswegen ja auch die Bezeichnung "Covert". Es gibt aber Indizien, und zwar viele, und die habe ich auch aufgezählt.

Und der von dir gepostete Artikel von Sergio Lerner widerlegt diese Indizien nicht. Du bist also derjenige, der faktenfrei argumentiert.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Soweit ich weiß ist der aktuelle Entwurf so, dass Segwit mit den 80% aktiviert wird und auch die 80% für die Aktivierung des HFs zuständig sind - im "schlimmsten" Fall kommt also beides gleichzeitig.

Wenn man das ganze ein bisschen absichern will könnte man den HF auch als Synthetic Fork durchführen - hab ich aktuell nichts mehr zu gelesen. Warum eigentlich?  Huh
Pages:
Jump to: