In regards to cloud-scale computing, they'll quickly be mining at a loss if enough everyday miners (ie those with a computer at home) mine at a loss since they probably won't worry as much about their relatively small electric bill vs active EC2, et alia costs. I probably mine at a loss now (given current exchange rates) but I don't mind the extra few dollars per month on my electricity bill with my otherwise underutilized processor and I would be more willing to risk just that given the potential end game than increasing my risk moreso by renting cloud computing.

Have the algorithm change pseudo-randomly, to another hash algorithm, depending on the time at which hash rate crosses a threshold.  If the space of hash algorithms is large enough, that pretty much destroys ASIC, because of the large amount of die space required to hold all the recombinant blocks, and the solution is fully decentralized.

What would that 1 line of code be?

The POW can be altered invalidate ASICs with 1 line of code.

Practically 6mil difficulty! We are going to beat BCN!

CPU is an ASIC

There is FUD at the moment going on about Bytecoin, that CryptoNote based coins have a backdoor.

https://bitcointalk.org/index.php?topic=512747.msg7018325#msg7018325

Personally I think this is a load of rubbish, many people here have read the entire codebase [1] of Monero (that is mostly the original CryptoNote implementation) and there seems to be no evidence of these special keys.

[1] I am sure I heard that some of the Monero developers have been over the code. I wouldn't mind this being confirmed again.

Yes - but remember: 1 address = 1 wallet. They'd have to manually balance funds between wallets for withdrawals etc. It could be done, but it would be massively inefficient and a PITA to code up. Payment IDs are the easiest / best way.

Did you know about the impending dump before our off exchange transaction?

it seems Poloniex withdrawal for MRO doesn't work. Status of my withdrawal now is ERROR.

1.  Eliminating dust by rounding all address balances down to the nearest 1000 bits.  This cuts the size of Block0 for the spin-off in half (from ~80 Mbytes to ~40 Mbytes).

2.  Reducing the complexity of the claiming process by not supporting certain bitcoin UXTOs with complex / non-standard redeem scripts.  If only 99.5% of the bitcoins were claimable, as opposed to 100%, would this be considered legitimate (assuming the rules were known in advance)?  Claiming standard payToPubKeyHash outputs is very easy (which is the vast majority of the bitcoin money supply), but complexity builds if every possible output script must be supported.  

3.  What is your opinion on spin-offs launched with time-limited claim windows (assuming the window is sufficiently long)?  DeathAndTaxes made some good arguments in their favour. 

Certainly people have proposed spin-offs that exclude Satoshi's coins, and/or all coins that haven't been moved recently. And alt-coin communities often point to Satoshi's holdings as showing that Bitcoin's distribution is poor. So people care. Whether it's affected the market is impossible to say; perhaps the current price would be double if those coins had been provably destroyed. In any case, destroying them within Bitcoin would be near-impossible politically, so it's kinda pointless to discuss it.

I like the idea of the time limit for claims, partly because it has the effect of excluding Satoshi's coins, and those of other inactive people, without having to impose an arbitrary historic cut-off date. If we excluded BTC untouched since 2012, for example, some people would lose out and there'd be nothing they could do about it. Where-as if we require claims to be made before 2016, then Satoshi himself can make his claim if he should awaken from his slumber. It's probably better for the new coin if its users are at least a little bit active.

Is the problem that FCN cant keep up with updates to the code base of its merge mined coins? It seems to work for Namecoin though..?

I skimmed the code, and you may be right.

src/cryptonote_core/miner.cpp:

...
      b.nonce = nonce;
      crypto::hash h;
      get_block_longhash(b, h, height);

      if(check_hash(h, local_diff))
      {
        //we lucky!
...

Could a developer comment on that? Will larger blocks hash slower? If so, what incentives do miners have to include more than the coinbase transaction in their blocks (transaction fees seem negligible at the moment imo)?

Will Monero ever reach 0.008? Seems like a constant downfall every day I check poloniex.

Sure. We're effectively arguing the same logic though, from different angles. I'm saying the gpu mining community is comprised of a lot of small scale operations, whereas MRO's current mining distribution would (I expect) be dominated by a few large cloud mining ops. Far, FAR easier & cheaper to scale up cloud mining infrastructure than scaling up GPU mining. So introducing a gpu miner would be moving in the right direction in that respect (not to mention the benefit to adoption, attention, etc).

Mining dynamics tend in the opposite direction (because efficiency wins out, and larger operations are more efficient).

Thanks, I think the problem was with the PIMP OS which was designed to run off a USB stick, I installed Zorin instead and everything worked smoothly.
 
Can anyone tell me where ByteCoin stores the blockchain in a linux system once it's downloaded and synchronized. I have fully synchronized the blockchain and want to copy it over to my other computer so I don't have to do it again but I can not find it.