Topic: [ANN] [MARKS] Incentivize Content Creators & Build a Reputation Value Framework - page 16. (Read 32570 times)

Good Project.. But How we can check that How many tokens have already been sold? Good luck guys!

 
This is good advice.

the team of this idea is very experienced I think, because there are some advisors from famous technology companies, such as dell, google ... this concept is interesting mix between paypal and cryptocurency .. Good luck guys.

Why ? This is not obvious at all. Proving this kind of baseless assertion, (if that were possible), would certainly require a proof spanning more than one line (pun intended). There is no way to prove this. This is just more embarrassing mental confusion, opinion and FUD from our erstwhile coder. (Yes, another high-brow word. Look it up. LOL)

A decentralized currency can follow the emission policies being set by CEM and the mergeReduction factor and still be decentralized. All that is required is that users and miners adopt these rules and follow them in a P2P decentralized fashion.


Correct. And this was a very serious problem for users, who just want their transactions to go through quickly. Therefore, the idea of CEM was born: Decouple the coin emission rate from the rate of block production. Now block production rate does not equal coin emission rate. Block production rate is stable, (averaging 2 minutes between blocks) and equates primarily to expediency of transaction processing.

Regarding the selfish mining issue, I believe Andrew K's understanding is again lacking. Selfish Mining is primarily about being able to tinker and abuse the timing and time-stamping, and abusing some measure of superior hashrate. Not directly related to block rewards at all. Please read and understand Bitcoin Core contributor David A. Harding's explanation on StackExchange.

I truly find it surprising that @onelineproof is so married to the idea of merge-mining.
He almost seems like the prophet of a merge-mining religion and the one true emission rate .... That is the only reason I speculate  about his motives. (And I acknowledge these possible motives are speculative, and by no mean hard accusations.)  
Talk about nice & reliable. Employ a guy for over a year, and then have him call the team's development direction and ideas a "scam" just because he doesn't understand, or they don't fit his erroneous notions or finds them unpalatable for whatever reason. That kind of baseless hyperbole and hysterical name calling has no place in a professional team; you may be free to disagree,  to express strong reservations, to try to prove your point of view etc. But to go so low as to imply fraud and ill intent, well, frankly that is just unacceptable. People who have followed Bitmark from the start will realize how far from the truth these accusations are. It is with real chagrin that we have to stop working with him.  

These ongoing accusations of "scams" which imply criminal fraud and intent, are simply unacceptable when the reasons to reduce merge-mine rewards are clear and founded on principle; they are not capricious nor random. Further, they are called for by the majority of the Bitmark community.

 Again, at risk of being repetitive,  despite being spelled out for him numerous times, let's say it again: It is honest and correct to reward work according to effort. Merge mined blocks are achieved with much less effort than native mined blocks. They should be rewarded proportionately This undisputed fact has unfortunately not yet permeated into @onelineproof's understanding. If this happens to lower emission rate, ¿so what? There is no rule that says a certain emission rate has to be maintained. That is just baseless dogma.

82ndabnmedic: I never said there was something wrong with you controlling another account. I am just clearing it up that's all. And to say I was ever disrespectful is nonsense. I always gave everyone a chance to make their case. In fact the current lead developer who replaced me (jarr0s) was disrespectful as you can see he called me "a rookie" and "retarded" on the github thread https://github.com/project-bitmark/bitmark/issues/68. All I did was say the truth by calling what I see as a scam a scam. Giving honest opinions is disrespect? I guess in their view it is because I got banned from slack, and jarr0s remained.

If you look at the website of Melvin Carvalho that @82ndabnmedic linked https://melvincarvalho.com/#me you can see a site where a guy claims to be this big mathematician and computer scientist who worked with these high-profile people. But can someone find me actual work he did or any papers he published? Also on the project-bitmark github you can see that his contributions are extremely minimal. On his github (melvincarvalho) it seems he is working on some repositories related to a "solid-server", it's unclear. My contributions to the project-bitmark repo are actually hidden because I didn't use my official username, so you will see many commits with "AK" or "Andrew K" in them, but I think I would have the top commits for that repository, even more than the original developer Mark Pfennig.

And now more invalid arguments coming from dbkeys. So let me clear up what CEM is. CEM means "coin emission modulation". It reduces the reward from 100% down to a maximum reduction of 50% according to the current hashrate (in the last 90 blocks / 1 day for an algo) compared with the peak hashrate for 365 periods of these 90 blocks. It was his idea actually. It is a good security feature actually. It incentivizes miners to work at peak hashrate. Without it, miners would be incentivized to collude so that they can work less for the same reward, which is basically how selfish mining works. An individual miner or a group of colluding miners mines in secret and then releases the blocks all at once, and it only requires about 30% of the hashpower as psycodad pointed out, so it lets them get the same rewards for less hashpower, and drives other hard working non-colluding miners out. With CEM, the selfish miners may get the first 90 blocks for cheap, but then with the lower hashrate, their reward would decrease, defeating the purpose (or at least diminishing the use) of their attack. We actually had a form of CEM before fork 1. We had a slow difficulty adjustment algorithm that would cause blocks to come at a slower rate when hashrate is low, thus reducing the emission rate in terms of real time (rather than block time). Now with the fast difficulty adjustment algo (DGW + resurrector), block time matches real time, so this keeps the same effect without delaying blocks for users. As long as miners are working at peak (providing peak security), the emission rate matches the target rate. It has always been like that. Further, the actual CEM reduction value is dependent on market forces and cannot be easily predicted or manipulated by insiders, especially with merge mining where the market forces depend on the value of other chains.

What dbkeys' fork does is completely cut off 80% of the maximum reward for merge miners, making it completely unavailable even if the miners are working at peak performance. Without paying bonuses to native miners, the emission rate will no longer be at target even if all miners are working at peak, except for the almost impossible scenario that all miners switch to native (sure lets leave that to luck!) (it's likely merge miners will take about 60+% of the blocks as they are now). Whether a miner native or merge mines depends on market values of other coins compared to Bitmark, and cannot be just set with an arbitrary fixed parameter for the differences in merged to native rewards. A bonus paid to native miners would also be needed to create a balance of merged and native miners, with a target ratio of merged to native blocks given by a parameter that I think should be dynamically voted on by users in order to be a completely honest protocol. I supported even a ratio of 99 native blocks to 1 merged block, as long as it was decided by dynamic user voting as you can see in the github thread. Whatever you do, you need to make sure the target emission rate remains the same when mining is at peak, that's just obvious if you want to continue claiming it's a decentralized currency.

Oh and for the insta-mining / faster issuance rant, of course I would never agree with increasing the emission rate, so what is his point? The point is that the rate is pre-determined and not changed (up or down) after that, because both upward and downward changes can benefit special interests.

And yes it's wrong to consider the hardship of a group of investors when making protocol changes. The genesis block of Bitcoin has the following data imbedded: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". No bailouts! Dbkeys now is suggesting that I'm a scammer because I can imagine that someone is a scammer. He's going much lower than I would expect...Sure call me a scammer, it's your free speech and I will defend my position. I have met many people in my life who seem nice, who seem reliable, but then it turns out they're not that nice and not so reliable. It is not hard at all for me to imagine that someone would be a scammer, and the point of P2P currencies to create a trustless system for transacting, without having to trust any one person, without having to trust any miners to be honest, because like it or not, people cheat and people are dishonest!

@Matiel says:

That's a very good question actually and related with what I just said. I am likely spewing a bunch of technical stuff that people may find hard to follow. Dbkeys seems to be throwing around sophisticated English language words (to appear educated, well-read, have a high social status, and thus unlikely to be a scammer). Ideally, you shouldn't trust anyone and just verify the logic and evidence presented. Also you should validate the code if you can (trust just the code and not the developer of the code). I think I made my argument clear. I don't want to repeat everything. If you have a particular quote of mine that you think needs clarification, then ask me, and I will clarify. This problem of "what is the truth" is also the problem that can be efficiently solved by Bitmark if it truly becomes a decentralized reputation system. We are constantly fed loads of information, and it is hard to know in what order information should be prioritized for further analysis and judgement on the conclusions. With a reputation system, we can more efficiently prioritize information so that we can quickly come to accurate conclusions based on who we value as accurate, for what category, and what fundamental assumptions we make. Different people may have different fundamental assumptions, so I hope such a system could allow for flexibility in that.

Anyway, a simple way to know, without much analysis is look at the block explorer (explorer.bitmark.cc or explorer.bitmark.co). Do you see any problems with Bitmark? Are blocks getting delayed? Are miners attacking? Is Poloniex blocking withdrawals because of some attack? No. All you see is a group of people called "Team Bitmark" who are rushing to put a new fork, without carefully analyzing what they're doing, and talking a lot about price and investors. Price is actually quite stable now after the adjustment of fork 1 to a fairer market value. Maybe it's "low", but it's stable. So you can judge based on that what the truth is.

If I do become a lead software maintainer for a cryptocurrency, and then if someone puts a gun to my head and makes me tell people to support a corrupt fork, then I sure hope people do revolt against me, because otherwise it means the project is dead. In this case, I think it is more likely that we have a group of investors who are under financial pressure due to poor decisions they made, and instead of putting in the hard work necessary to improve the situation, they want to take the "easy" way out.

If people don't support my vision for Bitmark, then I will create another chain (possibly with a new currency or simply with Bitcoin transferred into a sidechain). Decentralized reputation is far too important to be left to lazy scam-rationalizing clowns.

I had one email about listing a coin on an exchange for 0.5 BTC. $3000 for a listing? No thanks, but I can get you some good volume if you list it!

Reading everything posted reinforces my impression that @onlineproof is a bit too rigid and does not know nor understand the history of Bitmark, even after I went through the trouble of generating and posting the emission graphs of the coin.

His fervor for adhering to an emission schedule that never was is... just silly. Especially in light of the long history of discussions about Coin Emission Modulation and its entire reason for being, which finally came to bear fruit in Fork#1: To reduce emission to match market demand. Try as he might to say this is not important, and "not the reason for it", it is exactly the reason for its existence; the record is out there on Bitmark's Github, and on extensive discussions in the Slack archives as well.

While it is true that the theoretical emission schedule could be adhered to, even while reducing rewards for merge-mining, it would mean that native rewards would have to be higher than the epoch's max reward.  It would no longer be a "max" reward.   There is no point and nothing to be gained by this.  _That_ would be disorderly and senseless. This goes against logic, and this viewpoint can easily be demolished with recourse to reductio ad absurdum.  If it was a good thing to issue coins faster, then why not issue them all quickly, in short spurt, insta-minining style ? Yes, in fact, why not just issue them all at once, ya, the entire remaining emission, some 17 million coins, to the lucky miner of some soon-to-be-issued block ? It would be just like winning the lottery !  Whopeee !   That would certainly accelerate the emission...
 But of course not:    ¡ Because it would be absurd !  The mindless, rigid insistence on adhering to a schedule which
   #1) Has never been adhered to in reality anyway (due to the rigidity and ineffectivenss of the original diffalgo), and
   #2) Because CEM v0.1 already throttles emission and stretches that schedule anyway,  (and not a single person before @onelineproof complained) exposes the insistence on blindly following a theoretical emission rate for no good reason as some kind of unreasonable religious fundamentalism.  
(It bears repeating that the total emission of some 27 million MARKS has never been in question or proposed to be altered. That emission is an absolute cap, and will eventually be reached.)

From the outset, Bitmark was designed to have not only block reward halvings, like bitcoin, but also intermediate quarterings, in order to reduce the importance of mining early-on versus later in the lifetime of the coin.  This is was established in the early days, the midSummer of 2014. The guiding philosophy is clear: let's make it equally attractive to mine this coin in the beginning, or later on, even years later on. By dynamically throttling the emission rate when the market calls for it, price stability is fostered and mining viability is ensured far into the future.  By throttling it further, when it is warranted for good reason (the principle of remuneration of work according to effort) this guiding idea is respected and strengthened.

CEM v0.1 already started the path in this direction, by moderately slowing the emission when hashrate is below recent peak performance.  CEM v0.2 strengthens this authority even more.

As far a the issue of merge mining goes, it is clear that it is desirable in certain measure, but not as the only kind of mining for  our blockchain, and must not dominate to the detriment of all native mining.  Perhaps a more dynamic adjustment of merge-mine rewards vs native mining can be achieved in the future, but for now, a simple scaling will do. It is honest and correct to reward work according to effort. Merge mined blocks are achieved with much less effort than native mined blocks. This simple fact has unfortunately been denied entry into @onelineproof's understanding, apparently.

 Because a large number of our blocks are now merge mined,  emission rate will be reduced, but as far as price goes, this would hardly create a pump. The current price of Bitmark is well below historical levels, in large measure because Fork #1, (while solving a number of difficult problems the coin faced), also opened a fire hose of emission, flooding the market with coins. If anything, fairly adjusting reward for merge-mined block may restore or help bring up the price to the levels it was at before, but to characterize that negatively shows a remarkable ignorance of the situation we are experiencing; a distorted perception of the true picture.

The dark accusations remind me that of a saying, sometimes involving leopards, sometimes lions,  (and sometime thieves !)  which goes something like this: 'The leopard thinks everyone has the same "spotted skin, as he does'.    In Spain, the  saying, ("el león cree que todos son de su condición"),    roughly translated: "The Lion thinks everyone is of his same condition"   leads me to suspect that perhaps he has ( or had ) some deal to exploit merge mining of the coin and now sees this plan threatened. Perhaps it is for personal reasons that he is so strongly opposed to what should be a relatively minor change in the big picture, bringing some balance to the ratio of merge-mined and native blocks. For the first 4 1/2 years, all Bitmark mining was native mining. Now we are unwittingly dominated by merge-mining.   Fork #2 simply seeks to restore balance to this situation.

In fact, we plan to make a two algos native-only again, and perhaps introduce an additional native-only algo. This would mean that at least 1/3 of the algos are native algos. This will, in fact, increase the rate of emission, since native blocks are not subject to the merge-mining reduction factor... and, all miners are welcome to be Bitmark native miners and earn the full native rewards.

About the only thing I agree with in the criticism leveled is that reducing the CEM window from 365 days (1 year) to 30 days (1 month) might be too drastic, therefore I will suggest that we only reduce the CEM look back time frame to 1/4 of its previous reachback, to 90 days (3 monts).


A couple more points:

The false analogy made to the arbitrary manipulations of fiat central bankers simply does not apply.
 First of all, because Coin Emission Modulation is not based on whimsy or human capriciouness. It is an algorithm, just like DGW is an algorithm, as are all block reward epoch reduction algorithms, they are algos written into program code. Of course program code _can_ be changed, (and should be) for good reasons, but this is done sparingly, and these changes are published and open sourced for public inspection.

CEM is an algorithm which attempts to track demand by equating hashrate to demand, and adjusts emission according to demand. Thus, it is not humans attempting to manipulate anything  (as the Chair of the Federal Reserve does by deciding to "Quantitatively Ease" the value out of your fiat savings) but  a coded algorithm, much like DGWv3 is an algorithm that regulates the timeliness of block production and ensures that transactions are processed promptly, CEM v0.1 and CEM v0.2 regulate emission to match market demand as best as possible, based on the only blockchain-instrinsic analog metric of demand available: mining hashrate.  The total eventual money supply of Bitmarks has never been changed, and more importantly, is limited to less than 28 million coins, (similarly as Bitcoin is limited to less than 22 million coins), as are most other reputable cryptos.

Also, addressing the question of tickers. Our original ticker BTM, while still in use in different venues, including Poloniex.com,  is also in conflicting use by a latecomer coin, Bytom. The Bitmark Project decided to change to and use MARKS as our main ticker symbol, both to avoid conflict and because it better represents the ultimate purpose of our blockchain. We lay claim to MARKS and hope others respect this.

I apologize to the Bitmark [MARKS] Community for the distorted and disrespect @onelineproof has shown to the community....Yes We announced that the TeamBitmark account would be used as our official means of communication for updates and coordination....so to say it is a puppet account (for me or the team) is utterly out off touch & offensive.

@onelineproof  I wish you the best of luck, I can rest easy knowing that I attempted to reach out and collaborate with you...in search of some mutually beneficial resolution....But working with you is all or nothing (and the sad this is that the part your "all in on" is flat out wrong/and based on distorted views of the market/blockchain dynamics)...

Correction, He was never our original Developer, he was initially an employee which we assumed may chose to become a full member of the team. -  (this is no longer an option)

So Lead Dev = No

Our Lead Developer is and has been Melvin Carvalho

https://melvincarvalho.com/#me

Melvin is an amazing developer and his needs no introduction.

TeamBitmark is a puppet account of 82ndabnmedic I assume, since the writing style is the same. What vote? Where did it take place? On slack where people get banned for disagreeing with the fork. How can you not get 100% support in such an environment?

I actually have a significant stake in Bitmark, it's not just peanuts. If I were to lose all my marks, that would be a very significant setback financially. I do have skin in the game, but for sure I would sell what I have on dbkeys' fork. The price of Bitmark never surpassed $1 except for a short time last winter when Bitcoin peaked, and the market cap never surpassed $7 million, except for that short burst. The BTC value of marks in 2014 is a useless measure since there was much less altcoins at the time, bitcoin value was lower, and there was much less marks in circulation. Same with any other BTC price / market cap. The only meaningful marketcap is USD since that's the dominant world currency right now. From 1.2 million to 7 million market cap is quite easy (we just saw a rise this month from 1 million to 1.2 million). Reducing the emission rate will not magically increase the price, it will reduce selling pressure so investors can more easily dump. Any gains will likely be temporary and unstable.

The email I listed previously in my signature seems to have problems so I am changing it back to my previous email:
@gmail.com
Like I said, this is the last chance if you support the uncorrupted version of Bitmark. Block reward changes that favor special interests will be visible on the blockchain forever. You cannot hide it.

It is not true that I didn't compromise. I personally believe merge mining is better for security and decentralization than native mining, but even if you do want to reduce the rewards of merge miners, I did accept that to a certain degree. But dbkeys mixes two things that are completely separate: 1) Reducing the reward for merge miners relative to native miners, 2) Modifying the emission schedule. (1) can be done in various ways without (2). You can see the github thread for 3 of these ways: https://github.com/project-bitmark/bitmark/issues/68#issuecomment-408140614. But now dbkeys is saying that those other ways would have merged miners quickly bringing up the peak hashrate of the native algo variant, and messing up the CEM calculations, so he wants to keep native and merge miners with the same difficulty adjustment, just with a different reward. But you can still respect the supply schedule. Just like DGW adjusts the difficulty to meet a target time for blocks, you can adjust the "bonus" paid to native miners to meet the emission rate target (taking into account CEM), with small variations about the mean (also other ways I thought of that don't require any variations). So you can think of the bonuses as money saved by paying merged miners less. Like I said, I would like merge mining to remain fully dominant, but at least this solution would respect the emission schedule, thus I wouldn't call it a scam.

Then they might say, oh well lowering the emission rate will help to delay the need for a fee market. But you need to understand what the point is of Bitcoin and other decentralized cryptocurrencies. Bitcoin was created in order to prevent the manipulation of the money supply by central bankers. A predetermined algorithm is used instead of people deciding what the proper emission should be at any given time. You can even read this in the bitcoin wiki: https://en.bitcoin.it/wiki/Controlled_supply
If the rate could be modified on the fly then insiders could use that to profit. They could buy before the announcement of a lowering of the rate, and sell right before the rate is announced to be increased. In general it can be used to temporarily create favorable conditions for special interests. Also miners look at this and see that the rewards are not stable, no good track record, and are more likely to attack the chain as a result.

There is also 2 other changes in dbkeys' fork. Only 30 periods instead of 365 are used for calculating the peak hashrate, and CEM can reduce the reward by up to 80% instead of 50%. I can give you many reasons why these changes would harm users, but it is important to understand that any drastic protocol change without clear proof that it benefits users is clown shoes. As for setting a fork height without a miner supermajority, it is dangerous for users who may end up sending money on the wrong fork. It's irresponsible.

As for the quote of me saying I'm stubborn, well yes it's true and I have high standards for some things, maybe higher than average. I don't think I'm such a good programmer, I just work hard on whatever I'm passionate about and pay attention to details. I mostly said that because they were pressuring me to do something I don't want to do, so I didn't want to give them false hope. I would be surprised if my comments on Slack are still publicly viewable, as I was banned from there a month ago by 82ndabnmedic, just for expressing my disagreement with the fork. I can also find you quotes of dbkeys saying how he wants to send a percentage of miner rewards into a developer fund (that was blocked by Melvin) and how he wants to consider master-nodes or proof of stake voting or mining... And for the price, who knows. I think $0.10 is a strong bottom, even with all merge miners selling. A 1 satoshi price would be almost impossible and it was an exaggeration. $0.10 to $1 is easy within a year. But people have to actually work hard to improve the protocol instead of coming up with ways to work less.

As for the person who said my thoughts about double spend protection are wrong, let them come here or any other open/uncensored forum and I can debate them. I think they are wrong about this, and also there is a nice thread about merge mining security in the bitcoin-dev archives: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html. I think one conclusion from that is that as long as you are not a scam-coin, merge mining is quite secure, and still the best you can do compared to the other alternatives.

I think currently, from the Bitmark community, there is just a few people who strongly support dbkeys' fork and most people don't care or don't understand the issues. If you see the github thread, I also initially said "sure why not, let's reduce the merge miners reward by 50%". But after more careful thought, I changed my mind on that and definitely don't want to mess with the emission schedule. On my side I see some kind of support from the following users in this thread: psycodad, tync, Matiel. Also I had some level of support by someone who contacted me privately. But I need strong support from at least a few people. So please make it known or contact me privately at least, and like that I can try to submit a petition to exchange to include my vision for the fork, and even let dbkeys have his vision under the BTM ticker if he wants (though I think putting scam-coins on an exchange would be unwise for the reputation of the exchange). I am in good contact with people who work in Trade-by-trade, but I don't want to use my access to push my own vision and I definitely need an exchange to make sure I am not the only person mining the chain. So this is the last chance! dbkeys' fork may activate in less than a week.

I think in the future sidechains will enable multiple currencies to exist on one blockchain (for the purpose of paying miners for transactions). They cam also further decentralize mining (no merge mining 2 sidechains of a chain at once). You could have for example Bitcoin being transferred to the Bitmark blockchain, and people can choose to pay with Bitcoin or Bitmark, just like now USD can be used in almost any country, but you could still use the local currency if you want. To transfer the Bitcoin would have a waiting time, so sometimes it would be better to use the MARKS, or marks could just be a backup, in case there are some problems with Bitcoin. So I don't think sidechains will completely kill altcoins, and still, with the best computers and moon-math, it is very inefficient to use sidechains in a trustless manner. The network effect (strong bonds between P2P nodes) with those nodes resistant to many attacks is what makes a coin a good store of value.

As you see on the project-bitmark github, they have pushed to master the fork dbkeys proposed (so he can easily sell his stash). Not only does it fundamentally change Bitmark from a P2P cryptocurrency to a crowdfunding campaign for investors, but it uses cheap hacks to get the thing done (forced block height not even waiting for user or miner votes), doesn't fix important bugs, and still continues to be advertised as a "decentralized cryptocurrency". If it is not 100% crystal clear to someone that this fork is about manipulating the price from the supply side, then ask me and I can try to make it more clear (except for dbkeys whom I already explained this to repeatedly).

In case someone / people want to continue with the current protocol, with a couple of minor/bug fixes that technically need a hard fork, then I created a github repo called bitmark-protocol, that has this under the software version number 0.9.7.3 (dbkeys' fork is 0.9.8.x). The core block number remains as 4, just a variant/subversion number 1 is embedded into the full version number, so the version number for blocks would be called 4.1 (dbkeys's fork has version number 5). My fork would require 950 out of the last 1000 blocks signaling for version 4.1 to activate. The code is available at https://github.com/bitmark-protocol/bitmark. You can clone the latest master for stable code. It is quite well tested, though I will test more thoroughly if I see version 4.1 blocks being mined. The dev branch is for developments before they enter master. I also launched an explorer for monitoring blocks: https://explorer.bitmark.cc and https://explorer.bitmark.cc/testnet for testnet.

The 2 fixes in this release are:
1) Use Bignum for the subsidy scaling factor to prevent an overflow that has occasionally caused block rewards to be much less than they should be.
2) Activate the resurrector even right after the surge protector kicks in. Currently, 25 blocks must pass before the resurrector (lowering of difficulty after some time of no blocks of an algo) can kick in after a surge protector event (9 in a row for an algo). This is a rare case, but still needed for correctness.

If there is not enough support for my fork, then, instead of creating a new coin, I will likely work on migrating the Bitmark protocol into a Bitcoin sidechain. Sidechain technology is still not mature and requires some layer of trust, but I think it can work and help other sidechains thrive as well. You can see my post about this here https://bitcointalksearch.org/topic/m.44289606

By the way, dbkeys' fork is not even well tested, they use the requirement block.nVersion >= 5, while it should be GetBlockVersion(block.nVersion) >= 5 in order to force version 5 blocks. The raw version number only worked for the first fork where we first introduced the notion of raw (with extra data) and core version numbers. It's not a critical bug, but still shows lack of testing.

Yes, this happened to Verge and is the reason they went 5mPoW.

This is perfectly right as you describe it, though the selfish miner is at all times connected with the honest network and nodes.
The selfish miners two or more nodes are connected to the whole network and they seem to agree on the chain all nodes have (while in hidden the selfish miner advances the chain on his 2+ nodes secretly).

Say, the honest network is on block # 1000 and all nodes agree on that, then the selfish miner mines say until # 1010 but leaves the network thinking it is still on # 1000 by not releasing these blocks. Only when the selfish miner hears from one of its peers that a block has been found and broadcasted by a honest miner, he/she will release 2 or 3 blocks to invalidate the honests miners work. If he he has and advantage of ten he can even wait longer to invalidate the others blocks.

There are certainly checks and balances in most wallets that limit how many blocks one can release at once and so on, I can't say much about this as I never dug into these parts in the code. Though the attacker knows this exactly and has "tuned" wallets/nodes that make sure other blocks are only seemingly accepted from honest nodes and he/shee only releases his blocks when needed and in an interval that is acceptable for the specific network currently attacked.

In the last 2-3 yrs we saw this very same attack on quite a lot scrypt chains (don't know about others, I am only into scrypt chains) like BTM, EAC, WDC, TIPS just to name a few and I am pretty confident it is still going on, ABY seems to be a current example of it.

Thanks for the clarification @psycodad. And this is what was happening. Nobody but Mr./Ms. Selfish mined Bitmark until they left, and shortly thereafter we switched to 8mPoW with DGWv3 anyway.  

 IIUC, this selfish-mining is possible (at least in part) because a larger chain can appear out of the blue and is accepted by all the nodes, because it is the longest, most-work chain, although the "honest" nodes had not seen the selfish node before at all.
Thus, the "selfish" part: The Selfish Miner did not share their work (and thus allow possible competition) until they were sure they hade a stronger chain to show.   Can you shed some more light on this ?

You don't need 51% for selfish mining at all, roughly 30-40% are sufficient depending on the specific selfish mining technique used by the attacker/selfish miner, even much less if the chain is stalled for weeks like BTM was at that time.

Selfish mining is not to be confused with a 51% attack where the goal is to doublespend inputs. The selfish miner just wants all blocks at lowest possible (hash-)price and to annoy honest miners until they leave by constantly invalidating the blocks the honest miners find.

The biggest wallet without any doubt is Poloniex wallet.

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (probably above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.