WilliamLie2 (OP)
|
|
June 10, 2014, 08:58:33 PM |
|
maybe it wasn't botowners who crashed the price after all. I didn't crash the price. I think it was botowner(s) + people who saw what was happening.
|
|
|
|
TwinWinNerD
Legendary
Offline
Activity: 1680
Merit: 1001
CEO Bitpanda.com
|
|
June 10, 2014, 09:10:53 PM |
|
was this premine announced? I really dislike coins that keep that a secret
|
|
|
|
HunterMinerCrafter
|
|
June 10, 2014, 09:18:05 PM |
|
maybe it wasn't botowners who crashed the price after all. I didn't crash the price. I think it was botowner(s) + people who saw what was happening. Most bot operators were/are holding, from what I can tell. Miniminer got confused and basically thought that the network was broken/crashing when it wasn't, so he unloaded the bulk of botted coins he had been hoarding, probably assuming that the exchange was going to have to quickly de-list. This was on the order of tens of thousands of coins. The total selloff (after him) was just over 500k coins. At the time there were just under 1 million coins in circulation that *weren't* the devs' coins from block 0. (so a little under 1.5million total) Some of these coins were probably traded back and forth during the crash, of course. In any case, it is poor form for devs to reserve coins for promotions and then sell them off for personal gain. If the devs were really concerned about preserving the value held then they should now be offering a promotions in btc at a rate equivalent to the price on their trade, I'd think. Instead they appear to have just panicked, sold (at what is now/soon likely a significant net loss) a large chunk of their holdings behind miniminer's sells, and now probably want to retain what they do have left for themselves.
|
|
|
|
HunterMinerCrafter
|
|
June 10, 2014, 09:21:21 PM |
|
was this premine announced? I really dislike coins that keep that a secret Yes, it is even still in the original post. "The 3 developers of Motocoin were each rewarded 150K of premined motocoins. Large portions of these coins will be used for bounties and giveaways (see below)" However there is nothing to see below. The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
|
|
|
|
WilliamLie2 (OP)
|
|
June 10, 2014, 09:25:27 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch.
|
|
|
|
HunterMinerCrafter
|
|
June 10, 2014, 10:08:06 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-)
|
|
|
|
WilliamLie2 (OP)
|
|
June 10, 2014, 10:43:13 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense.
|
|
|
|
HunterMinerCrafter
|
|
June 10, 2014, 10:48:55 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense. As I said, those coins (aside from the three 150k blocks) weren't really a pre-mine at all. The game was public for those 8k blocks, it just wasn't until that time that it was really being promoted, reddit activity, etc. That is all I mean.
|
|
|
|
ivanlabrie
|
|
June 10, 2014, 10:52:06 PM |
|
Dev sells premine...fails to fend off bots, no promotion bounties. MEH.
HunterBotDude should take over development at this rate :p
|
|
|
|
WilliamLie2 (OP)
|
|
June 10, 2014, 10:58:18 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense. As I said, those coins (aside from the three 150k blocks) weren't really a pre-mine at all. The game was public for those 8k blocks, it just wasn't until that time that it was really being promoted, reddit activity, etc. That is all I mean. This is just what you would expect, information spreads over time. But you were saying like if it was announced only 6 days after launch. EDIT: I had dozens of connections in those early days, so it wasn't "a few people".
|
|
|
|
Jacqul
|
|
June 11, 2014, 03:04:22 AM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense. As I said, those coins (aside from the three 150k blocks) weren't really a pre-mine at all. The game was public for those 8k blocks, it just wasn't until that time that it was really being promoted, reddit activity, etc. That is all I mean. This is just what you would expect, information spreads over time. But you were saying like if it was announced only 6 days after launch. EDIT: I had dozens of connections in those early days, so it wasn't "a few people". Personally I was watching this coin and playing the game quite a while before launch. I played as soon as it launched and got a few of the sub 30 blocks. I made a thread in a few places because I thought the idea is awesome. The pre-mine was tiny and announced. WilliamLie has been awesome and I can understand if he is despondent because of the early rise of botters ( we weren't expecting them this early.) Dev responded to community concern about the target time dropping too quickly and changed pay out from 100 to 20 and dropped the expected time. I think the launch and everything since has been great. The only problem has been the botting and the dump on C-Cex when this was became clear. Miraculously the coin survived and is still going. Since then there has been some very interesting discussions as a spin-off from the botting problem. WillimaLie is still engaging and support the coin. Just wanted to say thanks for the effort. I have enjoyed this coin a lot so far and I'm very interested to see where it goes from here. If dev wanted they could've scammed and made more money than they did from premine considering the effort put it. So far they have acted with integrity and been very capable.
|
|
|
|
BTCat
Legendary
Offline
Activity: 1960
Merit: 1010
|
|
June 11, 2014, 07:53:00 AM |
|
Vote for MOTO to list on Mintpal. nr. 433 Motocoin Pay to vote (Each 0.001 BTC received will count for 1 vote): 17JFRp2snSqNLYij7v6mvK1vUfQgWmtwgY https://www.mintpal.com/votingSeriously, 1 vote in over 12 hrs? Such lazyness.
|
|
|
|
radi324
Full Member
Offline
Activity: 196
Merit: 100
Muniti creator
|
|
June 11, 2014, 07:59:42 AM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense. Sold the premine yet?
|
|
|
|
HunterMinerCrafter
|
|
June 11, 2014, 12:04:12 PM |
|
The "other" premine wasn't really a premine at all. The chain was soft-launched between a few people, and spread quietly for a few days (~6) before being announced here and elsewhere just before/around the block 8000 fork.
WHAT? This coin was announced here 20 days before launch. Ok, re-announced here, I guess. :-) Are you a troll? Everyone can just read beginning of this thread to understand that what you are saying is a complete nonsense. As I said, those coins (aside from the three 150k blocks) weren't really a pre-mine at all. The game was public for those 8k blocks, it just wasn't until that time that it was really being promoted, reddit activity, etc. That is all I mean. This is just what you would expect, information spreads over time. But you were saying like if it was announced only 6 days after launch. EDIT: I had dozens of connections in those early days, so it wasn't "a few people". I didn't intend to start any drama, I was just making an offhand comment, and it started others in on the premine argument. I couldn't care less about the bounty. It is a bit of a shame that the giveaways won't happen, but that doesn't affect me any. Can we get back to the topic at hand? Is there any ETA on patches for the difficulty target or for the map reset frequency? Should I consider putting something together? One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain. As for the map reset, I still think that simply allowing the users something like 4 blocks of "slack time" (by using 2 bits of nonce to specify which of the top 4 blocks to generate map from, and adjusting confirmation semantics accordingly) is the best approach.
|
|
|
|
DeepCryptoanalist3
Member
Offline
Activity: 81
Merit: 10
|
|
June 11, 2014, 12:27:15 PM |
|
One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain.
What was that? I only see a bunch of words with no sense. Perlin function has no scale difficulty. What does it mean a "perlin complexity"? Perlin noise computation is not related to the map size it is always calculated from the 4 nearest points. And we aren't looking where to inject computation difficulty it is not a PoW currency.
|
|
|
|
WilliamLie2 (OP)
|
|
June 11, 2014, 12:42:25 PM Last edit: June 11, 2014, 12:54:48 PM by WilliamLie2 |
|
Is there any ETA
No. One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain.
What was that? I only see a bunch of words with no sense. Perlin function has no scale difficulty. What does it mean a "perlin complexity"? Perlin noise computation is not related to the map size it is always calculated from the 4 nearest points. I agree, no sense. As for the map reset, I still think that simply allowing the users something like 4 blocks of "slack time" (by using 2 bits of nonce to specify which of the top 4 blocks to generate map from, and adjusting confirmation semantics accordingly) is the best approach. This is some huge and complex change to the whole blockchain semantics. I still don't understand how are you going to add transactions if you generate map only based on previous blocks. But anyway, this would require a lot of time to work out this scheme and a lot of changes to client.
|
|
|
|
WilliamLie2 (OP)
|
|
June 11, 2014, 12:50:54 PM Last edit: June 11, 2014, 01:05:39 PM by WilliamLie2 |
|
by using 2 bits of nonce to specify which of the top 4 blocks to generate map from, and adjusting confirmation semantics accordingly
Ah, now I see how wrong it is. If you measure distance from top block then you should include hash of block that you think is top, but if you know its hash then you can just generate map from it.
|
|
|
|
HunterMinerCrafter
|
|
June 11, 2014, 01:18:44 PM |
|
One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain.
What was that? I only see a bunch of words with no sense. Perlin function has no scale difficulty. What does it mean a "perlin complexity"? Uhhhh, wut? Perlin complexity is 2^N where N is the dimension of the seed. This is well known, is even on the wikipedia page under "complexity" heading. Right now we are calculating a two dimension perlin coherency from a two dimension seed, so we have constant complexity of 2^2. There is nothing preventing us from calculating a two dimension coherency by first calculating a three dimension coherency from a three dimension seed, and applying a (modular) combiner to "flatten" the resulting noise into a 2d coherency. (Arguably we could also scatter the 3d coherency back onto a 2d plane, and re-seed a second perlin round from the resulting (now 2d) noise, but this gives us an overall polynomial exponential complexity, instead of the nice, clean "2^N curve like bitcoin has" outcome.) Perlin noise computation is not related to the map size it is always calculated from the 4 nearest points.
It is calculated from 4 points only in a 2d space. It would be calculated from 8 points in a 3d space, 16 points in a 4d space, 32 points in a 5d space, 64 points in a 6d space, and so on. See where the 2^N comes from, now? And we aren't looking where to inject computation difficulty it is not a PoW currency.
Huh? It is most certainly a PoW currency (just with a very "fancy" work function) and we certainly are looking to inject (in some form) computational difficulty. (Any proposed solution that doesn't result in increased computational difficulty doesn't do anything to hamper bots. The only real metric for the bots' performance is computational difficulty of the work challenge!) I'm just proposing that we might be able to do it directly/explicitly via a complexity curve, instead of trying to come up with some way of "indirectly" coupling difficulty and targettime, likely by playing with block acceptance semantics, as we've proposed previously. I'm just trying to offer more options. I'm not saying that this would necessarily be better in the long run than doing it indirectly (I think there are pros and cons both ways, and multiple trade-offs to be taken into consideration) I'm simply pointing out the possibility.
|
|
|
|
HunterMinerCrafter
|
|
June 11, 2014, 01:25:27 PM |
|
by using 2 bits of nonce to specify which of the top 4 blocks to generate map from, and adjusting confirmation semantics accordingly
Ah, now I see how wrong it is. If you measure distance from top block then you should include hash of block that you think is top, but if you know its hash then you can just generate map from it. I thought we covered this already... Under this scenario you *could* just generate the map from the top block, but you are not *forced* to until the block you are working on becomes too old. Yes, your submitted work would include the hash of the block you think is top (as normal) as the previous block reference, you just wouldn't be forced to use this most recent block as map seed. As such, forced map resets would be 4 times less frequent. We could use any number for the allowed depth, really, and could even have this number adjust dynamically based on block rates, to keep map refresh frequency relatively consistent with network hash rate.
|
|
|
|
WilliamLie2 (OP)
|
|
June 11, 2014, 01:42:18 PM |
|
I thought we covered this already...
Under this scenario you *could* just generate the map from the top block, but you are not *forced* to until the block you are working on becomes too old. Yes, your submitted work would include the hash of the block you think is top (as normal) as the previous block reference, you just wouldn't be forced to use this most recent block as map seed. As such, forced map resets would be 4 times less frequent. We could use any number for the allowed depth, really, and could even have this number adjust dynamically based on block rates, to keep map refresh frequency relatively consistent with network hash rate.
As I tried to explain you, no one cares about what you submitted if you didn't protect it by some proof-of-work. Therefore, it is unnecessary to complicate protocol by sending useless stuff (like previous block hash in your example).
|
|
|
|
|