That all looks right.

That expected time is in seconds, and 586991 / 3600.0 / 24 = 6.79 days

You should stake once every 7 days or so. You haven't staked at all in 23 days. That's unlucky.

Take a look at your debug.log file - it's in the same folder as your CLAM wallet.dat.

Do you see something like this?


If so, what do the "stake took ..." lines say? If it's more than 16 seconds that's a problem.

What nobody seems to have mentioned in this thread is that the whole problem was caused by transaction malleability.

The unconfirmed output that is causing the Ver's transactions not to confirm results directly from the parent transaction having been malleated.

The irony here of course is that "bigger blocks now" wouldn't have prevented the problem whereas Segregated Witness would have prevented it, because SegWit fixes malleability for those who use it.

Edit: here I point this information out to Roger himself. He apologizes. (search for 'doog' on the page)

You don't give me anywhere enough information to answer your question.

Can you tell me:

 * Are you keeping it online 24/7?

 * Is it up-to-date with the CLAM blockchain? ( run getblockcount in the debug console; compare output with the 3rd column at http://khashier.com/ )

 * Is it actually attempting to stake? (run getstakinginfo in the debug console; expect something like the following: )

LN uses nodes in the same way that the p2p Bitcoin network uses nodes. None of them are special. Anyone can run a node. Each node connects to multiple other nodes. None of them are centralised.


The hubs are the nodes and the spokes are the connections between the nodes.


Instead of wondering about it you could research it. If any node goes offline before its channels are closed, the channel will be closed when the timelocked transaction becomes valid, after a suitable delay.

Did you recently buy this account from the original Franky? I seem to remember talking with Franky a few years ago and he seemed smarter then. It could just be that he was agreeing with me then. That can make me think people are smart when in fact they're just repeating something they've read.

Also in v3.2.0 I found another confusing inconsistency:

If I use the 'paper wallet' or 'bulk wallet' tabs to encrypt a private key, I get a "6Pn" (compressed) or "6Pf" (not compressed) encrypted private key, whereas if I use the 'wallet details' tab to encrypt the same private key, I get a "6PY" (compressed) or "6PR" (not compressed) encrypted private key.

The little research I did tells me that 6Pn and 6Pf represent "Encryption when EC multiply mode is used" whereas 6PY and 6PR represent "Encryption when EC multiply flag is not used".

Why is "multiply mode" used in 2 of the 3 tabs offering encryption but not in the 3rd? Is that deliberate? Is there a good reason for it? Is using "multiply mode" any more or less secure than not using it?

When securing your coins you have two conflicting issues to address:

1) you want to be able to access the coins at some point in the future
2) you don't want anyone else to be able to access the coins without your permission

If you don't encrypt your paper wallet then you are making (1) more likely, but (2) less likely. If anyone finds your printed paper wallet they can immediately just take your coins.

So you encrypt it. It's relatively hard to crack the password on paper wallets, but there's a risk that you will forget the password yourself. So (1) is less likely, but (2) is more likely.

It's a trade off. Encrypt if you like. Or don't.

I think the latest installment of QS' hit show "clutching at straws" featured a link to this thread. That's probably how you ended up here.

Exactly this. As a result he didn't gain a million dollars in the recent price increase. That would only be the case if he sold his BTC for USD. And why would he do that if he believes in the future of Bitcoin?

I see no coincidences here. Lots of Bitcoin gambling sites were buggy, and I helped to fix lots of them. I saw "were" because I no longer waste my time trying to help new sites. Experience shows that it almost never ends well.

As much as I hate feeding the troll, I guess I should respond to the 3 cases he mentioned:

1. The balloon site offered me a bounty when I reported their bug, but never paid it. I didn't do anything other than play their game to discover the bug. I published my interaction with the site owner. I wasn't extorting him. He offered a bounty freely, and later retracted the offer. The whole way he was running the site was scammy, offering payouts he wasn't bankrolled to be able to offer, etc.

2. The crypto-games site had a bug which someone else found. I never attempted to get a bounty for finding it, since I never found it. I remember the guy who did find it offering to share any bounty with me, but I don't remember ever asking for that, or ever receiving anything.

3. PRC had a bug bounty in place. I found a serious bug that was actively being exploited by an attacker and they took the longest time to pay the bounty. Note the winky face after the joke about "paying him off". That means it's a joke.

Yes, the network targets one block per minute. Though block timestamps are always multiples of 16 seconds (since some date in 1970 or something) and so cannot be exactly one minute apart from each other).

The only significance of 8 hours I can think of is that it's roughly the amount of time it takes for a block to mature after being staked. The staking output cannot be spent until it has 500 confirmations, and at 1 confirmation per minute that's a little over 8 hours.

Having said all that, staking is random. If you have 1000 CLAMs you can expect to stake about once per day on average at the moment. If you have more or less, change that estimate proportionally. The client uses the current network difficulty to estimate the expected time until staking. The network difficulty wanders up and down each day and so the estimate reported in the client wanders down and up as the difficulty adjusts. Like with Bitcoin mining, you never make "progress" towards staking a block. Every 16 seconds you either get to stake or you don't. Eventually you'll get to stake if you keep trying.

I'm not sure what you're saying here. Are you accusing me of abusing the trust system in some way? I barely use the trust system other than for marking scammer and promoters of scams as being untrustworthy. I don't see how you can call that abusive.

This whole thread is complaining about how I fixed some publicly available code which was incorrectly determining the sending address of Bitcoin (or CLAM, as it happened to be in this particular instance) transactions. In balance I think such a change is a good think. People copy an paste open source code snippets for use in their own projects. It's better to fix bugs in open source code when you see them because you never know what project the code will find itself in next. Correcting errors I find online is habitual for me. If that constitutes "shade activity" then so be it. I'm not going to stop fixing errors wherever I see them.

I was wondering that too, but Just-Dice clusters were easy to identify, and they say all the gambling clusters are purple.

Weird that 999dice got onto the chart and JD didn't!

I found the following interesting, and thought I'd share it here:

I came across a new paper on the subject of Bitcoin address clustering - the practice of studying transactions on the blockchain to identify which groups of addresses belong to which wallets:

I noticed this diagram of the largest address clusters:



I hadn't heard of betvip.com before the CLAM whale digger surfaced, but from the little research I did, it appears that he was digging mostly from that cluster.

The diagram shows just how many more whale diggers there could be. There are many more the same size or bigger. And then there are LTC and DOGE clusters too, not shown here.

Edit: Of course, many of these clusters could have been mostly empty addresses on the CLAM snapshot date, and so wouldn't be candidates for digging.

Yes, the key word here is 'average'. Each stake can take more or less time to actually happen; it's pretty much random, since whether you stake or not is based on the size of the hash of a bunch of stuff.


I don't, sorry. I personally only really use poloniex if I want to buy or sell CLAMs. It's the biggest market, usually has a decently narrow spread, reasonably low fees, and I have never had problems trusting them with up to 50 BTC or so in my balance. I did play about with one of the other exchanges when they first added CLAM but I didn't like the site felt, or the lack of liquidity in its market so I went back to poloniex.

I can also recommend arranging direct trades in the just-dice chat tab. You can usually find somebody willing to trade CLAM for BTC, and there's a free built in automated escrow system (type /escrow there for details).

Or in layman's terms, by default every signature is signing the complete set of inputs and outputs. If you change any input or output the signatures become invalid.

There's no difference other than that with a coinjoin the inputs are owned by different people whereas with the transaction you made all the inputs were owned by you.

Before coinjoin, you could look at a transaction and be pretty certain that all its inputs were owned by the same wallet. People would use this information to cluster addresses into groups.

After coinjoin that assumption is no longer valid. Multiple parties can cooperate to sign a single transaction where they each own some of the inputs. This makes clustering by ownership harder to do.

Here's an early example:

  

It looks like gmaxwell owns both input addresses, but he doesn't. He only owns the smaller one.

Congratulations to The Great CLAM on reaching the one million blocks milestone!

It's been a while since I replied to posts here, so here goes:


You want tcp/31174 open to the world for p2p connections, and tcp/30174 open locally if you want to use RPC. Don't open the RPC port globally unless you know what you're doing.


I've been updating it semi-regularly here:

https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

I did just update it too.


It was exploitable for sure. I don't think it was designed to be exploitable; I think it was an accident. I did point out to the developers (on Jul 23 '14) that it seemed exploitable soon after it was launched (on Jul 12 '14) but it was already live by then:


It turns out that the cheating that happened combined this with manipulating the timestamps on blocks. See how the timestamp on block 163967 is 6 minutes earlier than the that on the previous block:


so it turned out it was even more exploitable than I had previously thought.


To maximize staking, smaller is better until you get to the point that your wallet is using all available CPU checking your outputs. You need to balance that against the future transaction fees required to recombine your outputs when you want to spend them. Note that splitting won't speed up staking, it will only reduce the effect of the 500 block maturation time after an output stakes.


If you only have 30 CLAMs, you will be waiting an average of 30 days to stake no matter how you split them. If you have 3000 CLAMs and split them into 100 piles of 30, each of the piles will be waiting an average 30 days to stake, but one of them will get lucky and stake early. You can expect a few of them to stake each day on average. If instead you split them into 1000 piles of 3, each will be waiting about a year to stake, but you can still expect a few of them to stake each day on average. And each time one of your 3's stakes, it is only making 3+1 CLAMs inactive for 500 blocks, whereas when one of your 30's stakes, it is making 30+1 CLAMs inactive for 500 blocks, which is clearly less efficient from a stake-as-much-as-you-can perspective.


I recently noticed that over 50% of the Just-Dice hot wallet was unavailable for withdrawal. Upon investigation I saw this massive stake transaction. A large deposit had staked before I got a chance to split it up. It split as it staked, but by then it's too late - all the outputs are unavailable until they get 500 confirmations.

You missed the point.

The point isn't that the new technique is faster, it is that the new technique is patented.

If it was only faster then everyone else could also go faster to keep up.

But it is both faster and patented, so even if everyone else comes up with the same idea, they still aren't allowed to compete because of the patent.

Until you can come up with proof that I am building a slave army of newborn babies I suggest you shut up about it.

Also (in an unrelated note) do you know where I can get good ear protection and bulk diaper supplies?

So someone with 500k CLAMs started dumping after he saw that the price was starting to fall? That seems reasonable to me. He held as the price was going up, and decided to cash out when it started to fall.

You never actually make any claims, so it's impossible to argue with you, but are we to suppose that you think I am the same person as CreativeCuriosity (one of the original creators of CLAM), and that we're both the same person as the whale digger? "CreativeCuriosity + dooglus + digger = CreativeDooger" - very clever!

I know I'm neither of them, and I would put money of the other two also being different people.

I'm sure people would be interested to see any evidence you have of any of the three of us being the same person. Just stringing our names together doesn't count, sorry.