Topic: [DeM] Deutsche eMark - DEM - cryptocoin SHA256 POS/POW - page 33. (Read 237668 times)

I am in this story named " eDEM " from the beginning . and i belive  in it more than you think ..
 There is small team that work on this coin very hard. !
And  there is unfortunatel a lot of "smart guys" like you, that talk a lot, but they do nothing !  You can join the developer team and show you skills including your "double spending bug "   use your know-how in right way and do some good job for this coin !

Perhaps I like this coin (and the principles behind it), I'd like to see the devs get off their asses and make it a viable currency, and my comments are my passive-aggressive way of trying to give them a nudge....
FWIW, only a dedicated shitcoin would have a known double spend flaw, not fix it, and have people trying promote it without it being fixed. Is it your contention that you'd like eMark to be a shitcoin? I hope not, because I don't.

You mention Bitcoin's version number which covers 11 major revisions and over 40 different release versions (4 major revisions and 11 different release versions since eMark has been), but I'm not sure why you mention it...

there is 10000 others Shitcoins that you can carry about...   even bitcoin is still on 0.14.1 ---wallet and if you are "computerGenie" you should know what i mean

1 less pool on the network and still just as many orphans. 

Notice for Maintenance @ GCPOOL


i had to Stop for about 3 Hours to upgrade to better CPU and RAM

just for your Information !

 sudo lshw -C cpu
  *-cpu
       product: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
       vendor: Intel Corp.
       physical id: 1
       bus info: cpu@0
       width: 64 bits
       
# sudo lshw -C memory
  *-memory
       description: System memory
       physical id: 0
       size: 46GiB




Will be back soon as possible .


All your Shares and Coins are SAFE .

Please use other Pools

Regards Glen

IMO, it's a horrible idea for "local" markets to adopt a coin that creates a double spend liability for them, and it's an even worse idea for a larger market to consider acceptance.  It's one thing to try to try to get a rescinded remittance from Joe Shcmoe that lives down the block, try to get it from an anonymous you-don't-know-who on the other side of the country.

The issue is not the pools otherwise it wouldn't be all throughout the network with several different types of pool servers having the exact same issue.
The issue seems to be that the wallet ignores consensus in that, anytime a block is sent out with a timestamp older than the most currently accepted block, the entire chain gets orphaned to the point where that block would have been the "next block" and only blocks built on that one are then considered valid.

An overly simplified example would be....

The current chain is:
Block AAAAAB - timestamp 9:15:02
Block AAAAAC - timestamp 9:15:06
Block AAAAAD - timestamp 9:16:02
Block AAAAAE - timestamp 9:16:32
Block AAAAAF - timestamp 9:17:15
Block AAAAAG - timestamp 9:17:27
Block AAAAAH - timestamp 9:17:43

And there exists a previously unaccepted:
Block AAAABA - timestamp 9:15:04 (built upon AAAAAB)

When AAAABA gets broadcast to enough nodes, the fact that 6 blocks have been built upon AAAAAB (and rendered valid by consensus) becomes irreverent, blocks AAAAAC through AAAAAH get orphaned and the new chain becomes:
Block AAAAAB - timestamp 9:15:02
Block AAAABA - timestamp 9:15:04
Block AAAABB - the next block the network is working on.

It creates "nice" doublespend attack opportunities for anyone using a merchant that uses less than 7 confirmations (fact, not FUD).  

@genie
You are saying there's an error in the algo? Or the pools?

15+% orphaned blocks indicate error in algo...but should be "patch-able"?

Just trying to understand.

As a factual side note (not FUD):

The block explorer retains orphaned block rewards in balances.

Example:
http://blockexplorer.deutsche-emark.org/address/NMEVk78QgXr5pViqJyNgqDmmYAcqMYoGa6
Balance shows "2651.353" (at the time of posting), this number includes....
http://blockexplorer.deutsche-emark.org/block/000000000000006584173731df286fbbfdb97e077f4e676de0fb90375a078a71
http://blockexplorer.deutsche-emark.org/block/000000000000015c00ac46c49e9ba43aa2134e098330b9654fcef1bc311737f4
and
http://blockexplorer.deutsche-emark.org/block/0000000000000104accb775a54a632dc6e149a86334d1c1faf978b6c9613e317
(among others) all of which were orphans (and the coins don't actually exist).

Ah, yes !  Thank you. Running it this way does indeed disable the wallet, as evidenced by a lack of 'walletversion' and 'balance' in getinfo RPC call:


coins@server:$ eMarkd getinfo
{
    "version" : "v1.4.1.0",
    "protocolversion" : 60010,
    "blocks" : 1298222,
    "timeoffset" : 0,
    "moneysupply" : 33912927.36520400,
    "connections" : 2,
    "proxy" : "",
    "ip" : "204.68.122.4",
    "difficulty" : {
        "proof-of-work" : 13463806.74920098,
        "proof-of-stake" : 281.88991196
    },
    "testnet" : false,
    "paytxfee" : 0.00100000,
    "mininput" : 0.00000000,
    "errors" : ""
}

If all is coded right, then you can just compile as normal and run the daemon with:

One thing to know is that if you compile the node for mining purposes, it is better to compile it *without* a wallet.  This is mainly to get speed advantage; of course, you mine with a wallet address from _another_ machine (or paper wallet, for that matter). Your mining node will run a bit faster and give it a slight edge over a setup that is also maintaining a wallet.
Deutsche eMark is in the family of coins that compile by changing over to the source directory and running the compile, like so:

cd ~/eMark/src
make -f makefile.unix    ( or, if you have lots of cores,  make -j -f makefile.unix,   to compile in parallel)

in the ~/eMark/src/makefile.unix  I found USE_WALLET:=1, and changed it to USE_WALLET=0   (near the top).      I tried to compile like this, but ran into an error, so there must be another way to compile correctly without wallet.    ¿Perhaps one the devs can let us know ?

I know in other coins that use  ~//.autogen.sh     and  ~//.configure you can do:
~//.configure --disable-wallet     

Then, perhaps, you should save us all some headaches and stop responding to posts in a manner suggestive that you're involved in the development... 

yep , guess what ? .

you are ALWAYS right . you Won and you are the Best .

Before you told about Devs Pool ( i am NOT the Dev , remember ?  ) check other Pools .here you got the same Problems . And yes , we know .... we working on new Wallets . Guess what ? told that 100 Times before.


and PLONK, cause its too frustrating to talk .


Glen

It's quite ironic that not 5 minutes before you posted that, I was just telling someone how sad I find it when people liberally use FUD to even include things that are actually, and provably, flawed. I can assure you that dismissing the fact that you, yourself, can't even run a pool that is free of this issue does nothing for the usefulness of this coin.

The developer's own pool has nearly 400 orphaned blocks in the last month (16.25% of all blocks from that pool); that's fact, not FUD.

is it only me thinking you are very negative ?

yep , you told that 1000 times before . Yep , we worked on . YEP , we all know that . YEPPP , we understood .


Glen
Edit : please feel free to help . If you know about this Problem , share your Toughs to fix .....
if you cant help , please stop Fudding ( it wont help )

Until the massive orphan and reorg issues are fixed, I'm not sure he could seriously talk with Joe's Ice Cream Truck. 

As i told you all before , we have LOTS of communication with several People :-) :-)

@glen123 you have to talk to Jens Weidmann, the head of Germany’s central bank Bundesbank 

https://cointelegraph.com/news/head-of-bundesbank-proposes-digital-currency-to-compete-with-bitcoin