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

Hallo Herr Bergmann,

den Kompromiss 2 MB + Segwit würde ich unterstützen, und wenn es sein muss auch gegen das Core-Team. Allerdings habe ich bisher außer den Tweets von Barry Silbert dazu nichts gesehen, und so weit ich weiß gibt es dazu noch nicht mal einen Client, nach so langer Zeit der Diskussion. Die Reaktion auf die Tweets war auch überwiegend positiv auf Reddit-Bitcoin, auf Reddit-BTC hingegen überwiegend negativ. Wenn Bitmain&Co an einem Kompromiss gelegen ist, warum unterstützen die dann weiter Emergent Consensus? Viele Bitcoiner haben mittlerweile den Eindruck, dass es den prominenten Vertretern der Big Blocker nur darum geht, die Bitcoin-Core Developer zu entmachten.



Meines Wissen nach kann man das so voranschaulichen:

Man stelle sich vor, die Miner werfen rote und grüne Legosteine.
Rote Legosteine = Blöcke, die nicht für Segwit signalisieren
Grüne Legosteine = Blöcke, die für Segwit signalisieren

Ab der Aktivierung von BIP148 am 1. August fangen die UASF-Clients nur noch die grünen Legosteine, und bauen daraus ihre Chain. Ein herkömmlicher Client fängt sowohl grüne als auch rote Legosteine und baut daraus seine Chain. Ab dem ersten roten Legostein, den ein Miner wirft, kommt es daher zu einem Chainsplit. Da immer ein Legostein genau auf den anderen passen muss, müssen die Miner, die die grünen Legosteine werfen, sich ab dem Moment entscheiden, ob sie sie zu den Clients werfen, die nur die grünen Legosteine fangen oder zu denen, die alle Legosteine fangen.

Ein herkömmlicher Node fängt zwar grundsätzlich auch alle grüne Legosteine, aber diejenigen, die für die rein-grüne Chain geworfen werden, werden nur als Verlängerung einer Orphan-Chain registiert. Sobald die rein-grüne Chain allerdings länger ist als die bunte Chain, macht ein herkömmlicher Client eine Reorganisation und ab sofort ist die rein-grüne Chain dann die Hauptchain und die bunte Chain ist eine Orphan-Chain. Das kann dann mehrmals hin-und hergehen, wenn die Hashrate der beiden Chains etwa 50:50 ist.

Warum wollt ihr mit BIP148 das Netzwerk splitten, anstatt einfach den Kompromiss 2MB + SegWit zu unterstützen? Es könnte so einfach sein. Wenn die Entwickler sagen würden, "ok, wir machen eine Hardfork zu 2 MB" würden die Miner sofort SegWit aktivieren. Wäre der klarste und am wenigsten disruptive Weg. BIP148 kommt mir vor, als wollte jemand was beweisen, also als würde jemand Bitcoin an sich aufs Spiel setzen, nur um irgendeine Art von Macht zu demonstrieren.

Was ich nicht verstehe - vielleicht kann das jemand erklären - ist dieser Satz von der uasf-webseite:


Meine Hervorhebung.

Kann eine UASF-Fork also SegWit auch für die Knoten aktivieren, die kein UASF-Update haben? Wie funktioniert das? Ich dachte, die Nodes warten auf 95 Prozent der Miner, um SegWit zu aktiveren. Oder reicht es aus, wenn ein Miner einen entsprechenden Block veröffentlicht?

@d5000
Naja strikt dagegen würde ich das nicht gerade nennen.

Bin da auch ähnlicher Meinung. Kann funktionieren, ist aber etwas über das Knie gebrochen und es wird extrem schwer die Exchanges zu überzeugen, so dass der ökonomische Druck vorab sichtbar wird.
Würden bereits 51% der Miner Segwit signalisieren und hätten Ihre Unterstützung für BIP148 zugesagt sähe das bestimmt anders aus.


BIP149 ist technisch wesentlich sauberer und falls die Miner dann wirklich absichtlich den chain split herbeiführen wollen, dann wird die Mehrheit die Blockchain der Segwit Output stehlenden Miner meiner Meinung nach als wenig wertvolle Altcoin ansehen.

Btw. Ethereum holt langsam mit den Transaktionsgebühren auf:
https://bitinfocharts.com/comparison/transactionfees-btc-eth.html#log&1y#1y

Nun ja, Greg Maxwell ist offenbar strikt gegen BIP 148. Seine Argumente kann ich nachvollziehen, denn das ganze ist nicht ganz ohne Risiko.

Aber wie gesagt, abwarten. Vielleicht brauchen wir den UASF gar nicht.

Ich habe bisher nur einen uacomment UASF in der Config-Datei eingestellt. Es sind ja noch gut zwei Monate Zeit, bis dahin hoffe ich, dass es Bitcoin Core Binaries geben wird, bei denen man die entsprechende Option einstellen kann.

Bei den führenden Core Entwicklern wird offenbar noch abgewartet, man hört ja nicht mal mehr was zu dem BIP, was Covert AsicBoost verhindern soll.

Die Exchanges werden erst spät auf den Zug aufspringen, wenn der Druck seitens der Community noch größer geworden ist. Die grossen Exchanges, auf die es ankommt, werden das zuerst untereinander aushandeln, und dann eine gemeinsame Presseerklärung herausgeben. War ja letztes Mal auch so, als die Hashrate von BU anstieg, haben sie alle gleichzeitig verkündet, dass sie BU als Altcoin listen werden bei einem Fork.

Hab mir mal den BIP148 UASF Client installiert.
Dann kann ich am 01. August selbst sehen, was passiert.

Unter Linux ist es ja einfach selbst zu bauen, aber für Windows ist das ganz schön schwierig, wenn man nicht das Linux-Subsystem installieren will. Hatte selbst keine Lust mir dafür einen Gitian Build-Server aufzusetzen, entwickle nicht selbst mit Bitcoin-Core.
Und es gibt ja Binaries die immerhin von 2 Core Developern signiert sind.

Blöd ist eben, dass der auf die Unterstützung von Handelsplätzen und dann irgendwo doch auf Miner-Unterstützung angewiesen ist, während das bei BIP149 nicht so ist, aber das dauert dafür eben noch 1 Jahr, bis Segwit durch einen UASF aktiv wird.

Mit 51% Miner Unterstützung würde BIP 148 sogar reibungslos über die Bühne laufen. Das wird aber schwierig zu erreichen :oD

Mal schauen, was auf der Consensus Tagung passiert.

Was man sonst noch machen kann?
Den Ginger Testnet Client von RSK Rootstock am 22.05. installieren und ausprobieren, wie einem das gefällt.
Mit Jaxx gibt es schon ein Wallet, was die Smart Bitcoins von RSK unterstützt.

Hoffe das Prodnet von RSK Rootstock kommt dann tatsächlich einen Monat später.

Solange man nicht einsehen möchte, dass "man" tatsächlich "ich selbst" bedeutet, wird es beim aktuellen Zustand bleiben. Ansonsten liegen die Lösungen auf dem dem Tisch. Man muss sie nur nutzen.

Tja, eigenes Geld und eigene Verantwortung sind schon eine schwere Bürde.

Besteht eigentlich die Aussicht, dass man sich zeitnah auf eine Lösung einigen wird, egal welche das auch sein wird?

AntPool ist Jihan Wu, also der designierte BU Präsident. Ausserdem war Jihna Wu schon vor der aktuellen Kampagne ein SPV Miner.

Warum produziert AntPool "laufend leere" Blöcke? Wollen die keine Transaktionen mehr bestätigen?

ich glaube hier wird hinter den kullissen ein spiel gespielt. es muss nicht direkt core sein es koennen ja auch core supporter mit den entsprechenden mitteln sein. die tx von um die 8 (oder mehr) pro sekunde koennten fake sein.

https://blockchain.info/de/unconfirmed-transactions

luke jr. holt die konventionelle bombe hervor wie mezzo bereits geschrieben hat:

https://www.reddit.com/r/Bitcoin/comments/6bxpsj/bip148_and_the_risks_it_entails_for_you_whether/

EDIT: IMHO sachlich betrachtet sollte man jetzt so vorgehen, dass bei dem leidensdruck momentan (tx werden nicht confirmed), SegWit aktiviert werden sollte. egal jetzt ob die tx kuenstlich erzeugt werden oder nicht. sie sind eine tatsache. dann wartet man bis zum naechsten leidensdruck und erhoeht die blockgrenze was aber eventuell durch off-chain tx und hubs, welche die gestiegenenen fees zahlen, nie passieren wird. wenn SegWit durch ist ist es durch. paradigma wechsel in BitCoin.

Ausserdem liegt jetzt ein BIP148 (UASF) Pull Request vor: https://github.com/bitcoin/bitcoin/pull/10428

Danke! Habs jetzt glaube ich in etwa gerafft.

Es gibt übrigens Gerüchte über einen bevorstehenden Kompromiss, dem etwa 80% der Miner (nach Hashrate) zustimmen würden. Im Grundsatz ist es das Gleiche wie das "Hongkong Agreement": Segwit wird sofort eingeführt, und nächstes Jahr gibt es dann einen Hardfork mit Blocksize-Erhöhung (wohl 2 MB).

Nur falls es noch jemand nicht wusste. Könnte auch mit dem Kursverlauf zu tun haben (auch wenn ich einen Test der 2000 USD auch so erwartet hätte).

Kurz gesagt ja - ein witness program ist eine Angabe, welche Bedingungen erfüllt werden müssen, damit man später die Bitcoins wieder ausgeben kann, jedoch teilweise implizit, im Gegensatz zur bisherigen expliziten Vorgehensweise bei nicht segwit Transaktionen.

Bei einer nicht Segwit P2PKH Transaktion (1er Adresse) wird aus der Adresse vorgegeben, wie die Bitcoins gelockt werden.
Der Lock-Script wird immer im "scriptPubKey" des jeweiligen Outputs gespeichert.
Eine 1er Adresse sagt also implizit, dass der output mit folgendem explitzen Bitcoin Script Code zu erstellen ist:
"OP_DUP OP_HASH160 <20-byte-public-key-hash> OP_EQUALVERIFY OP_CHECKSIG".

Adressen sind eben dazu da, dass man als Benutzer nicht selbst diesen Bitcoin Script Code erstellen muss und zusätzlich noch Sicherheit hat, dass man durch die Prüfsumme in der Adresse vor Eingabefehlern geschützt ist.

Der Code zum unlocken der Bitcoins wird aktuell immer in die scriptSig eines Inputs einer Transaktion geschrieben. Die mit der obigen scriptPubKey gesperrten bitcoins kann man mit einer gültigen scriptSig im Format wieder entsperren.


Bei Segwit ist es etwas anders:

Quote

P2WPKH

The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):

    witness:      
    scriptSig:    (empty)
    scriptPubKey: 0 <20-byte-public-key-hash>

Während man bei den alten Transaktionen der scriptPubKey jedes mal explizit angibt, was die bitcoin script engine machen muss, so wird das bei segwit implizit, aber bleibt natürlich eindeutig. An der Stelle spart man dadurch immerhin 4 Byte pro Output und minimal Rechenzeit für das parsen des Skripts.

Damit das implizit funktionieren kann, hat man 2 Arten von "witness programs" für die Version 0 standardisiert.
Der scriptPubKey im Output einer Transaktion enthält deswegen als erstes Byte die Script Version und dann das witness program.

Beispiel für P2WPKH:
Explizit steht da also 0 <20-byte-public-key-hash> - bei P2WPKH Transaktionen ist also das witness programm der 20 Byte / 160 bit Hash des Public Keys.

Die Daten zum Entsperren wandern im Input einer Transaktion wandern vom Feld scriptSig in das neue Feld witness.

Implizit weiß man durch die Script Version 0 und die 20 Byte Länge des Witness Programs, dass bei diesem Format, zum entsperren der Bitcoins im Feld witness die zugehörige Signatur und der vollständige Public Key enthalten sein muss.

Extension Blocks sollten dann andere Versionen als 0 verwenden und können dort dann eben eigene witness programs standardisieren, die ggf. ganz andere Formate haben.

Das neue Adressformat aus BIP0173 speichert übrigens genau das:

Quote

...
Title: Base32 address format for native v0-16 witness outputs
...
"Bech32"
...
The following list gives valid segwit addresses and the scriptPubKey that they translate to in hex.
BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4: 0x0014751e76e8199196d454941c45d1b3a323f1433bd6
...

Vorne ist die codierte Adresse - BC für Bitcoin, 1 als Trenner ohne weitere Bedeutung, und dann der codierte scriptPubKey, also:
0x00 (version 0 witness program) 0x14 (20 Byte auf den Stack pushen) 0x751e76e8199196d454941c45d1b3a323f1433bd6 (und das 20 Byte P2WPKH witness programm bestehend aus dem Public Key Hash)

Mit Adressen, die sich an den Standard halten könnte man also auch Extension Blocks nutzen und hätte volle Kontrolle darüber in welchem Extension Block das ganze landen würde.

Danke nochmal für die Erklärung. So in etwa hatte ich mir das vorgestellt - deshalb hat mich "Carlton Banks"' Behauptung auch ziemlich irritiert.

Ich muss jetzt nur noch verstehen, was ein "witness program" wirklich ist - tu mir noch etwas schwer damit. Intepretiere ich den von dir zitierten Auszug aus BIP141 richtig, wenn ich es so beschreibe: eine Datenfolge, mit denen der Besitzer der Bitcoins die Bedingungen für die Autorisierung eines Outputs als Input einer neuen Transaktion erfüllt? Also in einer P2WPKH-Transaktion die Kombination aus digitaler Signatur und Public Key?

Klar - die Miner können nicht entscheiden, in welche Extension-Blockchain die das packen, das entscheidet man immer noch als User.
Theoretisch ist es natürlich möglich, dass ein anderer Miner zusätzlich in einer anderen Extension-Blockchain auch die Transaktion dort reinstellt, wenn man einen absichtlich schlechten Transfermechanismus designt - praktisch ist es aber nicht möglich, weil niemand sowas benutzen würde.

Bei dem Bcoin Extensionblock Transfermechanismus wird die 1:1 Beziehung analog der Segwit Spezifikation erzeugt.
Das heißt der Benutzer legt über die witness program version fest, in welchem Extension-Block die Transaktion gültig ist und über das witness program kann er sicherstellen, dass nur ein berechtigter Empfänger (also ggf. er selbst) die Bitcoins im Extension-Block entsperren kann.

Bcoin hat das aktuell noch nicht sauber spezifiziert, bzw. nutzt aktuell noch die v0 (und v1-v7 für zukünftige softforks) witness programs und ist somit aktuell noch inkompatibel zu Segwit in den kanonischen Blöcken. Aber es gibt ja insgesamt 16 witness program versions, das sollte man ja in den Griff bekommen :oD

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

Und eins kann ich noch hinzufügen die Miner werden ja dafür entschädigt, dass Sie Extension-Blocks unterstützen, weil sie innerhalb der Extension-Blocks ja Gebühren kassieren. Also wäre es für die Miner verkraftbar bzw. sogar interessant alle populären Extension-Blockchains zu unterstützen.

Und noch mal zu parallelen Extension-Blockchains. Jeder Extension Block muss ja seinen eigenen Netzwerk-Effekt erzeugen. Das ist alles andere als einfach, wie man an den Altcoins sieht, auch wenn es Extension Blocks etwas einfacher haben können.
Falls es in vielen Jahren mal wirklich mehrere Extension-Blockchains gibt, wird das gute Gründe haben.

Danke MoinCoin! Wenn ich das richtig verstehe (stehe etwas auf dem Schlauch), ist das Problem also durchaus vorhanden, dass Miner mehrere "Extension Blockchains" erzeugen können, die nebeneinander koexistieren.

Mir stellt sich folgende Frage aus der Sicht eines Core-Benutzers, der Extension Blocks "freigeschaltet" hat. Kann ich dann bestimmen, in welche Extension-Blockchain meine Transaktion kommt? Wenn ja (was ich aus deiner Antwort meine herauslesen zu können), dann sollte das Problem keine praktischen Auswirkungen für Nutzer haben: Ich als Core Nutzer muss dann einfach nur die Hauptblockchain und die gewählte Extension-Blockchain validieren. Der Miner kann nicht einfach kommen und meine Transaktion in eine andere Extension-Blockchain verschieben, so dass ich diese auch "checken" muss. Das könnte ja für Spam-Angriffe mit dem Ziel einer Zentralisierung missbraucht werden, was der vorhin erwähnte Nutzer befürchtete.

Oder habe ich da was falsch verstanden?

Bitcoin ist aktuell eine denkbar schlechte Währung für Darknets aufgrund der schlechten Anonymität. Confidential Transactions würde da deutlich was bringen.
Und warum keine Payment-Channels über TOR mit Confidential Transactions?

Also es kommt eben darauf an, was man verifizieren will.
Wenn man überhaupt keine Extension Blocks auswertet, kann man immer noch feststellen, dass es nicht mehr BTC gibt, als es geben sollte und alle Standard-BTC Transaktionen gültig sind, also alle Transaktionen die für einen wichtig sind.

Theoretisch könnte man natürlich die Resolution Transaction (Tx für Ext-Block -> Main-Block) so aufbauen, dass diese alle Extension-Block-Chains einschließt, dann müsste man alle Extension Blockchains auswerten um sicherzustellen, dass innerhalb der Extension-Blocks, die einen wirklich interessieren alles in Ordnung ist - aber warum sollte man das machen?

Jeder Extension Block hat seine eigenen Transfer-Mechanismus - es ist unmöglich mehr Bitcoins aus einer Extension-Blockchain heraus zu transferieren in die Main-Chain, als jemals Bitcoins von der Main-Chain in die Extension-Blockchain transferiert wurden.
Die Miner haben hier eine wichtigere Aufgabe für Sicherheit zu sorgen innerhalb der Extension-Blockchain, als bei der Main-Blockchain, weil nur Nodes, die auch die Extension Blocks unterstützen eben dort auch für Sicherheit sorgen.

Und aus ökonomischen Gründen kann das für Miner stimmen was der Nutzer da sagt, denn falls der vorherige Block ungültig hinsichtlich eines Extension-Blocks ist, ist es natürlich für den Miner des neuen Blocks eine große Gefahr, dass sein Block verwaist wird. Deswegen ist es sicherlich sinnvoll für Miner alle Extension Blockchains zu validieren.
Jeder Extension-Block ist deswegen auch darauf angewiesen, dass er ausreichend Miner (dauerhaft >50%) oder entsprechend viele Nutzer hat, die den unterstützen.

Das führt auch automatisch dazu, dass wir nicht allzu viele unterschiedliche Extension-Blocks haben werden, weil der Aufwand dann doch recht hoch sein wird für die Miner, damit löst sich das Problem etwas von selbst.

Aus sicht eines einfachen Nodes: Wenn einem ein spezieller Extension Block egal ist, kann es doch einem auch egal sein, ob innerhalb der Extension-Blockchain irgendwelche ungültigen Transaktionen passieren oder Extension-Bitcoins aus der Luft erschaffen werden, denn die könnten ja nur in der Main-Blockchain wieder freigeschaltet werden, wenn es die da auch vorher gab.

Als einfacher Node verhält es sich denke ich wie bisher - ggf. geht etwas von der Sicherheit bei 1-Bestätigungs Transaktionen verloren, wenn die Miner inkompetent sind, da es öfter zu einzelnen verwaisten Blöcken kommen kann.

Und die 100 Blöcke Cooldown helfen es abzusichern, dass wenn man Bitcoins aus einer Resolution Transaction empfängt, aber nicht die Extension-Blockchain überprüft, dass es nach den 100 Bestätigungen wohl kaum zu einem Reorg kommen kann. Das ist bestimmt noch ein Punkt an dem man arbeiten kann. Alternativ hätten wir mit Segwit ja auch atomische Cross-Chain Payments, mit denen man die Wartezeit umgehen kann und es somit für ein Node, die keine Extension-Blocks unterstützt auch nie notwendig sein wird Bitcoins aus einer Resolution-Transaction zu empfangen.

Viele BU-Unterstützer (zum Roger Ver - "Nodes die keiner Miner sind verlangsamen nur die Verbreitung von Blöcken")  dürfte das ja auch nicht stören, schließlich sehen viele es dort so, dass die Miner aus eigenem Interesse sorgen, dass alle Blöcke gültig sind.