Do you how big is the PoS block reward?
https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L1049// slimcoin: miner's coin stake is rewarded based on coin age spent (coin-days)
int64 GetProofOfStakeReward(int64 nCoinAge, u32int nTime)
{
// FIXME static int64 nRewardCoinYear = CENT; // creation amount per coin-year
int64 nRewardCoinYear = nTime > POB_POS_TARGET_SWITCH_TIME ? (10 * CENT) : CENT; // creation amount per coin-year
int64 nSubsidy = nCoinAge * nRewardCoinYear * 33 / (365 * 33 + 8);
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfStakeReward(): create = %s nCoinAge = %"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nCoinAge);
return nSubsidy;
}
(The FIXME is the old ppcoin code, preserved for reference.) As can be seen from the code, details can be obtained by specifying the -printcreation command-line arg on startup and (in case it slid under your radar) -debug is also required for such loquacious logging. Cheers Graham |
|
|
|
When I click the link that you provided, I sometimes get an error message that reads, "The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later."
...
As for the syncing, after 6 days, it seems to have stopped at 66%. It had been making steady progress at 10% per day. I'm crossing my fingers that it's just taking a break and will eventually resume.
Try (literally, i,e stop and restart the app) “turning it off and on again”. I had to do that with the OS X client. Apologies for the minkiz failure, good ole' BSD: MemoryError: (12, 'Cannot allocate memory -- BDB2055 Lock table is out of available lock entries'), I need to turn the webserver off'n'on again (after first navigating to the directory containing the db files and incanting a 5th-level Unix wizard's spell of “BDB Giddyap”, i.e. db53_recover -h . (not forgetting the “.”) --- which I have now done and minkiz is up'n'running again and (having tested the link) should now deliver a snapshot in reasonably short order: https://minkiz.co/noodlings/slm/slm-datadir-snapshot.zipHowever, given that you're well advanced in a “proper” sync from the network, you may wish to let the OS X client continue to synch from the network --- fwiw I would consider that a useful “external” test and would compensate you accordingly with a small shower of SLM (and partly as a quid pro quo for wasting your time by pointing you to a non-functioning service). Cheers Graham |
|
|
|
I've set up an instance of the IQUIDUS JS-based block & tx explorer and after a couple of days backfilling the underpinning mongodb persistence, it's now up to date: http://tessier.bel-epa.com:3001/Just checkin' - is it accessible to everyone? It's accessible from me, thanks for that. Thanks, that's reassuring. (Summary is imminent, btw) Cheers Graham |
|
|
|
Try 92.233.116.13
trying connection 92.233.116.13:4777 lastseen=26.8hrsatm, my trying-to-sync (1689923 blocks thus far) datacoin node can only see 99.0.80.78:24498Cheers Graham |
|
|
|
is that too tricksy?
I can access it. Thanks, that's step 1. "IQVIDVS" is a little hard to get my head around with the missing U after the Q.  When I first saw it, I thought it said "IVIQUIDUS", maybe "VIQUIDUS" would be better? In classical Latin capitals, there is no difference between U and V, so IQVIDVS is a perfectly valid serialisation. (I do confess to having a somewhat “elliptical” sense of humour.)Cheers Graham |
|
|
|
I've set up an instance of the IQUIDUS JS-based block & tx explorer and after a couple of days backfilling the underpinning mongodb persistence, it's now up to date: http://tessier.bel-epa.com:3001/Just checkin' - is it accessible to everyone? I shall give it it's own CNAME URL and a modicum of rebranding - I thought “IQVIDVS”... or is that too tricksy? Cheers Graham |
|
|
|
I began downloading the blockchain for the Mac wallet 3 days ago. It is kind of slow. I am only at 40% and I estimate it will take 5-7 more days to download the complete blockchain. Is there a way to download it faster?
Glad to hear that syncing is at least looking promising But yes, there is - the old “datadir snapshot” approach still works as I proved to myself the other day, bringing a freshly-compiled OS X Slimcoin binary up to date. The resource https://minkiz.co/noodlings/slm/slm-datadir-snapshot.zipis a nightly snapshot of selected datadir contents ( blk0001.dat, blkindex.dat and database/*.log) from a Slimcoin client compiled with BSD 4.8. Download, copy to ~/Library/Application Support/SLIMCoin, unzip in place. Belt and braces Dept: first copy/move blk001.dat, blkindex.dat, database/* to a safe place, just in case the snapshot doesn't work for you because it's not a Tuesday, or your name isn't Graham, or because some other random fluctuation in the space-time continuum gives Slimcoin the slightest opportunity to pointedly ignore what you're offering it (including perfectly good bootstrap files, I might add). HTH Cheers Graham (Dunno yet if it's a solution that also works for Windows, will try and check that sometime next week) |
|
|
|
This paper uses data from the MIT digital currency experiment to shed light on consumer behavior regarding commercial, public and government surveillance.
The setting allows us to explore the apparent contradiction that many cryptocurrencies offer people the chance to escape government surveillance, but do so by making transactions themselves public on a distributed ledger (a ‘blockchain’).
We find three main things.
First, the effect of small incentives may explain the privacy paradox, where people say they care about privacy but are willing to relinquish private data quite easily.
Second, small costs introduced during the selection of digital wallets by the random ordering of featured options, have a tangible effect on the technology ultimately adopted, often in sharp contrast with individual stated preferences about privacy.
Third. the introduction of irrelevant, but reassuring information about privacy protection makes consumers less likely to avoid surveillance at large.
“The Digital Privacy Paradox: Small Money, Small Costs, Small Talk” - Susan Athey: Graduate School of Business, Stanford University, and NBER. Christian Catalini: MIT Sloan School of Management, MIT. Catherine Tucker: MIT Sloan School of Management, MIT and NBER, February 13, 2017 (PDF)And, of course, the one thing that distinguishes altcoin devs from others is their deep understanding of the role of human factors in engineering. Cheers Graham |
|
|
|
Sorry for delay, manic day. Relationship between holding company and users? None. Relationship between holding company and devs, which you may have meant, would be based on contractual agreement and buy-in.
Ah, okay. Basically, a private startup. Thanks for elaborating. Cheers Graham |
|
|
|
coimarketcap shows last 7 days only, and it is not detailed enough.
Detailed historical price data requires storage === costs money. Otherwise: Navigate to https://coinmarketcap.com, select “Tools” drop-down menu, click on “Historical Snapshots”, click on any date, import the HTML table to Excel. https://coinmarketcap.com/historical/Cheers Graham |
|
|
|
a holding company
And what relationship holds between the holding company and the users of an open source project? Cheers Graham |
|
|
|
patent options
Which organisation will own the rights to these patents? Cheers Graham |
|
|
|
Could it be a workaround to use the integrated block explorer for that?
Unfortunately not. Block browsers have difficulty with addresses - they require a horizontal slice through what is essentially vertically-indexed data (blocks) and so an additional address index must be created and maintained. The more sophisticated explorer that Mr Spread created for Spreadcoin (also sported by PIVX) has all the details: https://github.com/spreadcoin-project/spreadcoin/commit/f36d3d2b5dbb88b1b5c8bebc57d55153b3f35cee#diff-a8f23ed02dbd9dbe8eb37b2097341d55R346And I finally tracked down the details of the wrinkle introduced by Mr Spread that (I think) explains why the Spreadcoin vanity address generator uses uncompressed addresses: SpreadCoin uses a more compact representation for signatures in transactions.
SpreadCoin as well as Bitcoin uses ECDSA signatures. While bitcoin keeps a copy of the public key of the corresponding signature around, SpreadCoin ommits this by recovering the public key on the fly directly from the signature.
This way it is not necessary to keep the public key of every ECDSA signature in the blockchain, so this leads to *smaller transactions and hence a smaller blockchain (at the cost of a few CPU cycles more).
(*reduction in size of transaction from 139 or 107 bytes in Bitcoin to 67 bytes in SpreadCoin.)
I don't know whether this factoid will “unblock” the issue but at least I now know what I'm looking for. Cheers Graham |
|
|
|
Maybe, if would be possible to get two wallets running in the same slimcoin-qt window
That might ameliorate some of the GUI display issues but it wouldn't solve the problem of watch-only-address txs being included in the staking calculations - which happens in the app's core routines. The (optional) GUI wallet code in src/qt/* is just a visually-rich presentation of the data obtainable from the core RPC API provided by src/bitcoinrpc.* - which would need to be refactored (read: “completely rewritten”) to handle >1 wallets. Cheers Graham |
|
|
|
sometimes an address like your first btc address or a vanity one that you like can be very important in some way
One of the ways in which such btc addresses are important is as a signal to others that these addresses are considered “special” by the owner and worth close attention, such as generating a “look-alikey” vanity address that is designed, in the right circumstances, to sneak under the user's perceptual filters. Re-use of btc addresses (either “vanity” or “favoured”) leaks information and opens up the attack surface so is not consonant with a “total opacity” approach. Just sayin'. Cheers Graham |
|
|
|
I think it would be a nice feature that any user can create offline address with their mnemonic passphrase (as paper wallet style) and add in the client as "only read" (like omniwallet) in order to control their funds and if later they need move their coin could add the passphrase in order to get private key for signing tx.
It's funny you should mention that. I found this gist lurking on github: Here it is in action - I took a fresh wallet and imported both the general and bounty donation addresses as part of an exercise prompted by remembering to demonstrate that the original QRCode image generation facility still works as expected with watch-only addresses:  and I can take the opportunity to expose the ugly reality of the UI presentation:  And when the watch-only txs are admixed with the ordinary-but-indistinguishable tx associated with one's own addresses, it becomes a right dog's breakfast. Aaaand the tx date is incorrectly shown in the listing - which is why a separate listing will be required for txs associated with watch-only addresses If I can find a single point in the stake-calculating code which can be used to filter out watch-only addresses from the rest (any address without a privkey is a watch-only address) and I can persuade the wallet to filter out the watch-only txs from the overview and I can create a duplicate of the tx listing that is specialised to watch-only addresses then we could be in business. Cheers Graham |
|
|
|
I think it would be a nice feature that any user can create offline address with their mnemonic passphrase (as paper wallet style) and add in the client as "only read" (like omniwallet) in order to control their funds and if later they need move their coin could add the passphrase in order to get private key for signing tx.
It's funny you should mention that. I found this gist lurking on github: https://gist.github.com/WyseNynja/8120948It's a distillation of laanwj's bitcoin commit that implements just such a beast and at first glance, it does seem logical to embrace that power-up for wallet users. Unfortunately, the transactions associated with watch-only addresses would need to be explicitly prevented from being considered in stake calculations - which is a whole other ball game. Cheers Graham |
|
|
|
Just out of curiousity, is this how it works?
More like this:  (Transcluded from the Bitcoin wiki entry for BIP 32) The seed is 32 bits of output from any acceptable source of entropic bits (YMMV). Using dictionaries of words is just one approach. Cheers Graham |
|
|
|
Nevertheless, perhaps stealingadapting Ian Coleman’s BIP39 JS solution would be preferable. Done. Added https://github.com/slimcoin-project/bip39, the instructions seem reasonably clear. I don't know the 8th-level mage's spell of get-gh-to-use-a-nonstandard-index that Ian incanted in order to get the app to run under GH pages but I shall ask. This one should download, open and run in the browser as a standalone HTML+JS app. Cheers Graham |
|
|
|
|
Show Posts
