[ANN] official NovaCoin thread - the original PoS+scrypt coin.

[brekyrself]

Are there any new developments with NovaCoin or new features in the works? 

[1713916062]

1713916062

[1713916062]

1713916062

[Balthazar]

Are there any new developments with NovaCoin or new features in the works?  

HD wallets and aliases for public keys (i.e. human readable addresses) are currently in the development.

Next snapshot will include a basic support for the deterministic private and public key trees generation.

[Sangsara]

The first block has been found and payments are working fine

Thanks for your help!!

Remember first 20 miners get 0% fee forever and everyone else 0% until Christmas!

http://novacoin.ecoining.com/

Thanks for joining us!

Hi,
please check "Contributor Hashrates" table:

Contributor Hashrates
Rank       User Name    KH/s    NVC/Day    USD/Day
1       anonymous    4,957    2.410    41.4520

i.e. 41.4520 / 2.410 = 17.2 $/NVC but now ~12.

[Balthazar]

You are lucky enough if block was found so quickly @ diff 370

[brekyrself]

Are there any new developments with NovaCoin or new features in the works?  

HD wallets and aliases for public keys (i.e. human readable addresses) are currently in the development.

Next snapshot will include a basic support for the deterministic private and public key trees generation.

Thanks for the update.  I feel this could be a successor to litecoin...

[glendall]

Hey if any super-knowledgeable person could help me out with this PoS question that'd be great.

So I have 2 nova wallets on 2 separate PCs. Both had balances transferred to them on the same day. About 30+ days later, one of the wallets generates a PoS block while the other does not.

1) Is this pretty normal? Is it correct to think that finding a PoS block is unpredictable, the chance increases as time increases ? Or in this scenario should they find blocks at the same time / same day?

The only difference between the two wallets is that the wallet that has not found a PoS block has been receiving a few coins from my mining. But I used a seperate address in the wallet for that, so that should not affect the coin-age of the balance that was already there, is my understanding. Is this correct?

2) After my first PoS block matures, should I transfer the new balance to another address in my wallet to restart the PoS process, or is it just as effective if I just leave it as is. Will a new PoS block eventually be found if I just leave it alone, once the new 'stake coins' return to my balance, without having to move the coins to a new address?

Thanks if anyone has the answers to these.

[Balthazar]

So I have 2 nova wallets on 2 separate PCs. Both had balances transferred to them on the same day. About 30+ days later, one of the wallets generates a PoS block while the other does not.

1) Is this pretty normal? Is it correct to think that finding a PoS block is unpredictable, the chance increases as time increases ? Or in this scenario should they find blocks at the same time / same day?

The only difference between the two wallets is that the wallet that has not found a PoS block has been receiving a few coins from my mining. But I used a seperate address in the wallet for that, so that should not affect the coin-age of the balance that was already there, is my understanding. Is this correct?

2) After my first PoS block matures, should I transfer the new balance to another address in my wallet to restart the PoS process, or is it just as effective if I just leave it as is. Will a new PoS block eventually be found if I just leave it alone, once the new 'stake coins' return to my balance, without having to move the coins to a new address?

Thanks if anyone has the answers to these.

1) It's a mining, just like with PoW. Block generation is a stochastic process, you can calculate average generation time but you can't predict the exact time.

There is no influence from incoming transactions, even if those transactions are sent to the same address. And you are right, block generation chances are growing in time.

2) No, you don't have to do anything. Age is calculated since input creation time and it doesn't matter how those inputs are created.

[Balthazar]

Next snapshot will include a basic support for the deterministic private and public key trees generation.

I suppose that deterministic keys generation feature will be ready for testing a few days later.

Some examples using incredibly experimental snapshot:

Root address 4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be (random key, created by OpenSSL):

Code:

validateaddress 4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be
{
     "isvalid" : true,
     "address" : "4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "020f253f0518bed2e7ca9faaaa13505fea6ed5f119dfca82c2aa6d6a05f69608d9",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : null,
          "depth" : 0,
          "sequence" : 0,
          "code" : "12d636d06b3f0b5f16c055e327b8eb1979968e8c9d76fbeec9db893952bbcdd1",
          "method" : 0,
          "generator" : "random"
     }
}

Root childrens (depth=1 nodes, created by private derivation function):

Code:

validateaddress 4Pe8Ma3xWsoNH3dv2UQgxREkpGuZVotNhM
{
     "isvalid" : true,
     "address" : "4Pe8Ma3xWsoNH3dv2UQgxREkpGuZVotNhM",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "03d1fe76c5d53aa67ce28f810d699e76a0790d64eb4df33695bfd73b26a4eb06c3",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be",
          "depth" : 1,
          "sequence" : 2147483648,
          "code" : "631304b49d0aad7c7ae6a0c1b7dc73ad4e285200cd08696fed3e21810cbdb400",
          "method" : 0,
          "generator" : "private"
     }
}

Code:

validateaddress 4HK9ASVuugmJFLgffyJy86UDjCBYEuoxtW
{
     "isvalid" : true,
     "address" : "4HK9ASVuugmJFLgffyJy86UDjCBYEuoxtW",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "02a3429445f4af9d8ea97854ce90b135c4f7f41e47a58171f2c3699ae617447812",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be",
          "depth" : 1,
          "sequence" : 2147483650,
          "code" : "968055d1b6e7ecd1d3176ce0c2b0462e35eb7b4c1e692e236ea22bb6ebdf1e53",
          "method" : 0,
          "generator" : "private"
     }
}

Code:

validateaddress 4ETWxpmDoR7mFUTLydB2qRkbxgcpyNs6CK
{
     "isvalid" : true,
     "address" : "4ETWxpmDoR7mFUTLydB2qRkbxgcpyNs6CK",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "03c79d8908215e56bb0c23cc33b37db5ae2329433fa7f7f0bc4d1d94b59686c721",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4F53LwSnLvWCj6AiDsipYR9rSvwQCmE4be",
          "depth" : 1,
          "sequence" : 2147483649,
          "code" : "f0fbeb0a8ad14c32094c12cd286f7176d24c7b5faa961b17b149aa4fa7fd09a2",
          "method" : 0,
          "generator" : "private"
     }
}

Depth=2 addresses (created by public derivation function):

4Pe8Ma3xWsoNH3dv2UQgxREkpGuZVotNhM's child address

Code:

validateaddress 4YpycyrHfyT8DPznsMRFfK3YfzjiqD6Jnx
{
     "isvalid" : true,
     "address" : "4YpycyrHfyT8DPznsMRFfK3YfzjiqD6Jnx",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "037eb093cf123e0ad5046b593d6296695667ce5f28c817a78a125c26c764655d89",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4Pe8Ma3xWsoNH3dv2UQgxREkpGuZVotNhM",
          "depth" : 2,
          "sequence" : 0,
          "code" : "989cf1b152adda25a167adcc84cdc33a3f135edc608b060d779950840c1367a5",
          "method" : 0,
          "generator" : "public"
     },
     "account" : ""
}

4HK9ASVuugmJFLgffyJy86UDjCBYEuoxtW's child address

Code:

validateaddress 4ZTVfWdK3CYSCyuKV5P3sXhuSdeXr56zme
{
     "isvalid" : true,
     "address" : "4ZTVfWdK3CYSCyuKV5P3sXhuSdeXr56zme",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "02ca0093fdda72840db9b9688423b6a400cb9b5c92c6d64f7de6c9670806063b24",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4HK9ASVuugmJFLgffyJy86UDjCBYEuoxtW",
          "depth" : 2,
          "sequence" : 0,
          "code" : "e1939b3e7b61f94bfa53e41b2ddb46f9b1e3e8e42f82edccfc038b26f54b3e04",
          "method" : 0,
          "generator" : "public"
     }
}

4ETWxpmDoR7mFUTLydB2qRkbxgcpyNs6CK's child address:

Code:

validateaddress 4GX3aZevqWP5Kdr23zVEbdgiyx5LDyf8SX
{
     "isvalid" : true,
     "address" : "4GX3aZevqWP5Kdr23zVEbdgiyx5LDyf8SX",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "03f95defede8c2af5b623fc449c624b1198798d435ee99ced5b4a824d185512b02",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : "4ETWxpmDoR7mFUTLydB2qRkbxgcpyNs6CK",
          "depth" : 2,
          "sequence" : 0,
          "code" : "ccd46f9594c443c2197f4cd0f604fc3e485f9fc77813becc0dea824f702f9bde",
          "method" : 0,
          "generator" : "public"
     }
}

Regular random address:

Code:

validateaddress 4GcWX4qwJoqKqQFitQLdhJ393Lo1U8Gq1E
{
     "isvalid" : true,
     "address" : "4GcWX4qwJoqKqQFitQLdhJ393Lo1U8Gq1E",
     "ismine" : true,
     "isscript" : false,
     "pubkey" : "03418392bb984cb6dc6dc06e919ed5c31c8172d574e7804743c46f899c87e422c9",
     "iscompressed" : true,
     "nodemeta" : {
          "parent" : null,
          "generator" : "random"
     },
     "account" : ""
}

P.S. Addresses are working, feel free to donate

[Balthazar]

By the way, about the keys... We haven't decided yet, should we remove a support for keypool & random keys approach or not... So, next releases will include support for the both approaches.

[Balthazar]

HD key support is almost ready, I'll receive and publish the pre-release patch tomorrow... Any testing would be helpful.

[KleinMatthias]

Hi,

Since not all users of this coin are as active as you are, may I ask for a feature in a future wallet version?

Please implement one of the following features:
1) an autoupdate feature which automatically keeps the QT updated without the user doing anything (or with the user just clicking an "update" button which only appears when new updates are available - but where the entire update process is done automatically)
2) a notification feature where the user can enter his eMail address into the wallet and the wallet sends him an eMail when a new version is available? That requires - of course - that the wallet has a way to check for updates. But since Microsoft/Apple/Adobe/andalltheothers can do it, so can you :-)
3) (for those who don't even run their QT all the time) a notification feature where the user can enter his eMail address into the wallet and the wallet sends that eMail address plus its own version information to a central server of yours which then sends out an eMail when a new software version is available. And which sends a warning eMail when a mantatory update has to be performed.

Naturally, as of today, the Cryptocurrency-community has been very active but with the price explosion of the Bitcoin last month, more and more "normal users" will enter the market.
They will not keep their wallet running all the time.
They will not check the forum all the time.
But they might spend hard cash on buying this coin at an exchange and then send it over to their wallet. As a community, we even need that kind of passive user - and we need their money buying this coin.
And when they find ways to spend or donate the coin, they will. And for that purpose they will open their wallets - but not in between.

Having said this, I personally prefer feature (3) because it has a few advantage over the other 2:

• It keeps even those "passive" users in the loop that do not run their wallet regularily.
• That way, if a really important change has to be made (e.g. a new blockchain), even those users won't lose their money because they get a notification. Think of the bad publicity when "normal users" start losing their money because they simply ignored their wallets for months only to find them not working anymore because weeks before, a new blockchain or equally invasive measure was introduced without them knowing.
• That feature can be extended for marketing purposes: add a checkmark "the makers of this coin are allowed to send me exciting news about this coin yaddayaddaya" - and voila you get yourself a free marketing database with tons of eMail addresses that you can use to keep engaging your users. Notify them of new shops where they can pay with this currency. Notify them of faucets. Notify them of exchanges that trade this coin. Notify them of the rise in value of that coin. And so on. Just keep engaging even the passive users - because to make a currency successful, you need every hand and every dollar you can get.

You guys and all the other professionals or those that have privacy concerns won't use that feature - and should never be required to do so. But the regular passive user will get that fuzzy feeling that he will be informed of important stuff without him spending much time checking bitcointalk or their wallets. And that will give him extra confidence when it comes to him spending the coin or buying the coin with his FIAT.

Just a few additional remarks:

• Naturally, the best possible combination would be (3) with (1) where the users gets a "move your ass and update your wallet or else..." eMail (friendly version, of course) - and then he opens the wallet and clicks on the "update" button and that's it for him.
  
• May be the required serverside portion (the thing that collects all version information and the eMail addresses and which also allows for sending out mass eMails to all users in that database) could be written in a generic way so that other virtual currencies can implement that feature, too?
• May be, future wallets should have a default setting that causes them to run in the background as a service whenever the computer starts. That way, even many passive users will contribute to the P2P network without them even knowing. But that was just a sideline remark and describes a completely different feature request. But then again, while you are at it... :-)

Don't know. What do you guys think about that feature request?
Does anyone second that request?
Does anyone have a better idea how to solve the above mentioned challenges that this new species of regular, passive users will introduce in the weeks and months to come?

Thanks
Matt
_{NVC: 4YcxgyWPSUhiU2UfBqbUrEk1Ca6pyBzzAW}


P.S. Just a full disclosure: I have posted this same feature request to the thread of some other cryptocurrencies as well.

[ocminer]

hey guys,

I've started a NVC Pool for testing:

https://www.novamine.co

Its Stratum + Vardiff with currently 0  % fee as long as it is in testing status.

SSL Certificate will be added soon.


Someone might give it a try, I'll get my rigs in tomorrow.

[brekyrself]

You guys and all the other professionals or those that have privacy concerns won't use that feature - and should never be required to do so. But the regular passive user will get that fuzzy feeling that he will be informed of important stuff without him spending much time checking bitcointalk or their wallets. And that will give him extra confidence when it comes to him spending the coin or buying the coin with his FIAT.

For the people who care about privacy, work with Invictus (Protoshares/bitshares/keyhotee) to add this feature and NVC into the Keyhotee software.

[Balthazar]

KleinMatthias
Actually there is no reason to worry, incompatible client will be rejected by the rest of the network, and then user will see the update notification.

There are no crypto currencies with automatic software update, and that's not a matter of privacy. It's a matter of security, an act of centralized distribution of malware is able to crash the entire P2P network.

http://www.h-online.com/security/news/item/Hacked-Kaspersky-server-deploys-scareware-1110984.html
http://techblog.avira.com/2013/06/27/opera-com-hacked-distributed-malware-signed-with-their-certificate-to-probably-thousand-of-users/en/

There's no way to guarantee that automatic update server won't be hacked or something like that.

[cabin]

Now that's a block!

[Balthazar]

Now that's a block!

< cut >

[Balthazar]

https://github.com/CryptoManiac/novacoin/commit/def6e8bd0d036ba0c41d1d38654bb2b454b5e296

For somebody who like to perform experiments.

Implements a basic support for deterministic keys generation.

Please note that this feature is very experimental for now. This code is incompatible with old wallet.dat format, don't try to run it in production or without backups.

This commit provides some new RPC commands:

* createroot [seed] - create a new root node from supplied or random seed
* dumpnode <novacoinaddress> - dump node into serialized data
* importnode <seriaizednode> [label] - create a new node using supplied serialized data
* getchildof <novacoinaddress> [fPrivate=false] [label] - get new child for supplied node
* listroot - list root nodes available
* listchild <novacoinaddress> - list a child nodes for a supplied address
* listorphan - list orphaned nodes, i.e. addresses without parent nodes
* listrandom - list randomly generated addresses
* rescan - similar to -rescan key

Removed RPC commands:

* keypoolrefill [n] - there is no keypool anymore, so we don't need this
* getnewpubkey [label]
* validatepubkey

Updated RPC commands:

* getnewaddress [label] - now creates a new child address for a public root instead of getting it from key pool
* getaccountaddress <account> - similar to getnewaddress
* dumpwallet <filename> - now able to dump HD nodes
* importwallet <filename> - now able to import HD nodes from file

No builds available yet, win32 and linux builds will be available later. Please read a commit description before trying to use it.

TODO:

1. Public key trees generation without unlocking of wallet;
2. Split wallet.dat into local transactions database and keystore;
3. Automatic recovery of key trees in case of database failure;
4. <...>

Win32 / Win64 build: http://sourceforge.net/projects/novacoin/files/experimental/novacoin-nosetup-0.4.4.7-test-windows.zip/download

[Balthazar]

Some examples of usage.

http://pastebin.com/vCjj8Ya6

• Key tree navigation (get a list of root nodes, move down from root to grand-grandchild);
• Node addition using a public and private derivation functions.

http://pastebin.com/zdBhmyHm

• Get a list of root nodes, create a new one using radom seed and validate it;
• Create 3 child nodes with private derivation function;
• Create  3 grandchild nodes using a public derivation.

http://pastebin.com/REf2pgTQ

Similar but using ultrasecure passphrase for root generation  

http://pastebin.com/Sy4qMwk0

Create new addresses and then get a child list for parent address.

[Mike270]

Hi Balthazar,

I like your support and the new features being added and would like to support that, but I see you don't have a Novacoin address in your footer (shame on you!! :-) ), so I'll wait and see whether you add one..

Kind regards
Mike

P.S.: Nice giving us the deterministic wallet feature - will there be included a feature into the client to print it out in a nice, good-readable way with basic instructions on what it is, plus a GUIey way to add it to the wallet? With more non-techy people entering into crypto, I think we need more user-friendliness than just a Text console somewhere in the menus.

[Balthazar]

Hi Mike

I like your support and the new features being added and would like to support that, but I see you don't have a Novacoin address in your footer (shame on you!! :-) ), so I'll wait and see whether you add one..

Hm... Actually I have it:

itzod bitcoin mining pool. 20 TH/s, 0% fee RSMPPS, no invalids. Custom diff / Stratum support.
฿: 1LaNK1ts1LLCkt5JGMxFYPpoStsfk886QQ Ł: Lah3GtpVPieFtvYms9QZUH87uJzvRA39NJ ₪: 4EWGRpkhPdpNT4hpV1dHZ42D9bVkBUz4Gb

 

Nice giving us the deterministic wallet feature - will there be included a feature into the client to print it out in a nice, good-readable way with basic instructions on what it is, plus a GUIey way to add it to the wallet? With more non-techy people entering into crypto, I think we need more user-friendliness than just a Text console somewhere in the menus.

This feature is very experimental for the moment and presented in a separate branch only. This client has no key pool and only way to generate new addresses is CKD function usage. "Create new address" button uses the CKD function too.

BTW, if everything will be fine with my network today, then I'll publish 0.4.4.6 update soon... This update should include optimized block index code.  

Testing results on celeron 880 with fully syncronized blockchain:

0.4.4.5 - block index load takes 126 seconds;
0.4.4.6 - block index load takes 7.26 seconds only.