Sollte man nicht mathematisch beweisen können, dass PoI funktioniert?
Ich bin nun nicht der größte theoretische Informatiker. Aber mein gefährliches Halbwissen sagt mir, dies müsste/sollte machbar sein.
--> Frage(n): Hat einen mathematischen Beweis (für PoI) niemand probiert bis jetzt?
Oder meinst Du mit "funktionieren", ob man in Praxi PoI so zum laufen und fehlerfrei bekommt, wie man geplant (berechnet?/bewiesen?) hat?
Da NIS noch nicht open source ist, ist auch der Quellcode zu POI nicht offen, eine Simulation/Berechnung ist daher zur Zeit nicht möglich. Man kann aber natürlich Strategien entwickeln, um seinen Wichtigkeitswert zu erhöhen. Bisher war niemand erfolgreich, das System auszutricksen.
Die Webarchitektur (nur NCC lokal betreiben - also keine blockchain runterladen - und dann zu irgendeinem Knotenpunkt (NIS) im p2p Netzwerk verbinden und völlig risikofrei alles tun...) ist ein weiterer Punkt, den ich ziemlich überzeugend finde. Möchte ich das mit Bitcoin machen, kann ich mich nur auf irgendwelche zentralisierten Servies verlassen...
Hier liegt ein Irrtum vor. Das "normale" Thin-Client Bitcoin-Sicherheitsmodell benötigt keine zentralisierten Services. Ein "SPV"-Client (wie zB. Multibit) im ["Normalen"|Offziellen|Standard] Bitcoin-Sicherheitsmodell kann mit jedem Full Node (trustless) kommunizieren.
MultiBit (ehemals der offz. empfohle Bitcoin Thin Client) braucht zB. nur 2 bis 3 MB Downstream/Diskspace (für Blockheader, Checksummen, etc.) und ist dann schon voll nutzbar.
Electrum wiederrum benötigt tatsächlich spezielle Electrum-Server. Allerdings ist auch deren Modell trustless und releativ dezentral. Gibt/gab ja zumindest mal einige Electrum-Server (50?) von relativ vertrauenswürdigen Betreibern. Ausserdem kann/könnte ja auch jeder seinen eigenen Electrum-Server fahren.
Vergleiche hierzu:
https://en.bitcoin.it/wiki/Thin_Client_SecurityInsbesondere:
https://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29_Clients und
https://en.bitcoin.it/wiki/Thin_Client_Security#Electrum.
Vielen Dank für die Infos!
Dennoch ist bei NEM eins bemerkenswert: Man kann prinzipiell sogar nur mit NCC (entspricht ja quasi einem thin-Client) minen (bei NEM heißt es "ernten")! Man kann NIS zwar so konfigurieren, dass nur bestimmte Adressen ernten dürfen, aber ich denke, es wird immer ein paar Server geben, die man nutzen kann, denn die Rechenleistung, die man zum ernsten braucht, ist ja nicht sonderlich extrem...
Was ist für mich als Nutzer der Unterschied ob ich einen "Nemesis-Account" erhalte oder nicht
Ein "Nemesis-Account" ist ein account, der quasi hartkodiert in der blockchain im ersten Block existiert. Die coins in diesen accounts sind 100% "vested", d.h. sie sind zu 100 % verwendbar, um zu ernten. Grundsätzlich muss du sonst immer eine gewisse Zeit lang warten, bis deine coins zur Ernte verwendbar werden - eine absichtlich eingebaute Trägheit, damit der Wichtigkeitswert nicht zu schnell schwankt/manipuliert werden kann.
dat frage ich mich auch und noch viel mehr! [...]
Was denn? Wenn du die Fragen stellst, kann ich sie dir vielleicht beantworten
[...]
Kann mir mal einer erklären wie ich diesen NEM Klienten installieren kann.
Die neuste Version geht bei mir nicht weil irgendwas mit Java nicht stimmt!!! Und ich habe es jetzt auch entnervt aufgegeben! und dabei habe ich die neuste Version
!!! *nerv*
Dann gibt es ja noch die "Standalone" Version aber wo ist da der Unterschied und was genau muss ich da downloaden??? Gibt es auch eine Erklärung auf deutsch, finde es im Moment alles zu kompliziert.
Der Installer verlangt die 64-bit Version von Java 8. Wenn der das nicht vernünftig mitteilt, sollte da noch der Text angepasst werden, da gebe ich dir vollkommen Recht!
Die Standalone Version ist quasi eine portable Version, muss also nicht installiert werden. Sie funktioniert auch mit 32-bit Java 8, allerdings wird 64-bit wohl nicht nur aus Performance- sondern auch aus Sicherheitsgründen empfohlen.