Bitcoin Forum
November 23, 2017, 04:30:49 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
  Print  
Author Topic: Re: Der Aktuelle Kursverlauf blockgrösse  (Read 175386 times)
Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
May 27, 2017, 04:56:30 PM
 #941

Auf dieser Seite ist unten eine Erläuterung, wie Exchanges sowohl BIP-148 Bitcoin als auch Legacy-Bitcoin handeln können.
Es ist leider ziemlich kompliziert:
https://www.weusecoins.com/uasf-guide/
Bitte selbst den Link durchlesen, ich möchte das nicht alles hier reinkopieren.
Für große Exchanges ist so etwas vom Aufwand her wohl machbar, aber für die Nutzer schwer verständlich.

Es hätte natürlich für die Exchanges den Vorteil, dass sie sich selbst keinem Risiko aussetzen. Eine Exchange, die einen Alleingang macht und komplett auf BIP-148 umstellt, geht zwar auch nicht unbedingt Pleite im Fall eines Mißerfolgs, aber sie verliert den Großteil ihrer Kunden, sowie alle ihre Coins auf der BIP-148 Chain, die nicht Kundeneinlagen waren. Die Coins der Kunden verliert sie natürlich auch, aber die muss sie ja nicht erstatten. Gleiches gilt natürlich für eine Exchange, die bei der UASF-Fork nicht mitmacht, in dem Fall, dass die UASF erfolgreich ist.

Ideal wäre es, wenn sich mehrere Exchanges absprechen und gemeinsam auf BIP-148 umstellen. Über entsprechende einklagbare Verträge mit verbindlichen Schadenssummen könnten sie sich gegenseitig versichern, dass sie sich nicht gegenseitig im Regen stehen lässen.

Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.
1511411449
Hero Member
*
Offline Offline

Posts: 1511411449

View Profile Personal Message (Offline)

Ignore
1511411449
Reply with quote  #2

1511411449
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511411449
Hero Member
*
Offline Offline

Posts: 1511411449

View Profile Personal Message (Offline)

Ignore
1511411449
Reply with quote  #2

1511411449
Report to moderator
d5000
Legendary
*
Offline Offline

Activity: 1568



View Profile
May 28, 2017, 11:55:45 AM
 #942

Core-Entwickler Eric Lombrozo geht unter die bösen Verräter, die statt dem Chainsplit noch einen Konsens verfolgen. So wie ich es interpretiere, will er versuchen, aus Barry Silbert's Agreement was brauchbares zu machen, dem auch die Core-Leute zustimmen können.

       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
,CoinPayments,
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
Gyrsur
Legendary
*
Offline Offline

Activity: 1820


#BEL+++


View Profile WWW
May 28, 2017, 04:49:37 PM
 #943

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
Lincoln6Echo
Legendary
*
Offline Offline

Activity: 1820


Don't use bitcoin.de if you care about privacy!


View Profile
May 28, 2017, 05:29:34 PM
 #944

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

Wer ist denn James Hilliard? Er ist ja der Autor von BIP91.
Mir sagt der Name im Moment gar nichts. Schon mal gut das es ein Softfork ist.

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
May 28, 2017, 09:37:41 PM
 #945

Ich denke, mit dem BIP wird lediglich Bitcoin Core kompatibel gemacht mit dem ersten Teil des New York Agreements.

Barry Silbert wird sicher derzeit versuchen, ein neues Dev-Team aufzustellen, das den 2 MB Hardfrok codiert (so trivial ist das nämlich nicht),  und vermutlich auch im Weiteren dann die Geschicke von Bitcoin leiten soll. Bei dem New York agreement war mit Gavin Andresen nur 1 ehemaligen Bitcoin Developer beteiligt.

Die Stille zu dem Thema ist ja geradezu ohrenbetäubend.

Soweit ich mich erinnere, gibt es auch einige anderen Bugs/Unschönheiten im Bitcoin Code, die man nur durch einen Hardfork beseitigen kann. Es wäre daher wünschenwert, wenn da sinnvoll zusammengearbeitet wird mit einigen erfahrenen Core developpern.

Aber das wünschenswerte passiert beim Bitcoin schon lange nicht mehr, also machen wir uns mal alle schön auf die nächsten Enttäuschungen gefasst.
Greshamsches Geld
Hero Member
*****
Offline Offline

Activity: 812



View Profile
May 29, 2017, 07:19:54 AM
 #946

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.
Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
May 29, 2017, 08:01:36 AM
 #947

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.
Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Dann minen sie ungültige Blöcke und verdienen nichts.
Greshamsches Geld
Hero Member
*****
Offline Offline

Activity: 812



View Profile
May 29, 2017, 08:46:52 AM
 #948

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

...

 Schon mal gut das es ein Softfork ist.
Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Dann minen sie ungültige Blöcke und verdienen nichts.
Verstanden. Wenn SegWit entweder (4) ab 80% oder SegWit(1) ab 95% offiziell durch ist, ist es durch. Danke.

Bergmann_Christoph
Sr. Member
****
Offline Offline

Activity: 366


View Profile WWW
May 29, 2017, 09:29:27 AM
 #949

...
Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

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.

Warum? Nur aus Prinzip, weil "Jihan böse" + "User haben die Hosen an"? Also, um einen Punkt zu machen?

--
Bester Bitcoin-Marktplatz in der Eurozone: Bitcoin.de
Bestes Bitcoin-Blog im deutschsprachigen Raum: bitcoinblog.de

Tips dafür, dass ich den Blocksize-Thread mit Niveau und Unterhaltung fülle und Fehlinformationen bekämpfe:
Bitcoin: 1BesenPtt5g9YQYLqYZrGcsT3YxvDfH239
Ethereum: XE14EB5SRHKPBQD7L3JLRXJSZEII55P1E8C
Greshamsches Geld
Hero Member
*****
Offline Offline

Activity: 812



View Profile
May 29, 2017, 10:06:45 AM
 #950

OHNE split mehr Kapazität + SegWit zu schaffen,
Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.
Ach, ist das so?

mezzomix
Legendary
*
Offline Offline

Activity: 1918


View Profile
May 29, 2017, 10:41:05 AM
 #951

OHNE split mehr Kapazität + SegWit zu schaffen,
Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

Doch das scheint zu gehen. Irgendwo im Development Bereich hat vor kurzem jemand eine Lösung, basierend auf den erweiterten segwit Transaktionen, skizziert. Damit wären 2MB per Soft-Fork möglich.

Allerdings würden die 2MB nur für segwit Transaktionen gelten. Ist aber auch klar, da die alten Knoten davon nichts wissen können. Ausserdem wäre es sinnvoll, da nur für die segwit Transaktionen das Problem mit dem quadratischen Aufwand zur Hashberechnung gelöst ist.

Möchte man segwit + 2MB per Hard-Fork, wäre die von Gavin vorgeschlagene segwit Umsetzung sinnvoller, da dort das Block-Format deutlich vereinfacht wird. Daneben könnte (sollte!) man mit einem Hard-Fork gleich noch ein paar andere Sachen geradeziehen. In diesem Zug könnte man dann gleich die bisherigen Transaktionsformate über Bord werfen. Warum Altlasten mitschleppen, wenn sowieso alle zum Stichtag umstellen müssen?! Die bisherigen Soft-Fork vorschläge sind nur unter der Annahme sinnvoll, dass die alten Knoten ohne Änderung weiterarbeiten können. Peilt man einen Hard-Fork an, muss man das gesammte System vereinfachen. Alles andere wäre grober Unfug.
Bergmann_Christoph
Sr. Member
****
Offline Offline

Activity: 366


View Profile WWW
May 29, 2017, 10:51:42 AM
 #952

OHNE split mehr Kapazität + SegWit zu schaffen,
Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.
Ach, ist das so?

Wenn weniger als 10 Prozent der Miner mitmachen, gibt es keine Chainsplit.

Soweit ich es gehört habe, ja, die allermeisten sind mit SW + 2 MB einverstanden. Du nicht?

Beantwortet alles aber meine Frage nicht: Warum unbedingt ein ChainSplit?

--
Bester Bitcoin-Marktplatz in der Eurozone: Bitcoin.de
Bestes Bitcoin-Blog im deutschsprachigen Raum: bitcoinblog.de

Tips dafür, dass ich den Blocksize-Thread mit Niveau und Unterhaltung fülle und Fehlinformationen bekämpfe:
Bitcoin: 1BesenPtt5g9YQYLqYZrGcsT3YxvDfH239
Ethereum: XE14EB5SRHKPBQD7L3JLRXJSZEII55P1E8C
Bergmann_Christoph
Sr. Member
****
Offline Offline

Activity: 366


View Profile WWW
May 29, 2017, 10:53:27 AM
 #953

OHNE split mehr Kapazität + SegWit zu schaffen,
Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

Doch das scheint zu gehen. Irgendwo im Development Bereich hat vor kurzem jemand eine Lösung, basierend auf den erweiterten segwit Transaktionen, skizziert. Damit wären 2MB per Soft-Fork möglich.

Allerdings würden die 2MB nur für segwit Transaktionen gelten. Ist aber auch klar, da die alten Knoten davon nichts wissen können. Ausserdem wäre es sinnvoll, da nur für die segwit Transaktionen das Problem mit dem quadratischen Aufwand zur Hashberechnung gelöst ist.

Möchte man segwit + 2MB per Hard-Fork, wäre die von Gavin vorgeschlagene segwit Umsetzung sinnvoller, da dort das Block-Format deutlich vereinfacht wird. Daneben könnte (sollte!) man mit einem Hard-Fork gleich noch ein paar andere Sachen geradeziehen. In diesem Zug könnte man dann gleich die bisherigen Transaktionsformate über Bord werfen. Warum Altlasten mitschleppen, wenn sowieso alle zum Stichtag umstellen müssen?! Die bisherigen Soft-Fork vorschläge sind nur unter der Annahme sinnvoll, dass die alten Knoten ohne Änderung weiterarbeiten können. Peilt man einen Hard-Fork an, muss man das gesammte System vereinfachen. Alles andere wäre grober Unfug.


Wie gesagt: Wenn Unternehmen und Miner einverstanden sind, ist ein Chainsplit vermutlich nicht weiter relevant, egal wie man es macht. Die Schwierigkeit beim Bitcoin-Mining ist mittlerweile so astronomisch ...

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

--
Bester Bitcoin-Marktplatz in der Eurozone: Bitcoin.de
Bestes Bitcoin-Blog im deutschsprachigen Raum: bitcoinblog.de

Tips dafür, dass ich den Blocksize-Thread mit Niveau und Unterhaltung fülle und Fehlinformationen bekämpfe:
Bitcoin: 1BesenPtt5g9YQYLqYZrGcsT3YxvDfH239
Ethereum: XE14EB5SRHKPBQD7L3JLRXJSZEII55P1E8C
mezzomix
Legendary
*
Offline Offline

Activity: 1918


View Profile
May 29, 2017, 11:08:14 AM
 #954

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

Ist es nicht. Wer mit "zu spät" argumentiert will andere nur grundlos in die Ecke drängen. Wenn man sowieso eine Revolution macht, dann wirft man Altlasten über Bord und zieht diese nicht wie beim evolutionären Ansatz hinter sich her. Wenn man an einem Geldsystem herumschraubt, dann macht man das unter den gegebenen Bedingungen (Hard-Fork / Soft-Fork) richtig - oder gar nicht.

Also entweder alles per Soft-Fork oder aber ein Hard-Fork ohne die ganzen Altlasten.

Meine Meinung.
flyer88
Sr. Member
****
Offline Offline

Activity: 399


View Profile
May 29, 2017, 11:14:01 AM
 #955

Im Grunde richtig aber imo nicht realistisch. Dann gehen die ganzen Diskussionen wieder von vorne los und wir haben in 10 Jahren noch keine Lösung. Denn ich bin mir ziemlich sicher irgendwer hat was dagegen und gründet eine Bewegung um zu zeigen, dass sein Ego das größte ist. Tongue

Bergmann_Christoph
Sr. Member
****
Offline Offline

Activity: 366


View Profile WWW
May 29, 2017, 11:16:37 AM
 #956

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

Ist es nicht. Wer mit "zu spät" argumentiert will andere nur grundlos in die Ecke drängen. Wenn man sowieso eine Revolution macht, dann wirft man Altlasten über Bord und zieht diese nicht wie beim evolutionären Ansatz hinter sich her. Wenn man an einem Geldsystem herumschraubt, dann macht man das unter den gegebenen Bedingungen (Hard-Fork / Soft-Fork) richtig - oder gar nicht.

Also entweder alles per Soft-Fork oder aber ein Hard-Fork ohne die ganzen Altlasten.

Meine Meinung.


Ich möchte jetzt nicht überdramatisieren. Aber sorry. Seit 2014 haben Leute gesagt "Erhöht die Blocksize", und es ist nichts passiert. Core hätte noch 2015, vielleicht auch noch 2016, eine Hardfork in xx Monaten ankündigen können und da all die tollen Dinge reinpacken. Haben sie aber nicht gemacht. Jetzt haben die Miner und die Wirtschaft die Geduld verloren und machen ohne Core eine Mimimal-Hardfork, um das Blocksize-Problem zu fixen.

Sowieso: Es ist war an sich logisch, in eine Hardfork so viel reinzupacken wie möglich, wenn man sie schon macht. Andererseits aber bedeutet das, dass der Code für die Hardfork und diese selbst komplexer wird, dass es mehr Möglichkeiten gibt, wie etwas schief geht, dass es mehr Kontroversen geben kann, dass es schwieriger wird, entstandene Schäden zu beheben, und dass die Umstellung der Clients und der darum herum gebauten Software eventuell schwieriger wird. Wenn ich es mir so überlege, sollte man es vermeiden, allzu viel in eine HF zu stecken.

--
Bester Bitcoin-Marktplatz in der Eurozone: Bitcoin.de
Bestes Bitcoin-Blog im deutschsprachigen Raum: bitcoinblog.de

Tips dafür, dass ich den Blocksize-Thread mit Niveau und Unterhaltung fülle und Fehlinformationen bekämpfe:
Bitcoin: 1BesenPtt5g9YQYLqYZrGcsT3YxvDfH239
Ethereum: XE14EB5SRHKPBQD7L3JLRXJSZEII55P1E8C
mezzomix
Legendary
*
Offline Offline

Activity: 1918


View Profile
May 29, 2017, 11:58:17 AM
 #957

Es wäre logisch so wenig wie möglich in den Hard-Fork zu packen, also viel alten Code zu entfernen und wenig neuen Code einzubauen. Das senkt das Risiko und erhöht die Testabdeckung, da es weniger Variationen zu testen gibt.

Von mir aus kann man auch segwit als Soft-Fork und 2MB als Hard-Fork machen, wenn alle das tatsächlich wollen. Das würde ich für mich dann eben unter verpasste Chance ablegen.

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!
Bergmann_Christoph
Sr. Member
****
Offline Offline

Activity: 366


View Profile WWW
May 29, 2017, 12:10:54 PM
 #958

Es wäre logisch so wenig wie möglich in den Hard-Fork zu packen, also viel alten Code zu entfernen und wenig neuen Code einzubauen. Das senkt das Risiko und erhöht die Testabdeckung, da es weniger Variationen zu testen gibt.

Genau, sehe ich auch so. So unkompliziert wie möglich, so dass es so viele Leute wie möglich verstehen und verifizieren können.

Quote
Von mir aus kann man auch segwit als Soft-Fork und 2MB als Hard-Fork machen, wenn alle das tatsächlich wollen. Das würde ich für mich dann eben unter verpasste Chance ablegen.


Für mich sind wir schon seit einigen Monaten auf dem Kontinten der "verpassten Chancen". Mich würde aber interessieren, welche Chance wir deiner Meinung nach mit 2MB + SW verpassen werden?

Quote
Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!

Manchmal wird SegWit als 2MB Softfork bezeichnet. Das ist falsch, da SegWit eher eine 1,5 MB Size mit DoS-Angriffsfläche von 4mb ist. Und darüber hinaus eine Menge andere Dinge als Blocksize-Erhöhung macht.

Extension Blocks ist die andere Idee von 2mb Softfork. Daran wird gerade gearbeitet, siehe bcoin, und vermutlich wird das der Ausweg werden, wenn wir ans Limit von 2MB+SW knallen bzw. wird schon vorher eingerichtet, um eine Art Sidechain für billige Massentransaktionen zu werden.

--
Bester Bitcoin-Marktplatz in der Eurozone: Bitcoin.de
Bestes Bitcoin-Blog im deutschsprachigen Raum: bitcoinblog.de

Tips dafür, dass ich den Blocksize-Thread mit Niveau und Unterhaltung fülle und Fehlinformationen bekämpfe:
Bitcoin: 1BesenPtt5g9YQYLqYZrGcsT3YxvDfH239
Ethereum: XE14EB5SRHKPBQD7L3JLRXJSZEII55P1E8C
mezzomix
Legendary
*
Offline Offline

Activity: 1918


View Profile
May 29, 2017, 12:28:34 PM
 #959

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!
Manchmal wird SegWit als 2MB Softfork bezeichnet. Das ist falsch, da SegWit eher eine 1,5 MB Size mit DoS-Angriffsfläche von 4mb ist. Und darüber hinaus eine Menge andere Dinge als Blocksize-Erhöhung macht.

segwit + 2MB als Soft-Fork bedeutet segwit und zusätzlich noch ein 2MB softfork. D.h. die Blöcke können inkl. Signaturen bis zu 8MB gross werden und nicht nur die 4MB bei segwit!

Es geht nur darum, dass man die zusätzlichen 2MB nicht per Hard-Fork löst, wenn man sowieso den alten Kram weiter mit sich rumschleppt. Dann sollte man die Gelegenheit nutzen und die alten Knoten einfach weiterlaufen lassen. Denn tatsächlich ist der Soft-Fork "nur" ein politisches Problem 1-3 der Miner, während der Hard-Fork jeden Knoten (inkl. aller Patches und Anpassungen) betrifft. Ein kurzfristiger Hard-Fork bedeutet, dass alle (nochmal alle!) Implementierungen zum Stichtag angepasst sein müssen.
Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
May 29, 2017, 02:50:29 PM
 #960

...
Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

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.

Warum? Nur aus Prinzip, weil "Jihan böse" + "User haben die Hosen an"? Also, um einen Punkt zu machen?


Hallo Christoph,

die UASF an sich ist mir gar nicht wichtig, wichtig ist mir, dass jetzt endlich mal etwas vorangeht. Wichtig ist mir dabei,

-dass Segwit als Soft Fork kommt, vor allem damit man testen kann, ob sich das Lightening network bewährt, aber auch aus anderen Gründen, z.B. dass endlich mal die Outputs genauso viel ins Gewicht fallen wie die Inputs bei der Transaktionsgebühr, und vieles mehr.

-dass eine Erhöhung der Blocksize per Hardfork massvoll ausfällt

-dass das Bitcoin Core Team den Client stellt und die Detailarbeit macht, denn auf deren technische Fähigkeiten vertraue ich am meisten


Aber es ist schön, dass sich der Fokus der Diskussion endlich verschoben hat in Richtung Kompromissfindung und die Eckpfeiler schon stehen (Segwit+2 MB), auch wenn vieles noch zu klären ist. Sieht man auch hier im Thread schön, wie sich der Fokus verschoben hat.

Den UASF-Avatar behalte ich noch so lange, bis es von der New York Consensus-Seite um Barry Silbert endlich mal etwas konkretes gibt: Wo ist der neue Github, wo sind die neuen Devs, oder soll doch alles von den Core-Devs gemacht werden?
Die Segwit-Blockierer sind da in der Bringschuld, und da ist es legitim, als User so lange noch weiter an der UASF-Propaganda festzuhalten.

Die Leute haben sich Bitcoins gekauft, weil sie dachten, dass Miner als Serviceleistung Double-Spends verhindern und dafür entlohnt werden, nicht weil sie von den Minern regiert werden wollen. Fremdregieren lassen kann man sich genauso gut im FIAT-System. Dass der Clique um Jihan Wu offenbar gar nicht klar ist, warum die Leute so verärgert sind, zeigt schon wie abgehoben die mittlerweile sind.

Gruß,

Rakete4

P.S. Dass ich nicht unter meinem Klarnamen schreibe, hat einfach den Grund, dass es meinen Namen nur einmal weltweit gibt, so dass dann jeder bei Google gleich auf Bitcoin stösst, der nach mir googelt. Und auf Neider habe ich keine Lust. Ich bin mittlerweile bei drei Bitcoin-Exchanges verifiziert, lande also auch im Gulag, wenn die Regierungen alle Bitcoiner dorthin befördern eines Tages. Es geht mir nur um die privaten Neider.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!