Topic: [neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin? - page 9. (Read 95279 times)

Yesterday:


Today:

Feeling damn good right now! Wish I could feel like this all the time.  

The Energizer Bunny dopamine crazed dude:



Edit: ground beef (w/egg and Worcestershire sauce), mozarella cheese, tomato, lettuce, and (no high fructose corn syrup) Heinz ketchup sandwiches on whole wheat French bread again tonight! I am so tired of eating a monotonous strict diet of tuna soup, eggs, oatmeal, raw carrots, and steamed greens. No ill effects from eating this yesterday. If I can eat the food I like again, I can gain back some of my strength. I need that brain food.

Let's go! do strange things! in some far away land in summertime dreams! where the pictures come back from that dead place of suffering and emptiness where they had gone.


Edit#2: the Internet is awesome! It has been extremely depressing for me the past few years to see the Internet become such an amazing creative resource and not being able to fully enjoy it!

I Feel Good!!! (so good)

Demonstrating my research on programming language (type) theory:

https://users.rust-lang.org/t/high-order-function-with-type-parameter/3112/8

https://users.rust-lang.org/t/most-coveted-rust-features/324/38

Or in short, why we probably don't need higher-kinded and higher-ranked types, but we do need first-class disjunctions and inversion-of-control ad hoc dispatch.

Next time my detractors make a thread to try to troll me, perhaps they should remember that when they do that, I turn such threads into a humiliating "tail between their legs" defeat for them every time:

https://bitcointalksearch.org/topic/m.14590792

https://bitcointalksearch.org/topic/m.14597791

Meritocracies can't lie. Those who work hard and are sincere, are not vulnerable to disingenuous trolls.

Hey I tried to basically ignore that troll thread. But some of them got nasty with the verbal abuse and false allegations. So I got "nastier" with the calm, unemotional, ice cold facts.

“Sit in the place of honor at my right hand until I humble YOUR ENEMIES, MAKING THEM A FOOTSTOOL UNDER YOUR FEET”

I will argue my statement was correct as stated, because there are other parties with significant resources and incentives who may not be mining normally but once the hashrate declines to the tail reward cost, they can then decide it is easier to attack the coin.

The better retort would be to argue that the as the adoption increases, the price will rise so the fixed size (in coins) tail reward has an adaptive valuation.

But I will retort that the value of shorting also scales up accordingly.

Rather what I do in my improved design, is to set the cost of mining to the reasonable fraction of the transaction value.

That is why I say the only way to solve the block chain Tragedy of the Commons is to require what is effectively a minimum transaction fee in the protocol. But then there is the problem of miners competing with each other to rebate the fee to the payer/payee so how to enforce a minimum transaction fee?

There is only one way to do that, which is to burn the fees. But if you burn them then the money supply declines to 0. So the only way is to burn hashrate. And that is why only my design which makes mining unprofitable will solve the problem.

This is why only main memory random access latency bound proof-of-work algorithms can potentially remain GPU and ASIC resistant. And they must be carefully designed so that increased computation can not be realistically traded for latency. One of the  challenges in such a design for a memory hard hash, is that very slow speed if you want the memory consumed to be larger than the SRAM caches of GPUs and ASICs. Ideally you want the computation to be very small, so that the electrical efficiency optimization of the ASIC won't be significant.

Signatures should eventually be verified on GPUs (or similar SIMD units that get integrated into CPUs in time). That will happen when it is needed. CPU SIMD instructions are kind of interesting but also kind of narrowly-targeted. Processing large amounts of data in a fixed pipeline will still be more efficient on GPU-type architectures.

But as you may have seen in the asm file above, there's hardly any SIMD in there. It's mostly serial operations. Miner program sending one input, expects one output from the hashing subroutine, thus nothing to do in batches of "same".


I believe it's not only CPU miners that are at stake here. Even signatures could be validated 2-4 at a time, on the same subroutine, to get SIMD benefits. So scaling is affected as well. It would need the main routine to be adjusted accordingly instead of sending 1 for processing (per thread) to 2-4 (per thread) and expect back 2-4. Heck, even cracking speed could be improved.

That is normally how SIMD code is written yes. It is why structs of arrays is more SIMD-friendly than arrays of structs. (Good) GPU SIMD code including miners works just that way, even the first BTC miners I think.

If you think CPU miners can be optimized the do more SIMD processing, and you are probably right in at least some cases, then go optimize and make some money.

While moving some strings to get compilers better at SIMD processing (btw ICC is crappy too in non-array use -I tested it), I think I stumbled on something which could be... well.... interesting...

I was going over the asm files of known hashtypes, in files like this: https://github.com/pooler/cpuminer/blob/master/sha2-x64.S

...to check what is the level of packed instructions that can cut cycles by 2.

(Don't mind that the case above is about bitcoin (which is now ASICed) - this can be pretty relevant for a whole lotta cases out there, including cpu altcoin mining).

So I'm going over the lines... and I'm like, where can I pack stuff together to make a difference, you know... And while I saw some stuff that can be packed, they are not generally too many because the action is serial... one after the other permutation. Then I did a lookup on the file to see how many registers it uses. It's up to XMM11. So there are quite a few extra registers to play around with. And then BAM. It hit me.

It's all wrong on how these hashtypes are used for mass-hashing. You can't do it one by one.

With hashing they are inserting some data and using sequential operations, where one permutation goes to the next, doing some kind of altering to the data, moving bits around etc etc, and in the end you get the hash. One input, one output, no parallelism - except in ...another thread. You can do that, say, 4 times in a quad core.

But that's wrong because you get no SIMD action and packing per thread, to cut the processing clock cycles in half.

What is needed is a mining program that does this:

1) The miner's main routine sends to the hashing routine 2 (SSE) (or 4 for AVX) inputs for checking, not one.

2) A hashing routine with 2 (or 4) inputs and 2 (or 4) outputs.

While inside the hashing routine, and since the routine will be doing the exact same thing for 2 hashes, these operations can be done in SIMD fashion - with packed instructions, instead of serial/scalar. Say the first step of the hash is "we do this to that" but since we also have another "this" we can pack them both to do it. And then there are some more benefits in maths involving the prime number tables where you can do it in parallel by loading the prime in a movddup on a register, moving the data from the first hash to the lower part of an xmm register and from the second hash to the upper part of the xmm register. Then you do them both, and you'are -1 mov too. LOL. The more "fixed data" there are in the hash, the better for parallelism within the same routine - if you load 2 or 4 hashes.

The routine will have to be custom written to process at least 2 or 4 hashes in parallel in order to be able to use packed instructions. In those stages where packing can't be done for whatever reason, the routine will process the stages in a serial fashion (as it would, normally).

3) In the end the routine returns to the main mining routing 2 (or 4) outputs.

Supposing the bottleneck is CPU and not RAM (but even if it is RAM, the CPU will be finishing faster) we are talking about gains that could be very serious (triple digit % on AVX).

The implications of the above, is that, well, every single cpu altcoin is currently cripple-mined.

How is that for interesting?

How can a community wiki answer on StackOverflow have 1000+ up votes and have 19 edits by various superstars, and yet entirely miss the point that literal values are not Javascript Objects:

http://stackoverflow.com/posts/332429/revisions (see my edit #20)

Any way, a little bit of evidence for readers that I am polygot in programming languages. Also continued to demonstrate that today with another post to the Rust forum:

https://users.rust-lang.org/t/rust-as-a-high-level-language/4644/55

Good idea! Thanks. I hadn't considered it because we already had a very good name for the currency that is not related to JAMBOX, but we should also consider the option of naming the currency similar to the social network name.

I just registered:

jambits.org
jamcash.net
jamcash.org

Note we already registered:

jambo.xyz
jambox.biz
jambox.cloud
jambox.io
jambox.me
jambox.org
jambox.rocks
jambox.us

Dink goes on the official contributors credits list, when if ever we create that.

If your vapor coin is secondary to the whole social platform you might consider using somthing like
Jambits ... Jamcash so you dont lose the consistency in a marketing plan, and would keep the relationship between
the two.

Yes indeed the future of messaging is a big one. I have a reference in my JAMBOX business model document on that, which goes into much more detail.

But social platforms aren't peaking. What is probably peaking is Facebook. People will need something new and different, but the inertia of Facebook won't allow just any social network to succeed. It will need to have something very compelling and which doesn't require that people have all their preexisting Facebook contacts on that new network in order to be compelling.


I emphasize that very much in the JAMBOX business model document, that the open protocol should be designed to make it immune from gouging profits.

I've been thinking about social platforms and stuff. These are kind of peaking, or are past their peak. Meaning that fatigue is increasing with their use, but there is one thing where the need is very persistent: The basic problem right now on the internet is the lack of a unified messaging system.

Before ICQ there was nothing really (IRC was very different and non-practical).

Then MSN and yahoo etc came along, ICQ was bought out and buried. Then, years later, skype came, but it too was on a fragmented market where some had skype, another had msn, etc etc. Now it's the same with viber, whatsapp, skype, fb messenger...

What people need is really an open protocol where clients can work with it, but something that a corporation can't buy out. We don't need a new ICQ or msn where suddenly a company decides to change it or even make it something else (=>skype). If continuity is a goal (=making something that can endure, like email for example), then it must operate as an open protocol.

Perhaps even the email protocol itself can be used to do that. Like an email-on-steroids, in terms of speed, with similar functionality but different ports + encryption. Max message size could be enforced at something like a few kilobytes for speed of delivery, but in order to eliminate the possibility of spam on the network, one would have to "add" another in their "contact list" with something like a key exchange. Someone would be unable to receive email-type IMs from unknown senders - so there would be no incentive by spammers to send messages that will never be received. Every client could then work on top of that protocol.

Another approach would be a meta-messenger. Something that renders irrelevant what your messenger is, just like metacrawler used to make yahoo, altavista, infoseek and lycos as the next best site to visit. Why get 1 result when you can get all of the best results in one site? But a meta messenger would have to somehow bypass the restrictions imposed by each application. There were many meta-messengers in the 2000s, like trilian, pidgin etc, but they usually left behind some large network which made them unfit as universal messengers. And they were also targeted for the more l33t users, so...

---

---

---

---

P.S. For those interested, I wrote a post sort of comparing smooth and myself in response to a question from altcoinUK.

Edit: for those interested in whether smooth and I would ever work together.

Appears that I have successfully argued that Rust has its priorities incorrect on their highly touted memory lifetime feature:

https://users.rust-lang.org/t/rust-as-a-high-level-language/4644/37 (read my several posts in that thread)

I am near to concluding that Rust is not the correct language for me to choose for my project.

Rust's Cargo solves that dilemma:

http://doc.crates.io/guide.html#cargotoml-vs-cargolock

Node.js npm and Ruby's bundler also apparently do something similar:

http://doc.crates.io/faq.html#why-build-cratesio-rather-than-use-github-as-a-registry