[ANN] [QCN] QuazarCoin | Full privacy&data protection | Egalitarian PoW

[OrientA]

Important update!

Please upload the new binaries

Win64
Mac OS X
Linux
Source

It has been a long time since I posted anything new and now I'm presenting you with a fresh release with some important updates. First of all, they will help with the upcoming big things and secondly I'm sure you will appreciate them as users.

• The high-level API for wallet and node has been implemented. Devs will be able to create new services conveniently and quickly. This update allows to finalize a cross-platform GUI wallet in the nearest future.
• The CryptoNight hash function was optimized to top speed.
• Blockchain now occupies 450 Mb instead of 1.3 Gb because it has been transferred from the RAM.
• Blockchain is no longer different depending on OS. There are 3 files instead of 1. You will need the blockindexes.dat & blocks.dat files in order to synchronize. The blockscache.dat file will be created by the daemon while processing in order to get the blocks quicker.

I've uploaded new blockchain, you can download it here.

Does Cryptonote.org supply the the new update or do you implement the above yourself?

[smooth]

Important update!

Please upload the new binaries

Win64
Mac OS X
Linux
Source

It has been a long time since I posted anything new and now I'm presenting you with a fresh release with some important updates. First of all, they will help with the upcoming big things and secondly I'm sure you will appreciate them as users.

• The high-level API for wallet and node has been implemented. Devs will be able to create new services conveniently and quickly. This update allows to finalize a cross-platform GUI wallet in the nearest future.
• The CryptoNight hash function was optimized to top speed.
• Blockchain now occupies 450 Mb instead of 1.3 Gb because it has been transferred from the RAM.
• Blockchain is no longer different depending on OS. There are 3 files instead of 1. You will need the blockindexes.dat & blocks.dat files in order to synchronize. The blockscache.dat file will be created by the daemon while processing in order to get the blocks quicker.

I've uploaded new blockchain, you can download it here.

Does Cryptonote.org supply the the new update or do you implement the above yourself?

I reviewed most of the changes and they are merged from the cryptonote code.

[OrientA]

Does Cryptonote.org supply the the new update or do you implement the above yourself?

I reviewed most of the changes and they are merged from the cryptonote code.

Is it from their August update?

[smooth]

Does Cryptonote.org supply the the new update or do you implement the above yourself?

I reviewed most of the changes and they are merged from the cryptonote code.

Is it from their August update?

Some of it is from June, but I didn't carefully trace every change.

[weret]

What are some recent developments? There haven't been much on Twitter for a bit.
Is there a possibility that QCN will be back on Poloniex?

[OrientA]

What are some recent developments? There haven't been much on Twitter for a bit.
Is there a possibility that QCN will be back on Poloniex?

I do not think it will be back on Poloniex in the near future. Even the volume of XMR is about 50 BTC per day recently, although it is the most traded coin there.

[q327K091]

everything took a hit in this last QT (dragged down by BTC) worry not, just make sure blockchain is stable which it is

[CoolGecko]

Hi everyone. I haven't posted for a while and thought I'd let people know what is going on in the Quazarcoin HTML wallet project that I'm working on. The following pretty much sums it up. I plan to make a github page for it in a about a week:

Quazarcoin HTML wallet - Features

Graphical scaling proportional to screen width: everything is scaled including the fonts. The idea behind this is that portable devices should have smaller fonts because they are held closer to the eyes. This should make the wallet easier to adapt to portable devices.

Multi screens: selected with tabs. Currently there are have 5 buttons: “Overview”, “Incoming” (transactions), “Outgoing” (transactions), “Send” and “Other”. I plan to put functionality that is used less often in “Other”. The first 2 screens are fully implemented and working. I plan to limit the buttons to 5, because I'm reserving space for other things.

Has status messages, and I plan to add indicators for loading blockchain and for the number of connections.

Runs on modern web browsers, e.g. Chrome and Firefox (and hopefully IE 10 -  I haven't tried it), but currently requires the installation of Node.js (which is freely available for the various OSs)

Requires simplewallet and quarcoind to be running and synced. This currently needs to be done manually, but I would eventually like to make that automatic.

Communicates with simplewallet and quazarcoind through a CORS enabled proxy server at localhost:6080. If at some point in the future, CORs support is added to simplewallet, I'll be able to eliminate the proxy. Currently Node.js is required because of the proxy server.

Transfers with the same TXID are summed to get entire transactions. They can be displayed either way, as transaction or transfer lists. They are displayed in reversed order, so the most recent are on top.

Currently consists as 6 files. These files must be installed in the same folder as Node.js (or a subfolder). They do not need to be in the same folder as  simplewallet and quazarcoind; they only need to be located on the same computer.

Values on the screen are refreshed every 20 seconds through AJAX. I can make the refresh rate settable by the user, if that's something that people care about . All network communications are non-blocking.

Written in XHTML5, CSS, Javascript and SVG. For the most part, it is platform independent. The only parts that are platform dependent are starting simplewallet and quazarcoind, and the proxy server.

Since the functionality depends only on the Quazarcoin RPC API, in most cases when simplewallet is upgraded the HTML wallet won't need to be upgraded. That is true because the API most likely won't change, except possibly for API extensions. As long as the old RPC calls haven't changed an update shouldn't be required.

[CoolGecko]

I'm now working on getting the transfers part of the HTML wallet working and have questions; I'd like to understand what's going on before implementing it. Here is the command for doing a transfer on the simplewallet terminal:

transfer <mixin_count> <addr_1> <amount_1> [<addr_2> <amount_2> ... <addr_N> <amount_N>] [payment_id]

What does the "mixin_count" mean. Is that the number of standard amounts that each amount you send is broken down to? So if someone sent 3 amounts and with a mixin_count of 5 there would be 3x5 (15) transfers?

About the payment_id, I looked at the code and they say it should be a 64 character string. Where does that come from? It doesn't sound like something that they would expect the user to make up.

I'm doing input checking and making it as strong as possible. For the coin address fields it looks like they are base 58. Is this the exact same base 58 that bitcoin uses? And about the first character of the addresses, I know that other altcoins start with specific characters like "1" or "N", and some coins have several possible characters that they can start with. What are all the possible characters that Quazarcoin can start with?

[OrientA]

The payment-id is given to you by the receiver to differentiate you from other payers as there is only one address in a wallet. That is different from Bitcoin which has one private key and numerous public address created by the private key.

[CoolGecko]

The payment-id is given to you by the receiver to differentiate you from other payers as there is only one address in a wallet. That is different from Bitcoin which has one private key and numerous public address created by the private key.

Is that id made up by the receiver or is it a specific identifier generated by the wallet? They say that it should be a 64-character identifier. I tried sending funds and plugged in a 64-character id with different letters and numbers and it was rejected. Then I tried a 64-character hexidecimal id and it seemed to accept that. So it seems what they want is a hexidecimal number with characters 0..9 and a..f. When I generated the wallet they gave me a 64-character hexidecimal number called the "view key". I'm just guessing, but is that the number that should be used. If I wanted someone to send me coins, would I have to sent that number first?

[jwinterm]

The payment-id is given to you by the receiver to differentiate you from other payers as there is only one address in a wallet. That is different from Bitcoin which has one private key and numerous public address created by the private key.

Is that id made up by the receiver or is it a specific identifier generated by the wallet? They say that it should be a 64-character identifier. I tried sending funds and plugged in a 64-character id with different letters and numbers and it was rejected. Then I tried a 64-character hexidecimal id and it seemed to accept that. So it seems what they want is a hexidecimal number with characters 0..9 and a..f. When I generated the wallet they gave me a 64-character hexidecimal number called the "view key". I'm just guessing, but is that the number that should be used. If I wanted someone to send me coins, would I have to sent that number first?

payment id is any 64-character hexadecimal string that is typically generated by the receiver (at this point usually just exchanges), and then given to the sender to prove that they are the one sending the coins. It is totally separate from your view key; the view key tooling is not implemented yet, but it would allow you to prove that you sent a tx without a payment id.

Also, the mixin count is the number of other identical transactions to "mix" with. It is essentially the degree of anonymity - the higher the mixin count, the more anonymous the tx is, but the larger (in terms of bytes) it will be.

Are you planning to make the html/js wallet open source?

[CoolGecko]

The payment-id is given to you by the receiver to differentiate you from other payers as there is only one address in a wallet. That is different from Bitcoin which has one private key and numerous public address created by the private key.

Is that id made up by the receiver or is it a specific identifier generated by the wallet? They say that it should be a 64-character identifier. I tried sending funds and plugged in a 64-character id with different letters and numbers and it was rejected. Then I tried a 64-character hexidecimal id and it seemed to accept that. So it seems what they want is a hexidecimal number with characters 0..9 and a..f. When I generated the wallet they gave me a 64-character hexidecimal number called the "view key". I'm just guessing, but is that the number that should be used. If I wanted someone to send me coins, would I have to sent that number first?

payment id is any 64-character hexadecimal string that is typically generated by the receiver (at this point usually just exchanges), and then given to the sender to prove that they are the one sending the coins. It is totally separate from your view key; the view key tooling is not implemented yet, but it would allow you to prove that you sent a tx without a payment id.

Also, the mixin count is the number of other identical transactions to "mix" with. It is essentially the degree of anonymity - the higher the mixin count, the more anonymous the tx is, but the larger (in terms of bytes) it will be.

Are you planning to make the html/js wallet open source?

Thanks to both of you; that clarifies things a lot. What do you think is reasonable range for mixin numbers? When the transfer command is sent to the wallet, they do input testing before the funds are transferred, yet I'm doing some preliminary testing as the keystrokes are entered.

Yes the wallet project I'm working on will be open source. I'm using mostly GPL licensed software and was planning on making it the same. I'm putting up a github page for it, but would first I'd like to get the transfer funds (I'm calling it "Send") screen working.

[OrientA]

mixin = 2-5 is OK. The effectiveness depends the number of total transactions in one block. The more transactions, the better.

[CoolGecko]

mixin = 2-5 is OK. The effectiveness depends the number of total transactions in one block. The more transactions, the better.

Great, I'll set the range to that for now. Thanks a lot; you have been very helpful.

[jwinterm]

mixin = 2-5 is OK. The effectiveness depends the number of total transactions in one block. The more transactions, the better.

afaik it doesn't depend on the number of txs in one block, it depends on having inputs existing any time previous in the blockchain. Also, you might want to make an option for mixin 0 and 1, so that people can send non-anonymous transactions. Maybe just make a warning text popup when mixin is low or something...

[smooth]

mixin = 2-5 is OK. The effectiveness depends the number of total transactions in one block. The more transactions, the better.

afaik it doesn't depend on the number of txs in one block, it depends on having inputs existing any time previous in the blockchain. Also, you might want to make an option for mixin 0 and 1, so that people can send non-anonymous transactions. Maybe just make a warning text popup when mixin is low or something...

1 is useless and harmful. 0 might be useful under certain circumstances (and is necessary when there aren't enough outputs of the same size to mix at all).

The useful mixing counts are 0 and 2+.

[CoolGecko]

I already wrote the code and used the values 0..5. I don't want to be real restrictive in the values that I allow. I just don't want to allow crazy values that might cause problems. I wrote it as a regular input, where you just enter it on a keyboard, but I'm thinking that I might change it to a selector where you select 1 of 6 values. That way I can put short comments beside each value. Getting the range right isn't a big deal, because this is something that can be easily changed in the future.

[CoolGecko]

Sorry, I haven't created a Github page for the wallet yet because I ran into a problem. I discovered that when I enter large transaction values, the transaction values get truncated. It turns out that Javascript only supports about 15 1/2 digits accuracy before it starts truncating. I would expect it to be much larger than that on the 64bit machine that I'm using, but Javascript math is based on a ECMA standard that I think is about 52bits precision for positive floating point and 31 bits precision for positive integers. I made an arbitrary precision math module, which partially solves the problem. I also need to do something about the RPC client. The RPC client, converts the coin value string transmitted over the network to a javascript number. Maybe I'll have to modify that so it doesn't parse the string to a number, but leaves it as a string, which isn't limited. I need to add these numbers up and the math module has a function that adds up character strings representing numbers of any size. So it will be a while before I put up the github page; I need to get this stuff working first.

[CryptoNote.eu]

If you are interested in general cryptonote-related chat:
Please join the channel #cryptonotes on the Freenode IRC network.

If you are new to Freenode or IRC in general, please see https://freenode.net/ for infos how to join chatroom.