TR Forums

Hey everybody, as you can tell by my post count I've been lurking a long while. I think the forum is still full of mature people and good programmers though, so I thought it would be good to post my question here.

I'm now responsible for aeternity's Go SDK, https://github.com/aeternity/aepp-sdk-go. In case you don't know, aeternity is like Ethereum, but we're trying to do it better.

The question is the classic "ease of use vs technical details" argument, and I want to know from your perspective what makes sense for you, as tech-but-not-blockchain enthusiasts.

One of the things aeternity has is AENS, which is like DNS but for addresses on the aeternity blockchain. We're working on making it feasible as a DNS backup for those cases when the DNS system revokes your name for whatever reason. Currently, the way you submit transactions to the blockchain looks like this:

aecli-go tx name_preclaim (parameters) -> returns a tx_ string
aecli-go account sign tx_ string -> returns a signed tx_ string
aecli-go chain broadcast tx_ string
(wait for the transaction to be included)

To register a name on AENS, you have to do this for a name_preclaim transaction, name_claim, and name_update (to point the name to an address). This can get tedious quickly and obviously there needs to be a simpler way. The reason for the preclaim-claim step is so that name squatters can't listen for a name registration on the network and then register the same name first by paying a higher transaction fee to be mined first.

Some questions:
1. As tech enthusiasts and mature programmers, would you consider a bash script a good way of automating all this? or would a single convenience command in the CLI be better?
2. Should transaction signing and sending be separated from transaction creation? What are some guidelines for making such a decision?
3. At what point would the CLI become an inflexible Fisher-Price toy - too simplistic for any other use than the trivially simple?
4. Would you be able to find AENS useful in any other areas? because we are looking to generalize it.
5. There are also JS, Python CLIs for aeternity - they broadly work the same way, but making my Go CLI more user friendly would mean a major departure. Would this be a problem for usability at all?

I'm not a target user, nor a unix user, but on Windows I'd prefer to have an app to do everything directly, without relying on batch files.

If those 3 commands are usually but not always executed as a single composite operation, I'd also implement the composite operation as a single command. It might allow for better error handling or cleanup. It's also easier for users, like "presets" in audio/video encoders.

5. What would be a usability problem? A difference in feature set?

meerkt wrote:

5. What would be a usability problem? A difference in feature set?

Well right now there is a difference in feature set, as well as differences in subcommand names, where some functionality is etc, because we don't have a testing framework to ensure that all the CLIs adhere to a common standard (I tried writing one, terribly buggy).

Also, because JS, Py and Go CLI flag parsing libraries are different, on one language you can pass a flag anywhere within the command and on the other only after the relevant subcommand. I know.

Thanks for your feedback!

Crayon Shin Chan wrote:

I'm now responsible for aeternity's Go SDK, https://github.com/aeternity/aepp-sdk-go. In case you don't know, aeternity is like Ethereum, but we're trying to do it better.

Most of your post is way over my head, but I would just do what you can to make sure Aeternity mining runs terribly on GPUs.

A difference in feature set can be understandable, but I don't see a reason for the options to have different names or behave differently.

Depending on the target platforms/scenarios, wouldn't it would make sense for the secondary interfaces (JS/Py) to just be frontends/bridges to the main/native program?

meerkt wrote:

A difference in feature set can be understandable, but I don't see a reason for the options to have different names or behave differently.
Depending on the target platforms/scenarios, wouldn't it would make sense for the secondary interfaces (JS/Py) to just be frontends/bridges to the main/native program?

They are basically frontends to the node's HTTP API. Although building those HTTP requests can be a pain for certain transactions.

The Egg wrote:

Most of your post is way over my head, but I would just do what you can to make sure Aeternity mining runs terribly on GPUs.

There is a nvidia only miner, but it does a very bad job of keeping the GPU busy

Crayon Shin Chan wrote:

There is a nvidia only miner, but it does a very bad job of keeping the GPU busy

Well, your proof of work is cuckoo, which is a memory-bound algorithm. It's compute time is minimal (5%? or is it even that?) as a component of total runtime, the rest of it is basically waiting for memory.

Hence, the GPU itself isn't very busy: GPU proper isn't doing much of anything, and you're not really hitting the bandwidth either.

Just waiting.

Glorious wrote:

Crayon Shin Chan wrote:

There is a nvidia only miner, but it does a very bad job of keeping the GPU busy

Well, your proof of work is cuckoo, which is a memory-bound algorithm. It's compute time is minimal (5%? or is it even that?) as a component of total runtime, the rest of it is basically waiting for memory.

Hence, the GPU itself isn't very busy: GPU proper isn't doing much of anything, and you're not really hitting the bandwidth either.
Just waiting.

Hey..hey..hey..hey.....hey. What are you tryin to do here?? We don't need to be helping miners to use GPUs and drive up prices again. The majority of us are gamers here. Leave the code unoptimized.

No go sit in the corner with a dunce cap on.

The Egg wrote:

Glorious wrote:

Crayon Shin Chan wrote:

There is a nvidia only miner, but it does a very bad job of keeping the GPU busy

Well, your proof of work is cuckoo, which is a memory-bound algorithm. It's compute time is minimal (5%? or is it even that?) as a component of total runtime, the rest of it is basically waiting for memory.

Hence, the GPU itself isn't very busy: GPU proper isn't doing much of anything, and you're not really hitting the bandwidth either.
Just waiting.

Hey..hey..hey..hey.....hey. What are you tryin to do here?? We don't need to be helping miners to use GPUs and drive up prices again. The majority of us are gamers here. Leave the code unoptimized.

No go sit in the corner with a dunce cap on.

OK, that made me laugh out loud. And I agree.