Slimcoin | First Proof of Burn currency | Decentralized Web

[dzarmush]

gjhiggins, do you want Slim to be added on other exchanges? Or you'd like to improve it first until v1.0?
If in your opinion it's ready to go to other exchanges should we contact them, gather entry fee and do other necessary stuff?

What would be your preferred list of exchanges? Bittrex is probably great, but what do you think about Cryptopia for example? Do you consider it good for Slim. Or since you think Slim won't be stable enough on Cryptopia it doesn't make sense to contact them? By the way, that problem you mentioned regarding stability on Cryptopia also spread to any other exchange or not?

[d5000]

@dzarmush: If I interpret gjhiggins' posts about that topic right, the "stability" issue is not really about "stability". The problem is that some exchanges try to get extra earnings "staking" via PoS, and that PoS in Slimcoin consumes a lot of resources (CPU/memory) because the hashing algorithm consumes a lot of CPU power (above all, if the wallet is "active" and receives many transactions/inputs).

So that should be solvable - it simply should be clearly communicated to the exchange (at least if it doesn't have a lot of resources) that they should NOT do "proof of stake minting" if they don't want to crash their client.

But there is not really an inmediate "technical" solution or "bugfix" - the only one would be to change the algorithm to something simpler.

(Correct me if wrong.)

Yes and I can even add more in BTC if we have some progress on getting to exchanges. [...]

If someone with reputation the community can trust is ready to hold bounty-bank - I can send SLM or even BTC to them because I don't have much time to monitor all the technical progress (and my English is not so good, sorry!).

I even can try to find some time and make Russian translations for all needed stuff if it can help somehow.

Thanks! For now I leave your bounties as they are in the OP then. If you want me to specify them or change them you can write me a PM (or in this thread, I'm here every week at least). A Russian translation would be awesome.

About the "bounty bank": For now I don't want to hold larger cryptocurrency sums on behalf of other people because I still don't trust my technical skills to secure them on my computer. Although, hm, a paperwallet could be a solution. Will think about it.

[cryptovore]

Is there a way to specify in the slimcoin.conf file the number of cores, so mining will be enabled immediately? I tried generate=4 but it doesn't seem to work.

[gjhiggins]

gjhiggins, do you want Slim to be added on other exchanges? Or you'd like to improve it first until v1.0?
If in your opinion it's ready to go to other exchanges should we contact them, gather entry fee and do other necessary stuff?

I'm with d5000:

From my point of view first a generous time should be used to test the current 0.5 client and its new features.

The codebase has been persistently problematic in the past, even after extended periods of stability.

I did learn a lesson looking over Mr Spread's shoulder during the period he was running tests with Spreadcoin. The first time through seemed a bit muddled and sort of petered out disappointingly. The second time through, he first published a set of objectives for the testing effort and that did the trick. So that's what I'm working on, a set of safety-first exercises and key callisthenics. With a bit of thought it might be distilled into a basic certificate of competence - the tx on the blockchain to stand as testament.

What would be your preferred list of exchanges? Bittrex is probably great, but what do you think about Cryptopia for example? Do you consider it good for Slim. Or since you think Slim won't be stable enough on Cryptopia it doesn't make sense to contact them? By the way, that problem you mentioned regarding stability on Cryptopia also spread to any other exchange or not?

I'm just another contributor to a communal effort aimed at curating the codebase. True, I have spent a lot of time working on the codebase but that's i) because I've been doing it on my tod so the effort was disproportionate but ii) it was sorely needed. Slimcoin seems to have maintained a reasonably stable network thus far but it is mostly comprised of 0.6.3 clients atm, so I can't really afford to be too pretentious about my perceptions of the impact of my contribution, not if I want them based on reality.

I'm with the crypto on this and I view exchanges as pseudonymous nodes in a peer-to-peer network. As commercial enterprises interacting with the blockchain, they may have interestingly different requirements to non-commercial users. Unfortunately, the goatfuck that is altcoin daytrading rather obscures everything. With a very broad brush, you could paint Novaexchange in reasonably favourable colours for i) knowing how to run a Slimcoin node without it crashing all the time and ii) not delisting the coin, despite the miniscule volume of trade.

I've lost track of the original post but someone produced a rather useful characterisation of altcoins, there were three but I can only recall two i) a store of value and ii) a token exchange, e.g. Dash and Dogecoin respectively. The difference is that the users of token exchange coins get their jollies from using the tokens to gain pro-social benefits, the users of store of value get their jollies from using the token to gain fiscal benefits. The result is that the fiat exchange aspects are given much less significance in the token exchange model.

Where does Slimcoin appear to fit in this characterisation?

Cheers

Graham

[gjhiggins]

Is there a way to specify in the slimcoin.conf file the number of cores, so mining will be enabled immediately? I tried generate=4 but it doesn't seem to work.

Good guess but Slimcoin's documentation is a bit erratic here'n'there and this one's an undocumented command-line option:

https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L5451

Code:

nLimitProcessors = GetArg("-genproclimit", -1);

so -genproclimit=4 and -gen=1 it is. Could try setting it in the config file, see if that works.

Cheers

Graham

[gjhiggins]

Attending to correspondence often produces digressions, occasionally some are just about worth a separate post:

Hacking around in ABE and ACME and importaddress has given me an insight that I thought I'd share ...

So, you take a zeroed HD, a freshly-installed OS, d/l Slimcoin, fire up the app, run importprivkey and, hey presto, there are your SLIM. What you don't get is those little notes you made for each previous tx but you do see the tx.

It's not a “wallet” at all, it's a transaction browser, scoped to a set of addresses and using a bit of temporary local storage.

Thinking of it as a tx browser relieves you of the misconception that your coins are safe in your wallet, the wallet merely *reads* the blockchain and holds some pubkey/privkey pairs in woefully transient local store. Give someone your privkeys and next time you open your “wallet” it could be empty.

'snot a wallet - thinking of it as one can lead you badly astray.

Cheers

Graham

[gjhiggins]

Another written-up digression ...

Where I am atm: working on nTotalBurnedCoins is slooooow, main.h is imported all over the place and so everything has to be recompiled, which seems to take forever and basically trashes the edit-compile-debug cycle. I've parked this effort on the back burner until I either get a new Linux box or get round to renting a fast machine in the cloud.

ACME-SLM is rolling along reasonably well. The blocknotify script which updates the Fuseki-hosted RDF graph has a bad habit of silently failing, leaving the RDF lagging until I notice it and run a catchup routine which so far has done the trick. So a little more work there, possibly refactoring to use a messaging system to trigger the graph update rather than calling the update script directly.

I'm currently extending ACME-SLM's features, my intention is to make it a desirable companion to the client that can be replicated as required. I picked up the OHLC history from Novaexchange and am retrofitting a marketcap line on top of the OHLC data.

In process:



This entails patching the RPC API to return the total minted coins and total burned coins for a given block, data that is saved in the database index but inaccessible via RPC.

From description of CBlock
/** Nodes collect new transactions into a block, hash them into a hash tree,
 * and scan through nonce values to make the block's hash satisfy proof-of-work
 * requirements.  When they solve the proof-of-work, they broadcast the block
 * to everyone and the block is added to the block chain.  The first transaction
 * in the block is a special one that creates a new coin owned by the creator
 * of the block.
 *
 * Blocks are appended to blk0001.dat files on disk.  Their location on disk
 * is indexed by CBlockIndex objects in memory.
 */

...

description of CBlockIndex and how to detect an orphaned block
/** The block chain is a tree shaped structure starting with the
 * genesis block at the root, with each block potentially having multiple
 * candidates to be the next block.  pprev and pnext link a path through the
 * main/longest chain.  A blockindex may have multiple pprev pointing back
 * to it, but pnext will only point forward to the longest branch, or will
 * be null if the block is not part of the longest chain.
 */

what actually gets written to the index:

    IMPLEMENT_SERIALIZE
    (
        if (!(nType & SER_GETHASH))
            READWRITE(nVersion);

        READWRITE(hashNext);
        READWRITE(nFile);
        READWRITE(nBlockPos);
        READWRITE(nHeight);
        READWRITE(nMint);
        READWRITE(nMoneySupply);
        READWRITE(nFlags);
        READWRITE(nStakeModifier);
        if (IsProofOfStake())
        {
            READWRITE(prevoutStake);
            READWRITE(nStakeTime);
            READWRITE(hashProofOfStake);
        }
        else if (fRead)
        {
            const_cast<CDiskBlockIndex*>(this)->prevoutStake.SetNull();
            const_cast<CDiskBlockIndex*>(this)->nStakeTime = 0;
            const_cast<CDiskBlockIndex*>(this)->hashProofOfStake = 0;
        }

        // block header
        READWRITE(this->nVersion);
        READWRITE(hashPrev);
        READWRITE(hashMerkleRoot);
        READWRITE(nTime);
        READWRITE(nBits);
        READWRITE(nNonce);

        // PoB
        READWRITE(fProofOfBurn);
        READWRITE(burnHash);
        READWRITE(burnBlkHeight);
        READWRITE(burnCTx);
        READWRITE(burnCTxOut);
        READWRITE(nEffectiveBurnCoins);
        READWRITE(nBurnBits);

        //cached hash of the block
        READWRITE(blockHash);
    )


In there is the nMoneySupply value needed (as the dividend to the corresponding OHLC record's price divisor) and I wrote earlier about adding an accumulating total READWRITE(nTotalBurnedCoins) to the above - and happily, hacking the index to do just that is fairly straightforward and seems to work.

Not *just* to retrofit a market cap but also to expose additional essential information via the API and get a better handle on adapting 3rd-party apps that need to read the Slimcoin blockchain.

I can, and shall, configure ACME to use a back-end store, make a daily call on Novaexchange's API and record the OHLC data for that day as a db entry along with nMoneySupply and nTotalBurnedCoins. 24 hours seems adequate granularity for such a broad-brush presentation.

And after that, it would be quite straightforward to extend the data recording to use coinmarketcap.com's API to pick up marcap data for, say a dozen other coins whose market characteristics are perceived as sufficiently similar to Slimcoin's in some aspect or other to act as an index backdrop, setting Slimcoin market data in a more readily comparable context.

The last task is to embellish the publications listing with the metadata that accompanies the signed graph (that will be) stored in the adjacent Fuseki dataspace:



Cheers

Graham

[cryptovore]

so -genproclimit=4 and -gen=1 it is. Could try setting it in the config file, see if that works.

Cheers

Graham

Thanks

[d5000]

I'm trying to use the inscription feature and get an error:

"Error: The transaction was rejected.  This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."

Is this a known issue? It may be related that I just minted a Proof of Stake block, but I had a lot of reserve balance still (and I see in the wallet that not all inputs were affected by staking).

Slimcoin version is 0.5 (gbb22dd4d).

The relevant part in the debug.log is probably this:

Code:

CommitTransaction:
CTransaction(hash=484fbc73ca, nTime=1501136718, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(17283294f379c7117bf9eb5d90fbc732ec4bf5c9f8b8ba30dfe23491ddfe81da, 1), scriptSig=304502201b5b5cd0cc0391ea)
    CTxOut(nValue=0.01, scriptPubKey=OP_DUP OP_HASH160 adba231af47c873bcdb647f1dfcaf84fd2a6443f OP_EQUALVERIFY OP_CHECKSIG)
    CTxOut(nValue=1499.97, scriptPubKey=OP_DUP OP_HASH160 4a8df7cebbb63515e991247380266dfa920c425c OP_EQUALVERIFY OP_CHECKSIG)
    CTxOut(nValue=0.01, scriptPubKey=OP_RETURN face01006d61676e65743a3f78743d75726e3a627469683a3162333665313831613165613563646637343831626338656634353930366263623532623431393026646e3d736c696d636f696e2e68746d6c)
keypool keep 7
AddToWallet 484fbc73ca  new
WalletUpdateSpent found spent coin 1500.00slm 17283294f379c7117bf9eb5d90fbc732ec4bf5c9f8b8ba30dfe23491ddfe81da
ERROR: CTxMemPool::accept() : nonstandard transaction type
CommitTransaction() : Error: Transaction not valid

Edit: Unfortunately, the problem did not go away when my stake was again added to the balance. I can send normal transactions, but no OP_RETURN transactions.

Edit2: I see that there is only one OP_RETURN transaction in the main blockchain (if I did the query the right way), and it is unconfirmed although it was sent in April. Does that mean that OP_RETURN tx are still non-standard and more people would have to upgrade to 0.5? I'll try the feature now in testnet.

Edit3: OK, tried testnet now - there it worked. So it seems that the OP_RETURN soft fork is still not activated and these transactions still are non-standard on mainnet.

What must be achieved before OP_RETURN is enabled? Must there be a majority of miners and minters support 0.5? The problem is that on Testnet most of the time I land on a fork when I try to mine, and/or the Fuseki server still doesn't know the transaction.

[hannusolo]

Hi, a question here:

I started mining a few weeks back but I haven't been at home for a while now. And I see the network hashrate has increased lately. Last time I checked there was no operating pool. Has it been changed lately? Or any plans about it?

[d5000]

Last time I checked there was no operating pool. Has it been changed lately? Or any plans about it?

There is currently no working pool (as far as I know). But one of the community members is planning to set up one. Stay tuned, in the next weeks very probably there will be news about it.

[gavrilo77]

Diff is like in good old times!!!

[dzarmush]

I also just today thought about updating the whole "bounty" part as it's pretty old ... Thank you for the confirmation of your bounty.

For the other users that have announced a bounty, I'll left this question here for a week or so and then PM the users if they have a Bitcointalk or Reddit account:

To all users: Do you have announced a bounty in 2016 or early 2017 that is mentioned in the OP?
Please confirm it replying to this thread. Thank you again!

Some of the bugs have probably already been solved (or were related to the old Peercoin version of SLM 0.3.2). But things like an Electrum port or a working pool are obviously still very much desired features.

I'd very much like to see Coinmarketcap fixed ) Would gladly donate 10K Slim for that.

[d5000]

I'd very much like to see Coinmarketcap fixed ) Would gladly donate 10K Slim for that.

I've two ideas how that could be done in the short term, without having to touch the code:

1) I write a script that gets the updated balance of the burn address (via a cronjob that does a SPARQL query) every 10 minutes or so from Graham's Fuseki instance, and calculates the "circulating supply" with it. This script would run on a server and then provide an API to Coinmarketcap. So CMC would not have to directly access the Fuseki instance and so it's URL could stay private for now.

@gjhiggins: Would that be acceptable use of your Fuseki instance? If not, there is no problem, because there is a second way ...

2) A script that grabs the Circulating Supply "scraping" the burn address balance from slimcoin.club bchain.info every 10 minutes or so and provides it to CMC in a machine-readable way. - Edited: Unfortunately with Slimcoin.club it doesn't work, as the supply at slimcoin.club is not delivered via HTML But with bchain.info it would work.

[dzarmush]

I'd very much like to see Coinmarketcap fixed ) Would gladly donate 10K Slim for that.

I've two ideas how that could be done in the short term, without having to touch the code:

1) I write a script that gets the updated balance of the burn address (via a cronjob that does a SPARQL query) every 10 minutes or so from Graham's Fuseki instance, and calculates the "circulating supply" with it. This script would run on a server and then provide an API to Coinmarketcap. So CMC would not have to directly access the Fuseki instance and so it's URL could stay private for now.

@gjhiggins: Would that be acceptable use of your Fuseki instance? If not, there is no problem, because there is a second way ...

2) A script that grabs the Circulating Supply "scraping" the burn address balance from slimcoin.club bchain.info every 10 minutes or so and provides it to CMC in a machine-readable way. - Edited: Unfortunately with Slimcoin.club it doesn't work, as the supply at slimcoin.club is not delivered via HTML But with bchain.info it would work.

That would be so cool. I think for a regular person if a coin doesn't have capitalization on CMC it looks broke and abandoned.

[gjhiggins]

I'd very much like to see Coinmarketcap fixed ) Would gladly donate 10K Slim for that.

I've two ideas how that could be done in the short term, without having to touch the code

It's going to be challenging if not impossible to make the implementation as transparent as the client's open sourced C++. Reliance on a single point of failure means that the solution lies outside the protection provided by the network. Changing the code is the only approach that preserves the essential transparency and robustness.

I don't know what gliss considers “trustable”, this is altcoinland after all. Who would trust marketcap figures if everyone was allowed to publish their own via an arbitrary HTTPS service?

There is an existing solution:

wallet.h

   int64 GetBurnTxTotal();


wallet.cpp
int64 CWallet::GetBurnTxTotal()
{
    int blockstogoback = pindexBest->nHeight;
    int64 totalburnedcoins = 0;

    const CBlockIndex* pindexFirst = pindexBest;
    for (int i = 0; pindexFirst && i < blockstogoback; i++) {

        CBlock block;
        block.ReadFromDisk(pindexFirst, true, false);

        BOOST_FOREACH (const CTransaction& tx, block.vtx)
        {
            std::string txmsg;
            CTransaction ctx = tx;
            if ( tx.IsBurnTx() ) {
                totalburnedcoins += tx.GetBurnOutTx().nValue;
            }
        }
        pindexFirst = pindexFirst->pprev;
    }
    return totalburnedcoins;
}

It's straightforward, obvious, runs and works but takes several *minutes* to return on my laptop, hence my approach of appending the data to the block index, i.e. using the index to cache the result of the calculation for each block, just as the originally-authored code does for the effective burned coins and the other burn data that isn't written to the block header.

I refrained from inserting a progress statement because it would only depress people - it would read: “Loading block index ...”, a phrase we are all far too familiar with

Cheers

Graham

[gjhiggins]

“Statement on Maintaining the Hashrate Security of Bitcoin Network” https://bitcointalk.org/index.php?topic=2051288.msg20441842#msg20441842

Characteristics of a Teal organisation (e.g. the peer-to-peer network that is labelled “Bitcoin”):

3. Evolutionary: let the organization adapt and grow, not be driven

...

A holistic and evolutionary approach follows naturally from genuine self-management, i.e. when authority is devolved to the individual. In the absence of centrally-imposed roles, behaving as a whole person is the default and in the absence of centrally-imposed goals, the organisation is free to evolve itself.

What's happening with Bitcoin and Ethereum is entirely natural and should be welcomed as a sign of a healthy ecosystem. Organic systems (those composed of people) are free to evolve and/or scale whereas mechanistic systems are constrained only to scale (ultimately to functional obesity).

I note the concerted efforts by the media to hype this up into a “civil war”, this is a result of the hierarchy's inability to view the world in anything other than a command-and-control framework.

A video on Teal --- presented from an Agile perspective but pertinent nevertheless: https://player.vimeo.com/video/121517508 (and then there's Frederick's own videos: http://www.reinventingorganizations.com/watch--listen--read.html)

Cheers

Graham

[hannusolo]

Last time I checked there was no operating pool. Has it been changed lately? Or any plans about it?

There is currently no working pool (as far as I know). But one of the community members is planning to set up one. Stay tuned, in the next weeks very probably there will be news about it.

Well currently I can mine it with my CPU of my mining rig, it found about 3-4 blocks a day last week, but my notebook's CPU can find a bit more. Now it's ok to solomine, but if the hashrate ramps up a pool will be definietly needed. I will follow the thread from now on

[d5000]

It's going to be challenging if not impossible to make the implementation as transparent as the client's open sourced C++. Reliance on a single point of failure means that the solution lies outside the protection provided by the network. Changing the code is the only approach that preserves the essential transparency and robustness.

I don't know what gliss considers “trustable”, this is altcoinland after all. Who would trust marketcap figures if everyone was allowed to publish their own via an arbitrary HTTPS service?

The problem is that I'm almost sure that services like Coinmarketcap do not run their own altcoin clients (they would have to run about 1000 clients) and so they rely on a single point of failure anyway. If the "total burnt coins" function is included into the code it would be ideal, so I fully support your approach. But anyway we would have to wait until a block explorer exposes the number "to the public" until CMC can use it, but even then the "single point of failure" problem would persist. For example, if ACME goes into "production", in theory the instance that was communicated to Coinmarketcap could be manipulated.

So the single point of failure problem in my opinion should be solved by redundancy, more than one source should be provided to them. This can already be done: My idea, if I continue with the "scraping" approach, is to provide the easily-readable source (my web service), the "source of the source" (bchain.info) and an alternative source (slimcoin.club) they always can check, and to publish the script at Github or a similar repository (I wrote a Python prototype with less than 50 lines of code).

That would be the "short term solution", and later, when ACME is finished and open sourced, then I think it should be hosted by more members of the community, so we have redundancy and a better service. I'm interested to run it if the VPS that runs my Slimcoin client supports it.

[muf18]

Woow. The hashrate and diff is really high now...
Who set up botnet ? Because I can't believe 10x hash rate of just 1-2 weeks ago.