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.
Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 85. (Read 185663 times)
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.
ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.
So ist es korrekt, nennt sich dann Konsens.
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^^
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^^
SEGWIT wird nie KOMMEN es war eine TOTGEBURT
Totaler Blockstream Crap Code .
Das ihr das immernoch nicht checkt hier
Totaler Blockstream Crap Code .
Das ihr das immernoch nicht checkt hier
Kurze Frage: Wieviel bekommst Du von Ver für Deinen Crap Talk hier?
SEGWIT wird nie KOMMEN es war eine TOTGEBURT
Totaler Blockstream Crap Code .
Das ihr das immernoch nicht checkt hier
Totaler Blockstream Crap Code .
Das ihr das immernoch nicht checkt hier
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. 
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... ;-)
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...
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.
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.
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.
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.
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.
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...
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
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.
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.
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...
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...
UASF ist die härtere Variante meines Vorschlags:
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?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.
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)
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/
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/
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.
UASF ist die härtere Variante meines Vorschlags:
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?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.
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.
ja Doc12 kannst ja gerne den POW Algo changen und mit den Blockstream Trotteln dann deinen eigenen Altcoin machen und dir dann den ganzen tag Payment Channel machen und deine BTC in der CLoud hinterlegen
Wenn Segwit und LN dann so super toll sind werden sicherlich alle den Coin nutzen wenn er so viele Vorteile bringt wie hier
immer so schön per Propaganda verbreitet wird .
Good Luck !
Wenn Segwit und LN dann so super toll sind werden sicherlich alle den Coin nutzen wenn er so viele Vorteile bringt wie hier
immer so schön per Propaganda verbreitet wird .
Good Luck !
Werden wir noch sehen wer hier den altcoin hält du clown.
Nee der Clown bist du eher du als wenn das nicht jeder sieht das diese Ganze Blockstream Funded Bank Take Over story
nicht von Weiter oben geplant und ausgeführt wurde damit wirklich jeder Depp glaubt Bitcoin hat mit den Rotschild und Rockefellern
nix zu tun. Dabei ist Bitcoin Part der Bargeldabschaffungs Agenda sonst wäre es schon längst Schlimmes Terror Geld und verpönt.
Bitcoin goes mainstream läuft alles wie geplant .
UNd wenn die massen an Bitcoin gewöhnt sind in paar Jahren kann man das Bargeld dann nach dem Wärhungscrash ganz weglassen
werden.
See ya in 2025 and zitiere mich dann wieder.
Genau Blockstream Funded Bank Rotschild Rockefellern, meine Fresse. Du bist so ein
Nein das wäre egtl eine Beleidigung für diese doch sehr klugen Primaten...
Der primat bist du eher dann gehe mal Merkel oder Schulz wählen und Believe ganz doll das sie wirklich was zu sagen haben .
Naja Leben lang Bildzeitung da kann man nichts machen sind halt verschiedenen generationen
oder wieso leihen wir uns von Rothschild EZB Geld gegen Zinsen . Kannst du mir das Erklären wieso die FED owned bei diesen Elite Familien ist und alle Präsidenten Sterben die sich kein Geld von der FED leihen wollen .
Ist bestimmt alles zufall genau wie dieses ganze Bitcoin gepushe im Mainstream aufeinmal und dem Wetlweiten Push im Bargeldverbot
auf der anderen Seite. Alles Zufall ja sicher ich glaube auch an den Osterhasen.
UASF ist die härtere Variante meines Vorschlags:
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?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.
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.
Jump to: