I have no base, other than that someone was 2 years ahead of someone else who manage to create a fork of their work. The monero guys probably didn't even have a clue that anonymity was the shiet until darkcoin showed them, and after that they wanted to make a quick buck and go down in history books as the 'inventors of the modern "new age" anonymous economy' pfft.
100% bullshit straw man argument. The developers of Monero have never claimed nor do they ever claim to have invented the technology. At least learn some of the history before going off spouting nonsense. |
|
|
|
In my opinion, ByteCoin is not premined. Others who are butthurt tend to disagree, but the fact of the matter is that it is debatable because the coin wasn't "premined" in the strict sense of the word. FUDsters throw that around way too much. If anything DarkCoin was 50% premined because half of the current coins were instamined within 48 hours of launch! Look at all the DarkCoin fanboys, blind to reality. ByteCoin was relatively unknown to the public, so they scream premined!!1 when in actuality it was mined by thousands of people for a few years. BCN is the real deal...Monero is a poorly marketed and branded copy cat and DarkCoin has it's many flaws which I don't need to get into. BCN and ducknote FTW.
It was MINED by THOUSANDS of people, yet completely unknown to the crypto community. You can't believe that now can you? Why not? Any arguments? Zero verifiable evidence. |
|
|
|
Alright. But seriously, monero appeared only some weeks after bytecoin got introduced to the forum. It's nothing more than a fork, it didn't even bring a GUI to the users.
Indeed, that's exactly what it tried to be. I prefer to call it a relaunch (without shady 80% premine) than a fork, although there were enough superficial changes (moving decimal point, etc.) to consider it a fork. In practice though, it was mostly just an open relaunch of Bytecoin, instead of trying to pass off the testnet using false claims of a large community with deep web "stores and services" and other lies. |
|
|
|
It's always great to have competition, as it makes products more perfect. From my side, I would happily agree to split the bounty between the developers of the most stable and easily usable wallets. There should be a voting at the 1st of July (?) of the best GUI, picked by the users.
1. Yes the bounty is still open. 2. Any contested bounty awards will be voted on by the identified contributors. There can definitely be multiple winners as there are likely to be for the pool bounty. |
|
|
|
If I was going to launch an alt-coin, I would use a true spin-off. Since I was the one who picked the mining algorithm and controlled the launch date, I'd have my miners fired up and ready to go right at launch. By mining when difficult was low, and perhaps by purchasing coins dumped for cheap, I bet a developer could accrue 0.1 - 1% of the money supply for a low cost. The beauty here is that there will be no questions about the legitimacy of the distribution. Every detail would be completely transparent.
Instamining where the developer has some major advantage is definitely questioned and there are some well known if somewhat successful (and likely a large number of less successful and less known) examples that are questioned. Buying from people who don't place the same value on it is likely to be viewed as more legitimate. Lol, after I wrote that post I was worried it would be mis-interpretted because I don't think I was clear. What I mean is that the developers could begin mining upon launch and could be well-prepared to do so efficiently. The only "advantage" the developer might have is that he's likely the one paying his coin's launch the most attention. For example, the snapshot.bin file could be based on the unspent outputs at Block #310,000. However, it could be agreed that the coin "launches" at Block #314,000 (giving everyone ~one month to make sure there's nothing "funny" about the snapshot.bin file). It would be agreed that the blockhash for Block #314,000 gets encoded in the snapshot.bin header and when this data is known, the coin goes "live." This type of launch mechanism allows everyone to know the launch details ahead of time, yet delays the launch until a certain event happens on the bitcoin blockchain. Once the event happens (Block #314,000 is found), it becomes every-miner-for-himself. The only advantage the developer has is that he is probably paying closer attention and will likely be ready to mine the moment this event occurs. And as I said, it is still likely to be questioned if the developer is uniquely "well-prepared" to mine and ends up mining a disproportionate amount because others are unaware of it or not uniquely well-prepapred (sometimes compounded by a low starting difficulty and bad difficulty adjustment algorithms that give a huge advantage to all miners -- but especially developers -- who get in early). But it is hard to argue with actually buying coins from a seller, although I guess even in that case there could be shenanigans. For example, the developer could be deceptive about plans for future investment, to scoop up cheap coins before revealing investment plans. Sort of a reverse pump-and-dump. If there are threads announcing the launch details months in advance, and even CoinDesk runs a story on it, then in my opinion the developers have done their due diligence in making the announcement. If they happen to mine most the coins for the first few weeks because few others bothered, then I don't see how that would be interpreted as a problem.
I agree with this extreme example in theory but I can't think of a single coin in practice that has been launched this way, with months of notice and press coverage. (I guess Etherium counts, though it hasn't been launched yet.) In practice what often happens is an announcement post is made and the thread gets quickly buried if it isn't among the most widely followed (and replied). |
|
|
|
|
IMPORTANT
I have received a proposal to award 49% of the bounty to zone117x, 49% of the bounty to LucasJones, and 2% to archit.
If there are any objections posted to this thread within 24 hours of this post, I will proceed to request approval of this award plan by majority vote of the identified contributors. If the vote fails, alternative proposals will be considered, again by majority vote.
If there are no objections posted to this thread within 24 hours of this post, I will distribute the bounty accordingly.
|
|
|
|
If I was going to launch an alt-coin, I would use a true spin-off. Since I was the one who picked the mining algorithm and controlled the launch date, I'd have my miners fired up and ready to go right at launch. By mining when difficult was low, and perhaps by purchasing coins dumped for cheap, I bet a developer could accrue 0.1 - 1% of the money supply for a low cost. The beauty here is that there will be no questions about the legitimacy of the distribution. Every detail would be completely transparent.
Instamining where the developer has some major advantage is definitely questioned and there are some well known if somewhat successful (and likely a large number of less successful and less known) examples that are questioned. Buying from people who don't place the same value on it is likely to be viewed as more legitimate. |
|
|
|
I actually think there needs to be some dynamic market mechanism for pricing the service provided by miners (processing transactions and securing the block chain). I haven't seen a convincing model for how do this though.
Part of Satoshi's insight is to just fix the supply and let the market adjust around it, which if correct (and many doubt this), means that it doesn't really matter what inflation rate is chosen (including 0%)
There was tons of stuff on the FreiCoin forums about this sort of thing, and maaku etc spent months on the problem to eventually abandon it for demurrage. If there is an answer, it's not an obvious one. The lack of a clear answer likely includes it not being clear that any of these approaches are necessarily better than satoshi's (though also not clear they are not). Therefore I largely abstain from these debates. |
|
|
|
Can someone please link me to the top addresses for monero?
If there exist such a public list.
As previously indicated the main point of this coin is to not support that (i.e. "private" into the thread subject). You can in fact create such a list but it doesn't mean anything because on-blockchain addresses are one-time-use so all you are listing are unspent outputs, not public addresses. Yes if people shared their view keys that would yield more information but I can't see any reason whatsoever why significant number of people would ever do that. |
|
|
|
|
selling 30m for 1 BTC (30m minimum) expires end of day UTC 6/10
|
|
|
|
|
I actually think there needs to be some dynamic market mechanism for pricing the service provided by miners (processing transactions and securing the block chain). I haven't seen a convincing model for how do this though.
Part of Satoshi's insight is to just fix the supply and let the market adjust around it, which if correct (and many doubt this), means that it doesn't really matter what inflation rate is chosen (including 0%)
|
|
|
|
My comment was not so much directed at the claim window as the stated intent to exclude possibly lost coins.
Okay, in some trivial sense all lost bitcoins are already excluded from the altchain, because any corresponding altcoins can never be claimed. But the important thing, as far as I'm concerned, is that there needs to be some point in the future when potential investors can stop caring about whether or not they still include those potential coins in their analyses. When does this hypothetical time in the future happen for bitcoin itself? Since the answer is never, if investors really "need" this, then they wouldn't be investing in bitcoin, and the bitcoin distribution wouldn't be efficient. Your argument is essentially a refutation of the original premise. |
|
|
|
New offer. Supersedes all previous offers.
0.04 / 50M / 2 / smooth (min 0.5 BTC; expires end of day 6/7 UTC; you send first)
Pending trade. No offers open currently. SOLD |
|
|
|
|
New offer. Supersedes all previous offers.
0.04 / 50M / 2 / smooth (min 0.5 BTC; expires end of day 6/7 UTC; you send first)
|
|
|
|
New offer. Supersedes all previous offers.
0.065 / 25M / 1.625 / smooth (min 5m; expires end of day 6/5 UTC; you send first)
0.05 / 25M / 1.25 / smooth (min 0.5 BTC; expires end of day 6/6 UTC; you send first) |
|
|
|
Hi I have been away for a week & come back to find I solo mined 15 mro, but now I see there was a mandatory upgrade & change to XMR. Are these coins now worthless or can I still transfer them? I'm running wallet v0.8.8.1.1 according to the log??
Your coins are fine. Just upgrade your wallet software. Backup your wallet files before doing anything else of course. |
|
|
|
It depends on how many chunks got in to get to that amount. As far as I've read, each time you got some MRO from the pool, a new address is generated for that. This is for our protection and it's OK. So I actually had to send from maybe 100 (internal) addresses to get to that 0.15 MRO (only one CPU mining). That's why the size was too big. If your 3000 MRO went to your wallet in one chunk or two, I'm almost sure you can send it away in one piece. I don't know more exactly, never had that many  So, if you let say mined 5 XMR, and then send 300 XMR on wallet from some exchange, you will be easily transfer back or anywhere else those 300 XMR, you will just have problems with mined 5 XMR? I thought of making 2 Wallets, but if it is this way is useless to do that. It is probably a good idea to mine to a separate wallet to keep those problematic tiny payments in one place. If you receive 300 from an exchange into a empty wallet, you won't then have any problem sending that 300 at one time. |
|
|
|
For these small payments we really need the wallet to calculate the best way to send a large payment and calculate the correct fee. If it's going to be a multi block payment then the client needs to handle that itself.
I agree. But first things first: let's have a proper wallet first. Then it can be improved. Yup. Also, better handling of unconfirmed transactions. If you try to send a transaction that is too large or has too small of a transaction fee, it maybe not make it into a block right away or ever. There is currently no UI for indicating to the user what is going on. |
|
|
|
|
New offer. Supersedes all previous offers.
0.065 / 25M / 1.625 / smooth (min 5m; expires end of day 6/5 UTC; you send first)
|
|
|
|
Is this an intended feature of cryptonote, that you can only send small chunks at a time? I'm not sure if I get it. Does this mean I couldn't send say, 3000 XMR at one time?
It's an issue of transaction size, with "size" meaning bytes not number of coins. What is happening is you are receiving a lot of little payments (probably from a pool). To spend each of those payments requires some number of bytes in your outgoing transaction, and those are size limited. The fix for this is for pools to wait for some minimum before paying out, but the pool code is brand new and this has not been implemented. As you say the workaround is to send several smaller chunks. If you send these chunks to another wallet, that second wallet will be able to make larger payments without running into the size limit. |
|
|
|
|
Show Posts
