Topic: true-cost-bitcoin-transactions - page 2. (Read 4220 times)

Bitcoin Classic hat Flexible Transactions seit v1.2.0 im Betastadium implementiert [1]. Auch Xthin war Teil dieses Releases. Um deine Frage zu beantworten: Aus dem gleichen Grund, aus dem die Qualität der Umsetzung nicht mit Blockstream mithalten kann: VC gesponsortes Unternehmen mit Vollzeitentwicklern vs. Freizeit-Entwickler, die nebenbei für ihr Geld arbeiten müssen.

Um die Abstimmung über die Blockgröße geht es bei BU auch nur indirekt. Es ist ein Feature, um den Fork auf eine größere Blockgröße zumindest ein wenig zu Koordinieren. Die eigentliche Abstimmung findet statt, indem es einfach ein Miner umsetzt und schaut was passiert. Als Nutzer folgt man innerhalb gewisser (konfigurierbarer) Grenzen einfach der längsten Chain, muss also keine Angst haben vom Netzwerk geforkt zu werden. Wenn jeder Bitcoin-Teilnehmer in der Lage wäre, den Client selbst entsprechend für größere Blöcke umzubauen, dann hätte es tatsächlich kein BU gebraucht. Aber da eben nicht jeder das Wissen dazu hat bzw. nicht die Zeit sich damit zu befassen, gibt es mit BU eine einfache Möglichkeit das Schicksal von Bitcoin ein wenig mehr selbst mitzubestimmen.


Was soll der Angriff durch eine Sybil-Attacke dem Angreifer bringen? Ein Miner wird nur dann einen größeren Block fabrizieren, wenn genügend andere Miner Unterstützung dafür im Blockheader ankündigen. Außer die Fork-Koordination zu stören erreicht der Angreifer also nichts. BU geht davon aus, dass ein Angriff nutzlos ist und damit die Daten durch das Node Announcement wieder eine gewisse Aussagekraft bekommen. Es ist ein Anhaltspunkt, nicht mehr und nicht weniger.


[1] https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0

Dieser Angriff hilft nur bei BU. Dort kaann über Fake-Nodes ein falsches Bild über die aktuell gewünschte / aktzeptierte Blockgrösse transportiert und so eine Fehlentscheidung der Miner produziert werden.

Bei meinem Patchvorschlag ist es egal, da das Netz nicht tatsächlich grösser wird, wenn ein Miner plötzlich 10k Nodes in Betrieb nimmt. Dann verbreiten sich seine Blöcke zwar unter diesen 10k Nodes, was aber keine praktische Relevanz hat, den es wird trotzdem keine der "echten" Nodes diese Blöcke aktzeptieren.

Sollten die BU Knoten die segwit Blöcke nicht mehr weiterleiten, dann forken sie sich in ein eigenes BU Netz. Das wurde der BU Gruppe bereits vorgeschlagen, wird aber von ihnen - aus naheliegenden Gründen - abgelehnt. Sie wollen, dass jeder ihr (fehlerhaftes da angreifbares, s.o.) System übernimmt.

Danke Mezzomix! Jetzt hab ich auch kapiert, was Franky mit der Versionsnummer meinte.

Bin ja echt mal gespannt ob jemand mal so einen Patch rausbringt. Sieht auf den ersten Blick so aus, als würde es einiges Bitcoin-spezifisches Programmierwissen benötigen. Ich hoffe ja, dass es nicht so weit kommt, aber alleine die Möglichkeit wäre eventuell genug, um ein ewiges Patt zu entschärfen.

Allerdings: Da ja bei Nicht-Minern jeder beliebig viele Nodes aufsetzen kann, könnte ich mir ein Sybil-Attack-Szenario vorstellen, bei dem beispielsweise Segwit-Fans und BU-Fans gegenseitig darum konkurrieren, wer das größere Client-Netzwerk aufbaut und die Blöcke der Gegenseite nicht mehr weiterleitet. Das wäre auch nicht optimal, allerdings meines Erachtens schon eine höhere Eskalationsstufe als heute.

Es benötigt dafür einen Patch für den Knoten.

Die Realisierung ist einfach. In jedem Block steckt nach BIP9 im entsprechenden Version-Bit die Signalisierung für den entsprechenden Soft-Fork. Für segwit ist dies das Bit 1. Jeder Block, der dieses Bit gesetzt hat, zählt as Stimme für die segwit Aktivierung. Wenn 95% der letzten 2016 Blöcke dieses Bit gesetzt haben, dann wird die neue Regel kurz darauf aktiv.

Jeder Knoten kann entscheiden, ob er einen Block ohne dieses Bit weiterleiten möchte oder nicht. Bekommt er nun einen Block der gleichen Höhe mit gesetztem Bit, verwirft er den Block ohne dieses Bit. Ein Block ohne dieses Bit wird nur dann aktzeptiert und weitergeleitet, wenn ein darauf aufbauender Block mit gesetztem Bit verfügbar ist.

Der Rest (IP Adressen, Version des Clients etc.) spielt bei diesem Mechanismus keine Rolle. Man blockiert damit auch nicht die Blöcke selbst, sondern gibt lediglich Blöcken den Vorzug, die den eigenen Vorstellungen entsprechen. Man kommuniziert diese Vorstellung auch nicht an andere Knoten. Das wäre sinnlos, da es über Komunikationsprotokoll Angriffmöglichkeiten durch Fake-Nodes gibt und daher eine saubere und ehrliche Abstimmung nicht möglich ist. Das ist übrigens auch der Wunde Punkt von BU - die Knoten können sich ohne Mining nicht an einer Abstimmung beteiligen, da das Ergebnis beliebig manipulierbar ist. BU geht von ehrlichen Knoten im Netz aus, die ihre Vorstellungen korrekt kommunizieren. Eine kuriose Annahme, wenn man die aktuelle Lage betrachtet.

Würde mich auch mal interssieren wie man das realisieren kann ... finde ich durchlaus legitim wenn die Nodes dadurch etwas Stimmgewicht bekommen.

Genau das meinte ich. Finde ich auch eine legitime Möglichkeit, Einfluss auf (Softfork-)Entscheidungen zu nehmen, da somit den Minern etwas Macht genommen wird.

Die Frage ist: Wie geht das genau? Muss der Code des Bitcoin-Clients dafür geändert werden oder geht das z.B. über eine Blacklist mit dem aktuellen Client?

Hab mir natürlich gleich Franky1 aufgehalst, aber immerhin hat er was brauchbares beigetragen, indem wohl die Versionsnummer des Clients Ausgangspunkt für eine solche "Weiterleitungsblockade" sein kann. Nur: Bitcoin 0.13.x kann man ja so konfigurieren, dass "Not Ready" für Segwit (oder einen beliebigen anderen Softfork) signalisiert wird. Sieht man dieses "Not Ready" direkt, wenn ein neuer Block an meinen Client weitergeleitet wird, oder muss ich separat das "Not Ready" eines Mining Pools erschnüffeln und auf dieser Basis dann die IP-Adresse blockieren? Hab das nicht ganz verstanden. Vielleicht gibts ja in der Protokolldokumentation was interessantes dazu ...

Ich hatte dazu schon mal was in anderen Threads geschrieben. Sollte die Überwiegende Zahl der Knotenbetreiber für segwit stimmen, ein paar der Miner dies aber trotzdem blockieren, dann könnten die Knoten neue Blöcke ohne segwit Signalisierung nicht mehr weiterleiten und diese - sobald verfügbar - durch Blöcke der gleichen Höhe mit segwit Signalisierung ersetzen.

Damit würden diese Knoten den Minern die segwit signalisieren einen ökonomischen Vorteil verschaffen, da sich die Blöcke ohne segwit langsamer im Netz verbreiten und statistisch gesehen teilweise durch segwit Blöcke verdrängt werden, bevor diese durch den folgenden Block letztendlich bestätigt werden.

Je mehr Knoten hier mitmachen, desto kleiner wird die Chance eines solchen Miners, seine Blöcke gegen den Rest der Knoten durchzubekommen. Eigene Knoten helfen nicht dagegen, da der Miner die Blöcke dann trotzdem nur in seinem eigenen Netz verbreiten kann. Ignoriert er das Votum der Knoten und besteht auf seinen eigenen Block, dann forkt er sich mit dem nächsten darauf aufbauenden Block automatisch aus dem Netzwerk.

Ich habe mal hier die Frage gestellt, ob Nutzer mit Full Node Druck auf die Miner ausüben können, um bestimmte Ziele (z.B. Segwit) zu erreichen, indem sie die Blocks bestimmter Pools blockieren. Mezzomix, du hast das ja mal angesprochen. Mal sehen ob/was mir geantwortet wird.

Warum wurden dann nicht Detached Signatures, Flexible Transactions, UTXO Commitments und die ganzen anderen tollen Features implementiert, wenn es nicht um das Blockieren geht?!

Im übrigen könnte man die Abstimmung über die Blockgrösse ebenfalls Off-Chain durchführen. Forken kann man sowieso immer, wenn man bereit ist, die Konsequenzen zu tragen. Dafür hätte es also kein BU gebraucht. So sehe ich die technische Notwendig von BU nicht. Machtansprüche, Politik und Blockade sind allerdings deutlich sichtbar.

Ich denke nicht, dass es bei BU darum geht Segwit zu blockieren und damit in Folge Second Layer Lösungen zu erschweren. Primär ist das Hauptziel von BU die Blockgröße vom Markt entscheiden zu lassen bzw. im Allgemeinen dem Nutzer möglichst viel Freiheit zu lassen.

Dass BU Segwit nicht unterstützt liegt nur daran, dass die BU Entwickler (und ich selbst übrigens auch) Segwit vom Konzept her für eine schlechte Lösung halten. Ich denke, auch dabei geht es um Freiheit: Segwit ist ein komplexes Konzept, das aber trotz seiner Komplexität kaum bis gar keine Erweiterungen für die Zukunft ermöglicht.

Im Gegensatz dazu ist Flexible Transactions [1] mit einem Hardfork eine saubere und zukunftsfähige Lösung. Ich könnte mir vorstellen, dass durch den Tag-Ansatz die Vielfalt der Second Layer und Subchain Systeme wesentlich größer ist, als bei Segwit. Dass Segwit vielleicht besser umgesetzt/getestet wurde, ist nur logisch, weil bei Blockstream entsprechendes Kapital vorhanden ist. Das Konzept an sich wird dadurch aber nicht besser.


[1] https://bitcoinclassic.com/devel/Flexible%20Transactions.html

Da stimme ich durchaus zu. Ich hätte ebenfalls gerne ein moderates Wachstum der maximalen Blockgrösse und gleichzeitig die Entwicklung von möglichst vielen Second Layer Lösungen.

Für Second Layer ist die Transaction Malleabilty ein Problem, da es damit schwieriger wird, eine definierte Transaktion im Script zu referenzieren. Damit sind alle Arten von Second Layer Transaktionen (Off-Chain, Sub-Chain, Side-Chain) mindestens schwerer zu implementieren, fehleranfällig oder gar nicht umsetzbar. Da BIP9 die Hürde mit 95% hoch setzt (was ich übrigens begrüsse!), kann man mit BU die Umsetzung mittels segwit relativ leicht boykottieren. Wie man hier sieht reicht die Drohung weniger Miner aus, damit sich genügend Nutzer kleinmachen lassen und glauben, sie hätten überhaupt nichts zu melden.

Genau wegen diesen Zahlen (danke flipperfish für die Berechnungen) halte ich es auch für ziemlich wahrscheinlich, dass wir mehrere Chains brauchen. Das könnten entweder Alt-Chains mit unabhängigem Wertmechanismus oder Sidechains mit Peg an den Bitcoin-Wert sein - meines Erachtens wird es immer beides geben. (Falls jemand die Antwort auf meine Frage weiter oben hat ... )

Wobei ich 10 Einkäufe pro Stunde für ubertrieben halte. Ich komme - als Privatperson - mit durchschnittlich ca. 2 pro Tag ganz gut zurecht Und für Micro-TX, z.B. Filme im Internet gucken oder Musik hören, gibt es ja schon heute längst attraktive Abomodelle und ansonsten eben Off-Chain-Techniken.

Ich finde es müssen beide Wege verfolgt werden: Second Layer und On-Chain. Wie ich oben gezeigt hatte, ist selbst bei 400 MB Blockgröße für das Second Layer System gerade mal eine Settlement Transaktion pro Woche drin (bei 1-2 Mrd Teilnehmern). Eine Settlement Transaktion alle 7 Jahre (= 400 Wochen = 1 MB Blockgröße) ist definitiv zu wenig. Da können wir auch beim Bankensystem bleiben...

@mezzomix:
Findest du BU blockiert die Entwicklung von Second Layer Systemen? Inwiefern?

Du darfst allerdings bei der Machbarkeit nicht nur den lokalen Rechner und den Downstream im Idealfall betrachten. Bei einem verteilten System hast Du 1:N Verbindungen und das Ganze soll auch nicht nur bei Schönwetter funktionieren.

Für die explodierende Blockchaingrösse gibt es auch Lösungen (UTXO Commitments, UTXO Snapshots). Diese werden aber auch nicht morgen da sein. Das Internet wird allerdings auch zuünftig ein limitierender Faktor sein. Dort ist das Wachstum lange nicht so gross, wie im lokalen Netz. (Mindestens) Second Layer ist der erfolgversprechende Weg, den aber ein paar Möchtegern-Führer gerade blockieren wollen. Die Macht dazu haben sie allerdings nicht, ausser die restlichen Nutzer lassen sich einreden sie seien zu klein und hätten sowieso nichts zu melden. In diesem Fall werden sie am Ende selber Schuld an der folgenden Entwicklung sein. Man kann die Hunde nicht zum jagen tragen.

Das klingt jetzt schon ein wenig wie "640k ought to be enough for anybody."

Ich glaube schon, dass ein verteiltes System solche Transaktionsmengen verarbeiten könnte:
10 Mio tx/h =~ 2778 tx/s. Bei 1 MB Blöcken schaffen wir 7 tx/s, bei ~400 MB Blöcken schaffen wir die 2778 tx/s.

Kurzer Machbarkeits-Check:
CPU? Schafft 4k tx/s -- CHECK.
Netz? Braucht ~6 Mbit/s, ist halbwegs machbar, selbst im bei Internetanschlussgeschwindigkeiten doch eher zurück liegenden DE -- CHECK.
Platte? ~20 TB / Jahr, zugegeben das ist bei 32€ / TB mit 640€ / Jahr schon ein teurer Spaß. Andererseits aber für den deutschen Mittelstand noch finanzierbar. Außerdem könnte man noch das Pruning aktivieren, was den Speicherplatz vermutlich irrelevant macht. Deswegen aus meiner Sicht auch hier -- CHECK.

Das soll natürlich nicht heißen, dass wir keine Second Layer Systeme benötigen, denn 1 Mio Menschen sind jetzt nicht gerade viel. Aber verschieben wir doch mal die Faktoren: 1 Einkauf in der Stunde --> 10 Mio Menschen. 1 Settlement Transaktion pro Tag --> 240 Mio Menschen. 1 Settlement Transaktionen pro Woche --> 1680 Mio Menschen. Reicht gerade mal für den nordamerikanischen Kontinent und Europa. Bei 2778 tx/s wohlgemerkt.

Nein, man hätte die Frage nicht mit kostet X beantworten können, ausser man hat eine sehr sehr gute Kristallkugel. Ich habe die nicht und sonst hat die auch niemand. Daher ist es am besten die einzelnen Aspekte anzusprechen und dann muss sich jeder sein eigenes Bild machenb - oder auch nicht.

Praktisch wirst Du Dir auch denken können, dass niemand für eine 0,001 BTC Transaktion eine Fee von 0,0005 BTC bezahlt. Nebenbei dürfte auch klar sein, dass 10 Einkäufe in der Stunde bei 1 Million Menschen von keinem verteilten dezentralen Netz getragen werden können. Die einzelnen Problemfelder sind also bekannt, die Lösungen liegen auf dem Tisch. Leute die die Realität nicht sehen wollen, ändern nichts daran.

Naja Haspower ist halt ein Sicherheitsaspekt.

Aktuelle Rechenleistung  3,155,481,777 GH/s Geteilt durch S9's 13TH (13000GH) = 242729

Also etwas über 300M € gerundet, brauchen tut man nur die hälfte siehe 51% ,...
klar kriegt so keiner an den Start würde Bitmain wohl auffallen usw. etc.

Trotzdem wenn man bei Bitcoin ernsthaft über Erfolg langristige Ziele nachdenken will sollte man sich da mal die Zahlen klar machen. Jeder wird da wohl wieder seine eigene Meinung haben was genug oder nicht genug ist.

Das war eigentlich auch die Intension meiner ersten Frage, die man mit ja / nein / ja kostet x / nein kostet y ; hätte beantworten können.

Das was du tust bringt die Diskussion nicht wirklich weiter in meinen Augen weil das was du schreibst so vaage gehalten ist, das man da nicht für / gegen argumentieren kann, weil es allgemeingültig ist. Ein Gleichgewicht wird sich immer einstellen!! Die Interessantere Frage wäre da schon in welchem Zeitrahmen und noch interessanter ist dann was bedeutet das für den Bitcoin.

PS.: Gehen wir mal davon aus das der ETF kommt und noch andere; das man den shorten kann wie alles andere, da kann man mit Sicherheit davon ausgehen das 3 EXH zuwenig sind.  Aber das lenkt vom Thema ab ..  

PPS.: Mir ist klar wie das Diff resizing funktioniert alle 2016 Blöcke und auch das die sinken kann, ich habe den BTC nicht erst gestern entdeckt sondern bin auch schon seit 2012 hier angemeldet ich hatte gezielt eine Frage gestellt und wollte Meinungen dazuhören nicht Infos wie das System funktioniert.  

Natürlich können Transaktionen zu teuer werden. Dann wird die Nachfrage zwangsläufig sinken, bis sich ein Gleichgewicht eingestellt hat. Dieser Effekt trifft jedes globale verteilte System. Bitcoin ist hier eben mal wieder der Vorreiter. Daher gibt/gab es auch bei Bitcoin die ersten ernsthaften Ansätze zur Lösung dieser Probleme.

Die Miner werden mit der aktuellen (oder sogar einer steigenden) Hashleistung dafür übrigens nicht benötigt. Das System kann in diesem Aspekt dynamisch in beide Richtungen adaptieren.

Und da sind wir wieder bei meiner Eingangs gestellten Frage.
Ist das möglich bei aktueller Blockgröße und aktuell angenommer Hashrate oder ist dann eine Transaktion kleiner 1000€ zu teuer, weil keiner Bock hat 5€ für ne Überweisung zu zahlen und alle 3te Welt Länder schon mal ausscheiden, wenn die Leute da keine 5€ am Tag verdienen (nur Beispielhaft)




Naja zur Zeit scheinen die sich größtenteils ja einig zu sein was sie da denken, aber unter ein paar Leuten kann man sich ja auch noch gut austauschen, zumal es mir schon so vorkommt als würde da eine gewisse Gruppenbildung bestehen.


Dem Stimme ich voll und ganz zu 

Da der Miner davon lebt, dass alle seinen Block aktzeptieren, sitzt der einzelne Miner eben nicht am längeren Hebel.

Unabhängig davon braucht Dich keiner zu fragen. Es ist und bleibt mit den heutigen und auch mit segwit Transaktionen Deine Entscheidung, ob und wie Du Off-Chin, Sub-Chain und Side-Chain Transaktionen nutzen möchtest. Du musst nach einem segwit Soft-Fork nicht mal segwit Transaktionen nutzen, falls Du das aus ideologischen Gründen nicht möchtest. Allerdings musst Du nach deinem segwit Soft-Fork aktzeptieren, dass andere segwit Transaktionen machen möchten.