Yes it's possible. The current algorithm is approximately keep choosing random outputs until it has enough (or maybe a little extra). That has some advantages in being unpredictable and disadvantages in being inefficient (and possibly others). I suggest writing up a proposal and/or implementing it. That said we don't know what that wallet might have looked like. If there's nothing but small outputs left in there and you try to spend a lot, you are going to get a lot of small outputs regardless of algorithm.
|
|
|
Wasn't otoh the guy who claimed to have dumped all of his XMR then posted an "after" screen shot where he was still hiding his XMR balance, or did I get him mixed up with some other troll?
|
|
|
^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.
Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert? If you are doing -verify 0 it means none of the data is being checked at all as it is added to the database. If the raw file is in any way invalid, you can end up with a bad blockchain in a corrupt database and never know it until later when "something" goes wrong. This is probably okay if you are importing a raw file you exported yourself from a working node (other than bugs), but probably not a good idea to use if you are downloading a raw file (other than maybe an official one, after verifying the checksum), and also probably not the greatest idea at this point when the code is still experimental (unless you are doing it for the purpose of an experiment).
|
|
|
^I'm running blockchain_import now. I tried blockchain_convert first, but export and then import (with --verify 0) works much faster for me.
Is there a drawback to this? If this works and is a lot faster, then what's the point of blockchain_convert? It worked until it stopped at block ~240000 - tried it twice. I'm now back to converter. Is this on Windows? I remember seeing something about setting the block size smaller being a work around for that.
|
|
|
Hi, maybe this is the wrong thread, if so, I apologize, as I did a lot of googling but came up short.
I'm for the first time running bitmonerod on Linux.
I compiled from latest linux 64-bit source, and now have the daemon running - I couldn't seem to use the blockchain.bin on monero.cc (kept crashing), so i've gotten it running but resyncing from scratch.
Here is my single question - Am I now using the new database format, or ... was there some compile switch i missed? My blockchain.bin is still pretty large, even with 333 days left to sync, but i'm not sure that matters.
Thanks for any help/advice.
If you got the master HEAD from github then yes you are using the experimental database version. Your blockchain.bin file won't be used, it will create a separate directory within .bitmonero for the database files.
|
|
|
Sorry for such an obvious/newbie question... but I have been mining AEON on minergate for a while... and have almost 300 coins stacked up, will I still be able to trade them once AEON is back on an exchange?
Yes your coins are still good, assuming minergate is still around. You might want to try to set up your own wallet and move your coins off when you get a chance. Never a particularly good idea of entrust your coins to a third party.
|
|
|
Update on Release Phoenix
Release Phoenix is a go!
I've successfully competed testing of:
1. New PoW 2. Block time switch to 4 minutes 3. Difficulty transition adjustment (prevents blocks from being mined too fast after switching to faster PoW)
I will be announcing a test release shortly, so people can try building and running on your own systems (it is set up to run separately from the main network).
Assuming no problems with the test release I will then push out a new general release with the hard fork set at some block in the future and a few other minor improvements.
|
|
|
New Aeon bootstrap for linux-x64 - date 5.5.2015 https://mega.co.nz/#!q940nAjC!2O_DkzYFfV5_vPckt-gOxeQFW3yOJKPOZfwIBAaoHUk Thank you Phantas. I will add to OP
|
|
|
Bump (and Microsoft, and HD firmware unless you have ideas how this relates to Monero)
Speaking of which let's pivot away from this free and open source software discussion unless it is tied in directly to Monero's future prospects.
|
|
|
More than one person expected a different emissions schedule way different to what was delivered. what you had said about the emission curve of bitmonero at time of release that it would be flatter but in reality it was not. therefore, can your claims be trusted.
What can I say? It was flatter and emontmon was incorrect in claiming otherwise, as clearly shown the source code on github, blockchain, etc. If you want to base your opinions on other people's incorrect statements rather than primary sources, I can't help you. .... lol When you say things like that, you come across like a scammer. You're view is the correct view, everyone else who was there at the time writing down what they were thinking are just, well, wrong. If relying on actual information like github or blockchains rather than incorrect opinions makes someone come across like a scammer, then your scammer detector needs recalibration (we already know that of course). ok. Lets ask you what you meant at the time. Perhaps that will help us to resolve this question. Who knows, you might be right, I'm just curious: I suppose this can still work if the emissions curve is flat-ish like BTC (i.e. not as much advantage to early mining).
My recollection from reviewing the code changes is that the emissions should be about 1/4 the speed of bytecoin. Not much advantage to early mining is relative though. Perhaps you have heard about Satoshi's 1m+ bitcoins? The emissions were and are 1/4 the speed of bytecoin in terms of blocks (change of the speed factor from 2 -18 to 2 -20 = 1/4). That was the exact day of launch and I wasn't involved with development so at that point I didn't yet recognize that the block time change reduced that difference by half. Nevertheless, it still works out to 1/2 the speed of Bytecoin i.e. flatter. Do try to stay on topic though.
|
|
|
More than one person expected a different emissions schedule way different to what was delivered. what you had said about the emission curve of bitmonero at time of release that it would be flatter but in reality it was not. therefore, can your claims be trusted.
What can I say? It was flatter and emontmon was incorrect in claiming otherwise, as clearly shown the source code on github, blockchain, etc. If you want to base your opinions on other people's incorrect statements rather than primary sources, I can't help you. Likewise one can look at a block explorer for Dash and see this, which bears no resemblance whatsoever to any of the published emissions formulas: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FdSe9cRz.jpg&t=663&c=ZkFKi-bVCPpvfQ)
|
|
|
Also as a practical matter reducing emissions, or worse, reducing supply, further concentrates early adopter and insider holdings and reduces the incentive for later adopters. Later adopters can reasonably ask the question why not just buy into something else where I too can be an early adopter with less risk, and they'd be right. There has to be a balance between incentives to early adopters and incentives to late adopters. If you front load scarcity and price increases, that can be great for traders and insiders, but you undermine late adopter incentives
Ask a late adopter which he wants to buy, a low inflation coin or a high inflation coin. A true late adopter would be buying a low inflation coin regardless (unless the coin is specifically designed to maintain high inflation forever, but none of these are). The only question is whether that happens when things are actually somewhat mature and widely adopted (with correspondingly low risk), or is accelerated with a fast-mine (QRK/UNO) or an instamine (DRK) to quickly produce low inflation before there is any real adoption. I would argue it also depends on price. A high inflation coin that is still in an early distribution phase will have a relatively low price, meaning it is easy, cheap, and low risk for early adopters to get in. The inflation is a viable trade off for the prospect of large gains if and when adoption occurs later. And, isn't the foremost purpose of a coin to be something people can use, and not only speculate on in hopes of getting rich?
No coins are there. If and when some are, we can look back and see which made it. The closest was probably Bitcoin starting back in the peak of SatoshiDice and Silk Road which happened when it had pretty high inflation (much higher even than now -- still pretty high)
|
|
|
......In reality you have to get it very close to right from the beginning or you are screwed. Attempting to fix it will destroy it. ..
Well that all makes sense. But, how many bitmonero/Monero 'lets change emissions' community surveys have there been? Two, I think. Both decided against. How many surveys on funding using block rewards, have there been? None that I know of. There was a brief discussion of it, but it never rose the the level of an organized survey or poll that I recall. The survey results may have led to no change, but that's as a result of community engagement and discussions. Some people would have wanted to make changes. What would have happened if any one of the various surveys had resulted in a change being the outcome?
Something different? Likewise, we could ask what would have happened if Evan didn't instamine Dash and didn't make a bunch of instaminer-, early-adopter- and insider-favoring monetary changes later. And of top if that we can ask what would have happened if Dash actually had sound technology? I might be supporting it today!
|
|
|
I also managed to get my Radeon HD5850 to crank out 195 H/s (stock 725/1000 @ 900/1150) with an all-copper Xeon heatsink with a 140mm high volume fan, using the Claymore GPU miner under Win7 x64.
Do you have any idea of the power usage? I'm guessing pretty high even though CryptoNight GPU mining is usually pretty low power for GPUs. The older ones didn't have very good power management though. I have a lot of those gathering dust....
|
|
|
Oh it was launched with just one emission speed. Never said otherwise.
But it was changed from the emission speed advertised, changed at the last minute, without explanation.
It was never "changed" in any way. You can disagree with the choice of speed (as I did and still do), fair enough, but you are lying if you claim it was "changed" Unlike Dash, which clearly was changed. I fail to see the problem with changing it. Some time ago the Monero Economic Workshop had a poll to change the Monero emission. That measure failed, but had it succeeded, why would it have been wrong to change the emission? Because a huge part of the value proposition of cryptocurrency is that your holdings aren't subject to changes based on political or dictatorial whims. If not for that, you might as well stick with fiat which is more efficient and has an enormous first-mover advantage. Every such change to a coin weakens it by creating a precedent and reasonable expectation of further changes, and every attempted change that fails strengthens it for the same reason. You can see this already with people saying that they fully expect Evan to make more changes (and indeed he just change the mining yet again, redirecting some rewards to "voting" -- effectively an increase in the money supply). Conversely I doubt people expect Monero to make these sorts of changes. Also as a practical matter reducing emissions, or worse, reducing supply, further concentrates early adopter and insider holdings and reduces the incentive for later adopters. Later adopters can reasonably ask the question why not just buy into something else where I too can be an early adopter with less risk, and they'd be right. There has to be a balance between incentives to early adopters and incentives to late adopters. If you front load scarcity and price increases, that can be great for traders and insiders, but you undermine late adopter incentives Given the way adoption of cryptocurrencies generally has been glacial you might argue that increasing supply (diluting early adopter holdings in favor of slower-than-expected late adopters) makes more sense than decreasing it, except of course for the lack of stability issue discussed two paragraphs back. In reality you have to get it very close to right from the beginning or you are screwed. Attempting to fix it will destroy it. The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.
|
|
|
Monero "instamining stigma"
eizh's comments were a bit hyperbolic and likely out of frustration with the poor communication from TFT. "it annihilated Quark and continues to plague DRK" -eizh Quark: "Quark intended to mine 247 million coins within 6 months as part of it's fast distribution model" DRK: "That means in less than 8 hours, almost 5% of the Darkcoins that ever will be created spawned in that 1/3 of a day" (both from http://www.devtome.com/doku.php?id=a_massive_investigation_of_instamines_and_fastmines_for_the_top_alt_coins) So no there is not much similarity here at all. "80% mined in such a short time (compare to BTC distribution which extends into decades" -eizh This isn't even correct. BTC mines 80% in about 9.5 years, not decades.
|
|
|
Oh it was launched with just one emission speed. Never said otherwise.
But it was changed from the emission speed advertised, changed at the last minute, without explanation.
It was never "changed" in any way. You can disagree with the choice of speed (as I did and still do), fair enough, but you are lying if you claim it was "changed" Unlike Dash, which clearly was changed. I have nothing to lie about. It seems pretty factual from the pre-ann thread: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FVsw4jVL.jpg&t=663&c=8_9W61rBtqfpxA) I'm genuinely interested to know what was promised and what was delivered. Everyone seemed to be under the impression that the emissions would not involve 80% in the first 4 years, but be distributed over a longer period - similar to bitcoin, in fact. Here's TFT's very first post about it (on the Bytecoin thread), even before the pre-ANN: Next week I will start my own fork of Bytecoin - another coin based on CryptoNote technology. It will be started from scratch (from block zero). I will write an anouncement today ot [ANN] subforum. Emission schedule will be more flat and block target will be reduced to 60 sec.
What was promised was "more flat" (later "flatter"). Flatter was delivered. Only a single speed speed factor was ever implemented, and was never changed. Close to bitcoin is subjective. Compared to Bytecoin or a lot of fast-mine (one week to one year) coins, it is certainly closer. Please stay on topic. You are spamming the forum with anti-Monero rhetoric on inappropriate threads.
|
|
|
thelibertycap, I nuked the meme pic as it was off topic and also its a bit unfair to create a Monero endorsement with a real person's picture when he hasn't actually endorsed it.
Speaking of which let's pivot away from this free and open source software discussion unless it is tied in directly to Monero's future prospects.
|
|
|
Oh it was launched with just one emission speed. Never said otherwise.
But it was changed from the emission speed advertised, changed at the last minute, without explanation.
It was never "changed" in any way. You can disagree with the choice of speed (as I did and still do), fair enough, but you are lying if you claim it was "changed" Unlike Dash, which clearly was changed.
|
|
|
...
Honestly, I don't think his generalities were very valid at all.
ArticMine, "opening the door to Windows Malware on GNU/Linux" sounds like FUD to me. How about we focus specifically on MoneroX, and not all these broad generalities.
Allowing the execution of certain Windows executables on GNU/Linux does increase the security risk of a GNU/Linux system given the sheer amount of Windows malware in the wild. I do recognise however that this risk is very small but it is finite. I do not use Wine for this very reason. When it comes to XMR, XBT, etc I prefer to be safe than sorry. MoneroX is a great project, unfortunately the choice of C# and .net is a small but not insignificant negative. I have downloaded and tested MoneroX and will likely do it again in the future. I am currently undecided on using it on an account with actual XMR, I may or I may simply wait for the official GUI. I agree with ArticMine that it isn't FUD. If you have something on your computer (.NET runtime) that can execute .NET programs intended for Windows they you have increased exposure. Is .NET Native available for Linux? If you can compile the application to a native Linux binary and use it without the .NET runtime installed, the issue with Windows malware wouldn't apply. At that point it is just programming language.
|
|
|
|