@gjhiggins: Do you think the 0.4.1 client is stable enough now to consider it the "stable" release (to not say the "official" one
)? I haven't tested it very thoroughly but for me it seems stabler than 0.3x. But I keep having sync problems, although only on one machine now (on the other one it's doing pretty well).
Long answer (surprise, surprise), I'll respond to your particular comments before waffling on at length about irrelevancies ...
It's difficult to offer informed help with sync issues, I haven't experienced any sync issues with the 0.4.1 client.
AFAICT, under typical network conditions, I'm not seeing anything exceptional in terms of number of orphans. However, in common with many small altcoin networks, Slimcoin’s slim number of nodes renders it much more vulnerable to instability from large and sudden changes in hashrate so I'd be rash if I were to attempt to make predictions about future stability.
CPU demand is directly related to a relatively large number of coins being staked and the (often consequent) large number of stake transactions in the wallet: the more coins staked, the more processing is required. I have successfully reduced Slimcoin's CPU usage to its previous level by raising my reservebalance.
On the topic of a possible release - I have been merging my exploratory git branches into the
prerelease branch and have something to offer the community ...
I recently dallied with
Sprouts, my interest being sparked by their experience of seeing “block too old, contact dev” warnings in the RPC output and the GUI - as Slimcoin has experienced in the past.
This, I discovered while playing around with the Sprouts code, is because it inherited Sunny King’s centralised “sync checkpoint” scheme which relies on the sync checkpoint private key holder to regularly and frequently generate fresh sync checkpoints. If that process ceases, the warnings will inevitably appear. Slimcoin’s original release inherited the same code+problem:
https://github.com/slimcoin/slimcoin/blob/master/src/checkpoints.cpp#L410 // Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex *pindexSync = mapBlockIndex[hashSyncCheckpoint];
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
}
For the 0.4.1 preparatory work, I just nuked it:
https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/checkpoints.cpp#L378 // Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
//FIXME : always too old
return false;
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
}
and left myself a note to find out why it was failing.
Now that I know
why these warnings were appearing, I can safely disable the sync checkpoint test:
https://github.com/slimcoin-project/Slimcoin/commit/e4d69b7f28e6c6325eab93b43e8aea980112ec7d#diff-c33d3ce1a2a004536aaf1b90f6458900R377 /*
https://talk.peercoin.net/t/the-removal-of-checkpointing/2121/18
d5000 writes:
My problem with the actual checkpointing approach is that it adds a
possible attack vector: let's call it the "CheckpointPrivateKey hack attack".
Any malicious individual which hacks the computer of the private key holder
can control the network and double-spend. Even worse, the computer with the
private key must be connected to the Internet to send the checkpoints, so
this key cannot be stored in offline cold storage (except if Sunny has some
kind of brainwallet mechanism).
*/
// Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
/* Disabled due to infeasibility of meeting maintenance requirements
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
*/
return false;
}
I applied the suppression to the Sprouts wallet, they're happy bunnies again.
Which is nice because Slimcoin actually came out well ahead in the deal ...
It transpires that Sprouts was launched a few months after Slimcoin and is one of the rare altcoins that was a genuine fork (i.e. contains the commit history) and buried deep in the full history was a little gem of a commit with the unprepossessing title
“Merge some Bitcoin code as preliminary step to support coin control features” and was commented thus.
New data structures:
-CPubKey
-CKeyID
-CScriptID
-CTxDestination
(cherry picked from commit 4708d16)
These data structures are the basic origin of the genetic difference between ppcoin and peerunity. We can merge upstream PPcoin code into Slimcoin but not Peerunity code. Slimcoin remains a PPcoin clone because it doesn’t have the above-mentioned data structures defined.
The other thing that Sprouts has are some might-be-nice-to-have GUI additions such as support for both signing and verifying messages (Slimcoin 0.4 only has support for signing) and support for creating multisig transactions.
So I had a go at applying the “preliminary step” commit but had to abandon the task because it proved more demanding than I had hoped. However, I
did manage to smuggle in just enough of the new data structures to be able to integrate the GUI improvements into Slimcoin.
Here's a feature parade ...
Drop-down menu contents, reservebalance value included in overview
I changed the relatively lightly-used “Burn coins” GUI component from a tooltab to a dialog box, reducing the demand for mainwindow horizontal space.
Block browser and transaction decoder
Simple RPC-driven blockchain browser and transaction decoder (copy'n'paster the tx id from the tx history listing). I'm investigating the possibility of extending it a tad to show tx type (i.e. identify OP_RETURN inscription txs).
Migrated Burn coins dialog
Standard “Burn coins” dialog, as a dialog.
Inscription dialog
A simplified dialog box for creating OP_RETURN txs. A tx value of 0 identifies the tx as an OP_RETURN tx, as according to the Bitcoin devs’ intentions. Some integration work still to be done, difficult to say how much but see below.
Sign message
Standard bitcoin feature of proving ownership of an address by signing (hashing) a message.
Verify message
Verify that hashing a message with an address matches a given hash.
Create multisig address
Completely untested but it’s ostensibly “just” a GUI presentation of basic client functionality normally accessed via JSON-RPC, so what could possibly go wrong?
Spend multisig transaction
Again untested and again, “just” a GUI presentation of basic client functionality.
“Torrent” listing
Work in progress. Originally a(n apparently non-functioning) component of
Torrentcoin, this GUI listing of “inscribed” torrent entries will scan the blockchain for OP_RETURN txs from address of the default wallet account.
Reserve Balance editing spinbox in options dialog
I've also been experimenting with providing GUI support for editing the
reservebalance value and have made some progress.
To make a decent fist of this turned out to be more complicated than it first seemed. Still working on this but it's basically functional in that - in the absence of an overriding setting either via config file
reservebalance or via command-line option, editing the value in the options dialog works. Until I can work out why the summary display doesn't update, you have to restart the client to see the changed
reservebalancevalue.
Just briefly, back to the commits ...
If we unwind a bit to a slightly more recent commit, we get to
“Relay OP_RETURN data TxOut as standard transaction type” --- which is a
much neater separation of the concerns than the one I distilled for myself previously for enabling OP_RETURN in Slimcoin.
I was able to use this commit to check the OP_RETURN implementation I completed earlier which was apparently producing nonsense:
gettransaction 7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920
{
"amount" : 0.00000000,
"fee" : -0.01000000,
"confirmations" : 0,
"txid" : "7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920",
"time" : 1484194638,
"comment" : "",
"from" : "",
"message" : "",
"to" : "",
"details" : [
{
"account" : "",
"address" : "msQd2xVVsXPEPkaUKegVwd531mXyKSnFax",
"category" : "send",
"amount" : -0.01000000,
"fee" : -0.01000000
},
{
"account" : "",
"address" : "1Wh4bh",
"category" : "send",
"amount" : 0.00000000,
"fee" : -0.01000000
},
{
"account" : "inscription",
"address" : "msQd2xVVsXPEPkaUKegVwd531mXyKSnFax",
"category" : "receive",
"amount" : 0.01000000
}
]
}
and there's some cause for hope in that it may just be an issue with the implementation of
gettransaction rather than some underlying problem because the results from
getrawtransaction make much more sense.
getrawtransaction 7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920 1

{
"hex" : "010000004e0377580121251f2c2af4baeb9369cc57e44ef6c821e3bed8c968fd6719e
8703c3b098c69000000004a493046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5
af6a51871c56b25783cbee60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb68
3f4ae799f882f1d601ffffffff035076f200000000001976a91479dc215797b4b61ec29fe325230 9
fbd96f8d4a5d88ac10270000000000001976a914826eef9b08e72c682285a6a54e5a9ec746e8
fa8388ac00000000000000000a6a08face010060d6870100000000",
"txid" : "7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920",
"version" : 1,
"time" : 1484194638,
"locktime" : 0,
"IsBurnTx" : false,
"vin" : [
{
"txid" : "698c093b3c70e81967fd68c9d8bee321c8f64ee457cc6993ebbaf42a2c1f2521",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5af6a51871c56b25783cb
ee60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb683f4ae799f882f1d601",
"hex" : "493046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5af6a51871c56b25783cbe
e60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb683f4ae799f882f1d601"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 15.89000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 79dc215797b4b61ec29fe3252309fbd96f8d4a5d OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : ["mrdHmBZZazjYsV81xbh1r915EbLzBtApvx"]
}
},
{
"value" : 0.01000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 826eef9b08e72c682285a6a54e5a9ec746e8fa83 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : ["msQd2xVVsXPEPkaUKegVwd531mXyKSnFax"]
}
},
{
"value" : 0.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "OP_RETURN face010060d68701",
"type" : "nulldata"
}
}
]
}
Quite promising really.
Next step is to create and make available testnet-only prerelease Windows and OS X apps and get the testnet up and running (testnet is easy to mine, doesn't use the expensive dcrypt hash).
Cheers
Graham
