[neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin?

[TPTB_need_war]

I'm starting to have doubts about Rust's by-default emphasis on low-level control of memory allocation lifetimes and scopes:

Someone confirmed it is ad hoc polymorphism, and my reply which is relevant in this thread also:

I am surprised afaics the ad hoc polymorphism is not mentioned any where in the documentation. And the Expression Problem nor the Wikipedia entry on Composition over Inheritance, are also ostensibly not mentioned in the documentation. For me, if considering Rust as potentially a better "high-level" language, the ad hoc polymorphism in a language which does not have Haskell's coinductive type system, seems to be unavailable in any other C/C++ derivative (potentially mainstream) language?

I'm suggesting the documentation maybe could be improved to proactively explain to incoming OOP (aka subclassing) converts, to make an argument for why they typically don't want to be using the anti-pattern of OOP virtual methods, and instead using late binding dispatch at the call site, instead of at the declaration site. In other words, ad hoc polymorphism un-conflates (makes) interface from (orthogonal to) data type, and the binding of the interface to a data type occurs at the function call site, not at the data type, interface, nor function declaration sites. Of course there are some tradeoffs, but the inflexibility of premature binding is removed.

For a mainstream high-level language, I am starting to contemplate if I am wishing Rust's ad hoc polymorphism was available in a strongly type language that had no verbosity GC and didn't basically force on us by default the noisy and complex type system of modeling lifetimes and memory (which apparently even infects generics with the 'a syntax ... I haven't learned that yet though). The lifetimes and memory allocation feels too heavy (a PITA) for a language that most programmers would want to use most of the time. Sometimes you want that control, but always by default? And a mainstream language without first-class (i.e. not a library) async/await is becoming an anathema.

There is an alternative Dust[1], but I can't tell if it supports trait, struct, and impl. It is coded in Javascript and it appears to use a LL(k) tables driven parser.

[1]	http://bilalhusain.github.io/dust/ http://akdubya.github.io/dustjs/#dust

Some unofficial hacks to get Rust to compile to Javascript via LLVM/Emscripten:

https://users.rust-lang.org/t/any-solution-to-write-html5-games-in-rust/4380

The ability to compile to Javascript and moreover to be able to comprehend the Javascript produced (at least for the unoptimized output case) so it could be debugged with Javascript debuggers (e.g. in the browser) would certainly make a language much more accessible. I am thinking Rust's semantics are too heavy to ever achieve the latter. Minimizing required tooling could potentially remove some tsuris.

[1714728144]

1714728144

[1714728144]

1714728144

[1714728144]

1714728144

[1714728144]

1714728144

[TPTB_need_war]

Go language:

Afair, Skycoin is programmed in Go. Here some of my quickly researched findings about Go:

Sharing a private message:

[...]

Btw, Go sucks as a replacement for C++ templates and anyone using that doesn't understand well modern Generics programming language design, which includes Ethereum:

https://en.wikipedia.org/wiki/Go_%28programming_language%29#Notable_users
http://yager.io/programming/go.html
http://jozefg.bitbucket.org/posts/2013-08-23-leaving-go.html

Also the marriage of a GC with what is intended to be a low-level systems programming language seems to be a mismatch:

http://jaredforsyth.com/2014/03/22/rust-vs-go/

[...]

[TPTB_need_war]

The shift to electronic money will be swift and physical currency will experience a waterfall collapse.

Armstrong also disses the idea that gold will go to a very high price ($10,000, or even $64,000, non-hyper-inflated dollars).  I am not sure that I agree with MA on this.  My best guess is that they will run out of physical gold at some point vs. all the paper gold.  I guess we will wait and see.

ORO my man, gold is never coming back as money every again. It is purely a speculation. That is why it will top at $5000 maximum. I understand it is very hard for you to accept this, but the reasons are very obvious. Physical money is a dinosaur in this era where we trade money instantly digitally. Gold is too slow. Fugetaboutit already.

Sorry man. I know you want wealth to not grow wings and fly away, but the Bible tells you that is impossible.

I love to hold gold 1 oz coins in my hand. It isn't a lack of passion for gold on my part. It is just my rationality.

Is this the case in the Philippines? In your estimation how much of the SE Asia transactions nowadays are digital and physical cash?

It is still mostly physical cash (80 - 90%?), but in another 5 - 10 years everyone will have a smartphone. The shift to all digital will be very rapid. The AsianUnion will open everything and poverty will be gone by 2033.

The world is going to change so fast...

I wouldn't be so sure, changing habits is not easy, it's not about giving everyone a smartphone. Large groups of the population can't and will not want to shift to all digital, physical money will have a significant share of transactions in the foreseeable future.

You don't realize how difficult it is here to get change for 500 pesos ($11).

You don't realize how young filipinos hate to carry around these heavy metal coins in their stylish no pockets clothes.

You don't realize that the Philippines was the SMS capital of the world before Twitter arrived.

Sorry you are don't realize that there are more filipinos under age 25 than over it.

The youth spend much of their time online here. The change is already underway.

[TPTB_need_war]

[...]

This dilemma of needing to place the modules of your project all in the same Git repository needs to be replaced with a good package manager which knows how to build from specific changesets in orthogonal repositories, where the relevant changeset hashes from the referenced module are accumulated in this referencing module so that merging DVCS remains sane. In other words, the package manager (module system) needs to be DVCS aware.

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

[TPTB_need_war]

well fuck i wrote a long winded butle and hit back so now its all erased. i take back what i say about you being an idiot, but you are still a spectator, whether its your health to blame or something else.

what im trying to say is that, and writing 7500+ posts and spending all day long here is unhealthy. go outside and do something, learn to play music, or go to the park and interact with people in meatspace. you are priding yourself in what can only be considered unhealthy behavior, im am also guilty of ODing on shiny backlights 4am night after night, from time to time, so i recognize your behavior, you seriously need to get out of the house.

Your posts are almost rational, except your assumption that my posts don't include incredibly valuable technical work that applies to my coding, is where you lose the plot.

I use the forum as a place to share my technical work ongoing. As well I do my economic theory development, which is also essential to my coding work.

You don't seem comprehend the value of my forum posts. Thus to you, it appears to be a speculator. To me, I am designing the crypto currency future technology in my posts. Do you need an example?

sure i could use an example, maybe it got lost in your other 7500 posts

How many do you want?

Hopefully you know that TierNolan is respected by the Bitcoin core devs and you can review the following thread where I explained to him and jl777 the only correct way to do decentralized exchange:

https://bitcointalk.org/index.php?topic=1364951.msg14078549#msg14078549

I solved one of the most important technical design issue that exists in crypto currency.

Just let me know how many examples you need, but I think that one is already blockbluster enough to demand your apology.

Now can I stop posting here and get back to my work?

[TPTB_need_war]

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.

[TPTB_need_war]

IMHO you made a mistake to not working with the Gadgetcoin developers. Are they as knowledgeable and articulated as you are? No, they aren't, but they are hard working developers. They have completed their project which will be bigger than Bitcoin is. Even if you are not keen on IoT, the IoT aspect of their solution took them to many top 100 companies. That gives them credibility to make other features (token, social media, communication features) popular. The social media aspect of their project is inline with your social media ambition. You need to compromise on toolset, people, environment, etc. to get somewhere. If you are chasing the perfect environment you will get nowhere. You still have 15 years until retirement, use that time wisely!

My career has not been about working with large companies. My career has always been about producing applications that consumers use. Thus I think I should stay focused where my talent has been already demonstrated. And yeah, after thinking about it, I am not interested in IoT. No passion for me whatsoever on that. Passion is very important to succeeding on a project. I am very passionate about JAMBOX. I think I can change the world with it possibly.

I am always looking for talented developers to work with, but another factor is that too many cooks can spoil the effort especially when there is stock or a crowdfund to divvy up. My goal right now is to find one other developer who is as talented or more so than me and this should come after the crowdfunding if that raises enough money to pay a top salary.

And my other goal is to open source much of the work, so I can work with many developers in the open source model.

I don't know if I can achieve this. We will see...

Note smooth appears to be a very talented developer, but he is anonymous (even to me). And he has his focus on Aeon/Monero. And he apparently hails from FinTech which is a quite different field from the consumer apps markets I want to address and where my past talent is. Also I never wanted to involve smooth in something that could fail, because he has already a community that he enjoys and that depends on him. And smooth is incredibly expensive to hire. Of course I don't even mention other Monero devs and Bitcoin core devs, as they are of course busy on their projects.

Also frankly, unless there is an exceptional candidate that convinces me otherwise, I prefer a USA co-developer if possible on JAMBOX. For the open source collaboration, no such strong preference of course. But for whom I need to share the money with and need to work very closely with, I think the cultural differences mean I would likely be most compatible with a developer from the USA.

So for now, I don't know who will be my key co-developer. Hopefully he/she will come to me at the right time. I need to demonstrate more code and momentum first.

[TPTB_need_war]

...the graveyard of crypto currency projects. However, please note the 10% chance is about 100% more than 99% of crypto projects (i.e. all BTC/LTC clones, NXT, IOTA, etc. ) have. You know better than anyone, nobody really cares about crypto currencies except this scam driven microcosmos, therefore the majority of these currencies are a dead end proposition.

I hope you understand why then my first priority is not on creating a crypto-currency (CC). Although my current software project JAMBOX does have the potential to incorporate a CC and I do have a design for a CC that I think will fix all the problems with the existing PoW designs, it is not my initial focus. I won't be working on the CC again for many months if not perhaps even until next year.

I feel more confident about my ability to stick my fingers in many pies and hopefully get stuck in one that finds a good market and is technically interesting. And that is one of the reasons I am looking at programming languages now.

I am not going to pigeon-hole myself in one corner of the Internet.

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.

[TPTB_need_war]

Regarding the future of Bitcoin and its Tragedy of the Commons economic design:

At best one would see the type of cartel that TPTB_need_war  has suggested; however my take is that this kind of cartel would only last for a short time before collapsing. Just witness what is currently happening in the crude oil market.

Cartels form in power vacuums. They must align with the greater power vacuums in order to sustain their market inefficiency (top-down control can't anneal maximum fitness). So the only way such a cartel would not fail, would be to become a fiat of the world government and be sustained by the Iron Law on Political Economics which is the perennial, inimitable power vacuum.

the only question that matters: block size!

No the only longer-term question that matters is the minimum transaction fee, since that determines the block size. Note that while transaction fees are much less than coinbase rewards, then miners might include any transaction without even a fee for Nash equilibrium reasons.

The solution to the block size problem has nothing to do with controlling the size of the blocks. It requires a different design where transaction fees trend near to costs but not to costs, thus not making the nodes of the system bankrupt.

This brings us back to the Cryptonote adaptive blocksize limit combined with a tail emission found in Monero where:
1) The cost of mining a block is set by the block subsidy

Correct, meaning the amount of hashrate miners spend will be equal to the block subsidy[1] (where block subsidy will ultimately be Monero's perpetual tail reward which is necessarily a fixed # of coins), because (as I pointed out in our prior discussion) transaction fees will trend to costs, due to that the median block size M_N will trend upwards to match market demand and thus there is no pricing power on transaction fees.

[1] Note this means the tail reward security of Monero will be very weak and insufficient.

2) The total amount in fees per block has to rise to a number comparable to, but most of the time smaller, than the block subsidy.

You wrote that before in our prior discussion:

The reason the above two scenarios do not apply to a Cryptonote coin with a tail emission such a Monero becomes apparent when one considers the economics of the total block reward components of fees and base reward (new coin emission). If the total in fees per block significantly exceed the base reward then it becomes economically attractive for miners to burn coins to the penalty by mining larger blocks. The block size rises until the total fees per block fall below a level where it is uneconomic for the miners to pay the penalty by increasing the blocksize. This level is comparable to the base reward. It is at this point where the need for a tail emission becomes clear, since without the tail emission the total block reward (fee plus base reward) would go to zero.

And it still doesn't make any sense to me. The block size will trend upwards to match transaction demand, because the penalty is driven to 0 as the median block size increases as  miners can justify burning some of the transaction fees to the penalty. That drives the median block size upwards, which drives the penalty to 0 again. The median block size doesn't have any incentive to decrease again, thus transaction fees then fall to costs.

Sorry as I told you before, Monero does not solve the Tragedy of the Commons in Satoshi's design. It does adaptively increase the block size while preventing spam surges.

I doubt John Conner's design has achieved any better, because as I explained at our prior discussion, there is no decentralized solution to that Tragedy of the Commons in the current proof-of-work designs. I have a solution, but it is a very radical change to the proof-of-work design that relies on unprofitable mining by payers.

[AlexGR]

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...

[TPTB_need_war]

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.

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.

What people need is really an open protocol where clients can work with it, but something that a corporation can't buy out.

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.

[Dink]

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.

[TPTB_need_war]

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.

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.

[TPTB_need_war]

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

[AlexGR]

I'll not reply again unless this gets more interesting, it is repetitive now.

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?

[smooth]

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.

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.

[AlexGR]

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.

That is normally how SIMD code is written yes.

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".

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.

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.

[smooth]

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.

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.

[TPTB_need_war]

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.

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.

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.

[TPTB_need_war]

[1] Note this means the tail reward security of Monero will be very weak and insufficient.

"Insufficient" is unclear because there is no unambiguous definition of how much is sufficient.

In large part it depends on the decentralization of mining. If mining is decentralized then you only need a small (but still nonzero) incentive because any miner can't really do anything other than follow the longest chain rule. While raw hash rate attacks are possible (i.e. temporarily centralizing mining by incurring a cost), in a larger system they will have significant cost and will only succeed as long as the ongoing cost is paid.

If mining is highly concentrated by nature then you are really only relying on the weak linear security of the block reward itself, and maybe not even that, because miners (e.g., hypothesized Chinese cartels) have all sorts of perverse incentives.

Your statement would be correct if you added ", assuming mining becomes centralized as I have claimed it will."

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.