Says you, I don't know you nor do I know Dooglus. Verify don't trust, you should know that.
Unlike your good self, I don't operate under a pseudonym, you may verify me all you like. Also, I believe the community is now in a much better situation to assess its collective response to your demands, Cheers Graham |
|
|
|
What's your agenda really?
To get you off've dooglus' back. In your ignorance, you chose the wrong target. Cheers Graham |
|
|
|
So who went through the open source code to check it? And why is this problem not being addressed in the past?
Whomsoever wanted to. Are you offering to help fund an analysis or a bugfix or are you expecting to benefit from the work of others? Yes we would have asked the community at the right time, I'm here to check out the tech first.
In an offensively strident, demanding and challenging manner, making a boatload of false assumptions that you never bothered checking and which acted to exclude you from information about the ongoing development of the codebase. Plenty of other coins to check out you know. Not our loss really.
Pish. If the idea had merit in the first place, then it still does. Are you really prepared to compromise your project rather than adopt a more socially-aware approach? Perhaps this might help position you better in your efforts (here or elsewhere, if the latter, then good luck - genuinely): https://minkiz.co/library/a-different-perspective-on-cryptocurrency.html Cheers Graham |
|
|
|
Our plan was to use the cryptocurrency to help clean beaches/oceans of plastic which is a hot topic.
Perhaps if, instead of making heroic assumptions, you'd raised the idea with the community first, you would have been apprised of pertinent factors. Unfortunately as things look now, we can't use a coin that's potentially being manipulated by a dev for obvious reasons. We can't sell that to the public.
Could you explain exactly what magical powers you think a dev possesses in order to secretly affect the operation of open source code? I'm waiting for Dooglus' response on the matter before I write a report about the state of Clams. I also PM'd him, but no response so far.
Hardly surprising as dooglus is a contributor (which would have been made clear to you, had you the courtesy to ask, see pt one above) and is perfectly free to make his contrbutions (or not) as and when he sees fit. He also owns/runs JustDice, so has a user's interest in the functioning of the coin, hence the contributions. I recommend you waste no further time and move straight to the report. If you care to make it public here, it's possible that someone will care sufficiently to draft a response that may be of interest to other members of your organisation. Cheers Graham |
|
|
|
OK thanks for that. Does that also apply to the standalone linux miner I recall ?
EDIT : source code for the miner seems to have been removed from github ?
No, that only offers -t <n> threads, too crude to use as a CPU usage control lever. I looked at: https://github.com/gapcoin/GapMinerCheers Graham |
|
|
|
One coin which I know of which had this feature built-in to the miner is coin Magi (XMG).
Unfortunately, that codebase is authored in Javascript and would likely prove a challenging integration (I confess I've spared myself the chore of actually checking). OTOH, Dropcoin ( https://bitbucket.org/nscrypto/dropcoin.git), (using a Core 0.10 base vs Gapcoin's Core 0.9 base, i.e. close but still non-trivial) has a "percentage of available hashpower" slider in a GUI "mining" tab which might suffice but the feature is incomplete because there is no corresponding parameter for the RPC-API setgenerate call. Rectifying this might be feasible/practicable. Cheers Graham |
|
|
|
Interestingly, I don't have the problem on Radium .... Both have QT-based wallets.
Nothing significant about that, they are both clones of Bitcoin, so they both inherit the Bitcoin QT wallet. Perhaps of more signifiance is a clear indicator that the coins use different codebases, vitiating the relevance of anything other than a detailed technical comparative analysis. Radium 1.4.7 includes the following updates:
Improved peer discovery and sync speed
Partial bitcoin 0.11 code rebase
Increased op_return size
Fix supply hard cap
Cheers Graham |
|
|
|
Any exchanges alive?
I think coingather was the last one. That exchange just stopped working one day. Domain was seized by the FBI in March: https://www.fbi.gov/investigate/cyber/information-on-coingather-com-seizureThe Coingather.com domain has been seized by the Federal Bureau of Investigation in accordance with a seizure warrant issued pursuant to 18 U.S.C. §§ 981, 982, and 1960 upon a probable cause finding by the United States District Court for the Northern District of Ohio that the Coingather domain was used, or was intended to be used, to commit or facilitate criminal violations of 18 U.S.C. § 1960 (Prohibition of unlicensed money transmitting businesses). Please refer back to this page for future updates regarding the status of accounts held on the exchange. If you would like to file a complaint and have not already done so, please visit www.IC3.gov. Please include in the body of the complaint a reference to “Coingather” and your contact information, including the e-mail address that you originally registered with the exchange. Cheers Graham |
|
|
|
even if it is kind of silent here,
Fair comment. I've been spending some time over in the Helium slack. Helium is a fork of PIVX with its public ledger transferred from Spreadcoin, so it is also a viable (if challenging) potential path for Bee. I've appointed myself describer and implementer of the public ledger transfer and I have worked out a scheme that uses the genesis block transaction to deposit the public ledger total into a multisig "Treasury" address (a notion directly transferrable to Bee). I need a functioning PoW period in order to test the Treasury multisig scripts that disburse the public ledger. Like Navcoin, PIVX/Helium has an initial limited PoW period to allow staking coins to mature, ready for when the network staking weight has to take over from the PoW mining at the end of the PoW period. There are a number of other forks of PIVX, some of which have proved educational. I've recently successfully tested the basic PoW mining phase and the next iteration should test the PoW/PoS changeover - which, if successful, would position Helium pretty much ready for launch. And if unsuccessful, would position me for some further education. Cheers Graham |
|
|
|
If the app can talk to the client, then is the block explorer a matter of operational convenience? Or maybe is it that a current UTXO set is a vital part of the app's functioning?
Both. Preference as it's easier to query the API then else (explained bellow). It's important to have current set of UTXOs, can't do without. So, P2TH (pay-to-tag hash)[https://peerassets.github.io/P2TH/) is why is using API easier for now. P2TH is an address, which is like a directory from which tree structure can be derived. It's used to query for new decks (assets) and their card (token transfers). So, flow when using a local node is a bit awkward. P2TH is imported into the node via `importprivkey` and then via `listtransactions` it's queried. This can be resolved by using latest Bitcoin-core code which offers `txindex` and other marvels, which allows you to simply query a address without importing, hopefully that will come later this year for us. Another solution is using electrum-server. Thank you for the clarification. Some of the members of the Slimcoin Owners Club are exploring the notion of inscribing TrustyURIs in the slot offered by OP_RETURN data. There are similar associated issues to be addressed, such as limiting tx search to specific addresses, etc. Cheers Graham |
|
|
|
Well, that is of course that "Core" wallet includes code of cut-down mining pool.
Maybe trying to simplify the software and excluding that part, as I humbly advised long ago, is still better?
Core Wallet does not need bundled mining software :-)
And there is no reason to not make separate version with solo mining enabled for those who want it.
All good points. BTW, what code branch should I look into to base new generation pool on it?
Just use "master" ( https://github.com/datacoinproject/datacoin-core), there's no specific branch (because the Yandex tar dumps were copies not clones, so no upstream commit history), so feel free to organise it any way that suits you. Please note, I lost track of the Yandex dumps during the flurry of Windows-specific changes and don't know how that actually played out, i.e. whether there are any critical changes that should now be included. Cheers Graham |
|
|
|
Thanks for contributing to the discussion. My aim was to open up some of the practical implications that I thought might be in danger of being glossed over. It's not so much that the presence of Iquidus in the mix is alarming, no more so than any nodejs app, it's just that the requirement (or otherwise) was unclear from the README and signalled that some more extensive due diligence was indicated. If the app can talk to the client, then is the block explorer a matter of operational convenience? Or maybe is it that a current UTXO set is a vital part of the app's functioning? Cheers Graham |
|
|
|
Mh. I had also proposed to adopt PeerAssets some time ago because I liked the simplicity they claim (I had helped testing it in the Peercoin community, but very superficially, at this moment it seemed pretty buggy still).
There're some hard-coded references to ppc/tppc remaining but perhaps of more concern to anyone proposing to implement PeerAssets are the dependencies. btcpy being one such example: btcpy is a Python3 SegWit-compliant library which provides tools to handle Bitcoin data structures in a simple fashion. In particular, the main goal of this library is to provide a simple interface to parse and create complex Bitcoin scripts.
N.B.: this library is a work in progress so it is highly discouraged to use it in a production environment. Also, as long as the version is 0.*, API breaking changes should be expected
(original emphasis retained) we would need to install a network (ideally, with nodes around the world) of very stable servers running these block explorers.
...
But I remember also a RDF-based idea for these purposes ...
Not forgotten, merely thrashing out some details. Apart from the obvious practical issue of figuring out how to use message-queueing to enable the blocknotify script to run asych, I felt I needed to acquire more direct experience in hacking the codebase directly (elsewhere, I hasten to add) before proceeding and lately I've felt a need to consider the implications of GDPR and friends. I believe TrustyURIs in themselves are not PII (there has been some informative HN discussion about how the practicalities of observing "right to be forgotten"actually play out in the context of backups) but how it's going to work in practice for federated RDF graphs requires some extensive thought. The fact that SPARQL searches can be made on federated graphs seems to satisfy the networks' requirement for an appropiately non-centralised solution but I believe anything other than a "click'n'deploy" approach to provding a [group|self]-publishing service will fall short of basic user requirements. This particular approach was never going to be as simple and easy as setting up an account on FB but I reckon it might be possible to achieve a suffciently gentle on-ramp slope to present at least a viable alternative. Cheers Graham |
|
|
|
Hmm... Well @peerchemist have said, that adoption it to Slimcoin shouldn't take more than 1H.
Immaterial. The app needs infrastructure support in order to function, specifically it relies on the API provided by the Iquidus block and tx explorer - in this instance, adapted to work with Slimcoin. I'm not aware of such a beast. Cheers Graham |
|
|
|
If you have a testnet node, please let me know what it is, I'll add it to my testnets.
Unfortunately, I'm out of the game until I upgrade my server. It's Ubuntu 15.10 and doesn't want to play nicely: The following packages have unmet dependencies:
libczmq-dev : Depends: libzmq5-dev but it is not installable
And the build instructions are now incorrect in that --disable-zmq (disable ZMQ notifications) is not a permissible option with the new codebase... In file included from madpool/pool.cpp:14:0:
madpool/pool.h:18:18: fatal error: czmq.h: No such file or directory
#include <czmq.h>
Sorry 'bout that. Cheers Graham |
|
|
|
According to @peerchemist - it shouldn't take long
I'm not entirely convinced that there is a full appreciation of the amount of infrastructure that will be required to support such a scheme. For example: __main__.py: from .provider import Provider, RpcNode./provider/__init__.py: from .common import Provider./provider/common.py:
class Provider(ABC):
...
@classmethod
def sendrawtransaction(cls, rawtxn: str) -> str:
'''sendrawtransaction remote API'''
# FIXME: Hard-coded PPCoin references
if cls.is_testnet:
url = 'https://testnet-explorer.peercoin.net/api/sendrawtransaction?hex={0}'.format(rawtxn)
else:
url = 'https://explorer.peercoin.net/api/sendrawtransaction?hex={0}'.format(rawtxn)
resp = urllib.request.urlopen(url)
return resp.read().decode('utf-8')
There's not a lot of point in changing testnet-explorer.peercoin.net to testnet-explorer.slimcoin.net unless there is actually an Iquidus explorer responding at that location. Cheers Graham |
|
|
|
the testnet client is unable to mine via setgenerate true.
Sadly neither generate <nblocks> <ntries> nor generatetoaddress <nblocks> <address> <ntries> seem to do much more than generate reams of error messages. But at least there are error messages, unlike the sullen silence of setgenerate  Cheers Graham |
|
|
|
I ask for my friend : The Sterlincoin Client is using 20-30% of my cpu very often. how can I reduce this?
Just a guess, but it sounds like it might be a case of "UTXO bloat". If you have ended up with, over time, a large number of small stake rewards that are now themselves staking, this can result in an increased demand on the CPU when calculating stakeweight. Try rounding them up into a single tx and send it to yourself, thus reducing the number of txs in the UTXO set. You can do this just by sending, say 50 coins to yourself, the client will make up the total from the "small change" that it has lying around. All you lose is a bit of stakeweight for a short time. You might need to repeat the exercise until all the small change has been changed into 50 SLG bills, making counting easier (as a rough analogy). Slimcoin suffers fom the same (or a similar) problem / design tradeoff and I've found bulking up the accumulation of small stake reward txs into a larger tx sent to myself (I use a dedicated address labelled "Stakepot") is a reliable way of reducing the demand on CPU. Cheers Graham |
|
|
|
|
Show Posts
