Beiträge von Hui

Es ist doch noch gar nicht Weihnachten.

Also ich setze da auf Rumhocker, der kann ja programmieren und ist wie ich das sehe, der einzige Entwickler hier. Und falls er nur Java / Kotlin kann und nicht C#, wär es sicher möglich für ihn, sich da einzuarbeiten und seinen Code mit C# weiterzuentwickeln.

Völlig fremd wird es ihm ja nicht sein, da das Windows Wallet in C++ geschrieben ist.

Es würde sich lohnen das Ganze unter Xamarin mit C# zu programmieren, dann hätte man auf einen Schlag ein Android Wallet + IOS + Windows Mobile. Man braucht also keinen IOS entwickler, einer der C# kann, reicht.

Das muss dir nicht leid tun.

Ich kann das nur nicht nachvollziehen. Wenn das stimmt, was du sagst, wäre ja die Anzeige der zu erwarteten Zeit im Wallet falsch.

Denn die wird berechnet aus dem Verhältnis zw. eigenem Gewicht und Netzgewicht.

Bsp: 1.000 DEM, die älter sind als 30 Tage und Netzgewicht von 720.000 DEM

unter "getstakinginfo" steht dann:

"weight" : 1000000000,

"netstakeweight" : 720000000000

Das heißt, das Netzgewicht ist 720 mal höher als das eigene Gewicht.

Bei 720 erzeugten Blöcken hat man also statistisch gesehen, die Chance 1 Belohnung zu erhalten.
Da 720 Blöcke an einem Tag erzeugt werden, ist die erwartete Zeit 1 Tag.

Das wird auch unten rechts bei Mouseover angezeigt.

Ich kann nirgends einen Hinweis erkennen, dass meine Coins mehr Gewichtung bekommen. Und wenn das so wäre, wäre wie gesagt die angezeigte Zeit falsch.

Unter Coincontrol gibts zwar eine Spalte "Priorität", das hat aber nichts mit der Gewichtung zu tun, sondern wirkt sich normalerweise nur auf die Transaktionsgebühren aus. (das konnte ich jedenfalls bei anderen Coins feststellen)

Bei DEM wirkt sich dies nach meiner Einschätzung gar nicht aus.

Dass Priorität und Gewichtung nicht dasselbe sein können, sieht man auch daran, dass bei 1337 unter "Coin Control" 2 Spalten dafür existieren. Während "Priorität" nur wenige Abstufungen kennt (zB. niedrig, mittel, mittel-hoch, hoch, am höchsten) und hohe Beträge sofort das Prädikat "am höchsten" bekommen, kann man in der Spalte "Weight" minütlich bzw. stündlich zukucken, wie das Gewicht jeder einzelnen Transaktion höher wird.

Du schreibst: "da sich das auf kleine wie auch auf große Coinblöcke linear auswirkt."

Das stimmt nicht ganz. Wenn man das Wallet monatelang offen staken läßt, wird ein großer Block niemals das Alter von 100 Tagen erreichen. Je nachdem wie groß er ist, bekommt er ja am 1. Tag schon den Stake und verliert sein Gewicht wieder.

Nur kleine Blöcke profitieren davon und haben dadurch die Chance überhaupt in angemessener Zeit eine Belohnung zu bekommen.

Das ist der Sinn, dass kleine Coinblöcke bevorzugt werden (je älter sie werden). Angenommen man hat 2 Transaktionen:

10 DEM + 1.000 DEM

Der kleine Block hat eine 100 mal kleinere Chanche, eine Belohnung zu erhalten als der große und wird deshalb immer älter.

Der große Block wird nach wenigen Stunden eine Belohnung erhalten und ist dann ja für 30 Tage nicht mehr stakefähig.

Der kleine Block altert und sein Gewicht wird jeden Tag um 10 höher. Also nach 100 Tagen hätte er dasselbe Gewicht wie der Große zu Anfang.

So ist es bei Elite (1337).

Anderes Bsp:

Man hat eine 300 Tage alte Transaktion von 100 DEM und auf einem getrennten Wallet eine 1000 DEM Transaktion, die 30 Tage alt ist.

Wenn es stimmt was du sagst, müsste die erwartete Zeit bei beiden Wallets genauso hoch sein, 100 DEM sind zwar nur 1 Zehntel von 1000, dafür ist es aber 10x so alt.

Tatsache ist, dass auf dem 100 DEM Wallet die angezeigte erwartete Zeit 10x höher ist, als auf dem 1000er Wallet.

Also spielt nur der Betrag eine Rolle und nicht das Alter.

Das jetzige Verfahren ist zwar besser als das, was die meisten Coins verwenden (feste Blockbelohnung), aber das heißt ja nicht, das man es nicht noch verbessern könnte.

Der große Vorteil bei DEM ist:
Man muss nicht 24/7 staken, um seine Stakebelohnungen zu bekommen, ist ist sogar egal, wann oder wie lange man stake't.

Ein Nachteil bleibt aber: Wenn das Netzgewicht steigt (das ist die logische Folge, wenn der Coin bekannter wird) wird es immer schwerer für die, die nur verhältnismäßig wenig Coins besitzen, eine Belohnung zu bekommen. Sie müssen Wochen oder Monate warten, um mal das "Glück" zu haben.

Lösung: Man macht es z.B. so wie Elite (1337).

Neue Coins haben ein Gewicht von 0. Nach exakt 24 Stunden haben sie ein Gewicht, das der Anzahl der Coins entspricht. Zeiten darunter werden anteilig berechnet.

Wenn man z.B. 24 Coins hätte, würde das Gewicht jede Stunde um 1 steigen.

Das führt dazu, dass sich die Wartezeit verringert, je länger man keine Belohnung mehr bekommen hat.

An den Spezifikationen des Coins ändert sich dadurch ja nichts. Es macht "nur" ein bischen Programmierarbeit.
Vielleicht ist das ne Überlegung wert für die Entwickler.

mir fehlt folgendes: Was ist das besondere beim PoS (Staken) gegenüber anderen Coins?

DIe meisten Coins haben eine feste Blockbelohnung. Das hat zur Folge, dass man bei diesen Coins das Wallet immer offen haben haben muss, wenn man am PoS teilhaben will. Nachträglich kann man nicht profitieren. Hat man nur kleine Mengen dieser Coins, muss man wochen- oder monatelang auf eine Stake Belohnung warten. Bei einigen Coins ist es zu empfehlen, sein Guthaben aufzusplitten (abhängig von der Menge der Coins), weil aufgrund des Min-Stake-Age nach einer Belohnung der gestakte Betrag für eine Zeit gesperrt ist.

Bei DEM ist das anders. Es gibt hier keine feste Blockbelohnung fürs Staken, sondern die Zinsen sind auf 3,8% jährlich festgesetzt und werden abhängig vom Alter des stakenden Betrages anteilig berechnet. Hier lohnt es sich, das gesamte Guthaben in einer Transaktion zusammenzufassen und nicht zu splitten (weil man dann schneller eine Belohnung erhält). Es gibt zwar auch hier das Min-Stake-Age, das mit 1 Monat sogar ziemlich hoch ist, aber die Zinsen werden rückwirkend berechnet. Es genügt 1x im Monat sein Wallet zum Staken zu öffnen. Hat man die Belohnung erhalten, kann man es wieder schließen. Auch wenn man es nur 1x im Jahr öffnen würde, hätte man keinen Nachteil, man würde genausoviel Zinsen bekommen.

Wer hier ständig sein Wallet offen hat, hat keinen Vorteil, sondern einen Nachteil. Die CPU Auslastung ist mit durchschnittlich 11% ziemlich hoch (andere PoS Wallets kommen auf 0,2-0,3%). Das kostet natürlich zusätzlich Stom. Diese zusätzlichen Kosten übersteigen bei geringen Guthaben sogar die Zinserträge.
Außerdem sorgt man damit für eine (unnötige) Erhöhung des Netzgewichtes, das zur Folge hat, dass Andere länger auf ihre Belohnung warten müssen.

Man benachteiligt also nicht nur sich selbst, sondern auch Andere.

Wer unbedingt das Wallet laufen lassen will, um das Netzwerk zu unterstützen, kann dies im gesperrten Zustand tun.

Das Oneplus X ist ein 32bit System mit Android 6

Punkt 2 wird niemals eintreten. Jedenfalls nicht mit den jetzigen Spec's des Coins.

Möglich wäre das zwar. Es ist nur die Frage, ob das die Mehrheit will. Man könnte es so machen wie Tether (USDT), der ja an den $ gekoppelt ist.

Genauso könnte man DEM an die alte DM (bzw. an den EURO) koppeln, so dass 1 DEM für immer 1/1,95583 = 0,511292 € wert ist.

Dann müsste man sich aber von Mining und PoS verabschieden. Drüber nachdenken könnte man ja, vielleicht hätte dann die DEM sogar eine bessere Chance zu überleben.

Danke

Das bezweifle ich, denn dann würde es auch mit Parameter -X gehen, der so definiert ist:

case 'X':
addrtype = atoi(optarg);
privtype = 128 + addrtype;

oclvanitygen -X53 Nabc

erzeugt die Meldung:

Hint: valid bitcoin addresses begin with "1"

aber vielleicht hab ich auch die falsche Version, ich habs ja nicht selbst compiliert.

Zitat von Elaar

Aber wovon bei DEM der Kurs abhängig ist hat sich mir noch nicht ganz erschlossen!?!

Von Angebot und Nachfrage. So wie auch bei allen anderen Coins oder auch Aktien, die an Börsen gehandelt werden.
Wie genau das erfolgt, kannst du hier lesen: http://www.finanzen.net/special/nachri…ande_-3-3968223

Man kann es es noch weiter beschleunigen, indem man im Arbeitsverzeichnis, wo auch die wallet.dat ist, eine zusätzliche Datei anlegt mit dem Namen

eMark.conf und dem Inhalt

-dbcache=1000

Das hat zur Folge, dass 1 GB Speicher reserviert wird (Ohne diese Datei oder den Parameter werden nur 25 MB verwendet)
Das Aufbauen / Verifizieren geht dann in weniger als 2 Stunden.

Wenn die bootstrap.dat im selben Verzeihnis liegt, findet das Programm sie auch selbst (wie vorher richtig beschrieben) und braucht den Parameter -loadblock nicht.
Wie gesagt, wenn im Wallet unten links "importig blocks" steht, funktioniert es, wie es soll.

Nachdem alles syncronisiert ist, können bootstrap.dat und eMark.conf wieder gelöscht werden.

Zitat von chris22

"vanitygen -X 53 Nabc" geht schon

Welche Version benutzt du?

Mit der v1.22win gehts so noch nicht, man braucht zusätzlich den Parameter -r (Die Machbarkeit wird dann nicht überprüft)
Ohne den Parameter wird die Fehlermeldung ausgegeben, dass es keine gültige Bitcoinadresse ist.

vanitygen.exe -X53 -r Nabcodervanitygen64.exe -X53 -r Nabc

Bestimmte Kombinationen sind ja nicht möglich, also z.B. "lk" oder "KO". Man sollte die Machbarkeit vorher mit Bitcoinadressen testen.
Der Parameter -r hat aber noch einen Vor- bzw. Nachteil, denn es wird nicht nach dem Präfix gesucht, sondern, ob die Zeichenkette überhaupt vorkommt.
Wenn man also Nabc als Präfix (vorn) haben will, kann man das so lassen, er findet aber auch Adressen, wo Nabc am Ende der Adresse oder mittendrin steht.
Man kann auch das führende N weglassen:

vanitygen64 -X53 -r abc

Die 64bit Version hat bei mir einen Geschwindigkeitsvorteil von 12%, der Key wird also im Schnitt 1,12 mal schneller gefunden.
Das ist kaum von Bedeutung. Schlimmer ist, dass alle 4 Kerne unter Volllast arbeiten, ca. 100 Grad heiss werden und natürlich auch sehr viel Strom verbraucht wird.
Obwohl ich ne uralte Grafikkarte hab (Geforce GTX 470), geht die Berechnung ca. 70 mal schneller (und die CPU wird kaum beansprucht), wenn man statt vanitygen oclvanitygen.exe verwendet:
MIt Segwit Adressen funktioniert das auch:

oclvanitygen -X5 3abc

Das Problem ist, ein führendes N wird nicht akzeptiiert, weil es dann keine Bitcoinadresse wird und man kann hier auch nicht den Parameter-r angeben, der existiert einfach nicht.

Es gibt zwar noch den Parameter -N (für Namecoin Adressen), der auf den ersten Blick (zumindest für DEM Coin Adressen) funktioniert:

oclvanitygen -N NDeMark

Allerdings lässte sich der generierte Privat Key nicht im Wallet einfügen, da er den Key als "ungültig" erkennt.

Hat jemand ne Lösung, wie man mit oclvanitygen Adressen erzeugt, die nicht mit 1 oder 3 beginnen?

Danke. Nun weiss ich endlich auch, wie ich Segwit Vanity Adressen mache. Ohne den "-X" parameter verlangt das Programm ja ne "1" an erster Stelle, das hatte ich verdrängt.

Dieses Byte sollte man lieber Encoding prefix nennen...

Das addressPrefix ist "N" wenn ich das richtig sehe, 0x35 wäre die Ziffer "5"
Mit dem Parameter -X wird außerdem die Versionsnummer angegeben und kein Präfix.

Es reicht also:

vanitygen.exe Nvanity

Bitte korrigieren, wenn ich mich irre.

Die bootstrap.dat wird mit dem Parameter "-loadblock" geladen.
also z.B.:

eMark-qt -loadblock=D:\bootstrap.dat

Am Besten erstellt man eine .txt Datei, die man danach in .bat umbenennt, dann kann man die per Doppelklick starten.
Wenn das Verzeichnis bzw. folgende Unterverzeichnisse Leerzeichen enthalten, muss man die gesamte Pfadangabe in Anführungszeichen setzen, also z.B.:

eMark-qt -loadblock="D:\Crypo Währungen\Deutsche eMark\bootstrap.dat"

Ob es funktioniert, sieht man daran:
Anstelle der Meldung unten links im Wallet:

Syncronizing with network...

steht jetzt da:

Importing blocks

Damit es keine Missverständnisse gibt: Der Fortschrittsbalken fängt in beiden Fällen ganz links an (bei über 3 Jahren Rückstand)
Das Aufbauen geht wesentlich schneller, da die Blocks nicht über Netzwerk geladen werden müssen. Es dauert trotzdem etliche Stunden... (nach meiner Schätzung ca. 1 Tag)