Slimcoin | First Proof of Burn currency | Decentralized Web

[johnwhitestar]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

[gavrilo77]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

[johnwhitestar]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

We've been added, but I've discovered it only now 

[gavrilo77]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

We've been added, but I've discovered it only now 

Oh!!! I was checking but did not see. It was very easy to list!!!

[johnwhitestar]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

We've been added, but I've discovered it only now 

Oh!!! I was checking but did not see. It was very easy to list!!!

Yep, and it seems a good place to be listed in.
I asked them to let me know when is the next listing.
I think we need to begin listing SLM on exchanges as it's a kind of advertising as well.
Maybe BlockDex? What do you think?

[gavrilo77]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

We've been added, but I've discovered it only now 

Oh!!! I was checking but did not see. It was very easy to list!!!

Yep, and it seems a good place to be listed in.
I asked them to let me know when is the next listing.
I think we need to begin listing SLM on exchanges as it's a kind of advertising as well.
Maybe BlockDex? What do you think?

Do you have link for contact?

[johnwhitestar]

Can we put SLM on https://c-patex.com/voting-en.php for voting?

I've asked them to list us for voting as the procedure is not described there. Let's hope they'll answer in time for us to vote.

I did the same as well

We've been added, but I've discovered it only now 

Oh!!! I was checking but did not see. It was very easy to list!!!

Yep, and it seems a good place to be listed in.
I asked them to let me know when is the next listing.
I think we need to begin listing SLM on exchanges as it's a kind of advertising as well.
Maybe BlockDex? What do you think?

Do you have link for contact?

Not really, but they are quite responsive on their discord.

[johnwhitestar]

Hello guys,

the domain slimco.in has expired and as consequence it went down.
While I'm waiting for the info about whether we can be able to renew it I've registered another domain www.slimcoin.info and restored the site from the github version we have.
I've noticed the site is not that updated as it should, so I've created the section "the-site" on discord to discuss the necessary changes.
If you are interested to discuss the topic please go there, in order to avoid repeating the discussion in different places. I'll be expressing ideas on what I think should be done. If nobody replies I'll consider the idea accepted, after a while.
Right now I'm waiting for everybody's feedback on the first idea I've expressed.

[johnwhitestar]

I'm beginning to work on our Wiki. So I've created the-wiki channel on Discord.

I think we'll need to discuss and to change some important concepts regarding SLM, so if you are interested in SLM's success or have something to share about it or other currencies, please, come to our Discord channel and participate in discussion.

[johnwhitestar]

There are some developers I'm speaking with right now about helping us with SLM development. What in your opinion would be the most urgent task to accomplish?

[d5000]

There are some developers I'm speaking with right now about helping us with SLM development. What in your opinion would be the most urgent task to accomplish?

There are three relatively easy tasks which could be done now:

1) Test and fix bugs in the editions which add the "importaddress" feature. I have tried it, the command itself seems to work, but it seems to have problems generating blocks on testnet, so there is probably a bug related to mining.

It has not been integrated still in the main Slimcoin tree but it's at gjhiggins' repository:

https://github.com/gjhiggins/Slimcoin/tree/feature.watchonly

2) The hard cap edit is meant to make big PoS stakers less powerful, so they can't generate more than a certain quantity of blocks in a row (in the current iteration, 13 blocks). This would offer some protection against "51% staking attacks".

https://github.com/d5000/slimcoin

Graham had compiled it for Windows:

https://mega.nz/#!3QdwjCBY!3lW_2YjSMi4Ml6tRaOTANo7wd-5hmslwT_QjWrEmpwo

3) Slightly more tricky, but still something where the code is already there, would be to fix the "optimised PoS" branch developed by iguanodon1 and integrate it into the main codebase. The problem with this branch, which has to be fixed before integrating it into the code, is that it generates much more orphan blocks than the normal way, but it improves staking performance significantly.

https://github.com/slimcoin-project/Slimcoin/tree/optimized-pos

Then obviously, if a longer-term involvement is planned, a modernized codebase (port to Peercoin 0.8 as a base) would be the next option. This would, however, be a pretty big task.

[gjhiggins]

1) Test and fix bugs in the editions which add the "importaddress" feature. I have tried it, the command itself seems to work, but it seems to have problems generating blocks on testnet, so there is probably a bug related to mining.

Have you mentioned this before/elsewhere? Is my memory failing me?

Cheers

Graham

[d5000]

1) Test and fix bugs in the editions which add the "importaddress" feature. I have tried it, the command itself seems to work, but it seems to have problems generating blocks on testnet, so there is probably a bug related to mining.

Have you mentioned this before/elsewhere? Is my memory failing me?

No, I had begun to test the feature, but after some days of running it I stumbled on the mining problem. I thought first it was my fault, and wanted to investigate further before complaining potentially about a bug that doesn't exist, but then I had the long discussion about PoD with johnwhitestar and didn't re-take testing for a while. When johnwhitestar asked for urgent changes I remembered it. I should have mentioned it at Discord, simpy forgot it, sorry.

[gjhiggins]

1) Test and fix bugs in the editions which add the "importaddress" feature. I have tried it, the command itself seems to work, but it seems to have problems generating blocks on testnet, so there is probably a bug related to mining.

Have you mentioned this before/elsewhere? Is my memory failing me?

I had begun to test the feature, but after some days of running it I stumbled on the mining problem.

There were no changes made to the mining code. Blocks are being generated but they're not being credited to the wallet, an issue obviously related to the added watchaddress code, possibly the address for the mining key is incorrectly being identified as a watch address.

Cheers

Graham

[d5000]

There were no changes made to the mining code. Blocks are being generated but they're not being credited to the wallet, an issue obviously related to the added watchaddress code, possibly the address for the mining key is incorrectly being identified as a watch address.

That's interesting, thanks for clarification! It's strange, because when I fired up another testnet node with the original (master) code after I closed the watchaddress version, it seems to have generated the blocks normally (i.e. there was not a point at the start where the new blocks "magically appeared", they went coming in relatively slowly.) But maybe I didn't observe "deep enough".

This weekend I'll have a bit of time so I can again fire up your watchaddress version and look at that possible bug, e.g. examing debug.log. I don't think I have the skill to solve it, but I can perhaps contribute to a better bug description.

[gjhiggins]

This weekend I'll have a bit of time so I can again fire up your watchaddress version

Not worth it. I had a choice between bringing the original branch up to the latest code or re-doing the additions using the latest code as a base. I chose the latter course and was wrong. Whilst it did work for me, watched addresses are indistinguishable from owned addresses in the GUI which is unfortunately unacceptable. So, I've had to recourse to the other option, bringing the (more complete) earlier branch up to date. In addition, the earlier branch included caching of watched address values, something that's going to be functionally vital.

Cheers

Graham

[d5000]

So, I've had to recourse to the other option, bringing the (more complete) earlier branch up to date. In addition, the earlier branch included caching of watched address values, something that's going to be functionally vital.

Cool, thank you for that. I've downloaded your new additions but they don't compile on my machine (Debian 11), are your editions ready for testing or should I wait a bit more?

If it helps you, this is the error message:

Code:

src/bitcoinrpc.cpp: In member function ‘bool SSLIOStreamDevice::connect(const string&, const string&)’:
src/bitcoinrpc.cpp:4570:43: error: ‘SSLStream’ {aka ‘class boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp> >’} has no member named ‘get_io_service’
 4570 |         ip::tcp::resolver resolver(stream.get_io_service());
      |                                           ^~~~~~~~~~~~~~
make: *** [Makefile:1681: build/bitcoinrpc.o] Error 1

I guess that's something related to boost-iostreams, I have installed Boost version 1.71 (including -dev). I saw support for Boost 1.70+ was your last commit, so it may be related to that.

[gjhiggins]

So, I've had to recourse to the other option, bringing the (more complete) earlier branch up to date. In addition, the earlier branch included caching of watched address values, something that's going to be functionally vital.

Cool, thank you for that. I've downloaded your new additions but they don't compile on my machine (Debian 11), are your editions ready for testing or should I wait a bit more?

Unfortunately ... I have been reluctantly forced to admit to myself that it's not really feasible to add watchonly address functionality to Slimcoin in a sufficiently robust and reliable enough implementation for DeFi use. The watchonly address functionality in Peercoin is there by virtue of Sunny King's later merge of Bitcoin 0.8.6. It's not a Peercoin-specific addition, it was inherited via that merge which occurred a substantial period of time after the 2014 Slimcoin fork of PPCoin.

It's not that watchonly addresses can't be hacked into Slimcoin after a fashion, the problem is that the functionality would then have been hacked into Slimcoin.

The extended isMine functionality didn't even have a solid test suite until Sep 2017 https://github.com/bitcoin/bitcoin/commit/7a1e873b27b790c965d9927ecd465710dc103136#diff-f70eb687f49d254115fb55bce1c23a1c and by that time, the architecture of the Bitcoin codebase had changed substantially, with the script-handling code having been split off into a separate directory and reorganised into subprocessing components (hence the first change in that diff is to src/script/ismine.cpp).

It's not something I'd want either to guarantee or to provide long-term support for and, from a practical perspective, PeerAssets would have to have a robust, reliable underpinning implementation with solid support.

I guess that's something related to boost-iostreams, I have installed Boost version 1.71 (including -dev). I saw support for Boost 1.70+ was your last commit, so it may be related to that.

Yes, it's a Boost 1.71 thing. I have a fix.

Cheers

Graham

[d5000]

Unfortunately ... I have been reluctantly forced to admit to myself that it's not really feasible to add watchonly address functionality to Slimcoin in a sufficiently robust and reliable enough implementation for DeFi use. [...]

It's not something I'd want either to guarantee or to provide long-term support for and, from a practical perspective, PeerAssets would have to have a robust, reliable underpinning implementation with solid support.

Thanks for your explanations. So I interpret basically you would recommend to first port the modern Bitcoin code (or better, PPC 0.8+) to Slimcoin, and then add the watchonly address functionality and the peerassets-based tokens.

One addition however I want to make: Original PeerAssets did not use importaddress at all, so it's not a totally mandatory feature. However, with importaddress, in my token code the validation process becomes much faster. If you don't use importaddress, if you validate a specific token transaction, you first have to retrieve all transactions of all Peerassets tokens at once via the "listtransactions" RPC command from the client, because the Peercoin (or Slimcoin) client cannot use the P2TH addresses (which mark all transactions belonging to a certain token, or "deck" in PeerAssets terminology) as filters, as they're unspendable (like the burn address) and so they can only be imported as watchonly addresses. This means that the duration of this step of validation depends on the quantity of PeerAsset tokens, and if there are many tokens in usage, it can lead to a serious delay.

Original PeerAssets code circunvents this problem a bit because it includes an interface which instead of the Peercoin client uses a block explorer to "validate" transactions. So there is a fast way to validate transactions. However, for serious DeFi usage I don't think this approach is recommendable, as it makes the whole process dependant on the block explorer's veracity.

I also want to emphasize that my efforts on the PoD tokens will only lead to a prototype. After the prototype is finished, a more skilled developer should look at the code and improve it. So for the current work which is left, a "hacked" version of watchonly addresses into the SLM client would be very useful for me. For the final release of the token system, and for the addition of watchonly addresses into the client, we could wait after the PPC 0.8 port has been done.

[johnwhitestar]

I also want to emphasize that my efforts on the PoD tokens will only lead to a prototype. After the prototype is finished, a more skilled developer should look at the code and improve it.

If so I need to begin looking for a developer because the PoD token is something I want to become reality.
Would you please let me know what are the requirements for the developer you mentioned? And in how much time should I find him?

Another question: is the watchonly addresses functionality already included in PPC0.8+ code or it has to be added after?