8pool work for Quazar Coin!
www.8pool.dtdns.net
qcn.8pool.dtdns.net
Current net hash 54 khs
Exchange hitbtc.com
Topic: [ANN] [QCN] QuazarCoin | Full privacy&data protection | Egalitarian PoW - page 10. (Read 186555 times)
January 17, 2015, 07:51:59 AM
January 05, 2015, 02:05:03 AM
Is Dev gone? QuazarCoin dead ?
full member
Activity: 882
Merit: 102
PayAccept - Worldwide payments accepted in seconds
December 12, 2014, 03:04:57 AM
this needs more exchanges
December 10, 2014, 06:42:03 AM
Hey guys,
Updated chainradar.com with pools information!
Find a pool best suited for yourself and you currency. Provided pool info: Name, Other coins, Version, Fee, Minimal payment, Miners, Hashrate, Uptime, Last server down.
Please don't hesitate to contact me through the contact form on the website or via the forum.
Updated chainradar.com with pools information!
Find a pool best suited for yourself and you currency. Provided pool info: Name, Other coins, Version, Fee, Minimal payment, Miners, Hashrate, Uptime, Last server down.
Please don't hesitate to contact me through the contact form on the website or via the forum.
November 24, 2014, 07:45:18 AM
November 19, 2014, 05:21:40 PM
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.
Thank you for the info. You're doing a lot of work. Just go on and you'll reach the success
Best Regards, Cornett
November 19, 2014, 01:23:44 PM
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.
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.
November 19, 2014, 01:11:34 PM
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.
November 11, 2014, 12:32:12 PM
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.
November 10, 2014, 10:33:39 PM
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+.
November 10, 2014, 11:54:32 AM
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...
November 10, 2014, 10:56:50 AM
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.
November 10, 2014, 08:16:54 AM
mixin = 2-5 is OK. The effectiveness depends the number of total transactions in one block. The more transactions, the better.
November 10, 2014, 05:22:22 AM
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.
November 09, 2014, 08:56:15 PM
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?
November 09, 2014, 03:50:50 PM
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?
November 09, 2014, 11:40:49 AM
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.
November 08, 2014, 09:50:47 PM
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 [ ... ] [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?
transfer
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?
November 08, 2014, 12:45:44 PM
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.
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.
November 05, 2014, 10:40:52 AM
everything took a hit in this last QT (dragged down by BTC) worry not, just make sure blockchain is stable which it is
Jump to: