Ich würde sogar sagen, Transaction Malleabilty ist der Hauptgrund für SegWit. Die geänderte Berechnung der Transaktionsgrösse sehe ich nur als ein zusätzliches "Verkaufsargument".
Topic: SegWit startet heute! (Read 1494 times)
Ich bin zwar in der Materie nicht sehr tief drin daher ist mein Halbwissen mit Vorsicht zu genießen aber für eine Offchain ala Lightning braucht man doch den Fix für Transaction Malleability. Das bringt doch SegWit auch mit? D.h. auch dafür wird SegWit benötigt, nicht nur um die Skallierbarkeit direkt zu erhöhen.
Bin der Meinung umso früher es kommt umso früher kann man sich um andere Probleme kümmern.
Bin der Meinung umso früher es kommt umso früher kann man sich um andere Probleme kümmern.
Dringend wäre in meinen Augen ein Bug im Protokoll oder Sicherheitslücken in den Crypto-Algorithmen. Ein voller Mempool ist noch nicht besonders Aussagekräftig. Vorgestern waren z.B. in meinem Mempool nur noch 4000 TX und meine eigene TX mit ca. 300 Byte ist mit einer Fee von knapp 7000 Satoshi im nächsten Block gelandet.
Ich denke es ist egal ob wir 1 MB, 2MB, 4MB oder 8MB Blöcke haben. Die Blöcke werden eher früher als später trotzdem voll sein. Auf Dauer wird man für hohe Transaktionsvolumen und kleine Beträge um Side-Chain TX und/oder Off-Chain TX nicht mehr herum kommen.
Ich denke es ist egal ob wir 1 MB, 2MB, 4MB oder 8MB Blöcke haben. Die Blöcke werden eher früher als später trotzdem voll sein. Auf Dauer wird man für hohe Transaktionsvolumen und kleine Beträge um Side-Chain TX und/oder Off-Chain TX nicht mehr herum kommen.
Also es gibt Tage an denen ich, trotz hoher Transaktionsgebühren, sehr lange auf eine Bestätigung warte. Vor wenigen Tagen hat sich ein Backlog von fast 100.000 Transaktionen aufgebaut.
Es mag vielleicht nicht sehr dringlich sein aber eine kleine Dringlichkeit besteht definitiv.
Soweit ich gelesen habe gibt es doch garnicht soviele Anpassungen, die gemacht werden müssen? Evtl. die Berechnung der Transaktionsgröße anpassen um die Fees besser berechnen zu können aber über "zuviel" Fees freuen sich doch die Minern. Wüsste nicht was man groß anpassen müsste?
Es mag vielleicht nicht sehr dringlich sein aber eine kleine Dringlichkeit besteht definitiv.
Soweit ich gelesen habe gibt es doch garnicht soviele Anpassungen, die gemacht werden müssen? Evtl. die Berechnung der Transaktionsgröße anpassen um die Fees besser berechnen zu können aber über "zuviel" Fees freuen sich doch die Minern. Wüsste nicht was man groß anpassen müsste?
Nein, es sind im Augenblick nicht mal 20% der Blöcke mit dem entsprechenden BIP9 Bit. Da die Änderung nicht dringend oder unbedingt notwendig ist, muss eine eilige Umsetzung gar nicht sein. Es ist besser, wenn bei einer Umstellung möglichst viele Applikationen bereits mit den neuen Funktionen zurecht kommen.
Habe knapp über 20% ist doch noch meilenweit von den angestrebten 95% entfernt, oder habe ich da was falsch verstanden?
Inzwischen hat die segwit Signalisierungsphase übrigens begonnen.
Code:
"bip9_softforks": {
"segwit": {
"status": "started",
"bit": 1,
"startTime": 1479168000,
"timeout": 1510704000
}
}
"segwit": {
"status": "started",
"bit": 1,
"startTime": 1479168000,
"timeout": 1510704000
}
}
Ja, sobald die nächste Difficulty Anpassung erfolgt. Dann müsste in den entsprechenden Blöcken das Version-Bit 1 und damit die Block Version auf 0x20000002 gesetzt sein.
Das heißt wenn ein miner oder pool mit 0.13.1 mined wird automatisch segwit dadurch signalisiert?
Vermutlich wertet coin.dance nur die Coinbase-Erweiterung aus, während der SegWit Softfork nach BIP9 tatsächlich über die Version-Bits signalisiert wird.
Allerdings beginnt die BIP9 Signalisierung erst mit der nächsten Anpassung der Difficulty in ca. 18h.
Allerdings beginnt die BIP9 Signalisierung erst mit der nächsten Anpassung der Difficulty in ca. 18h.
Dann mal schnell ab auf die 0.13.1 :-)
Kurz und knapp: Malleability fixes und die Verschmälerung von Transaktionen, damit mehr in einen Block passen.
Ersteres ist zum Beispiel sehr interessant für Lightning. Genauer gesagt geht's darum Transaktionen nachträglich zu verändern so dass sich deren Inhalt zwar nicht aber die TXID ändert. Bin auch nicht soo tief drin. Zweiteres erhöht natürlich enorm die Kapazität von Blöcken. Meine um den Faktor 1,7-1,8 ohne dabei selber die Blockgröße anzuheben. Dadurch wird Bitcoin skallierbarer. Auch wenn die Blockgröße irgendwann angehoben werden sollte, profitiert man auch dann von SegWit.
Ausführlicher findest du es hier: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Laut den Statistiken ist segwit angeblich auf 2% runter gegangen. Kann es sein dass https://coin.dance/blocks etwas falsches misst?
Kurz und knapp: Malleability fixes und die Verschmälerung von Transaktionen, damit mehr in einen Block passen.
Ersteres ist zum Beispiel sehr interessant für Lightning. Genauer gesagt geht's darum Transaktionen nachträglich zu verändern so dass sich deren Inhalt zwar nicht aber die TXID ändert. Bin auch nicht soo tief drin. Zweiteres erhöht natürlich enorm die Kapazität von Blöcken. Meine um den Faktor 1,7-1,8 ohne dabei selber die Blockgröße anzuheben. Dadurch wird Bitcoin skallierbarer. Auch wenn die Blockgröße irgendwann angehoben werden sollte, profitiert man auch dann von SegWit.
Ausführlicher findest du es hier: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Laut den Statistiken ist segwit angeblich auf 2% runter gegangen. Kann es sein dass https://coin.dance/blocks etwas falsches misst?
Sorry für meine unwissenheit, kann mir jemand erklären was SigWit ist? Kurz und knackig...
Bin noch auf der 0.12...
Bin noch auf der 0.12...
Letztendlich haben die Pools eigentlich nix zu sagen.
Wenn sich ViaBTC wirklich quer stellen sollte, sind hoffentlich genug Miner bei Sinnen und wechseln von ViaBTC auf einen anderen Pool. Letztlich entscheidet jeder einzelne Miner für welchen Pool er mined.
Das kommt auch noch dazu. Gibt es dazu mehr Informationen, zum Beispiel wie man sowas macht? Betreibe mittlerweile einpaar Fullnodes.
Wenn sich ViaBTC wirklich quer stellen sollte, sind hoffentlich genug Miner bei Sinnen und wechseln von ViaBTC auf einen anderen Pool. Letztlich entscheidet jeder einzelne Miner für welchen Pool er mined.
Nicht solange ViaBTC ca. 10% der Hashleistung hat. Solange stellt das eine Sperrminorität dar. Allerdings kann jeder Knoten(betreiber) dem das nicht passt dagegen stimmen, indem er neue(!) Blöcke von ViaBTC nicht weiterleitet.
Das kommt auch noch dazu. Gibt es dazu mehr Informationen, zum Beispiel wie man sowas macht? Betreibe mittlerweile einpaar Fullnodes.
Die letzten neuen Core Features wurden von den Minern recht schnell angenommen. So ist aktuell CPFP (Core 0.13+) bei einigen Minern aktiv und führt dazu, dass man hängende Transaktionen (z.B. 0-Fee) nachträglich sehr schnell in einen Block bekommen kann.
Das wird wirklich spannend und wird sich eine ganze Weile hinziehen. Bleibt zu hoffen, dass es wirklich im Zeitrahmen passiert.
Erst wird es noch eine ganze Weile dauern bis alle Core-Miner wirklich SegWit einsetzen und dann gibt es noch die großen Gegner, allen voran ViaBTC, die aktuell weit über 5% der Miningpower beisteuern.
Ich fürchte, wenn wir uns endlich der 80%-Region nähern, werden die Gegner Forderungen stellen.
Vielleicht kommen aber auch einfach nur alle zur Besinnung und Ende des Jahres sind wir durch...
Erst wird es noch eine ganze Weile dauern bis alle Core-Miner wirklich SegWit einsetzen und dann gibt es noch die großen Gegner, allen voran ViaBTC, die aktuell weit über 5% der Miningpower beisteuern.
Ich fürchte, wenn wir uns endlich der 80%-Region nähern, werden die Gegner Forderungen stellen.
Vielleicht kommen aber auch einfach nur alle zur Besinnung und Ende des Jahres sind wir durch...
Nicht solange ViaBTC ca. 10% der Hashleistung hat. Solange stellt das eine Sperrminorität dar. Allerdings kann jeder Knoten(betreiber) dem das nicht passt dagegen stimmen, indem er neue(!) Blöcke von ViaBTC nicht weiterleitet.
Super, danke.
Mal schauen ob und vor allem wie schnell die 95% erreicht werden.
Mal schauen ob und vor allem wie schnell die 95% erreicht werden.
Hier gibt es statistische Daten: https://coin.dance/blocks
Quote
# Miners will be able to signal that they are willing and able to enforce segwit starting at the beginning of the first 2,016-block retarget period on or after 15 November 2016 (UTC).
Gibt es schon irgendwo statistiken wieviele Blöcke für SegWit gestimmt haben?
Quelle:
https://bitcoincore.org/en/2016/10/27/release-0.13.1/
Jump to: