Da es hier um Sicherheit geht, klinke ich mich nochmal ein..
Zu 2. Es ist denke ich uns allen bewusst, dass die Hashpower der Miner dem Bitcoin wesentliche nein extremste nie dagewesene Sicherheit gibt. Mit einfachen Energie-Überlegungen (hardware, strom, maintenance) kommt man auf die enorme Potenz gegenüber allen off-chain Lösungen. Oder anders, wenn off-chain Lösungen annähernd dieselbe Sicherheit erreichen wollten, wie on-chain, dann müssten diese vergleichbare Energie aufwenden wie das on-chain Netzwerk + den Pegging Teil, den on-chain ja nicht hat. Ist das transparent ? Sicherheit kostet Geld Leute!
Ja - Aber Sicherheit vor wem? Vor allem vor "bösartigen Minern", Zensur und Double Spends? - Vor wem oder was noch?
Die Sicherheit des eigenen private Keys, oder die Sicherheit vor Hackern ist ja unabhängig davon.
Die dezentralisierten Off chain Transaktionen basieren ja auf On Chain Transaktionen, also erben diese bei entsprechendem Design die Sicherheit der On Chain Transaktionen.
Ggf. sind ein paar Anpassungen sinnvoll - vgl. Bcoin Extension Blocks mit Möglichkeit zur Kapazitätsreservierung.
Die Sicherheit vor Hackern ist sicher nicht schlechter als bei einem Hot-Wallet, womit es üblicherweise konkurrieren wird.
Jedenfalls senken dezentralisierte Off-Chain-Transaktionen nicht die On-Chain Sicherheit, wenn stattdessen überhaupt nicht Bitcoin benutzt werden würde, da sich neue Use-Cases ergeben.
Okay - War es ein contentious Hard Fork?
Wieviele Entwicklerteams waren dagegen? War der meist eingesetzte Client nicht zu dem Hard Fork kompatibel?
Wieviele Entwicklerteams gibt es überhaupt bei der Coin.
Gibt es mehrere politische Lager die sich bekämpfen?
Ist die Situation irgendwie mit Bitcoin vergleichbar?
Wie kann man bei Bitcoin ähnliche Voraussetzungen schaffen?
Hard Forks sind nicht grundsätzlich schlecht, aber wenn sie umkämpft sind, dann sind sie eben extrem schwierig und führen schnell zu zwei Chains.
Und wenn wir eben wie bei Bitcoin mittlerweile teilweise die Situation haben, dass die Lösungen der einen Gruppe grundsätzlich inakzeptabel für die ander Gruppe sind, dann müssen wir eben andere Wege finden.
Ich denke mir nur immer dabei - super das müsste einen Big Blocker doch freuen.
Einfach die Leute das aktivieren lassen, dann wird sich zeigen, dass es nicht reicht, falls es so sein sollte.
Die anderen Verbesserungen in Segwit sollten Grund genug sein das zu aktivieren.
Wenn das für normale Nutzer offensichtlich wird, dass es nicht reicht, ohne dass Sie sich entscheiden müssen, welcher Doktrin sie sich unterordnen wollen, dann gibt es auch Konsens für andere Optionen zum Beispiel solche, die einen Hard Fork erfordern.
Ehrlich gesagt habe ich mich auch schon bei dem Gedanken erwischt. Aber er ist einfach zu doof.
Wir gehen der Weg, der uns nicht zum Bahnhof führt (aber an der Kirche und anderen Sehenswürdigkeiten vorbei!), obwohl wir es wissen.
Was passiert danach? Ich denke mal, man wird uns die nächste Lösung präsentieren. Lightning, Mast, Schnorr? Müssen wir jeden Umweg ausprobieren, bevor wir die Blocksize erhöhen?
Es wäre sicher einfacher gewesen, wenn man Segwit frühzeitig aktiviert hätte. Ich find den Gedanken überhaupt nicht doof, sondern beruhigend.
Du weißt ja wie das mit Analogien bei Bitcoin ist - meine findest du ja auch nicht so toll - ich bin jetzt auch nicht von deiner begeistert, denn immerhin bewegen wir uns in die richtige Richtung und packen das in unseren Rucksack (Malleability Fix, etc.), was wir sowieso für unterwegs brauchen und uns schneller zum nächsten Ziel vorankommen lässt (Effizienzsteigerungen wie Schnorr - Senkung des benötigten Blockspaces).
MAST und Schnorr zusammen werden langfristig auch nicht genug bringen - die Frage ist eben, bringen sie zu dem Zeitpunkt wo sie kommen für die absehbare Zeit bis zur nächsten Maßnahme genug?
Wenn Segwit wirklich kurzfristig nicht reichen sollte, dann würden viele das eben auch nicht mehr glauben, dass die kleinen Maßnahmen ebenso reichen.
Ich glaub ich habs schon öfter gesagt, dass ich das nur im Zusammenhang mit Sidechains (insbesondere RSK) und Extension Blocks mittelfristig (die nächsten paar Jahre) für ausreichend halte.
Falls Sidechains und Extension Blocks nicht funktionieren, oder einfach nicht angenommen werden, lässt sich das zumindest auch relativ leicht rückgängig machen, entweder indem man direkt das UTXO Set kopiert, oder den Leuten bis zu einem bestimmten Zeitpunkt die Möglichkeit gibt ihre Bitcoins wieder in die Main-Chain zu übernehmen, während man das bei Segwit und Emergent Consensus Blocksize aus politischen und technischen Gründen nicht ohne massive technische und ökonomische Auswirkungen rückgängig machen können wird.
Er sagt, er will mit seinem Pool keine SW Transaktionen minen. Das ist ebenfalls kein Angriff, sondern die freie Entscheidung eines Pool-Betreibers. Aber wie Jihan und Roger schon sehen musste, reagiert ein Teil der Community mit sehr hässlichen Wutanfällen darauf, wenn Miner freie Entscheidungen treffen. Und schon gar nciht ist das ein Angriff gegen Second Layer Solution. Wenn überhaupt, dann gegen SW.
Ja es ist höchstens ein mittelbarer "Angriff", weil die 2nd Layer Technologien momentan auf Segwit aufbauen.
Ein Machtspiel ist es allerdings definitiv, weil er ökonomische Incentives dafür ignoriert. Das Bitcoin Protokoll gibt ihm allerdings diese Freiheit - soll er halt machen.
Für mich umso mehr ein Grund, dass ich lokal ein Bitcoin Node habe, da solche Maßnahmen für mich nicht das Vertrauen in die Miner stärken.
Ein Nutzer alleine kann nicht entscheiden, was die Anforderungen für einen Node sind. Das kann nur die Gesamtheit der individuellen Nutzer als Kollektiv. Und zu sagen, man hindert den Rest der Welt daran, Bitcoin zu benutzen, weil man selbst einen Raspberry behalten will, ist egoistisch. Wäre ein Fall von Tragedy of the Commons.
Ja es ist egoistisch, aber momentan gibt es meiner Meinung nach noch genug nicht ausgeschöpfte Maßnahmen.
Und wie wir sehen können hat es doch genug Einfluss, so dass die Miner nicht einfach einen Hard Fork durchgezogen haben.
Und im schlimmsten Fall - auch die Raspi entwickeln sich technisch weiter - und die Clients werden auch besser.
Tragedy of the commons spielt aber auch in die andere Richtungen - Maximierung des eigenen Ertrags auf Kosten der Anderen. Bei der Blockgröße ist sogar sehr offensichtlich, wenn die Miner einfach alles in die Blöcke schmeißen und einfache Nodes die Kosten dafür tragen - Nutzung von begrenztem Blockspace, wenn man die Transaktion nicht hätte On-Chain machen müssen, also wenn Kosten für die Nutzer der Blockchain höher ist, als der daraus entstehende gemeinsame Nutzen und damit die verbundene Wertsteigerung von Bitcoin.
Die Miner könnten ja auch an etwas arbeiten, damit normale Nodes entlohnt werden, so wie das bei RSK sein soll.
2. Wenn wir mal Rootstock nehmen - das ist merged mined, saugt also 0 Hashpower ab
Ja, das stimmt. Ich glaube, er weiß nicht, dass es Merged Mining gibt. Oder er hat es in einem abstrakteren Sinn gedacht, da auch die Sidechain in irgendeiner Weise Ressourcen von Nodes verlangt. Und LN saugt Gebühren von den Minern ab.
Dafür haben die Sidechains allerdings nicht mit der technical debt aus Satoshis Zeiten bei Bitcoin zu kämpfen, sondern können wesentlich effizienter arbeiten und gezielter optimiert werden
3. Ja das wird interessant - Es gibt Systeme, da kann man sich in der Theorie nicht erklären, warum sie funktionieren, aber in der Praxis funktionieren sie dann Problemlos - und es gibt Systeme, die theoretisch einwandfrei funktionieren sollten, aber in der Praxis scheitern. LN könnte beides sein - Es gibt ja Versuche beides mathematisch zu beweisen. Meine Meinung ist, dass wir es erst in der Praxis wissen können.
Eben. Du ahnst was ich jetzt sage: Daher lasst usn die Blcoksize ordentlich erhöhen und derweil an LN arbeiten. Wenn es klappt, freue ich mich. Solange ich aber höre "Wir brauchen keine Blocksize-Erhöhung, weil LN" werde ich nur wütend ...
Ja das LN definitiv die Lösung ist, ist auch aus meiner Sicht quatsch, ich kann mir aber gut vorstellen, dass es helfen kann, wenn seine Zeit gekommen ist. Andererseits denke ich da eher wie Andreas Antonopoulos, dass wir Scaling niemals abschließend lösen können, sondern das Scaling ein Ziel ist, dem man sich immer nur temporär annähern kann.
Edit:
Mir fällt da noch was ein.
Wäre es nicht ein Traum für die Anti-Core-Fraktion, wenn sich zeigen würde, dass Segwit Fehler enthält?
Noch ein Grund um Segwit zu aktivieren, wenn da doch so viel neuer Code mit so viel möglichen Bugs drin ist.
Damit könnte man wunderbar die Position der Core-Devs schwächen.
Man hat ja schließlich davor gewarnt, aber musste es ja leider auf Wunsch der Community aktivieren, deren Meinung so extrem durch Zensur beeinflusst wurde.
