Yes and no. Monero's stated policy is to tweak the algorithm to break existing ASICs and deter new new ones, which would fit within what I said, in doing little other than creating a temporary advantage. I don't think that's a good approach for AEON in part because the frequent forks are a burden on limited developer resources, more likely to result in a screwup due to limited resources, fewer eyeballs on the code, etc.

The first tweak (variant 1) did only that, and did not even attempt to improve the ASIC-resistance in any fundamental way. The second and third (third being CN-R) tweaks actually attempt to improve ASIC-resistance to some degree and by some accounts (not really confirmed nor confirmable) have reduced the ASIC advantage, though not enough. RandomX attempt to reduce the advantage drastically and reduce the need for frequent forking. I do not know if it would or will be successful.

I'm neutral and I will support either continuing to tag along with Monero's anti-ASIC strategy or ASIC-friendly and low-overhead algorithm such as SHA-3.

I don't support ASICs on cryptonight nor arbitrary changes to this or that algorithm with no useful properties of its own but intended to give temporary advantage to GPU miners for some limited period after a switch.

I'm not going to embrace Cryptonight ASICs because such a thing is pure stupidity from a design perspective (useless added cost and complexity and poor verification time, and increased DoS vulnerability).

If we embrace ASICs it will be with a sensible ASIC-friendly algorithm. The only reason to make the tradeoffs Cryptonight does is "egalitarian mining"

Okay I read that one when it was first posted. It gets into a lot of "he said, she said" type details which are IMO missing the point.

There are certainly different views of what went wrong. My view is that the whole thing, while well-intended, was a bad idea, and still would have been a bad idea even if the results had been somewhat better.

Incremental approaches with usable intermediate milestones like better Tor integration or figuring out how to best integrate with existing i2p implementations first before perhaps working on improving them, are a better fit with a largely volunteer-staffed, donation-financed project like Monero. When people flake out and don't finish the work, waste of scarce donation funding is limited. When people leave after finishing the work because they lose interest and want to do something else (or because the price of Monero drops), it is more feasible for others to take on maintenance of the code, or to work on a replacement. When people do some of the work and then move on, the portion already done might be useful in partially-completed form instead of a code doorstop (which in turn makes it more likely for others to take it on in terms of continued development and/or maintenance).

Funding one person for two years to work on a moon shot type project within this context is just a bad idea. It was an even worse idea to do so with one person who didn't already have a track record of successfully developing for Monero, but it would still be kind of bad even if he had. (I wouldn't support a two-year moon shot done by moneromooo either, although I would perhaps or even probably support him working toward a two-year goal with intermediate, already-usable, milestones.)

But remember, the Monero Core team takes a light touch on things like FFS and the community of donators are the ones actually making these calls. If donators want to fund something stupid we are not going to serve as gatekeepers even though we administer the FFS in a narrow sense.

Which article?

There are still issues but at least the modularity improvements mean that it is possible to not deploy the entire enormous runtime (with its entire attack surface) just for one application. So not ideal, but less bad than it used to be.

@joroz That's not quite the right take.

The Java platform features that knaccc is using to streamline the deployment (and expected to streamline it further later this year) either didn't exist or were not in their current state of maturity two years ago. So some of the "progress" was achieved not solely by knaccc's "two weeks" but due to the passage of two years of time, and the work of Java developers over those past two years. Much as I respect and appreciate the work, knaccc alone did not accomplish the "task" in "two weeks".

(It is also not yet a fully-integrated i2p+Monero solution that kovri was at least attempting to accomplish. Whether it will get there remains to be seen but it certainly looks more promising.)

There was a report of Russia starting to buy Bitcoin, but who knows if it is even true.

https://www.telegraph.co.uk/technology/2019/01/14/russia-plans-tackle-us-sanctions-bitcoin-investment-says-kremlin/

Yeah, the SBD pegging hasn't that effective as I stated, but you still shouldn't attach significance to whether SBD or STEEM happens to have a higher price per token. They are very different assets.

@r1s2g3

SBD is supposed to peg to the US dollar. It isn't perfect but it does seem to get around to pegging eventually. After rising to about $10 last year it ended up back at $1. After dropping to 50 cents a month or two ago it has ended up back close to a dollar (94 cents currently, was recently as high as 98 cents).

STEEM is not pegged to anything. It is worth what it is worth like any other crypto (i.e. more when there are a lot of buyers and less when there are a lot of sellers).

You should not expect there to be any particular relationship between SBD and STEEM.

Good point about ETH. They are cutting their mining reward by 30% and it is happening on Wednesday. That's a HUGE amount of hash rate that is being effectively given the boot.

Honestly I am staying the hell away from the Kovri drama. I've been wary of it for quite some time.

That is not meant as a comment either way about whether any action should or should not be taken. It is simply my position that until required by some sense of governance (such as the core team being called upon to weigh in on whether FFS milestones have been met), I will exercise my prerogative as an unpaid volunteer to not get involved with it and to work for a better Monero and a better world in other ways.

That seems possible. RPi is 32 bit right? My clam client (linux command line) after it has been running a while is using about 3.4 GB of address space though not quite that much actual memory. Seems close to a 32 bit limit. I'm on 64 bit system with plenty of RAM so it doesn't matter at all in my case but it may in yours.

I see $5000 24h volume on coinmarketcap. What you are looking at?

Explained here along with alternate ways to access: https://www.reddit.com/r/steemit/comments/adkepr/steemit_has_censored_the_account_of/edj5tgt/

Steemit.com is a web site which views the blockchain not the blockchain itself.

Wider market conditions play a role. It isn't the only factor but it is a factor.

The GUI version of the latest update (0.12.8.0) has been tagged and binaries uploaded. It was waiting for a fix to the Windows build process which has now been resolved.

https://github.com/aeonix/aeon-gui/releases/tag/v0.12.8.0-aeon

Yeah, except for the GUI, RingCT, bulletproofs, updated PoW algorithm, LMDB, mandatory minimum ring size and decoy selection that doesn't completely suck to the point of being useless, and a million other things that actually make it not shit.

It wasn't, it was a bug. Once the bug was fixed and the nodes that got confused were unconfused, there was only one valid chain, no real reorg.

Forking bugs this this can happen in any literally any blockchain regardless of hash rate unless the code is bug free. In fact it did happen in Bitcoin, though it was caught relatively quickly.