[DeM] Deutsche eMark (v1.4) - ein deutscher Cryptocoin

[Bzzzum]

Deutsche elektronische Mark

Die Zukunft des digitalen Bezahlens

__________________________________________________________

Das Projekt ist OpenSource und die Idee hinter der Deutschen eMark ist, die Crypto-Währungen in unserem heimischen
Markt bekannter zu machen und auf eine breitere Akzeptanz zu stoßen.

Die eMark basiert auf dem gleichen Prinzip wie der allgemein bekannte Bitcoin, hat jedoch gegenüber dem Bitcoin die Vorteile, daß durch den
"Proof of Stake" Zinsen erzeugt werden und zu jeder Transaktion ein Verwendungszweck hinzugefügt werden kann.


- SHA256D, Proof of Work (PoW) + Proof of Stake (PoS)
- 210 Millionen PoW-Coins
- 3.8% Zins per Jahr - Auszahlung monatlich (30 Tage)
- 50.00 DEM per Block
- 2 Minuten pro Block
- 140 Zeichen langer Verwendungszweck (TX comment)


Deutsche eMark Website:
http://deutsche-emark.de/

Forum:
http://forum.deutsche-emark.de/


Blockexplorer
blockexplorer.deutsche-emark.org

Mining-Pools:
Glens Pool: http://dem.gcpool.eu
coinz.at: http://coinz.at
ispace.co.uk: http://dem.ispace.co.uk/
803 Mine: http://pool.803mine.com

Exchange:
Yobit: https://yobit.net/en/trade/DEM/BTC
Cryptopia: https://www.cryptopia.co.nz/Exchange?market=DEM_BTC
coinexchange.io: https://www.coinexchange.io/market/DEM/BTC

Source:
https://github.com/emarkproject/eMark

Wallet's:
Win und Mac Wallet:
Bitte ladet Euch die neuest Version immer von unserer Webseite http://deutsche-emark.de/


Social-Media:
Twitter: https://twitter.com/Deutsche_eMark
Facebook: https://www.facebook.com/deutscheemark



Ihr könnt das Projekt gern unterstützen. Wir suchen immer engagierte Leute mit Ideen und Visionen. Meldet Euch einfach hier in diesem Forum.

__________________________________________________________
history:


** UPDATE AUF VERSION 1.4 **
Bei der eMark findet am 15.05.2016, 00.00.00 GMT ein außerordentliches Wallet Update statt.
Alle Nutzer werden gebeten, vorher auf die Version 1.4 zu updaten.
Transaktionen von älteren Versionen werden ab dem 15.05.2016 nicht mehr akzeptiert.
Bitte denkt bei dieser Gelegenheit an eine Sicherungskopie der wallet.dat.
Ein neu laden der Blockchain ist notwendig.

Download Windows
https://github.com/emarkproject/eMark

Folgende Änderungen treten am 15.05.2016 in Kraft:
StakeProtokoll V2 (Blackcoinfork)
Timedrift 120 min --> 15 s
Process Message zur dezentralen Abfrage der Blockchain
Regtest zusätzlich zum Testnet hinzugefügt



** UPDATE AUF VERSION 1.3 **
** Neues eMark Wallet verfügbar **
Unser altes eMark Wallet hat ein riesen Update bekommen. Es wurden alle bekannten Sicherheitslücken geschlossen, neue Features eingebaut und die Sprachdateien komplett eingedeutscht.
Es ist nicht notwendig das Update zu laden, das alte Wallet funktioniert auch weiterhin gut. Wer jedoch die neue Optik und die bessere Performance der Version 1.3 nutzen möchte, ist gezwungen sich die komplette Blockchain neu herunter zu laden Das dauert zur Zeit ca. 8-10 Stunden. Der Grund liegt darin, dass das neue Wallet jetzt die Blockchain in der modernen LevelDB Datenbank speichert.   Bei dieser Gelegenheit sollte auch wieder mal eine Sicherungskopie der wallet.dat gemacht werden.
Download auf www.deutsche-emark.org

[phantastisch]

Source für eventuelles kompilieren für Linux oder Codereview ? 

[Bzzzum]

Source für eventuelles kompilieren für Linux oder Codereview ? 

Danke, hatte ich doch tatsächlich vergessen hinzuzufügen

[klaus]

Ein emotionsbeladenes Kürzel - DEM

[gMaN1337]

4. Jetzt kann es eigentlich schon mit dem „Minen“ eurer ersten Deutschen eMark losgehen.
starte die Datei eMart-qt-server.bat
starte den CGMINER über die Runme.bat

wo finde ich die eMart-qt-server.bat ?

[Bzzzum]

4. Jetzt kann es eigentlich schon mit dem „Minen“ eurer ersten Deutschen eMark losgehen.
starte die Datei eMart-qt-server.bat
starte den CGMINER über die Runme.bat

wo finde ich die eMart-qt-server.bat ?

Hi,

habe ich unter Punkt 2 beschrieben:

2. im Ordner des eMark Wallet erzeugt Ihr euch auch mit dem Editor eine eMart-qt-server.bat
Folgenden Inhalt zieht Ihr Euch per Copy&Paste in die Datei:
Code:
Quote
emark-qt.exe -server

Also mit dem Editor erstellst Du eine neue Datei, welche Du mit dem oben genannten Inhalt abspeicherst. Achtung im Editor darf nicht zum speichern Dateityp "Textdatei" ausgewählt sein.
Hier musst Du auf alle Dateien umstellen und die zu speichernde Datei muss auf .bat enden.

[Verlaufen]

Ist minen nicht mit CPU möglich (vom Sinn mal abgesehen) ?
Ich bekomme Fehlermeldung wg fehlender GPU, gewartet wird wohl noch auf USB-Gerät. Scheint aber ohne dies nicht loszugehen.

[gMaN1337]

hehe danke

wie kann ich den server übers netzwerk ereichen ?

habe in der config versuch die ip auf meine interne-netzwerk ip zu änderen aber klappt nicht

[Bzzzum]

Ist minen nicht mit CPU möglich (vom Sinn mal abgesehen) ?
Ich bekomme Fehlermeldung wg fehlender GPU, gewartet wird wohl noch auf USB-Gerät. Scheint aber ohne dies nicht loszugehen.

Hm, hab ich mit CPU noch nicht getestet. Müsste aber in den Einstellungen vom cgminer zu erledigen sein.

[Verlaufen]

danke, ich schau mal.

[gMaN1337]

hehe danke

wie kann ich den server übers netzwerk ereichen ?

habe in der config versuch die ip auf meine interne-netzwerk ip zu änderen aber klappt nicht

so funktioniert habe es hin bekommen ^^

bekomme immer ne meldung das Pool 0 not providing wortk fast enough...

[Bzzzum]

Hi,

du hast die erstellte emark-qt-server.bat gestartet? Diese setzt dein Wallet in den Servermodus.
Danach startest Du den cgminer wie oben beschrieben.
Dann sollte es so aussehen:

[gMaN1337]

also blöcke findet er trotz der meldung keine ahnung was die besagt...

[lassdas]

- 2 minute block targets

2 Minuten ist ein Witz, oder?
Und bevor Du gleich anfängst mit "..aber wir brauchen doch schnelle Confirmations, weil wir an der Kasse nicht warten wollen..", lies Dir in aller Ruhe das folgende Posting durch:

...
As for the choice of the interval itself.   Satoshi chose 10 minutes to be conservative but it isn't as conservative as many people think.  Most people say it only takes a second to download a block so why wait 600 seconds, 150, 30 or even 10 seconds should be "more than enough".

The reality is it is more complex than that.  It isn't all or nothing you need to consider:
a) Small nearly empty blocks will be faster than very large blocks in the future (the goal should be building the coin for the future not the launch)
b) The block target is just a target.  The actual times will vary so even with Bitcoin's "slow" 600 second interval often competing blocks are found before a block fully propagates the network.
c) In a peer to peer network it takes multiple hops so that multiplies the transit time of a block.
d) Any hashing power lost to orphans reduces the security of the network.

Mining is a Poisson Process and the interval between events (block found) will follow a Poisson distribution.  So while 10 minutes is the average interval a significant portion of those blocks will be found much faster (and a significant portion much slower).  I don't have time to draw the curve for multiple block intervals so I will steal an existing example curve from wikipedia. 



One could draw the same curves using seconds in the block target of various coins.  The reason for the chart is to illustrate that while a coin may TARGET a specific interval the actual block times will fall in a distribution around the target time.  Just looking at the average time is deceptive.   For security implications we are interested in how often blocks will be found very quickly (relative to propagation interval).  
For a chain with a target time of x seconds, about 39% of blocks will be found in 0.5x seconds or less, about 22% will be found in 0.25x seconds or less, about 10% of the blocks will be found in 0.10x seconds or less. 

When a block is found before a previous found block propagates the network an orphan occurs.  The next block will either build on the previous block or the newly found one.  From a security perspective it doesn't really matter which one will be orphaned because regardless work and thus security is lost.  Even on Bitcoin's "slow" network about 1% or the hashpower is wasted due to orphans and the network right now is very small and blocks are very small.  An attacker is going to keep working on the attack chain even if he is a block behind so orphans help the attack by reducing the effective hashrate and thus security of the network. 

Now for small networks (less hops) and low tx volume even very short block targets aren't a significant problem however Satoshi designed Bitcoin not for genesis day but for what would be optimal if Bitcoin became mainstream.  Any crypto-currency that grows to any meaningful volume is going to have much larger blocks.  Someone saying the brand new "xyz coin" with 10 seconds blocks isn't a problem is being naive when you consider the average block is a maybe a half dozen tx and there aren't more than a few hundred nodes.  

So lets look at a more longer term scenario.  Imagine a scenario where the average block is 25 MB.  To relay that to one peer in 1 second would require 200 Mbps.  However no node connects to only 1 peer so even relaying it to the minimum 8 peers would require 1,600 Mbps.  For a miner (if you work for a pool you are a worker the pool is the "miner") 8 peers is insufficient to rapidly broadcast a block and poor connectivity means higher relative and less revenue.  With just 50 peers to relay a 25MB block in 1 second requires 10 Gbps. 

However the miner can only influence his relative oprhan rate (his orphans vs network average orphans) the overall orphan rate is based on the average node connectivity and the size of the network.  Also remember there will be multiple hops and before relaying each node has to verify each tx, each tx hash, each leaf of the merkle tree (requiring 2n-1 hashes for n txs), the block header, and the block hash.  The average node may a minimum of 8 connections but for propagation what matters is unique connection.  When a node learns of a block how many nodes is it connected to that don't already know the network.  Lets estimate the unique connectivity between Bitcoin nodes is 5.  In a network of 50,000 nodes that means 7 hops to propagate the block to all nodes.   

So lets start making some assumption about a future network to see how long propagation could take.
50,000 nodes
5 unique connections between nodes
1 Gbps of upstream bandwidth
25 MB block size.
100 ms latency between blocks
15% overhead due to TCP/IP
250 ms to verify block & txs.

We are looking at 7 hops and ~10.5s for propagation to all nodes in the network.   This is just an estimate in reality due to the disimilar nature of peers makes any computation essentially impossible it would either need to be observed or simulated.  I would point out that this example network is pretty optimistic from a delay standpoint.  It has a low occurrence of redundant connections and very high average upstream bandwidth (probably unrealistically so for residential connections even in the intermediate future).  Still we are looking at 10.5 s from the time a block is found until all nodes have received and verified it.  Now one may say 10.5s is smaller than even a block time of 20s so it shows Bitcoin is unrealistic.  However remember the interval just being a target, actual interval between blocks will be a distribution.  It isn't all or nothing any propagation delay increases the rate of orphans.   We use the term "network" like it is a single continually in sync system but the reality is it is an ocean of independent peers.  The network is never 100% in sync but the larger propagation delay the longer there is a lack of consensus on the longest chain, and an orphan can occur.  Even on slow Bitcoin network about 3% of blocks will be found in 10.5s or less and that assumes difficulty is perfectly matched with hashrate.  Right now the network is operating 30% faster than the assumed hashrate for the current difficulty so that would be closer to 4% orphans.  The smaller the target interval relative to the expected propagation delay the more security will be "counterfeited" by orphans (miners working on mutually exclusive blocks).

So what is the perfect block interval?  There isn't one. It is compromise between security and responsiveness.  Changing it is very difficulty (if not impossible) and the "perfect" target time is very dependent on network conditions and tx volume and those are going to change over the life of the currency.  Satoshi chose conservatively based not on the conditions at the time of launch (tiny blocks, and a handful of nodes) but based on the potential future (massive blocks and tens of thousands of nodes).  Even for Bitcoin as the network grows larger and more complex the "peer finding mechanism" will probably need to be improved to ensure the network has good end to end connectivity.  Nodes will want to work together to avoid creating bottlenecks which can make propagation unnecessarily long.  
...

Ach und warum die Difficulty sich mit jedem Block ändert, ist mir auchnicht so ganz klar,
wie soll man denn entscheiden, ab wann sich das Mining nichtmehr lohnt, wenn sich die Diff alle 2Minuten ändert? 

[ewibit]

Vielen Dank für Euer Interesse und Unterstützung.

Source:
https://github.com/emarkproject/DEM

Ubuntu 13.04

Code:

make -f makefile.unix

Code:

In file included from /usr/include/boost/smart_ptr/enable_shared_from_this.hpp:16:0,
                 from /usr/include/boost/enable_shared_from_this.hpp:16,
                 from /usr/include/boost/thread/pthread/thread_data.hpp:11,
                 from /usr/include/boost/thread/thread.hpp:17,
                 from /usr/include/boost/thread.hpp:13,
                 from util.h:21,
                 from alert.h:13,
                 from alert.cpp:8:
/usr/include/boost/smart_ptr/weak_ptr.hpp:138:16: Anmerkung: boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(const boost::weak_ptr<Y>&) [with Y = void; T = void; boost::weak_ptr<T> = boost::weak_ptr<void>]
/usr/include/boost/smart_ptr/weak_ptr.hpp:148:16: Anmerkung: boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(boost::weak_ptr<Y>) [with Y = void; T = void; boost::weak_ptr<T> = boost::weak_ptr<void>]
make: *** [obj/alert.o] Fehler 1

[usekevin]

Google

404. That’s an error.

The requested URL / was not found on this server. That’s all we know.


Ahja...

[Bzzzum]

Google

404. That’s an error.

The requested URL / was not found on this server. That’s all we know.


Ahja...

Gut, vielleicht hätte ich es mit " ... erreichbar sein wird." Denn aktuell bin ich gerade noch dabei, das Forum zum laufen zu bekommen.
Und wie oben schon erwähnt, kann man sich gerne an dem Projekt beteiligen.

[Bzzzum]

Ubuntu 13.04

Code:

make -f makefile.unix

Code:

In file included from /usr/include/boost/smart_ptr/enable_shared_from_this.hpp:16:0,
                 from /usr/include/boost/enable_shared_from_this.hpp:16,
                 from /usr/include/boost/thread/pthread/thread_data.hpp:11,
                 from /usr/include/boost/thread/thread.hpp:17,
                 from /usr/include/boost/thread.hpp:13,
                 from util.h:21,
                 from alert.h:13,
                 from alert.cpp:8:
/usr/include/boost/smart_ptr/weak_ptr.hpp:138:16: Anmerkung: boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(const boost::weak_ptr<Y>&) [with Y = void; T = void; boost::weak_ptr<T> = boost::weak_ptr<void>]
/usr/include/boost/smart_ptr/weak_ptr.hpp:148:16: Anmerkung: boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(boost::weak_ptr<Y>) [with Y = void; T = void; boost::weak_ptr<T> = boost::weak_ptr<void>]
make: *** [obj/alert.o] Fehler 1

Habe versucht den Fehler mit einer frischen Ubuntu 13.04 zu rekonstruieren - komme zu dem gleichen schluss.
Was ich allerdings nicht verstehen kann, unter Debian gab es keine Probleme. Allerdings bin ich zugegebener Maßen auch kein absoluter Linux-Experte.

[frelex]

Google

404. That’s an error.

The requested URL / was not found on this server. That’s all we know.


Ahja...

Wenn du ihr euch übers Netzwerk verbinden möchtet müsst ihr in der config "rpcallowip=*" angeben.

Ich war außerdem gestern mal für ein paar Minuten so frech und habe meine 3 Jupiter ins Netzwerk gehängt!
1000 DEM 

[herzmeister]

löl, der Name wurde hier im Forum schon mal diskutiert, ich erinnere mich.

die Proponenten hatten damals aber dann doch noch ein paar andere "Visionen" ... wie Obergrenzen für die Miner oder sowas.  Und alles irgendwie natürlich fairer und gerechter und nationaler und was weiß ich. Irgendwelche unlogischen Dinge, die ohne Aufsichts- und Kontrollbehörde nicht möglich wären.

Aber so ist dies hier natürlich nur ein weiterer Fork... nette Spielerei. Vielleicht kann man ja ein paar AfDler oder was damit beeindrucken.