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

Are there any blockchain to download?
WTB slimcoin..
price PM thx.

You’re a leetle ahead of the game, I hadn't actually gotten round yet to updating the makefiles for the headless client.

Two object files were missing from the list and the -std=gnu++11 CXXFLAG wasn’t set.

The latest commit should allow a successful compilation of the slimcoind headless client and the test_slimcoin binary (it does for me on 16.04 at any rate).

As soon as I’ve figured out how to generate compressed & uncompressed pubkeys, I can make the correct value bindings in the test suite and then I can move on to sorting out the Travis CI config.

Cheers

Graham

I  cant build "master"


and a lot of "no known conversion"

Used make -f makefile.unix

The mist begins to dissipate ...


Cheers

Graham

https://github.com/slimcoin-project/Slimcoin/commits/master



peercoin original test bindings:


Note: strSecret?C values have an extra char.

TIL TWIWMBLA (*) “compressed keys” ...

https://bitcointalksearch.org/topic/how-to-determine-a-wifprefix-and-compressedwifprefix-for-a-paper-wallet-eg-1046919

Cheers

Graham

(*)  TWIWMBLA = “This week I will be mainly learning about ...” (https://www.youtube.com/watch?v=SWr0E_Qb39A)

any news?

Kudoz to that, much appreciated!

Okay, thanks. I'll run it up on a VM.

Cheers

Graham

Ubuntu 14.04 and 16.10. Same error

Master i compile without problem including qt

This approach seems to have paid off. I've been able to replace the half-assed partial bridge code that I smuggled in with (more trustworthy) commits that I cherry-picked from the PPC development stream --- to the extent I have been able to successfully merge the latest PPcoin master branch.

The “stealth transactions” addition has been put on hold, it won't compile when merged with the new Slimcoin code because of an organisational infelicity:


The source code is both syntactically and semantically correct, the compilation error points to a problem with the organisation of the codebase.

So I decided “first things, first”: I've merged all the existing prerelease code into the master branch and have now turned my attention to the ensuring that the test suite fixtures are adjusted to use Slimcoin addresses, etc. and that the tests pass.

Ultimately, I'll update the Travis CI configuration file and then we should be able to return to the reassuring position where Travis CI triggers on each new Slimcoin GH commit: automatically cloning the repos, compiling the code and running the test suite.

When that's complete (and both Windows/MacOX binaries generated) I will cut a release, assuming we don't hit any snags on the way.


Cheers

Graham

Noted.

What OS are you using for the build?

Cheers

Graham

I transcribed Peter Bushnell’s “Stealth addresses” branch of Deepcoin into a Slimcoin “feature.stealthaddress” branch.

As one might expect with such a speculative venture, the added code didn't all work. I could create stealth addresses but not send money to them because of an inbuilt sanity check in the “send coins” code which checks that the destination address length == 20 chars (stealth addresses are at least twice that length). So, nearly, but no cigar.

I've been shepherding my ducks into a line, tidying things up in preparation for a release and, whilst reviewing the commit history, saw that the PPCoin codebase had seen various commits after the date of the “common commit” between the PPCoin and Slimcoin codebase that I exploited to bring Slimcoin up to PPCoin 0.4

In both instances, you need to scroll down to the commit labelled “Fix calculation of account balance.” (the common point).

In the PPcoin repos, there's a series of later commits, some with opaque labels which mask their significance but broadly, everything up to the top of that page is relevant to Slimcoin and I spent yesterday evening working my way through the sequence, fixing conflicts from cherrypicking the commits i.e. apply just the selected commit and ensuring that the result compiles (instead of the simpler but cruder approach of merging all the commits in one indigestible chunk).

In the process of managing the conflicts introduced, I noticed that the “address.length == 20” sanity check was replaced by a check which (presumably) will accept stealth addresses (represented as OP_RETURN data) of a length > 20 chars. So, if it all works out, I should be able to successfully add stealth address support to Slimcoin.

Also, some of the GUI additions will become more robust as they typically assume that the codebase support the abstractions introduced in the “Merge some Bitcoin code as preliminary step to support coin control features” commit

New data structures:
-CPubKey
-CKeyID
-CScriptID
-CTxDestination
(cherry picked from commit 4708d16)

And it's these new data structures that I reported previously that I managed to “smuggle in” to allow the GUI code to function, e.g. in the Deepcoin stealth address code:

https://github.com/Deepcoinbiz/Deepcoin/commit/51221031e8aa4ec0b9bd25bab1508a7a71df2fd9#diff-c04bd6830c6c2f5dac54b1559805f906R482

std::map<CTxDestination, std::string>::iterator mi = wallet->mapAddressBook.find(address_parsed.Get());

It remains to be seen whether these later PPcoin commits actually support the integration of coincontrol (not achieved yet in PPcoin, I believe) but we do have an existing model in the Sprouts codebase: (scroll down to “Fix calculation of account balance” as before, subsequent commits should be cherry-pickable).

The coincontrol additions are in the commit labelled Merge pull request #1 from sproutcoin/coincontrol (list of commits, scroll down to the label). There are a lot of changes and it's very definitely speculative work but it just might provide an opportunity to re-seat the Slimcoin code in a much more recent codebase, so I reckon it's worth a go.

On a tangent, I have mischievously selected some contents of https://github.com/smith7800/ for your delectation ...


I think it is entertainingly suggestive that the original dev is still active but has no active interest in Slimcoin. And, if true, would seem to put the kibosh on any speculation that the original dev was someone notable in the crypto[graphy|currency] scene.

Cheers

Graham

do the best expect the worst and do not lose your cheerfulness at any cost in the game of life.

You'd be surprised about their egalitarian approach. Their customer management head is a female. But enough with the prayers, the project is still in its very early stages, as promising as it looks.

The debugging of OP_RETURN looks a bit tiring. The data written is properly encoded/decoded? Just asking...

As for what it should be used for, well, the sky is the limit. I can think of many uses, from vertical knowledge databseses, Quora or Stackoverflow-like, but server-less, up to alternative publishing territories for specific groups.

Very interesting. Looks like the first option is a bit "expensive". The second one, though, looks promising. And sending the "extended public key" in an OP_RETURN transaction, encrypted, could only add to the layer of protection. Sounds like an interesting direction.

I could not compile "prerelease"

/usr/include/c++/6/array:90:12: note:                 template struct std::array
     struct array
            ^~~~~
makefile.unix:134: recipe for target 'obj/net.o' failed
make: *** [obj/net.o] Error 1

OP_RETURN is the key:

https://bitcoinmagazine.com/articles/stealth-transactions-and-reusable-payment-codes-how-bitcoin-addresses-can-be-hidden-in-plain-sight-1467743772/

Cheers

Graham

Thanks for the feedback, that is most useful. I'll attend to master and ensure that it compiles (temporarily ignoring the auto_ptr deprecations) and (all but two of) the tests succeed (below is a description of how to compile and run the tests)
.


I found it just a little too tedious to keep all the branches merged with master and frankly, once ported, there isn't much to do other than add tests, so I merged the lot into prerelease and will then merge that with master to create a release (which, on Github, opens the opportunity to provide OSX/Win binaries downloadable from the GH repos “Releases” tab. That's the overall plan at any rate.


Thanks for drawing my attention to AKASHA. I did see it and I passed it by - I'm being brutalist; any social-networking-oriented effort that is insensible to the implications of a 99.9999:0.0001 m/f ratio can safely be ignored as doomed to fail. (see Simon Baron-Cohen’s work on the “Extreme Male Brain” and note carefully that this a spectrum [1, 2])


OP_RETURN debugging continues - I'm beginning to suspect that (at least part of) the problem lies in what I've coded to be written as OP_RETURN data rather than what's being read but neverthess, OP_RETURN txs are being correctly recognised by the code:





The (lifted from Torrentcoin) code correctly reads the OP_RETURN data and (incorrectly in our case) splits the data by space characters and assigns the (expected) third chunk (the split is 0-indexed) to be processed.

It's not getting what it expects and there's no clue in the Torrentcoin code as to what was written originally as OP_RETURN data (I can only assume there was a separate RPC script that did the heavy lifting) so I'm obliged to use the C++ code to build an understanding of what the code expects to see - and then decide whether that's actually suitable for Slimcoin's particular use of OP_RETURN.

There is an overall direction to the work I'm doing on the Slimcoin code. The codebase is now (reasonably? arguably?) stable - but what are we going to do with it?

So, I'm looking at “Server-less & domain-less websites updatable via torrents and bitcoin blockchain.” https://github.com/elendirx/web2web/

I've already got this running (on a 0.13.X Core codebase) using the Qt5 WebEngineWidget. The disadvantage is that QWebEngineWidget uses the Chromium JS engine and (so) there is no MXE cross-compilation path to Windows. I'm given to understand that native compilation on Windows is feasible using a recent version of VS but I'm not really in a position to go down that route, so it's tentative at best. However, it's a pure soft fork, uses the standard OP_RETURN tx feature and doesn't need anything out of the ordinary, so QWebEngine-capable Linux and OS X “publish-by-torrent” Slimcoin clients can happily co-exist with vanilla WIndow clients

[1] https://iancommunity.org/cs/understanding_research/extreme_male_brain
[2] https://en.wikipedia.org/wiki/Empathizing–systemizing_theory

“Here comes the science ...”



It's a spectrum which prompts me to think objectively about the implications for altcoin communities which are, in practical terms, all-male groups.

Cheers

Graham

Great update and thanks a lot for your work!

As I saw a bit of activity on the repository I played with a few of the branches during the last few days.

The master branch didn't compile, but the feature.publishing did. Oh, all the compiling was on a linux box. This version: "SLMv0.4.1-alpha-62-g97dfe67-dirty-alpha" stopped at block 58389 and wouldn't pick up from there. Zero connections as well.

Just a word about the OP_RETURN features. Did you hear about AKASHA (http://akasha.world)? It's not a coin (well, not yet) but more like a decentralized social network. Like really decentralized, there is no server on which the data resides. The app is a collection of smart contracts on top of Ethereum and they use IPFS for storage. I tested it from the early alpha implementation and at least they GUI is very nice. Still slow but very promising. This project may go in the direction of that "collective intelligence" you talked about in some of your previous posts.

As for Slimcoin, still a huge fan and looking forward to the OSX release. Right now I'm moving all the Slimcoins from the linux machines (including the raspberry PI) to the OSX version, in which I enabled staking. So mining and burning is done on Linux and staking only on the visual client.

Again, many thanks for your contribution, it's highly appreciated!

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


For the 0.4.1 preparatory work, I just nuked it:

https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/checkpoints.cpp#L378


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


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.

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