rico666cz

Sind meine BTC (noch) sicher?

Wie werden sie sicherer gemacht?

Kann das BTC-Ökosystem durch all dies (LBC) gefährdet sein? Und ab wann (zeitlich gesehen)?

Ja, Deine BTCs sind prinzipiell noch sicher - ungefähr so sicher wie Deine Rente, vielleicht sogar noch sicherer.

Momentan ist die sicherste Vorgehensweise GAR NICHTS zu machen (wer anfangen sollte hektisch seine

BTCs auf viele Adressen zu splitten läuft eher Gefahr irgendwas zu vermasseln und rein rechnerisch

erhöht er das Risiko für einen Fund. rechnerisch - nicht praktisch)

Riesige Beträge auf einer BTC Adresse halten sollte man eh nicht - unabhängig vom LBC.

Da muss jeder wissen wo für ihn die Grenze ist.

Sollte irgendwann durch den LBC das BTC Ökosystem gefährdet sein, würde ich mit Vorlauf

Bescheid geben, oder den Not-Aus Knopf drücken.

Also, wie oben von fjvbit gesagt: "Alles ist gut, keine Gefahr".

Rico

Genau gesagt ECDLP mit der Babystep-Giantstep Methode.

Für #52 würde es ca. 12 Minuten und 1GB Speicher brauchen. Die zwei Fällle ergeben sich, weil ich das Vorzeichen des Babysteps nicht überprüfe (baue ich vielleicht später ein).

 

Aber ob ich 20 Minuten response-time schaffe ist unwahrscheinlich    Nur wenn ich zufällig online bin, die Nachricht rechtzeitig sehe und den Laptop bereit habe.

Viel länger kann ich aber nicht warten mit der Veröffentlichung, Abgesehen muss dann die Transaktion schon laufen, bevor Du den privkey bekommst.

Was die Laufzeit anbelangt: Vielleicht könnte ich es ja schneller machen? 

Oder gar eine OpenCL Fassung? (wobei sich da EC traditionell etwas spreizt)

Rico

...so viele Hashes zu berechnen.  Public Keys zu berechnen ist zwar 100-1000 mal auwändiger, aber das lassen wir mal kurz außer acht.

Darauf möchte ich noch kurz zurückkommen. Der aktuelle LBC Generator (die CPU Version, nicht die GPU Fassung)

braucht auf meinem Notebook für 16,7M Keys (= 2 x 16,7M Adressen) aufgerundet stolze 19 Sekunden (pro Kern).

Davon entfallen 3 Sekunden auf die pubkeys und 16 Sekunden auf die 2 SHA256 + 2 RIPEMD160.

Die GPU Fassung braucht 3 Sekunden für Alles...

Rico

Wenn ihr #52 gefunden habt, kannst du ja mal den public key (im Format "028c6c67bef9e9eebe6a513272e50c230f0f91ed560c37bc9b033241ff6c3be78f") schicken, ohne den private key zu verraten.

 

Ich würde gerne mein kleines C-Programm testen:

...

Nein, keine Monstermaschine, nur mein zwei Jahre alter Laptop mit Core-i5 Prozessor und ohne angeschlossenes Netzteil.  Das Programm funktioniert aber leider nur, wenn man den public key hat, der hash reicht nicht  .

Oha? Ein EC^-1 ? So richtig?

Jedenfalls spannend. Für #52 bitte ca. 1 Monat gedulden - wir haben noch etwas Suchschuld abzuarbeiten.

Aber auch wenn die Suchrate etwas runtergeht - über 30 Tage sollte es nicht werden.

(edit: meine Antwort sollte natürlich implizieren: ja - natürlich bekommst Du von mir den pubkey vorab

und ich hoffe, ich bekomme dann innerhalb von ... 20 Minuten? Eine von N privkey-Alternativen für N < 10)

Rico

Speichern ist nicht nötig, siehe https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012204.html

Benötigt 4-fachen Rechenaufwand, aber dafür nur ein paar 100 byte Speicher.

 

nicht parallelisierbar: Das ist zwar richtig, aber mit Parallelisierung wird es nicht 2^53-mal schneller

Wie kommst Du jetzt auf 2^53? ;-)

(halb-rhetorisch um auf Deinen Rechenfehler aufmerksam zu machen, den Du natürlich zur

Grundlage weiterer Überlegungen machst.)

Es gibt auf jeden Fall einen guten Anhaltspunkt über die Kosten für 2^86 Hashes.

Ich habe doch explizit geschrieben: "Rhetorische Frage - keine Antwort notwendig"

Rhetorische Fragen des Gegenüber sind dazu da, dass man über die Sache nachdenkt, ergo ein wenig in sich geht. Und so...

Was machst Du? Du wechselst flugs die Kategorie. Nun ist es nicht mehr die Zeit (Billionen Jahre), sondern die Kosten.

Ja was nun? So diskutieren hysterische Weiber (oder wie ich immer sage: Argumentationskette wie ein Flohzirkus).

Mein Punkt war, dass Du durch die Angabe mit "Billionen Jahre" den Hauch der Unmöglichkeit deutlich machen möchtest. Ich wollte dagegenhalten, dass die Hashkapazität - lass es in 4 Jahren sein (aber vermutlich früher) - doppelt so hoch sein wird. Ha! 500 Milliarden Jahre gespart! In 4 Jahren! Magie!

Ich erlaube mir auf die anderen Sachen gar nicht erst einzugehen, weil eine Implikationskette nunmal ab der ersten Fehlimplikation wertlos ist.

Aber ich finde es gut, wenn ausführlichst dargestellt wird, warum dieses Projekt eigentlich

unmöglich ist, haben wir später mehr zu lachen. In der Zwischenzeit freue ich mich über den

Fund von #51.

Rico

Es geht bei LBC nicht um eine Kollisionsattacke, sondern eine Preimage-Attacke.  Auch wenn der Name anderes vermuten lässt.  

Es geht um gar keine Attacke, es geht darum eine Kollision zu finden. Aber wenn jemand unbedingt sehen möchte wie ich eine Attacke fahren würde, dann kann ich mich dem auch mal für 6 Monate widmen.

Wenn ich die Wahl habe 2^133 Schlüssel ausprobieren praktisch ohne Speicherbedarf und 100% parallelisierbar, oder 2^80 hash160 zu erzeugen und zu speichern(wie ?) und dadurch der Parallelisierbarkeit weitestgehend verlustig zu gehen, wähle ich ersteres.

Das Beispiel mit dem Bitcoin-Netzwerk ist ja formal nicht falsch und dennoch ein ganz schlimmer Selbstbetrug (den im übrigen 99,9999% aller "Experten" begehen).

Ich frage mal ganz naiv - in anbetracht der Billiardzichtillionen Jahre - wie viele Jahre hat das Bitcoin-Netzwerk zum Aufbau dieser Mining Power gebraucht?

Rhetorische Frage - keine Antwort nötig.

Rico

Die Bitbreite von 160 ist unumstritten (https://www.coinforum.de/topic/4003-wie-ist-eine-offline-paperwalleterstellung-möglich/page-2#entry65913), aber es ist eben auch diese Breite systematisches durchprobieren...

Der referenzierte Artikel ist ja ziemlich falsch. Was du als public key bezeichnest, ist der hash160.

Der public key hat (uncompressed) 512bit, bzw. 256 bit (compressed).

Erst das wird durch den RIPEMD160(SHA256(public key)) gejagt und man bekommt den hash160 mit 160bit Entropie.

Ein wenig mehr Sorgfalt bei der Nomenklatur emfehle ich (multi-key statt multi-sig habe ich ja noch durchgehen lassen

aber das wird langsam zu bunt)

Mit der Motivation, paar Fundstücke im Suchbereich zu legen, könnte noch eine Zeitlang Mitspieler bei der Stange bleiben.

Aber wie im richtigen Leben, beim Mining, verursacht es auch Kosten. Wenn es dann langweilig wird und mehr Kosten als Gewinn raus kommt, sollte sich die Begeisterung bei der Mehrzahl legen.

Immer her mit den Prognosen. Ist Mangelware heutzutage. Mining = richtiges Leben. *daumen-hoch-emoji*

Sonst Kryptografisch, RIPEMD-160 ist aus den Jahre 1996, also ein altes Eisen. Damals nur

als zusätzliche Sicherheit zu SHA256 mit zugenommen. Sollte es zu wirklichen technischen Fortschritten

kommen, könnte man den Code komplett überarbeiten, oder eben "nur" auf SHA512 / RIPEMD-320 umsteigen.

Den Hardrock macht dann jeder mit, wenn es ernsthafte Drohungen mit LBC gibt.

Ich sage ja immer jedem, dass der LBC keinesfalls eine Bedrohung für Bitcoin ist. Zwar wäre der Umstieg auf einen neuen

Adresstyp m.E. wünschenswert, aber nicht so ohne weiteres möglich - erstmal bräuchte es da ein entsprechendes BIP, dann

verstehe ich nicht, warum man sich wieder ein Folding würde antun wollen tun (512 -> 320 bit), aber das mögen

irgendwelche Coredevs auskarteln.

Was ich stark bezweifle, dass "verlorene Adressen" einen entprechenden Umstieg mitmachen würden und ich

bezweifle auch, dass sich ein Konsens fände diese Adressen zu invalidieren. Im "schlimmsten" Fall also, würde

der LBC alte (verlorene) Adressen recyclen.

PPS: Vielleicht ne neue Grafikarte? https://www.amazon.de/HPE-NVIDIA-Tesla-Dual-Module/dp/B00TWFEIWA

Neu? K80 bah... haben wir etliche im LBC laufen - viel zu alt, viel zu lahm.

Der neue Generator läuft da auch nicht drauf, stiefmütterliches Nvidia OpenCL.

Wenn schon, dann eine Maxwell oder besser noch Pascal GPU - am besten im Verbund

mit einer AVX512-fähigen CPU.

Rico

 

Schön zu hören, dass ihr die Zeit als Größe noch nicht verstanden habt.

Jede Putzfrau ist da klüger, weil eben über die frische gewischten Böden wieder Leute laufen.

Wer denkt, ein Hochhaus "systematisch" von oben nach unten durch zu wischen und dann ist alles fertig, sollte sich mal auf ein U- oder S-Bahnhof stellen und Dynamik verstehen lernen.

 

In Eurer Software geht ihr nur von Single-Keys aus, richtig? Was ist mit den Multi-Keys-Adressen?

Schon klar, dass Du nach meinem Seitenhieb ein wenig hippelig reagierst. 

Das Thema Zeit - insbesondere das Nutzen von Adressen nach der LBC Suchfront haben wir bereits im deutschen bitcointalk.org Forum durchdiskutiert - vor geschätzt 4-5 Monaten. Habe ich jetzt keine Lust das nochmal auf Putzfrauen-Niveau durchzukauen.

Die hash160 von Multi-Key Adressen suchen wir seit neuestem auch (en-passant ohne Zeitverlust), aber das knacken selbiger machen wir mal eben zum Nachtisch wenn wir welche gefunden haben. Schliesslich ist ja so eine P2SH praktisch überhaupt nicht gegen Brute-Force abgesichert sobald man den privkey zum betreffenden hash160 hat.

Rico

Das ist ja irre spannend.

 

Steigt die Wahrscheinlichkeit von Treffern mit der Anzahl verwendeter Adressen, oder ist das irrelevant?

 

Was ist die "Puzzle"-Transaktion? Habt ihr die selbst gebaut, oder ist das eine spezielle Transaktion, die ihr angreift?

Wird noch spannender. Der Pool hat heute Nacht seinen dritten Fund gemacht. Details folgen bald.

Die "Puzzle"-Transaktion ist nicht von uns. Da hat vermutlich jemand ein "Frühwarnsystem" aufgestellt.

Ich vermute in weniger als zwei Wochen werden wir #51 gefunden haben (https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS)

und wir greifen die nicht an. Die liegt einfach nur auf dem Weg. Näheres dazu ist hier zu finden:

https://bitcointalk.org/index.php?topic=1306983.0

Die Trefferwahrscheinlichkeit steigt natürlich mit der Anzahl der verwendeten Adressen. Doppelt so viele Adressen - doppelt so hohe Trefferwahrscheinlichkeit.

Aber ich möchte gleichzeitig beruhigen: Ich selbst habe natürlich Bitcoins und sehe noch keine Veranlassung die irgendwo panikartig anderweitig zu deponieren. Erstens wüsste ich nicht wohin, zweitens sind die Wahrscheinlichkeiten so gering, da ist die Gefahr beim BTC-Transfer durch irgendeinen Fehler BTCs zu verlieren millionenfach höher.

Rico

Habe ich das richtig verstanden, dass der LBC den Suchraum von systematisch "unten" (kleine/kurze private keys, wenig Bit) nach "oben" durchsucht und somit zuerst Ausgänge findet, die mit einem kleinen private key verwendet werden können?

 

Es könnte sein, dass die zwei "echten" Adressen von Irgendjemandem beim Rumspielen/Testen/Sonstwas (un)absichtlich mit einem kleinen private Key generiert wurden. Dann hätte der LBC keine Kollision, sondern exakt den zur Generierung verwendeten Key gefunden. Richtig? Ist dieses Szenario nicht deutlich nahe liegender, als die Vermutung, dass es sich um eine Kollision handelt?

 

Da es extrem unwahrscheinlich ist zufällig einen so schlechten Key zu generieren, muss man sich als 'normaler Nutzer' demnach (noch) keine Sorgen machen, dass seine Adressen durch den LBC "geknackt" werden. So würde ich das jedenfalls interpretieren, sofern ich das alles richtig verstanden habe...

Die "Experiment"-Hypothese gibt es natürlich, wobei diese genauso unbewiesen ist wie die "Kollision nur fehlt uns der 'Originalschlüssel' zum Beweis"-Hypothese.

Momentan haben wir nur Indizien die mal die eine, mal die andere Hypothese stützen. Ergo: Wir sind momentan so schlau als wie zuvor. 

Die Adressen sind nicht irgendwie als Experimental-Adressen auffällig. Im Gegenteil, beide sehen wie reguläre Changes aus.

Die Wahrscheinlichkeit für eine Kollision ist gering, aber die Wahrscheinlichkeit zweimal exakt den Originalschlüssel zu treffen ist mit 1/(2⁹⁶)² auch nicht ohne.

Die Vorstellung "kleine kurze Schlüssel" seien "ganz weit weg" von "guten langen Schlüsseln" ist wegen Kollisionen eben falsch.

Zahlen stimmen nun nicht, aber es spricht prinzipiell nichts dagegen, dass

0000000000000000000000000000000000000000000000000005c3aaf3f00001   (kurzer "schlechter" Key)

in den gleichen hash160 zeigt wie

8724876a87f87e8768d780c002378abe28494323259879bc6c6e7887f2a0021a    (langer "guter" Key)

(am Rande sei bemerkt das Copy&Paste in den WYSIWYG-Editor hier mächtig schei*e ist)

Warum? Durch den sog. Avalanche-Effekt sowohl der sha256 wie auch der ripemd160 Funktionen der eben besagt, dass 1 bit Änderungen in den Eingangsdaten gut 50% der Bits in den Ausgangsdaten flippen sollen. Das ist eine gewollte Eigenschaft guter Hashfunktionen.

Bedeutet aber in letzter Konsequenz: Es gibt keinen numerischen Sicherheitsabstand!

Rico

wenn nur einmal getestet wird, ist es doch für die Zukunft relativ egal...

Kommt darauf an. Manchmal sucht einer auch den bereits abgegrasten Suchraum nochmal ab:

Siehe z.B. auf https://lbc.cryptoguru.org/trophies

die Passage "2016-10-20 15:00:00 GMT

A manual revisit of the 38-42 bit search space revealed these private keys..."

< 2^50 würde ich niemals Bitcoins ablegen bei 160 Bit echte Länge...

Natürlich nicht. Das Thema hatten wir auf bitcointalk.org. Gegen den LBC wäre wohl ein Schlüssel im Bereich 2^159 + rand(2^158) am besten.

Denn Sinn von diesem "Pool" verstehe ich nicht so ganz. Es ist so etwas wie Schnitzeljagt?

Erst werden Bitcoins in einem bestimmten Bereich "versteckt" und dann gesucht?

Sind schon mal 2 verschiedene keys für eine Adresse gefunden worden?

Eine Schnitzeljagd veranstalten wir ab und zu, damit uns nicht langweilig wird. Dann gibt es ja noch die Puzzle transaction als globalgalaktische Schnitzeljagd.

Ansonsten geht's schon hart zur Sache: Gefunden werden kann prinzipiell der Zugriff zu jeder Adresse. Mit übersichtlicher Wahrscheinlichkeit - da hast Du schon recht.

2 Verschiedene Keys für 1 Adresse: Nein - bislang noch nicht, da wäre sicher ein größerer Rummel nicht zu vermeiden. Wir arbeiten daran.

Allgemein zum Sinn vom Pool: Wenn man wüsste, was der schon so an Erkenntnisgewinn und technologischen Nebenprodukten abgeworfen hat, würde man sich die Sinnfrage nicht stellen.

Bevor jetzt wieder die "unschuldige Frage" Was denn? kommt: Zu viel in den letzten 6 Monaten um es hier in annehmbarer Zeit niederzuschreiben.

Rico

Detailiertere Funktionsweise siehe hier  https://lbc.cryptoguru.org/man/theory

Es wird einmal getestet (selten zweimal - wenn sich die Clients gegenseitig überprüfen) und fertig.

Theoretisch könnte man also Bitcoins auf einem Privatkey < 2⁵⁰ ablegen, aber das wäre unklug, da wenig Entropie.

Allerdings hat kein Privatkey eine höhere Entropie als 160bit. Leider. Ist so. Siehe auch den Link warum.

Jetzt schauen wir erstmal, dass der neue GPU client an die Leute rausgeht (wesentlich schneller als oclvanitygen), und dass wir endlich bald #51 finden (https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS) - in weniger als 1 Monat sollte es ja soweit sein.

Rico

was meinst du damit, warum machen Privkeys keinen Sinn?

Privkeys alleine suchen macht keinen Sinn, weil man ja dann nicht weiß

ob der Suchraum nicht bereits von jemandem abgegrast worden ist und Du somit 0% Chance hast etwas zu finden. 

Rico was genau willst du mit Deinem Post genau aussagen?

 

ich verstehe es nicht...

Ok, dann so:

• Ja, der LBC hat zwei "echte" Adressen mit BTCs drauf gefunden (Nein, eine Kollision wurde noch nicht bewiesen)
• P2PSH ist nicht sicherer als P2PKH
• Es gibt in der LBC Software keine Viren/Trojaner/Malware/Adware/... (Liste hinreichend aber nicht vollständig)
• Privkeys alleine suchen macht überhaupt keinen Sinn

und als Bonus

• kleiner Seitenhieb auf Axiom0815

Rico

Du kannst davon ausgehen, dass dann ein viel größerer Rummel um die Sache gemacht worden werde.

Nö - warum? Understatement ist doch cool. 

Mit ein bisschen Werbung und den Versprechen, man könne den Fund für sich behalten, kapert die Gier den Verstand und viele "kleine Leute" spendieren ihre Rechnerleistung und holen sich Software darauf, wo sie nicht wissen, was die wirklich macht.

Logisch wäre, wenn ich was finde ist es meins allein, dass ich dann auch alleine suchen kann ohne die andern.

Es gibt zwar mehrere axiomatisch fundierte und konsistente Logiken, aber Deine gehört nicht dazu.

Klar kannst Du alleine suchen, aber noch schlimmer als beim Solo-Mining weisst Du hier nicht, ob der Suchraum nicht bereits von jemandem abgegrast worden ist und Du somit 0% Chance hast etwas zu finden. Der LBC Pool stellt ja genau sicher, dass nicht Arbeit doppelt gemacht wird.

Ergo werden da auch nicht irgendwelche Privatkeys zufällig ausgekotzt, sondern man läuft systematisch durch.

Die Software macht genau das was draufsteht: Sie generiert so schnell es geht aus privkeys aus einem bestimmten Bereich hash160 und gleicht diese gegen alle Adressen ab auf denen Unspents sind. Im Übrigen auch P2SH. Weiterhin im Übrigen sind P2SH nicht sicherer als P2PKH, siehe

 https://bitcointalk.org/index.php?topic=1581701.msg16344155#msg16344155

So viel zu Deinem "fast unendlich ³"  - der Brüller.

Die Software braucht zu ihrem Betrieb weder irgendein privaten Key von Dir, noch eine wallet.dat noch eine Blockchain auf dem Rechner. Installier' das auf einem nackten System oder sonstwie.

Ich finde es gut, wenn Du einen Thread startest und Dich mit dem Thema beschäftigst, aber bevor Du weiter im Trüben stocherst - frag doch jemanden, der sich mit sowas auskennt. 

Rico

Wenn man noch mit CPUs nach Bitcoins minen(*) möchte, dann das hier:  http://lbc.cryptoguru.org:5000/about

Rico

(*) nicht 100% ernst gemeint

Kann man diese Themen nicht irgendwie locken oder so?

Nachdem nun die mupool.com domain ja mittlerweile zum Verkauf steht...

Rico

Regelmäßiger Passwort-Wechsel wird von vielen Experten empfohlen, hier z.B. vom BSI:

https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/Umgang/umgang_node.html

Gibt auch andere Stimmen

https://www.projekt29.de/datenschutzblog29/ist-haeufiger-passwortwechsel-wirklich-sinnvoll

Ich halte diesen erzwungenen Passwortwechsel für Banane, mein Passwort war gut. Ich habe es jetzt durch ein schwächeres ersetzt. Aus Trotz. Dem Möchtegern-IT-Experten-Azubi vom Coinforum zeig' ich's! 

Rico

Ich würde Kraken als seriös aber technisch inkompetent bezeichnen.

Die GUI ist ein Graus (sowohl Geschwindigkeit wie auch Ergonomie), wenn das Handelsvolumen mal über die Informationsmenge einer schreienden Kindergarten-Klasse hinausgeht, macht das Backend die Grätsche.

Naja - man kann dann schon vom Support einen Transaktions-Gutschein ergattern (nachdem diese blauäugig meinten ein "Sorry" sei ausreichend). Aber die 1000 Krakengroschen (ca. 10 EUR)... naja

Aber um wieder etwas zu der OP-Frage zurückzukehren:

Man muss bei Kraken keine Angst haben, dass sich da eine schattige Truppe im Zweifelsfall mit den dort gelagerten Funds auf und davonmacht. Auch glaube ich, dass ein heist vermutlich besser gemanaged würde als z.B. bei Bitfinex.

Wovor man bei Kraken aber definitiv Angst haben muss, ist, dass einem die Orders nicht durchgehen, wenn die Märkte mal etwas hektischer werden. Da dies aber aus Trader-Sicht auch als Verlust anzusehen ist... naja siehe oben. seriös aber inkompetent.

Rico

Hallo,

 

wer noch schnell ein paar BTC loswerden möchte bevor sie nix mehr wert sind ;-)

...

Die BTC werden nicht in Euro getauscht sondern kommen auf mein kleines "Sparbuch für die Rente".

Hä? Dann sind die doch aber nix mehr wert?

Warum stiert mich eigentlich auf  ripple.com der Fidor Verrätergnom an? ;-)

Rico

Ich hatte es im November krachen lassen und bei KnC einen Stapel Jupiters gekauft, nach dem Motto "Mein Server macht mit seiner CPU 20 MH/s - ich brauche 1 Million mal mehr".

Die haben so 40 Tage lang gemined und wurde nnun stück für Stück noch mit Gewinn abverkauft. Einige goldene Exemplare (680+ GH/s - alle Cores funktional) die mir ans Herz gewachsen sind habe ich behalten, mal schauen , vielleicht kann man die noch übertakten.

Ansonsten mine ich momentan Scrypt - das ist so richtig Hardcore.

Rico

Diese Fakeseite müssen die Bitcoiner schon vor Wochen entdeckt haben, deshalb auch der Hinweis auf das grüne "Verified by"-Symbol in der Browseradresszeile.

Wundert mich, dass die Seite dann noch up ist. Ich meine Sonst sind die Strafverfolgungsbehörden auch so kompetent und schnell.

Oder jemand sagt der Polizei, die betreiben Steuerhinterziehung mit Bitcoins, dann ist die Seite innerhalb von 24h down :-)

Rico

So als Business Angel/Investor hätte mich das schon interessiert,

und dass man für die Frischlinge eine Bezahlung in EUR anbietet

ist auch verständlich, dass man aber die Konferenzgebühr nicht in BTC

bezahlen kann ist ein No Go.

Klar habe ich auch denen direkt ein Feedback geschickt, aber es ist Sonntag

und ich musste mich auch hier auskotzen.

Rico

Damit will ich nur den Leuten hier Sicherheit geben, dass selbst bei einem derartigen (zeitweiligen)Absturz überhaupt nichts gefährdet ist. Immer langfristig betrachtet und vorausgesetzt, dass keine großen äußeren Störungen kommen.

Äußere Störungen werden von Tag zu Tag unwahrscheinlicher, nachdem Regierungen in den USA, China und D keine Hindernisse aufgebaut haben und die Akzeptanz des BTC wächst.

Das müsste man nun vielleicht etwas relativieren, denn das was in China abgegangen ist kann man wohl nicht mehr als "kein Hindernis" titulieren.

ad BB: Ja, wenn sich jeder daran hält funktionieren die gut. ;-)

Rico