Re: Der Aktuelle Kursverlauf blockgrösse

[Limx Dev]

UASF ist die härtere Variante meines Vorschlags:

Wobei eine Evolution machbar wäre - die Lösung wartet auf Aktivierung. Es zeichnet sich aber am Rande ab, dass das Pool-Mining das zentrale Problem (pun intended) an der Sache ist. D.h. die tatsächlich sinnvolle Lösung zur Änderung der Blockgrösse wäre eine Änderung des Hash-Algorithmus. Die sanfte Methode wäre, die entsprechenden Blockade-Miner in den Arsch zu treten indem  ihren Blöcken ein geringerer Stellenwert eingeräumt wird.

Während mein Vorschlag lediglich darauf abzielt, Blockade-Miner etwas auszubremsen, wirft UASF die Blockierer einfach aus dem Netz. Letztendlich ist beides eine mögliche und sinnvolle Option, da sich mehrere tausend Nutzer nicht von 3-4 Poolbetreibern erpressen lassen sollten.

Und wie willst du die Mehrheitsmeinung der User feststellen?

Bitcoin funktioniert immer noch so, daß dies per PoW geschieht. Die Miner entscheiden.

Bisher generieren die Miner die Blöcke, aber alle Knoten müssen diese Blöcke verifizieren. Wenn ich alleine, die Blöcke der Blockierer nicht mehr weiterleite, passiert gar nichts. Machen das sehr viele Knoten, dann verliert ein blockierender Miner immer mal wieder einen Block gegen einen Miner, der die Weiterentwicklung nicht blockiert. Er hat statistisch gesehen weniger Glück beim Finden von Blöcken und somit einen ökonomischen Nachteil.

Jeder Knoten kann sich ohne weitere Nachteile entscheiden, bestimmte Blöcke nicht mehr weiterzuleiten. Genauso wie ein Miner beliebige Transaktionen in einen Block aufnehmen kann, kann sich jeder Knoten entscheiden, welche Blöcke er weiterleiten möchte und welche nicht.

Theoretisch ein guter Ansatz. Das ablehnen von nur einen Block führt zu einen Fork beim Node oder zu einem Orphan beim Miner. Das verifizieren ist eigentlich nicht mehr als ein paar Prüfffunktionen die da durchlaufen insbesondere ob der Hash schwer genug ist und ob es zum nbits des Headers passt.

[1714802374]

1714802374

[1714802374]

1714802374

[mezzomix]

Das Verifizieren beinhaltet auch die Signaturprüfung aller Transaktionen im Block. Mein Vorschlag zielt aber gar nicht darauf ab, einen Block abzulehnen, sondern den unerwünschten Block nicht weiterzuleiten (Relay). Das führt erst dann zu einem Orphan, wenn es ein anderer Miner schafft, einen bevorzugten Block gleicher Höhe zu erzeugen.

[curiosity81]

Hier noch der Artikel zu BU-Blocks:

https://bitcoinblog.de/2017/03/07/antpool-erzeugt-ersten-bitcoin-unlimited-block/

Und der entsprechende Artikel was UASF ist:

https://bitcoinmagazine.com/articles/latest-twist-block-size-debate-called-uasf/

[molecular]

UASF ist die härtere Variante meines Vorschlags:

Wobei eine Evolution machbar wäre - die Lösung wartet auf Aktivierung. Es zeichnet sich aber am Rande ab, dass das Pool-Mining das zentrale Problem (pun intended) an der Sache ist. D.h. die tatsächlich sinnvolle Lösung zur Änderung der Blockgrösse wäre eine Änderung des Hash-Algorithmus. Die sanfte Methode wäre, die entsprechenden Blockade-Miner in den Arsch zu treten indem  ihren Blöcken ein geringerer Stellenwert eingeräumt wird.

Während mein Vorschlag lediglich darauf abzielt, Blockade-Miner etwas auszubremsen, wirft UASF die Blockierer einfach aus dem Netz. Letztendlich ist beides eine mögliche und sinnvolle Option, da sich mehrere tausend Nutzer nicht von 3-4 Poolbetreibern erpressen lassen sollten.

Und wie willst du die Mehrheitsmeinung der User feststellen?

Bitcoin funktioniert immer noch so, daß dies per PoW geschieht. Die Miner entscheiden.

Bisher generieren die Miner die Blöcke, aber alle Knoten müssen diese Blöcke verifizieren. Wenn ich alleine, die Blöcke der Blockierer nicht mehr weiterleite, passiert gar nichts. Machen das sehr viele Knoten, dann verliert ein blockierender Miner immer mal wieder einen Block gegen einen Miner, der die Weiterentwicklung nicht blockiert. Er hat statistisch gesehen weniger Glück beim Finden von Blöcken und somit einen ökonomischen Nachteil.

Jeder Knoten kann sich ohne weitere Nachteile entscheiden, bestimmte Blöcke nicht mehr weiterzuleiten. Genauso wie ein Miner beliebige Transaktionen in einen Block aufnehmen kann, kann sich jeder Knoten entscheiden, welche Blöcke er weiterleiten möchte und welche nicht.

Ja genau, das Node-Netzwerk kann das "orphaning risiko" für die Miner erhöhen. Dadurch ergibt sich die Möglichkeit, daß sich die Blockgrößte auf ein gesundes Maß einpendeln kann, sozusagen ein forwährender, verteilter Entscheidungsprozess wie groß die Blöcke sein dürfen. Der Miner muss entscheiden wie groß er den Block macht: sein Vorteil an mehr tx: mehr Gebühren, sein Nachteil: erhöhtes Risiko den gesamten Block reward + fees komplett zu verlieren. (Peter Rizun hat dies ja auch erarbeitet: ("A fee market exists without a blocksize limit": youtube, paper)

[butch3r]

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...

[Queenvio]

Glaube nicht, dass es dafür ein genaues Datum gibts. Entscheidend am Ende das Netzwerk.

Aber BU holt im Moment wieder auf, was die Debatte wieder anheizen wird.

Verstehe auch nicht, warum man BU nicht in de core implementiert, so müssen wir warten bis SW genug Zustimmung hat und dann evtl das gleiche Spiel noch mal mit eine. hardfork. Besser jetzt schon einbauen, dann ist die Verbreitung zu dem Zeitpunkt wo man es aktivieren will schon gegeben.

[Limx Dev]

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...

Ja gibt es ...ich glaube 1 Jahr nach update 13.1

[mezzomix]

Die Blocksize per Hard-Fork zu erhöhen ist überhaupt kein Problem. Lege einen Termin fest und hole die Zustimmung eines jeden Knotenbetreibers ein, dass er zu diesem Termin sein System auf die aktuellste Version umstellt. Bei manchen wird es nicht so einfach wie beim normalen Heimanwender, da dort weitere Infrastruktur läuft. Diesen Betreibern wird die Community sicher Hilfe in Form von Entwicklungsleistung/Geld anbieten.  

Wäre es so einfach, hättet ihr alle schon seit mindestens 10 Jahren IPv6 im Produktivbetrieb und wir hätten IPv4 schon abschalten können. Komischerweise machen die meisten immer noch IPv4 und kommen dann hier mit solchen komischen realitätsfernen Vorschlägen bezüglich der Blockgrösse. Man schaue sich https://bitnodes.21.co/nodes/ an. Wer soll diese Knoten alle kurzfristig umstellen und wer bezahlt dafür?!

Hinweis: Bei mir läuft seit über 15 Jahren IPv6 und ich habe mit einer sofortigen (1-2 Wochen damit ich die Patches einspielen/portieren kann) Umstellung der Blockgrösse auf bis zu 8MB auch kein Problem.

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun. Den Schuh darf sich nun derjenige anziehen, dem er passt. 

[molecular]

Glaube nicht, dass es dafür ein genaues Datum gibts. Entscheidend am Ende das Netzwerk.

Aber BU holt im Moment wieder auf, was die Debatte wieder anheizen wird.

Verstehe auch nicht, warum man BU nicht in de core implementiert, so müssen wir warten bis SW genug Zustimmung hat und dann evtl das gleiche Spiel noch mal mit eine. hardfork. Besser jetzt schon einbauen, dann ist die Verbreitung zu dem Zeitpunkt wo man es aktivieren will schon gegeben.

Richtig, es gibt kein Datum. BU hat auch kein aktivierungs-treshold. Sobald ein miner sich sicher genug fühlt, kann er einen 1.1 MB block minen und dann haben wir den hardfork (oder split, aber hoffentlich nicht). Das wird aber dauern... wird keiner machen ohne 75% oder wahrscheinlich noch viel mehr support sowohl von den anderen minern als auch von den nodes.

Segwit sieht nicht gut aus. Mal sehn ob core wirklich versuchen will das mittel UASF durchzuprügeln. Ich halte das für keine gute Idee.

Ich favorisiere folgende Lösung: die Entwickler tun sich zusammen und bauen "Segwit as HF + BU". Das wäre meiner Meinung nach Mehrheitsfähig (nach einem recht langen Weg, allerdings). Wenn da ein breit genuger Konsens erreicht werden kann, dann wäre das die Gold-Lösung und ohne große Gefahr einzuführen.

[molecular]

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...

Ja gibt es ...ich glaube 1 Jahr nach update 13.1

Ja, dann ist segwit abgelaufen (oder aktiviert). Aber das ist ja nicht das Ende der Debatte. Ist ja nicht so, daß dann automatisch BU eingeführt wird. Dann haben wir halt 1MB erstmal und immer noch Kapa-Probleme.

[molecular]

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun.

Ich hoffe du meinst nicht mich. Da müsste ich mich wehren und dann bekomme ich wieder ein zu großes Ego vorgeworfen... ;-)

[mezzomix]

Ich favorisiere folgende Lösung: die Entwickler tun sich zusammen und bauen "Segwit as HF + BU". Das wäre meiner Meinung nach Mehrheitsfähig (nach einem recht langen Weg, allerdings).

Also ich bin dagegen. segwit + einmalig 2-8MB wäre für mich kein Problem. Blankoschecks auf zukünftige Erhöhungen stelle ich nicht aus.

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun.

Ich hoffe du meinst nicht mich. Da müsste ich mich wehren und dann bekomme ich wieder ein zu großes Ego vorgeworfen... ;-)

Den Schuh darf sich nun derjenige anziehen, dem er passt. 

 

[commander11]

SEGWIT wird nie KOMMEN es war eine TOTGEBURT

Totaler Blockstream Crap Code .


Das ihr das immernoch nicht checkt hier 

[flora_digitalis]

SEGWIT wird nie KOMMEN es war eine TOTGEBURT

Totaler Blockstream Crap Code .


Das ihr das immernoch nicht checkt hier 

Kurze Frage: Wieviel bekommst Du von Ver für Deinen Crap Talk hier?

[commander11]

Ver  =?

Ich bin wohl der einzigste hier der liest was die Miner sagen und technisch Versierte User im gegensatz zu den Core Lemmingen hier

in der DE Community.^^


Ich mine mit 5 s9 Ants BU  und du  


ONE HASH ONE VOTE


Würde mal das Whitepaper lesen um Bitcoin zu verstehen an deiner Stelle^^

[mezzomix]

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

So ist es korrekt, nennt sich dann Konsens.

[ImI]

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

Mir wäre lieber ONE BTC ONE VOTE. Diejenigen welche auch tatsächlich Bitcoin halten sollen bestimmen wo es lang geht.

Auch die Umsetzung wäre extrem simpel, einfach abstimmen per signed Message und Problem gelöst.

Keine Miner und keine (nie gewählten oder sonstwie legitimierten)  Developer die über alles bestimmen.

[mezzomix]

Das wäre dann PoS (Proof of Stake). Damit gibt es dann aber wieder andere Probleme. Ist eben nicht alles schwarz oder weiss.

Mal abwarten, wie sich die Sache entwickelt.

[commander11]

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

Mir wäre lieber ONE BTC ONE VOTE. Diejenigen welche auch tatsächlich Bitcoin halten sollen bestimmen wo es lang geht.

Auch die Umsetzung wäre extrem simpel, einfach abstimmen per signed Message und Problem gelöst.

Keine Miner und keine (nie gewählten oder sonstwie legitimierten)  Developer die über alles bestimmen.

solche abstimmung gibts grad steht alles in Reddit ist 80  zu 20 %  kann jeder mit seinen Coins Signieren läuft aktuell sowas

einfach mal Ver Twitter schauen da war der link oder auf R btc

[mezzomix]

Ich mache gar nicht mit, weil ich das für sinnlos halte. Sollte BU nach  XT/Classic scheitern, dann werden wir bald darauf den nächsten "tolle" Hard-Fork präsentiert bekommen und dieselben Leute werden wieder die versuchen, die weitere Entwicklung zu blockieren.

Es ist relativ klar, dass aktuell >50% der Knoten mit segwit umgehen können und >99% der Knoten auch nach dem Soft-Fork ohne Veränderung mit dem System arbeiten können. Dagegen sind <10% der Knoten in der Lage mit einem Hard-Fork umzugehen. Diese Nutzer alle zum einem terminierten Update (Hard-Fork) zu zwingen halte ich für groben Unfug. Das Ganze kann nur den Zweck haben, die weitere Entwicklung zu blockieren.

Revolution (ein Hard-Fork) funktioniert mit keinem grösseren funktionierenden technischen System. Evolution (ein Soft-Fork) ist dagegen tägliche Praxis. Nicht Umsonst gibt es bis heute keine revolutionäre Umstellung von IPv4 auf IPv6. Kein grösseres Betriebssystem bekommt eine revolutionäre Umstellung der Schnittstelle hin, nach der sämtliche Software neu angepasst werden muss. Bei Geld sehe ich revolutionäre Änderungen noch kritischer. Trotzdem hätte ich persönlich kein Problem mit einer Änderung der Blockgrösse (bis 8MB) - gehöre damit aber vermutlich zur kleineren Gruppe unter den Bitcoin Nutzern.