Going with Cryptonight Monero AuxPoW would just be handing all the newly hashed coins over to botnet 'owners'. Could you describe what the problem with botnets is? I am admitedly ignorant here, but from what I understand, this is not a big deal. If you look at Monero pools you'll see lots of miners with hashrates equivalent to 20,000 CPU cores and more and it wouldn't be profitable for people to buy or rent that many CPU cores. So they're very likely using stolen processor cycles from infected computers that are controlled within a botnet. Some large botnets can control the resources of up to a million infected computers without the legal owners of those computers even knowing. These botnets get to use the spare CPU cycles and memory of the infected computers. So adopting the cryptonight hashing algo would mean handing over the overwhelming majority of all newly hashed coins to a few small groups of criminals. Going with a GPU biased hashing algo would give dedicated miners an advantage over the criminal owners of botnets. Although if Anoncoin or the coins it merge-mines with within a myriad become very valuable. Then botnets will still target GPU biased coins just that GPU miners will have an upper hand. As even Bitcoin was still plagued by botnets in its GPU days at times. The only way to truly avoid the botnet problem is to use ASIC's. The only thing is though is that GPU's are more readily available to anyone who wishes to contribute to the network. A lot of people and especially the cryptocoin types will already have GPU's that they can use to hash with. While someone new to the game would find it a lot easier to buy or build a PC with a GPU fitted. PoW is supposed to be about fairly sharing the hashed coins to miners who help secure the network. While the more individual miners a chain has then the more people who have a stake in that coins future. So therefore more fanboys to help evangelise the benefits of the coins. I'd suppose going ASIC would be fairer than going CPU only well at least it's stop criminals controlling the majority of the supply of all new coins. Hi Matt, Cryptonight can be GPU mined - do a google search for "Claymore GPU miner" - I have been mining XMR for a few months with this miner and it works wonderfully (it is about 10-20x faster to GPU mine xmr vs cpu mining it (Per GPU) - this is probably why you see some miners with a really high hashrate. |
|
|
|
I think using a hot wallet is insecure (unless we are talking about pocket change here).
Might as well keep the OS up to date.
Sorry I was talking about my watch-only wallet, the cold wallet is on a perma offline computer. So you think keeping the OS up to date is better then? I was worried maybe I could pick up some sort of vulnerability by updating lots of things. |
|
|
|
|
What do you guys think is the best for security, installing updates or not updating. I'm talking about system updates, not armory updates. I am running Ubuntu 14.04.
|
|
|
|
Okay but if a person does not notice it, just sends the coins to a cold wallet, and never checks it or sends a ticket to cryptsy then they just lose? Will the coins eventually appear if no ticket is sent? Where are thrse coins going?
I think they periodically do audits to catch things like this (like every few weeks or so). Let's see. AnonCoin ASrmjhb29xQqu45MST1MPcruhg1WkQS9td 213.79691608 ANC Yes 2014-06-26 19:15:08 Processed TrxID: 199ea7e24c2f29b73c5518e3f967a040540f282950d78d9c68bb66f641e91d6d @ 2014-06-26 19:20:12 Supposedly sent 3 days ago. Actually not yet sent. http://altexplorer.net/address/ASrmjhb29xQqu45MST1MPcruhg1WkQS9tdI won't send a support ticket and see if it eventually arrives. Definitely put a support ticket in unless you are ok waiting a couple weeks. |
|
|
|
tried to withdraw some anc from cryptsy 24 hrs ago, still pending. they are aware of the issue and trying to fix it. anyone else in the same situation?
Been like that for a few days now, many who's had the same experience. I got my ANC after 4 days. It's been four days after being processed for me....and the last two emails I sent to support I haven't had any response at all. At roughly the same time a few days ago I bought some anoncoin and sent it to two different wallets. One brand new wallet, where the coins arrived with no problem, and one anoncoin wallet I have had for a while, the coins have not shown up yet http://altexplorer.net/address/ASrmjhb29xQqu45MST1MPcruhg1WkQS9tdSimilar issues have been posted about other coins recently, philosophersstone etc. There is a tx id on cryptsy but no coins. That happens with cryptsy. You have to open a Support Ticket with them and include the TXID details. I have 2 open now for 2 different coins. Okay but if a person does not notice it, just sends the coins to a cold wallet, and never checks it or sends a ticket to cryptsy then they just lose? Will the coins eventually appear if no ticket is sent? Where are thrse coins going? I think they periodically do audits to catch things like this (like every few weeks or so). |
|
|
|
Yes, I understand this. But if I have for example 110 DRK in my wallet (one address) will the "denomination" create transaction that will send 100 DRK to new address and then this new address will go thru the pool?
Currently if you want to send say 15 coins for example - 10 coins will go to an address you own, 100 coins will enter the pool, 85 of those coins will come back as change. Eventually Darksend will work slightly differently, the entire 115 coins enter the pool, you will receive 100 coins back as change at many different addresses in various denominations. |
|
|
|
One technical question about DarkSend.
Let's say that I have 110 DRK in one address and I want to pay 30 DRK to another user using DarkSend.
DarkSend does something called "denomination". What does this mean? That it will send first 100 DRK to another address and then include these 100 DRK in DarkSend pool from this address?
Is this just this one transaction (in this example) or maybe denomination does also something else so that the original address (with 110 DRK at the beginning) is somehow obfuscated?
Thanks.
Recap of How DarkSend Works
DarkSend functions in a way that is very similar to a tumbler, which is an idea that has been around for quite a while, but with a few specifications that increase the effectiveness. It has went through multiple changes and updates, but the most recent release, release candidate 2 (RC2), is nearing complete anonymity.
When a user, let’s call him Tim, sends darkcoins through DarkSend to another user, let’s call her Sandy, he must send 10 darkcoins, even if that amount is larger than what he would like to pay her. DarkSend then puts his coins in a pool, and pauses until two additional users initiate transactions. These new users will add their own 10 darkcoins to the pool, and DarkSend blends the 30 coins into a random assortment. If we assume that Tim wanted to send Sandy 8 darkcoins, then at this point 8 darkcoins would be deposited into Sandy’s wallet, but those 8 coins would be a mix of coins from all 3 users that had initiated transactions. Tim’s remaining 2 coins are placed into a Random Pool Address (RPA) which was created during the transaction. This RPA is not tied to any user, thus it is impossible to connect to a specific user, but Tim can access it.
This process is happening for the other 2 users that sent 10 darkcoins through DarkSend as well, so at the end, it is impossible to determine which transaction was related to a specific user. To an outside observer, 3 users put 30 darkcoins in, and 3 – 6 addresses receive coins out (3 if each user intended to send a full 10 darkcoins, up to 6 if each user intended to send less than 10 darkcoins). Source : http://coinbrief.net/darkcoin-darksend-bitcoin/Some additional (more recent) informations : [...]
Thanks for the questions. It does seem like you're missing something. Although, it might not be your fault. The whitepaper is definitely out of date. We've done a lot of work at tweaking the trust model so that it can't be exploited. I'll try to explain how it works briefly, then hopefully if I get time I can revisit the whitepaper soon. - Masternodes don't have any power over the transactions. They just coordinate the signing. All parties must sign in order for the transaction to be valid. So there's no way to cheat and take the money. - Users submit collateral. At a later phase if a user doesn't provide the signature as agreed, the transaction will fail. Without colateral this could be done over and over bringing the system to a halt. - Masternodes have the ability to take the collateral transaction if they wish, but it's paid to the bounty fund. So it doesn't benefit them, it just benefits the community. This removed the incentive to cheat and take the money. There's no relying on pools at all anymore. Payments to masternodes are done with a voting system embedded into the blockchain. It would take 51% of the mining power to pay the wrong masternode, or another party (because the last few miners to solve blocks must agree on who should be paid) Transaction currently require 3 parties to be created, so there's a short wait. There are no fake transactions to make that quicker, although this could be done. There's usually 5 or so transaction per 2.5 minutes, so the network should be able to function pretty efficiently under these requirements. Hoping that helps . Thanks, Evan Ok, thanks, but I don't see any "denomination" happening in these examples? The amount sent, depending on its value, go thru a pool of 10, 100, 1000 etc. DRK. It's worth mentioning that Evan decided to scrap denominated pools because of various issues (needing more coins than you want to send, "dirty" addresses that result from the splitting off of a denominated amount, etc). The plan is to allow inputs of any size into a single pool (with a minimum resolution of .1 DRK), the change addresses will be denominated and sent back to several different addresses. Denominated change addresses will come in RC4, pool size change will happen in either RC4 or maybe later, not sure. |
|
|
|
[01:51] <evan82> http://pastebin.com/QmbM8dPH[01:51] <evan82> I found the problem :-) [01:51] <evan82> It's actually rather simple to fix [01:51] <tifozi> ahem [01:52] <evan82> anyone care to guess from the paste? I'm curious [01:52] <tifozi> checking [01:52] <tifozi> badVote [01:53] <evan82> Both votes have the same hash, but they have different votes [01:53] <evan82> er both blocks* [01:54] <evan82> Two blocks are solved at nearly the same moment on the network, both are propogated and accepted by the network. In the current implementation both blocks have the same hash, but in these blocks there's some discrepency about who to vote for. [01:54] <evan82> In one block the miner votes for 88802 and 88803, in the other the miner abstains from voting. When the next block is solved it's based on of one of the older blocks, so half of the network beleives the miner cheated and rejects the block causing a fork. [01:54] <GNULinuxGuy> nice  [01:54] <evan82> The solution to this is rather simple. Any changes to the votes need to also change the hash of the block. The network must not think these two blocks are the same. [01:54] <tifozi> How come we didnt see this in testnet [01:54] <tifozi> seems rather simple problem [01:55] <tifozi> what in mainnet causes it [01:55] <evan82> Not sure. No one noticed. [01:55] <qqr> race conditions are hard to witness HURRAY! Time for a beer. |
|
|
|
If anyone has any evidence to suggest that the network was "forked" at any point, please share - I have reviewed IRC transcripts and have read every post, and was monitoring the pools throughout the hardfork implementation and there was never any evidence that I am aware of to suggest that the network had actually forked. Hopefully Evan will re-release the same code and we can try to fork RC3 in a couple days.
I was going through the two block explorers and I think it was a ...97 block which I saw on chainz and the official block explorer. They had different values for the same block. I was refreshing the block explorers periodically, I did notice chainz was behind at one point (chainz often lags for no apparent reason so I wouldn't read much into that), but I didn't see any evidence of a fork, just some lagging. When the revert went up both explorers (and all pools) were on the correct chain. several forks where found on the network, that is why reversal was the only logical choice I understand. Better to be safe than live with the worry that additional forking may occur down the road. You were right about at least some forking occurring, I see that coinmine.pl was on a wrong fork for over an hour https://www2.coinmine.pl/drk/index.php?page=statistics&action=blocks - so I take back my previous statements. |
|
|
|
If anyone has any evidence to suggest that the network was "forked" at any point, please share - I have reviewed IRC transcripts and have read every post, and was monitoring the pools throughout the hardfork implementation and there was never any evidence that I am aware of to suggest that the network had actually forked. Hopefully Evan will re-release the same code and we can try to fork RC3 in a couple days.
I was going through the two block explorers and I think it was a ...97 block which I saw on chainz and the official block explorer. They had different values for the same block. I was refreshing the block explorers periodically, I did notice chainz was behind at one point (chainz often lags for no apparent reason so I wouldn't read much into that), but I didn't see any evidence of a fork, just some lagging. When the revert went up both explorers (and all pools) were on the correct chain. |
|
|
|
Simcom: BTW, I def. saw some strong evidence of sideforking last night. My biz partner sent me 250DRK last night to top out our fifth community owned node and it just never arrived (he was using .9x I was using .10x). I'm assuming this transaction was orphaned since it never arrived (and I *think* it never left his wallet).
Anything that happened before the hardfork is irrelevant. Likely a run-of-the-mill orphaned block. |
|
|
|
|
Hi all, I have been been following todays events closely and I have few (maybe controversial) remarks:
First, the hardfork implemetation went perfectly as far as I can tell. The network never became forked at any point. Immediately following the hardfork a couple of the pools were 1-5 minutes behind the highest block, but at no point did any of the pools ever fork - despite repeated claims to the contrary by people that should know better ::cough cough::. I believe Evan mistakenly interpreted this 1-5 minutes of lag on certain pools and masernodes as a fork, when in fact it was not (probably due to the differences in blockheight reported by the pools and those reported to him by masternode owners). As others have suggested, the reason for this lag is probably because the solved blocks were just taking longer than usual to propagate through the network because there were a lot of old clients on the network, something not entirely unexpected.
This minor issue solved itself approximately 15-20 minutes after the hardfork took effect, and the network hummed along perfectly fine for another 30 minutes before the reversion was released on github. During this time masternode payments were also working perfectly. In retrospect, the decision to revert the code was probably a mistake, but I understand the decision as Evan was acting out of an abundance of caution and that bit of lag spooked him.
If anyone has any evidence to suggest that the network was "forked" at any point, please share - I have reviewed IRC transcripts and have read every post, and was monitoring the pools throughout the hardfork implementation and there was never any evidence that I am aware of to suggest that the network had actually forked. Hopefully Evan will re-release the same code and we can try to fork RC3 in a couple days.
|
|
|
|
Any news for the weekend?  Not much. The latest estimate of a working zc implementation is by july 10th according to Gnosis. That is great news! July 10th is not that far away. I am excited! Almost no progress uploaded to github in the last 2 months as far as I can tell. What am I missing here? Is there another repository somewhere that is showing progress? Zerocoin supposedly has a team of people working on the implementation and they are still 3-6 months from completion, yet Gnos1s is holding down a day job, coding on the weekends, and his ZC implementation will be done 3 weeks from now? Can someone explain how this makes any sense? I want to believe it is true it seems very very unlikely anything will be done by July 10 at the current rate. Is Gnos1s holding back a bunch of code that is almost done or something?  |
|
|
|
10% Mining Bonus at Extremehash.com
www.extremehash.com is consistently finding blocks, and welcomes you to cash in on the bonus! Consistent blocks | Larger payments | Solution to Dust problems
Profit now!minerd -a cryptonight -o stratum+tcp://mro.extremehash.com:7777 -u address -p x I still don't understand where the ten percent bonus comes from. Are you magic? He bought extra coins to hand out. |
|
|
|
Caution advised: No payouts from http://monero.crypto-pool.fr/ in the last 14hr+.The pool shows my Total Paid at over 2XMR, but nothing has been received. My wallet is synced and operating fine and I've never had issues with payouts from other pools before. I contacted the pool admin, and he doesn't seem to know what's going on (claiming payouts are fine when they are not, and asking me if I am out of sync). It's certainly not a problem on my end, because others confirm not receiving payment (at least 2 other miners in IRC). I would suggest being careful on crypto-pool.fr until the pool admin provides an update. Yep, having same problem. Started mining there about 14 hours ago and haven't received any payments yet. Interestingly, I am also having problems receiving a poloniex withdrawal, the transaction status is confimed finished and it gives me a transaction hash, but that does not exist on the blockchain - about 5 hours have passed now and still nothing in my wallet or on the blockchain. Very weird. Edit: Does anyone have recommendations on an alternate GPU pool? |
|
|
|
|
What version of armory do you guys recommend using? The computer cannot run ubuntu 12.04.3, so the stable offline bundle will not work - is it safe to use the alpha offline bundle instead?
Thanks!
|
|
|
|
|
Hi etotheipi,
Quick question - I have a laptop running Ubuntu 14.04 LTS, and I want to make it my dedicated cold offline computer. Should I install this Offline bundle release? I first tried to install Ubuntu 12.04.3 as your website suggests to be compatible with the 0.91.1 Offline Bundle, but my laptop would not run this old version of ubuntu, only the newest version of ubuntu supports the computers hardware. So would it be ok to safely use this alpha release on my 14.04 system? Alternatively I could try to get the 0.91.1 Offline Bundle installed but your website suggests only Ubuntu 12.04.3 (exact) will work.
Thanks!
|
|
|
|
|
Can someone please remove "*** PLEASE UPDATE TO 0.4.8 OR 10.8.8 ***" from the website.
|
|
|
|
|
Show Posts
