Bitcoin Forum
March 28, 2024, 10:55:45 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 94 »
  Print  
Author Topic: Re: Der Aktuelle Kursverlauf blockgrösse  (Read 185654 times)
mezzomix
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 10, 2017, 06:56:37 AM
 #221

Der Vorschlag ist besser als BU. Er enthält allerdings ziemlich viele Fallstricke, über die eine schlechte Implementierung stolpern kann. Ich persönlich möchte eine solche Entscheidung gar nicht bei den Minern sehen, vor allem nicht mit der aktuellen Pool Landschaft.

Ich hätte nichts gegen einen grösseren Hard-Fork einzuwenden, bei dem man neben einigen Optimierungen und einer für die nächsten Jahre ausreichenden Block-Size auch einen Mining Algorithmus nutzt, der eine Auslagerung von Arbeitsleistung effektiv unmöglich macht. Ein Algorithmus, der in jeder Runde die Informationen aus dem Block und aus dem UTXO Set verwertet, würde das Mining wieder auf die ursprüngliche Idee zurückführen. Daneben würde dies einen einfacheren Bootstrap auf Basis eines UTXO Commitments erlauben.
1711623345
Hero Member
*
Offline Offline

Posts: 1711623345

View Profile Personal Message (Offline)

Ignore
1711623345
Reply with quote  #2

1711623345
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711623345
Hero Member
*
Offline Offline

Posts: 1711623345

View Profile Personal Message (Offline)

Ignore
1711623345
Reply with quote  #2

1711623345
Report to moderator
commander11
Sr. Member
****
Offline Offline

Activity: 545
Merit: 250


View Profile
March 10, 2017, 07:12:51 PM
 #222

https://zander.github.io/posts/BitClub-attack/


Wieso schreibt eigt keiner was das die Segwit Supporter das NEtzwerk  Attacken jetzt wo klar ist langsam selbst dem letzten kronleuchter

das Blockstream Core Failed ist sieht man das wahre Gesicht von den Segwit Leuten indem sie versuchen durch Attacken zu zeigen das wir unbedingt Segwit brauchen  ...

Hätte auch schief gehen können und Bitcoin mächtig schaden können  Roll Eyes  Huh Huh Huh Huh
Limx Dev
Copper Member
Legendary
*
Offline Offline

Activity: 2324
Merit: 1348



View Profile
March 11, 2017, 01:09:23 PM
 #223

Ich habe jetzt einen Vorschlag aufgegabelt, der mir wirklich gefällt. Credits gehen an Jeff Garzik, "upal" und "DooMAD", der das etwas ausgearbeitet hat. Es ist eine Mischung aus BIP 100 und 106.

Grundsätzlich voten hier auch die Miner die Blocksize, aber ganz anders als bei Bitcoin Unlimited. Und zwar dürfen die Miner in jeder Difficulty-Periode (2016 Blocks), wenn 50% der Blöcke der vorigen Periode fast voll (also >90% der Kapazität) waren, dafür voten, die Blockgröße um 10% zu erhöhen. Analog dazu darf gevotet werden, die Blockgröße 10% zu verringern, wenn die 90% der Blöcke weniger als 50% des Maximums erreichen.

Um Spam-Attacken teuer zu machen (verhindern kann man sie leider nicht), wird gleichzeitig festgelegt, dass eine solche Erhöhung nur dann passieren darf, wenn die gesamten durchschnittlichen Fees der aktuellen Periode höher sind als in der letzten Periode, und eine Verringerung nur dann, wenn analog dazu die Fees niedriger sind.

Die Vorteile:
- eine Mega-Blockerhöhung, wie sie bei BU befürchtet wird, würde lange dauern und würde, falls die Miner dafür per Spam-Attacken konspirieren müssen, sie hohe Fees für die Spam-Attacken kosten.
- da das ganze langsam vor sich geht, hätten bei einer zu stark steigenden Blocksize die normalen Nodes Zeit, Gegenmaßnahmen treffen, z.B. mit der "mezzomix-Weiterleitungsblockade".
- trotzdem kann relativ schnell auf Bottlenecks reagiert werden.

(Edit: Zahlendreher)

Das ist wirklich TOP !! Gefällt mir...

Bitcore BTX - a UTXO fork of Bitcoin - since 2017
___██ WebSite
██ Telegram
___██ Github
██ Github - Releases/ Wallets
___██ SBTX Pancakeswap
██ ChainzID Explorer
___██ UTXO fork
██ Coinmarketcap.com
commander11
Sr. Member
****
Offline Offline

Activity: 545
Merit: 250


View Profile
March 11, 2017, 01:35:41 PM
 #224

http://wmstudios.com.au/index.php/blog/108-bitcoin-is-under-attack-but-only-because-it-is-a-threat-to-the-global-elites


Hier der Grund wieso Maxwex und Adam nie die Blocksize erhöhen werden das würde Ihre Eigene Firma zerstören  Wink
d5000
Legendary
*
Offline Offline

Activity: 3864
Merit: 5807


Decentralization Maximalist


View Profile
March 13, 2017, 08:03:14 PM
 #225

Zum Kompromissvorschlag mit den 10%-votes: Den diskutieren wir gerade hier. Lauda hat eine zusätzliche Obergrenze vorgeschlagen, die verhindert, das allzu große Werte gevotet werden.

Folgendes ist mein bisher konsensfähigster Vorschlag:
1) Zuerst wird SegWit implementiert und eine längere Zeit (bis 1 Jahr) bleibt dies die einzige Blocksize-Änderung, um auf mögliche Spam-Angriffe/neue Risiken reagieren zu können.
2) Nach Ablauf der Frist wird das Voting-System freigeschaltet. Miner können 10% plus oder 10% minus voten, sobald die Bedingungen (50% der Blöcke über 90% der alten maximalen Blocksize, Fees höher als bei letzter Blocksize-Änderung -> Miner dürfen für +10% voten, bei 90% der Blöcke unter 50% dürfen sie für 10% weniger voten) gegeben sind.

Dazu kommt aber eine feste 2 MB Base / 8 MB Weight Obergrenze, die 2 Jahre lang Bestand hat.

3) nach weiteren 2 Jahren wird die feste Obergrenze auf 3 MB / 12 MB erhöht.

Das ganze wird zusammen gecodet, damit auch Miner mit einer Vorliebe für große Blöcke zustimmen können. Die Core Devs könnten dafür eine Erklärung abgeben, dass sie die höheren Blockgrößen später nicht mehr heruntersetzen werden.

Super wäre es, wenn jemand, der des BTC-Programmieren mächtig ist, daraus ein echtes BIP erstellt.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
lassdas
Legendary
*
Offline Offline

Activity: 3649
Merit: 1412


View Profile
March 13, 2017, 10:18:31 PM
 #226

Was soll denn der Punkt mit den Fees höher als bei letzter Blocksize-Änderung?
Das bedeutet im Klartext, daß, um ein Wachstum des Systems zu ermöglichen, die Fees zwangsläufig immer steigen müssen.
Den Sinn dahinter versteh ich mal garnicht.
butch3r
Full Member
***
Offline Offline

Activity: 243
Merit: 108



View Profile
March 14, 2017, 07:03:17 AM
 #227

Warum sollten die miner denn für größere Blöcke voten? Ein großer Mempool erhöht doch ihre gewinne.

Und welcher Anteil der Miner muss denn für eine Blocksize-Änderung voten damit die durchgesetzt wird? Wenn dieser Wert zu hoch ist, ist es wahrscheinlich, dass überhaupt nichts passiert, so wie jetzt gerade.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 14, 2017, 07:07:29 AM
 #228

Warum sollten die miner denn für größere Blöcke voten? Ein großer Mempool erhöht doch ihre gewinne.

Auf kurze Sicht vielleicht. Aber long-term? Bitcoin ist ja nicht die einzige coin mit der man Geld verschieben kann.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
mezzomix
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 14, 2017, 07:26:16 AM
 #229

Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben. Vor allem nicht, da manche Poolbetreiber gerade zeigen wie bösartig und schädlich sie schon mit den aktuellen Rechten umgehen (SPV Mining, Nutzung der Miningleistung zur Blockade der weiteren Entwicklung, Malleated TX).
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 14, 2017, 03:57:35 PM
 #230

Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben. Vor allem nicht, da manche Poolbetreiber gerade zeigen wie bösartig und schädlich sie schon mit den aktuellen Rechten umgehen (SPV Mining, Nutzung der Miningleistung zur Blockade der weiteren Entwicklung, Malleated TX).


Ich möchte weder dich in eine Schublade stecken noch selbst in eine gesteckt werden, aber beim lesen dieses gerade erschienenen Artikels "Two Theories of Bitcoin" von Mengerian musste ich immer wieder an deine (von mir angenommene) und meine eigene Sichtweise denken. Die Sichtweisen nennt der Autor:

  • Extreme Consensus
  • Market Consensus

Der Artikel ist leider auf englisch. Ich möchte ihn hier nicht zusammenfassen. Fehlt mir die Zeit dies angemessen zu tun.

EDIT: aus dem Artikel:
 
Quote
In trying to understand one another better, perhaps we can also nudge our understanding closer to an accurate representation of reality.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
d5000
Legendary
*
Offline Offline

Activity: 3864
Merit: 5807


Decentralization Maximalist


View Profile
March 14, 2017, 07:15:19 PM
 #231

Was soll denn der Punkt mit den Fees höher als bei letzter Blocksize-Änderung?
Das bedeutet im Klartext, daß, um ein Wachstum des Systems zu ermöglichen, die Fees zwangsläufig immer steigen müssen.
Gemeint sind die Gesamt-Fees pro Block, also nicht die durchschnitllichen Fees pro Transaktion. Das bedeutet, dass auch bei mehr / größeren Transaktionen die Fees ansteigen können, ohne dass die durchschnittliche Fee pro kB ansteigen muss. Bei jeder 10%-Änderung steigt ja die Kapazität, und wenn die Blöcke voll sind, muss somit die Gesamt-Fee steigen, wenn die Durchschnitts-Fee nicht fällt.

Der Punkt stammt aus BIP 106. Ich habe mir auch schon überlegt, ob der wirklich sein muss. Das Problem ist halt, dass ohne die Bedingung eventuell Anreize für Spamattacken zugunsten einer Blocksize-Erhöhung entstehen.

Ich halte in der aktuellen Umgebung mehr/besondere Rechte für Miner - was letztendlich hauptsächlich Poolbetreiber sind - nicht für Konsensfähig. Ich persönlich bin dagegen, den Poolbetreibern mehr Rechte abzutreten als sie sowieso schon haben.

Deshalb wäre dein Patchvorschlag (dass Full Nodes Blöcke, die für "unerwünschte" Entscheidungen voten, zurückhalten können) keine schlechte Idee, um ein wirksames Korrektiv durch die anderen Full-Nodes für den Fall zu erhalten, dass sich die Miner vom Mehrheitswillen entfernen. Hast du schon mal an ein BIP gedacht (oder gibt es schon eins)?

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
Lincoln6Echo
Legendary
*
Offline Offline

Activity: 2459
Merit: 1057


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


View Profile
March 15, 2017, 06:24:49 AM
 #232

http://imgur.com/8i5xJvC

Upsi kleiner Bug bei den BU nodes.Passiert... Roll Eyes

https://mobile.twitter.com/SatoshiLite/status/841788146958270465

Quote
1/ Today’s Bitcoin Unlimited node crashing bug proves that users cannot trust Bitcoin’s $20B network in the hands of BU developers.
nrg1zer
Legendary
*
Offline Offline

Activity: 1190
Merit: 1000



View Profile
March 15, 2017, 06:40:19 AM
 #233

Wer ist Charlie Lee noch gleich? Ich kann mir Namen leider nicht so gut merken.
Lincoln6Echo
Legendary
*
Offline Offline

Activity: 2459
Merit: 1057


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


View Profile
March 15, 2017, 06:42:25 AM
 #234

Wer ist Charlie Lee noch gleich? Ich kann mir Namen leider nicht so gut merken.

Charlie Lee ist der Erfinder von Litecoin und Bruder von Bobby Lee die beide bei BTCC eine leitende Funktion haben.
mezzomix
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 15, 2017, 07:13:17 AM
 #235

Deshalb wäre dein Patchvorschlag (dass Full Nodes Blöcke, die für "unerwünschte" Entscheidungen voten, zurückhalten können) keine schlechte Idee, um ein wirksames Korrektiv durch die anderen Full-Nodes für den Fall zu erhalten, dass sich die Miner vom Mehrheitswillen entfernen.

Ja, wobei ich das als Notlösung sehe, wenn gar nichts anderes mehr geht.

Hast du schon mal an ein BIP gedacht (oder gibt es schon eins)?

Gibt keins und die Methode ist sicher nicht konsensfähig. Ausserdem sind noch mehr Optionen das allerletzte was man gerade benötigt. Es liegen genug ernsthafte Optionen auf dem Tisch (segwit, 2-8MB Hard-Fork), die die aktuellen Probleme lösen, teilweise sehr gut getestet wurden, kein grosses Risiko bringen und die Arbeitsteilung / das Systemverhalten nicht ändern.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 15, 2017, 07:16:37 AM
 #236

Hier eine zusammenfassung der Attacke auf die BU-Nodes:

These guys moved fast. It went like this:
  • BU devs found a bug in the code, and the fix was committed on Github.
  • Only about 1 hour later, Peter Todd sees that BU devs found this bug. (Peter Todd did not find this bug himself).
  • Peter Todd posts this exploit vulnerability on twitter, and all BU nodes immediately get attacked.
  • r/bitcoin moderators, in coordination, then ban all mentions of the hotfix which was available almost right away.
  • r/bitcoin then relentlessly slanders BU, using the bug found by the BU devs, as proof that they are incompetent. Only mentions of how bad BU is are allowed to remain.

Die BU-Nodes sind Teil des Bitcoin-Netzwerks und stellen momentan keine Gefahr dar, sondern unterstützen das Netzwerk so wie jede Core Node auch. Ein Angriff auf diese Nodes ist ein Angriff auf Bitcoin. Die Zensur des hotfixes finde ich genauso verwerflich wie die Attacke selbst.

Ganz unterstes Niveau mittlerweile.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 15, 2017, 07:24:38 AM
 #237

http://imgur.com/8i5xJvC

Upsi kleiner Bug bei den BU nodes.Passiert... Roll Eyes

https://mobile.twitter.com/SatoshiLite/status/841788146958270465

Quote
1/ Today’s Bitcoin Unlimited node crashing bug proves that users cannot trust Bitcoin’s $20B network in the hands of BU developers.

FUD!

Der gute Mann vergisst zu erwähnen, daß der Bug nicht einfach von selbst zugeschlagen hat. Es war eine entsprechende Attacke mit speziell angefertigten XTHIN Messages nötig. Wer die Attacke ausgeführt hat? Darüber kann jeder mal selber nachdenken.

Die BU-Software hat auf diese fehlerhaften Pakete mit Ausgabe einer Fehler-Info und stop der node reagiert. Das kann man als Bug bezeichnen (der übrigens bereits gefixt war als Peter Todd auf twitter drüber hergezogen ist: die Nodes welche solche fehlerhaften Nachrichten schicken werden jetzt als DOS-Nodes geflaggt und die angegriffene Node läuft weiter).

Diese Art von bugs hat jede software. Auch Core.

Wie macht mein ein dezentrales Netzwerk resilienter gegen Attacken die sich aus solchen Bugs ableiten lassen?

Diversität

Wenn das Netzwerk aus verschiedenen Implementationen besteht, ist immer nur ein Teil angreifbar. Bei einer Monokultur ist gleich das ganze Netz verwundbar.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
mezzomix
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 15, 2017, 07:28:31 AM
 #238

Ja, lässt sich aber wohl nicht vermeiden. Solange Lücken (egal ob im Systemdesign, Protokoll oder in der Implementierung) da sind, werden diese auch genutzt. Andere Beispiele: "Stresstest", Mempool Exhaustion, Transaction Malleability, ...

Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.

Besser als die Angriffe auf BU Knoten wäre eine Abstimmung mit den vom Bitcoin-Design vorgesehenen Mitteln: Jeder Knoten verifiziert Blöcke und Transaktionen und entscheidet eigenständig über die Aktzeptanz und die Weiterleitung. Das ist die Kernfunktion des System, daher sollte diese Funktion auch genutzt werden.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 15, 2017, 07:32:10 AM
Last edit: March 15, 2017, 07:44:28 AM by molecular
 #239

Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.

Das BU Design ist das Bitcoin Design. Jeder kann auch den core-code nehmen und das blocksize limit rauseditieren. Daß Bitcoin funktioniert basiert nicht auf der Unmöglichkeit dies zu tun.

Es geht auch nicht um eine Abstimmung. Es geht darum den Minern die Sicherheit zu signalisieren (auf rein technischer Ebene), daß Ihre blocks auf zustimmung stossen (oder auch nicht). Diese technische Ebene ist aber nicht die einzige Ebene die die Miner beachten müssen: Sie haben die Aufgabe und auch das starke Eigen-Interesse nach solchen Regeln zu minen, daß die größtmögliche Ökonomische Mehrheit die chain akzeptiert. Das findet nicht nur auf der Netzwerk-Protokoll-Ebene (blocksize limit) statt, sonder auch auf der Ebene der monetären Parameter: wenn sie beispielsweise das coin limit auf 42 millionen erhöhen, dann findet das die ökonomische Mehrheit voraussichtlich nicht gut. Wenn sie drauf beharren, dann gibt es einen Split (UASF, PoW-Change, minority fork oder was auch immer) und der Markt regelt den Rest. Ganz schnell crasht der Preis dieses "Bitcoin 42". Also werden die Miner soetwas nicht tun. Sie werden versuchen einen Chain zu bauen, die den größtmöglichen Wert hat. Ich finde darin kann man Vertrauen haben. Funktioniert bisher blendend. Das ist Bitcoin.

Besser als die Angriffe auf BU Knoten wäre eine Abstimmung mit den vom Bitcoin-Design vorgesehenen Mitteln: Jeder Knoten verifiziert Blöcke und Transaktionen und entscheidet eigenständig über die Aktzeptanz und die Weiterleitung. Das ist die Kernfunktion des System, daher sollte diese Funktion auch genutzt werden.

Ja genau, und BU vereinfacht dem Node-Betreiber die Änderung einiger der relevanten Regeln für diese "Akzeptanz und Weiterleitung". Das ist kein Fehlerhaftes Design sondern "benutzerfreundlich"


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
mezzomix
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 15, 2017, 08:24:23 AM
 #240

Deshalb ist übrigens auch das BU Design fehlerhaft, da die Annahme über eine ehrliche Abstimmung durch die Knoten nicht haltbar ist.
Das BU Design ist das Bitcoin Design. Jeder kann auch den core-code nehmen und das blocksize limit rauseditieren. Daß Bitcoin funktioniert basiert nicht auf der Unmöglichkeit dies zu tun.

Das stimmt nicht ganz, da die Knoten auch noch ihre gewünschte und maximal aktzeptierte Blockgrösse mitteilen. Diese Information ist nicht vertrauenswürdig (= kann falsch sein), dient aber als Basis zur Berechnung der maximalen Blockgrösse. BU heisst nicht, dass der Client beliebige Blockgrössen aktzeptiert!

Es gibt keine technische Möglichkeit, auf Basis einer unsicheren Information, sicher eine überall aktzeptierte maximale Blockgrösse zu errechnen!

Es geht auch nicht um eine Abstimmung. Es geht darum den Minern die Sicherheit zu signalisieren (auf rein technischer Ebene), daß Ihre blocks auf zustimmung stossen (oder auch nicht). Diese technische Ebene ist aber nicht die einzige Ebene die die Miner beachten müssen: Sie haben die Aufgabe und auch das starke Eigen-Interesse nach solchen Regeln zu minen, daß die größtmögliche Ökonomische Mehrheit die chain akzeptiert. Das findet nicht nur auf der Netzwerk-Protokoll-Ebene (blocksize limit) statt, sonder auch auf der Ebene der monetären Parameter: wenn sie beispielsweise das coin limit auf 42 millionen erhöhen, dann findet das die ökonomische Mehrheit voraussichtlich nicht gut. Wenn sie drauf beharren, dann gibt es einen Split (UASF, PoW-Change, minority fork oder was auch immer) und der Markt regelt den Rest. Ganz schnell crasht der Preis dieses "Bitcoin 42". Also werden die Miner soetwas nicht tun. Sie werden versuchen einen Chain zu bauen, die den größtmöglichen Wert hat. Ich finde darin kann man Vertrauen haben. Funktioniert bisher blendend. Das ist Bitcoin.

Nein, das ist bisher eben nicht Bitcoin (s.o.). Bisher basiert Bitcoin auf vollständiger Verifikation und nicht darauf, dass das System erst mal zerfällt (Split) und der Markt danach den Gewinner aussortiert.

Besser als die Angriffe auf BU Knoten wäre eine Abstimmung mit den vom Bitcoin-Design vorgesehenen Mitteln: Jeder Knoten verifiziert Blöcke und Transaktionen und entscheidet eigenständig über die Aktzeptanz und die Weiterleitung. Das ist die Kernfunktion des System, daher sollte diese Funktion auch genutzt werden.
Ja genau, und BU vereinfacht dem Node-Betreiber die Änderung einiger der relevanten Regeln für diese "Akzeptanz und Weiterleitung". Das ist kein Fehlerhaftes Design sondern "benutzerfreundlich"

BU erlaubt es dem Node-Betreiber eben nicht (ebensowenig wie Core), Relay und Aktzeptanz sauber zu konfigurieren. Die einzige (zusätzliche) Entscheidung, die der Node-Betreiber hat ist die maximal aktzeptierte Blocksize. Ist diese kleiner als der nächste Block, ist er raus. Im Nachgang kann dann der berühmte Markt aussortieren, ob er für immer raus ist oder ob sich eine oder mehrere Mehrheiten finden. Keine guten Voraussetzungen für ein(sic) Geldsystem.
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 ... 94 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!