 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
I'm having an issue with digging. I dug 2 valid (afaik) wallet files but received no clams. However, several addresses entered from this same wallet on the FreeBitcoins.com site were shown as diggable, and I just dug one address via that site ( https://freebitcoins.com/clamchecker/digs/fcc24c32fc8a2d6e96af82bcd4de5d4a23c8257332844d08ffb1e10317942fb4/) - still waiting on payment but it seemed successful. I downloaded Clams Client (clam-1.4.17-win64.zip - SHA256 E1206F....D492) yesterday from the GitHub link on the CLAMclient.com site. I then downloaded the bootstrap file (SHA256 checksum matched) and tried to import both an old Bitcoin and Litecoin wallet.dat. Although the wallets held addresses used before May 2014, no Clams were received in my wallet, which shows 0 balances and no visible transactions. I tried both digging both wallets multiple times, both via Import File in the wallet and from the importwallet command in the wallet's console. The console gave no output after running the importwallet command, just a red minus line with no text. The receive tab in my wallet displays a bunch of importwallet addresses, none of which match the addresses in the debug.log file. I spoke to tryphe in #clams on freenode, he was very helpful but we weren't able to resolve the issue. He told me to examine the debug.log file and I found about 20 DIG entries. The weird thing is these entries link to transactions which occurred arround the time I was digging but lead to addresses not under my control (or at least not visible in the receive tab of my client). From the comments on clamsight, it looks like some of these addresses were dug via freebitcoins.com, others via a wallet, and most of them were spent to an exchange. I'm really confused, can anyone help me understand what's going on here? Just to clarify things a bit more, Sir Lagsalot seems to have taken the proper precautions when digging and didn't enter any private keys online. What makes the situation peculiar is these transactions signed by his keys: http://clamsight.com/tx/73ea5b1acd26a477af250e5bd97d7336751598e2f89aac0ef0c2feeacf9c7f4b#i0http://clamsight.com/tx/0f4cb75614432bca313a7a3b70aa658d8b2d3f83e494fa3009b71411475f9419#o0which he claims he did not make. To make it even weirder; one is from freebitcoins.com, and one is from a clam wallet. None of those addresses that the coins got sent to are his exchange/wallet addresses. He also claims that the wallet was encrypted since inception, and given all his keys aren't emptied (they are now, as a precaution), I'm not really sure what to think. Any ideas? I've installed v1.4.17 for Linux and am running the console via ./clam-qt
I am only getting 2 peers. I'm wondering if there are nodes I can add to my clam.conf? I've looked around and the info seems to be pretty old and ineffective.
I've also added bootstrap.dat files in my ./clam folder posted by dooglus elsewhere here but that doesn't really address the lack of peers or will it when I catch up?
Thanks in advance.
It doesn't really matter how many peers you have during the bootstrap process. Once it completes, you will have more peers. If you really want a lot of connections, you should open the port, otherwise no one can directly connect to you. If it seems like it's stuck and not loading the bootstrap (the disk should be swamped while bootstrapping), try restarting the client with '--connect=localhost' in the args, and it should work properly. At some point, it will become 98%+ synced, and you can remove those args. I left CLAM alone for about 80 days, then restarted it a few days ago - and it's still trying to sync...
The debug log is full of "already have block" and "ORPHAN BLOCK 751" entries.
2017-05-08 10:22:14 SetBestChain: new best=e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a height=1486871 trust=466372186589834826465 blocktrust=338273748876064 date=04/28/17 01:14:40
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:26 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
2017-05-08 10:22:30 ERROR: ProcessBlock() : already have block 1486871 e14bb9bc8557e99af05120468920505f7c1208fdb321a9124e41234659fd420a
Here's a random but typical example. The same block was received four times over a period of 16 seconds.
Why are peers sending blocks multiple times, and seemingly (due to all the orphan blocks) out of order?
It's taken 3 or 4 days just to advance the blockchain by a couple of months. Any further work on fixing this?
Check out the bootstrap. It will get you caught up, which avoids most of the orphan nonsense. I wrote a bit of a how-to here: https://www.reddit.com/r/Clamcoin/comments/5z5x77/sync_issue/ (sorry for the piggy-back links) As for fixing the issue: yes, it's a problem. None of us have been able to pinpoint the root cause, and since it doesn't happen when caught up to the chain, it's been put on the backburner. Eventually the issue was condensed into this one: https://github.com/nochowderforyou/clams/issues/294Anyone is feel free to help if they're familiar with the block indexing code, and would get some clams thrown their way if they fixed it. |
|
|
|
I've never been able to claim CLAMS from old BTC addresses, is there a specific way to do it?
Synced the whole blockchain then pointed to a local BTC wallet.dat file but no luck (with the Windows and Mac Desktop Wallet).
Is there another way to claim CLAMS from old BTC addresses? Any guide anywhere?
Or is this now over and cannot claim anymore?
It sounds like you did it correctly. The distribution is indeed still going on. You should have some sort of debug.log output that it was scanned. You can also run 'importprivkey <pkey>' to test a single key(BTC/LTC/DOGE). |
|
|
|
Why does this coin sync at 100 block/day or something silly like that? Is there a fix?
What do you mean? The blocks should average out at about 1 per minute, or 1440 per day. I'm referring to syncing a new node I started syncing in early April and it literally took weeks, though it does seem to have finally completed. Nice to know that it works from scratch for someone else. The upside is that once the client is synced it doesn't seem to happen nearly as much or at all. The problem is that the orphan code is a bit screwy and the large number of orphan blocks on the CLAMs chain seems to compound an issue in the orphan code, causing syncing to become very inefficient. There was a commit that was problematic: https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112However none of us were that familiar with the block indexing code enough to actually pinpoint the issue. In fact, I think it still happens with that commit reverted, but that's when it was realized. There are 3-4 issues(not separate issues, just bug reports) open directly related this problem but it hasn't been resolved yet. I believe there's a 500+ CLAM bounty on it last time I spoke to SuperClam; however I'm not sure if that still stands. I'd really like to see this fixed though. Anyhow, to avoid network syncing for most of the chain, you can download dooglus' bootstrap here: https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191And here's more instructions on how to use it: https://www.reddit.com/r/Clamcoin/comments/5z5x77/sync_issue/df4as22/Hope that helps. |
|
|
|
From the ToS: 3. Coinitrage does not confirm that the data presented as the content is decisive, complete, correct, or affirmed. Is there any sort of proof of solvency, such as keeping all invested funds at a single wallet address, per coin? Maybe sign a message with the addresses as well, so we know you control these funds. The only reason that we know 40+ BTC might be invested is because you're telling us, and this type of grey line is neither assuring nor convincing. So, where is the 40+ BTC? |
|
|
|
From the CLAM thread: Doog, JD has some bugs now
It turns out when I designed the JD database I thought 2.1 billion bets would be more than would ever happen. We just hit 2.1 billion bets (2^31) so things stopped working. I've suspended betting and am modifying the database to remove the limitation. I'll post again once it is done. I've no idea how long it will take, sorry. Why would you put a limitation like that in the first place? Seems like it would just be an extra line of code to go in. Because and people love using small default size variables. I actually joked that this would happen a few months back, however I thought I was wrong because you can enter any number in just-dice.com/roll/<number> etc. 1029381803572348957394875348975 and it doesn't complain. So I didn't say anything. *shrug*  |
|
|
|
I was looking around for more peculiar stuff. Here's an instance where cryptoguru's block explorer recorded a TX of the entire coinbase(pretty much) that tried to get spent right in the middle of the difficulty "attacks" (i.e., notice the chain is moving at half speed):  Edit: I went through this with funk and this is just a sum of multiple transactions, not a single transaction. You can see most of the blocks here: http://explorer.woodcoin.org/chain/Woodcoin?hi=309100&count=100 |
|
|
|
I think you missed the point of me posting that graph, which indicates that something has been going on for ~8-9 months, not ~3,000 blocks. If you watch the chain, it's quite indicative of a netsplit as transactions are pooled from the diff attacked chain onto a "just barely longer" chain, and then attacked for 30+ blocks (the difficulty adjuster length) immediately. Mining then stops until it happens again, presumably because the "just barely longer chain" is on a netsplit with multiple nodes in contention. Maybe their connection can't handle the onslaught of incoming blocks, or there are multiple nodes serving miners work when the attack occurs? I don't know. so, we are at 357 182... look like there was 3000 blocks stolen on the chain
Who were they stolen from? The diff attacker? And where did they go? Like Funkenstein, I see no double spends, and I see no unconfirmed transactions. Just a diff attacker and a netsplit. If it was a malicious attacker, I'd expect to see some extraordinarily large malicious spends, not valid reorgs with valid transactions in them. Satoshi deemed the chain with more trust (not more blocks) as the main chain, simply because a valid long-term miner will win outright simply to cover the array of strategies that people will try; including what you're seeing here. From that standpoint, neither chain is malicious and there is no attacker, but a chain with more trust that wins outright. I'll let people judge for themselves, though. I looked on the block explorer for a large reorg, but I didn't find it. There's not many transactions on chain, so it's hard to tell where the splits occur, so I went through the last 4,000 or so blocks: 359306: http://explorer.woodcoin.org/block/8c5da867aeed8afd323de11e73e7b92fc90bd9d090fe5e7fd11c913b0e5cfd2e358947: http://explorer.woodcoin.org/block/dbc7a64fbf3242c1d2837783925c5c90203381a7b19ff722c0fb9c9c9bb42ebd358932: http://explorer.woodcoin.org/block/30e197100ae71b14242d13845d99c7d36108d8a6234a70bc28ca11b8e767ffc8358598: http://explorer.woodcoin.org/block/e9182271fe244a2494a565fda1a2bcf83c217697d41332883566e12925bd9622358560: http://explorer.woodcoin.org/block/ccdb8889eb82a3befda373c6e706fb0188d82421d324aea052eac2010a4e4544357986: http://explorer.woodcoin.org/block/9767225db64cd68810e77160c8bdb7d7eb40dd8979b801b91bce9b641ac7c602357391: http://explorer.woodcoin.org/block/b5e4b84e7266cec9ac8a3414c09c2ab85e92cda037182ece20d0b69401ab9669357252: http://explorer.woodcoin.org/block/c025e43de9f27c472ff5cf3c8dd194424c27c469dce0f429e80f49a822e8782c356860: http://explorer.woodcoin.org/block/85b6e1ac53743844c245d8532d3c8d767bbf5434b51b637e27cfad58ff8e011c356602: http://explorer.woodcoin.org/block/8ad174df2a338014e84dea6241d2f8d23df618ec36c72acea37196b9aefc0f8e356540: http://explorer.woodcoin.org/block/87d796fecc1b2493c6c273931463fe65de465ce546a6f2a786ab58956ec575dd356333: http://explorer.woodcoin.org/block/6af22fad10f7b10792b7b680c6ac0bc60a475b1b45b4aee0395b21f51b55e55a356197: http://explorer.woodcoin.org/block/adc12cad7092154cbef9e7027d03674bfa8713f4fff700720fe1ab4216ccae84355892: http://explorer.woodcoin.org/block/ed9754c1d6f6096e006575f20e16fa7e8ad5c044a39c12bd588dcb06d22c48ed355879: http://explorer.woodcoin.org/block/35b5aeae99f0c4182bf24f5297e99d2f7df0e69e2f30d45bf8239ff72775f174355864: http://explorer.woodcoin.org/block/02bd02c3978b401ca1b28397a9d5ba1198e9e14763b2d21f252914225d0816df355647: http://explorer.woodcoin.org/block/9ef99c7ba91b4fd2d8ccf3cefef69d37b4cb9da0c25475da9b96ba57e5cb27faask ccex all txs are locked since days Why not 8 months ago when the diff started roller-coastering? The diff attacker could just as easily mine for a bit longer and double spend the mined coin, but they haven't. If anything, they should just up the amount of confirms it takes to get on the exchange, considering this kind of contention is happening, and probably has been for a while. |
|
|
|
any idea what could explain the increase of orphans in the last days ? <snip> and i received some wood from the sky Orcs attack!! Modern day Robin Hood?  |
|
|
|
 Sweet!
|
|
|
|
funkenstein and the pioneers of log driving!  |
|
|
|
|
~0.19% daily ROI speaks for itself.
|
|
|
|
Thanks everyone, I had to to a double/triple take.  Many thanks to minerjones and the raffle affiliates for putting on such a great raffle! Thank you!
|
|
|
|
Sweet! Sign me up for a random spot! Thanks minerjones! |
|
|
|
|
Long Live the Great Clam.
|
|
|
|
|
The pool appears to be on a fork or not working correctly. It accepts my hash fine though.
|
|
|
|
Am I stupid or am I stupid?  Where can I download desktop wallet? All the builds are built by third parties, unless you want to build it yourself. The links are in the first post under "Windows Versions". |
|
|
|
|
I'm all for things staying the same. Market sentiment is dubious and people seem to have unsewn themselves from inside their couches just for this reason. Nothing is wrong, and we all signed up for the same distribution. Without the distribution, it's just another token. Aspirations always win, in due time.
|
|
|
|
|
I'm not insinuating anything. You're the one that said you could prove it was fair. But you still haven't, despite all of this.
You can't. No one can. (apparently)
The money of your players is placed on faith that you've done the right thing, not concrete evidence.
Once again, thanks for clarifying.
|
|
|
|
Why are you just insistent on posting relentless garbage? Don't you want your site to be fair to your user base?
I think it's important to be careful with the language. There's nothing to suggest that his site isn't fair. The issue is that we can't know whether it is or not unless he proves it to us. I agree, but the questionable responses are equivalent to "You said I was wrong, but that's not true. But look! A shiny quarter!". He's asserting himself to being correct by leaps and bounds while being quite duplicitous by switching the subject to some unrelated details of his system, and then using that for 95% of the post. We're sticking with GLI - For 25 years, Gaming Laboratories International, LLC has continuously delivered THE best quality land-based and iGaming testing and consulting services with supreme accuracy while reducing time to market. With 21 laboratory locations spread across Africa, Asia, Australia, the Caribbean, Europe, North America and South America, GLI is the only global organization of its kind to hold U.S. and international accreditations for compliance with ISO/IEC 17025, 17020 and guide 65 standards for technical competence in the gaming, wagering and lottery industries. For more information, visit www.gaminglabs.com. If you choose not to play on our site, then vote with your web wallet. If you wish to disparage us because we don't use a dice system to measure the fairness of slots, then expect a swift response. If you'd like to discuss scam sites, then please do so on another thread. This is our official thread meant to answer our player's questions, update them on contest results, and make promotional announcements. We have gone out of our way to explain that Provably Fair systems were used during initial testing, and they were ineffective when applied to a slots scenario, and for several security reasons, we do not subject our software and platform to systems that put our security and that of our players at risk. In other words, the "institution" that supplies numbers for you and has your players' money in their best interest, is not in your control. There is no proof. Thanks for clarifying. There was no need to beat around the bush, though. |
|
|
|
|
Where are you getting that quote from? Also, (good)working implementations don't use a new server seed for every roll, and let the client choose a new seed for themselves at their discretion. Which in turn, lets you verify a sequence. Which, by the way, you already said was impossible to do in my "casino in the sky".
|
|
|
|
|
