Bitcoin Forum
April 19, 2019, 05:47:05 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: CEX.IO Wartungsgebühr ohne Hashleistung  (Read 1189 times)
stürmchen
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
October 23, 2014, 10:16:13 AM
 #1

Hallo Gemeinschaft!

Leider fand ich zu meinem Problem nichts in den Foren.
Um mein "Problem" ""kurz"" zu schildern:

Ich hatte auf CEX.IO eine Hashingleistung von 55 GHs. Diese habe ich jedoch am: 23.09.2014 auf einen anderen Account übertragen, sprich am ursprünglichen Account keine Hashingleistung (0,00000000) mehr verfügbar.
Habe auch seit dieser Zeit, keine, auch nur für einen Bruchteil einer Sekunde jemals gekauft. (Kann ich auch mit Konto-Bewegungsdaten beweisen!)

Am: 22.10.2014 bemerkte ich, dass mir 0,00000025 BTC Wartungsgebühr für einen Share-Anteil von 512 Anteilen in Rechnung gestellt wurden. Grundsätzlich kein Problem, hätte ich CEX GHs-Leistung auch nur kurz besessen, jedoch kann ich dies 100%ig ausschließen.
Bei genauerer Beobachtung stellte ich fest dass der erzeugte Block #326467 mit dem Worker: Account-Name.ghash, mit kurzfristig: 610.84MH/s Rechenleistung gemint wurde.
Ich kann auch ausschließen, dass es sich um meine eigene Mining-Hardware gehandelt hat, da es weder eine IP-Aufstellung (bei eigener Mining-Hardware wird die IP sowie mein eingegebener Worker aufgelistet) gibt UND der oben angeführte Worker-Name nur von CEX.IO bzw. GHash.IO benutzt wird, wenn man Hashingleistung dort erworben bzw. noch im Einsatz hat!

Also gut, daraufhin ein Support-Ticket aufgemacht, auch prompt die Antwort dass sich ein Supervisor darum kümmern wird; Schlussendlich folgende Antwort:
_______________________________________________________________________________ _____________________________________________________
Here is an explanation of your cloud mining and paid maintenance during the period when you didn’t have any GHS on your account.
When cloud miner submits a share, stratum server decides, from whose domain it will be contributed. The size of a share depends on network difficulty, hence those users who have less GHS than some discrete value which allows mining to be continuous (5 GHS at the moment), start receiving the shares irregularly, not at every shift.
From PPLNS algorithm point of view these users are recognized as pool hoppers, and receive slightly less payouts.
Also those users whom we owe a tiny amount of shares, can wait for the payouts for long, and when they do receive them, PPLNS automatically lessens the payout, so it can be negative, taking the maintenance cost in account.
In other words, if you had tiny amount of GHS (less than 4 at the moment, but this number increases with Bitcoin network difficulty), we may owe you some low-difficulty shares, because we unable to provide them with miners set to a higher difficulty.
However, we account these funds, and if our miners are restarted, for some few seconds they send low-difficulty shares which are being distributed automatically to the users we owe, and accounted by PPLNS system as micro mining, hence the maintenance cost.
Please let me know if you need a more detailed and easy explanation, I will be glad to let you understand this all.

Best Regards,
XXXXXXX, CEX.IO support
_______________________________________________________________________________ _____________________________________________________

Soll das nun etwa wirklich bedeuten, dass ich mit meiner damalig verkauften Rechenleistung, einen aktuellen BTC-Block (28-29 Tage später) gemint habe und schlussendlich die Wartungsgebühr in der Höhe von 0,00000025 BTC korrekt ist?
Ich verstehe den technischen Hintergrund von CEX.IO ehrlich gesagt überhaupt nicht, doch vielleicht hat hier jemand eine Antwort für mich, die mir Klarheit schafft!?

Um noch eines anzumerken: Ich pfeife natürlich auf die 25 mBTC, doch geht es meiner Meinung nach hier um das Prinzip! Oder liege ich falsch damit?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!