wwurst

Der ganze Markt ist ja eh undurchsichtig (da steht er aber den klassischen Börsen nicht nach),. Interessant ist aber, dass Jihan Wu mit seiner Ankündigung, dass Bitmain Hasrate auf BCH-ABC werfen wird auch gleich einen Kurssturz des BTC unter 5000$ angekündigt hatte. Wäre das plausibel: das massive BCH-minen auf beiden Forks ist nicht kostendeckend (sondern eine "politische" Aktion), deshalb müssen die Miner ihre Bitcoins auf den Markt werfen um die Stromrechnungen zu zahlen?

@Jokin meines Wissens gibt's zur Zeit einen Lightning Node entweder direkt zusammen mit einem Bitcoin-Fullnode (da -txindex nötig ist geht das auch nicht mit -prune zusammen) , oder per neutrino o.ä. als Light Client, aber nichts "dazwischen".

Ah, danke, beim schlimmsten Feind hätte ich natürlich zu allerletzt gesucht 😉 😉 Is ja merkwürdig...

Dann frage ich nochmal, mit anderen Worten, dasselbe wie ein paar Posts weiter oben: wenn ich jetzt einen SV-Node betreiben wollte, wo finde ich dieses Update? Wie gesagt, ich bin wohl zu blöd - ich finde nur SV-Quelltext auf github, keine Ahnung ob und mit welcher toolchain ich den für Raspi oder Windows kompiliert kriege - jedenfalls nicht in fünf Minuten...

Auf die Gefahr hin, dass ich mich jetzt als völlig ahnungslos oute: mit was wird denn BCH-SV nach dem Hard Fork übermorgen gemined und genoded? Mit den alten pre-fork ABC/UL clients? Oder mit einem selbst compilierten SV-client 0.1.0 von github, wo ín letzter Zeit verdächtig wenig Aktivität und nichts über Tests zu lesen war? Habe ich einen SV-client für's Volk übersehen oder wird sich das alles nur zwischen Minern und Exchanges abspielen?

Ich habe jetzt mal versucht mich einzulesen. Habe ich was verpasst, oder gibt es heute (eine Woche vor dem Hardfork) fertige clients von ABC, BU, XT für die neuen Regeln, Von SV aber nur ein github mit sehr geringer Aktivität und dem sourcecode für eine ungetestete Version 0.1? Dann wird wohl erstmal geforkt , und da es soweit Einigkeit über die neuen Regeln und fertige clients gibt, wird das wohl am 15.11. ein sauberer Übergang ohne Split. SV müsste dann irgendwann später eingrätschen, oder?

Wer "ersetzt" denn irgend etwas? Das Lighning-Netz (und andere) ist ein Zusatzangebot. Jeder kann es sich, in jedem Einzelfall, raussuchen, ob er schnell und billig (und nicht ganz so sicher, und mit einem Zwischensystem) eine Currywurst kauft, oder ob er seine Lebensersparnisse direkt in die Blockchain schreibt.

Einen passenden "Schnauzer" gibt's noch nicht (für Nicht-Südtiroler: der tägliche Comic in den "Dolomiten"), aber der heutige (26.10.) Dilbert passt hier ganz gut. www.dilbert.com

meiner ist jetzt up: 17 Tage, 12:27h in dieser Zeit insgesamt: up 248 MB ; down 1600 MB (an DSL 50) hängt natürlich davon ab, wieviele neue Nodes sich bei dir eine komplette Blockchain besorgen - je besser deine Leitung ist, desto mehr werden das sein...

Halte ich grundsätzlich für einen guten Wég. Sicheres Passwort, das du dir aber merken kannst, und nicht an der Anzahl der Backups sparen - am besten gleich ein paar, an verschiedenen Orten. Geklaut, kaputt oder unauffindbar ist schnell mal einer oder zwei. Drei wären mein Minimum, mehr je nach Paranoia und dem Betrag um den es geht.

Kurzantwort: nein. Du brauchst einen Lighning-Node Im "zuständigen" Technik-Thread findest du mehr Informationen als du jemals haben willst ? https://coinforum.de/topic/11465-lightning-network-bitcoin/

Hallo zusammen, ich mache hier mal ein Thema für mein Problem auf. Bei mir läuft eps 0.15 mit bitcoind 0.17.0 und lnd 0.5 auf einem Raspberry Pi, installiert nach Stadicus' Anleitung https://github.com/Stadicus/guides Wenn ich jetzt mein Elektrum-Wallet auf dem PC mit meinem eps verbinde, dann wird eine der Transaktionen als "Status: local" angezeigt. Diese tx ist schon Monate alt und wird von allen Blockexplorern und öffentlichen Elektrum-Servern als korrekt und bestätigt mit dem richtigen Datum angezeigt. Das bitcoind update auf 0.17.0 hat schon einen blockchain reindex ausgeführt, Neustarts gab es mehr als genug... Fällt euch sonst noch etwas ein, was ich probieren könnte um das Problem einzugrenzen? Den Raspi hatte ich neu aufgesetzt, in einer früheren Inkarnation (eps 0.12 und bitcoind 0.16.0) gab's dieses Problem noch nicht.

Roger Ver macht genau das, was (er glaubt dass es) ihm und seinen Firmen/Investments hilft. Das ist nicht verwerflich. Und es spricht für Bitcoin, dass es auch gegen solche massiven (weil gut finanzierten) Angriffe bisher widerstandsfähig ist. Peinlich ist halt, dass Roger, wie in dem verlinkten Video, gerne "populistische" Phrasen drischt, wenn er nicht Crypto-Anfängern, sondern gestandenen Profis gegenübersitzt. Mal ganz abgesehen davon, dass der "Roger Ver" - Lightning - Knoten ohne Verbindungen ein Witz war - selbst in echt wäre er kein "Beweis" , das "das Lightning-Netz" einzelne Benutzer zensieren könnte. Knoten sind pseudonym, und es ist eine individuelle Entscheidung jedes Teilnehmers, mit wem er verbunden sein will und mit wem nicht, da gibt es keinen netzweiten Zensurmechanismus. Das kann man einem Einsteiger auf reddit als Werbespruch für BCH auftischen, es in einer Diskussion mit einem Profi wie Charlie Lee wieder und wieder hochzukochen ist tatsächlich nur peinlich, und Charlie kann ich für seine Selbstbeherrschung nur bewundern...

@Christoph Bergmann wofür genau suchst du denn die Anleitung? Für den (nicht mehr geflegten) Electrum Server genau wie für den aktuellen ElectrumX stehen doch Anleitungen bzw links auf den jeweiligen github-Seiten. https://electrumx.readthedocs.io/en/latest/ Und wie mann den "Personal" auf einem Raspi aufsetzt, steht in dem oben von mir verlinkten Stadicus-guide (hinten, bei den "Extras"), das sollte 1:1 auf jedem Ubuntu-ähnlichen Linux genauso gehen. Der Unterschied: ElektrumX bedient beliebige Adressen, die ihm aus dem Internet von Clients zugerufen werden. Der eps nur einen festen Satz (bei mir: meine eigenen) Adressen, das schafft ein Raspi grade noch.

Ja, da bin ich wieder. Habe meinen Node von Grund auf neu aufgesetzt, nach der aktuellen Anleitung von Stadicus. Das läuft jetzt runder, mit automatischem LN-Wallet-unlock, IP-Wechsel-Erkennung und so... https://github.com/Stadicus/guides/blob/master/raspibolt/README.md bitcoin core 0.17.3, lnd 0.5 und eps 0.15 Trotz mehrerer Versuche wollte lnd erst laufen, als ich mein ~/.lnd-Verzeichnis völlig geleert habe. (LN-Wallet natürlich vorher in Sicherheit gebracht), deshalb hat mein Node jetzt einen neuen pubkey. Noch ein paar Feinheiten, dann probiere ich wieder aus. Gibt's den recksplorer nicht mehr? (https://lnmainnet.gaben.win/) eps 0.13 hatte damals einwandfrei funktioniert, jetzt habe ich ein Problem mit einer tx, die korrekt in der Blockchain liegt aber von eps nur als "lokal" angezeigt wird. Macht hier noch jemand was mit Electrum Personal Server? Dann würde ich zu dem Thema mal einen neuen Faden aufmachen, hat ja direkt nichts mit Lighning zu tun...

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

http://www.spiegel.de/wissenschaft/mensch/chemnitz-krawalle-wie-man-nazis-erkennt-a-1225712.html

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

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.

@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...

@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.

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! ?

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....

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?

>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.