Bitcoin Forum
November 22, 2017, 02:29:08 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 63 64 65 66 67 68 69 70 71 [72] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
  Print  
Author Topic: Re: Der Aktuelle Kursverlauf blockgrösse  (Read 175001 times)
Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
July 17, 2017, 08:08:30 AM
 #1421

Man müsste den offiziellen Release von Segwit2x "Bitcoin One million" nennen, da es voraussichtlich bis zu einer Million Transaktionen pro Tag ermöglicht. In Wirklichkeit wohl etwas darunter, aber bischen Marketing-Speech könnte dem Ganzen gut tun, zumal rein technisch 1 Mio Transationen möglich sind.
Den Big-Blockern würde das signalisieren, dass die Kapazität für lange Zeit ausreichend sein wird, um niedrige Gebühren zu gewährleisten, und den Small-Blockern nimmt es vielleicht die Angst, dass danach immer weitere Blocksize Erhöhungen folgen werden.  Weil man ja dann bei einer runden Zahl an Transaktionen ist, und der nächste Schritt (1 Milliarde) ohnehin nur mit gänzlich neuer Technologie zu erreichen ist.
1511317748
Hero Member
*
Offline Offline

Posts: 1511317748

View Profile Personal Message (Offline)

Ignore
1511317748
Reply with quote  #2

1511317748
Report to moderator
1511317748
Hero Member
*
Offline Offline

Posts: 1511317748

View Profile Personal Message (Offline)

Ignore
1511317748
Reply with quote  #2

1511317748
Report to moderator
1511317748
Hero Member
*
Offline Offline

Posts: 1511317748

View Profile Personal Message (Offline)

Ignore
1511317748
Reply with quote  #2

1511317748
Report to moderator
There are several different types of Bitcoin clients. Hybrid server-assisted clients like Electrum get a lot of their network information from centralized servers, but they also check the server's results using blockchain header data. This is perhaps somewhat more secure than either server-assisted clients or header-only clients.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511317748
Hero Member
*
Offline Offline

Posts: 1511317748

View Profile Personal Message (Offline)

Ignore
1511317748
Reply with quote  #2

1511317748
Report to moderator
1511317748
Hero Member
*
Offline Offline

Posts: 1511317748

View Profile Personal Message (Offline)

Ignore
1511317748
Reply with quote  #2

1511317748
Report to moderator
flipperfish
Sr. Member
****
Offline Offline

Activity: 336


Dolphie Selfie


View Profile
July 17, 2017, 04:54:20 PM
 #1422

Thema Zentralisierung:

  • ...freier Blockgröße: Die Blockgröße wird soweit ansteigen, bis die Nachfrage nach Transaktionskapazität befriedigt ist. Ist dafür dann ein 20k Node notwendig, können nur noch Teilnehmer mit entsprechendem Geschäftsumsatz einen solchen Node betreiben. Dieser Geschäftsumsatz kann auf vielfältige Weise erreicht werden. Die direkte Variante ist, Node-Services gegen Gebühr anzubieten. Unter den Node-Service-Providern wird es zu Konkurrenz kommen. Der Markt entscheidet unter Berücksichtigung der Gesamtlage (d.h. Hardware-Preise, geopolitische Lage, Nutzerzahlen, ...), wieviel Ressourcen auf den Betrieb des Bitcoin-Netzwerks verwendet werden. Praktisch ideale Dezentralisierung.


Das ist doch komplett Science fiction aus heutiger Perspektive. Wenn es einen Mechanismus im Bitcoin-Protokoll gäbe, der Nicht-Mining-Nodes entlohnt, gäbe es viel weniger Widerstand gegen eine Blocksize-Erhöhung.

Wozu brauchst du den Mechanismus auf Protokoll-Ebene? Deinen Internetprovider kannst du ja auch für seine Dienstleistung bezahlen, ohne dass ein Bezahlmechanismus in die gängigen Internet Protokolle eingebaut wäre. Aber wieder ein schönes Beispiel für meine Aussage von oben: "nicht nur die technische Seite betrachten, auch die wirtschaftliche".

Quote
  • ...freier Blockgröße: [siehe oben].
Schön, dass du das auch aufschreibst - Lustiger Weise denke ich, dass Bitcoin wahrscheinlich vor dieser Situation durch die Konkurrenz mit den Altcoins gerettet werden wird.
Sollte Bitcoin allerdings die absolut dominierende Währung auf der Welt sein, wäre das allerdings durchaus möglich, dann haben wir praktisch wieder Banken, außer dass diese eben nicht SEPA und SWIFT, sondern Bitcoin nutzen. Ein bisschen spannend wird es aber schon, wer in Zukunft noch Lust hat Full Nodes laufen zu lassen und andere diese kostenlos nutzen zu lassen, vor allem wenn die Anzahl der Full Nodes sinkt und gleichzeitig die Anzahl der Nutzer weiter ansteigt.

Wieso sollte ein Node-Provider eher einer Bank ähneln, als ein Off-Chain Hub?

Du musst bedenken, dass man die Daten von mehreren Node-Providern vergleichen kann und ziemlich schnell auffliegt, wenn einer schummelt. Wenn erstmal bekannt ist, dass ein Node-Provider schummelt, ist auch ziemlich schnell sein Geschäftsmodell kaputt. Bei einem Off-Chain Hub habe ich nicht die Möglichkeit, dessen Ehrlichkeit durch die Konkurrenz zu verifizieren.

Über die Anzahl der Full Archival Nodes mache ich mir auch keine Sorgen, da gibt es genug Teilnehmer, die ein Interesse daran haben einen solchen zu betreiben: Exchanges, Payment Provider, Bitcoin Whales, Miner, Node-Service-Provider, Blockchain Investigation Services, große Firmen mit genug Umsatz und dem entsprechenden Sicherheitsbedürfnis,  ...

Und auch die "alles kostenlos" Kultur wird nicht zu kurz kommen: Jedes Geschäft, das Bitcoin akzeptieren möchte, wird dem Kunden auch entsprechende Node-Services zur Verfügung stellen. In der Kneipe um die Ecke gibt es ja auch eine kostenlos nutzbare Toilette, obwohl der Wirt daran nichts verdient. Für den Privat-Nutzer wird es entsprechende Web-Services und Smartphone Apps geben, die sich durch Werbung und den Verkauf von Datenbeständen, mit denen man Transaktionen einer Identität zuordnen kann, finanzieren. Genau so, wie es im restlichen Internet eben auch läuft.
hv_
Hero Member
*****
Offline Offline

Activity: 644


View Profile
July 17, 2017, 05:27:52 PM
 #1423

Thema Zentralisierung:

  • ...freier Blockgröße: Die Blockgröße wird soweit ansteigen, bis die Nachfrage nach Transaktionskapazität befriedigt ist. Ist dafür dann ein 20k Node notwendig, können nur noch Teilnehmer mit entsprechendem Geschäftsumsatz einen solchen Node betreiben. Dieser Geschäftsumsatz kann auf vielfältige Weise erreicht werden. Die direkte Variante ist, Node-Services gegen Gebühr anzubieten. Unter den Node-Service-Providern wird es zu Konkurrenz kommen. Der Markt entscheidet unter Berücksichtigung der Gesamtlage (d.h. Hardware-Preise, geopolitische Lage, Nutzerzahlen, ...), wieviel Ressourcen auf den Betrieb des Bitcoin-Netzwerks verwendet werden. Praktisch ideale Dezentralisierung.


Das ist doch komplett Science fiction aus heutiger Perspektive. Wenn es einen Mechanismus im Bitcoin-Protokoll gäbe, der Nicht-Mining-Nodes entlohnt, gäbe es viel weniger Widerstand gegen eine Blocksize-Erhöhung.

Wozu brauchst du den Mechanismus auf Protokoll-Ebene? Deinen Internetprovider kannst du ja auch für seine Dienstleistung bezahlen, ohne dass ein Bezahlmechanismus in die gängigen Internet Protokolle eingebaut wäre. Aber wieder ein schönes Beispiel für meine Aussage von oben: "nicht nur die technische Seite betrachten, auch die wirtschaftliche".

Quote
  • ...freier Blockgröße: [siehe oben].
Schön, dass du das auch aufschreibst - Lustiger Weise denke ich, dass Bitcoin wahrscheinlich vor dieser Situation durch die Konkurrenz mit den Altcoins gerettet werden wird.
Sollte Bitcoin allerdings die absolut dominierende Währung auf der Welt sein, wäre das allerdings durchaus möglich, dann haben wir praktisch wieder Banken, außer dass diese eben nicht SEPA und SWIFT, sondern Bitcoin nutzen. Ein bisschen spannend wird es aber schon, wer in Zukunft noch Lust hat Full Nodes laufen zu lassen und andere diese kostenlos nutzen zu lassen, vor allem wenn die Anzahl der Full Nodes sinkt und gleichzeitig die Anzahl der Nutzer weiter ansteigt.

Wieso sollte ein Node-Provider eher einer Bank ähneln, als ein Off-Chain Hub?

Du musst bedenken, dass man die Daten von mehreren Node-Providern vergleichen kann und ziemlich schnell auffliegt, wenn einer schummelt. Wenn erstmal bekannt ist, dass ein Node-Provider schummelt, ist auch ziemlich schnell sein Geschäftsmodell kaputt. Bei einem Off-Chain Hub habe ich nicht die Möglichkeit, dessen Ehrlichkeit durch die Konkurrenz zu verifizieren.

Über die Anzahl der Full Archival Nodes mache ich mir auch keine Sorgen, da gibt es genug Teilnehmer, die ein Interesse daran haben einen solchen zu betreiben: Exchanges, Payment Provider, Bitcoin Whales, Miner, Node-Service-Provider, Blockchain Investigation Services, große Firmen mit genug Umsatz und dem entsprechenden Sicherheitsbedürfnis,  ...

Und auch die "alles kostenlos" Kultur wird nicht zu kurz kommen: Jedes Geschäft, das Bitcoin akzeptieren möchte, wird dem Kunden auch entsprechende Node-Services zur Verfügung stellen. In der Kneipe um die Ecke gibt es ja auch eine kostenlos nutzbare Toilette, obwohl der Wirt daran nichts verdient. Für den Privat-Nutzer wird es entsprechende Web-Services und Smartphone Apps geben, die sich durch Werbung und den Verkauf von Datenbeständen, mit denen man Transaktionen einer Identität zuordnen kann, finanzieren. Genau so, wie es im restlichen Internet eben auch läuft.

Alles richtig, der schlaue Flipper. Wo denn bloss die alle hingeganen sind, nachdem die Erde einer Hyperraumstrasse weichen musste...?

Carpe diem  -  cut the down side  -  be anti-fragile
A feature that needs more than one convincing argument is no and Satoshi owes me no proof.
My coding style is legendary but limited to 1MB, sorry but cannot come much over my C64, Bill Gates and Tom Bombadil
Bergmann_privat
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 17, 2017, 07:01:06 PM
 #1424


Wieso sollte ein Node-Provider eher einer Bank ähneln, als ein Off-Chain Hub?

Du musst bedenken, dass man die Daten von mehreren Node-Providern vergleichen kann und ziemlich schnell auffliegt, wenn einer schummelt. Wenn erstmal bekannt ist, dass ein Node-Provider schummelt, ist auch ziemlich schnell sein Geschäftsmodell kaputt. Bei einem Off-Chain Hub habe ich nicht die Möglichkeit, dessen Ehrlichkeit durch die Konkurrenz zu verifizieren.

Über die Anzahl der Full Archival Nodes mache ich mir auch keine Sorgen, da gibt es genug Teilnehmer, die ein Interesse daran haben einen solchen zu betreiben: Exchanges, Payment Provider, Bitcoin Whales, Miner, Node-Service-Provider, Blockchain Investigation Services, große Firmen mit genug Umsatz und dem entsprechenden Sicherheitsbedürfnis,  ...

Und auch die "alles kostenlos" Kultur wird nicht zu kurz kommen: Jedes Geschäft, das Bitcoin akzeptieren möchte, wird dem Kunden auch entsprechende Node-Services zur Verfügung stellen. In der Kneipe um die Ecke gibt es ja auch eine kostenlos nutzbare Toilette, obwohl der Wirt daran nichts verdient. Für den Privat-Nutzer wird es entsprechende Web-Services und Smartphone Apps geben, die sich durch Werbung und den Verkauf von Datenbeständen, mit denen man Transaktionen einer Identität zuordnen kann, finanzieren. Genau so, wie es im restlichen Internet eben auch läuft.

Das bringt wunderbar zum Ausdruck, was viele Leute derzeit so ärgert: Einfach mal ein bißchen den Kopf hochhalten, vorwärts schauen, darauf vertrauen, dass der Markt und die vielen klugen Leute, die involviert sind, Lösungen finden. Es gibt echt so viele Wege, die man erkunden kann. Aber stattdessen sollen wir den Kopf hängen lassen und nur ängstlich murmeln: "Ohmeingott, Bitcoin wird benutzt, das müssen wir so klein wie möglich halten, oh mein gott, auf keinen Fall wachsen, weil dann kommt die furchtbar schlimme Dezentralisierung."

Ist jetzt übertrieben ausgedrückt, natürlich, aber etwas das ist eine Grundstimmung, die seit einigen Jahren immer dominanter wird. Ist schon fast Häresie geworden, zu sagen, dass Bitcoin so, wie es ist, gut funktioniert, dass SPV funktioniert, etc.

Aber, was anderes, oder, was verwandtes: Viele der Early-Early-Adopter sind abgesprungen, als sich die Party ab 2011 gefüllt hat. War dann nicht mehr so real. Ab 2013 hatten diese Early Adopter die Schnauze voll von dem Zirkus. Kann es sein, dass derzeit etwas ähnliches mit der zweiten Welle von Early Adopter passiert, aber die eben versuchen, "ihren Bitcoin" mit Zähnen und Klauen zu verteidigen?
d5000
Legendary
*
Offline Offline

Activity: 1554



View Profile
July 18, 2017, 12:35:53 AM
 #1425

@Rakete4: Gute Idee. Würde ich unterstützen ...

Nein, es ist nicht das gleiche. Es hat schon seine FUD-Gründe wieso MoinCoin als Vergleich die Usenet-Server als Vergleich heranzieht und nicht etwa DNS-Server.

OK, das sind aber eher technische Unterschiede, oder? Aus Sicht des technisch unbedarften Users sieht es imho bei beiden Modellen so aus:
- ich verbinde mich mit einem Dienstleister, der mir das Handling der Blockchain abnimmt und dafür Gebühren nimmt
- der Dienstleister könnte mich theoretisch angreifen, aber ich kann den Angriff durch Beobachten des Netzwerks (z.B. durch Nutzung eines anderen Block Explorer _oder_ durch Kontrolle des Payment-Channels bei LN) abwehren. Bei LN über Settling, beim Light Node durch Warten auf Bestätigungen. Die Angriffe sind zwar technisch tatsächlich vollkommen unterschiedlich, aber letztendlich geht es bei beiden darum, dass ich eine Zahlung akzeptieren könnte, die dann ungültig wird (bei LN: weil der Node den Status des Channels zurücksetzt, beim Light Node: wenn ich auf einer ungültigen Chain lande).

Quote
Nur die Frage ist wieso  irgendwer nun unbedingt eine eigene Node betreiben 'muss'. Ist das ein abseitiger sexueller Fetisch?
Wieder aus Nicht-Techniker-Sicht: Mehr Redundanz bedeutet mehr Sicherheit. Ich kenne die Einwände (Fibre u.a.) aber mehr Fullnodes sollte immer besser sein. Und: nur mit einem Fullnode kann ich mich gegen bestimmte Angriffe wehren.

Quote
Definiere Full Node. Wenn Full Node mit 'ach und krach' die Blockchain  auf der Festplatte aktuell halten meint gehts sicherlich. Wenn Full Node meint auch noch permanent eine angemessenen Anzahl von Light-Nodes zu bedienen eher nicht.

"Jeder" braucht nur ersteres können. Das wäre nur ein Problem wenn sich zweiteres nicht verhindern ließe (d.h. dass sich ein Light Node an deinen Full Node "anhängt"). Die Antwort kenne ich leider nicht.

Quote
Eine bestimmt Anzahl von (On-chain) Konten  benötigt einen   dementsprechenden  Speicherplatz, und wenn Du  eine durchschnittliche Transaktionsrate  pro User annimmst kannst Du die daraus  resultiernde  Blockgröße ermitteln.

Die Rechnung habe ich mal ganz rudimentär gemacht: eine 20MB-Blöcke-Chain (1 TB/Jahr) könnte ca. 160 Mio. User bedienen, wenn diese nur eine Transaktion pro Monat ausführen (z.B. nur den LN-Channel wieder aufladen).

Kritischer scheint aber das UTXO Set zu sein, das entsprechend RAM frisst - bei 8 MB-Blöcken laut der bekannten Bitfury-Studie 32 GB, wenn keine Zwischenspeicherung auf der Festplatte erfolgt.

Quote
Eine Lösung  wäre die Datenhaltung per DHT zu lösen, allerdings müsste  dies jemand  implementieren. Die Investoren der 2nd Layer Dienstleister werden daran ganz sicher kein Interese haben, aus der Richtung wird also nichts kommen.

Hab mal irgendwo aufgeschnappt das wäre angreifbar. Kenne die Details aber nicht.

       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
,CoinPayments,
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
hv_
Hero Member
*****
Offline Offline

Activity: 644


View Profile
July 18, 2017, 11:12:22 AM
 #1426

^  Interessant wäre dabei immer, WANN denn diese 20MB Blöcke erreicht werden - und was wir dann für eine Technik am Start haben.

Auch 32GB UXTO set - mal ne andere DB versuchen ?


Egal, erstmal zuschauen, wie das SW2x gerade noch reinkommt. Das ist eigentlich gut, wenn sich die Minerseite mal 'einig' ist, oder?

(Mhh , wollten wir nicht dezentrtale Miner ...?)

Das übt nun wieder Druck auf die Nodes aus, das NYA auch so umzusetzen, dass für mich aber auch an das Hongkong (?) agreement erinnert SW + später 2MB / November ist dann = später...

Das sieht alles nach Last-Minute-Kompromiss aus und Bös-Fork-Verhinderung.


Carpe diem  -  cut the down side  -  be anti-fragile
A feature that needs more than one convincing argument is no and Satoshi owes me no proof.
My coding style is legendary but limited to 1MB, sorry but cannot come much over my C64, Bill Gates and Tom Bombadil
Bergmann_privat
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 18, 2017, 11:22:43 AM
 #1427

Nur Miner müssen UTXO im Ram halten. Nodes können es auch auf der HD speichern.
MoinCoin
Sr. Member
****
Offline Offline

Activity: 446


Extension Blocks <3 Rootstock <3


View Profile
July 18, 2017, 11:59:40 AM
 #1428

Nur Miner müssen UTXO im Ram halten. Nodes können es auch auf der HD speichern.
Streng genommen müssen nicht mal Miner das ganze im RAM halten, das ist nur eine krasse Vereinfachung.
Macht man aktuell einfach aus praktsichen Gründen -> Das UTXO Set ist klein und RAM ist günstig genug, so dass es bisher nicht optimiert werden musste.
Und Miner heißt in dem Fall Mining-Pools - Hasher müssen überhaupt nichts davon im RAM halten.

Die Transaktionen, welche über das P2P Netzwerk reinkommen werden ja schon zu dem Zeitpunkt des Empfangs validiert und damit kann der UTXO Eintrag in den Cache (RAM) geladen werden.
Für das gesamte UTXO-Set reicht ein schnell zugreifbarer Datenspeicher, das muss nicht unbedingt RAM sein, da reicht auch eine SSD.

Für den Miner gibt es je nach Sichtweise 1-2 Gründe möglichst viel vom UTXO-Set im Speicher zu halten:
Grundsätzlich geht es immer um Profitmaximierung, also immer den Block-Kandidaten zu berechnen, der den maximalen Profit verspricht.
Das heißt zum einen die Transaktionen, welche hohe Gebühren zahlen, möglichst schnell in den aktuellen Block-Kandidaten zu nehmen.

Und es heißt natürlich auch, dass man Blöcke von anderen Minern möglichst schnell validieren will.
Nur, wenn ein anderer Miner also einen Block sendet, der Transaktionen enthält, die aktuell nicht im Mempool sind, muss in dem Fall überhaupt zusätzlich auf das UTXO-Set zugegriffen werden, um feststellen zu können, ob der Block valide ist.

Der einzige Grund für einen Miner auf das UTXO zuzugreifen ist also immer, wenn man eine neue Transaktion erhält und überprüfen muss ob die Transaktion gültig ist. Dazu muss man natürlich schauen, ob der entsprechende UTXO Eintrag existiert. Wenn man das UTXO-Set im RAM hat, kann der Miner also im Mikro-/Millisekunden-Bereich schneller reagieren, was die Spy-Mining- oder SPV-Mining-Zeit (Mining von leeren Blöcken) um Millisekunden verkürzt und ebenso es erlaubt neue Transaktionen Mikro-/Millisekunden schneller in den Block-Kandidaten zu übernehmen.

Effekte:
Kürzere Zeit, in der leere Blöcke gemined werden -> Geringere Zeit in der der Miner durch invalide Blöcke angreifbar ist -> Also theoretisch auch niedrigere Orphan-Rate
Miner kann Blöcke mit höheren Gebühren produzieren

Solange eine normale Full-Node also problemlos die Transaktionen verifizieren kann, während das UTXO-Set bei der Full-Node auf einer HDD liegt, ist der Vorteil bei den momentanen Verhältnissen praktisch ausschließlich ökonomischer Natur und auch da nur sehr minimal gegenüber schnellen Speichern, wie einer SSD.


Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
Bergmann_privat
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 18, 2017, 12:29:49 PM
 #1429

Schon gehört?

Am 1. August gibt es die Big Block Bitcoin Cash Fork
https://bitcoinblog.de/2017/07/18/fork-in-sicht-bitcoin-cash-wird-am-1-august-zu-groesseren-bloecken-forken/

Bin ja sehr gespannt, ob da was draus wird.

@MoinCoin: Damit ist das UTXO set bis auf weiteres nicht im geringsten ein Problem. Wenn es mal über 10 Gigabyte geht, könnte man darüber nachdenken, ob man es hier lässt, damit auch Smartphones das ganze UTXO problemlos speichern können. Aber da es noch keine dieser Art von Light-Wallet gibt, die auf Basis des UTXO arbeiten, ist die Frage eher theoretisch. Für die bisherigen Nodes und Miner scheint es keine Rolle zu spielen.

Findest du es nicht seltsam, dass das Team Small Blocks immer wieder gesagt hat: "Das UTXO ist der wahre Flachenhals"? Wie überhaupt die wandernden Flaschehälse recht merkwürdig sind ...
MoinCoin
Sr. Member
****
Offline Offline

Activity: 446


Extension Blocks <3 Rootstock <3


View Profile
July 18, 2017, 05:40:45 PM
 #1430

Oops - Post ist etwas lang geworden  Grin

Am 1. August gibt es die Big Block Bitcoin Cash Fork
https://bitcoinblog.de/2017/07/18/fork-in-sicht-bitcoin-cash-wird-am-1-august-zu-groesseren-bloecken-forken/

Bin ja sehr gespannt, ob da was draus wird.
Bin auch gespannt - damit steht zumindest mal fest, dass wir mindestens 2 unterschiedliche Bitcoins haben.
Die Zeit ist natürlich extrem knapp, damit auch Light-Wallets entsprechende Software rausbringen können, damit man sicher die entsprechende Chain auswählen kann, oder eine Reorg-Protection hat.
Naja - ist wohl erstmal ein Grund ein BitcoinABC Full Node laufen zu lassen *lol*
Lustig, dass BCC von Bitfinex schon dem Bitcoin Core Split-Token zugesprochen wurde  Cheesy
Welchen Namen das wohl erhält, falls Bitfinex mitzieht Smiley

Grundsätzlich find ich das schon in Ordnung. Es gibt zwar keinen technischen Grund vor Segwit Angst zu haben, vor allem, da es Opt-In ist, also niemand einen zwingen kann das zu benutzen, aber der Zeitpunkt ist ungefähr der letztmögliche um einen Fork zu machen, bei dem es kein Segwit gibt.
Ansonsten bin ich eher enttäuscht, dass der Fork nicht bereits viel früher passiert ist, als noch nicht klar war, dass ein Kompromiss (Segwit2x) gefunden wird, der zwar nicht von allen, aber immerhin von vielen getragen wird.

Ist die Frage, ob das den Hard Fork von Segwit2x jetzt gefährdet - zumindest haben wir die Möglichkeit mal zu sehen, wie so ein Bitcoin Hard Fork abläuft und können daraus ggf. noch etwas lernen.


@MoinCoin: Damit ist das UTXO set bis auf weiteres nicht im geringsten ein Problem. Wenn es mal über 10 Gigabyte geht, könnte man darüber nachdenken, ob man es hier lässt, damit auch Smartphones das ganze UTXO problemlos speichern können. Aber da es noch keine dieser Art von Light-Wallet gibt, die auf Basis des UTXO arbeiten, ist die Frage eher theoretisch. Für die bisherigen Nodes und Miner scheint es keine Rolle zu spielen.

Findest du es nicht seltsam, dass das Team Small Blocks immer wieder gesagt hat: "Das UTXO ist der wahre Flachenhals"? Wie überhaupt die wandernden Flaschehälse recht merkwürdig sind ...
Ja die Größe des UTXO ist und bleibt für die nächsten Jahre zumindest für Miner kein Problem.

Nein ich finde es nicht seltsam, weil beide Seiten Fundamentalisten haben, die es mit der Warheit, oder technischen Details nicht so genau nehmen.
Ich bin auch nicht per se ein Small-Blocker, vielleicht wirkt das nur so, weil von den Themen, die mich stören meistens hier nur die Big-Blocker Punkte aufkommen.

Die wandernden Flaschenhälse sind aber auch nicht merkwürdig - das ist normal bei einem technischen System - hat man einen Flaschenhals beseitigt ist etwas anderes der neue Flaschenhals - das ist immer so. Wenn wir lange genug alles andere optimieren, dann wird das UTXO irgendwann automatisch zum größten Flaschenhals.

Und es ist auch immer eine Frage, ob es gerade im Fokus eines Entwicklers ist. Wenn man einen neuen Anwendungszweck, wie die von dir genannten Light-Wallets die auf Basis eines UTXO arbeiten auf einmal als neuen Anwendungszweck erkennt, kann also auch ohne, dass sich sonst etwas technisch verändert hat, ein neuer Flaschenhals entstehen - bzw. er war für den Anwendungszweck zwar immer schon da, aber man hat es vorher einfach übersehen.

Und die Light-Wallets wurden ja auch entwickelt, weil zum Beispiel der benötigte Speicherplatz ein Flaschenhals war.

Am Ende ist eben alles eine Frage der Optimierung und der damit verbundenen Konsequenzen.

Und nochmal zum Thema - Ich sehe mich nicht als Small-Blocker, oder Team Core:
Luke-Jr mit seinen Zensur Bestrebungen und seinem 300kb Hard Fork Vorschlag ist mir zum Beispiel ein Dorn im Auge. Meine Meinung, das ich BIP148 für gefährlich und unnötig halte habe ich ja auch schon oft genug hier gesagt.

Anderer Punkt: Ich finde nicht, dass wir bereits jetzt einen Fee-Market (was für ein dämliches wort, Preis für eine Gebühr hahaha) entwickeln müssen, noch dass es aufgrund der extrem vielen unbekannten Variablen überhaupt einen vernünftigen Fee-Predictor geben kann, der sich nicht selbst schlägt -> Sprich der konstante Backlog von Greg ist meines Erachtens auch keine Voraussetzung, damit das Bitcoin-Mining auch noch funktioniert, wenn der Block-Reward stark abfällt. Es ist aktuell noch kein Problem, es lässt sich bestimmt anders lösen, als mit einem konstanten Backlog -> Zum Beispiel in dem die Auszahlung des Block-Rewards+Fees auf viele Blöcke verteilt wird

Ich bin aber stark der Meinung, dass wir erstmal alle uns zur Verfügung stehenden Technologien nutzen sollten, bevor wir riskante Dinge anpacken und Block Space grundsätzlich ein knappes Gut bleiben sollte, solange wir nicht die Situation mit den Full Nodes in den Griff bekommen, damit die Zentralisierung nicht zu stark wird. Wenn die risikoarmen Lösungen ausgeschöpft sind, wird sich auch unterstützung für Lösungen mit höherem Risiko (inhärentes Chain Split Risiko) finden.






Quote
Quote
Quote
Und wir hatten immer eine bekannte Feste Obergrenze, die fällt ja bei EB / ABC praktisch weg.
Nee. So viele Seiten der Diskussion, und wir landen wieder da. Das ist traurig.
Ja - und ich hab ja mal ausführlich erklärt warum und da warst du glaub ich nicht unbeeindruckt - kann es gerne wieder raussuchen.
Du hast mir erklärt, wie BU schleichend in die Zentralisierung führen kann. Ich war davon ähnlich beeindruckt wie von Peter-Rs Vortrag, wie SegWit schleichend dazu führt, dass Miner keine Signaturen prüfen / speichern. Beides beruht auf ähnlich realistischen / paranoiden Annahmen. Spielt in derselben Liga wie zu sagen, SPV funktioniere nicht ohne Fraud Proofs.

Beeindruckt != Zustimmung.

Wie gesagt: Wir können bei Ethereum, Dash und Monero sehr gut beobachten, wie Emergent Consensus in freier Wildbahn funktioniert.

Abgesehen davon: Mir ging es um deinen Satz, dass BU / Emergent Consensus kein Limit hat. Das ist eben falsch und ich hätte erwartet, dass du es weißt.
Ja es ist auch nur eine Hypothese. Ein bisschen ärgerer ich mich, dass du das mit Peter-Rs Vortrag vergleichst, weil dazu Segwit erstmal geändert werden müsste (Änderung am P2P Layer und Änderung am Consensus-Layer), damit das funktioniert, was er vorgestellt hat, während  meine Hypothese, dass es zu einer schleichenden Zentralisierung mit Emergent Consensus auf einfachen Annahmen fußt:
Sobald es genug freie Kapazität vom sichersten Blockspace gibt, steigt über die Zeit auch der Bedarf
Nachdem einmal der initiale Widerstand überwunden wurde das einzuführen, wird es nie wieder Nicht-Miner-Nodes geben, die zusammen genug Widerstand leisten können um eine Anhebung zu blockieren
Für Miner stellt eine ansteigende Blockgröße nur minimalen zusätzlichen Aufwand dar, das heißt, solange sie irgendwelche andere Vorteile haben, werden diese die Blockgröße einfach immer erhöhen

Gerade bei Ethereum war das schon spannend mit dem Account basierten System - Die Exchanges haben ja teilweise die Deposits und Withdrawals während der hohen Last Phase gesperrt - Das kann bei Bitcoin mit dem UTXO basierten Ansatz ja nicht so einfach passieren -> Da setzt sich die höhere Fee automatisch durch.

Hast du übrigens mal geschaut, wie wenig Transaktionen Dash hat? Ich war erstaunt, wie wenig das sind, wo Roger da doch so oft von redet.
https://bitinfocharts.com/comparison/transactions-ltc-dash-xmr.html#3m

Bis auf Ethereum kommt kein System auch nur annähernd an Bitcoin heran und ist deswegen auch nur schwer vergleichbar.

Wenn wir jetzt 2 verschiedene Bitcoins haben wird es spannend.
Wird spannend, ob die Lager sich jetzt auch technisch gegenseitig angreifen, indem zum Beispiel einfach sinnlose Daten (Transaktionen) in die Blockchain geschrieben werden.

Quote from: Bergmann_privat
Quote from: MoinCoin
Wer will da noch gegen eine Vergrößerung gegenhalten? Schließlich muss man ja "besser" sein als die andere Chain und immer genug freien Blockspace haben, damit 0-conf einigermaßen funktioniert.
Also falls wir durch Segwit2x keinen klaren Gewinner bekommen  gehe ich stark davon aus, dass sich eine Chain auf die Dezentralisierung konzentriert und die andere Chain das Problem der Zentralisierung erstmal ignoriert und das Blockgrößen Limit effektiv abschafft.
Soso. Das System 0-conf und freier Blockspace hat zwar jahrelang gut funktioniert, und du plädierst für ein "weiter so", aber irgendwie jetzt doch nicht ...?

Und wegen der Konkurrenz durch Altcoins gibst du lieber jetzt auf, als es überhaupt zu versuchen?
Ja, weil immer absehbar war, dass es nur ein bisschen mehr freien Block space gibt.
Was meinst du mit aufgeben?


Quote from: Bergmann_privat
Nur Kontroversen unter Minern machen eine Hard Fork zum Chain Split. Kontroversen ansonsten sind weitgehend egal. Außerdem macht deine Agitation gegen Hardforks hier eine Hardfork unnötig kontrovers. Du trägst also zu dem Problem bei, das du gelöst sehen willst. Etwa so: "An sich bin ich vollkommen einverstanden, allerdings muss ich einverstanden sein, und ich bin nicht einverstanden, weil ich erst einverstanden sein muss." Du machst die Kontroverse zum Selbstzweck.
Nur weil eine Kontroverse unter Minern bei einem Hard Fork einen Chain Split sicher macht, heißt das nicht, dass man das Gegenteil ausschließen kann, wenn sich die Miner einig sind.
Selbst wenn die Miner sich absolut einig sind und 100% Hash Power haben, haben Nutzer und Entwickler jederzeit die Möglichkeit einen neuen Fork aufzumachen, wenn dieser nicht den exakt gleichen Consensus Mechanismus und im Falle von Bitcoin den Double-SHA256 PoW-Algo nutzt, besonders deutlich wird dies bei einem hypothetischen Wechsel auf Proof of Stake.


Quote from: Bergmann_privat
Siehe hierzu auch
Quote
Quote
Ich finde auch nicht, dass ein Chain-Split ein Weltuntergang ist - es ist eben die Frage unter welchen Voraussetzungen der stattfindet.
Deine Vorraussetzung hier: Replay Protection.

und
Quote
Quote
Quote
D.h.: Du willst niemals eine Hardfork.
Falsch - Ich will niemals einen Chain Split.

Ich weiß, die Zitate sind etwas aus dem Zusammenhang gerissen. Etwas widersprüchlich wirkt es aber schon, findest du nicht?
Unter der Annahme, dass ein Hardfork niemals 100% Zustimmung finden wird, ist ein Hardfork immer gleichzusetzen mit einem Chainsplit.
D.h.: Du willst niemals einen Hardfork?

Replay Protection, wie sie derzeit diskutiert wird, ist die sicherste Garantie, um eine Chain Split zu provozieren.

Die Argumentation geht jetzt also etwa so:
1. Wenn schon Hardfork, dann mit Replay Protection
2. Keine Hardfork, wenn Chain Split, also: keine Hardfork, da Replay Protection

Brillant!
Du hast schon recht, dass das ein sich selbst schließender Argumentationskreis ist. Ich halte den deswegen aber nicht für falsch und auch nicht für undurchbrechbar.
Segwit2X kommt dem ja schon recht Nahe - hätte man sich mit dem Hard Fork mehr Zeit gelassen, dann würden am Ende wirklich nur noch extreme Fundamentalisten übrig bleiben.

Mein größtes Problem mit Segwit2X ist, dass ich keine Ahnung habe, was nach dem 2MB Hard Fork passiert. Wie ist der weitere Plan? Bzw. was für Eigenschaften von Bitcoin repräsentiert der - welchen Stellenwert hat Dezentralität und Zensur Resistenz.
Wenn man die Core Leute an Bord hätte, hätte ich ein gutes Gefühl, dass es ausreichend diversifizierte Interessengruppen gibt.

Wenn sich das aufspalten sollte, dann könnten am Ende beide Bitcoins nichts für mich sein.
Die Eine Seite, die sich überhaupt nicht um Dezentralität schert und dann ein anderes Bitcoin, was sich zu sehr darauf konzentriert.

Meine Argumentation hast du allerdings nicht korrekt dargestellt, denn es gibt bereits die klassische Replay Protection das über "Taint" zu regeln.
Die ist einfach sehr fehleranfällig für normale Nutzer, weil kompliziert umzusetzen. Und erstmal braucht man neue Bitcoins, also den Taint, damit die Transaktion nur auf einer Kette gültig ist.
Und eine Replay-Protection hat für mich nichts mit der Chain-Split gefahr zu tun - die ist für mich intrinsisch für einen Hard Fork, dank des Status-Quo-Bias.
Niemand kann vorhersagen, wie sich ein Hard-Fork tatsächlich entwickelt und ob es zu einem Chain-Split kommt oder nicht.

Ich halte es einfach für eine sinnvolle Vorsichtsmaßnahme, die leicht umzusetzen ist, wenn ein Hard Fork folgendes bietet:
1. Wipeout-Protection
2. Replay-Protection
3. Reorg-Protection für Light-Wallets, bzw. sichere Auswahl der Blockchain für Light-Wallets

UAHF hat 1+2, 3 fehlt, Segwit2X hat nur 1

Quote
Hast du übrigens gewusst, dass Mike Hearn mal mit Get_UTXO es SPV-nodes erlauben wollte, bei Full Nodes die UTXO abzufragen, das aber von Core niedergeschmettert wurde? Mit Get_UTXO wäre es vermutlich gar kein Problem, einen kleinen "21-Millionen-Prüfer" aufs Smartphone zu bringen, der das UTXO aufbaut und alle 20 Min die Peers wechselt, um zu checken, ob es richtig ist ...
Langsam bitte: Core kann nur entscheiden, was in Core kommt.
Und da Get_UTXO nicht den Consensus-Layer betrifft, sondern nur den P2P-Layer kann Core nicht verhindern, dass das in Bitcoin kommt.
Meines Wissens nach hat er das in Bitcoin-XT eingebaut.
Warum haben Bitcoin Unlimited, Bitcoin Classic und BitcoinABC & Co. das nicht übernommen?
Vielleicht ist es doch nicht so toll?

Ich glaube es war nicht nachprüfbar, ob die Nachricht authentisch ist und damit hat es zu keiner Erhöhung der Sicherheit geführt.
Ggf. wurde es auch nicht gemerged, da es DOS Angriffe erleichtert.

Bringt ja sowieso nur was für 0-conf und die Transaktion dürfte man selbst nur erhalten, wenn der UTXO-Eintrag existiert.
Das heißt die Node, die einem die Transaktion geschickt hat könnte man nicht nach dem UTXO Eintrag fragen, denn warum sollte die Node nur einmal die Wahrheit mitteilen und einmal lügen.
Zudem ist das anfällig für MITM Angriffe.

Quote
Verbindet sich der SPV Node mit der Blockchain mit der meisten Arbeit? Wenn ja, bräuchtest du einen sehr ausgefuchsten Sybil-Angriff oder müsstest einen gültigen Block fälschen. Beides ist als Angriff zu teuer, um eine echte Gefahr für die Zielgruppe <20k $ Node zu sein.
Ja - Der Angriff ist sehr teuer - aber bei mehreren Bitcoins, wie wir es bald haben werden lohnt er sich unter bestimmten umständen, ohne das der Miner einen Schaden hat, denn er schadet nur der Kette die er bekämpfen will.

Quote
Quote
Wir wissen leider nicht, wann Bitcoin die Eigenschaften der Dezentralität verliert. Wenn wir das wissen, wird es leider schon zu spät sein. Ist dann die Frage, ob es noch einen Unterschied macht, ob derjenige, der jetzt die Transaktionen kontrolliert "Miner", "Paypal" oder "Bank" heißt.
Wir wissen noch nicht mal, was "Dezentralität" bedeutet. Ist aber vermutlich recht bequem, wenn man das Wort verwenden will, um Behauptungen zu stützen.
Dezentralität bedeutet für mich, dass ich mir keine Sorgen machen muss, dass es irgendeine Partei geben kann, die die Fungibiltät meiner Bitcoins einschränken kann.
Das wenn ich bereit bin eine Gebühr zu bezahlen, die hoch genug ist, mir sicher sein kann, dass meine Transaktion in die Blockchain aufgenommen wird.

Das bedeutet für mich, dass niemand, auch nicht wenn die Regierungen von den USA, EU und China zusammentun genug Druck auf irgendjemand ausüben können, weil es so viele Teilnehmer im Markt gibt, das ein gezieltes Vorgehen gegen einzelne Teilnehmer mittelfristig keine Auswirkungen hat, weil sofort ein anderer Teilnehmer die Aufgaben übernimmt.

Wenn wir nur wenige Full Nodes oder Miner haben, dann wird das System von innen und von außen angreifbar.

Quote from: Bergmann_privat
Quote from: MoinCoin
Mit Sidechains und Extension-Blocks kann man aber zumindest das relativ gefahrlos austesten, wann wir da an Grenzen stoßen, während die einfache Erhöhung der Blockgröße unumkehrbare Resultate schafft.
Und gleichzeitig haben wir keinen Chain Split.
Sidechains und Extension Blocks sind sehr viel zentralisierter als echte Bitcoin-Transaktionen. Noch bevor die "Dezentralität" ernsthaft in Gefahr ist, wirfst du unnötigerweise einen Großteil der Transaktionen zentralen Akteuren in den Rachen. Brillanter Plan, um die Dezentralität zu retten.

Ist das wirklich so? Also Extension Blocks sind vielleicht zentralisierter als das aktuelle Bitcoin - aber nicht zentralisierter als ein Bitcoin, bei dem die Miner die Regeln bestimmen, oder bei einem Bitcoin mit großen Blöcken. Und selbst bei Sidechains sind es die Miner die für die Sicherheit sorgen.
Wenn man ein Light-Wallet nutzt, hat man keine größere Gefahr.
Für Sicherheit sorgen bei Extension Blocks wie bei normalen Blöcken die Miner und auch alle Full-Nodes, die Extension Blocks unterstützen. Wir verschlechtern uns also nicht und haben dafür noch zusätzlich ein sehr dezentrales normales Bitcoin, auf das man auch mit einfacher Hardware zugreifen kann. Wenn sich zeigen sollte, dass alle die Extension Blocks nutzen und das die Sorgen über Zentralität unbegründet sind, kann man die Extension-Blocks und die normalen Blöcke sogar zusammenführen. Sowas meine ich mit "gefahrlos ausprobieren"

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
ajas
Member
**
Offline Offline

Activity: 92


View Profile
July 18, 2017, 05:43:18 PM
 #1431

Quote
Schon gehört?
Am 1. August gibt es die Big Block Bitcoin Cash Fork

Prima, dann habe ich demnächst 3x soviele Bitcoins wie jetzt:

 1) bitcoin cash
 2) Die core developer
 3) SegWit2x

Man muss davon ausgehen dass die ersten beiden Gruppen keinen
Millimeter von ihrer Position abweichen und um jeden Preis einen
Fork herbeiführen werden. Die dritte Gruppe sind diejenigen, die
sich um einen Kompromis bemüht haben. Sollen ausgerechnet die klein
beigeben ?

Es fragt sich dann nur noch welchen Wert die jeweiligen Coins behalten
werden.


el_rlee
Legendary
*
Offline Offline

Activity: 1496



View Profile
July 18, 2017, 06:52:27 PM
 #1432

Irgendwie verstehe ich die Zusammenhänge nicht ganz...



und



SegWit2x ist also was? Weder BIP91 noch BIP148? Was muss bis ersten August auf über 80% steigen, damit was passiert? BIP91?

Danke!

Wenn SegWit2x also BIP91 ist (das anscheinend schon seit mindestens 22. 5. 2017 existiert https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki), warum signalisieren dann die Pools irgendeine Intention und nicht gleich BIP91 ?

Warum ist BIP91 in den letzten 24h so massiv gestiegen?
hv_
Hero Member
*****
Offline Offline

Activity: 644


View Profile
July 18, 2017, 07:01:40 PM
 #1433

Soweit ich es verstehe, benutzt man das core BIP91'signal , um dann btc1 von Jeff Garzick und Sergio Lerner zu aktivieren, oder core macht bei dem 2MB HF mit... Sonst könnte es sein, dass es nur den btc1 gibt, wenn die miner zusammenhalten und  sich an das NYA binden...

Carpe diem  -  cut the down side  -  be anti-fragile
A feature that needs more than one convincing argument is no and Satoshi owes me no proof.
My coding style is legendary but limited to 1MB, sorry but cannot come much over my C64, Bill Gates and Tom Bombadil
MoinCoin
Sr. Member
****
Offline Offline

Activity: 446


Extension Blocks <3 Rootstock <3


View Profile
July 18, 2017, 07:18:59 PM
 #1434

Also:
Das BIP91 Signal wird nicht von Bitcoin Core unterstützt, sondern nur von dem btc1 core client (pools wie viabtc haben ggf. eigene Implementierungen) und hat zunächst einmal nichts direkt mit Segwit zu tun..
Das nutzen nur die Miner untereinander - Als Endbenutzer kann man das ignorieren.

Sobald BIP91 aktiv ist (frühestens in 6 Tagen), sind nur noch Blöcke, die für BIP141 signalisieren gültig und dadurch wird die Aktivierung von Segwit dann bei allen Clients die Segwit unterstützen innerhalb von ca. 4 Wochen erfolgen.

BIP91 muss vor dem 01. August aktiv sein.

Segwit2x beinhaltet BIP91, BIP141 und den 2 MB HF, das kommt praktisch alles nacheinander.

Das 1. Diagramm ist falsch, weil Segwit 4 Wochen bis zur Aktivierung braucht, der Pfad ist aber korrekt.
Wenn wir es einfach halten wollen, dann brauchen wir momentan nicht mehr betrachten.

Edit:
Das mit BitcoinABC ist auch falsch.
Es wird aller Voraussicht nach zum 1. August 2 verschiedene Bitcoins geben:
Das normale Bitcoin - und Bitcoin Cash (womit BitcoinABC kompatibel ist)

Edit2:
Das BIP91 Signal ist so massiv gestiegen in den letzten Stunden, weil btc1 die entsprechende Software erst gestern veröffentlicht hat

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
ajas
Member
**
Offline Offline

Activity: 92


View Profile
July 18, 2017, 08:32:20 PM
 #1435

Gehen wir jetzt mal zur technischen Umsetzung der anstehenden Forks
für den Endnutzer über.

Wir müssen also demnächst 2-3 verschiedene Clients laufen lassen
um unsere verschiedenen Bitcoin-Sorten verwalten zu können.

Bislang ist die Blockchain 130 Gbyte groß. Ist es möglich den Anteil bis
August 2017 nur 1x auf der Platte zu halten wenn man z.B. ein Btrfs
Filesystem benutzt?

Ist da jemand Experte?
TestNutzer1
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 18, 2017, 08:51:08 PM
 #1436

Gehen wir jetzt mal zur technischen Umsetzung der anstehenden Forks
für den Endnutzer über.

Wir müssen also demnächst 2-3 verschiedene Clients laufen lassen
um unsere verschiedenen Bitcoin-Sorten verwalten zu können.

Bislang ist die Blockchain 130 Gbyte groß. Ist es möglich den Anteil bis
August 2017 nur 1x auf der Platte zu halten wenn man z.B. ein Btrfs
Filesystem benutzt?

Ist da jemand Experte?


Also ich habe nun folgende Versionen laufen
bitcoin-0.14.2-uasfsegwit1.0
bitcoinUnlimited-1.0.2.0
bitcoin-core-0.13.2-addrindex

Also das BTC Cash bin ich noch dabei zu installieren bzw. BitcoinABC .

Hab ich alles dabei oder fehlt mir was, grad bezüglich der neuen Forks?


MoinCoin
Sr. Member
****
Offline Offline

Activity: 446


Extension Blocks <3 Rootstock <3


View Profile
July 18, 2017, 09:12:26 PM
 #1437

Also du hast mehrere Möglichkeiten.
Du brauchst ein Light-Wallet, wie zum Beispiel Electrum, bei dem du einen Server auswählen kannst.
Achte darauf, dass du dir Taint besorgst oder selbst erstellst, damit du Replay Protection hast und den Taint bei jeder Transaktion verwendest.
Anleitung auf Englisch http://docs.electrum.org/en/latest/hardfork.html
Anleitung ist zwar für BU, funktioniert aber genauso mit BitcoinABC

Die sichere Variante und wenn du sowieso schon einen Historical Full Node hast:


Anleitung um Bitcoin ABC / Bitcoin Unlimited Cash Edition / etc. ohne redundante Daten gleichzeitig zu Bitcoin Core zu nutzen:

Schritt 0:
(Unbedingt durchführen, ansonsten kann eure Bitcoin Core Installation unbrauchbar werden)
Eure Verknüpfung zur BitcoinABC binary anpassen, damit das sein eigenes Datenverzeichnis hat und ggf. Port und RPC-Port anpassen, damit beide Clients gleichzeitig laufen können
-datadir=OrdnerZuNeuemDataVerzeichnis -port=28333 -rpcport=28334

Folgende Schritte gehen nur vor dem Hard Fork, also vor dem 01. August, ansonsten weiter unten gucken:
1. die alten blk...dat und rev..dat Dateien einfach als Symbolic oder Hard link in den "blocks" Ordner im neuen "data" Ordner reinkopieren
2. Optional zur Sicherheit: Die letzten Symlinks von den blk*.dat und den rev*.dat Dateien löschen und die Originale kopieren
    Vorsichtshalber könnt ihr eure *.dat Dateien im alten Verzeichnis als Schreibgeschützt markieren
3. den "chainstate" Ordner kopieren
4. den index ordner im "blocks" ordner kopieren

.bat Datei für Windows um Schritte 1-4 automatisch auszuführen  (Bitte passt die Pfade entsprechend eures Systems an)
Die .bat als Administrator ausführen, ansonsten werden keine symbolischen Links angelegt.
Code:
SETLOCAL EnableDelayedExpansion
set srcDataDir=C:\Bitcoin\data\
set tgtDataDir=C:\bitcoinABC-0.14.3-win64\data\

Call :CreateOrCleanupDir %tgtDataDir%\blocks
Call :CreateOrCleanupDir %tgtDataDir%\blocks\index
Call :CreateOrCleanupDir %tgtDataDir%\chainstate

copy "%srcDataDir%\blocks\index\*" "%tgtDataDir%\blocks\index\"
copy "%srcDataDir%\chainstate\*" "%tgtDataDir%\chainstate\"

for /f "delims==" %%k in ('dir "%srcDataDir%\blocks\blk*.dat" /s /b') do (
set lastFile=%%~nxk
mklink "%tgtDataDir%\blocks\%%~nxk" "%%~k"
)

del "%tgtDataDir%\blocks\%lastFile%"
copy "%srcDataDir%\blocks\%lastFile%" "%tgtDataDir%\blocks\%lastFile%"


for /f "delims==" %%k in ('dir "%srcDataDir%\blocks\rev*.dat" /s /b') do (
set lastFile=%%~nxk
mklink "%tgtDataDir%\blocks\%%~nxk" "%%~k"
)

del "%tgtDataDir%\blocks\%lastFile%"
copy "%srcDataDir%\blocks\%lastFile%" "%tgtDataDir%\blocks\%lastFile%"


pause
goto :eof

:CreateOrCleanupDir
if exist "%1" (
del "%1\*"
) else (
md "%1"
)
goto :eof



BitcoinABC braucht dann nichts mehr synchronisieren, sondern ist sofort bereit für den Einsatz, allerdings geht das nur vor dem 01. August

Wenn man das nicht vor dem 01. August geschafft hat:
1. Symlinks nur für die blk*.dat Dateien erstellen -> bat datei anpassen (rev*.dat Dateien brauchen wir nicht)
2. Symlinks von blk.*dat Dateien, welche nach dem 31. Juli modifiziert worden sind löschen - ggf. wieder die Ursprungsdateien schreibschützen.
3. Achtung: BitcoinABC mit der -reindex Option starten - ansonsten nutzt er die blk*.dat Dateien nicht, sondern lädt diese neu runter

Die Software muss die blk*.dat Dateien neu in die Datenbank einlesen und die Blöcke, welche nach dem Hard Fork erzeugt wurden neu runterladen - das kann einige Stunden dauern.



Praktischerweise wird man wohl kaum mehrere Full Nodes laufen lassen. Du kannst also die Bitcoins, die dir weniger wichtig sind entweder verkaufen oder in ein anderes Light-Wallet übertragen.

Extrem vorsichtig musst du sein, wegen der Replay Protection sein.
Das heißt spätestens ab dem 30.07. keine Transaktionen mehr ausführen, solange es noch Backlog im Mempool gibt, bzw. darauf achten, dass man auf jeden Fall eine Fee nimmt, die so hoch ist, dass die Transaktion noch vor dem Chain Split bestätigt wird.

https://jochen-hoenicke.de/queue/#4d
https://bitcoinfees.21.co/

Dann auf der Chain, die Replay Protection hat, also am 01. August Bitcoin ABC alle Coins mit einer Replay-Protected Transaktion an eine eigene Adresse schicken.

Wenn du einfach so deine normalen Bitcoins transferierst, kann es sein, dass die Transaktion auf der Bitcoin-ABC (Bitcoin Cash) Chain dupliziert wird (replay) und du die Kontrolle über die Bitcoin-Cash Bitcoins verlierst.

Also ich habe nun folgende Versionen laufen
bitcoin-0.14.2-uasfsegwit1.0
bitcoinUnlimited-1.0.2.0
bitcoin-core-0.13.2-addrindex

Also das BTC Cash bin ich noch dabei zu installieren bzw. BitcoinABC .

Hab ich alles dabei oder fehlt mir was, grad bezüglich der neuen Forks?
Overkill - die ersten 3 landen (so wie es aktuell aussieht) auf der gleichen Chain - zumindest in den nächsten 3 Monaten
Es wird erstmal nur Bitcoin und Bitcoin Cash geben.

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
Rakete4
Full Member
***
Offline Offline

Activity: 235


View Profile
July 18, 2017, 09:16:52 PM
 #1438

Greg Maxwell und Matt Corallo helfen jetzt mit, dass die Segwit-Aktivierung mit BIP91 klappt. Sehr bullish!
https://github.com/btc1/bitcoin/issues/85

MoinCoin
Sr. Member
****
Offline Offline

Activity: 446


Extension Blocks <3 Rootstock <3


View Profile
July 18, 2017, 09:48:29 PM
 #1439

Greg Maxwell und Matt Corallo helfen jetzt mit, dass die Segwit-Aktivierung mit BIP91 klappt. Sehr bullish!
https://github.com/btc1/bitcoin/issues/85
Das gleiche Problem dürfte BitcoinABC haben.
Workaround könnte sein - Peers.dat löschen und BitcoinABC neustarten.
Habe dann zumindest auch mal ein Bitcoin ABC als Peer

Tip: 1P4yZF9b9w2Sy7PXV5AC1RQ8rQ4RoacYG2
ajas
Member
**
Offline Offline

Activity: 92


View Profile
July 18, 2017, 10:35:46 PM
 #1440


Vielen Dank @MoinCoin für die Anleitung mit den Links. Das war genau
das was ich wissen wollte (ich hab zwar Linux aber kann das leicht
übersetzen).

Also nach meinem Verständnis muß man folgende Clients laufen lassen um
gewappnet zu sein:

  1) bitcoin core                                   (für die Autisten)
  2) bitcoin_unlimited oder bitcoin_abc   (für die BigBlocker und Puristen)
  3) btc1                                              (für die Schlitzohren und Schlitzaugen)

Entschuldigt die Polemik, aber ich glaube diese 3 Varianten werden
ausreichen: 2) würde sich von 1) oder 3) am 1. August abspalten.  Der
Fork zwischen 1) und 3) würde dann erst später stattfinden, falls nicht
eine Seite noch aufgibt.

Quote
Praktischerweise wird man wohl kaum mehrere Full Nodes laufen
lassen. Du kannst also die Bitcoins, die dir weniger wichtig sind
entweder verkaufen oder in ein anderes Light-Wallet übertragen.

Auf die Frage 'welche dir weniger wichtig sind' kann man dann zu
unterschiedlichen Antworten kommen:

1) unter dem ökonomischen Aspekt: wo werden meine Bitcoins am meisten
   Wert sein. (Was werden wohl die anderen Akteure tun?) Da kann man
   alle Chains unabhängig voneinander weiterverfolgen und sehen was passiert.

2) unter dem weltanschaulichem Aspekt: welche Art Bitcoin würde ich am
   liebsten haben. Da könnte man dann nur versuchen die anderen zu
   sabotieren (keine entsprechenden Nodes laufen lassen, alle Bitcoins
   verkaufen oder vernichten Huh). Aber ob man da ausreichend Einfluß
   hat?

Letztendlich glaube ich immer noch dass ein einziger starker Bitcoin
am besten wäre. Aber mit der Ansicht steht man wohl allein.
Pages: « 1 ... 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 63 64 65 66 67 68 69 70 71 [72] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!