Ich dachte Du bist SW-Entwickler, von daher duerftest Du damit vetraut
sein.

Was? Ich? Wie kommst Du denn auf sowas?

Es wird niemand gezwungen, einen bestimmten Pfad einzusetzen. Der
Konsens entscheidet dann, was sich durchsetzt.

Bitcoin ist kein Konsenssystem. Konsens gibt es nur in der kleinen Dunbar-Kommune, aber nicht in einer Gesellschaft. Das müsstest Du eigentlich wissen nach so vielen Jahren im DGF. Bei Bitcoin entscheidet die Hashing Power, also momentan 3 (in Worten: drei!) chinesische Mining Pools, die mit den Blockstream/Core Developern gerade kürzlich ein Hinterzimmer-Agreement abgeschlossen haben, und letztere machen bekanntlich Propaganda über zensurierte Foren. Mehr Zentralisierung (Entwicklung / Mining) ist kaum mehr möglich.

Die politische Propaganda
ist voellig ueberfluessig, es sei denn man kann technisch nicht ueberzeugen
und versucht es dann auf unfaire Art. Klar, so entstehen diese albernen VTs
ueber Core-Devs.

Dass einige Core Developer mit Adam Back und dem Scammer Austin Hill die Firma Blockstream gegründet und Geld eingesammelt haben, um noch mehr Core-Entwickler zu engagieren und die Mainchain zu limitieren, damit sie dann an den Side-Chains abkassieren können, ist ein derart bekannter und offensichtlicher geschäftspolitischer Fakt, dass es schon eine Zumutung ist, hier von VT zu fabulieren.

Beschaftige Dich mal mit der Kollisionsrate als Funktion von Latenz und
Blockgroesse. Und die Dezentralitaet als Funktion der Latenz. Dann wirst Du
sehen, dass Core keine neuen Loesungen verhindern will, sie gehen einfach
nur wissenschaftlich vor (halten sich ja aus der Politik auch weitestgehend
raus).

Wenn ausgerechnet diese Figuren, die mit allen Mitteln eine Dezentralisierung der Entwicklung blockieren, über Dezentralität dozieren, dann wird mir jedesmal übel.
Ja, Latenz ist das neue Schlagwort der Core-Entwickler. Vorher war es die Bandbreite.
Tatsache ist, dass es keinerlei Probleme gab mit zunehmender Blockgrösse hinsichtlich der Dauer der Transaktionsbestätigungen:

https://blockchain.info/de/charts/median-confirmation-time?timespan=all&showDataPoi...

Und ausserdem erhöht dieser Segwit-Unsinn mit dem 75% Discount für spezielle Transaktionen die Blocklimite sofort auf 4 MB, was plötzlich okay ist, weil mit dieser Subvention Lightning erzwungen werden soll. Aus dieser Vervierfachung der Limite resultiert aber kaum eine Erhöhung des Transaktions-Durchsatzes.

As it is commonly known, actual normal space for segiwt is at around 1.6 or 1.7mb. However, an attacker is given 4mb. Next year, the hardfork is to increase maxblocksize to 2mb, with segwit on top that makes it 3.5 or so mb for normal usage, but an attacker is given 8mb. And what next, 5mb for normal users but 20 for attackers? 10mb for normal users but 100 for attackers?

The whole thing is design to make onchain scaling a punishment. It follows the same logic as flexicap whereby if miners want to increase the blocksize they have to pay a portion of their mining reward in exchange thus punishing them. So too segwit punishes everyone by incorporating a penalty in giving attackers far more blockspace than normal users.

https://bitco.in/forum/threads/hello-shills.1002/page-2#post-16352

https://www.reddit.com/r/btc/comments/4c14jz/if_the_block_size_doubles_does_the_cost_of...

Zudem müsste langsam auch der Hinterletzte mitbekommen haben, dass Spam-Attacken dann am einfachsten zu bewerkstelligen sind, wenn die Blocklimite nur knapp über der jeweils durchschnittlichen Blockgrösse angesetzt wird. Der helle Wahnsinn:

The greater dishonesty is claiming that a block size limit increase would be a change, whereas the shift to a fee market would not be.
Bitcoin was designed, and explicitly described, as having no effective limit on block size; so that every transaction that paid for its processing cost would be confirmed in the next block. For that goal to be met, any block size limit in the implementation should be comfortably larger than the peak block size in normal traffic. For security against spam attacks, any such limit should be many times larger than that.
That was bitcoin's service model when it was offered to the public in 2009. That is how it has been until July 2015. That is how it should be, to be a usable payment system. If there is a "social contract", it should be to keep it working like that: with no effective limit on block size.
Blockstream wants to change bitcoin radically, to a system where blocks have a limited size, set by the developers to be much less than the potential demand; so that users have to compete for space in a running auction, the "fee market". This new service model implies unbounded confirmation delays, higher fees for users, and less revenue for miners. It also forces users to remain online, checking the progress of their transactions, and issuing replacement transactions when there are unexpected surges of demand.
Blockstream's bosses seem to be convinced that this model is better than Satoshi's; and are determined to impose it on everybody, like it or not.
AFAIK, this fixed-size model was Greg's idea, and he has stubbornly stuck to it in spite of everybody telling him that it was a totally bad one. If Greg was honest, he should have tested his idea by creating an altcoin with limited block size and a fee market; and only propose that change of model for bitcoin if and when that test succeeded. But that would have been too much work and too much time. Moreover, Greg himself must have realized that no one would use such a coin. Fully in the spirit of the classical hacker, he did not see anything wrong with "testing" his idea by deploying it in bitcoin itself, using all the bitcoin users as guinea pigs alpha testers.
Also in the classical hacker spirit, he never thought it necessary to describe and justify his proposed change to the users, much less seek their approval, before implementing it. There is still no BIP for the "fee market". That is not surprising: besides being "unnecessary" in Greg's view, it would be very hard to write -- especially the "Expected Benefits and Drawbacks" section.

https://www.reddit.com/r/btc/comments/4c0sql/cores_strategy_is_to_make_bitcoin_permissi...