[ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65%

[cryptonit]

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

[hallared]

Cryptonit (Helmut), thank you for sharing who you are, it´s nice to know it is "real" people working with DMD . 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.

[hallared]

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

[cryptonit]

Cryptonit (Helmut), thank you for sharing who you are, it´s nice to know it is "real" people working with DMD . 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  

[danbi]

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?

[cryptonit]

this news are great news for pools and exchanges!

thx danbi

[paladin281978]

... 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?  

[polanskiman]

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.

[stoody]

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

[polanskiman]

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

That's a good idea . 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

[danbi]

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.

[polanskiman]

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.

[cryptonit]

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 cloud@bit.diamonds
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:

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

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

Quote from: pallas on Today at 07:52:44 AM
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

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!
cloud@bit.diamonds
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.....

[cryptonit]

usecryptos prices starts to mirroring cryptsy
please move some more sell and buy orders there

[stoody]

71.654129 minted DMD so far...... few that was a long count lol

[polanskiman]

71.654129 minted DMD so far...... few that was a long count lol

Did you not see my post above?

[stoody]

lol yer i did mate... thanks but its not that bad to copy and past a few numbers... i had time

[cryptonit]

i see i see
a mined and minted coins stats overview in wallet is ur wish

per day per week per month and all time.....

i will check with danbi if thats possible

maybe when u force wallet to do a rescan of blockchain and we implement a code that it cound ur minted and mined blocks.......

lets see what is possible

[polanskiman]

i see i see
a mined and minted coins stats overview in wallet is ur wish

per day per week per month and all time.....

i will check with danbi if thats possible

maybe when u force wallet to do a rescan of blockchain and we implement a code that it cound ur minted and mined blocks.......

lets see what is possible

If that is possible, a simple total minted coins would suffice in my opinion. Could be added in parenthesis after the Balance in the overview tab such as:

Balance: 0.000 DMD (including 0.000 DMD minted)

or something like that.

[stoody]

i see i see
a mined and minted coins stats overview in wallet is ur wish

per day per week per month and all time.....

i will check with danbi if thats possible

maybe when u force wallet to do a rescan of blockchain and we implement a code that it cound ur minted and mined blocks.......

lets see what is possible

If that is possible, a simple total minted coins would suffice in my opinion. Could be added in parenthesis after the Balance in the overview tab such as:

Balance: 0.000 DMD (including 0.000 DMD minted)

or something like that.

i like that idea in the balance part that would be cool