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

hehe, die Coffee-Attack: Wenn wir die Blocksize erhöhen, werden alle bayerischen Mütter und Omis ihren Kaffee in der Bäckerei mit Bitcoins bezahlen.

Ernsthaft: Hast du irgendeinen Grund für die Annahme, dass wir in 1-2 Jahren knapp 10 Millionen Transaktionen am Tag haben? Bisher scheint ein linearer oder schwach exponentieller Anstieg vorzuliegen, der die Blocksize alle 2 Jahre verdoppelt. Dementsprechend wäre die Blocksize in 2 Jahren bei 2mb, in 4 Jahren bei 4, in 6 bei 8, in 8 bei 16 und in 10 bei 32. Falls es so weitergeht. Kennst du einen Grund, weshalb wir dieses Schema plötzlich verlassen und eine Explosion zu erwarten haben, in denen die Blocksize nicht wie bisher alle 2 Jahre um den Faktor 2 erhöht, sondern um den Faktor 32? Oder war die Zahl einfach nur aus den Fingern gesaugter FUD gegen Onchain-Scaling?

Ja - dann muss man eben die Situation annehmen.
Aber nein, es wird seit Jahren rumgeheult, dass die Core Devs ja so gemein sind.
Das ist auch nicht KISS und vor allem nicht hilfreich.

Deswegen ist ein "einfacher" 2 MB HF ist ja nicht mal aus Entwicklersicht KISS konform, denn der Entwickler muss auf einmal erklären, warum 2 Bitcoins besser als 1 Bitcoin ist oder das kein Problem ist, dass jeder einzelne Benutzer manuell eingreifen muss. Mal abgesehen davon, dass eine Konsequenz auch ist, dass die SPV Client Entwickler jetzt erstmal Lösungen entwickeln müssen um die "Stealth-Hard-Forks" zu unterstützen.

UASF BIP 148 verstößt meines Erachtens ebenso gegen das KISS Prinzip, weil es extrem komplizierte Konsequenzen hat.

Wenn etwas sehr schlecht ist und das andere extrem schlecht, dann sind nicht unbedingt Lösungen, die wir verfolgen sollten.

Wir sollten uns darauf beschränken, was auch in der Vergangenheit funktioniert hat, vor allem aus Anwendersicht.
1 Bitcoin, Software weiter verbessern, so dass es für die Endanwender einfacher wird Bitcoin zu nutzen.
Wenn das nicht ohne größeren Entwicklungsaufwand geht, ist das vielleicht nicht schön, aber die Realität.

Segwit ist fertig entwickelt und getestet.
Das jetzt einfach zu nutzen, weil es schon da ist, entspricht dem KISS Prinzip, vor allem aus Sicht der Endanwender.

Edit:
Wenn wir wollen, dass Hard Forks so ablaufen, wie bei den Altcoins, dann müssen wir bei Bitcoin die Voraussetzungen dafür schaffen, dass dies eben auch so ist - also ein Hard Fork darf nicht umstritten sein.

Natürlich muss es wie bei SW SF Aktivierung genügend Consensus geben. Core (ex Luke) hat dies aber bisher verhindert und einen HF auf unbekannt verschoben.

Andere Cryptos zeigen dass HF geht. Evtl sogar regelmässig...

Komisch, dass viel HF hater mit UASF genau den HF riskieren?


PS: 'Glaub ich' gibts im Riskmanagment nicht.

Andererseits, vielleicht muss der Markt ja auch mal 2 coins durchspielen und dann hinterher einen bevorzugen. Wer weiss? Es ist nicht der Weltuntergang.

Das ist doch ein absoluter Trugschluss.
Resultat:
2 verschiedene Bitcoins
2 verschiedene Codebasen

Das ist sowas von extrem weit weg vom KISS Prinzip.

Segwit ist sicherlich komplizierter als ein 2 MB Hard Fork, aber viel einfacher als 2 verschiedene Bitcoins, kommt KISS also viel näher.

Edit es stellt sich immer die frage für wen "KISS":
Segwit:
Umstrittener Hard Fork - KISS für Entwickler, maximal kompliziert für alle anderen

Risikoabschätzungen sind heutzutage sehr mechanisch.

Bitcoin ist derzeit schon ein komplexes ! System, dessen Mechanik bez. Ursache und Wikrung nicht leicht zu Verstehend sind , insbesondere noch die exponetielle Wachstumsdynamik!

Was ist das Totschlag-Argument, dass immer gilt?  Keep it simple. Klare Schritte, keine neuen Layer oder gar neue Komplexizität einführen.

Ein Blocksize Increase mit HF erfüllt dies am sichersten.

Ich habe lange gekodet.

Hier gilt auch: Je klarer & kürzer der Code ist, desto besser kann er verstanden und modifiziert werden.
Skalierung kommt i.d.R. als Geschenk ( technischer Fortschritt ) mit oder ist eine sehr transparente Aufgabe, die bei diesem einfachen Code 'jeder' oder eine genügend grosse Allgemeinheit zusammen machen kann!

-> SW + Layer usw fällt da durch.

Das ist m.M. nach auch genau der Grund, dass grosse Miner und deren Riskmanagers SW nicht wollen.

Ich hab überhaupt nichts gegen On Chain, solange die Auswirkungen kontrollierbar bleiben.

Aber warum sollte man dann den mit Abstand schwierigsten und zerstörerischsten Weg nehmen, also einen umstrittenen Hard Fork mit sehr hohem Chain Split Risiko, der dazu führt dass es mehrere Bitcoins gibt?

Es gibt doch genug Alternativen - Segwit - Extension Blocks - Blocksize Soft Fork (mit etwas mehr Vorbereitungszeit ist das dann auch nicht unbedingt ein Evil-Soft Fork) - Sidechains - Off-Chain.

Und genug Altcoins mit den gewünschten Eigenschaften gibt es auch schon.

32 MB könnten wir in 1-2 Jahren doch locker füllen.

Und wenn klar ist, dass man auch 128 MB Blöcke haben könnte gibt es auch sicher neue Use-Cases, dass heißt, wir würden das auch in 3-4 Jahren easy schaffen die 128 MB Blöcke zu füllen. Unternehmen wie Amazon nehmen doch derzeit überhaupt kein Bitcoin an, weil alleine sich mit dem Zweck mehrere MB pro Block füllen ließen.

Und wie schön du das beschreibst, das eins nach dem anderen kommt.
Heißt das, dass wenn wir nicht automatisch langsam in so ein abhängiges System rutschen wollen, bereits jetzt Widerstand leisten sollten?

Ich meine Roger Ver sagt ja immer, dass wir nicht das an Bitcoin zerstören sollten, bei dem wir wissen, was funktioniert, sondern das machen sollten, was wir immer schon gemacht haben, wenn das auch in der Vergangenheit funktioniert hat.

Die Blockgröße wurde  in der Vergangenheit von Bitcoin ohne Hard Fork mehrmals angehoben. Wenn es Hard Forks gab waren diese nicht umstritten. Also sollten wir doch bei dieser Vorgehensweise bleiben.

Es war immer einfach genug einen eigenen Full Node auf dem eigenen Computer laufen zu lassen, so dass es viele gab und man als SPV Client sich keine Sorgen um die Sicherheit machen musste.

Bitcoin hatte immer den größten Netzwerkeffekt von allen Kryptowährungen.

Warum wollen wir diese Eigenschaften zerstören indem wir die Blockgröße mit einem umstrittenen Hard Fork anheben, der zu einem Chain Split führt und damit aktiv den Netzwerkeffekt untergräbt?

Warum bleiben wir nicht bei den Methoden, bei denen wir wissen, dass diese auch in der Vergangenheit funktioniert haben?
-Ein Netzwerk
-Ein Bitcoin
-Keine umstrittenen Forks, die zu Chain Splits führen können
-Erhöhung der Transaktions Kapazität

P.S.
Ich persönlich finde nicht, dass ein Full Node unbedingt noch auf einem Raspi laufen können muss


Warum sollten Shops nicht einfach Bitpay nehmen?
Die Maschine kostet ja nicht nur 20.000$ in der Anschaffung, sondern auch einen hohen, laufenden Unterhalt, z.B. Strom, Versicherung, Gebäude, Personal (Ingenieure) etc.

Der incentive für 20k$ Node betreiber ist z.B. für Geschäftsknoten, die z.B. 0Konf TXs damit absichern müssen.
Wenn nur 1% der Welt dies macht, ist das für alle 'kleinen' Konsumer perfekt.

Frage, welcher kleine betreibt denn selber einen Internetknoten, eMailknoten, VoIPknoten?
Wir müssen uns, mit der exponentiellen Skalierung, vom Gedanken 'Kleinuser macht alles' verabschieden...

Shops müssen bald verstehen, dass sie dadurch sicher ihr Geld bekommen, stornofrei.

Wie lange darf z.b. bei PayPal der Kunde seine zahlung stornieren?

In Zahlen ist das eine hohe Versicherungsprämie, die auf dauer eine teure Node locker armortisieren lässt.

Mind. 3 solche dicke fette Nodes sind 'bekannt' und in der Schweiz

Ernst&Young (E&Y)
Falcon Privat Bank
Swissquote

Die Frage ist seltsam. Die Blocksize-Debatte steht ja seit 2 Jahren still, weil man wegen Sorgen bezüglich der Zentralisierung keine größeren Blöcke erlauben will.


Die Antwort ist genauso seltsam. Wir wissen alle, dass Blöcke nicht über Nacht 120 Megabyte groß werden, sondern dass das ein gradueller Prozess ist. Man wird erstmal 2mb bekommen, dann 4, dann 8, dann 16 und so weiter. Bis aktuelle 1000$-Systeme da nicht mehr mithalten können, vergehen noch 5-10 Jahre (in denen es vermutlich eine gigantische Deflation der Hardware-Preise in BTC gibt ...)

Was ist die Alternative? Wenn du einen Full-Node für immer auf einem Raspberry oder einem Laptop laufen lassen kannst, wird Bitcoin voraussichtlich gescheitert sein. Das Datenvolumen und das UTXO sind kein technisches Problem, sondern ein Indikator für den Erfolg von Bitcoin. Gerade die Versuche, das UTXO durch Regulierung der Gebühren klein zu halten, sind meiner Meinung nach exemplarisch für eine falsche Denkweise. Wenn der Preis steigt und immer mehr Menschen Bitcoin benutzen, wird es unvermeidbar sein, dass wir die 18 Millionen Bitcoin oder so in immer kleinere Teile zerspalten.

Wenn es mal notwendig ist, dass wir 20.000$ Nodes haben und man einen Bitcoin-Provider brauchen wird - was noch eine Weile dauern wird - wird es weiterhin einen gigantischen Vorteil gegenüber dem heutigen System sein. Erstens weil du weiterhin deine privaten Schlüssel hast, und zweitens weil die "Bitcoin-Provider" in einem globalen Wettbewerb stehen und genauso wenig reguliert werden können wie die Video-Filehoster.

Wenn es zudem noch gelingt, irgendeine Art von Incentive für Node-Betreiber zu finden, so dass diese ein Stückchen Gebühr bekommen, wenn sie Transaktionen propagieren, etwa einfach indem der SPV-Node die Adresse eines public full nodes abfragt udn jeder Transaktion noch ein Stückchen output an diese hinzufügt, oder durch Payment-Channels, wie auch immer, wird es kein Problem mehr sein. Joinmarket ging in die richtige Richtung, wurde aber durch die Gebühren gekillt.

Schätze mal deine Zahlen genau auf die Zeit ab, realistscher Deckel oben ist z.B Visa, und dann dazu noch Moores Law Korrektur. Das reicht für ein paar Jahre on-chain, ohne dass wir murxen müssten...

Ja - ich weiß das es die aktuell gibt. Die Frage zielte in eine andere Richtung.
Wenn es nur noch wenige Full Nodes gibt, wird es dann das immer noch in der Form geben? Gibt es immer noch Full Nodes zu denen man sich kostenlos verbinden kann, oder muss man dann dafür bezahlen (weil kostenlose Nodes überlastet sind).

Unter welchen Umständen würde es kostenlos bleiben können? Bei sonstigen kostenlosen Diensten im Internet geht es immer darum entweder die Nutzerdaten abzugreifen und zu vermarkten, oder andere Produkte zu verkaufen, oder Werbeeinnahmen zu generieren. Die Dienste setzen bisher aber auch auf zentralisierte Plattformen, damit hätten wir dann aber auch keinen Vorteil mit sehr großen Blöcken, weil zentralisierte Services funktionieren auch mit der aktuellen Blockgröße.

Ist schon klar, dass das nicht von heute auf morgen passiert.
Wir haben ja jetzt die Situation, dass es noch so günstig ist einen Node laufen zu lassen, dass es genug Leute gibt die das einfach so machen.

Bei welcher Blockgröße kippt das?
Bereits bei 4-8 MB wird es zwar messbar sein, aber wann wird es kritisch - 32 MB sind schon über 1,5 Terrabyte pro Jahr.

Naja, was würden wir alle denn machen, wenn wir die 'Zentralisierung' schmecken?

Nun bei 87.1% (und 1ne Woche to go) das ist der zeitlich am nächsten liegende Entscheidungspunkt. Und es ist schon die Kompromisslösung, wobei ich befürchte bei der 2Mb Erhöhung die dann auch folgen muss gibt es wieder Kapriolen. Ab dem 25. erwarte ich eine Trendwende. Von Einkäufen jetzt oder gar noch coins halten ist aktuell abzuraten.


Gibt es schon, nennt sich Light Wallet, ist aber bisher noch optional. Aber die Leute haben sich bereits daran gewöhnt würde also Akzeptanz finden.
Das liegt wohl an den ganzen Anleitungen für neue User "wie kaufst du auf XYZ Market deinen Koks ein" da wird selten etwas von einer kompletten Blockchain downloaden erzählt, geht mehr in die Richtung sofot loslegen.

Würde mich auch interessieren.
Wie wird das, wenn es so ist wie in CSW Vision, dass ein Full-Node 20000$ kostet.
Muss man dann bezahlen um die Services von dem nutzen zu können?

Wird das dann so wie mit dem Usenet, dass man ein Bitcoin-Network-Provider braucht?

Ohja. Ich frag auch mal was:

Warum muss man sich eigentlich keine dauerhaften Sorgen bezüglich 'Zentralisierung' bei on-chain Skalierung machen?

Hier scheint einige Kompetenz vorhanden zu sein, dafür bin ich dankbar. Ich muss jedoch zugeben, selbst nicht mehr folgen zu können. Für Fragen bin ich noch nicht bereit, bei mir herrscht bzgl. Cryptos inzwischen Chaos im Kopf.

Lieber einmal mehr nachfragen, wenn es hilfreich ist.
Ist alles nicht immer so leicht zu verstehen vor allem wenn man die ganzen BIP Nummern nicht im Kopf hat. Wenn ich mich so viel damit beschäftige, dann kann es auch mal passieren, dass ich zu sehr mit den Details verliere und dann die einfache Verständlichkeit verloren geht.

Finde ich gut, wenn man nachfragt, falls man nicht alles verstanden hat.
Denn wenn man es selbst nicht verstanden hat, dann wird es wahrscheinlich auch andere in der Community geben, denen es genauso geht.
Der Thread enthält zwar sicher schon einiges, aber solange die Fragen sich nicht wiederholen gibt es sicher kein Problem.
Und ein gewisser Teil liest hier sicher auch einfach nur mit und die können dann auch davon profitieren.

sorry

Danke

tldr;
BIP148 und BIP91 sind beide nur BIPs, die dafür sorgen, dass es eine Koordination gibt um BIP141 Segwit zu aktivieren.


1. so ungefähr Segwit2x  enthält ein in den Zeitpunkten leicht abgeändertes BIP91 um das normale BIP141 Segwit zu aktivieren. BIP91 erfordert 80 % Hashpower - Start für das Miner Signaling 21. Juli, frühestens 23. Locked in, ab 25. aktiv
Segwit2x ist praktisch BIP91 + BIP141 + 2MB Hard Fork (der Hard Fork kommt ja aber erst später, wenn überhaupt)

2. Ja originale chain

Ergänzung zu 1.
BIP91 ab 25. aktiv würde bedeuten, dass dann nur noch Blöcke gültig sind, die das Bit für die Aktivierung von BIP141 Segwit signalisieren. Das heißt wir hätten zu 100% Blöcke die für die Aktivierung von BIP141 signalisieren.

BIP148 macht praktisch das gleiche, wie BIP91, nur das bei BIP91 die Miner vorher signalisieren.
Es geht darum, dass die Miner sagen können Sie hätten Segwit BIP141 aktiviert und nicht die User über BIP148.

BIP141 Segwit braucht eine Difficulty Periode (2016 Blöcke, ungefähr 2 Wochen) mit 95% aller Blöcke, die die Aktivierung Signalisieren, dann geht es in den "Locked In" Zustand. Eine Difficulty Periode später geht es dann in den aktiven Zustand.

Das heißt, bis wir Segwit nutzen können ist frühenstens Ende August, je nachdem, wann die Difficulity Perioden dann wirklich anfangen.