Ja das mit den 51% Angriffen ist alles eher theoretischer Natur, selbst wenn Jihan das wollen würde und dann verspräche, dass alle Pools, die sich daran beteiligen kostenlose Hardware bekämen.

Aber selbst dann - hinter einigen Pools stecken ja auch viele unabhängige Miner, die einfach den Pool wechseln können.
Da müsste man dann schon tief in die Tasche greifen und wohl mit LTC/ETH oder USD/EUR die Miner direkt für ihre Hashpower vergüten, da BTC wohl massiv an Wert verliert bei einem 51% Angriff und somit das viele Miner nicht wollen würden.

Freue mich schon auf morgen, denn dann ist es endlich soweit - Rootstock RSK Testnet wird öffentlich :oD
Das würde mir persönlich als Übergangslösung reichen, bis Segwit in einem Jahr über UASF BIP149 aktiviert wird oder ein Kompromiss ala Segwit2MB aktiviert wird.

Hey Christoph - hast du berücksichtigt, dass nicht die Anzahl der Blöcke zählt, sondern Anzahl der Blöcke * Schwierigkeit aka kumulierter PoW?
Wenn die leerminen auf der UASF Chain, dann löschen die leicht ihre alte Chain aus.

Man braucht ca. 69% Mining Power um die UASF Chain effektiv zu killen:
34% um schneller zu sein, als die BIP148 Miner um dort nur leere Blöcke zu minen
35% damit die legacy Chain mehr kumulierten PoW hat

Das Problem ist eben, dass der Angreifer zwei Blockchains erstellen muss, die BIP148 aber nur eine.

Eigentlich braucht man noch mehr, damit man sicher ist.
Heute Nacht konnte man das wieder gut sehen - einige Blöcke haben mehrere Stunden gebraucht um gefunden zu werden.

Und wenn man 49/51 splittet, dann sind immer noch nur 2/3 aller Blöcke in der BIP148 Chain nutzbar.

Soviel dazu - ich halte das trotzdem für keine besonders gute Idee das durchzuziehen, wenn nicht die Mehrheit der Miner hinter BIP148 steht.

Edit:
BitcoinEC ist leider nicht funktionsfähig, sondern ist über das Github Repository nie hinausgekommen.
Die tatsächlich implementierte Funktionalität entspricht ungefähr dem einen uacomment zu setzen.
Siehe tatsächliche gemergte PRs: https://github.com/bitcoinec/bitcoinec/pulls?utf8=%E2%9C%93&q=is%3Apr

Extension Blocks von Bcoin hat aktuell kein BIP, sowie eben BU ja auch nicht den BIP Prozess nutzt.
Glaube da ist noch kein Aktivierungsprozess spezifiziert. Wird aber höchstwahrscheinlich ein Soft Fork ohne inhärentes Chain Split Risiko.

BIP148 ist Erzwingung eines MASF von Segwit über BIP9 per UASF Flagday 1. August 2017 -> Chain Split Risiko
BIP149 ist Segwit UASF im Juni 2018 (oder so) per Flagday über BIP8 Prozess -> Vorzeitige Aktivierung durch Miner jederzeit möglich, kein inhärentes Chain Split Risiko

BIP100 ist ja ein Hardfork, das wird noch lange dauern, bis sowas in der Art kommt.

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.

@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

Bearstamp macht seinem Namen mal wieder alle Ehre.
Schön zu sehen, wie die Walls vernichtet werden.

Nach 2000 USD ist im Augenblick noch nicht viel Tiefe.
Könnte dann fix aufwärts gehen.

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.

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

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.

@dinofelis
Are you familiar with the LTCP from Sergio Demian Lerner (RSK Labs)?
AFAIK it is especially suitable for refilling payment channels, but however the Bitcoin architecture makes it harder, than an account based system like Rootstock or Ethereum, but nonetheless it could provide immense blockspace savings for bitcoin.

As a softfork LTCP would use extension blocks on bitcoin to provide an account based system layer
https://www.docdroid.net/QHJX8Ml/luminotransactioncompressionprotocolltcp.pdf.html#page=8

No, sorry this is false.
A miner cannot choose a random extension block, as he also cannot put a bitcoin transaction on the litecoin blockchain.
Technically he can try, but the Block/Tx would be invalid or junk data.

Look at the bcoin ToTheMoon Spec and BIP141.

A user can choose to use the extension block, if he uses the witness version specified by that extension block proposal and witness programs.

A user has to transfer his bitcoins from the main blockchain to a specific extension blockchain with an "enter transaction".
Then he can transfer the bitcoins within the extension blockchain, without touching the main blocks.
If he needs the bitcoins back in the main blocks, he sends the bitcoins with an "exit transaction" back to the main blocks. This is a bit more complicated and will be done by miners through a resolution transaction and needs a cooldown period of 100 blocks, before the bitcoins can be spent again.

Of course the user does not need to do this manually - this is done for the user by your wallet Software. The wallet software will use a payment protocol or you'll provide a specific extension block bitcoin address or an main block address (1 and 3 adresses).
For sending to an extension block from the main blockchain your wallet only has to understand the extension block addresses. It does not need process the extension block data.

To send and receive in the extension blocks your wallet has to support the specific extension block and you have to enable support for the specific opt-in extension block in your wallet.

And you don't even need to process the extension blocks, if you receive from an extension block to your main block address.
Receiving from an extension block address to a main block address with a software, which is not aware of  (or has not opted-in to) extension blocks is similar to how unupgraded wallets handle segwit transactions.
You cannot tell if the unlock script was correct, because you don't see it, but you can tell, that you have received real bitcoins which are now under your control, and that all bitcoins in the main block are valid, which is an important reason to run a full node in the first place.


Some miner may put this to an additional extension block, but it would be invalid or just junk data without meaning, where no one ever could be forced to process that junk data. Meaning no miner would do that, because he would just waste his resources.

The important fact remains:
The user is totally in control, where the transaction will end up and has meaning or in which utxo set his bitcoins are stored.
There will be separate (different kind of) bitcoin addresses for extension blocks.
Think different than 1 and 3 adresses for main blocks, which in fact are a recipe how to create the "lock script" for the outputs in a bitcoin transaction. In fact the recipe from 1 (P2PKH) addresses are completely incompatible with extension blocks.
3 (P2SH) Addresses are invalid, because the recipe tells to store the output in the canonical block utxo and not in the extension block utxo (segwit can use nested P2SH, because it uses the main block utxo)

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.

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?

Warum gibt es dann keine Altcoin, die Flex trans implementiert, wenn das so viel besser ist?
Hardforks sind für die meisten Altcoins ja kein Problem.

Warum benutzt du dann so ein besch... Wallet? Zwingt dich Blockstream dazu?

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.

Ja - erinnere mich mal, dass es ein Deck gab von Roger Ver, allerdings ohne Quellenangaben und ohne Kontext und ohne Zeitangabe, von wann diese Aussagen stammen - ggf. sind diese Aussagen veraltet und die betreffenden Personen haben ihre Meinung geändert?
Edit: Quellenangaben sind doch unten auf den Slides - naja werde ich mir mal in Ruhe durchlesen
https://www.docdroid.net/NG1sbVq/pantera-march-2017.pdf.html

Aber was weiß ich? Segwit hat einen Witness Scaling Factor größer 1, was bedeutet, dass der verfügbare Blockspace mit Segwit erhöht wird.
Taten sind für wichtiger als Worte, und das zeigt für mich zumindest, dass die Segwit Macher aktuell etwas gegegen volle Blöcke machen wollen.

Ich bin zumindest der Meinung, dass eine gewisse Fee wirkungsvoll gegen Spam schützt. Die sollte eben in dem Rahmen liegen, in dem es einen nicht wirklich stört, also unter 50 cent / Tx.
Jeder einzelne 1 € Kaffee muss nicht wirklich in die Blockchain (siehe /r/btc Thread neulich)

Aus meinem Studium weiß ich aber auch, dass Systeme die an der Kapazitätsgrenze arbeiten und nicht konstante Verarbeitungsgeschwindigkeit aufweisen (hier Blockzeit) sehr unvorhersehbar reagieren.
Das kann man ja ganz leicht mit einer diskreten (/eventbasierten) Simulation nachweisen, ohne das man die Mathematik dahinter verstehen muss.

Volle Blöcke mit dem aktuellen Mining Prozess ist wirklich suboptimal. Mit Bitcoin-NG könnte ich mir das besser vorstellen. Aber auch da bleibt es schwer, weil man beim Senden der eigenen Tx abschätzen muss, was alle anderen Menschen auf der Welt für Tx demnächst senden werden, um die eigene Gebühr richtig zu setzen.

Abgesehen davon fühle ich mich als Benutzer von den Minern missachtet.
Das Core oder Blockstream Segwit für irgendwas in der Zukunften brauchen mögen ist mir doch egal.
Mein Eindruck ist, dass deutlich über 80% aller Bitcoin Nutzer Segwit nutzen möchten.
Ich als Benutzer will es haben - die Miner sind doch keine Dienstleister gegenüber Core oder Blockstream, also sollten die doch bitte im Sinne der Nutzer handeln.
Einige Miner weisen leider ein Verhalten auf, wo ich mich frage, für wen die Minen wollen.
Wenn die Miner sich so auf Core fixieren (HongKong Agreement) kommt das bei mir so an, als ob wir Nutzer unwichtig sind.

Am Ende sind doch wir Nutzer die Entscheiden, ob wir Bitcoin benutzen wollen.


Also meiner Meinung nach macht es einen Hard-Fork nur schwerer, wenn sich zeigen sollte, dass Segwit ausreichen sollte und LN Software verfügbar ist und zufriedenstellend funktioniert.
Wenn man das Gegenteil zeigen könnte, würde dies meiner Meinung nach die Argumente für einen Hard-Fork stärken.
Bis dahin ist Segwit eben die einfacherer auszurollende, besser getestete, sowie technisch elegantere Lösung.

Und für den Fall, dass Blockstream sagen würde - ihr müsst jetzt leider alles weitere auf unserer Elements Sidechain machen und dafür bezahlen würde sich automatisch ein Sturm der Entrüstung ausbreiten, der einem Hard-Fork breite Unterstützung zusichern würde. Aber solange das nicht eintritt bleibt das nicht mehr als eine Verschwörungstheorie.

Je länger man aber Segwit nicht aktiviert, desto schwächer sehe ich die Argumente für einen Hard-Fork. Wenn man lang genug wartet haben wir bald die LN-Software, andere Sidechains und ggf. Extension-Blocks.

Das Spam-Limit hat überhaupt keine Bedeutung im Rahmen eines HFs - siehe auch Bitcoin-Dev Mailingliste diesen Monats - Diskussion von Sergio Lerner. Im Rahmen eines Hard-Forks kann man doch alles ändern, was man will.
Andersrum - das macht doch einen HF einfacher zu verkaufen, weil man die Magic Numbers loswerden kann die man für den Softfork als Übergangslösung braucht.

Und zu den Validierungszeiten.
Eine Transaktion mit 200 Inputs erzeugt einen Berechnungsaufwand bei den Signaturen von 40000 Inputs.
Mit der Rechenzeit kann man also bereits die Signaturdaten von über 1 MB Segwit Transaktionen locker abdecken.
Soweit ich weiß ist aktuell bei CPU-Zeit der limitierende Faktor immer noch die Signaturoperationen.
Das heißt Segwit schafft da die Möglichkeit für einen Hard-Fork hinsichtlich der CPU Validierungszeit sub-linear zur Blockgröße zu skalieren.

Kurz noch zum pruning:
Man muss ja eine gewisse Menge an Blöcken vorhalten bei einem geprunten Client, damit man auch einen Reorg verarbeiten kann.
Mit Segwit kann man allerdings auch da schon die Signaturdaten prunen und sich trotzdem sicher sein, dass die lokalen Transaktionsdaten noch intakt sind. Somit kann man auch auf einem Gerät mit eingeschränktem Speicherplatz leichter wesentlich große Blöcke verarbeiten.

Für mich macht Segwit deswegen in Summe einen Hard-Fork viel einfacher. Soweit ich weiß haben ja auch viele Core Developer gesagt, dass für die Segwit ebenfalls eine Voraussetzung für einen Hard-Fork für die erhöhung der Blockgöße sehen, vielleicht deswegen.

Ist wieder einiges passiert in letzter Zeit - ich versuch mal etwas aufzuholen

lol ihr seid lustig. Bin noch weit davon entfernt, das ich mich selbst als technischen Profi bezeichnen würde. Aber schön, dass es euch nützt, was ich schreibe und wohl auch noch einigermaßen verständlich ist.

Und zu dem Vorschlag. Finde den recht interessant. Selbst, wenn man den Algo durch einen Spam-Angriff austricksen will sind die Auswirkungen gering genug.
Meine Meinung ist, dass wir mit den Hauptblöcken sehr konservativ umgehen sollten was Blockspace angeht um die Dezentralisierung nicht zu gefährden.
Ich habe aktuell Zweifel, ob Moores Law in seiner jetzigen Form bestehen bleibt, von finde ich eine lineare Skalierung interessant.

Die Frage bleibt, findet sich eine ausreichende Mehrheit dafür? Und meine persönliche Meinung ist, dass wir so wie Bitcoin aktuell funktioniert eher 1 Jahr braucht, bis man einen Hardfork aktivieren kann, nachdem wichtige Clients die Software rausgebracht haben. Wird dann wohl frühestens 2019 was.

Paar kleine Anpassungen sind sicher auch nicht schlecht, zum Beispiel, dass man für die alten Transaktionen mit dem quadratischen Rechenaufwand für Signaturen weiterhin insgesamt nur 1 MB pro Block maximal zulässt und den zusätzlichen Speicherplatz nur linear skalierenden Transaktionen (z.b. Segwit) gestattet. Ich weiß, dass es nicht quadratisch zur Blockgröße ist, aber das alte Design von Satoshi ist einfach schlecht und man kann so viel Rechenzeit sparen, ohne das irgendwelche alten Transaktionen ungültig werden und so dem Zentralisierungs-Effekt entgegen wirken. Wäre mal interessant zu wissen, wie der Faktor ist für Worst-Case 1 MB Block mit alter TX und Worst-Case Block mit 1 MB an Segwit TX. Denke das wir da irgendwo zwischen Faktor 100 und 100000 liegen, die Segwit schneller ist - hat da irgendwer Daten?

Kurzer Abschweif:
Bei Extension Blocks halte ich persönlich die Auswirkungen von Zentralisierung für beherrschbar. Wir haben ja immer noch die dezentralisierten kanonischen Blöcke die weiter jeder benutzen kann. Das ist übrigens auch das einzige was mich an dem Purse/Bcoin Vorschlag stört. Fände es besser da aggressiver zu sein und  in die vollen gehen und den Code so designen, dass man direkt auf 20+ MB Blockgröße bei Bedarf wechseln kann (statt max 6MB).

Hallo Christoph,
welche Macher meinst du denn? Hast du irgendwelche Nachweise?
Eric Lombrozo?
Johnson Lau wohl kaum, so viel wie der mit Hardforks und Extension Blocks forscht?
Pieter Wuille?
Gmax? Hat soweit ich weiß Segwit nicht implementiert, und zudem hatte er diese Woche noch auf Reddit geschrieben, dass er volle Blöcke für nicht notwendig hält, damit Bitcoin ökonomisch stabil ist.
Adam3us programmiert ja sowieso nicht für Bitcoin hat nichts mit Segwit zu tun.
Der einzige, der verbleibt ist Luke-Jr. Aber ist der ein Segwit-Macher? Soweit ich weiß hat er nur die Idee beigetragen, Segwit als Soft-Fork möglich zu machen. Davon abgesehen hat er ein paar komische Ansichten bzgl. voller Blöcke und Spam, aber die sind meiner Meinung nach überhaupt nicht repräsentativ für Core.

Und was hat das damit zu tun, das wir in Zukunft auch volle Blöcke haben? Segwit macht doch einen Blocksize Hard-Fork viel einfacher. Man hat dann im Hardfork die Worstcase Validierungs-Zeiten für den Block viel geringer zu gestalten. Und mehr prunen kann man auch, also kann man so die Hardwareanforderungen im Vergleich zu einem einfachen Blocksize Hard-Fork viel geringer gestalten.

Und mittlerweile gibt es auch so viele Programmierer die sich mit Segwit auskennen - sogar ViaBTC kennt sich ja jetzt dank Litecoin mit Segwit aus.

Hatte gestern etwas Glück, dass meine Transaktionen noch durchgegangen sind.
RBF ist aber auch nciht so einfach. Hatte eine TX mit 130 Sat/Byte, wollte auf 150 Sat/Byte erhöhen, Bitcoin-Core hat mich das aber nicht Broadcasten lassen - hat mir nur eine Fehlermeldung zurückgegeben, dass die Fee zu gering sei. Glücklicherweise ist es dann doch nach einer Stunde bestätigt worden.

Und zum Schluss gibts sogar mal was neues von BU - da kommt ja sonst nicht so oft was letzter Zeit
BUIP055: Increase the Block Size Limit at a Fixed Block Height
Macht es denke ich auch möglich sich besser vor einem BU Hard-Fork zu schützen.

Edit:
Hatte vor ein paar Tagen kurz zur Segwit Aktivierung über BIP8/BIP149 geschrieben, hat noch niemand hier im Tread was dazu gesagt. Würde mich freuen zu hören, was ihr darüber denkt.
Damit würde man sich ja die Nuclear-Option sparen - die Miner müssten die Spaltung der Blockchain aktiv herbeiführen.
Wesentlich sauberer als BIP148. Der einzige Bekannte, der für BIP148 noch trommelt ist soweit ich weiß Luke-Jr.

@mezzo
Okay - also dann doch eher manuell.
Das Muster ist zumindest nicht BU, denn die wollen ja Hardforken.
Wenn irgendwelche Pools die alte Chain zusätzlich killen wollen vielleicht.

Das mit der Marketingkampagne wird schwierig..
Da müssten sich so viele miteinander verschwören, damit viele darauf reinfallen würden.
Ein staatlicher Akteur, der das Internet in seinem Land zensieren kann, hätte vielleicht den Hauch einer Chance, aber nur in seinem Land. Außerhalb kann ich mir das schwer vorstellen.

Kannst du mir erklären was du da mit Hardfork meinst? Die Validationsregeln werden doch nicht aufgeweicht oder inkompatibel mit den alten Regeln.
Chain split != Hardfork

Für mich ist das ganz klar ein Softfork.
Entweder man sagt, dass Block X ungültig ist, wenn er nicht einen bestimmten block hash hat, oder man sagt, dass Block X ungültig ist, wenn er einen bestimmten block hash hat. Beides sind Verschärfungen der Validierungsregeln und damit ein Softfork.

Bei einem Hardfork müsste man ja auch die Software updaten.

Ich denke im Fall eines Angriffs muss man eben als Nutzer auf der Hut sein und sollte auch ruhig mal einen Tag warten bis man eine Tx als bestätigt ansieht. Miner müssen wirklich aktiv arbeiten und sich untereinander abstimmen, damit Sie mit Ihrer Hashpower an der gleichen Chain arbeiten.

Wahrscheinlich wird ein Wechsel weg vom aktuellen PoW sinnvoll, denn der Angreifer könnte immer wieder neue (kurze) Attacken starten.

Double spend ist mit RBF doch mittlerweile ziemlich einfach oder?

Mit zu niedriger Fee senden - Ware erhalten.
Dann mit RBF einen double spend durchführen.

Immer mehr Wallets haben RBF Unterstützung.
Wenn ich eine Transaktion sende, die mir beim Empfänger sowieso erst nach Bestätigung gut geschrieben wird, sende ich mittlerweile immer RBF.

Blockchain.info zeigt das übrigens nicht an, ob die Transaktion RBF ist oder nicht.

Sollte man auf jeden Fall drauf achten, dass wenn schon unbestätigte Transaktionen akzeptiert werden, dann dass die ohne RBF sind.

Und die Wahrscheinlichkeit kommt eben auf die höhe des Betrags an, sowie die Wahrscheinlichkeit für den Betrüger, dass er nachträglich erwischt/bestraft werden kann. Beim Room77 werden die damit wohl kaum Probleme haben.

@mezzo
Du meinst also, man würde die guten Blöcke daran identifizieren können, dass die wieder verschwinden?
Oder weniger PoW haben, als die gute Chain?
Bzw. ein böser Block ist ein solcher, der einen anderen orphaned?
Das könnte auch wieder neue Möglichkeiten für einen Angriff eröffnen und zwar mit weniger als 50% Hashpower.

Das erkennen, dass ein Angriff passiert ist sicher noch relativ einfach.

Aber erklär mir mal bitte, wenn das technisch so einfach zu neutralisieren ist, wie du das machen würdest.
Anhand welcher Kriterien könnte man das automatisiert machen, ohne das man neue Angriffsvektoren eröffnet?

Wenn man einschränkt, welche Blöcke gültig sind, entspricht das der Definition eines Softforks.
Und sowohl Miner, als auch User müssen sich dann koordinieren, damit Sie mit den gleichen Regeln arbeiten, damit sie sich auf der gleichen Chain befinden.
Wenn die Nodes die Regeln des Softforks nicht kennen wird es aber schwierig, dann landen die schnell auf der "falschen" Chain.

Edit:
BU Nodes fallen gerade mal wieder reihenweise aus

Und ungefähr passend dazu neu - Ein schönes Video von Andreas über die Bedeutung von Nodes, leider mit übersteuertem Ton
https://www.youtube.com/watch?v=fNk7nYxTOyQ

Edit 2:
Ist euch aufgefallen, dass BW Pool aufgehört hat 8MB Blocks zu signalisieren?

Dazu müsste man aber erstmal erkennen können, von wem der Block ist.
Der Angreifer muss seine Blöcke ja nicht so einfach erkennbar machen, wie die Pools das im Augenblick tun.

Das könnte gehen, indem man der Einfachheit halber den Pubkey-Hash der Coinbase Transaktion (praktisch die Bitcoin-Empfangsadresse) zur Erkennung nimmt oder natürlich die Miner die Blöcke gleich digital signieren in der Coinbase-Tx.

Das geht meines Wissens nach nicht so einfach mit Bitcoin-Core, allerdings sollte man das über die RPC Schnittstelle und einer weiteren App schon hinbekommen können.

Einfach ist das aber alles nicht.
Die Informationen zu sammeln ist ziemlicher Aufwand - und alle müssen die gleichen Informationen verwenden, sonst gibts Chaos.

Das geht aktuell nur mit Payment Channels.
Gibt zwar bereits seit längerem Lösungen von 21, aber die setzen sich nicht durch.
Ggf. wird das möglich mit Lightning Network Payment Channels, das braucht aber einen Malleability Fix.
Segwit ist die mit Abstand bekannteste und am besten getestete Lösung, aber das könnte noch ein Jahr dauern, bis das aktiviert wird, da viele Bitcoin-Miner das aktuell nicht wollen.

Dir bleibt sonst aktuell nur übrig auch unbestätigte Transaktionen anzunehmen.

Edit:
Guck dir mal die Zahlungsdienstleister an, die übernehmen da ggf. das Risiko für dich.

Server spinnt - ein paar mal aktualisieren.
Irgendwann geht es schon.