Author

Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 706. (Read 1260677 times)

legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
Below are all release infos about DMD Cloudmining gathered so no one need to read through all pages to find it.
People tell us they have friends they wana tell them about DMD Cloudmining and if there is any reward if theur friends are investing too.

So we create referral Bonus:
If u are a investor in DMD Cloudmining project and u invite someone else to join  a 1% referal reward bonus will be added to ur account.
Someone who have not invested himself is not able claim that bonus so if u plan to earn some bonuspower by referals
u need to invest at least 100$ yourself. Why someone should tell me that u refered him?
i dont know maybe because u give them some reward (some free DMD as example) or because he like to help u because u his friend.....

more info on cloud mining?

pm me or mail at [email protected]
this is still the first early adopter investment round

public full details and statistics of earnings will be avaiable in 2 or 3 months

when u want to be part of it already and earn this few months waiting time
u have to go with trust in me



decide based on following calculation:
Quote
risc because no statistics no withdraw possibility and a only a word from cryptonit u get endless a share of earned dmd as guarantee
vs
Quote
stay on save side wait a few month then based on stats invest but missed the early adopter phase which give
like everywhere highest gains

if ya invest with fiat u have my real name
its not like i can disappear
https://www.xing.com/profile/Helmut_Siedl


its a invest basical in diamond and diamond foundation
because u need to believe we do the best we can for diamond

but if u dont believe that why are u here at all?

we all share the same dream
some work  active to make it come true
some passive  wait for it to happen

by invest into dmd cloudmining u go active
and u still have no work to do ur one time investment was enough
and will be endless rewarded with DMD payouts







more infos about DMD cloudmining:

all the code is prepared to enable us later on give u the ability to trade shares between users
this will need a few weeks maybe month to go life because a trading portal and so on need to be set up

but i still want to inform u about it so u know its not only a invest for longtime dmd payouts
its also a invest into a later on tradeable good

DMD Cloudmining shares!

when u invest ur amount of $ will be converted 1:1 in shares

this is possible on a fair way reagarding old investors because yes the amount of shares grow
but yes the new invested money will be spend to increase cloudmining hashrate
so the old shares dont lose power because new people join in

now the most interesting part where the early investers get they early adoper rewards:

similar to POS ur DMD Cloudmining shares grow by itself!

as u all know the design of DMD Cloudmining is that 70% of earning will be converted to DMD and paid out to shareholders (starting with oktober)

and 30% of earnings will be used to increaded DMD cloudmining hashrate

the converted $ value of that 30% will be spread each month and added to all shareholders
as free-reinvest-shares effective increase ur DMD cloudmining shares every month for free!

and no the best info at last:

if u invest in september ur investment will at start of oktober not increased by the normal 30% of earnings reinvest share
BUT by 100% of dmd  cloudmining earnings from september! (and over 7000$ worth of hashrate working there already for ur bonus!)

september no DMD payouts will happen instead we add this big early investor bonus!

this will be the next big thing
be part of it minimum invest is as low as 100$
a amount that nearly everyone should be able to invest
and by join in early ur effective sharepower will be much bigger in the follow up months!
[email protected]
im here to answer any follow up questions u might have


--------------------------------------------------------------------------
--------------------------------------------------------------------------
DMD Multipool Lotto
earn lotto numbers for free when u mine at DMD Multipool
next drawing 5. Oktober 100 DMD
http://multipool.bit.diamonds/

--------------------------------------------------------------------------
--------------------------------------------------------------------------
No mining gear to join DMD Multipool?
Get some DMD Cloudmining shares.
We will give them ability to earn DMD lotto tickets too.....

full member
Activity: 266
Merit: 100
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?

Although the idea is great, rendering a backup not only obsolete but useless because a transaction happened seems to me a bit radical and de facto dangerous. The only way I see to overcome the risk of losing coins in the event of a wallet.dat corruption for example would be to automatically back up the wallet at shutdown or even maybe at each transaction. This would however greatly increase resource usage.

This is the current situation. Not only with Diamond, but with virtually any Bitcoin code based crypto currency.

The 'change address' setting, if used, will actually eliminate this risk. At the cost of 'reducing anonymity' as some see it.

The wallet could automatically backup the file on one or more locations. However, in most setups this is essentially the same drive and when it fails, it does not matter how many copies you had (also there is the need for copy management). In theory, we could provide 'cloud backup' solution, encrypted and all that -- which will provide truly automated backup and versioning for the wallet.dat file (it's the only one worth saving). But I don't believe many will agree to store their wallet elsewhere, no matter how 'secure' the protocols etc are.

Ok. I misunderstood. I thought this was the consequence of your new implementation. I stand corrected.
sr. member
Activity: 393
Merit: 250
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?

Although the idea is great, rendering a backup not only obsolete but useless because a transaction happened seems to me a bit radical and de facto dangerous. The only way I see to overcome the risk of losing coins in the event of a wallet.dat corruption for example would be to automatically back up the wallet at shutdown or even maybe at each transaction. This would however greatly increase resource usage.

This is the current situation. Not only with Diamond, but with virtually any Bitcoin code based crypto currency.

The 'change address' setting, if used, will actually eliminate this risk. At the cost of 'reducing anonymity' as some see it.

The wallet could automatically backup the file on one or more locations. However, in most setups this is essentially the same drive and when it fails, it does not matter how many copies you had (also there is the need for copy management). In theory, we could provide 'cloud backup' solution, encrypted and all that -- which will provide truly automated backup and versioning for the wallet.dat file (it's the only one worth saving). But I don't believe many will agree to store their wallet elsewhere, no matter how 'secure' the protocols etc are.
full member
Activity: 266
Merit: 100
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?
hi ya mate:) i know its a tall ask but i really would like to see a "total coins minted" tab or something so i dont have  to count all the minted coins... lol i would understand if ur rolling ur eyes right now Smiley

That's a good idea Smiley. Alternatively and to avoid counting manually all minted coins you could export all transactions with the export tab and open up the .csv file in Excel then filter transactions by type. I concede it's not as fast as having the total amount displayed on the wallet but faster than counting with a calculator - lol
full member
Activity: 126
Merit: 100
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?
hi ya mate:) i know its a tall ask but i really would like to see a "total coins minted" tab or something so i dont have  to count all the minted coins... lol i would understand if ur rolling ur eyes right now Smiley
full member
Activity: 266
Merit: 100
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?

Although the idea is great, rendering a backup not only obsolete but useless because a transaction happened seems to me a bit radical and de facto dangerous. The only way I see to overcome the risk of losing coins in the event of a wallet.dat corruption for example would be to automatically back up the wallet at shutdown or even maybe at each transaction. This would however greatly increase resource usage.
hero member
Activity: 742
Merit: 500

... What other change related feature would you like to see in the wallet?

Perhaps the wallet must report after each transaction, what you need to make a backup copy of the wallet.dat?
several variations of this message: immediately after the transaction, before closing the wallet (if was transaction), once a week or after restarting wallet...
If necessary I can help translate additional functions on the Ukrainian and Russian languages.

can also be, you can add the function to input PIN (4-5 digits) code for outgoing transactions (protection from the virus and if someone else's gains access to computer). There were cases when encrypting wallet he did not take the password and the coins were lost forever.

or is it nonsense?  Smiley
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
this news are great news for pools and exchanges!

thx danbi
sr. member
Activity: 393
Merit: 250
I am currently toying with an implementation of settable destination address for change for the non GUI wallet. The GUI wallet has this functionality, via coin control, but the non-gui wallet does not.

The original Bitcoin implementation creates a new address for each send transaction and sends the change there. The theory is, that this will prevent tracking your own change back to your wallet -- but in reality the algorithm is well known and there is software to handle this mapping (all information is public in the blockchan anyway). So the 'privacy' benefit from this feature is highly questionable.

However, by create new addresses (public/private key pairs) in the wallet, it grows with each send transaction and becomes bloated with unused addresses (as the change is later reused/emptied) -- which leads to serious performance issues --- the recent glitch at http://dmdpool.digsys.bg being one -- for about a year, the wallet has accumulated several tens thousands addresses.. and it has resources. Also, you need to create backup of your wallet after each send transaction. Otherwise, if you for example have an 500 DMD amount and send 1 DMD out of it, the change will be 499 DMD -- will sit in a new address which does not exist in your backup... and if you need to restore from backup, you *will* lose that amount.

My current implementation does this:

- provides the 'setchangeaddress' RPC call to set the destination address for change;
- provides the 'getchangeaddress' RPC call to display the current address for change, if any;
- will (by tomorrow) implement -changeaddress, and the equivalent changeaddress= (in config file) to set up the address at startup.

This eliminates the useless growing of the wallet and performance degradation for busy wallets (such as pool, exchange etc wallets).

This feature is independent from the coin control feature to select change address. If you use coin control to set the address, it will override this setting. As it should, because it's only set via interactive GUI.

Is there anything else I am missing? What other change related feature would you like to see in the wallet?
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds

Cryptonit (Helmut), thank you for sharing who you are, it´s nice to know it is "real" people working with DMD Smiley. It would be desirable to have similar information for Popshot (Alex) and Danbi (Daniel) as well. Maybe an info page about Diamond Foundation on bit.diamonds?

The cloudmining project seems interesting. This project will be given a closer look in the near future.


for dmd cloudmining we need a legal person who is running the business and thats why i stated my infos

as soon as we create the DMD Diamond Foundation as a company
all the details about all foundation members will be available
and the DMD cloudmining will be run then by diamond foundation
(cant be done now dmd diamond foundation is no legal person until official formed as a legal entity)

but i will ask if they willing give a sneak peak earlier

i can tell ya danbi is a big fish in real a methusalem of IT business a true pioneer of internet age in europe  Cool
full member
Activity: 150
Merit: 101
The hen or the egg
Regarding the Cryptohunger pool

Polanskiman has a point regarding not having Cryptohunger pool listed on OP, and Popshot has also a point regarding info and warnings to miners.

Regardless, information should be correct.

Accordning to HR:s earlier investigations there is a 20% fee when mining Digibyte at Cryptohungers pool. This has been shown by transactions and addresses in the Digibyte blockchain.

In Cryptohungers DMD Pool the fee seems to still be the same as before, 8,4%, at least according to the DMD blockchain. Link to block 566058 recently found by the Cryptohunger pool:

http://diamond.danbo.bg:2750/block/00000000037c7bb04ab20493bd9e72b5cd7b9f85655e49026c1057c5b5da39c8
full member
Activity: 150
Merit: 101
The hen or the egg

Cryptonit (Helmut), thank you for sharing who you are, it´s nice to know it is "real" people working with DMD Smiley. It would be desirable to have similar information for Popshot (Alex) and Danbi (Daniel) as well. Maybe an info page about Diamond Foundation on bit.diamonds?

The cloudmining project seems interesting. This project will be given a closer look in the near future.
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
i moved 1500 DMD to usecryptos please more people fill orderbooks there

every earnings of dmd i sell there i will convert into DMD buy orders there
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
I see. And buy demand should hopefully raise DMD price and make "native" mining more profitable (or we will loose too much hashrate).

exactly
mining is mostly for people who run a GPU farm
only few of them are really holding DMD

dmd cloudmining is for investors who want to hold DMD

and be able earn DMD when the high rewards POW times are ending too

and DMD multipool is a way to give people who own dedicated mininghardware which is not able mine groestl
mostly sha256 and scrypt asics a way to mine for DMD rewards too

this way we have a way for each kind of investor and miner to get his hands on DMD

but my preference is DMD cloudmining because of the great one time invest and automatic growing sharepower (=hashrate)

i call that Cloudmining with POS (prove of share) where each month based on the shares u own already u get new shares for free

legendary
Activity: 2716
Merit: 1094
Black Belt Developer
I see. And buy demand should hopefully raise DMD price and make "native" mining more profitable (or we will loose too much hashrate).
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
about cloudmining, I'd be interested to know more about the infrastructure; i.e. will you be building your own mining firm or will you rent it? where will it be located? etc.

we have deals with seperate cloudmining providers
we have only hashrate located in maintained datacenters
(some of locations i know be used are in  UK australia south amerika usa .....)
u can consider DMD Cloudmining act as big customer
scanning market always increase its hashrate with best offer

if someone wana invest some hours daily to scan market
be in touch with providers be able get the best bang for the buck
then go for it

if u dont have the time then dmd cloudmining do that work for free
because its a win win situation for us

we help u and u help diamond buy creating buy demand

in case someone still think this dmd cloudmining is mining DMD via groestl

NO

dmd cloudmining is mining via sha256 scrypt and morphable algos
other coins selling them and with the earnings buying DMD and split them between the shareholder

i think its understandable we keep details of the exact deal
how much hashrate at which provider what special deals we have and so on secret
(for early investo thats the risc that they buy the cat in the bag but thats why they get the early adopter bonus)

later on we will provide exacts stats regarding how much invested money
did generate how much DMD and how much $ value that represent

the stats will look like:

invested $: 100
free reinvest share: 57
bonus/malus shares: 10 (will be used later on for trading shares (shares u receive is bonus shares u gave away is malus)
total sharepower: 167

earned DMD last day:  xx (xx$ actual marketvalue)
earned DMD this week(ongoing): xx (xx$ actual marketvalue)
earned DMD last week: xx (xx$ actual maketvalue)
earned DMD this month (ongoing): xx (xx$ actual marketvalue)
earned DMD last month: xx (xx$ actual marketvalue)
total earned DMD: xx (xx$ actual marketvalue)

we can make bets about who did guess the correct amount of week until
total earned DMD: xx (xx$ actual marketvalue) is bigger than invested $: xx
legendary
Activity: 2716
Merit: 1094
Black Belt Developer
about cloudmining, I'd be interested to know more about the infrastructure; i.e. will you be building your own mining firm or will you rent it? where will it be located? etc.
full member
Activity: 266
Merit: 100
We knew this long ago. Nothing new.

Was 20% fee well known? Last time it was 8%. Once his pool ceases to operate the entry will be removed.
There are 10 miners at the moment, I suppose people don't care that much after all.

20% or 8% or whatever the %age is (was), what I meant to say is that we knew what kind of persona he is. I experienced it myself. He is not a transparent individual. And that for me is enough not to promote his pool (nor to mine in it). I understand you guys want to inform people but by doing so you are also promoting the pool indirectly.

Leaving it in the OP, I can understand. Leaving it in the official website I think is inappropriate. It's only my point of view though Smiley
legendary
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
more infos about DMD cloudmining:

all the code is prepared to enable us later on give u the ability to trade shares between users
this will need a few weeks maybe month to go life because a trading portal and so on need to be set up

but i still want to inform u about it so u know its not only a invest for longtime dmd payouts
its also a invest into a later on tradeable good

DMD Cloudmining shares!

when u invest ur amount of $ will be converted 1:1 in shares

this is possible on a fair way reagarding old investors because yes the amount of shares grow
but yes the new invested money will be spend to increase cloudmining hashrate
so the old shares dont lose power because new people join in

now the most interesting part where the early investers get they early adoper rewards:

similar to POS ur DMD Cloudmining shares grow by itself!

as u all know the design of DMD Cloudmining is that 70% of earning will be converted to DMD and paid out to shareholders (starting with oktober)

and 30% of earnings will be used to increaded DMD cloudmining hashrate

the converted $ value of that 30% will be spread each month and added to all shareholders
as free-reinvest-shares effective increase ur DMD cloudmining shares every month for free!

and no the best info at last:

if u invest in september ur investment will at start of oktober not increased by the normal 30% of earnings reinvest share
BUT by 100% of dmd  cloudmining earnings from september! (and over 7000$ worth of hashrate working there already for ur bonus!)

september no DMD payouts will happen instead we add this big early investor bonus!

this will be the next big thing
be part of it minimum invest is as low as 100$
a amount that nearly everyone should be able to invest
and by join in early ur effective sharepower will be much bigger in the follow up months!
[email protected]
im here to answer any follow up questions u might have


--------------------------------------------------------------------------
--------------------------------------------------------------------------
DMD Multipool Lotto
earn lotto numbers for free when u mine at DMD Multipool
next drawing 5. Oktober 100 DMD
http://multipool.bit.diamonds/

--------------------------------------------------------------------------
--------------------------------------------------------------------------
No mining gear to join DMD Multipool?
Get some DMD Cloudmining shares.
We will give them ability to earn DMD lotto tickets too.....

hero member
Activity: 774
Merit: 554
CEO Diamond Foundation
We knew this long ago. Nothing new.

Was 20% fee well known? Last time it was 8%. Once his pool ceases to operate the entry will be removed.
There are 10 miners at the moment, I suppose people don't care that much after all.
Jump to: