Not sure if it will bounce enough to cover this disaster.
What disaster? Fairly solid support for a base between $3-$4 compared to the sub-$1 of a year ago? Cheers Graham
|
|
|
Just a quick update. I have been evaluating a few ways of compiling for arm devices, and it looks like one of the best ways may well be to cross compile Slimcoin's dependencies and use those to cross-compile the client itself. Any thoughts?
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
|
|
|
Maybe if we omit any of the src/qt{/*.cpp, /*.h} changes and just shunt it into the RPC core?
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
|
|
|
Additionally, here is a reference to the original watch-only-addresses commit in Bitcoin Core. 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/5ca5fb179e3ac873c9fe547b6bac68bdab87c0c7Cheers Graham
|
|
|
This had gotten unpleasantly and disturbingly off-topic. Please desist.
Cheers
Graham
|
|
|
Can I load the block history completely? Is there an analog of the "-blocksonly" mode? I mean "pruning". I want to try a coin, but it's not possible for me to download the whole blockchain from 2014 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
|
|
|
I am using an orange pi for compilation because then I have qt and other librarys avaliable for arm.
Thanks for the help, but I just tried compiling with -march=native and it is still having segmentation faults.
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
|
|
|
Does this mean that you will provide AUR packages for Arch Linux or will I still need to do so?
I'm just getting to grips with the model, made some progress, it seems straightforward enough. I'll report back on further progress. 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-aurCheers Graham
|
|
|
I will now start work on compiling the daemon for arm
Arch Linux isn't the only route to cross-compiling arm binaries: https://askubuntu.com/questions/250696/cross-compile-for-arm#250721warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
Search results are instructive. Optimisation is architecture-specific, so you'll need to use the appropriate flags. Cheers Graham
|
|
|
Please list all unique coins.
Ethereum - Smart contracts. EOS - Async Smart contracts. NEO - Smart contracts QTUM - Smart contracts
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
|
|
|
hi, any beecoin founder here? I have a serious proposal to make.
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-54e45787cdb38fd8469fe6d1c48e67beR378I 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 rejectedlooks like it isn't rejected under 1.1. Does this mean that you will provide AUR packages for Arch Linux or will I still need to do so?
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
|
|
|
Am I seeing blocks that are substantially under 60 seconds here (contrary to what we advertise) ?
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
|
|
|
Firstly, thank you for taking the time to respond.
It's a pleasure. (We English tend to the masochistic at times). No, I believe it affects debian jessie, ie. debian 8, as well. I would imagine that it affects any distribution that uses openSSL1.1, but without further research I could not say for certain. This issue was raised earlier in the thread as well: 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. Firstly, I must point out that I will not have much time to work on this for several weeks ...
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/SlimcoinI'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
|
|
|
fondleslabs...now thats just brilliant, LMAO!
Not my invention, alas - it was brought to you courtesy of the scurrilous and irreverent “El Reg”. Cheers Graham
|
|
|
/usr/bin/ld.exe: cannot find -lminiupnpc Upd: That's OK. I just installed libminiupnpc-dev. Sorry about that, build documentation is disorganised atm. You will need qrencode too if you used USE_QRCODE=1 Cheers Graham
|
|
|
this project has a big volume, but why there is a dump
um... Well, there was this thing called Helium that was announced and ......ahhh, come to think of it... nm. so.... when did you wake up there, Rip Van Winkle? 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
|
|
|
I am new on this forum A very warm welcome to you. the error preventing Slimcoin compiling against openSSL1.1
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. I recently noticed that this error had been fixed on the peercoin codebase on the development branch. I compared Slimcoin's codebase to peercoin's and found that they were so similar that I could modify the appropriate files in Slimcoin so that it could be compiled against openSSL1.1. I have compiled it successfully and I am currently in the process of testing it to ensure that it is still stable and all features still work. Currently it is almost halfway through syncing from zero. If this is successful, this would enable it to be compiled for both Arch Linux and Debian.
Related to this is the release of Slimcoin as an easy to install application on various platforms. If it becomes possible to compile against openSSL1.1 I was contemplating placing Slimcoin on Arch Linux's AUR to enable easier installation and accessibility.
By the way, I am also working on producing precompiled applications for arm based devices, as I would personally use these, again I would place these on the Arch linux AUR.
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. If you(the Slimcoin developers) would let me know how you would like me to proceed with these fixes and proposals, I would appreciate your feedback.
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
|
|
|
|