great !! is this a fix for current zone117x's pool source or something new ?
Fix, it'll be a major github commit at that time. |
|
|
|
I have some comments on this. There has never been a hardfork of Monero. We're still operating on the same blockchain that TFT started back in the day. The original Bitmonero software can still sorta connect to and sync to the network, although it will get stuck at certain times because the software originally evaluated block rewards incorrectly and couldn't handle tx_extra. So, unlike other blockchains like DOGE or DRK, we've had zero hardforks up to now (just softforks). There are cases where the ByteCoin devs merged things in without review (seemingly), for instance a number of TFT's fixes. It's obvious that whoever owns the amjuarez ByteCoin repo trusts whatever TFT devs, which is unfortunate as he introduced a very severe mining bug into ByteCoin (which Monero fixed a while ago). The bug othe speaks of was first bypassed here: https://github.com/monero-project/bitmonero/commit/5ceffa8c8abb96bb8314939bf75c9b935ea7b5bcI caught it originally when I added checkpoints to the code and noticed that the blocks before checkpoints weren't having their PoWs checked, This was very dangerous, because it allowed you to upload random blocks to anyone syncing the client that corrupted the block database. So, I disabled checkpoints and then fixed it properly. https://github.com/monero-project/bitmonero/commit/3a3a8176782a4fa75b0607fba0393c9d4a1746be (blockchain_storage.cpp) and checkpointing flagging was turned on here: https://github.com/monero-project/bitmonero/commit/e7171250739790a5e5040264c4c1356ddeeea241BoolBerry has 100% the same code, so either they fixed it the same way independently or they used our fix. In either case, it was a very severe bug. |
|
|
|
^It seems you were using an old version of the source/binaries, so you didn't payed the right fees for the transactions. Download the latest one from the OP. Delete the poolstate.bin file (from %APPDATA%\bitmonero) and backup your wallet (the .keys file is the most important). Then delete the .bin file and run the wallet again to resync it with the network.
Am I correct to assume that if you have the deterministic wallet you don't have to back it up as it can be recreated from the seed? Yeah. Although you may want to test it to make sure you've got the seed correct. |
|
|
|
Hi There!
I'm eventually back again. Was working on several outstanding features nobody could overcome in the nearest future.
But now before going on and pushing updates I would like to ask the community for help and support. Not for free for sure. I've developed a very clean strategy for next actions.
I'm a developer, not so social as you can see)
I spend most of the time developing new features and polishing code.
As community can easily see, most of my work was abandonded due to lack of forum activity.
I see I need strong PR manager for Bitmonero project or a team that could take that business. It goes without saying smart people understand that currencty without strong engineering support (including mathematicians, developers) has no future. That's why I'm not so worry about current situation. The Monero team is doing good PR for me as well - when appropriate time comes, people will easily find out the real source and will figure out, what has real investment potential.
But now it is really sad to see where the clone is going. Throwing without a direction.
Even with the name they still not sure what they are developing.
MRO first, then XMR, is next name XXX to look more mature?
The way it was developed today and the past several months is just going nowhere. They still did not get the key idea of Bitmonero project. It requires thinking and understanding where is it going.
I have very clear vision about future development, and would like to make an offer for the community.
I also accept feature requests from users.
This message is an official call for oustanding PR sharks!
Please, PM me by 25.06.2014, answering simple questions:
0. What is the most outstanding result of your PR company?
1. How many people you can manage within a team?
2. What is your interest in supporting Bitmonero ?
Future is right there, next corner.
See ya,
I'm thankful_for_today
I'm not sure I should even say anything at all, since the tone of your message is condescending. In the past month, we've recruited several new developers to work on features that are generally non-functional on the daemon, fixed (vaguely) the txmempool but you commited that caused random blockreward destruction for miners, and hired a couple of academic mathematicians/cryptographers to review the implementation code and CryptoNote whitepaper. We got the pool implementation working and are close to GUI beta (amongst several other working betas based on .net for Windows). We fixed a number of other issues with the software and have a massive TODO list of things that need to be resolved. We extended ourselves to work with you and offered push/pull to the repo so you could push any changes you wanted to. I'm not sure what exactly else you needed from us. It appears that you wanted to remove the community here from any design and development aspects of the coin, which is counter to everything cryptocurrency has stood for up to this point. |
|
|
|
Of course, GPU miner was not ready on day 1. Brand new algo would take some R&D time. So far, we have an account of a single entity at a ~2x advantage (not exact figure: could be less, could be more). So essentially he has 2 CPU solo for every 1 CPU of joe public solo . And now the pools are gaining interest levelling the playing field.
I would not be surprised if a GPU miner was actually available on day one. Unfortunately (or possibly intentionally), the GPU implementation of Boolberry runs almost an order of magnitude faster on GPUs than CPUs on unoptimized code. Optimization was reportedly extremely easy for those who undertook it, ...Of course, the original CryptoNight implementation was crippled too without us realizing it, and we pushed the optimized code when it became available. But none of our core team had anything to do with that. |
|
|
|
Monero needs higher block time, at least 2 minutes like the regular Bytecoin. It's an already unscalable coin with high storage requirements where pruning won't work. Why make the problem worse with 1 minute blocks? Instead of forking to fix this problem while you still can, the can is being kicked down the road to be ignored until it can't be changed.
Also, this thread is severely lacking in free lunches. I made a call on XC that you would have more than doubled your money in a short time span buying it weeks ago in the thread.
Block time isn't as important to bloat, but rather the number of tx going on in the network and the number of outputs/inputs they have. The biggest issue right now is that the default node.js pool code creates very large amounts of bloats, likely bloating the blockchain 20 fold. We're working on patching the payment system for the pool now. |
|
|
|
Which part of the quote do you doubt?
This part: This is a good thing for the coin, and I would say definitely better than if it was cheap for a long time and then shot up in price. In the latter case it would be effectively premine from the late entrants' point of view and it might be rejected, similarly as I reject all the coins that are more than 10% mined when I hear about them. I guess it depends on how you qualify cheap though -- Bitcoin's price was obscenely cheap early on. I guess I wasn't sure if you were referring to Monero as being like this, though. |
|
|
|
Anyone watching Monero (XML) lately? Wow, it has been up to almost .005 BTC. There are rumors of Mintpal implimentation, might be a part of it.
Thanks to those who mentioned it, started picking some up at .0026, bit more at .0038-.0041. I feel ok in this range.
Mintpal anticipation I'm not sure we should care so much about mintpal Mintpal DRK 24h Volume 395.119 BTC Poloniex XMR 24h Volume 475.91 BTC Higher price gives more resources to the devs (who are typically large holders) and early investors, and makes all holders happy. This is a good thing for the coin, and I would say definitely better than if it was cheap for a long time and then shot up in price. In the latter case it would be effectively premine from the late entrants' point of view and it might be rejected, similarly as I reject all the coins that are more than 10% mined when I hear about them. I doubt it, there's still massive amounts of inflation (~23,040 coins to miners each day). http://monerochain.info/charts/coinsIt's not until 2-3 years in that we'll likely see obscene increases in price given simple economics. |
|
|
|
I seriously think the error size limit bug is on purpose. Keeps people from dumping the coins.
I have 137 XMR in my wallet, i can't even send 1 XMR to the exchange...
So...What to do?
set mixin to 0 and send smaller amounts, eg 0.5 MRO |
|
|
|
The transaction size limit only happened with small miners who received to many dust from pools. Normal users (like me) has no problem, i can transfer thousands of coins in one transaction smoothly.
Apparently the pool software need some fix, i don't know who is doing it.
We're waiting on zone117x to do it, if anyone is skilled with node.js, they can also implement it. https://github.com/zone117x/node-cryptonote-pool/issues/12Fix should do this this: 1.) keep track of all shares on the server and distribute reward per block for contribution internally 2.) allow the user to request manual payout or set auto payout threshold 3.) allow only payments in increments of 0.1 (because of the denomination code); do not allow payments smaller than 0.1 In the meantime, all smaller miners are recommended not to mine at moneropool.com or moneropool.org, as mining there will produce lots of dust if your HR is low. |
|
|
|
do you have an idea when the transaction size limit bug will be fixed??
Soon, it is in active development |
|
|
|
Rest assured I have fiddled with the daemon enough to know when it's stuck and when it's not. Of course there's a possibility the daemon functions perfectly normally otherwise but fails inexplicably when a block is found?  The version on master doesn't have this issue, but the old version does (if it found a block, it wouldn't broadcast it). You mean 0.8.7? 0.8.8 and 0.8.7 official release builds both had this issue The experimental master (current master) does not |
|
|
|
Rest assured I have fiddled with the daemon enough to know when it's stuck and when it's not. Of course there's a possibility the daemon functions perfectly normally otherwise but fails inexplicably when a block is found? The version on master doesn't have this issue, but the old version does (if it found a block, it wouldn't broadcast it). |
|
|
|
Small pools might not know when their daemons are stuck because they find blocks so inconsistently. Other possible issues could be they're using an outdated daemon or their ulimits aren't high enough.
Most likely this. Smaller pools should set a cron job to restart their daemon and wallet periodically, aside from raising ulimits. |
|
|
|
Peter R., the same "soft anonymity" you claim bitcoin can provide is also very much available in CryptoNote. But, the "hard anonymity" is also available in CryptoNote. You are very much able to prove your transactions, and as such there would be legal avenues under which retribution could be claimed. But, unlike bitcoin, it requires participation of both of the spenders (something that can be demanded in a court of law), rather than a rash abuse of something that should be private.
So if I sent you $1,000 and you didn't make good on your end of the deal, could I easily prove that? In any case, I should probably study the Cryptonote technology more closely because I'm actually not that clear on it. Yeah. There are two private keys to speak of, one which is used to recover your public key addresses (view key) and another which recovers your private key for those addresses (secret key). You could prove to a third party that you own the address by giving them the view key (which reveals that you own the public key) and then by signing from that public key using the private key that is generated for that public key via your secret key. For instance, the view key to our donations fund for development is e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703, which will let you out the outputs that are owned by that account on the blockchain. You can also disable ring signatures by setting mixin to 0, which means you spend directly from an input instead of mixing it with an arbitrary number of inputs (= mixin value). So, effectively, you can operate without privacy if you really want to. More simply: Ring signatures obfuscate inputs, stealth addressing obfuscates outputs, but both may be functionally disabled if you so choose. |
|
|
|
Would you still feel that we need more than one cryptocurrency if there was a sidechain that supported ring signatures (2-way exchange rate peg / bitcoins freely flow on and off the sidechain)? Or what if we could create anonymous tokens pegged to 1 : 1 with BTC using Gavin's recent Oracle idea?
Sidechaining is possibly unscalable, centralizing, and insecure. Aside from that, I would prefer to operate in a blockchain that has complete obfuscation from the start, rather than later, as you're going to run into the issue where authorities are going to be staring at the ledger and examining closely every movement into and out of the private chain. This activity is publicly visible for the Bitcoin blockchain and sidechains. I think a good question to ask might be: if you already had a cryptocurrency with high privacy, would you need to append a sidechain to it that didn't? |
|
|
|
This is what I get when I attempt to use the save_bc command (save blockchain): Error: Blockchain can't be saved: possible lost connection to daemon But in the terminal window for bitmonerod.exe it says: SYNCHRONIZED OK What am I doing wrong. It is a pain to have to continually wait for the blockchain to redownload each time I restart the bitmonerod.EXE file. Type 'save' in the daemon window. Also, if you type "exit" in the daemon window when closing, it automatically saves blockchain before exiting. That error is usually a bug as well, the daemon still usually saves the blockchain, it's just that the RPC timesout because the daemon is saving. Im on Windows 7 starter 32bit. This was never a issue with the previous deamon/wallet.
The deamon sync in its normal slow time. If I sync everyday then the deamon will take about 1/2hr to sync but this problem with simple wallet is unbearable
The issue is due to both stealth addressing and the tx dust from the pool software, which is still being fixed. In a CryptoNote coin, you must test each transaction output to check to see if it is owned by your private key. Therefore, as more tx emerge, it takes longer to scan the blockchain. There has got to be a better way to do this. If this ever gets used by many the sync time will be FOREVER. The problem right now is that obscene amounts of dust is being created by zone117x's pool software, which is causing slow resyncs. When the dust issue is properly addressed, this will be less of an issue. In the meantime, everyone should try to move their hashing power around to non-major pools in an effort to cut down on dust. Note that mining dust hurts your profitability as well, as you need to generate more tx (and spend more fees) in order to transfer it anywhere. |
|
|
|
Im on Windows 7 starter 32bit. This was never a issue with the previous deamon/wallet.
The deamon sync in its normal slow time. If I sync everyday then the deamon will take about 1/2hr to sync but this problem with simple wallet is unbearable
The issue is due to both stealth addressing and the tx dust from the pool software, which is still being fixed. In a CryptoNote coin, you must test each transaction output to check to see if it is owned by your private key. Therefore, as more tx emerge, it takes longer to scan the blockchain. |
|
|
|
|
Deterministic wallets have been merged back into master. The bug seemed to be an issue with the Microsoft 2012 VC compiler, and using the 2013 compiler seemed to fix these issues.
|
|
|
|
|
Show Posts
