Quote from: gjhiggins on May 20, 2017, 05:16:30 PM

I'll commit a fix later this evening.

An anticipated fix has been committed to master.

It compiles for me with Qt 5.8 but that doesn't exercise the problem - however the Travis CI build uses Qt 5.5.1 and the CI build succeeded, so I'm cautiously hopeful. <- written earlier, looks like we now have a fix.

With respect to inscriptions, this is work-in-progress, an ongoing experiment, a step into the dark ...

There's a design flaw in the Inscription GUI in that it sends the tx to the wallet's default address and the listing (atm) is of the inscriptions associated with the address of the default account. I haven't yet fully worked through the implications but even if it could be configured to trawl the blockchain for inscription tx to an arbitrary Slimcoin address, I've already lost touch with which address my inscriptions are tied to. The UI for addresses is pretty naff, there's little to distinguish one random string of base58 chars beginning with S from another.

There's a couple of ways to get a separate, more user-friendly handle on a Slimcoin address. You can either implant semantics into the address by using a customised vanity address as a publishing address or in the passphrase by using a mnemonic-style value.

Slimcoin can import xkcd-style mnemonic passphrases via the importpassphrase facility:

Code:

importpassphrase "collect house buttery stable"
{
"Secret" : "cRm57kUw7B9UKpYheJYAJJA8Apq388ynVfkrL3f8FktfJxN6pLQS",
"Address" : "mwHuDZ7Y7JJnjhGgaaW1xWcpapEf9KcBGq",
"Hash" : "6348f9f61cf9fa984cc36be39bf736011db7e57381484d5b7dad2ba1bf33af7c",
"Phrase" : "collect house buttery stable",
"Length" : 28
}

Try it at home (on testnet), you should get the exact above output from the exact above input - i.e. as deterministic as it gets with Slimcoin.

There is a built-in customised key generator in the RPC command set: makekeypair and it only needed a little tweaking to turn it into a minimalist customised address generator (output linebreaks added by hand):

Code:

makekeypair

{
"private key: " : "3081d30201010420537b8eb800e4676227f4c493f4723b2a5b1139865607624f33b
01b00ce5ea670a08185308182020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffff
ffffffffffffffffffffffffffffefffffc2f300604010004010704210279be667ef9dcbbac55a06295ce8
70b07029bfcdb2dce28d959f2815b16f81798022100fffffffffffffffffffffffffffffffebaaedce6af4
8a03bbfd25e8cd0364141020101a1240322000301e1974220afd7fe09613cbee87dee86c9da7b89cf34e79
e7b946e4bb9b220d7",
"secret (hex): " : "f02300dc1f7f0000c62400dc1f7f0000c62400dc1f7f00000000000000000000",
"secret (base58): " : "VPoEHH5S1iS2ct19wmnitHMdpZqD5zJ7qFgSkZ7SWLoWbFUcoJvc",
"pubkey (hex): " : "02b11385adec2ea3c12bb6d37923bb4282ea55e54ff78e5d7f94988f2719a5b520",
"address (base58): " : "SXxxFHq78iUiDBnFqMABeWt6tTsxMR4QTo"
}

This is quite nice for ad hoc key generation, not so nice for computing customised addresses because all the hashing has to be performed in the confines of a single thread - the one in which the client is running. If you're going to use it for address generation, keep it to 2 (Sx) or 3 (Sxx) characters.

NB, I'm still negative towards using vanity addresses for receiving payments because using them for that purpose introduces a known error, that of (inevitably) mistaking SGHigginsXsomerandomstring for SGJHigginsXotherrandomchars (or near offer). However, customised addresses are intended be used only informally, i.e. to act as publishable inscription addresses.

Suppose I'm publishing a blog via sending inscriptions to my advertised Slimcoin publishing address, with each inscription showing a torrent hash that identifies a specific torrent-published post, e.g https://www.torrentzengine.top/8DD2669BF1FB6B0D6B069A428A719FD43E32CDA9

If you think that the posts linked to by my inscriptions are worth keeping abreast of, then at some point in the future, you'll be able to add my Slimcoin publishing address to the your whitelist of information resources published on the Slimcoin blockchain. It's all metadata ofc, that's all that there's space for in an OP_RETURN (in a sane world, at least). A truly forward-looking organisation would sort itself out a communally-owned torrent publishing resource that club members could use to store the content of their posts rather than having to rely on an informal and unreliable network of personal tit-for-tat reciprocal torrent hosting. Not that the latter approach is either exclusive or infeasible, it just requires more dedication and more work at the individual level before such a service can be used - i.e. it presents a barrier to incomers.

I use my experience of being a member of my local dinghy sailing club (BCYC) to inform me of how a persistent (since the 1930's) informal social group can successfully manage communally-owned resources for the simultaneous benefit of multiple stakeholders with disparate interests that sometimes conflict.

Aaaanyway, back to the plot. So, I dusted down Spreadcoin's old vanity address generator tab (which usefully uses the same pubkey and privkey prefixes, 63, i.e. S and 63+128 respectively) and, in a separate (not yet committed) branch, added it to Slimcoin.

It works pretty much as advertised and it's less cryptically minimalist in that it helpfully lets you know which of the base58 characters are permissible to use in your customised address and it performs the hash work in a different thread (or three or four or whatever). And it does have extra whistles and bells. And it generates customised addresses.

Unfortunately, importing the reported privkey for the generated address SMYCUSTOMISATIONblahblahblah results in an entirely different address showing in the wallet. Ho hum, more work required. Stay tuned.

Cheers

Graham