Re: Der Aktuelle Kursverlauf blockgrösse

[d5000]

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?

[MoinCoin]

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

...
Witness program

A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
...
If the version byte is 0, and the witness program is 20 bytes:
It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.
The HASH160 of the public key must match the 20-byte witness program.
After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.
...
If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.[2]

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.

[d5000]

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?

[MoinCoin]

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 <sig> <pubKey> wieder entsperren.


Bei Segwit ist es etwas anders:

P2WPKH

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

    witness:      <signature> <pubkey>
    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:

...
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.

[d5000]

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).

[mezzomix]

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

[Gyrsur]

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.

[MemberCount+1]

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

[mezzomix]

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

[Milquetoast]

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

[Rakete4]

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

[mezzomix]

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

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.

[MoinCoin]

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.

[Rakete4]

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.

[d5000]

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.

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.

[MoinCoin]

BIP148 not as much-- unless it's widely enough adopted it's more disruptive than it could have been--, but UASF, absolutely. I said as much on the bitcoin-dev list weeks ago, it was linked on rbtc. Try to keep up.
Every softfork is a user activated softfork, ultimately. If something is only enforced by miners, it's mere policy-- and subject to go away at miners whim or as the collection of miners changes.

@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

[Bergmann_Christoph]

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:

BIP148 is a UASF that is designed to cause the existing SegWit MASF deployment to cause activation in all existing SegWit capable node software (which currently is 80% of the network nodes).

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?

[Rakete4]

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.

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.

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

BIP148 is a UASF that is designed to cause the existing SegWit MASF deployment to cause activation in all existing SegWit capable node software (which currently is 80% of the network nodes).

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?

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.

[MoinCoin]

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?

BIP148 ist ja kein klassischer UASF (vgl. P2SH), sondern will ja den Miner Activated Soft Fork erzwingen und somit Segwit bei den Clients ohne UASF-Update herbeiführen.

Das heißt wenn die BIP148 Chain irgendwann einmal den meisten kumulierten Proof-of-Work hätte (~51% aller Miner dauerhaft), sind alle alten Clients ja auf der gleichen Chain, weil BIP148 nur ein Softfork ist.
Alte Clients (>= Satoshi 0.13.2) überprüfen ja über den BIP9 Version bit, ob Segwit dann irgendwann aktiviert wird.
Mehr machen die BIP148 Clients ja auch nicht, außer dass zusätzlich eben alle Blöcke als ungültig anerkannt werden, wenn der Miner nicht die BIP9 Aktivierung von Segwit signalisiert.


Wenn eben zum Beispiel nur 40% aller Miner einer BIP148 Chain folgen, dann haben wir eben zwei Chains.
Die lässt sich übrigens nicht so einfach 51% angreifen, weil man dann zwangsweise Segwit aktivieren würde ohne, dass man das will.
Normale Clients folgen dann eben der Chain, die für Sie gültig ist und den meisten PoW hat, also in dem Fall nicht die BIP148 Chain.
Hier hätten alte Clients also kein Segwit.
Manuell kann man der BIP148 Chain folgen über den RPC Aufruf "invalidateblock" an der Stelle, wo die zwei Blockchains auseinandergehen.


Falls dann irgendein Miner aus Trotz einen Hardfork initieren würde mit Big-Blocks, dann landen alte normale Clients mittelfristig auch auf der BIP148 Chain, weil die Big-Block Chain ja ungültig für die meisten Knoten ist. Dann wirds spannend, weil BU immernoch keine wipeout protection eingebaut hat.

Was natürlich auch passieren kann, und was ich aktuell für relativ wahrscheinlich halte, wenn keine Exchanges mitziehen ist, dass überhaupt kein Miner BIP148 mined, dann bleibt die BIP148 Chain eben stehen. Normale Clients bekommen dann überhaupt nichts von der ganzen BIP148 Aktion mit.

Edit:
Hätte nichts gegen Segwit+2MB, aber viel schneller als BIP149 wird das auch nicht.

[Z80]

Also, auch wenn man hier nicht voten kann und meine Meinung/Wunsch eh nicht von Core oder Unlimited gehört wird:
Ich bin für Segwit+2MB als Kompromiss!

Nebenbei... es wäre für Core doch sooo einfach. Stimmen sie Segwit+2MB zu würde die Bitcoinwelt sofort folgen und unlimited wäre Geschichte. Aber nein, keinen Millimeter wird sich bewegt, koste es was es wolle. Der totale Sieg oder Untergang.  Naja, ist traurig.

Aber mal ne Frage... ich komme langsam durcheinander mit den BIP's...
BIP-148 war UASF-Segwit richtig?
BIP-149 war genau nochmal was?
BIP-100 gab es doch auch noch... und Extension-Blocks hat bestimmt auch nen BIP, oder?
Welche BIP's stehen sonst noch zur Debatte? Könnt ihr mich mal kurz aufklären?