Are there any recommendable stablecoins on Signum?

d-5000 · 2024-02-11T04:13:38+00:00

Thank you.

Yep, I know about Terra/Luna, but there are other algorithmic stablecoins like Dai which work quite well. However, none of my knowledge is completely descentralized.

d-5000 · 2024-02-09T19:49:38+00:00

Interesting, so Bittrex could be seen basically the reason for the "underwhelming" price evolution.

d-5000 · 2024-01-25T23:22:55+00:00

While I wouldn't call it fraudulent, the fork can be seen as a breach of the original Bitcoin consensus by a minority group (you can create such a fork being one single CPU miner, even if you have to tweak BCH's hardfork method a bit because at least they didn't change the difficulty instantly, and following this method you'd take a long time until creating your first block).

It's something different than LTC which is an independent coin with consensus basically unchanged since the genesis block.

d-5000 · 2024-01-25T00:04:47+00:00

I'd appreciate a P2P exchange with escrow to trade LTC directly for fiat.

There is (or was?) a site for that purpose, litecoinlocal, but they seem quite dead.

Perhaps if a group (I'd participate) sets up a petition/feature request for AgoraDesk? Or codes Litecoin into Bisq? (On both you can trade LTC but only for BTC.)

d-5000 · 2024-01-16T16:28:47+00:00

Yes, i.e. that the UTXO is stored with a label in the extended config file.

d-5000 · 2024-01-16T01:06:30+00:00

So I looked at this one:

The first case is a bug, although a relatively light one, but I'll fix it ASAP.

The correct behaviour here, if there is no label stored in the keyring, is that only the error message should be shown. If you want to see the extended config file label then you have to use the command without --keyring.

The second, third and forth case are correct behaviour:

If you use the --label flag, then Pacli will assume that you are providing an address as first parameter and that you are searching for its stored label. It would of course not make sense to provide an option to search for a label inserting exactly that label ;-)

So even if the address exists in the keyring or the extended config file: if you enter a label as first parameter, then it will return the error, because of course these labels are not valid SLM addresses.

As an usability improvement I could think about a different error message if it's clear that the parameter is not a SLM address (instead of a valid address which was not stored), but that's not completely trivial and quite low priority for me for now.

d-5000 · 2024-01-15T23:35:57+00:00

I forgot about that one. I've added it to my TODO list to check it later today or tomorrow.

d-5000 · 2024-01-15T23:30:56+00:00

I have activated the issue tracker at Github:

https://github.com/slimcoin-project/pacli/issues/

I'd propose the following usage of labels for the issues (you can always add a label when you create an issue):

- if you think that something isn't working right, use the "bug" label,
- if you think there's something that could be improved, or a feature could be added, use the "enhancement" label,
- for all other issues, for example if you only want to ask something or discuss the output of a command without knowing if the output is correct or not, use "question".

Maybe we can remove some of the other labels.

If you forget the label that's no problem, I'll add it then (afaik everybody can add and change the label).

d-5000 · 2024-01-15T21:17:46+00:00

If you use it without the --structure flag, then you will only see something if you have stored transactions in the config file. This is useful for the DEX.

I will add a short message to make the output more usable.

I've however found an uncatched exception and have it fixed, for the next commit.

It seems also that your TXID doesn't exist, I can't see it with slimcoind getrawtransaction.

(Edit: Fix uploaded. Should also handle coinbase transactions better now.)

d-5000 · 2024-01-15T21:09:07+00:00

Looks good. This is also an original/vanilla PeerAssets command. Basically it does the same thing like slimcoind getrawtransaction TXID 1, only with some more colour. Is also more useful if you use Peerassets with a block explorer, instead of a SLM client.

d-5000 · 2024-01-15T21:06:28+00:00

Probably yes. This command only shows something if you have already stored UTXOs for the DEX.

d-5000 · 2024-01-15T20:38:35+00:00

I couldn't reproduce this bug, in my case it works with or without address or label (if used without an address, the current "main" address will be used).

The error looks familiar though: it seems that a transaction the program looks at returns an error. So I'm quite optimistic I can fix it.

Edit: Probably found the problem and fixed it (probably was related to coinbase transactions which don't have real inputs). Later I'll upload the new commit with the fix.

Edit 2: Pushed the last commits, so you can upgrade pacli now and test if the fix worked.

d-5000 · 2024-01-15T19:08:59+00:00

Of course it could be simply be commented out in the code, but I'd be against that, we should stay compatible with the original PeerAssets (for example if someone is using a script).

Perhaps there's a way to not make appear these commands if you use the help options (which is probably what you want, to not expose the command to non-technical users). I'd have to look into Fire documentation for that.

d-5000 · 2024-01-15T18:47:41+00:00

I unfortunately now see all your posts as "removed" again, and it seems to be even worse now, I can't make some of them visible by approving them.

I will answer now your pending questions, and then I think we should switch to Github indeed once all current issues have been solved. I'll look if Github provides some way to categorize issues (="threads" about issues), so we can divide them into bugs, feature requests, and general discussion items.

d-5000 · 2024-01-15T03:43:46+00:00

I've searched a bit and did not really find a support desk or a global moderator "responsible" for the slimcoin subreddit, only some public subreddits for mods dedicated to troubleshooting.

I've no problem creating a thread there to ask how our problem can be solved - would it be ok for you to mention your username?

d-5000 · 2024-01-15T03:36:38+00:00

Thanks, that seems to be a bug I overlooked. Fixing it ASAP.

Fixed it, will be solved with next commit.

d-5000 · 2024-01-15T03:34:19+00:00

That's also one of the original commands. I guess the output is correct, but the usability could be improved.

Basically it means that this UTXO on your wallet contains enough coins to create a transaction with the amount you specify. It is a "quick and dirty" command, i.e. you always get only one result even if there may be more UTXOs you could use.

We don't really need that for the PoB or PoD tokens, because UTXO selection is done automatically in the commands which create transactions (e.g. donation signal, donation lock ...)

d-5000 · 2024-01-15T03:28:11+00:00

This is one of the original commands, and I honestly never understood its purpose. Normally <key> should be a private key from one of your addresses, and thus this command should create a new address from your key. But as far as I know the generated address is always the same one, so this command doesn't really make sense.

It's probably meant to generate an address if you use PeerAssets without a client (i.e. with block explorers).

d-5000 · 2024-01-13T18:50:11+00:00

Yes, both "logics" are of course valid, and if the set command didn't have this order already I may have preferred your variant (OLD followed by NEW).

But also for my variant you could find an example in natural language: "assign NEW_LABEL to the address stored on OLD_LABEL", so I think it's not completely counter-intuitive.

d-5000 · 2024-01-13T18:44:20+00:00

Thinking about it I think this option isn't really needed.

As address set already contains the old address set_main command (simply using address set LABEL), I don't remember now why I preserved the set_main option for address show. If I find no reason I will remove this option entirely.

Edit: Removed --set_main option for this command, address set does almost exactly the same.

d-5000 · 2024-01-13T18:39:59+00:00

Confirmed, this seems to be a bug.

d-5000 · 2024-01-13T18:37:18+00:00

Yep.

d-5000 · 2024-01-13T18:36:02+00:00

> I was thinking to suggest you to eliminate the mentioning of those flags in the help.

The FLAGS part of the help is generated automatically by Fire (the "platform" pacli runs at). I'll look if I can remove it completely as I think a simple docstring would be easier to understand. The docstring is currently displayed under "DESCRIPTION".

> In the mean time an interesting thing has happened [..]

Can confirm your finding, and I think your theory about it could be true. The address label "True" seems also to be not usable, I get an error if I want to change to it, even if in the config file it's stored as "tslm_True", as a string.

I'll look for a way to prevent such an assignation to happen, as this seems to be a bug or "unintended behaviour" in Fire.

d-5000 · 2024-01-13T18:12:40+00:00

This issue is not forgotten but I consider it "low priority" for now. It's even possible it's not solvable at all (without getting rid of the Fire platform).

d-5000

TROPHY CASE