|
Hi all,
As we know, scrypt profitability (or hashes required to solve for a block) can be represented in the following equation:
difficulty * (2^32) / blocktime = estimated_hashes_for_block
The equation differs for x11, however this is limited to the center part (2 to the 32nd power).
Does anyone know what this value needs to be to suit x11 algorithm coins?
james
|
|
|
|
|
i stand by my original comments; nothing to add.
you were provided with a working client and sourcecode, as well as plenty of testing.
the last binary sent was to ensure that you were indeed running the last compiled wallet; not the intermediary ones sent in the meantime.
the fact you've been quick to jump to accusations; then raise a 'scam accusation' thread, after being provided with source code and working binary, simply shows me and others that you aren't patient at all; the delay at the end would have caused little to no issues for either of us.
the work was paid for and completed; you have sourcecode and wallet, transaction complete - our last encounter i had sent the coins to you; and you were told that you will need to wait for the coins to stake for 12 hours, had you simply left the wallet open - they wouldve kept staking.
i'm leaving this where it sits, i havent had any negative dealings with this forum until the accusation you've raised now.
james
|
|
|
|
|
i stand by my original comments; nothing to add.
you were provided with a working client and sourcecode, as well as plenty of testing.
the last binary sent was to ensure that you were indeed running the last compiled wallet; not the intermediary ones sent in the meantime.
the fact you've been quick to jump to accusations; then raise a 'scam accusation' thread, after being provided with source code and working binary, simply shows me and others that you aren't patient at all; the delay at the end would have caused little to no issues for either of us.
the work was paid for and completed; you have sourcecode and wallet, transaction complete - our last encounter i had sent the coins to you; and you were told that you will need to wait for the coins to stake for 12 hours, had you simply left the wallet open - they wouldve kept staking.
i'm leaving this where it sits, i havent had any negative dealings with this forum until the accusation you've raised now.
james
|
|
|
|
all, have uploaded my fork of bitc to github ( https://github.com/mooncoindev/moonterm). this is a console-based spv mooncoin client that operates without a copy of the mooncoin blockchain.  this one's definitely for the tinkerers both mingw and cygwin fail to compile this for windows, cygwin gets very close after some hacking; however bitc utilizes some file-based functions that are experimental in cygwin and it trips up when writing the wallet to disk  james |
|
|
|
hello all, quick recap of events. was asked to help with the blockchain bloat of the existing hyper client, as cryptodatabase had pointed out it was a drain on system resources and ran slowly at times. i suggested moving to another client or restarting the chain with different parameters. had ended up reusing the existing hyper codebase with different parameters (back/forth correspondence below): last successful chain after coinbase generation (sent to cryptodatabase) @ 22032017 email addresses removed for privacy. confirmation of blockchain status @ 03042017 email addresses removed for privacy. cryptodatabase had forgot to enable staking in the client. the chain had sat stagnant for some time (staking not enabled on node coind); and i did not keep my copy of the wallet open for long after sending coinbase to cryptodatabase. confirmation the client had been working correctly, fired it up @ 12042017 and immediately started staking (my wallet): https://bitcointalk.org/index.php?topic=624651.msg18557094#msg18557094i was slightly irked that a scam accusation was in the works. i found out that cryptodatabase had started work with another dev (his perogative, no offense taken) and had received his new codebase; to find he wasnt provided with a windows compile: no compiled copy from new dev: https://bitcointalk.org/index.php?topic=624651.msg18580043#msg18580043to my knowledge neither the new hyper wallet has launched, nor has the coinswap taken place (as of today; 27th april 2017). i'd provided a node for it to stay on (since removed), clean source code and a compiled qt wallet (along with coinbase sent to him). additionally it was pointed out that a user had issues using the wallet on windows 7; which is odd, as my development VM runs windows 7. cryptodatabase had mentioned his financial motivations for the wallet refresh was due to owning a lot of HYPER; and it had recently been delisted by one exchange. as of now (27th of april, 2017); thecryptochat.net, where this offhand comment was made is currently down so i am unable to grab a screencapture to show this here. this is a big 'tell', so i won't place too much importance on it until i have the chat logs.  i've been a regular of this forum for some years; i'd welcome anyone who ive become friends with to comment here to provide me with some backing, as to being an honest character (being eccentric is not a personality flaw). james |
|
|
|
hello all, quick recap of events. was asked to help with the blockchain bloat of the existing hyper client, as cryptodatabase had pointed out it was a drain on system resources and ran slowly at times. i suggested moving to another client or restarting the chain with different parameters. had ended up reusing the existing hyper codebase with different parameters (back/forth correspondence below): last successful chain after coinbase generation (sent to cryptodatabase) @ 22032017email addresses removed for privacy. confirmation of blockchain status @ 03042017email addresses removed for privacy. cryptodatabase had forgot to enable staking in the client. the chain had sat stagnant for some time (staking not enabled on node coind); and i did not keep my copy of the wallet open for long after sending coinbase to cryptodatabase. confirmation the client had been working correctly, fired it up @ 12042017 and immediately started staking (my wallet):https://bitcointalk.org/index.php?topic=624651.msg18557094#msg18557094i was slightly irked that a scam accusation was in the works. i found out that cryptodatabase had started work with another dev (his perogative, no offense taken) and had received his new codebase; to find he wasnt provided with a windows compile: no compiled copy from new dev:https://bitcointalk.org/index.php?topic=624651.msg18580043#msg18580043to my knowledge neither the new hyper wallet has launched, nor has the coinswap taken place (as of today; 27th april 2017). i'd provided a node for it to stay on (since removed), clean source code and a compiled qt wallet (along with coinbase sent to him). additionally it was pointed out that a user had issues using the wallet on windows 7; which is odd, as my development VM runs windows 7. cryptodatabase had mentioned his financial motivations for the wallet refresh was due to owning a lot of HYPER; and it had recently been delisted by one exchange. as of now (27th of april, 2017); thecryptochat.net, where this offhand comment was made is currently down so i am unable to grab a screencapture to show this here. this is a big 'tell', so i won't place too much importance on it until i have the chat logs. i've been a regular of this forum for some years; i'd welcome anyone who ive become friends with to comment here to provide me with some backing, as to being an honest character (being eccentric is not a personality flaw). james |
|
|
|
|
Moon Lite token ready to launch tonight.
|
|
|
|
Nova Exchange has changed the blockchain confirmations from 999 to 250 !!!! Great news !!!
I'm glad to see that the latest additions to the codebase have qualmed any potential fears as to the blockchains stability; which are 100% reflected in the reduction of confirmations required from NovaExchange. Take a week away from cryptocurrency and so much happens!  james |
|
|
|
Hi all, Took a week away from cryptocurrency and what a wad-full of hate is in my inbox  I had been in talks with CryptoDatabase as to rebooting the existing Hyper chain; and had forgotten to mention manually kick starting staking in the client.  Has been running fine, I had disabled staking in my own client as I thought others had jumped in. Eagerly awaiting your response CryptoDatabase  james |
|
|
|
I already proposed that many months (years?) ago, but any change of the algo in that way was declined categorically by Mooncoin_Foundation.
i'd say probably for good reason to a point; not the easiest thing to do and guarantee compatibility, definitely not something you'd want a fly by night dev in charge of. so far argon2 has been mildly difficult to implement, but more patching, compiling, waiting and revising to be done. i had advised you that the reason for p2pool not working; is its requirement for getwork (p2pool requires getwork for low latency and this is why it works so well), as getblocktemplate isnt instant - in fact getblocktemplate (and its blocking of submitblock thread) has been responsible for many a lost bitcoin block over time. there are some classic back/forth jabs on github (or even here i think) between kano and luke-jr on this topic. getwork isn't impossible (nor that difficult) to reimplement back into the codebase, however i'm not sure if an argon2-based coin has ever been trialled on p2pool - might be an idea to ask around first. |
|
|
|
Is there a way to speed up blockchain confirmations? e.g. higher hashrate?
Confirmations can be taken two different ways; do you mean the amount of blocks it takes mined MOON to become spendable (COINBASE_MATURITY), or the amount of blocks required before MOON received can be spent, if it is sent to you by someone else? Hashrate will help, but due to the block difficulty retargetting algorithm it will always even out. Multiple confirmations in cryptocurrency are viewed as a good thing; as it means that the existing work has been proof'd multiple times, which aids in keeping the network secure. Quicker confirmations in everyway I suppose, however, when you say "it will always even out" due to the block difficulty retargeting algorithm, do you mean the speed will always even out? e.g. the higher the block difficulty the slower the confirmations, the lower the block difficulty the faster the confirmations, etc. If you apply a higher level of hashrate to speed the confirmations up; the difficulty retargetting algorithm will increase the difficulty of following blocks to compensate. |
|
|
|
Moonterm looks great like a simple lightweight client, and nostalgic at the same time.
MOON is nostalgic by itself. The era of Altcoin fairness has gone in 2014, but maybe back to the future?
If a common user is able to use it on Windows without downloading a full blockchain, it's great, it can be used for MOON Word recording onto blockchain transactions.
Does it require relying on a trusted node? Anyway can be usable with many purposes.
Definitely. It doesn't require a trusted node, the initial screenshot was slightly misleading. I actually switched from using clang as a compiler to gcc (clang was default on original repository), as a result it started binding to more than one host, was noticeably quicker and I can't get the send bug to occur. Fingers crossed. Perhaps a small dig at Apple (who put a lot of effort into clang's development)? Additionally, Apple users will be able to use this client as well, however it is not a favourable platform for me to work on; so support will be limited (treat yourself to a PC, you'll thank me for it). |
|
|
|
100%.
Thank you for MOON SPV-client.
Any chance for common users to use it with Windows or mobile devices - in future?
There is an assert issue that i'm debugging with send amounts at the moment (it is intermittent); but this is definitely possible for Windows, and i'd say the appeal of a nostalgic text-based client (even for a laugh despite being fully featured) would be there. It wouldn't actually be a lot of work either. For mobile though; Moonrush is still going to be the most suitable client. The reason behind the moonterm port - is actually to help me debug the sending issues that Moonrush was having pre-DDoS attack |
|
|
|
There is a suggestion to make these rewards 1/10 of current in the new release with CPU Argon2 mining.
It just will move MOON to satoshi markets, and miners will again have the same rewards in BTC, but very likely MOON will be listed at large exchanges and traded for BTC after you cut the inflation.
Who will support that?
I think this is a good idea; Mooncoin has matured and it is probably time to ease off on the generous block rewards, as to keeping its value steady. I hope i've added (some) value at least in my short tenure as dev. |
|
|
|
Additionally because i'm an eccentric character:moonterm (spv mooncoin console client)  fully working SPV-client (no blockchain required) ported from https://github.com/bit-c/bitc.gita very well written base for any SPV client, out of respect for the author i will keep the codebase name as is if there is sufficient interest i will release the source, i'm currently using it to learn about transaction constructor/serialization. (stay tuned for the commodore vic20 edition)
|
|
|
|
Hi all, Block reward changes as below:block: 1100000 reward: 17906 block: 1200000 reward: 16414 block: 1300000 reward: 15151 block: 1400000 reward: 14069 block: 1500000 reward: 13131 block: 1600000 reward: 12310 block: 1700000 reward: 11586 block: 1800000 reward: 10942 block: 1900000 reward: 10366 block: 2000000 reward: 9848 block: 2100000 reward: 9379 block: 2200000 reward: 8953 block: 2300000 reward: 8564 block: 2400000 reward: 8207 block: 2500000 reward: 7878 block: 2600000 reward: 7575 block: 2700000 reward: 7295 block: 2800000 reward: 7034 block: 2900000 reward: 6792 block: 3000000 reward: 6565 block: 3100000 reward: 6353 block: 3200000 reward: 6155 block: 3300000 reward: 5968 block: 3400000 reward: 5793 block: 3500000 reward: 5627 block: 3600000 reward: 5471 block: 3700000 reward: 5323 block: 3800000 reward: 5183 block: 3900000 reward: 5050 block: 4000000 reward: 4924 https://github.com/mooncoindev/moonschedule contains code showing the function working (as extracted from mooncoin 0.10.5) baz |
|
|
|
Is there a way to speed up blockchain confirmations? e.g. higher hashrate?
Confirmations can be taken two different ways; do you mean the amount of blocks it takes mined MOON to become spendable (COINBASE_MATURITY), or the amount of blocks required before MOON received can be spent, if it is sent to you by someone else? Hashrate will help, but due to the block difficulty retargetting algorithm it will always even out. Multiple confirmations in cryptocurrency are viewed as a good thing; as it means that the existing work has been proof'd multiple times, which aids in keeping the network secure. |
|
|
|
|
Other pools and block explorers; can you please update to the latest commit available on github.
Or at a minimum; attempt to restart your current node with -maxtipage=999999.
A lot of code concerning optimization/correct behaviour of getheaders was introduced - and i notice that a lot of early 0.10.5 clients simply display the following after a 'getpeerinfo':
"synced_headers" : -1
"synced_blocks" : -1
|
|
|
|
|
Show Posts
