Jump to content

wwurst

Mitglieder
  • Gesamte Inhalte

    48
  • Benutzer seit

  • Letzter Besuch

Reputation in der Community

17 Good

Über wwurst

  • Rang
    Mitglied
  1. Vanitygen berechnet solche Adressen für dich. Leider nicht für Segwit-Adressen, keine Ahnung wie die Bitmexen das machen... https://github.com/samr7/vanitygen edit: egal, hier gibts auch einen für P2SH Vanity-Adressen https://github.com/kristapsk/segvan
  2. http://www.spiegel.de/wissenschaft/mensch/chemnitz-krawalle-wie-man-nazis-erkennt-a-1225712.html
  3. wwurst

    Stresstest BCH

    Sagen wir mal, bei "second layer payments eigentlich vermeiden möchte". Wenn man nicht grade ein Geschäftsmodell hat, dessen Ziel es ist, die dickste Spinne im LN zu werden 😉 Eine gute (englische) Zusammenfassung des LN-Routing-Problems: https://www.yours.org/content/the-lightning-network-routing-problem--explained-31e1ba7b38f5
  4. Dann haben entweder du oder ich da was gründlich missverstanden. Mein Verständnis: Der Node greift auf ein ganz normales , aber für diesen speziellen Zweck eingerichtetes Wallet (das "Lightning-Wallet", LW) zurück. 1. Dieses LW fülle ich, mit einer ganz normalen Blockchain-tx. 2. mit einem Teil des LW-Guthaben eröffne ich einen (oder mehrere) Channel, mit je einer Blockchain-tx Die spezielle Lightning-Implementierung LND hat ein "autopilot" Feature, das mir (stark verkürzt) automatisch ein paar Channels zu gut verbundenen Knoten im Lighning-Netz aufmachen kann. Das ändert aber nichts an der Funktionsweise dieser Channels: jeder braucht eine open- und irgendwann eine close-tx auf der Blockchain. Beim close landet das verbliebene Saldo im Channel wieder im LW. Das was du beschreibst, Channel zu und der Autopilot behält das Geld, wäre eine ziemlich einseitige Sache 😉 Das closen eines Channels über die Blockchain sorgt ja auch dafür, das Betrugsversuche und "Verwaisung" aufgelöst werden.
  5. wwurst

    Stresstest BCH

    @Jokin ganz ähnlich hatte Andreas Antonopoulos das in einem seiner Vorträge aufgebaut, und dann nochmal ein paar Größenordnungen dazugenommen, wenn die bisher "banklosen" Menschen in der 3.Welt dazukommen, und dann noch Mikropayments... Zigarettengeld transportiert man auch nicht im Panzerwagen, Kleinbeträge müssen nicht unbedingt in der Blockchain einbetoniert werden. Soweit die für mich schlüssige Begründung für 2nd-Layer-Lösungen wie Lightning. Und nie vergessen: aus Sicherheitsgründen muss Platz auf der Blockchain immer genug kosten, damit die Sicherheit der "verblockten" Werte gewährleistet bleibt. "Transfercoin" mit niedrigen Gebühren ist eine schwache Existenzberechtigung für BCH, das können ETH und LTC schon lange...
  6. @Jokin , eine tx (für alle Channels) auf die Lightning-Wallet, dann für drei Channels (von denen oben die Rede war) je eine open- (und irgendwann close-) tx . Deswegen funktioniert Lightning ja auch nur als Netz - würde man für jeden Kaffee einen eigenen Channel öffnen und wieder schließen dann wäre die Last auf der Blockchain sogar weit höher als bei einer direkten tx.
  7. wwurst

    Bitcoin Cash (BCH)

    Ich würde jetzt nicht das Niveau der reddit-Hysteriker zum Maßstab machen 😉 Das einzige Argument, das ich von BTC-Entwicklern gegen (sofort) größere Blöcke bei BTC gelesen habe, war daß es die technische Weiterentwicklung durch das nehmen der billigen Hintertür verlangsamen würde. Ganz so unrecht hatten sie ja nicht, utxo-committments sind ja jetzt die erste echte technische Neuerung, die zuerst bei BCH kommen könnte. Alles andere war ja, laut der Big Blocker, der sichere Tod von Bitcoin 😉 Vielleicht ist es Zeit für einen eher ironischen Rückblick auf die damalige Hysterie und was davon übrig blieb. Darum sollte sich die Journaille mal kümmern! 😉
  8. wwurst

    Bitcoin Cash (BCH)

    Danke, sehr interessant. Nur den letzten Satz verstehe ich nicht. Auf BTC-Seite wurde doch nie behauptet, größere Blöcke gingen nicht. Der Streit ging um die Reihenfolge: erst in das 1MB reinpressen, was technisch geht (BTC) oder erstmal größere Blöcke, um Druck vom Kessel zu nehmen (BCH). Ist denn die Codebasis der BCH-Clients inzwischen soweit von Bitcoin Core weg, daß man annehmen müßte, BTC würde mit größeren Blöcken nicht genausogut klarkommen? Segwit war ein nötiger Schritt auf dem Weg zu Schnorr-Signaturen (und damit massiven Effizienzgewinnen beim Überprüfen von Transaktionen) - denkt im BCH-Lager überhaupt noch jemand an so was? Bin schon zu lange weg von der Diskussion....
  9. wwurst

    Bitcoin Cash (BCH)

    Das ist ja genau das Horrorszenario der großen Miner. Der Block-Reward sinkt fest verdrahtet, auf fette Kurse der Reward-BTC ist kein Verlass, bleiben vor allem die Gebühren um die Stromrechnung zu zahlen. Nicht umsonst standen Bitmain/Jihan Wu voll hinter den "anderen" Skalierungslösungen wie BCH. Und aus Sicherheitsgründen will man ja auch als Anwender den Mining-Aufwand nicht ins Bodenlose fallen lassen. Da wird sich beim BTC ein neues Gleichgewicht finden müssen, das genug on-chain-Aktivität und damit Gebühren übriglässt. Eine nach Zeit oder Betrag limitierte Channel-Lebensdauer?
  10. wwurst

    Sicherheit - Notebook, Linux, virtuelle Umgebung

    >Das klingt nach viel Arbeit (einmalige Einrichtung) aber auch wirklich gut! Eher Einarbeitung als Einrichtungsarbeit - qubes installierst du von einem Stick wie andere Linux auch >Wie sieht es mit der Performance aus? Für 150€ erwarte ich auch heute nur ein sehr langsames "Office" Notebook? Das ist mein Crypto-Notebook, mit dem will ich keine Videos bearbeiten, WOW zocken oder minen 😉 für Libreoffice etc würde es aber locker reichen, ist ein i5m mit 2,6GHz >VMs sind doch sehr rechen intensiv? Nur wenn das Host-System die Virtualisierungsarbeit machen muss. Bei qubes macht das XEN auf Hardware-Ebene, Overhead ist fast Null. Nur RAM braucht halt jede, falls sie parallel laufen sollen - bei Crypto-Anwendungen passiert das eher selten. >Ich habe mich bisher dafür entschlossen das System jedes Mal neu aufzusetzen. Klar, das geht auch. Für mich war da auch die "sportliche" Herausforderung wichtig. Und ich brauche kein zweites cold/offline Notebook. >Da ich meine Wallets nur "einmalig" zur langfristigen Lagerung öffnen muss und ich den Bestand via Browser Checke (jede Währung hat ja diese Blockchain/Tangle Links im Netz), >benötige ich nichts mehr davon und kann das OS nach einmaligem Gebrauch "weg werfen". Naja, aber nach Hard Forks mit wallet-upgrades, Splits oder wenn du sonst mal an deine kalten Coins willst ("langfristig" ist ja anders als "für immer") fängst du von vorne an. Und ich irgendwo in der Mitte 😉 Aber das ist alles Geschmacksfrage. Wollte nur eine technisch mögliche Alternative vorstellen.
  11. wwurst

    Sicherheit - Notebook, Linux, virtuelle Umgebung

    Ich habe mir inzwischen einen gebrauchten Lenovo T420 für denselben Zweck besorgt. Mit RAM-Aufrüstung und Billig-SSD waren das so ca. 150€ Qubes OS 4.0 drauf und erstmal in das "etwas andere" System/Bedienkonzept eingearbeitet. Jetzt geht mir das flott von der Hand, für jede Kryptowährung (ggf sogar mehrfach) eine virtuelle Maschine, in der das jeweilige Wallet etc. installiert wird. Jede braucht nur soviel Plattenplatz wie die installierte Software, da alle vom System von einem gemeinsamen Template abgeleitet werden. Das ist bei mir Fedora 28, ist aber eigentlich egal, weil man normalerweise eh keinen Desktop der VM zu sehen kriegt sondern nur die gestartete Applikation selbst. Der Web-Browser etc. ist im Template, wenn der oder andere Basis-Software ein update kriegen, dann muß ich nur das Template updaten, nicht x VMs. Der große Vorteil ist die totale Isolation der VMs gegeneinander durch Hardwarefunktionen (VT-x und VT-d), man kann also auch mal das Wallet einer neuen, dubiosen shitcoin installieren (in einer eigenen VM) ohne daß man um seine Bitcoins fürchten müßte. Für jede VM kann man einstellen, ob sie über die normale Firewall ins Netz geht oder (via whonix) über TOR. Das ist alles in Qubes schon vorbereitet und geht mit einem Klick. Es geht sogar cold storage/offline wallets auf demselben Laptop: in einer VM, an die gar keine Netzwerkhardware "angeschlossen" ist. Angeblich soll auch Windows (ab 7x64) in einer VM laufen, aber das habe ich mir noch nicht angetan. Das Ganze ist nicht so handlich und anfängerfreundlich wie Trezor & Co. , aber mindestens so sicher, viel flexibler, und kaum teurer. Passt für mich.
  12. Aua... Auch dem Mailprogramm muß man beim Einrichten das Passwort zur Mailbox verraten. Von den anderen Ideen/Konzepten hier überzeugt mich bisher keines von meiner Lösung abzuweichen. Das mit der Sterblichkeit ist ja nun kein neues Problem der Menschheit, deshalb vertraue ich da auf die etablierten Prozesse um für tot erklärt zu werden. Und mit der Testamentseröffnung kriegen die Erben dann den Schlüssel für meine Kryptos, alle meine PC- und online-Passwörter, und eine Liste aller "normalen" Konten, Schliessfächer etc. (für die sie dann eh einen Erbschein brauchen).
  13. Bei mir gibt's ein Textfile mit allen wichtigen Infos, inc. denen zu Crypto-Wallets, das in einem VeraCrypt-Container steckt. Von dem Container gibt es x Kopien an verschiedenen Stellen (aber nicht beim Notar). Im Testament steht die Passphrase zum Container. Da kann keiner alleine, weder in meinem Umfeld noch beim Notar, schindludern. Und gegen ausgefuchste Kriminalität oder sogar geheimdienstliche Angriffe kannst du als Privatmensch eh nicht anstinken. Das mit den Totmann-Schaltern im Netz ist mir suspekt: wenn einmal auf einem der beteiligten Rechner das Datum nicht stimmt, oder sonst eine Software zickt, ist ruck-zuck der Schalter ausgelöst.
  14. Wenn man Zahlungen empfangen möchte, dann ja. Im use-case Handel also auf Seiten des Anbieters. Noch... (hoffentlich) Wer per Lightning nur bezahlen will, der zieht sich Eclair auf's Handy, füttert es mit Kleingeld und fertig.
  15. wwurst

    Handy schrott! und nu??

    Das mit dem Backup von 2FA-Daten auf dem Handy ist ein Kreuz... Geht eigentlich nur mit Tricks (root + Titanium Backup bei Android, zB) die einem dann aber wieder andere Probleme machen - root ist halt auch ein Sicherheitsrisiko. Ich nehme die portable Windows-Open-Source WinAuth. https://winauth.github.io/winauth/index.html Da kann ich dieselben Seeds wie im Google-Authenticator eingeben, und das Backup ist ein einziges, passwortgeschütztes File, das man gut verschlüsselt sichern/ausdrucken/etc kann. Ausserdem kann WinApp dann im Fall der Fälle als "Nachschlüssel" dienen, bis das neue Handy eingerichtet ist. Für linux gibts da oathtool / OmegaPhil , habe ich selbst aber noch nicht probiert
×

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.