What disaster? Fairly solid support for a base between $3-$4 compared to the sub-$1 of a year ago?

Cheers

Graham

Sorry, I can't help with the details yet, I am waiting for the cex.io compliance officer to get round to verifying my document submission, so I don't actually have an ARM device to play with yet.

Cheers

Graham

That might work but I have a nasty suspicion that watch-address txs will still turn up in the GUI unless explicitly filtered out. It did actually work for Slimcoin but I absent-mindedly imported Slimcoin's burn address and that promptly brought the client to a standstill while it futilely calculated the staking weight of 000s of txs for which it didn't have a privkey, sigh. There was an earlier PR (https://github.com/bitcoin/bitcoin/pull/2861) for the same feature, I found the discussion quite illuminating - the inclusion of pubkey-only addresses also has implications for a buncha other RPC commands and whilst the current focus is on Apertus' specialised and limited use case, in other broader use-case contexts, consequences for users need to be understood in detail - such as importing an address (pubkey) and subsequently, at a later date, importing the corresponding privkey and then (not unreasonably) expecting to be able to spend from what was previously a watch-only address but is now expected to be an “ordinary” address.

Cheers

Graham

A backport to Slimcoin didn't work so well - imported addresses not excluded from staking calcs, more work required. That shouldn't be an issue for Datacoin, though. There were some GUI infelicities which do seem to have been addressed in  this commit for Dogecoin (Core 0.9, I think) -  https://github.com/dogecoin/dogecoin/commit/5ca5fb179e3ac873c9fe547b6bac68bdab87c0c7

Cheers

Graham

This had gotten unpleasantly and disturbingly off-topic. Please desist.

Cheers

Graham

Unfortunately not. That feature was introduced to Bitcoin long after Slimcoin was cloned from Peercoin.

If it's lack of space that's a constraint, there's no remedy. Otherwise, there is a “snapshot” of the datadir which will bring the coin up to 00:15 this am: https://minkiz.co/noodlings/slm/slm-datadir-snapshot.zip, just unzip it in datadir, see if it works for you.

Cheers

Graham

There is a backport to 0.8.6 which might ease things in the interim: https://github.com/litecoin-project/bitcoinomg/commit/a946dcdb2a1db076e974fe58bed6a47d97000b1f

Cheers

Graham

Ah, right. Again my unfamiliarity with the domain unfortunately limits my ability to make constructive suggestions. I don't know the “orange pi” variant, I've been weighing up the devices listed as suitable hosts for a Kali Linux ARM image: https://www.offensive-security.com/kali-linux-arm-images and have been browsing the range of device solutions offered by https://pimoroni.com. My interest is in narrowing down the range of options to 2/3 devices suitable for hosting an implementation of Slimcoin ACME to act as a content publishing/curation resource. Thanks for adding “orange pi” to the expanding range of choices. As soon as cex.io's compliance officer okays my documentary evidence (it's been 3 days now, maybe GCHQ is being difficult), I'll be in a position to place orders. Gotta say the USBArmory looks very attractive but that's just pure techno-lust and has nothing to do with the ACME solution I'm seeking. But I will order one of Ron Garret's deeply cool USB cryptosticks: https://sc4.us/hsm/ (Ron is curator of the “crypto-practicum” cryptographers mailing liist <crypto-practicum@lists.sonic.net>, well worth lurking on, IMO)

Cheers

Graham

I've adapted the Peercoin resources for use with Slimcoin. makepkg completes successfully for both qt and daemon. It's ready to be finished off and submitted to AUR when there's a contemporary tarball on github (its configured to use a slimcoin tarball on minkiz.co atm).

https://github.com/slimcoin-project/slimcoin-aur

Cheers

Graham

Arch Linux isn't the only route to cross-compiling arm binaries: https://askubuntu.com/questions/250696/cross-compile-for-arm#250721


Search results are instructive. Optimisation is architecture-specific, so you'll need to use the appropriate flags.

Cheers

Graham

For a list of supposedly unique coins it's a bit same-ey. Too few details on the technical side to be meaningful - Bitcoin's scripting language is quite capable of effecting “smart contracts” - for the same arbitrary definitions of “smart” and “contract” that everyone else seems to be happily taking for granted.

Unique? Try Datacoin - 128K of data stored on the blockchain per tx, Slimcoin - unique tripartite minting (by proof-of-burn, proof-of-stake and proof-of-work), Gridcoin - BOINC client, Gapcoin - prime gap search, Navcoin - unique anon system, and those are just off the top of my head. You might need to break down the technical aspects into categories and go for a “top five” in each. Top tip: ls -l ./src/qt/forms usually gives a clue to GUI extensions which may be offering special unique features and github is searchable.

(btw, every blockchain observing the bitcoin protocol is a directed acyclic graph)

Cheers

Graham

OP long since gone, the current de facto curators of the social consensus are cryptohunter and GREEDYJOHN. I'm lending technical support, fwiw.

Cheers

Graham

Ah, good catch - I'd somehow omitted one change: https://github.com/backpacker69/ppcoin/commit/fdc540e775f83eed12b670286adb90e673619825#diff-54e45787cdb38fd8469fe6d1c48e67beR378

I effected the change, pushed the commit and successfully compiled the binaries under Arch Linux. There is one failing key test, annotated:

     // R length on 9 bytes
      // Rejected by OpenSSL 64 bits, so it should be always rejected

looks like it isn't rejected under 1.1.

I'm just getting to grips with the model, made some progress, it seems straightforward enough. I'll report back on further progress.

Cheers

Graham

https://stackoverflow.com/questions/22745076/libpng-warning-iccp-known-incorrect-srgb-profile#22747902

Cheers

Graham

That perception is reinforced by what I'm seeing on the Datacoin ACME: http://tessier.bel-epa.com:5059 (select Blocks->Browse the recent blockchain to see intervals for the last 100 blocks)

(Apologies for the unconscionable length of time it's taking me to get round to polishing up/finishing off the Datacoin ACME. Once again, I've taken on far too much and am having to plough through it.)

Cheers

Graham

It's a pleasure. (We English tend to the masochistic at times).

Ah, okay. I can't quite get my head round this issue. My Vagrant+ansible deployment script executes without problems on Debian Jessie, compiling both headless and GUI clients and successfully running the test suite - but Jessie reports its apt-updated-upgraded-gotten openssl as 1.0.1t so I don't get where the 1.1 issue arises for Debian 8. But that's just my poor understanding of the Debian ecosystem.


Unless I miss my guess, your primary interest is in working with a capable build rather than working on a capable build, so to save time and effort all round, I've moved straight to a solution. The peercoin commit you found was: https://github.com/peercoin/peercoin/commit/5b09830e5de0f5105534e69dbf4acffb3255869b which I have cherry-picked into a branch, resolved the conflicts, commented out a few problematic OP_CODE sections in script.cpp that were inherited from prehistory (and have not yet been excised from the Slimcoin codebase but probably should have been long ago, for reasons of safety, like all the other altcoins did), checked that the test suite executes without issue and merged the branch to master so Travis CI can act as backstop - which it is doing nicely: https://travis-ci.org/slimcoin-project/Slimcoin

I'm re-checking the build under Jessie (yep, it all compiles, tests pass) and have a Vagrant Arch Linux box, so I can have a play with a modified version of Peercoin's PKGBUILD file.

Cheers

Graham

Not my invention, alas - it was brought to you courtesy of the scurrilous and irreverent “El Reg”.

Cheers

Graham

Sorry about that, build documentation is disorganised atm.

You will need qrencode too if you used USE_QRCODE=1

Cheers

Graham

I wonder if the apparently increasing tendency to not read up-thread is a consequence of increasing numptiness or is merely a consequence of the limited screen real estate on fondleslabs seriously impairing the UI of a web app designed for desktops (c.f. bitcointalk's SimpleMachinesForum implementation)

Cheers

Graham

A very warm welcome to you.

Would I be correct in inferring that this issue is specific to the Arch Linux distro and not a general issue? Either way, more info would be most useful to me, at least.

For those following along at home, unless I've misunderstood massively, IMO this work by eddycurrent has opened up a significant line of development for Slimcoin in terms of taking advantage of the work being done on Peerbox.

May I offer a slight change in perspective? You're perfectly entitled to write we. What's the most convenient way for you to proceed, as a Slimcoin developer focusing on Arch Linux and devices?

At the moment, I am woefully ignorant on how the Slimcoin build behaves on other Linux distros. I did manage to hack up a Vagrant+ansible deployment script for compiling on Debian Jessie, I can't recall why it's only in my personal github repos (https://github.com/gjhiggins/ansible-slm-jessie) and why I haven't pushed it up to the slimcoin-project github a/c, maybe because (IIRC), the challenge (from ArchiTektor?) is to compile on the previous Debian release (I'm inadequately familiar with Debian, sry).

Given the potential impact of a “Slimbox”, I'm quite prepared to roll up my sleeves and support your work - hence my offered change in perspective - how would you (knowing far more about the topic than I do) like to proceed?

Cheers

Graham