Nice to see the action behind Hashrate rally, it will be a new Hashrate rally on September with some new rules.
|
|
|
Very nice, as i said DigitalNote services Age is on the way
|
|
|
DigitalNote "generation" transaction has no dust and very small and good for mixing and SMALLEST CryptoNote transaction, because of outputs structure (only 2 outputs with static block reward and no dust, because of halvings. 150 block reward= 100and 50). DigitalNote "generation" transaction size = 130 bytes (i take min. nowdays value!), and average XDN "empty" block = 174 bytes. I'm curious why you didn't just make it 100 or 200 which would have been even smaller (one output), about half the size instead of 150 (two outputs). BTW, I don't see the point of rehashing a bunch of bickering from February, clearly everyone has moved on and continued development since then. If trolls are digging that stuff up to create conflict, it would probably be better to just ignore them. There were some "1" outputs when there was a duck->dark time, so XDN blockchain had a periods of "1" output. Although 100 + 50 with 2 outputs is an "ideal" variant, IMO. Agree with your BTW, @smooth. Any way i am not going to conflict with someone, just answering questions, no anger here.
|
|
|
Hello dNote, Look what fluffy_troll a trollero dev is talking about you. I think is disgusting trolleros devs makes such comments about another dev. As for me - monero is a biggest bubble, because there is only speculation about it
Of course there's speculation. But there is also actual use. <-Actual use? Look at XMR blocks and transactions count, i can see lots of "empty" blocks here http://chainradar.com/xmr/blocks blockchain is unusable with its size
How do you suppose you'll have a usable cryptocurrency that is actually used, and yet not have an ever-growing blockchain? What a silly comment, it really shows the desperation of this trolling. <-Sorry, i may said it in the way you didn`t get me. I mean № of blocks (more than 500 000 after just one year), big size of blockchain, lots of "dust" there, with "bad" outputs. IMO almost everything about monero seems terrible - unusable blockchain size (On average PC, it just can`t be a network node)
Runs just fine on a Raspberry Pi 1 with 256mb RAM, so I guess he must be talking about running it on a 486 DX2 66. <- Read previous statement. block intervals
Chosen by...thankful_for_today! And here I thought you were hailing him as an incredible human being? <- So you can change everything if you want and can. tx generation size
Is duck dark digital dontcareNote really trying to claim that their transactions are significantly smaller? <- Yes, for sure, XDN DigitalNote (duck, Dark) transactions are significantly smaller, not only transactions, but all "mixing process" is much more efficient, avoiding dust. Let me show you: DigitalNote "generation" transaction has no dust and very small and good for mixing and SMALLEST CryptoNote transaction, because of outputs structure (only 2 outputs with static block reward and no dust, because of halvings. 150 block reward= 100and 50). DigitalNote "generation" transaction size = 130 bytes (i take min. nowdays value!), and average XDN "empty" block = 174 bytes. http://chainradar.com/xdn/block/59e82fb50a8690ce37c3ee3887671894fe96c5b53dfdc1fbbd2b8e32c8d9416chttp://chainradar.com/xdn/blocksMonero XMR average generation transaction consist of min. 4 outputs with dust now and lots of XMR blockchain transaction outputs consists lots of "dust", bad for mixing, bad for blockchain size. Average XMR "generation" transaction size = 209 bytes (i take min. nowdays value!) and average "empty" block = 253 bytes. http://chainradar.com/xmr/block/3ce1606a4741d65f8c6cf9fa879b74c7af0c955912adf2457ca55b121a8b4f1cSo lets compare. Lower values are better. DigitalNote XDN vs Monero XMR transaction and block size. Generation tranaction size 130 vs 209 <- XDN wins >60% over XMR here"Empty" block size 174 vs 253 fee size
0.001 XMR per kilobyte (most transactions are 1kb-2kb), so that's about $0.0000056 per transaction. Gosh. So expensive. <- okno GUI after almost 1 year since start
Wrong. There are several GUIs: https://getmonero.org/getting-started/choose<- Show me native cross platform (Linux, OsX, Windows) GUI that i can build myself? I can`t find any open-source Monero GUI with described specifications, and only with this specifications there is a need in this GUI. totally wrong way of development
As opposed to dNote, which has the "totally right" way of development, no? If that's the case, then why have they attracted NO other contributors? https://github.com/xdn-project/digitalnote/graphs/contributors vs. https://github.com/monero-project/bitmonero/graphs/contributors<- First, thank you, xdn-project repo is new, second and main one - you, guys, have much a bigger mouths and time to spend on shouting. looks like just no understanding of CN technology.
Looks like I've got to rehash some of our research bulletins. Let's do this one: MRL-0003: Monero is Not That Mysterious<- Looks like too many words and much less features and important improvements.
|
|
|
Hello dNote,
Look what fluffy_troll a trollero dev is talking about you.
I think is disgusting trolleros devs makes such comments about another dev.
Can you please give me a link to that and i will answer directly. Thank you.
|
|
|
Will add some of DigitalNote XDN comparison here in a few days.
|
|
|
I like your approach, Sir, @rpietila. Would be nice to see some of your attention with $XDN.
|
|
|
1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.
Feels strange to me. Why sacrifice original CryptoNight? We are going to very strong ARMs now, with lots of fast cache, look at MediaTek, look at Apple A7/A8, look at AMD servers with arms, pretty good performance for an original CryptoNight. I got your idea, but i think in that case "light" cryptonight will be less secure.
|
|
|
You guys rock! It sounds like the aliases will be super easy to use, just like the rest of what DigitalNote does.
Yes, we are working to make it easy for web developers and services integration. DNS+JSON-API will be very useful for any cryptocurrency alias, including Bitcoin.
|
|
|
By the way we are working on ALIAS, but not OpenAlias, but our own Digital Aliasing system, made for web. Not only DNS, but DNS + JSON API. For all cryptos, but made for DigitalNote. Very flexible and easy for both users and developers. With the Aliasing we will introduce a ready to use platform based on it for free aliasing, as well as your own platform building instructions. Stay tuned.
Couldn't you just slap a JSON-API on top of OpenAlias? I mean, why create yet another standard if the existing one is battle-tested and works fine? we always create our own standards, we don`t want to fork/copy any of features of any of coins, like you can see how far is DigitalNote from any other CryptoNote: "d" in address (with extra letter), supply structure -> no dust generation outputs, messages, blockchain banking, etc, etc, etc, we keep work to provide #1 proof-of-work cryptocurrency with true value because of its features. OpenAlias was good, but we are going to make some better stuff. And DigitalNote aliases will include all OpenAlias features, but updated, with JSON-API and with different easy to use structures.
|
|
|
By the way we are working on ALIAS, but not OpenAlias, but our own Digital Aliasing system, made for web. Not only DNS, but DNS + JSON API. For all cryptos, but made for DigitalNote. Very flexible and easy for both users and developers. With the Aliasing we will introduce a ready to use platform based on it for free aliasing, as well as your own platform building instructions. Stay tuned.
The age of DigitalNote services is coming.
|
|
|
According to your log, it looks like you have a problem with building only connectivity_tool (not a critical issues to run digitalnote). And you may not have any problems with building digitalnoted and simplewallet. Check it, please. Maybe for some reason, you had some older source code, so after you made "git pull" and made a building of the digitalnote in the same folder. In that case you should regenerate makefile with CMake and try to build it again.
|
|
|
Hummm v2 version, what's the difference between the v1 and v2 ?
v2 is for console wallet, not GUI wallet. Before it was 2.0.9-beta, now it is 2.0.10-beta. With every fix or improvement, version number goes +1 at the end: 2.0.*-beta, so next will be 2.0.11-beta, after 2.0.12-beta, etc Same with GUI: 1.0.3-beta, 1.0.4-beta, 1.0.5-beta, etc.
|
|
|
bump! Hi. I'm trying to compile the new XDN code on mint 17. Getting these errors. Any ideas. Thanks (...) cc9icLts.ltrans8.o:(.text+0x2adc): undefined reference to `epee::log_space::log_singletone::get_prefix_entry()' cc9icLts.ltrans8.o:(.text+0x2b97): undefined reference to `epee::log_space::log_singletone::do_log_message(std::string const&, int, int, bool, char const*)' cc9icLts.ltrans8.o:(.text+0x2bbc): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' cc9icLts.ltrans8.o:(.text+0x2bca): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' cc9icLts.ltrans8.o:(.text+0x2d34): undefined reference to `epee::log_space::log_singletone::get_prefix_entry()' cc9icLts.ltrans8.o:(.text+0x2de4): undefined reference to `epee::log_space::log_singletone::do_log_message(std::string const&, int, int, bool, char const*)' cc9icLts.ltrans8.o:(.text+0x2e09): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' cc9icLts.ltrans8.o:(.text+0x2e17): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' /tmp/cc9icLts.ltrans9.ltrans.o: In function `void epee::serialization::convert_int_to_uint<signed char, unsigned long>(signed char const&, unsigned long&)': cc9icLts.ltrans9.o:(.text+0x933): undefined reference to `epee::log_space::log_singletone::get_prefix_entry()' cc9icLts.ltrans9.o:(.text+0x9e0): undefined reference to `epee::log_space::log_singletone::do_log_message(std::string const&, int, int, bool, char const*)' cc9icLts.ltrans9.o:(.text+0x9ff): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' cc9icLts.ltrans9.o:(.text+0xa0d): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' /tmp/cc9icLts.ltrans9.ltrans.o: In function `void epee::serialization::convert_int_to_uint<short, unsigned long>(short const&, unsigned long&)': cc9icLts.ltrans9.o:(.text+0xb84): undefined reference to `epee::log_space::log_singletone::get_prefix_entry()' cc9icLts.ltrans9.o:(.text+0xc31): undefined reference to `epee::log_space::log_singletone::do_log_message(std::string const&, int, int, bool, char const*)' cc9icLts.ltrans9.o:(.text+0xc50): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' cc9icLts.ltrans9.o:(.text+0xc5e): undefined reference to `epee::log_space::log_singletone::get_set_err_count(bool, unsigned long)' /tmp/cc9icLts.ltrans9.ltrans.o: In function `void epee::serialization::convert_int_to_uint<int, unsigned long>(int const&, unsigned long&)': (...)
Please, provide more info about your error, copy-paste all your logs about that.
|
|
|
DigitalNote XDN http://digitalnote.org has Cryptonight pow and 6th perfect number as a coins number and a classic bitcoin halving with no blockchain dust
|
|
|
Another reason is a security. Since https://mymonero.com/ is a centralized app (or am i wrong) it is quite critical to observe the source code. There is a back end that is not released, but the functions it performs are relatively simple, and do receive the spend keys at all (see next sentence). Most of the functionality, including all operations on spend keys, are done using JavaScript code you can view in your browser. But back end matters. Why just not to release a full source code for everyone to check it. If we are talking about wallets for "money units" transfer closed source code is a critical issue for trust. It has been stated that it will be released. For security of funds the back end does not matter. The transactions are created and signed in the front end. The back end simply relays them, which is no different in function from any other node. For the money transferring operation every part of source code matter. I do not know what do you have at back end => why should i trust you? You may spy on my transactions (i don`t say you do), or do anything you want. I'm pretty sure it is stated in the terms of service that MyMonero does monitor your transactions to some extent (indeed it has to in order to function). If you want the highest level of privacy you should use your own private wallet (and also take care to prevent network-level spying). So there is no issue of security with spying, since that is part of the normal functioning. If you are concerned about the security of your funds you can review the JavaScript to see that the private spend keys are never sent to the back end (only view keys are). Ok. But anyway, some day i would like to see a source code.
|
|
|
|