Für welche Bitcoin Fraktion bist du: Core oder Classic?

[4ley]

Hallo allerseits,

mich würde mal eure Stellung zu der Core vs. Classic Debatte interessieren. Stimmt ab und hinterlasst ein Kommentar warum ihr für das eine oder das andere gestimmt habt.

Ich tendiere zu Classic, da es mehr im Sinne von Satoshi war die Blocksize zu erhöhen, anstatt durch Sidechains und ähnlichem Bitcoin komplizierter zu machen als nötig.

Zitat: https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
 

It can be phased in, like:

if (blocknumber > 115000)
maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Edited February 24, 2016 by 4ley

[Christoph Bergmann]

Auf geht's! Wählt alle kräftig. Ich bin auch gespannt auf das Ergebnis.

 

Ich persönlich bin für Classic, aber das ist in keinster Weise stellvertretend für bitcoin.de.

 

Von den Reaktionen der Leser des Bitcoinblogs würde ich schätzen, dass das Ergebnis etwa 2:3 (core:classic) ausgehen sollte.

[...]

Habe mal fuer Classic gevotet obwohl ich eigentlich Unlimited als einzig wirklich sinnvolle Option sehe.

[4ley]

@cabuso die Überlegung war Unlimited und XT auch in die Umfrage mit reinzunehmen, da aber diese beiden sehr höchstwahrscheinlich keine Option mehr darstellen, müssen sich alle nun zwischen den beiden größten entscheiden.

 

Auf nodecounter.com kann man sehr schön die momentane Verteilung der Nodes sehen. Man muss aber sagen, dass die Seite die Anzahl der Nodes darstellt. Die Anzahl sagt nichts über die eigentliche Hashingpower aus, die aber beim Hardfork entscheidend ist. Bzw. man könnte es auch folgendermaßen sagen: Wenn von den letzten 1000 Blöcken 750 Classic Blöcke sind, dann sind 75% erreicht. Wenn diese 75% einen Monat lang aufrecht erhalten werden können, dann wird der Hardfork ausgelöst und die Blocksize für neue Blöcke auf 2 MB angehoben.

Edited February 24, 2016 by 4ley

[segeln]

Auf geht's! Wählt alle kräftig. Ich bin auch gespannt auf das Ergebnis.

 

Warum erklärst Du nicht mal den praktischen (und nicht technischen) Unterschied zwischen core und classic,verständlich für 08/15 user?

Siehe auch meinen post im blog.

http://bitcoinblog.de/2016/02/24/bitcoin-core-0-12-0-ist-veroeffentlicht/

[...]

@cabuso die Überlegung war Unlimited und XT auch in die Umfrage mit reinzunehmen, da aber diese beiden sehr höchstwahrscheinlich keine Option mehr darstellen, müssen sich alle nun zwischen den beiden größten entscheiden.

 

Auf nodecounter.com kann man sehr schön die momentane Verteilung der Nodes sehen. Man muss aber sagen, dass die Seite die Anzahl der Nodes darstellt. Die Anzahl sagt nichts über die eigentliche Hashingpower aus, die aber beim Hardfork entscheidend ist. Bzw. man könnte es auch folgendermaßen sagen: Wenn von den letzten 1000 Blöcken 750 Classic Blöcke sind, dann sind 75% erreicht. Wenn diese 75% einen Monat lang aufrecht erhalten werden können, dann wird der Hardfork ausgelöst und die Blocksize für neue Blöcke auf 2 MB angehoben.

Ist so nicht ganz richtig, Unlimited ist sowohl mit Core als auch mit Classic kompatibel. Hast aber insofern Recht als es von Miningseite jetzt erstmal um Classic <> Core geht.

Auf nodecounter kann man sich btw. auch die Verteilung der Bloecke ansehen.

[Axiom0815]

Hallo,
 
als Deutschland Ost & West zusammen wuchsen, diskutierte man nicht über die finanziellen Konsequenzen, sondern über die Kindergartenplätze in der DDR.
Heute, wo die Schulden uns in Europa über den Kopf gewachsen sind, eine Finanz-Kernschmelze also den absoluten GAU in naher Zukunft abzeichnet, diskutieren wir über Flüchtlinge.
(Ja natürlich, alles beide genannten Themen sind wichtig.)
 
Jetzt wo der neue Client 0.12.0 veröffentlich wurde, klar wir diskutieren wieder über Client A oder B - vielleicht aber auch C oder D.
Die Skalierung ist ohne Frage wichtig, mir scheint aber hier schon ein pro- und kontra-Lager entstanden zu sein.
Nicht zuletzt finden wir uns hier in der Diskussion schon in einer Abstimmung!
 
Okay, schauen wir mal den neuen V 0.12.0 unter die Haube.
Zu lesen gab es ja jetzt reichlich auf allen Kanälen. Scheinbar aber mehr eine Vervielfältigung (mit Poesie), als reale Tests.
 
libsecp256k1
 
Die Eigenentwicklung von libsecp256k1 ist ein Hammer! Man kann nur den Hut ziehen.
Wie macht sich das im Praxistest bemerkbar?
Ein Blick in die Konsole sagt mir:

 

/Satoshi:0.12.0/
OpenSSL 1.0.1k 8 Jan 2015
Berkeley DB 4.8.30: (April  9, 2010)

 
Meinung -
 
Automatische Nutzung von Tor
 
Wow, die Zeiten der Zeit sind verstanden worden!
Der 08/15-User muss in der Lage sein über TOR Bitcoin zu benutzen, bevor es zu schärferen Einschränkungen kommt.
 
Test:
Core 0.12.0 telefoniert lustig am TOR-Gateway (Browser) vorbei. (Obwohl Standard-Port 9150)
 
Na gut, dann mal unter Netzwerke die Optionen auswählen (nicht automatisch, sondern manuell).
Core lässt sich nicht zähmen. Wenn es doch zur TOR Nutzung kommt, wird TOR nur als Übertragungsmedium benutzt.
Man kommt bei anderen Clients mit den Port 8333 raus und wird unmittelbar wieder rausgeschmissen - "böses TOR". Eine Nutzung scheitert.
 
Meinung:
 
Nun das gute. TOR ist nach wie vor mit einer richtigen Konfiguration ohne Probleme zu nutzen.
Der 08/15 User steht aber nach wie vor, vor ihm überfordernde Probleme. (Wer kennt schon Bitcoin.conf?)
 
Für den geneigten Leser, der TOR nutzen will, aber auf den Schlauch steht, einen hidden-Services innerhalb es TOR-Netzwerkers (ich vermeide bewusst DARK-Netz, was ja schon mal wieder Manipulation ist) zu finden hier eine Liste:

• 2j2hz4zbuedcntub.onion:8333
• 2zdgmicx7obtivug.onion:8333
• 3ffk7iumtx3cegbi.onion:8333
• 3hshaantu6ot4upz.onion:8333
• 3lxko7l4245bxhex.onion:8333
• 4crhf372poejlc44.onion:8333
• 5at7sq5nm76xijkd.onion:8333
• 5ghqw4wj6hpgfvdg.onion:8333
• 5k4vwyy5stro33fb.onion:8333
• 77mx2jsxaoyesz2p.onion:8333
• 7g7j54btiaxhtsiy.onion:8333
• 7iyfdkr72hgtdjoh.onion:8333
• b2ykuvob44fn36wo.onion:8333
• bcb2tjvmui4p4bpf.onion:8333
• bitcoin2rajdbpny.onion:8333
• bitcoin625tzsusi.onion:8333
• bitcoincfqcssig5.onion:8333
• bitcoinostk4e4re.onion:8333
• bk5ejfe56xakvtkk.onion:8333
• blxbv6hlwofkuwiw.onion:8333
• bmutjfrj5btseddb.onion:8333
• btc4xysqsf3mmab4.onion:8333
• btcdatxubbzaw4tj.onion:8333
• btcnet3utgzyz2bf.onion:8333
• by4ec3pkia7s7wy2.onion:8333
• czsbwh4pq4mh3izl.onion:8333
• d2433q7bnshmwyb3.onion:8333
• dhxkxk6fn6zplasy.onion:8333
• dioq2yg3l5ptgpge.onion:8333
• dqretelgl3kjtzei.onion:8333
• drp4pvejybx2ejdr.onion:8333
• e3tn727fywnioxrc.onion:8333
• e7zgwdjbzwt4cfj4.onion:8333
• evolynhit7shzeet.onion:8333
• gb5ypqt63du3wfhn.onion:8333
• go2wkyflxur5leym.onion:8333
• h2vlpudzphzqxutd.onion:8333
• hhiv5pnxenvbf4am.onion:8333
• hkxy4jpeniuwouiv.onion:8333
• i2r5tbaizb75h26f.onion:8333
• iksneq25weneygcj.onion:8333
• it2pj4f7657g3rhi.onion:8333
• jxrvw5iqizppbgml.onion:8333
• k22qrck6cetfj655.onion:8333
• khrx2h3r2yux5ntp.onion:8333
• kjy2eqzk4zwi5zd3.onion:8333
• lazsruhzupsgpvwm.onion:8333
• lrkxsickfjnusslh.onion:8333
• lzxpkn6ptp3ohh63.onion:8333
• msphsgfiqfq5stne.onion:8333
• mtzcz5knzjmuclnx.onion:8333
• nkf5e6b7pl4jfd4a.onion:8333
• nns4r54x3lfbrkq5.onion:8333
• okdzjarwekbshnof.onion:8333
• plq4fgyit3bal2ms.onion:8333
• pqosrh6wfaucet32.onion:8333
• pt2awtcs2ulm75ig.onion:8333
• q6him22vxrpflsw3.onion:8333
• rlgktll62klm6jhs.onion:8333
• sjdomi4yb2dwkjbc.onion:8333
• syix2554lvyjluzw.onion:8333
• szsm43ou7otwwyfv.onion:8333
• td7tgof3imei3fm6.onion:8333
• tfu4kqfhsw5slqp2.onion:8333
• u2o3yfzcxbitcoin.onion:8333
• ukronionufi6qhtl.onion:8333
• uvwozwxlihntigbb.onion:8333
• v6ylz45dn5ybpk4d.onion:8333
• vk3qjdehyy4dwcxw.onion:8333
• vqpye2k5rcqvj5mq.onion:8333
• vso3r6cmjoomhhgg.onion:8333
• wpi7rpvhnndl52ee.onion:8333
• xdnigz4qn5dbbw2t.onion:8333
• xudkoztdfrsuyyou.onion:8333
• xyp7oeeoptq7jllb.onion:8333
• ymnsfdejmc74vcfb.onion:7033
• z3isvv4llrmv57lh.onion:8333
• z55v4ostefnwfy32.onion:8333
• zy3kdqowmrb7xm7h.onion:8333

Schauen wir mal was die nächsten Wochen so bringen.
 
Axiom

Edited February 25, 2016 by Axiom0815

[...]

Völliger Schwachsinn. Es zeigt die Stärke von  Bitcoin. Wenn ich Backroom Deals und zentrale Planung haben will kann ich auch jede existente Fiatwährung nutzen.

1. Wenn >= 75% der Hashpower fuer Classic sind gibt es keine Spaltung, es geht einfach auf 2 MB weiter.

2. Sollten mehr als 50% der Hashpower gegen die Ziele von Bitcoin arbeiten kann man einfach den Proof of Work aendern und sich von den Minern befreien. Das ist eine Stärke und keine Schwäche, die keine andere Zahlungseinheit hat.

 

Deine Haltung ist, warum wir das aktuelle Problem haben. Nur weil es Bitcoin Core heisst  und die älteste Implementierung ist, ist es noch lange nicht die mit der "Classic" Orientierung. Falls du es nicht mitbekommen hast: Bitcoin Core hat ganz offen die Ziele von Bitcoin umdefiniert und die Whitepaper Vision aufgegeben, um 2nd Layer Solutions künstlich attraktiver zu machen.

Die Leute müssen sich nicht einig sein. Dafür gibt es die Blockchain, die ist eindeutig, Fertig!

 

edit: das war an monk gerichtet.

 

@Axiom: Das tolle RBF Feature hat Core 0.12 auch!... und auch an dich gerichtet:

Siehst du es wie Core, dass Bitcoin nicht als Währung genutzt werden sollte und man künstlich Vaporwarelösungn wie Lightning konkurrenzfähig machen soll?

Edited February 25, 2016 by cabuso

[Axiom0815]

 

@Axiom: Das tolle RBF Feature hat Core 0.12 auch!... und auch an dich gerichtet:

Siehst du es wie Core, dass Bitcoin nicht als Währung genutzt werden sollte und man künstlich Vaporwarelösungn wie Lightning konkurrenzfähig machen soll?

 

Das es unterschiedliche Interessen gibt ist normal. *wir sind nicht lebensfremd*

Man muss diese Interessen nur klar auf den Tisch legen, um von anderen bewertet zu werden. Hier scheint jetzt auch der Konsens baden zu gehen und mit Nebelbomben und Scheingefechten gearbeitet zu werden.

 

Was ich nicht verstehe, da ich Bitcoin-Nutzer eine gewissen IQ unterstelle. Nur wer sein Hirn auch benutzt landet bei Bitcoin als reale Alternative.

Wer der Herde nach läuft, ist immer der Letzte.

[bitcoin-live.de]

Wirklich erstaunlich wie klar die Abstimmung momentan ist, wobei man schon sagen muss das es nicht wirklich repräsentativ für die ganze Community ist. 

Aber als Indikator, doch 

[Christoph Bergmann]

Warum erklärst Du nicht mal den praktischen (und nicht technischen) Unterschied zwischen core und classic,verständlich für 08/15 user?

Siehe auch meinen post im blog.

http://bitcoinblog.de/2016/02/24/bitcoin-core-0-12-0-ist-veroeffentlicht/

 

Falls deine Frage noch nicht beantwortet wurde, hier meine Version:

 

Bitcoin hat ein Block-Limit von 1 MB. D.h. es passen maximal 2-3 Transaktionen je Sekunde durch das Netzwerk. Das war lange kein Problem, wird aber auf absehbare Zeit eines werden (derzeit haben wir Blöcke mit 0,8 MB, was angesichts der Varianz des Auftauchens von Blöcken bedeutet, dass Blöcke voll sind).

 

Seit mehr als einem Jahr wird darüber diskutiert, ob und wie man die Größe der Blöcke erhöht. Das große Problem ist, dass diese Änderung nicht "konsens-kompatibel" ist, d.h. wenn die einen Knoten / Miner im Netzwerk sie einführen, sind sie nicht mehr mit anderen vollständig kompatibel. D.h. um das einzuführen, braucht man die größtmögliche Einigkeit. Leider sind wir in die Situation geraten, dass die Kernentwickler das Problem meiner Meinung nach viel zu lange schleifen lassen haben, weshalb es im Lauf des vergangenen Jahres zu einer Spaltung der Community kam: auf der einen Seite die Entwickler, die das Blocklimit möglichst gering halten, auf der anderen Seite die Wirtschaft mit Unternehmen wie Coinbase und BitPay, die das Blocklimit so schnell wie möglich erhöhen wollen, um weiteres Wachstum zu ermöglichen.

 

Im Endeffekt sind beide Seiten nun wieder recht nahe zusammen, streiten sich aber um Details bzw. um Politik. Die eine Seite wird durch Core repräsentiert, die andere durch Classic.

 

Technisch gesehen möchte Core in den kommenden Monaten durch Segregated Witness (SW) über eine Softfork (sagen wir über einen Hack) geringfügig skalieren, während Classic durch eine Hardfork geringfügig skalieren möchte. Core sagt, dass SW die bessere und sicherere Möglichkeit ist, kurzfristig Platz für mehr Transaktionen zu schaffen, während Classic sagt, dass wir demonstrieren müssen, dass eine Hard Fork möglich ist und dass eine einfache Erhöhung des Blocklimits der bessere Weg ist, um zu skalieren, wofür es auch in der Tat Gründe gibt (aber das geht jetzt zu weit)

 

Classic ist nun als Alternativer Client veröffentlicht und wird, falls 75% der Miner über 1.000 Blöcke hinweg für Classic stimmen, eine Hardfork durchführen, durch die die Knoten von Classic und Core nicht mehr vollständig demselben Netzwerk angehören werden. Im Detail kann eine Hardfork haarsträubend kompliziert werden, weshalb gehofft wird, dass bei 75% Miner-Zustimmung de andere Implemenierung einfach verschwindet.

 

Auf dem bitcoinblog habe ich darüber schon recht viele Artikel geschrieben. Liest mal hier: http://bitcoinblog.de/tag/blocksize/

[Christoph Bergmann]

Danke für die wie immer fundierten Infos.

 

Wie ist dein Blick in die Konsole bei libsecp256k1 denn zu verstehen?

 

Hallo,
 
als Deutschland Ost & West zusammen wuchsen, diskutierte man nicht über die finanziellen Konsequenzen, sondern über die Kindergartenplätze in der DDR.
Heute, wo die Schulden uns in Europa über den Kopf gewachsen sind, eine Finanz-Kernschmelze also den absoluten GAU in naher Zukunft abzeichnet, diskutieren wir über Flüchtlinge.
(Ja natürlich, alles beide genannten Themen sind wichtig.)
 

...

 

Axiom

 

[Christoph Bergmann]

Hallo, die Frage zeigt das Grab fuer den Bitcoin. Ich bin gegen die Spaltung. Denn wenn die sich wegen Differenzen einmal gespalten haben, dann werden die es wieder tun. Irgendann haben wir dann 10 Bitcoins oder Systeme. Was fuer ein Schwachsinn, das schwaecht das System als solches nur, wenn die Leute sich nicht einig sind.

 

Adrian

 

Haben wir schon längst, nennt sich Altcoin --

 

Es gibt aber tatsächlich die Meinung, dass man jede Art von Hardfork in jedem Fall vermeiden soll, um keinen Präzedenzfall dafür zu schaffen, dass man alles bei Bedarf ändern kann.

 

Ich sehe das nicht so und fürchte eher, dass derzeit ein Präzedenzfall geschaffen wird, dass Bitcoin nicht weiterwachsen kann, aber das ist eine Ansichtssache. Das einzige, was imho hilft, ist die Einigung auf eine nachhaltige Hardfork, an der sich alle beteiligen. Classic bietet das leider nicht, sondern verschiebt das Problem mit 2 MB leider nur ein Stück in die Zukunft (was aber imho besser ist, als es gar nicht anzugehen).

[Axiom0815]

Danke für die wie immer fundierten Infos.

 

Wie ist dein Blick in die Konsole bei libsecp256k1 denn zu verstehen?

 

 

 

Du hattest ja schon in Dein Artikel angedeutet, dass irgendwas mit TOR scheinbar nicht stimmt.

Arbeitest Du mit der Bitcoin.conf? Oder nur mal so die "Automaitik" getestet...?

 

libsecp256k1

 

Im Core auf Hilfe | Debugfenster und unter Hinweis - Allgemein lesen.

[4ley]

Haben wir schon längst, nennt sich Altcoin --

 

Es gibt aber tatsächlich die Meinung, dass man jede Art von Hardfork in jedem Fall vermeiden soll, um keinen Präzedenzfall dafür zu schaffen, dass man alles bei Bedarf ändern kann.

 

Ich sehe das nicht so und fürchte eher, dass derzeit ein Präzedenzfall geschaffen wird, dass Bitcoin nicht weiterwachsen kann, aber das ist eine Ansichtssache. Das einzige, was imho hilft, ist die Einigung auf eine nachhaltige Hardfork, an der sich alle beteiligen. Classic bietet das leider nicht, sondern verschiebt das Problem mit 2 MB leider nur ein Stück in die Zukunft (was aber imho besser ist, als es gar nicht anzugehen).

 

Dieser Präzedenzfall würde zeigen, dass man zwar alles ändern kann, weil man nunmal code einfach ändern kann, aber es würde auch zeigen, dass eine Änderung von der Mehrheit erst akzeptiert werden muss, damit diese auch in Kraft tritt. Was momentan stattfindet, ist ein demokratischer Prozess. Die Miner wählen die Partei (Software), für die sie mit ihrer Hashingpower stimmen. Wenn die Erhöhung auf 2 MB klappt, dann ist dies auch ein Präzedenzfall dafür, dass die Erhöhung auf 4, 8, 16, etc. MB reibungslos klappen kann.

 

Problematisch sehe ich den Ansatz von Core. Core verlässt die ursprüngliche whitepaper Definition von Bitcoin und erweitert das System auf unvorhersehbare Art und Weise. Hinzukommt, dass in Zukunft das System so kompliziert werden kann, dass man es eventuell kaum verstehen kann, wie es aktuell im Finanzsektor ist. Das könnte dazu führen, dass getrickst werden kann, diese Tricks aber gar nicht oder viel zu spät erkannt werden.

[...]

Das es unterschiedliche Interessen gibt ist normal. *wir sind nicht lebensfremd*

Man muss diese Interessen nur klar auf den Tisch legen, um von anderen bewertet zu werden. Hier scheint jetzt auch der Konsens baden zu gehen und mit Nebelbomben und Scheingefechten gearbeitet zu werden.

 

Was ich nicht verstehe, da ich Bitcoin-Nutzer eine gewissen IQ unterstelle. Nur wer sein Hirn auch benutzt landet bei Bitcoin als reale Alternative.

Wer der Herde nach läuft, ist immer der Letzte.

 

Es gibt nur einen Konsens und das ist der Minerkonsens auf der Blockchain.

Es gibt und gab nie einen Grund für weltweiten Konsens aller Beteiligten. Bitcoin ist ein 51% Hashingpowermajority-Wahlrecht. Von Anfang an. Dieses Bedürfnis nach Konsens vom kleinsten Bitcoiner bis zur größten Börse ist eine Umdeutung des Begriffs durch die BS-Propagandaabteilung.

 

Die Interessenkonflikte von BS, die bis auf einen, alle relevanten Coredevs bezahlen, werden bis heute von BS geleugnet. Das alleine ist aus meiner Sicht Grund genug Core nicht zu benutzen. So ziemlich alle anderen Beteiligten haben ihre Karten auf den Tisch gelegt.

 

Davon abgesehen macht Core geisteskranke Verrenkungen und baut aus ideologischen Gründen verkomplizierten Code (Softfork SegWit).

[Axiom0815]

Es gibt nur einen Konsens und das ist der Minerkonsens auf der Blockchain.

...

 

Das ist schlicht falsch!

 

Satoshi Nakamoto hat zur Abstimmung die Client-Software gewählt. Solch ein gehabe um die Miner (Power-Farm-Bildung / Monopolbildung) war nie im Grundkonzept vorgesehen.

 

Und das ist auch heute noch so. Auch wenn viel anderes geschrieben wird!

Wenn der Nutzer einen Client X wählt und damit der Mehrheit beitritt, ist dies die wirkliche Wahl.

 

Ob Softwareentwickler ABC noch zig andere (nicht kompatible) Alternativen entwickeln und "mussche-bubu" mit Miner XYZ machen, ist schlicht egal.

 

Die Miner-Schwierigkeit (difficulty) wird sich automatisch den neuen Gegebenheiten der Wahl anpassen und die (korrupten) Cliententwickler und Miner im anderen Zweig der Gabel können sich gegenseitig die XYZ-Bitcoin zuschieben, denn ein anderer will diese wertlosen Coins dann nicht mehr haben.

 

Axiom

[...]

Das ist schlicht falsch!

 

Satoshi Nakamoto hat zur Abstimmung die Client-Software gewählt. Solch ein gehabe um die Miner (Power-Farm-Bildung / Monopolbildung) war nie im Grundkonzept vorgesehen.

 

Und das ist auch heute noch so. Auch wenn viel anderes geschrieben wird!

Wenn der Nutzer einen Client X wählt und damit der Mehrheit beitritt, ist dies die wirkliche Wahl.

 

Ob Softwareentwickler ABC noch zig andere (nicht kompatible) Alternativen entwickeln und "mussche-bubu" mit Miner XYZ machen, ist schlicht egal.

 

Die Miner-Schwierigkeit (difficulty) wird sich automatisch den neuen Gegebenheiten der Wahl anpassen und die (korrupten) Cliententwickler und Miner im anderen Zweig der Gabel können sich gegenseitig die XYZ-Bitcoin zuschieben, denn ein anderer will diese wertlosen Coins dann nicht mehr haben.

 

Axiom

Ich glaube du hast mich da missverstanden, weil der zweite Teil deiner Antwort genau das aussagt was ich auch sage.

Der zweite Teil bei dir zeigt doch, dass es keinen "Konsens" im Bitcoinnetzwerk geben muss, so wie er heute gerne propagiert wird (d.h. alle Teilnehmer sind einverstanden). Wenn ich mit den Entwicklungen von Bitcoin nicht einverstanden bin, kann ich jederzeit die Blockchain mit einem neuen PoW forken. Das ist die Macht, die alle Netzwerkteilnehmer haben und die verhindern kann, dass boesartige Maechte Bitcoin uebernehmen.

Innerhalb einer Blockchain gibt es aber nur eine Abstimmung und nur einen Konsens und das ist die laengste Chain.

 

Innerhalb einer Blockchain gilt die vereinfachte Aussage von Satoshi: "One Cpu - One Vote". Welche Coin/Blockchain erfolgreich ist, dass ist eine Frage des Marktes und der Nutzerabstimmung, so wie du es beschreibst.

[Christoph Bergmann]

Du hattest ja schon in Dein Artikel angedeutet, dass irgendwas mit TOR scheinbar nicht stimmt.

Arbeitest Du mit der Bitcoin.conf? Oder nur mal so die "Automaitik" getestet...?

 

libsecp256k1

 

Im Core auf Hilfe | Debugfenster und unter Hinweis - Allgemein lesen.

 

Ich denke mal, das ist nur fehlende Dokumentation.

 

Muss ich in die bitcoin.conf etwas eintragen, um Tor zu benutzen?

[Christoph Bergmann]

Es gibt und gab nie einen Grund für weltweiten Konsens aller Beteiligten. Bitcoin ist ein 51% Hashingpowermajority-Wahlrecht. Von Anfang an.

Schön wär's --

 

Leider (zum Glück) stirbt eine Blockchain recht zäh. Schau' dir mal den Auroracoin an. Der hat 51-Prozent-Angriffe abbekommen, einen Time-Warp, wurde in mehrere Chains geforkt - und es gibt ihn immer noch.

 

Wenn wir den Bitcoin forken, wird vermutlich auch der alte coin weiterleben. Wenn 99,9% der Miner - bzw. jeder Asic - die neue Fork mined, dann kann es sein, dass die alte Fork einfriert, weil es hundert Jahre dauern wrüde, bis sich die Difficulty anpasst. Aber an sich kann es durchaus sein, dass eine zweite Bitcoin-Blockchain weiterlebt und eventuell auch einen eigenen Wert hat. Dann haben wir eine gewisse Double-Spend-Problematik, da man Coins von der einen auf die andere Chain doublespenden kann.

 

Daher denke ich, dass eine 51%-Fork extrem gefährlich wäre.

[Axiom0815]

 

Muss ich in die bitcoin.conf etwas eintragen, um Tor zu benutzen?

 

Ja, am besten machst Du Dir für TOR eine zweite bitcoin.config. Nennen wir sie mal bitcoin.conf2.onion.

...
  
# ---ab hier für TOR ------------------------------------------------------------------ 
proxy=127.0.0.1:9150				#proxy (Tor Browser)
listen=1					#Eingehende Verbindungen annehmen
torcontrol=127.0.0.1:9151 			#Zu benutzender TOR Kontrollport wenn 
                                                #Onion Auflistung aktiv ist
onlynet=onion 					#Nur zu Knoten des Netzwerktyps <net> 
                                                #verbinden (ipv4, ipv6 oder onion)
proxyrandomize=1 				#Zufällige Anmeldedaten für jede 
                                                #Proxyverbindung verwenden. Dies aktiviert
                                                #Tor-Datenflussisolation (Standard: 1) 
listenonion=1				        #Automatisch versteckten Tor-Dienst 
                                                #erstellen (Standard: 1) 

# Onion nodes
addnode=2j2hz4zbuedcntub.onion:8333
addnode=2zdgmicx7obtivug.onion:8333
addnode=3ffk7iumtx3cegbi.onion:8333
addnode=3hshaantu6ot4upz.onion:8333
addnode=3lxko7l4245bxhex.onion:8333
addnode=4crhf372poejlc44.onion:8333
addnode=5at7sq5nm76xijkd.onion:8333
addnode=5ghqw4wj6hpgfvdg.onion:8333
addnode=5k4vwyy5stro33fb.onion:8333
addnode=77mx2jsxaoyesz2p.onion:8333
addnode=7g7j54btiaxhtsiy.onion:8333
addnode=7iyfdkr72hgtdjoh.onion:8333
addnode=b2ykuvob44fn36wo.onion:8333
addnode=bcb2tjvmui4p4bpf.onion:8333
addnode=bitcoin2rajdbpny.onion:8333
addnode=bitcoin625tzsusi.onion:8333
addnode=bitcoincfqcssig5.onion:8333
addnode=bitcoinostk4e4re.onion:8333
addnode=bk5ejfe56xakvtkk.onion:8333
addnode=blxbv6hlwofkuwiw.onion:8333
addnode=bmutjfrj5btseddb.onion:8333
addnode=btc4xysqsf3mmab4.onion:8333
addnode=btcdatxubbzaw4tj.onion:8333
addnode=btcnet3utgzyz2bf.onion:8333
addnode=by4ec3pkia7s7wy2.onion:8333
addnode=czsbwh4pq4mh3izl.onion:8333
addnode=d2433q7bnshmwyb3.onion:8333
addnode=dhxkxk6fn6zplasy.onion:8333
addnode=dioq2yg3l5ptgpge.onion:8333
addnode=dqretelgl3kjtzei.onion:8333
addnode=drp4pvejybx2ejdr.onion:8333
addnode=e3tn727fywnioxrc.onion:8333
addnode=e7zgwdjbzwt4cfj4.onion:8333
addnode=evolynhit7shzeet.onion:8333
addnode=gb5ypqt63du3wfhn.onion:8333
addnode=go2wkyflxur5leym.onion:8333
addnode=h2vlpudzphzqxutd.onion:8333
addnode=hhiv5pnxenvbf4am.onion:8333
addnode=hkxy4jpeniuwouiv.onion:8333
addnode=i2r5tbaizb75h26f.onion:8333
addnode=iksneq25weneygcj.onion:8333
addnode=it2pj4f7657g3rhi.onion:8333
addnode=jxrvw5iqizppbgml.onion:8333
addnode=k22qrck6cetfj655.onion:8333
addnode=khrx2h3r2yux5ntp.onion:8333
addnode=kjy2eqzk4zwi5zd3.onion:8333
addnode=lazsruhzupsgpvwm.onion:8333
addnode=lrkxsickfjnusslh.onion:8333
addnode=lzxpkn6ptp3ohh63.onion:8333
addnode=msphsgfiqfq5stne.onion:8333
addnode=mtzcz5knzjmuclnx.onion:8333
addnode=nkf5e6b7pl4jfd4a.onion:8333
addnode=nns4r54x3lfbrkq5.onion:8333
addnode=okdzjarwekbshnof.onion:8333
addnode=plq4fgyit3bal2ms.onion:8333
addnode=pqosrh6wfaucet32.onion:8333
addnode=pt2awtcs2ulm75ig.onion:8333
addnode=q6him22vxrpflsw3.onion:8333
addnode=rlgktll62klm6jhs.onion:8333
addnode=sjdomi4yb2dwkjbc.onion:8333
addnode=syix2554lvyjluzw.onion:8333
addnode=szsm43ou7otwwyfv.onion:8333
addnode=td7tgof3imei3fm6.onion:8333
addnode=tfu4kqfhsw5slqp2.onion:8333
addnode=u2o3yfzcxbitcoin.onion:8333
addnode=ukronionufi6qhtl.onion:8333
addnode=uvwozwxlihntigbb.onion:8333
addnode=v6ylz45dn5ybpk4d.onion:8333
addnode=vk3qjdehyy4dwcxw.onion:8333
addnode=vqpye2k5rcqvj5mq.onion:8333
addnode=vso3r6cmjoomhhgg.onion:8333
addnode=wpi7rpvhnndl52ee.onion:8333
addnode=xdnigz4qn5dbbw2t.onion:8333
addnode=xudkoztdfrsuyyou.onion:8333
addnode=xyp7oeeoptq7jllb.onion:8333
addnode=ymnsfdejmc74vcfb.onion:7033
addnode=z3isvv4llrmv57lh.onion:8333
addnode=z55v4ostefnwfy32.onion:8333
addnode=zy3kdqowmrb7xm7h.onion:8333

Dann mit bitcoin-qt.exe  -conf=bitcoin.conf2.onion starten.

 

Die Kommentare sollten selbst erklärend sein. Tor Browser ist unter www.torproject.org zu bekommen.

 

Eine aktuelle Liste der TOR Nodes findet man unter http://btcnodes.org/tor.

 

Axiom

Edited February 25, 2016 by Axiom0815

[...]

Schön wär's --

 

Leider (zum Glück) stirbt eine Blockchain recht zäh. Schau' dir mal den Auroracoin an. Der hat 51-Prozent-Angriffe abbekommen, einen Time-Warp, wurde in mehrere Chains geforkt - und es gibt ihn immer noch.

 

Wenn wir den Bitcoin forken, wird vermutlich auch der alte coin weiterleben. Wenn 99,9% der Miner - bzw. jeder Asic - die neue Fork mined, dann kann es sein, dass die alte Fork einfriert, weil es hundert Jahre dauern wrüde, bis sich die Difficulty anpasst. Aber an sich kann es durchaus sein, dass eine zweite Bitcoin-Blockchain weiterlebt und eventuell auch einen eigenen Wert hat. Dann haben wir eine gewisse Double-Spend-Problematik, da man Coins von der einen auf die andere Chain doublespenden kann.

 

Daher denke ich, dass eine 51%-Fork extrem gefährlich wäre.

Es ging einfach nur um das Prinzip. Das Wort "Konsens" wird im Zusammenhang mit Bitcoin gefaehrlich missbraucht.

[4ley]

Leider (zum Glück) stirbt eine Blockchain recht zäh. Schau' dir mal den Auroracoin an. Der hat 51-Prozent-Angriffe abbekommen, einen Time-Warp, wurde in mehrere Chains geforkt - und es gibt ihn immer noch.

 

Ein paar interessante Gedanken zum 51% Angriff https://youtu.be/yQGQXy0RIIo?t=21m57s