I've found that contemporary browsers will no longer execute JS in opened files of HTML (check the JS console in the browser or the browser log for messages to this effect). In order to function, the page needs to be hosted by an HTTP server locally (or, at least for Chromium, a command-line option must explicitly be provided).

The GH page version will work just fine as an app and is as private as any github HTTPS connection (so, vulnerable to MITM conducted by your local sovereign state TLA actor).

Nevertheless, perhaps stealingadapting Ian Coleman’s BIP39 JS solution would be preferable.

Cheers

Graham

It's not a paper wallet generator, despite the appearance of a QR code graphic ...

A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key. - https://en.bitcoin.it/wiki/Deterministic_Wallet

The first feature is your “one ring to bind them all” deal. The magic (seed) phrase “collect house buttery stable” will enable me to recover all of the privkeys generated from this seed (the parent private key or “privkey”) and thereby enable to me to take control of any and all UTXOs associated with those privkeys (which, AIUI, are actually an encoding of the parameters for the selected ECC scheme).

The second feature is important for online sales, allowing a merchant such as myself (they are really cool digital prints) to enable my remote server to create receiving addresses for incoming payments without needing the privkey (which otherwise would be exposed to attack on the server).


Unfortunately (1), that is the one-click solution.

Unfortunately (2), to be effective, one-click solutions require that users already have a reliable mental model that is sufficiently accurate and detailed to adequately inform the choice that they are faced with. Few people would be comfortable with a one-click solution for submitting tax returns that basically translated to: “Here's all my money, take whatever you want”.

Users aren't always in the best position to articulate their interface requirements because they typically don't have access to domain fundamentals such as ...

The levels-of-processing effect, identified by Fergus I. M. Craik and Robert S. Lockhart in 1972, describes memory recall of stimuli as a function of the depth of mental processing. Deeper levels of analysis produce more elaborate, longer-lasting, and stronger memory traces than shallow levels of analysis. Depth of processing falls on a shallow to deep continuum. Shallow processing (e.g., processing based on phonemic and orthographic components) leads to a fragile memory trace that is susceptible to rapid decay. Conversely, deep processing (e.g., semantic processing) results in a more durable memory trace.
- https://en.wikipedia.org/wiki/Levels-of-processing_effect

The above is broadly describable as falling under the remit of “user task analysis” and “user information requirements analysis”- what the task is in terms of cognitive processes and their functioning, what information is known to be required to inform those cognitive process, how that information is best presented to integrate effectively with the cognitive processes, how to account for known effects of perceptual distortions, characteristics and limitations of short-/long-term memory performance and ditto for the limits of attentional performance.

- http://visionlab.harvard.edu/Members/darylfougnie/Daryl_Fougnie_%28Academic%29/Home_files/Fougnie-in%20press-chap%201.pdf

As a cognitive psychologist by discipline, to me this stuff is just basic characteristics of the standard i/o routines known to be reliably present in the typical installation of the “HomSap v1.0” wetware OS and it's just an irrational aberrance of modern life that people are, by and large, comfortably oblivious to the (entirely predictable) limitations of their own particular installation of HomSap 1.0.

Cheers

Graham

Q.E.D.

In case it's of interest to anyone ...

It transpires that the adapted Spreadcoin customised address generator produces uncompressed keys - this explains why the customisation is lost on importing the (uncompressed) privkey.

As evidenced by the addresses shown in the wallet, Slimcoin takes a compressed-key-by-default approach, inherited from PPCoin.

This was the original output from makekeypair before I adjusted it (prematurely, it would seem) to remove the uncompressed part:

  * secret (hex): f092e90100000000c693e90100000000c693e901000000000000000000000000
  * : uncompressed
    * secret (base58): 7S78qD9aBwpiCNCZsx9BmMKtsLY58p2zWKftnSPJkyV1SQULjGz
    * pubkey (hex): 0480d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be4b13b00a4853b bf4cd00a1b1812cd401da8386405613a4927110e1db4cf21f19
    * address (base58): SkM4auwYLe4R59zkXFnVJ3tCzCkZGms9cu
  * : compressed
    * secret (base58): VPp5ZncqVJyaqAa47tP8WkiPwBE9FUbnpRQfZZ3TP6Jcvtmy6WWR
    * pubkey (hex): 0380d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be
    * address (base58): Siy45aBFsMzqtDEik4taLgDucHm5Tf1BdR


The difference between compressed and uncompressed being:

Anyway, in the course of getting to the nitty-gritty of the compressed/uncompressed issue, I forked bip32.org’s javascript-hosted Hierarchical Deterministic Key Generator, configured it to use an extended public/private keypair of my own invention that I considered appropriate for Slimcoin  - spub (0xef6adf10) and sprv (0xef69ea80), committed the changes and configured the github pages rendering.

It's a standalone web page which can be hosted locally, disconnected from the net, for extra peace of mind.

Cheers

Graham

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:


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):


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

Move your wallet safely out of your datadir then delete the contents of that folder. Resynch from scratch, wait until synced, stop client. Copy old wallet back into datadir, restart client.

No, it's not specific to Slimcoin, here's a not-too-dissimilar report from Sterlingcoin:


You can disable staking in Slimcoin by setting reservebalance=0 in your slimcoin.conf file or as a command line option.

At present you cannot disable mint-by-proof-of-burn in Slimcoin which in all probability is having the same effect on syncing as does enabling mint-by-proof-of-stake, i.e. causing the client to generate a unique-to-it stake/burn block in mid-synch which then results in the client starting its own private fork and failing to sync further, so ...

Move your wallet safely out of your datadir then delete the contents if the folder. Resynch from scratch, wait until synced, stop client. Copy old wallet back into datadir, restart client.

Good luck in your mission Jim, should you choose to accept it.

Cheers

Graham

P.S. Yes, it would be useful if Slimcoin had a nice, fresh convenient bootstrap.dat for people to download. I have added a dumpbootstrap routine that I filched from CLAM:

https://github.com/slimcoin-project/Slimcoin/commit/c7adc1f652f7f8831c6373da48b68b77765a7b82

(I was quite pleased with myself until I discovered that the Windows client, rather predictably and somewhat infuriatingly, just ignores the generated bootstrap.dat file. Ho hum, more work to do.)

That crossed my mind as a fleeting thought, I should have paid it heed, thank you.


Cheers

Graham

ditto from hetzner.de:


Cheers

Graham

Ah, mea culpa. I should have realised the need for a backward-compatible solution. I'll commit a fix later this evening.

Cheers

Graham

I advised a new poster to leaven their enthusiasm with reality, equating that to dismissal is induced hyperbole of entirely your own invention. I'll leave you to it.


Cheers

Graham

Yes.


They will come to whatever wallet is online and contains the address which made the burn tx that “won” the burn hash for which the coins are being received.


Only the address. Wallets are as ephemeral as mayflies, only the blockchain endures. Every unspent TXO is associated with an address. To reassign the unspent TXO to a different address (i.e. spend the coins), the appropriate privkey for the TXO's currently-associated address needs to be provided to the scripting engine so that the necessary matching hash can be computed and checked.

Mint-by-proof-of-burn coins go to the address of the “winning” burn tx:


Over the total period of their expiry, burned coins will generally figure in the PoB calculations for about a year.


Yes. The client must be contributing hash to the network in order to earn rewards. The greater the number of coins staked, the greater the amount of hash required as contribution. The fewer the contributing clients, the more work the remaining contributing clients have to do in order to provide the requisite amount of total hash power designed to maintain the integrity of the public ledger.

And *that’s* why my client is permanently nailed at 100% of its allocated thread, it's completely consumed with calculating the overall staking weight - that’s how reservebalance works, by cutting down the search space and thereby reducing the computational demand. My wallet reports over 3500 transactions in total, no wonder the GUI client is unacceptably sluggish in responding to user input. The vast majority of those txs were received by one address from which a few significant, unexpired burn txs have been made.

Creating a new wallet and importing the privkey for that address also imports the 3000+ tx history and - without a reservebalance that basically equates to “staking=no” - again the client process immediately consumes 100% of its allocated thread as it disappears into endlessly calculating the new stake weight, in order to earn more coins which arrive as transactions which then must be taken into account in the calculation of the new stake weight, in order to earn more coins ...

As the number of nodes decreases, the [number of coins received by|hash load on] the remaining clients increases.

It’s beginning to look like the network was configured around an assumption that people would overwhelmingly prefer burn hashing, not stake hashing. My GUI client is already consuming 33% of its allocated thread and there are only 250 tx in total and a balance of 1400 SLM. I set reservebalance to 0 in order to check what kind of tx rate I’d see and that turns out to be at least a dozen tx a day (i.e. 8 staking tx thus far today and two orphaned stakings). Just to confirm, I shut down the GUI client and fired up the headless daemon - which also consumed 33% of the thread, so the elevated CPU use is not explained by some infelicity introduced into the GUI.

With a continual stream of incoming tx, that 30% will simply increase until the total thread compute capacity is reached and then the engine will start to fall behind. It's an issue for some PoS coins - Sprouts (a PPCoin clone with a codebase not too dissimilar to Slimcoin's) was recently delisted by Cryptopia because their wallet was crashing “30 times a day”, a condition apparently local to them and not reported by anyone else. There is some evidence to suggest that the exchange was staking the coins in the deposit wallet, which could well explain the particularly acute problem they were experiencing.

The Slimcoin address which I used to have in my local GUI client is now being curated by my remote server, a faster m/c, where it only consumes 5% of its allocated thread.

I’m tempted to consider this as a consequence of the basic design tradeoff entailed by PoS in the constraining of hash work calculations to the thread in which the app is executing - in PoW coins, hash work calculations are performed by recruiting additional compute power from a separate spawned thread, leaving the app's ability to respond to user input unimpaired.

Fortunately, Slimcoin’s mint-by-proof-of-burn offers a compute-friendly alternative: if your client is thrashing then don’t stake, burn.

Each to his own, ofc.

Cheers

Graham

The fact is the quoted repository does not have a COPYING file.

Cheers

Graham

The repository contains copied bitcoin code but the developer has removed the COPYING file, a classic indication of a developer with a distinctly idiosyncratic model of the world. You might wish to leaven your enthusiasm with a small dose of cool reality.

Cheers

Graham

A glutton for punishment, eh?

Hmm, although not strictly pertinent to the invitation, the earliest posting record I can find is on usenet, made from HPLabs on sci.psych nearly 30 years ago but I've been active a fair bit since then, so it sort of depends on your interests, really.

Assuming a cryptocurrency focus, there's DOACC, a (n abandoned in March 2016) collection of altcoin metadata and an accompanying OWL ontology (docs), plus Minkiz, an attempt at finding entertaining (and perhaps even useful) ways of serialising the metadata.

Taking a guess, of particular interest might be: a convenient ordering by name, a list of coinmarketcap's top-250-ish pos coins and metadata, ditto for pow, coins listed by algo and, by way of what sadly passes for entertainment in this domain, the hodlerscope and, as a courtesy to visitors, an opportunity to express faux-outrage at the brazen exploitation of the foundry.

“Minkiz” is a piece of online art, if you can get behind that notion.

Other than that, the long-suffering subscribers to the current main Slimcoin discussion thread are kind enough to tolerate my occasional wafflings. There there's my work on V but you'll need a strong head for that.

Cheers

Graham

You're nearly there, keep questioning the assumptions. Just one small step to go: “mass adoption would give you far more profit and a more stable future”.

Cheers

Graham

5530 and 5531 respectively.

https://github.com/vcoindev/vcoin/blob/master/src/chainparams.cpp#L30

Cheers

Graham

The private key is obscured, the address is visible and can be checked. The private key can also be encrypted (BIP38).

To gain the maximum from such an investment, some attestation of the provenance of the item would be desirable.

Not all that different from holding a Victorian penny black stamp. The extrinsic value as a rare Victorian printed item far exceeds the intrinsic face value as a postage stamp. A Dogecoin paper wallet provably containing the full amount of unspent coins and provenanced as originally owned by Jackson Palmer might be worth a few bob to collectors in the far future  - say, a couple of years at current rate of change

I'm from the past (it truly is another country) and my antiquated perspective is: if they'll collect Pokemon, they'll collect anything.

Cheers,

Graham

By serialising to paper, you migrate information from a low-entropy context into a high-entropy context and can use the entropic decay of the medium as a proxy “timestamp” accruing from the information being serialised on the universe's blockchain, so to speak.

Chemical analysis would identify a forged paper wallet in the same way that chemical analysis is used to identify a forged oil painting, by comparing the recorded level of localised entropic decay of the serialisation with the calculated level of universal entropic decay to be expected from such a serialisation.

2FA, something you have and something you know. You have the printed wallet, you know how old it should be.

There was some support for the notion in the past: https://bitcointalk.org/index.php?topic=408951.0

Cheers

Graham

Oh, how I wish.


Cheers

Graham

Isn't a paper wallet the only practicable realisation of this? That'd probably have worked. Anyone got a time machine?

Cheers

Graham

Sounds like it.

“Other than that Mrs. Johnson, how did you enjoy the play?”

Cheers

Graham