Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 109. (Read 137076 times)

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

“Statement on Maintaining the Hashrate Security of Bitcoin Network” https://bitcointalksearch.org/topic/m.20441842

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

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

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

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.

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.

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

Diff is like in good old times!!!

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.

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?

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:


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.

Thanks

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(this)->prevoutStake.SetNull();
            const_cast(this)->nStakeTime = 0;
            const_cast(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

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

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


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

Cheers

Graham

I'm with d5000:

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.


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

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.

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


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.

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?

So I guess Coinomi would be our only option now.
Or if you know how to get read ACME, by the app and use it to listen and transmit transactions, that would do the trick too? I must studied throughly specification of Slimcoin, it still is a mistery for me.

It uses an extensively modified version  of Abe, for which the trail starts here.

Slimcoin's extended block structure (as described in “Anatomy of the Genesis block”, a new addition to the website-hosted docs, edits, corrections, etc. welcome) impacts Abe profoundly because Abe reads the block data out've the chain, recreates the individual block metadata and tx structures, then stashes the data in a DB.

It is quite nitty-gritty stuff, even had Peter Bushnell hunting for implementation detail.

It's not clear to me yet whether ABE's db structure would need to be changed for this specific usage (but it obviously would have to be changed for Abe to be usable as a block explorer for Slimcoin).

Cheers

Graham