Pages:
Author

Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 44. (Read 185830 times)

sr. member
Activity: 409
Merit: 286
Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.
Blödsinn. Der Mempool ist bei den allermeisten Knoten durch eine Konfiguration begrenzt (Core Default 300MByte). Sinnvollerweise aktzeptiert niemand (mehr) so lange Transaktionen, bis der Rechner aufgibt.
Ja, der Teil ist richtig. Dennoch wird eine 10 Prozent Chain nicht wirklich benutzbar sein.

100min statt 10min sind durchaus nutzbar. Ausserdem wird eine solche Chain schnell an Hash-Leistung gewinnen. Ich würde es darauf ankommen lassen, aber Jihan wehrt sich mit aller Gewalt dagegen. Warum wohl?


Warum sollte eine solche Chain an Hash rate gewinnen? Transaktionen, die keine obszöne Gebühr bezahlen, schaffen es gar nicht in den Mempool, der Rest muss 100-3000 Min auf eine Bestätigung warten, ein Großteil der User ist dank SPV nodes von dieser Chain abgeschnitten, und die Chain kann jederzeit durch die anderen Miner per 51-% Attacke angegriffen werden. Wenn die Coins auf dieser Chain überhaupt gehandelt werden, dann zu sehr viel niedrigeren Preisen. Daher machen die 10 Prozent der Miner die ersten 20 Wochen lang massive Verluste.

Sollte der Coin dieser Chain nach Ablauf von 20 Wochen noch existieren und mehr als 10 Prozent des anderen Coins wert sein, wird die Hash-Rate steigen. Das bedeutet, dass ein großer Teil der anderen Miner wechseln wird, es werden 5-6 Tage lang rasend schnell Blöcke entstehen, und danach, wenn sich die Schwierigkeit wieder anpasst, werden die Miner wieder wechseln, und wir haben erneut nur 30-50 Prozent Kapazität. Das Spiel kann sich ewig wiederholen ...

ich habe da recht lange darüber nachgedacht. Solange eine 10-Prozent Chain nicht den Algorithmus ändert, der die Difficulty anpasst, kann sie nur als Shitcoin überleben, aber nicht als ernstzunehmendes Zahlungsmittel.
legendary
Activity: 2702
Merit: 1261
Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.
Blödsinn. Der Mempool ist bei den allermeisten Knoten durch eine Konfiguration begrenzt (Core Default 300MByte). Sinnvollerweise aktzeptiert niemand (mehr) so lange Transaktionen, bis der Rechner aufgibt.
Ja, der Teil ist richtig. Dennoch wird eine 10 Prozent Chain nicht wirklich benutzbar sein.

100min statt 10min sind durchaus nutzbar. Ausserdem wird eine solche Chain schnell an Hash-Leistung gewinnen. Ich würde es darauf ankommen lassen, aber Jihan wehrt sich mit aller Gewalt dagegen. Warum wohl?
sr. member
Activity: 409
Merit: 286
Bleibt trotzdem dabei, dass man derzeit praktisch keinen Sicherheitsgewinn als SPV Node hat, wenn man die Signatur überprüft.

Das Problem wird leider größer, wenn wir einen Weg gehen, wo noch weniger Leute Anregungen haben Full Nodes laufen zu lassen.
Zudem ist die Kommunikation mit den SPV Nodes ist nicht kryptografisch abgesichert, also anfällig für MITM Angriffe - wie sollte man das auch absichern - dann würden wir wieder bei einem Vertrauens basierten Ansatz, wie bei https landen, den Bitcoin ja ersetzt.

Praktisch ist das also nur eine Frage der Zeit, bis sowas angegriffen wird.

Das einzige, was hilft ist, dass man einfach auf genug Bestätigungen für seine Transaktion wartet.

Wenn du heute SPV verwendest, muss jemand, der dich betrügt, einen validen Blockheader produzieren, soweit ich das verstanden habe, da Merkle tree, nur damit du die unbestätigte Tx als gültig ansiehst.

Wenn du mit SPV SegWit / Ext Blck Transaktionen akzeptierst, kann dir prinzipiell jeder eine gefälschte unbestätigte Tx unterjubeln, ohne dass du es nachprüfen kannst.

Faktisch bricht eine Softfork 0-confs von alten Clients und alten SPV nodes. Eine HF macht das nicht. Das kann man nicht kleinreden.

Quote
Das ist so etwas zu kurz gefasst - Auch SPV Nodes folgen der aus ihrer Sicht validen längsten Chain.

Luke JR hat vor kurzem erstmals ein BIP aufgesetzt, mit dem SPV nodes prüfen können, ob eine Chain bestimmten Regeln gehorcht. Das ist aber noch nicht umgesetzt. Daher ist, soweit ich weiß, für alle SPV nodes die längste Chain diie gültige Chain. Immer.

Quote
Es gibt aber eben auch viele Thin Clients, die auf eine feste Client / Server Architektur aufbauen, da ist es dann wieder vorbei mit dem Hard Fork, da für den Server das ein Hard Fork wäre, dem er nicht folgt.

Yepp. Zentralisierte Lightnodes können einer anderen als der längsten Chain folgen. Richtig.

Quote
Ja - Bei Electrum wählt er automatisch den Server mit der längsten Blockchain, egal ob die nun ungültig ist oder nicht, es wird nur der PoW überprüft - dazu darf das Headerformat natürlich nicht mit einem Hard Fork verändert werden.

Genau. Darum sind auch nicht alle Hardforks gleich. Eine Blocksize-Hardfork ist meiner MEinung nach viel weniger disruptiv als SegWit. Deswegen würde ich SegWit auch niemals als Hardfork akzeptieren.


Quote
Ich hab mich mittlerweile mit Segwit2x angefreundet, aber BU ist für mich ein mit offenen Augen ins Verderben rennen.
Dann benutze ich lieber wieder Euro, Gold und Aktien oder eine andere Kryptowährung.

Ich freu' mich ja, dass du mit SegWit2x einverstanden bist, da das die Lösung ist, die derzeit am wahrscheinlichsten ist. Ich find's nicht geil, aber sehr viel besser als der Status Quo und auch sehr viel besser als nur SegWit.

Warum für die BU das Verderben ist, verstehe ich nicht, aber wir diskutieren das schon so lange, daher mache ich mir wenig Hoffnungen, dich vom Gegenteil überzeugen zu können ... meiner Meinung nach ist das ein Beweis, das Propaganda wirkt, aber auch darüber möchte ich nicht streiten ... bin froh, dass ich hier seit ein paar Tagen mitdiskutiere, ohne wie noch vor einigen Wochen sofort von mehreren Leuten als "Feind des Bitcoins" beschimpft zu werden.
sr. member
Activity: 409
Merit: 286
Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.

Blödsinn. Der Mempool ist bei den allermeisten Knoten durch eine Konfiguration begrenzt (Core Default 300MByte). Sinnvollerweise aktzeptiert niemand (mehr) so lange Transaktionen, bis der Rechner aufgibt.

Ja, der Teil ist richtig. Dennoch wird eine 10 Prozent Chain nicht wirklich benutzbar sein.
sr. member
Activity: 409
Merit: 286
@rakete

schade, dass dir nichts anderes einfällt, als dich auf einen Teil meines Posts zu stürzen und mir dazu auch noch kognitive Dissonanz zu unterstellen. Mein Kommentar enthielt grob geschätzt zehn Argumente, von denen das von dir hinterfragte mit das unwichtigste war.

Denn ob es 10 oder 100 oder 1000 Miner gibt, ist an sich egal. Ist halt so. Wenn die Chain, die diese Miner bilden, vom Markt und den Usern akzeptiert wird, dann ist es die valide Chain. Punkt. Das ist die Realität, unabhängig davon, wie viele Miner es gibt. Wenn dir das nicht passt, und du meinst, wir brauchen Anti-Monopol-Gesetze, mit denen ein Kollektiv von Personen, die weder Work noch Stake vorweisen können, den Produzenten und Konsumenten vorschreibt, was sie zu tun haben, dann habe ich eine gute Nachricht für dich: Es gibt eine perfekte Währung für dich - den Euro.

Sorry, dass ich so angesäuert reagiere. Dass du dir einen einzigen Punkt aus meinem Post herauspickst und mir dann kognitive Dissonanz unterstellt war nicht nett. Abgesehen davon war dein Post recht informativ. Die Story mit Prohashing kannte ich noch nicht.

Übrigens: Alleine schon Slush hat 5.300 aktive User und insgesamt fast 20.000. Gibt also schon mehr als 10 Miner weltweit.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Ist dir ein Fall bekannt, in dem ein SPV Node betrogen wurde? Mir nicht. Ich kenne Firmen, die Electrum als Node benutzen.

Es gibt einen Angriff, der etwa so geht, dass sich 51 Prozent der Miner verschwören, um dir einen Double Spent unterzujubeln. Ich glaube, dafür braucht man Fraud Proofs. Bin mir hier aber nicht ganz sicher. Spielt in jedem Fall in einer komplett anderen Kategorie als Signaturen nicht prüfen zu können.

Beim einen muss ich einen bestätigen Input fälschen, also mindestens einen gültigen Blockheader verschwenden, um einen ungültigen Block zu bauen. Beim anderen muss ich dir lediglich eine Transaktion schicken.
Siehe noch mein Edit 2 vom letzten Beitrag:
Nein mir ist kein Fall bekannt.
Bleibt trotzdem dabei, dass man derzeit praktisch keinen Sicherheitsgewinn als SPV Node hat, wenn man die Signatur überprüft.

Das Problem wird leider größer, wenn wir einen Weg gehen, wo noch weniger Leute Anregungen haben Full Nodes laufen zu lassen.
Zudem ist die Kommunikation mit den SPV Nodes ist nicht kryptografisch abgesichert, also anfällig für MITM Angriffe - wie sollte man das auch absichern - dann würden wir wieder bei einem Vertrauens basierten Ansatz, wie bei https landen, den Bitcoin ja ersetzt.

Praktisch ist das also nur eine Frage der Zeit, bis sowas angegriffen wird.

Das einzige, was hilft ist, dass man einfach auf genug Bestätigungen für seine Transaktion wartet.

Das sind für mich einfach Punkte die Zeigen, wie wichtig es ist, dass möglichst viele Leute Full Nodes laufen lassen, damit wir nicht wieder bei einem Vertrauens basierten System landen.

SPV nodes folgen immer der längsten Chain. Also BU. Ausschließlich. Da ist kein Zufall im Spiel. Wenn es einen BU server für Electrum gibt, loggen sich alle clients bei dem ein.

Deswegen waren Ankündigungen von Börsen wie "Wir werden niemals BU akzeptieren" lächerlich, da sie damit einen recht großen Teil ihrer Kundschaft ausgesperrt hätten.
Das ist so etwas zu kurz gefasst - Auch SPV Nodes folgen der aus ihrer Sicht validen längsten Chain.
Aus Sicht mancher SPV Clients ist ein Block Size Hard Fork nicht mal ein Fork, wenn Sie diese Regel nicht beachten (sogar nicht mal ein Soft Fork).
Es gibt aber eben auch viele Thin Clients, die auf eine feste Client / Server Architektur aufbauen, da ist es dann wieder vorbei mit dem Hard Fork, da für den Server das ein Hard Fork wäre, dem er nicht folgt.

Ja - Bei Electrum wählt er automatisch den Server mit der längsten Blockchain, egal ob die nun ungültig ist oder nicht, es wird nur der PoW überprüft - dazu darf das Headerformat natürlich nicht mit einem Hard Fork verändert werden.

Quote
Quote
Dann kommt es eben zum Chain Split - egal ob das jetzt ein zweiter Hard Fork oder Soft Fork oder was auch immer wird.
Selbst 100% der Hash Power reichen nicht aus, wenn ein nicht unerheblicher Teil das Wesen des Bitcoins als verraten sieht.

Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.

Ein Chain Split passiert mit einer UASF. Ja. Aber nicht mit einer ordentlich durchgeführten Miner-Fork.
Das trifft nur auf Clients mit alter Codebase wie BU zu - Core braucht in der Standard-Einstellung nie mehr als 300 MB für den Mempool.
Ich kann da nur wiederholen - BIP148 ist meiner Meinung zu aggressiv und kein normaler UASF - BIP149 als UASF erzeugt keinen Chain Split.
Ich hab mich mittlerweile mit Segwit2x angefreundet, aber BU ist für mich ein mit offenen Augen ins Verderben rennen.
Dann benutze ich lieber wieder Euro, Gold und Aktien oder eine andere Kryptowährung.
legendary
Activity: 2702
Merit: 1261
Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.

Blödsinn. Der Mempool ist bei den allermeisten Knoten durch eine Konfiguration begrenzt (Core Default 300MByte). Sinnvollerweise aktzeptiert niemand (mehr) so lange Transaktionen, bis der Rechner aufgibt.
full member
Activity: 235
Merit: 100
Zudem gibt es vielleicht 10 Mining-Pools, aber sehr viel mehr Miner. Ich verstehe nicht warum, aber leider hat sich dieses Vorurteil, dass mit BU die MIner die Blocksize diktieren, eingebrannt. Es ist aber einfach nur falsch.

Hallo Christoph,

wenn dir nicht klar ist, dass bei ca. 10 großen Minern und ca. 1.000.000 Usern das Emergent Consensus System die Machtbalance zugunsten der Miner verschiebt, dann solltest du dich dringend mit Dingen wie Spieltheorie oder Kommunikationswissenschaft beschäftigen. Eigentlich weiß man das auch intuitiv ohne irgendwelche Theorien zu wälzen.

10 Personen können untereinander eine Abmachung treffen, 1.000.000 können das nicht so ohne weiteres.

Und wenn du wirklich glaubst, dass die großen Mining pools jeweils aus einer großen Zahl an unabhängigen Minern bestehen, die da jeweils ihre Hashrate bündeln, dann: Täum weiter.

Für einige wenige Mining-pools mag das tatsächlich so sein, aber in der Regel kommt der Großteil der Hashrate je Pool von einem Mining-Unternehmen.

Kennst du den Litecoin-Mining-Pool Prohashing? Vermutlich ja, weil der Pool-Operator auf der Seite der Big-Blocker war oder noch ist. Sein Name fällt mir gerade nicht ein. Ein sympathischer Typ soweit ich gesehen habe.
Prohasing ist ein Multipool, der das Maximum an Profitabilität für seine Kunden herausholt, indem er zwischen verschiedenen Scrypt-Coins hin-und-her wechselt. Im Zusammenhang mit der Segwit-Aktivierung bei Litecoin hat dieser Pool Operater im Litecoin-Reddit geschrieben, dass 55% seiner Hashrate von zwei Kunden kommt, und diese beide für Segwit signalisieren wollen. Deswegen hat er damals dann ankündigt, für Segwit zu signalisieren, obwohl er von Segwit eigentlich nicht viel hielt.

Wenn also sogar bei so einem Profit-Maximierenden Pool nur zwei Miner 55% der Hashrate stellen, ist doch klar, das bei den größeren Pools noch weniger Miner die Hashrate stellen. Für die großen Miner lohnt es sich nämlich nicht, zwischen verschiedenen kleinen Coins zu wechseln, weil die Hashrate die Difficulty zu stark nach oben treiben würde.

Ich kann dir die Links gerne raussuchen, spare mir die Zeit aber vorest, da ich bei dir bewusste oder unterbewusste Realitätsverweigerung vermute. Es gibt dafür den Begriff Kognitive Dissonanz:
https://de.wikipedia.org/wiki/Kognitive_Dissonanz
Die Kognitive Dissonanz fällt auch bei anderen Themen wie Covert Asicboost und Antbleed auf, wenn man die beiden Reddits vergleicht.

Gerade du als Bitcoin-Journalist solltest deine Überzeugung hin- und wieder mal möglichst unvoreingenommen mit der Realität abchecken. Ok, du hast bisher deine eigene Überzeugung in deinen Artikel auf Bitcoinblog weitgehend aussen vor gelassen, aber dennoch wäre das sinnvoll.

Gruß,

Rakete4
sr. member
Activity: 409
Merit: 286

Das Problem ist aber als SPV Node teilweise egal, da man als SPV-Node sowieso nicht vor Double-Spends geschützt ist, ohne dass die Blockchain verlängert wurde mit neuen Blöcken, da man überhaupt nicht mitbekommt, dass ein Double-Spend versucht wird.
Auch kann man als SPV Node überhaupt nicht feststellen, ob die Bitcoins, die man erhält überhaupt echt sind - von daher bringt das verifizieren der Transaktion auch nichts. Man kann ja auch eine echte Signatur zu falschen Bitcoins haben.

Edit:
Bin mir nicht ganz sicher, ob das stimmt mit den gefälschten Bitcoins - Die Double Spend Problematik ist jedenfalls Real - ggf. kann man den Outpoint allerdings beweisen indem man einen Pruned Merkle Tree vom entsprechenden Block beim Full-Node anfordert, der beweist, dass der Output existiert - allerdings kann man so nicht beweisen, dass dieser nicht bereits ausgegeben wurde - das müsste der Full-Node dann einem als Fraud-Proof zusenden - soweit ich weiß haben wir aber keine Fraud-Proofs.

Ist dir ein Fall bekannt, in dem ein SPV Node betrogen wurde? Mir nicht. Ich kenne Firmen, die Electrum als Node benutzen.

Es gibt einen Angriff, der etwa so geht, dass sich 51 Prozent der Miner verschwören, um dir einen Double Spent unterzujubeln. Ich glaube, dafür braucht man Fraud Proofs. Bin mir hier aber nicht ganz sicher. Spielt in jedem Fall in einer komplett anderen Kategorie als Signaturen nicht prüfen zu können.

Beim einen muss ich einen bestätigen Input fälschen, also mindestens einen gültigen Blockheader verschwenden, um einen ungültigen Block zu bauen. Beim anderen muss ich dir lediglich eine Transaktion schicken.

Quote
Das ist ansich richtig, aber du vertraust hier auf zufälliges verhalten - mal wird es funktionieren mal nicht.
Denn das Problem ist ja, dass es zufällig ist, ob man überhaupt auf der Chain landet, oder bei anderen Clients die nicht der Blockchain folgen.
Bei der aktuellen sehr geringen anzahl an BU-Nodes ist es sogar sehr wahrscheinlich, dass man eben nicht dem Hard Fork folgt, egal wieviel Hash Power der hat.

SPV nodes folgen immer der längsten Chain. Also BU. Ausschließlich. Da ist kein Zufall im Spiel. Wenn es einen BU server für Electrum gibt, loggen sich alle clients bei dem ein.

Deswegen waren Ankündigungen von Börsen wie "Wir werden niemals BU akzeptieren" lächerlich, da sie damit einen recht großen Teil ihrer Kundschaft ausgesperrt hätten.

Edit: Vergiss den zweitletzten Absatz. Da habe ich wieder schneller geschrieben als gedacht. Du hast recht. Bei echten SPV-Nodes wie BitcoinJ ist der Zufall mit im Spiel, da die Nodes ja erstmal Kontakt zu einem BU node haben müsse. Und wenn nur jeder 10. Node BU ist, könnte es sein, dass er das nicht hat.

Quote
Dann kommt es eben zum Chain Split - egal ob das jetzt ein zweiter Hard Fork oder Soft Fork oder was auch immer wird.
Selbst 100% der Hash Power reichen nicht aus, wenn ein nicht unerheblicher Teil das Wesen des Bitcoins als verraten sieht.

Ja, wenn ein nicht unerheblicher Teil meint, dass eine Fork Bitcoin ruiniert, etwa indem KYC eingeführt wird oder so, ja. Daher haben die Miner ja auch noch nicht geforkt, und daher übergibt BU auch nicht den Minern die komplette macht. Aber rechne einfach mal selbst aus, was passiert, wenn 90 Prozent der Miner forken und es keine Replay Protection gibt. Anstatt 144MB verarbeitet die Chain nur 14MB am Tag, und es dauert 20 anstatt 2 Wochen, bis sich die Difficulty anpasst. Bis dahin sind nur noch Nodes mit mehr als 30 Gigabyte Ram in der Lage, den Mempool zu bändigen. Wenn überhaupt ... es wird etwa 30 Mio unbestätigte Transaktionen geben ... keine Börse und kein User wird diese Chain benutzen wollen.

Ein Chain Split passiert mit einer UASF. Ja. Aber nicht mit einer ordentlich durchgeführten Miner-Fork.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Ok.

Man kann von SW / ExtBl Addr. aus an Light/SPV nodes senden. Allerdings können die SPVs nicht die Signatur solcher Transaktionen verifizieren, richtig?

Was Light/SPV-Nodes ferner nicht können, ist, die neue Kapazität zu nutzen, die SW/ExtBl bietet, da sie weder sparsamere SW-Tx noch Ext-Tx bilden können. Es ist ihnen auch nicht möglich, Bitcoins an native SW-Adressen sowie an Ext-Adressen zu senden.

Aber an sich funktionieren sie weiter.
Ja, wenn man seinen SPV nicht updated.
Das Problem ist aber als SPV Node teilweise egal, da man als SPV-Node sowieso nicht vor Double-Spends geschützt ist, ohne dass die Blockchain verlängert wurde mit neuen Blöcken, da man überhaupt nicht mitbekommt, dass ein Double-Spend versucht wird.
Auch kann man als SPV Node überhaupt nicht feststellen, ob die Bitcoins, die man erhält überhaupt echt sind - von daher bringt das verifizieren der Transaktion auch nichts. Man kann ja auch eine echte Signatur zu falschen Bitcoins haben.

Edit:
Bin mir nicht ganz sicher, ob das stimmt mit den gefälschten Bitcoins - Die Double Spend Problematik ist jedenfalls Real - ggf. kann man den Outpoint allerdings beweisen indem man einen Pruned Merkle Tree vom entsprechenden Block beim Full-Node anfordert, der beweist, dass der Output existiert - allerdings kann man so nicht beweisen, dass dieser nicht bereits ausgegeben wurde - das müsste der Full-Node dann einem als Fraud-Proof zusenden - soweit ich weiß haben wir aber keine Fraud-Proofs.
Edit2:
https://en.bitcoin.it/wiki/Thin_Client_Security
Ja - es ist praktisch nutzlos als Thin Client die Signatur zu überprüfen, solange es kein Unused Output Tree und Fraud Proofs gibt, solange man nicht sicher weiß, dass die Full Nodes zu denen man verbunden ist 100% vertrauenswürdig sind. Und falls diese vertrauenswürdig sind, werden diese bereits die Signatur für einen überprüft haben (egal ob Segwit oder nicht), sonst hätten diese die Tx nicht weitergeleitet.


Quote
Quote
Hard Fork, Evil Soft Fork oder Chain Split -> SPV Node funktioniert nicht, oder landet auf einer zufälligen Chain -> Update der SPV Node unbedingt erforderlich

Hier muss ich vehement widersprechen. Jeder SPV nodes wird im Falle einer Blocksize-Hardfork einfach weitermachen wie bisher, da sie nur Header und Tx brauchen. Beides bleibt dasselbe. Im Gegensatz zu einer Softfork kann ein SPV / Lightnode im Falle einer Blocksize-HF aus dem Stand heraus deren volle Kapazitätsgewinne nutzen.

Dementsprechend bleibe ich dabei, dass eine Blocksize-Hardfork für SPV / Light-Nodes viel unkomplizierter ist als eine Softfork für SW / Ext. Blocks.

Das war ja auch das witzige mit Electrum. Ein Electrum Client dockt einfach nur an die längste Chain an, die von Electrum Servern bereitgestellt wird. Ironischerweise folgt Electrum daher einer BU-Fork, obwohl der Entwickler, Thomas Voegtlin, vehement gegen BU ist. Dasselbe trifft auf ALLE dezentral organisierten SPV / Light-Nodes zu. Lediglich zentralisierte Modelle, wie GreenAddress oder Mycelium, bei denen die User der Chain folgen, die eine Firma verordnet, sind in der Lage, nicht der längsten Chain (also BU) zu folgen.
Das ist ansich richtig, aber du vertraust hier auf zufälliges verhalten - mal wird es funktionieren mal nicht.
Denn das Problem ist ja, dass es zufällig ist, ob man überhaupt auf der Chain landet, oder bei anderen Clients die nicht der Blockchain folgen.
Bei der aktuellen sehr geringen anzahl an BU-Nodes ist es sogar sehr wahrscheinlich, dass man eben nicht dem Hard Fork folgt, egal wieviel Hash Power der hat.


Quote
Quote
Es gibt nun mal nicht die perfekte Lösung um alle glücklich zu machen:
Die Alternative 2 Blockchains - 1 für Big Blocker und 1 für Small Blocker macht das gleiche, außer das man zusätzlich noch mit unterschiedlichen Währungen (BTC-A, BTC-B) arbeitet.

Auch hier, Widerspruch: Eine mit 90 Prozent der Miner aktivierte Hardfork wird nicht in zwei Chains oder zwei Währungen münden. Sie wird damit enden, dass wir eine größere Blocksize haben (sagen wir, 2 oder 4 oder 8 MB). Wäre meiner Meinung nach die perfekte Lösung, auch wenn die die von Mezzomix erwähnen Update-Schwierigkeiten respektiere.
Dann kommt es eben zum Chain Split - egal ob das jetzt ein zweiter Hard Fork oder Soft Fork oder was auch immer wird.
Selbst 100% der Hash Power reichen nicht aus, wenn ein nicht unerheblicher Teil das Wesen des Bitcoins als verraten sieht.
sr. member
Activity: 409
Merit: 286
Ok.

Man kann von SW / ExtBl Addr. aus an Light/SPV nodes senden. Allerdings können die SPVs nicht die Signatur solcher Transaktionen verifizieren, richtig?

Was Light/SPV-Nodes ferner nicht können, ist, die neue Kapazität zu nutzen, die SW/ExtBl bietet, da sie weder sparsamere SW-Tx noch Ext-Tx bilden können. Es ist ihnen auch nicht möglich, Bitcoins an native SW-Adressen sowie an Ext-Adressen zu senden.

Aber an sich funktionieren sie weiter.

Quote
Hard Fork, Evil Soft Fork oder Chain Split -> SPV Node funktioniert nicht, oder landet auf einer zufälligen Chain -> Update der SPV Node unbedingt erforderlich

Hier muss ich vehement widersprechen. Jeder SPV nodes wird im Falle einer Blocksize-Hardfork einfach weitermachen wie bisher, da sie nur Header und Tx brauchen. Beides bleibt dasselbe. Im Gegensatz zu einer Softfork kann ein SPV / Lightnode im Falle einer Blocksize-HF aus dem Stand heraus deren volle Kapazitätsgewinne nutzen.

Dementsprechend bleibe ich dabei, dass eine Blocksize-Hardfork für SPV / Light-Nodes viel unkomplizierter ist als eine Softfork für SW / Ext. Blocks.

Das war ja auch das witzige mit Electrum. Ein Electrum Client dockt einfach nur an die längste Chain an, die von Electrum Servern bereitgestellt wird. Ironischerweise folgt Electrum daher einer BU-Fork, obwohl der Entwickler, Thomas Voegtlin, vehement gegen BU ist. Dasselbe trifft auf ALLE dezentral organisierten SPV / Light-Nodes zu. Lediglich zentralisierte Modelle, wie GreenAddress oder Mycelium, bei denen die User der Chain folgen, die eine Firma verordnet, sind in der Lage, nicht der längsten Chain (also BU) zu folgen.

Sprich: jede Form von dezentralen SPV wallets ist vollumfänglich mit BU kompatibel, während Softforks wie Ext Blocks / SW ihre Funktionalität deutlich beeinträchtigen.

Quote
Es gibt nun mal nicht die perfekte Lösung um alle glücklich zu machen:
Die Alternative 2 Blockchains - 1 für Big Blocker und 1 für Small Blocker macht das gleiche, außer das man zusätzlich noch mit unterschiedlichen Währungen (BTC-A, BTC-B) arbeitet.

Auch hier, Widerspruch: Eine mit 90 Prozent der Miner aktivierte Hardfork wird nicht in zwei Chains oder zwei Währungen münden. Sie wird damit enden, dass wir eine größere Blocksize haben (sagen wir, 2 oder 4 oder 8 MB). Wäre meiner Meinung nach die perfekte Lösung, auch wenn die die von Mezzomix erwähnen Update-Schwierigkeiten respektiere.

Quote

BU/EC setzt auf einen Konsens der Miner. Das ist unter den aktuellen Bedingungen (10 Miner, viele tausend Nutzer) nicht ausreichend.

Nein, wie oben schon erwähnt und dadurch bewiesen, dass die Miner weiterhin noch nicht geforkt haben: nein. BU/EC setzt auf einen Konsens von Minern UND Usern. Zudem gibt es vielleicht 10 Mining-Pools, aber sehr viel mehr Miner. Ich verstehe nicht warum, aber leider hat sich dieses Vorurteil, dass mit BU die MIner die Blocksize diktieren, eingebrannt. Es ist aber einfach nur falsch.

 
legendary
Activity: 2702
Merit: 1261
BU setzt auf dieses Konsens-Modell, während die UASF verlangt, dass eine auf keine Sybil resistente Weise zu bestätigende "Mehrheit" der User ihren Willen gegen die Miner durchsetzt.

BU/EC setzt auf einen Konsens der Miner. Das ist unter den aktuellen Bedingungen (10 Miner, viele tausend Nutzer) nicht ausreichend. Technisch gesehen ist UASF ebenfalls kein grosser Wurf und ausserdem ist der Zeitrahmen sehr knapp bemessen. Um eine dauerhafte vollständige Blockade zu umgehen ohne die freundlichen Miner rauszuwerfen ist es trotzdem geeignet. Die harte Lösung wäre, sich neue Miner zu suchen, wenn die alten gegen die Nutzer arbeiten (Mining Algorithm Change). Damit trifft man dann allerdings neben den feindlichen Minern auch die freundlichen.

SPV nodes: Jetzt wird es interessant. Meine Meinung war, dass sowohl SegWit als auch Ext Blocks für alle SPV / Lightnodes nicht abwärtskompatibel sind, also quasi eine Hard Fork sind, da sie das Transaktionsformat ändern. Im Gegensatz zu einem reinen Blocksize Increase per Hard Fork, der mit allen bestehenden Light / SPV nodes vollständig kompatibel ist.

Doch die sind abwärtskompatibel, da die Empfänger (über die Adresse) bestimmen, was sie empfangen können. Ein Empfänger der kein segwit kann, wird auch keine segwit Transaktion bekommen. Die alten Transaktionsformate bleiben weiterhin gültig. Das gilt für Full- und SPV-Nodes.

sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Ja, nicht verarbeiten, super, nicht sehen, Mist. Mit Ext Blocks Transaktionen wird man nicht in der Lage sein, jeden Teilnehmer von Bitcoin zu bezahlen. Daher ist das für mich eine der schlechtesten Lösungen, die zur Debatte stehen.
Es gibt nun mal nicht die perfekte Lösung um alle glücklich zu machen:
Die Alternative 2 Blockchains - 1 für Big Blocker und 1 für Small Blocker macht das gleiche, außer das man zusätzlich noch mit unterschiedlichen Währungen (BTC-A, BTC-B) arbeitet.

SPV nodes: Jetzt wird es interessant. Meine Meinung war, dass sowohl SegWit als auch Ext Blocks für alle SPV / Lightnodes nicht abwärtskompatibel sind, also quasi eine Hard Fork sind, da sie das Transaktionsformat ändern. Im Gegensatz zu einem reinen Blocksize Increase per Hard Fork, der mit allen bestehenden Light / SPV nodes vollständig kompatibel ist.
Ich weiß nicht, was du meinst?
Auch für SPV Nodes ist das ein Soft Fork:
Eine SPV Node, die kein Segwit/Ext-Block unterstützt kann sich zu einer beliebigen Full-Node (also mit Segwit/Ext-Block oder ohne) verbinden und kann auch von Segwit oder Ext-Block Adressen Bitcoins normal empfangen. Außerdem kann es an Nested-P2SH-Segwit Adressen senden. Senden an Ext-Block Adressen und senden an Native-Segwit-Adressen geht allerdings nicht, außer mit einer Raw-Tx.

Eine SPV Node, die Segwit/Ext-Block direkt unterstützt, muss beim verbinden zu einer Full-Node darauf achten, dass diese den gewünschten Service (Segwit/Ext-Block) eben zur Verfügung stellt. Die Node kann dann in einer beliebigen Kombination von Legacy, Segwit, Ext-Block Adressen empfangen und an diese senden.

Vergleich Hard Fork, Evil Soft Fork und Chain Split:
Eine SPV-Node kann nur innerhalb ihrer Chain senden und empfangen. Zudem muss die SPV-Node darauf achten, dass sie überhaupt zu einem Node verbindet, welche auf der richtigen Chain ist. Soweit ich weiß kann man das nicht so einfach erkennen, sondern muss erstmal komplett alle Header runterladen und verarbeiten und dem SPV Node zudem beibringen, wie es die Chains unterscheiden kann.
Wenn das Transaktionsformat oder die Header verändert werden funktioniert die SPV Node nicht mehr.

Also:
Soft Fork ohne Chain Split -> SPV Node funktioniert wie erwartet ohne weitere Anpassungen -> Update der SPV Node schaltet neue Funktionen frei

Hard Fork, Evil Soft Fork oder Chain Split -> SPV Node funktioniert nicht, oder landet auf einer zufälligen Chain -> Update der SPV Node unbedingt erforderlich

Edit:
Das Transaktionsformat von Segwit und Ext-Blocks ist rückwärtskompatibel, geht ja nicht anders, da es ein Soft Fork ist
sr. member
Activity: 409
Merit: 286
Eine Zeitlang habe ich große Hoffnungen auf ExtBlocks gesetzt, aber seit mir klar ist, dass Nodes ohne Ext. Blocks die Transaktionen nicht mal sehen können, gefällt mir das fast noch weniger als SegWit.
Lustig - das Nodes ohne Ext. Blocks, die Ext. Blocks nicht verarbeiten müssen, ist was ich so toll finde an Ext. Blocks.

Das ist zumindest auch die einzige mir bekannte Variante, wie es überhaupt zu schaffen wäre Small-Blocker und Big-Blocker gleichzeitig in einem Netzwerk zufrieden zu stellen.

Edit: Und mit SPV Nodes ist es ja sowieso problemlos möglich die Extension Blocks zu nutzen

Ja, nicht verarbeiten, super, nicht sehen, Mist. Mit Ext Blocks Transaktionen wird man nicht in der Lage sein, jeden Teilnehmer von Bitcoin zu bezahlen. Daher ist das für mich eine der schlechtesten Lösungen, die zur Debatte stehen.

SPV nodes: Jetzt wird es interessant. Meine Meinung war, dass sowohl SegWit als auch Ext Blocks für alle SPV / Lightnodes nicht abwärtskompatibel sind, also quasi eine Hard Fork sind, da sie das Transaktionsformat ändern. Im Gegensatz zu einem reinen Blocksize Increase per Hard Fork, der mit allen bestehenden Light / SPV nodes vollständig kompatibel ist.
sr. member
Activity: 409
Merit: 286
Wie misst du die Community? Wenn du jetzt sagst "durch Nodes" dann muss ich dir leider mitteilen, dass du die Idee von Bitcoin nicht verstanden hast.

Alle Sybil-resistente Daten die man haben kann - Hashrate und Stake - zeigen deutlich, dass 40 bis 90 Prozent der Community hinter BU stehen.

Du weisst sicherlich, dass das nur die halbe Wahrheit ist. Diese Daten gelten auch nur für die Miner (bzw. Pools). D.h. von 10 Pools stehen 4 hinter BU, wobei unklar ist ob es tatsächlich 10 unterschiedliche Betreiber sind.

Für die gesammten Nutzer gibt es keine sicheren Daten bzw. kann es keine geben. Aus diesem Grund ziehen die BU Pools übrigens auch keinen Hard-Fork durch. Sie wehren sich sogar mit aller Gewalt gegen die entsprechenden Vorschläge. Die Wissen nämlich genau, in ihrer eigenen kleinen Gruppe (der Pools) sind sie der König. Allerdings ist ein König der Poolbetreiber etwas ganz anderes als ein König über alle Bitcoin Nutzer. Da sie sich (zurecht!) unsicher sind, ob die Nutzer mehrheitlich ihrem Hard-Fork folgen würden, lassen sie es lieber bleiben. Sie sind also nicht ganz dumm und wissen sehr wohl, dass die Hash-Rate im realen System nur die halbe Wahrheit ist. Sie hat lediglich den Vorteil, dass man die Hash-Rate sicher beziffern (und sie mit genug Geld auch einfach kaufen) kann. Für alles andere muss man auf der sozialen Ebene agieren, wo die Grenzen nicht mehr so scharf bestimmbar sind, wie im technischen Bereich.

Wäre es so wie Du hier implizieren möchtest, hätte Jihan Wu schon lange den Hard-Fork einfach durchgezogen. Alleine die Tatsache, dass er das nicht macht, zeigt jedem deutlich, dass die Beschränkung auf die Hash-Rate ein reines Scheinargument ist. Immerhin hat er sich aus der Deckung gewagt und allen klar gemacht, dass man ihn in Zukunft ebenfalls scharf im Auge behalten und jede seiner Aktionen kritisch hinterfragen sollte. Zumindest wird man in Zukunft wachsam sein, denn nun weiss man dass man in Gefahr läuft ein Messer im Rücken zu haben, sobald man sich umdreht.


Hei, ich habe nicht damit begonnen, zu postulieren, was die Community will Wink

Dein Kommentar gibt mir die seltene Gelegenheit, vollständig zuzustimmen. Er bestätigt, dass BU eben nicht die ganze Macht an die Miner abgibt, sondern dass EC sowohl die Zustimmung von User als auch Miner benötigt. BU setzt auf dieses Konsens-Modell, während die UASF verlangt, dass eine auf keine Sybil resistente Weise zu bestätigende "Mehrheit" der User ihren Willen gegen die Miner durchsetzt.
legendary
Activity: 2702
Merit: 1261
Wie misst du die Community? Wenn du jetzt sagst "durch Nodes" dann muss ich dir leider mitteilen, dass du die Idee von Bitcoin nicht verstanden hast.

Alle Sybil-resistente Daten die man haben kann - Hashrate und Stake - zeigen deutlich, dass 40 bis 90 Prozent der Community hinter BU stehen.

Du weisst sicherlich, dass das nur die halbe Wahrheit ist. Diese Daten gelten auch nur für die Miner (bzw. Pools). D.h. von 10 Pools stehen 4 hinter BU, wobei unklar ist ob es tatsächlich 10 unterschiedliche Betreiber sind.

Für die gesammten Nutzer gibt es keine sicheren Daten bzw. kann es keine geben. Aus diesem Grund ziehen die BU Pools übrigens auch keinen Hard-Fork durch. Sie wehren sich sogar mit aller Gewalt gegen die entsprechenden Vorschläge. Die Wissen nämlich genau, in ihrer eigenen kleinen Gruppe (der Pools) sind sie der König. Allerdings ist ein König der Poolbetreiber etwas ganz anderes als ein König über alle Bitcoin Nutzer. Da sie sich (zurecht!) unsicher sind, ob die Nutzer mehrheitlich ihrem Hard-Fork folgen würden, lassen sie es lieber bleiben. Sie sind also nicht ganz dumm und wissen sehr wohl, dass die Hash-Rate im realen System nur die halbe Wahrheit ist. Sie hat lediglich den Vorteil, dass man die Hash-Rate sicher beziffern (und sie mit genug Geld auch einfach kaufen) kann. Für alles andere muss man auf der sozialen Ebene agieren, wo die Grenzen nicht mehr so scharf bestimmbar sind, wie im technischen Bereich.

Wäre es so wie Du hier implizieren möchtest, hätte Jihan Wu schon lange den Hard-Fork einfach durchgezogen. Alleine die Tatsache, dass er das nicht macht, zeigt jedem deutlich, dass die Beschränkung auf die Hash-Rate ein reines Scheinargument ist. Immerhin hat er sich aus der Deckung gewagt und allen klar gemacht, dass man ihn in Zukunft ebenfalls scharf im Auge behalten und jede seiner Aktionen kritisch hinterfragen sollte. Zumindest wird man in Zukunft wachsam sein, denn nun weiss man dass man in Gefahr läuft ein Messer im Rücken zu haben, sobald man sich umdreht.
sr. member
Activity: 286
Merit: 251
Extension Blocks <3 Rootstock <3
Eine Zeitlang habe ich große Hoffnungen auf ExtBlocks gesetzt, aber seit mir klar ist, dass Nodes ohne Ext. Blocks die Transaktionen nicht mal sehen können, gefällt mir das fast noch weniger als SegWit.
Lustig - das Nodes ohne Ext. Blocks, die Ext. Blocks nicht verarbeiten müssen, ist was ich so toll finde an Ext. Blocks.

Das ist zumindest auch die einzige mir bekannte Variante, wie es überhaupt zu schaffen wäre Small-Blocker und Big-Blocker gleichzeitig in einem Netzwerk zufrieden zu stellen.

Edit: Und mit SPV Nodes ist es ja sowieso problemlos möglich die Extension Blocks zu nutzen
sr. member
Activity: 409
Merit: 286
Hallo Christoph,

wir wäre es denn, wenn du auch deine Unterstützung für Bitcoin Unlimited zurücknimmst?

Warum sollte ich? Anders als ein UASF-Node wird mein BU-Node auch nach dem 1. August im Konsens mit allen anderen Peers im Netzwerk sein.

Genau genommen sind BU-Nodes die einzigen Nodes im Netzwerk, die ohne (bislang noch nicht existierendes) Update dem Agreement von New York folgen können.

UASF ist im Widerspruch zum Agreement von New York.
BU ist die einzige Implementierung, die schon jetzt New York umsetzen kann.

Das ist eher ein Grund mehr, für BU zu werben, als dagegen. Aber wie dir sicherlich aufgefallen ist, habe ich weder in meinem Avatar Werbung für BU noch werbe ich auf meinem Blog für BU.

Ich rede gelegentlich hier von BU und werde, wenn du mich wie in diesem Fall darauf ansprichst, auf erklären, warum ich BU mag.


Quote
Ihr habt jetzt ein halbes Jahr lang viel Aufmerksamkeit bekommen, durch das Miner-Signalling für BU, habt es aber nicht geschafft, mehr ca. 10, maximal 15% der Community von dem Emergent Consensus Konzept zu überzeugen.

Wie misst du die Community? Wenn du jetzt sagst "durch Nodes" dann muss ich dir leider mitteilen, dass du die Idee von Bitcoin nicht verstanden hast.

Alle Sybil-resistente Daten die man haben kann - Hashrate und Stake - zeigen deutlich, dass 40 bis 90 Prozent der Community hinter BU stehen.

Coin-vote: https://vote.bitcoin.com/arguments/bitcoin-unlimited-s-path-to-solve-bitcoin-s-scaling-issues-is-better-than-bitcoin-core-s

Darüber hinaus IST es Emergent Consensus, wenn sich Miner und Ökonomie dafür entscheiden, 2mb Blöcke zu machen.

Quote
Das Ziel von Bitcoin Unlimited ist ja, mit den einstellbaren Parametern die Einheit der Non-Mining-Nodes zu brechen, um so mehr Macht auf die Miner zu übertragen. Dieses Ziel wird zwar kaschiert, aber die meisten Bitcoiner sind nicht dumm und durchschauen das. Und die Leute wollen eben nicht von den Minern regiert werden, weil die Mining-Landschaft zu stark zentralisiert ist.

So? Eigentlich ist es das Ziel von BU, Nodes und Minern gemeinsam zu erlauben, einen Emerging Consensus für die Blocksize zu finden und diesen umzusetzen, anstatt darauf zu warten, dass die Core Entwickler eine Lösung finden, die dann auch akzeptiert wird. Das "Konsens durch Core" nicht funktioniert, sondern die Community splittet, sehen wir ja derzeit.

Dass du die Freiheit der User, selbst zu entscheiden, wie groß die Blöcke sein dürfen, damit verwechselst, dass die Miner alles beherrschen, zeigt, was du vom User hältst: Nämlich gar nichts. Er ist ein Opfer, das unfähig ist, selbstverantwortlich Entscheidungen zu treffen. Ich nehme mal an, du meinst auch, dass man Alkohol und Tabak verbieten muss, denn wenn die User die Wahl haben, zu trinken und zu rauchen, dann werden die Zigarettenhersteller und die Wirte bestimmen, wie viel Nikotin und Alkohol die Leute im Blut haben. Ach ja, Schokolade, Kaffee, Schwarztee und so weiter sollten wir auch verbieten. Denn wenn die Leute die Wahl haben, ob Apfel oder Schoki, dann bestimmt Lindt, wie hoch unsere Insuln-Werte sind.

Das hört sich jetzt lächerlich an. Aber exakt so - 100 Prozent - geht dein Argument, dass BU den Minern alle Macht gibt.

Warte, ich habe noch ein Beispiel: Das Ziel der Demokratie ist es, die Einheit der Bürger in Deutschland zu brechen, damit Russland alles beherrscht. Das Ziel der Pressefreiheit ist es, die Einheit der Meinungen der Bürger zu brechen, damit die Regierung alles bestimmen kann. Das Ziel der Produktvielfalt im Supermarkt ist es, die Einheit der deutschen Konsumenten zu brechen, damit die belgischen Schokoladenhersteller alles beherrschen.

Quote
Das Segwit geblockt wird, obwohl die Mehrheit der User das wünscht, ist ein Symptom davon. Hätten wir tausende Miner, die jeweils nur winzige Bruchteile der gesamten Hashrate kontrollieren, wäre es etwas anderes.

Wie misst du die "Mehrheit der User"? Sag' jetzt nicht "Node Count" oder "Twitter Poll" oder "reddit upvotes", ansonsten - du weißt schon.

Und, "tausende Miner": Wir haben tausende von Miner. Du verwechselst offenbar Pools mit individuellen Minern. Mining ist hoch dezentralisiert, auch wenn die Pools die Funktion von Wahlmännern haben. Wenn die tausende von Minern aus aller Welt, die es wirklich gibt, so sehr für SegWit wären, wie du meinst, dann würden sie bei BTCC oder F2Pool minen. Machen sie aber offenbar nicht.

Quote
Und ja, ich weiß, im Statoshi Whitepaper steht drin "The proof-of-work also solves the problem of determining representation in majority decision making.", aber das ist nur eine Metapher. Die hat Satoshi gewählt, um das Proof-of-Work Konzept anschaulich zu erklären, denn das war damals brandneu. Im Nachhinein betrachtet, war es ein Fehler von Satoshi, die politischen Begriffe "Representation" und "Decision Making" da reinzubringen, denn beim Mining geht es eben gerade nicht um politische Entscheidungen, sondern um ein System aus ökonomischen Anreizen.

Ok. Ich finde die Aussage von Satoshi recht eindeutig, genauso wie seine Bemerkung, das man das Limit beizeiten aufheben sollte. Aber vermutlich war auch dieser Kommentar ein Fehler von ihm. Ebenso wie seine Kommentare zu SPV-Nodes, HD-Filmen, Mikrotransaktionen und so weiter. Aber egal.

Quote
Abgesehen davon ist der Name "Emergent Consensus" irreführend, weil es keinen Mechanismus gibt, der sicherstellt, dass alle auf einer Chain bleiben.

Es kann keinen Mechanismus geben, der sicherstellt, dass alle User auf derselben Chain bleiben. Dazu müssten sie nämlich dieselbe Software benutzen. Eventuell wäre das mit einer Mischung aus Polizeistaat, Vorratsdatenspeicherung, Backdoor und massiver Propaganda zu machen. Aber ich gehe mal davon aus, dass dir das, trotz deiner Ansichten zur Wahlfreiheit, genauso widerstrebt wie mir.

Wenn das dein Kriterium ist, dann ist Bitcoin gescheitert. Was es aber geben kann ist ein System von Anreizen, asr gewährleistet, dass die Mehrheit der Miner und User auf einer Chain bleiben, die dominant genug ist, um Bitcoin genannt zu werden. Und dort gibt es dann einen Konsens über die Transaktionshistorie sowie die Anforderungen an Transaktionen und Blöcke. Dass Bitcoin Unlimited auch bei der starken Unterstützung durch Miner und User noch keine Chain Split gestartet hat, zeigt, dass BU, zumindest bislang, diesen Anforderungen im Feldtest gerecht wird. Im Gegensatz zur UASF.
full member
Activity: 235
Merit: 100
Kannst du mir erklären, warum dir eine UASF so wichtig ist?

Es gibt jetzt ein Agreement, das von genügend Minern und Unternehmen getragen wird, um OHNE split mehr Kapazität + SegWit zu schaffen, und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Die ganze Zeit hieß es, eine Hard Fork sei schlecht, weil sie zu einem Chain split führen kann. Nun haben wir die Möglichkeit, die Hard Fork ohne Chain splitt zu schaffen, und die UASF Fans versuchen auf Teufel komm' raus SegWit auf eine Weise zu aktivieren, die garantiert zum Chain Split führt.

-bitte auch das Addendum unten an meinem Post beachten -

Hallo Christoph,

wir wäre es denn, wenn du auch deine Unterstützung für Bitcoin Unlimited offiziell zurücknimmst, und deinen Namen von deren Website streichen lässt? Dein Posting ist schon ein paar Tage alt, aber ich möchte das nochmal aufgreifen, nachdem ich gestern einen Blick auf reddit/r/btc geworfen habe, und enttäucht war, das sich dort nichts geändert hat, trotz New York Consensus.

Ihr habt jetzt einige Monate lang viel Aufmerksamkeit bekommen, durch das Miner-Signalling für BU, habt es aber nicht geschafft, mehr ca. 10%, maximal 15% der Community von dem Emergent Consensus Konzept zu überzeugen.

Das Ziel von Bitcoin Unlimited ist ja, mit den einstellbaren Parametern die Einheit der Non-Mining-Nodes zu brechen, um so mehr Macht auf die Miner zu übertragen. Dieses Ziel wird zwar kaschiert, aber die meisten Bitcoiner sind nicht dumm und durchschauen das. Und die Leute wollen eben nicht von den Minern regiert werden, weil die Mining-Landschaft zu stark zentralisiert ist. Dass Segwit geblockt wird, obwohl die Mehrheit der User das wünscht, ist ein Symptom davon. Hätten wir tausende Miner, die jeweils nur winzige Bruchteile der gesamten Hashrate kontrollieren, wäre es etwas anderes. So war es damals von Satohis erhofft, deswegen "Peer-to-Peer" im Titel des Whitepapers.

Und ja, ich weiß, im Statoshi Whitepaper steht drin:

"The proof-of-work also solves the problem of determining representation in majority decision making."

Aber das ist nur eine Metapher. Die hat Satoshi damals gewählt, um das Proof-of-Work Konzept anschaulich zu erklären, denn das war damals brandneu. Im Nachhinein betrachtet, war es ein Fehler von Satoshi, die politischen Begriffe "Representation" und "Decision Making" da reinzubringen, denn beim Mining geht es eben gerade nicht um politische Entscheidungen, sondern um ein System aus ökonomischen Anreizen.

Abgesehen davon ist der Name "Emergent Consensus" irreführend, weil es keinen Mechanismus gibt, der sicherstellt, dass alle auf einer Chain bleiben.


Gruß,

Rakete4


Addendum:
Es lohnt auch, sich mit der deflationären Natur von Bitcoin zu beschäftigen. Selbst mit 1-Terrabyte-Blöcken würde Bitcoin niemals zum alltäglichen Zahlungsmittel. Ich bin unter anderem über die Freigeld-Bewegung von Silvio Gesell zu Bitcoin bekommen. Wenn man versteht, dass nur ein fließendes Geld ein stabiles Geld sein kann, dann weiß man auch, dass Bitcoin ein Anti-Geld ist. Bitcoin kann wie Gold zur individuellen Absicherung dienen, aber es kann niemals der Motor einer funktionierenden Volkswirtschaft sein. Wenn man die Dezentralität von Bitcoin zerstört, dann wird Bitcoin auch kein Mittel zu individuellen Absicherung mehr sein.

sr. member
Activity: 409
Merit: 286
Und wenn wir eine Hardfork der Datenträger vermieden hätten, würden wir heute weiterhin 5,25" Disketten benutzen.

Und das hat 20-30 Jahre gedauert. Bei den entpsrechenden Schnittstellen hat man übrigens über weite Strecken und so lange das möglich war den MIgartionspfad (erst IDE, dann  SATA) gewählt. Dabei geht es hier nur um ein paar Datenträger, die innerhalb kürzester Zeit umkopiert werden können und die vor allem parallel mit alten Modellen betrieben werden können. An ein globales Geld-System werden andere Anforderungen gestellt. Selbst wenn man extrem Agil ist, sollten daher 2-3 Jahre nachdem das Konzept fest(!) ist drin sein. Wie gesagt, ich habe nicht generell etwas gegen einen Hard-Fork, nur sollte man den nicht a) in wenigen Monaten über's Knie brechen und b) tatsächlich eine sinnvolle Richtung einschlagen und ihn nicht als reines Machtinstrument missbrauchen. Ausserdem sind Soft-Forks bevorzugt. Erst wenn das nicht mehr sinnvoll möglich ist (ECDSA angreifbar, Mining Algorithm Change), ist es an der Zeit über einen Hard-Fork nachzudenken.


Ich muss zugeben, der Teil mit der Hardfork ist das einzige Argument, das mich von Seiten der Small Blockers zumindest teilweise überzeugt. Allerdings möchte ich nicht einsehen, dass sich Bitcoin deswegen bremsen muss. SegWit (oder andere Softforks) mögen Vorteile haben, aber wenn man an Scalierung / Kapazität interessiert ist, ist eine reine, einfache Erhöhung der Blocksize unschlagbar.

Zu Datenträgern: Ich erinnere mich noch als ich meinen ersten Computer mit CD-Rom hatte. Damals gab es Spiele, die haben die 600 MB auf der CD für Grafiken und Videos genutzt, die davor unmöglich waren. Das ist ja quasi eine Hardfork, da das nicht auf 5,25" passt. Die Softfork-Variante wäre, das Spiel so zu programmieren, dass man es auf Diskette spielen kann, aber man eine CD einlegen muss, wenn man etwa die Zwischensequenzen sehen will oder besondere Grafiken / Extralevel genießen will. Oder es simultan zur CD auf 500 Disketten auszuliefern. Ich glaube sogar, so etwas gab es sogar mal, aber die meisten Leute fanden es uninteressant ...

Die Hardfork, um die es bei Bitcoin derzeit geht, ist seit 2-3 Jahren intensiv im Gespräch. Sie wird dafür verwendet, um onchain zu skalieren, ohne dabei wie bei SegWit extreme Komplikationen für selbstgemachte Nodes einzuführen, ohne eine Fee-Regulierunug (Signatur-Discount) zu verhängen, und ohne eine Angriffsfläche von 4 MB bei einer Kapazität von 1,5-1,7 MB zu eröffnen. Wenn man anständig per Softfork skalieren kann, sehr gerne. Eine Zeitlang habe ich große Hoffnungen auf ExtBlocks gesetzt, aber seit mir klar ist, dass Nodes ohne Ext. Blocks die Transaktionen nicht mal sehen können, gefällt mir das fast noch weniger als SegWit. Immerhin hat Ext. Blocks das Potenzial, echte Kapazität anstatt der lächerlichen 1,5-1,7 MB zu schaffen.

Wenn man an Kapazität interessiert ist, sind alle bekannten Alternativen zur Hardfork um ein vielfaches schlechter. Daher erscheint es mir einfach unklug, aus der Furcht vor der Fork diese herauszuzögern / durch schlechtere Ansätze zu ersetzen. Es wird in Zukunft nur noch schwieriger werden.

Edit: Interessant, angeblich verschicken manche Behörden noch Patientendaten per Diskette an Behörden. Und oft werden Faxe ja noch immer akzeptiert. Weiter gedacht sind die deutschen Gesetze, in denen nie Gesetze gelöst, aber immer nur neue eingeführt werden, auch abwärtskompatibel. Die Welt ist voller Softforks. Aber ich bin mir nicht sicher, ob das immer sinnvoll ist ...
Pages:
Jump to: