MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 10, 2017, 12:36:36 PM Last edit: July 10, 2017, 04:03:45 PM by MoinCoin |
|
Payment-Channels sind schon heute möglich. Sind aber auch relativ naheliegenden Gründen ein totaler Flop.
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 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.
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. 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.
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.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
Rakete4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 10, 2017, 03:01:11 PM |
|
@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.
|
|
|
|
d5000
Legendary
Offline
Activity: 4004
Merit: 7088
Decentralization Maximalist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 10, 2017, 11:16:19 PM |
|
@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.
Dem schließe ich mich an! Hab viel gelernt ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 09:46:50 AM Last edit: July 11, 2017, 10:07:51 AM by MoinCoin |
|
Danke erstmal für die positiven Rückmeldungen ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) 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.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
Greshamsches Geld
Legendary
Offline
Activity: 1372
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 10:44:32 AM |
|
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?
|
|
|
|
MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 11:18:03 AM |
|
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.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
Greshamsches Geld
Legendary
Offline
Activity: 1372
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 11:23:57 AM |
|
Danke. Dem möchte ich mich auch anschließen. @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.
|
|
|
|
Z80
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 04:10:17 PM |
|
... Dem möchte ich mich auch anschließen. @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.
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!!! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
Es ist schwierig zu antworten wenn man die Frage nicht versteht...
|
|
|
I, Karus
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 70
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 04:16:51 PM |
|
Ich ebenfalls. Ist sehr lehrreich und dazu sehr objektiv geschrieben, trotz klar bestimmter Positionen. Mein Respekt für soviel Diskussionsdisziplin!
|
|
|
|
d5000
Legendary
Offline
Activity: 4004
Merit: 7088
Decentralization Maximalist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 06:25:00 PM |
|
Danke schon mal für die Rückmeldung MoinCoin! Kann mir nicht vorstellen, dass das ein echter Showstopper ist.
Habe mich jetzt etwas durch den Bandwurmthread des "Bugs" gelesen und komme inzwischen zur gleichen Schlussfolgerung. 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 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? Leute die unentschieden waren - wer weiß, wie sich das bei denen auswirkt.
Miner, die nur halbherzig für Segwit2x sind/waren, wären die kritische Gruppe. Muss man halt beobachten.
|
|
|
|
MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 11, 2017, 07:01:50 PM |
|
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?
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.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2017, 05:46:00 PM |
|
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.htmlhttps://github.com/btc1/bitcoin/pull/46
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
|
MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 12:09:42 PM |
|
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/WDhWkHxAlso ich warte jetzt erstmal die 10 Tage ab.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
Milquetoast
Legendary
Offline
Activity: 1620
Merit: 1030
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 12:57:03 PM |
|
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?
|
|
|
|
sofu
Legendary
Offline
Activity: 1890
Merit: 1085
Degenerate Crypto Gambler
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 02:24:55 PM |
|
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?
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
|
|
|
|
d5000
Legendary
Offline
Activity: 4004
Merit: 7088
Decentralization Maximalist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 06:47:36 PM |
|
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?
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!
|
|
|
|
Greshamsches Geld
Legendary
Offline
Activity: 1372
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 07:45:11 PM Last edit: July 13, 2017, 07:57:46 PM by Greshamsches Geld |
|
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/WDhWkHxAlso ich warte jetzt erstmal die 10 Tage ab. 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 Szenario 2: "Segwit2x" - kein Split im August, aber... beschrieben hat. und MoinCoin auch. Ich bin erstmal sehr zuversichtlich.
|
|
|
|
MoinCoin
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 08:03:08 PM |
|
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.
|
Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
|
|
|
Greshamsches Geld
Legendary
Offline
Activity: 1372
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 13, 2017, 08:07:29 PM |
|
tldr;
sorry Danke ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
|