For CLAM, the consensus only insists that the 1st input and 2nd output have the same pubkey when staking. Later inputs and outputs can have any pubkey you like.

I use this as a free way of tidying up the 'dust' outputs that collect in my wallets from faucets.

There's also -rewardto, which sends just the staking reward to the specified address. This would be useful if you wanted to keep your principal but send the staking income to an exchange for selling, for example.

I came up with the idea when I wanted to switch the majority of the JD coins from one staking address to another.

Moving them would have killed their age and caused a 4 hour period of no staking - so I figured I would have them move themselves over to the new address the next time they staked.

Doing this made the chart nice and smooth too. Unfortunately the chart page stopped working about a week ago, presumably because it now has too many transactions on that address - oh, but it's working again now:

Any idea what this is referring to?


Is he saying that implementing BIP 62 opens up a new known attack vector?

Does this require a payout or a profit of that value?

The natural interpretation would seem to be that you need to profit by half of the maximum profit.

That would require a payout multiplier of at least 6.26x, which has a chance of happening of less than 16% (else the game would be +EV).

The site (ballonbit) didn't pay the amount they had promised to pay me, and my feedback for the scammy dice site (dicebitco.in) was left before there was any indication that they were scammy. But you know all this since we have been over this elsewhere.

OK, so some of them only give you a light dose of the clap. But I think his point was clear enough.

Each block in the chain is a list of transactions.
Each transaction has a list of inputs and a list of outputs.
Work through the transactions in order, keep a list of all the outputs which aren't used as inputs for other transactions.
That gives you the list of unspent outputs.

Each output has a script which says how it can be spent.

The CLAM developers copied those outputs' scripts and put them into the CLAM block chain.

For example, this BTC transaction funds 1CrPRwBkwZdEejXusCbh8o35YMN7g7ffKf with an output which has this script to spend it (it looks a little different but that is just because of how the different block explorers are displaying it. It is actually a byte for byte identical copy):



The same script was used in this CLAM transaction to fund the corresponding CLAM address by making an output with the same script to spend it:



To use an analogy, each public key (ie. address) is like a lock, and the corresponding private key is the key that unlocks it.

The CLAM developers simply copied the locks from the BTC chain to the CLAM chain. They don't have access to the keys which open those locks, but since the locks are exact copies anyone who can unlock the BTC lock can also unlock the corresponding CLAM lock.

Edit: I found one...

Do you consider incoming trust as well as outgoing?

If someone is 'farming' trust, they will probably be leaving positive trust on multiple alts at a time. Recognising such patterns could maybe make your tool stronger.

SuperCLAM will no doubt tell you about the roadmap, but I can tell you it wasn't made for JD. I know this because CLAM was launched quite some time before I even heard about it.

Trust lists are public. I don't see how anyone could have a problem with you sharing them, or the results of analysing them.

I say post your results.

There's nothing wrong with my logic. I didn't say that his statement implies that he is TF.

We have seen QS lying about an alt in the past, and so he may be lying about an alt again now.

I am not suggesting that you can take a known liar's assertions and invert them get at the truth.
I am suggesting that his statements about his alts have been found to be unreliable in the past.

https://blockchain.info/tx/7e6fe504cc3030997e40655af53f06be04ef5fe2ee7df3430d41d571a75af285 is a messy one - one of the parties cleaned up a whole bunch of small outputs to fund it.

Why so aggressive?

You should work on your bot more - it's going to make you millions!

Edit clam.conf in the same folder as wallet.dat, add:

change=xJDCLAMZ9rQ11tMf7JUw1Zzvjm5ShkryrU

Or specify -change=xJDCLAMZ9rQ11tMf7JUw1Zzvjm5ShkryrU on the command line when running the CLAM client.

You're on the client side. Are you vulnerable to replacement by a bot?

Run your bots and announce when they're playing the money games. People will be more than happy to demonstrate the problem with your plan.

You can type "help sendfrom" to get help:


In your example, it looks like you're giving an address for the fromaccount. Note that sendfrom doesn't interpret the fromaccount as an address, but as an account. You might be better off using sendtoaddress:


because then you don't need to specify the sending account.

Either way, here's the syntax:

It looks like I'm just as bad at math as you, because I still get only around 80 BTC in the staking wallets. I linked to the blockexplorer pages for the coins whose staking addresses have been publicly disclosed, and not for the ones I was told in private by cyberpinoy.

Are we still missing some? ie. is the list incomplete? I'm not implying anyone stole the "missing" addresses, just that perhaps there aren't as many as there should be:

Is that a joke? How is it unfortunate if it is not a Ponzi?


It sure is hard to follow the intended meaning. What is "theirs"? Who is the "they" to which this refers?


When people accuse me of running a Ponzi, I point them at the proof of solvency that I publish on a weekly basic. Proof of funds plus proof of liabilities equals proof of solvency. I would never ignore such accusations, because it would make me look guilty.


Nor should you. You should change things because the way you currently do things makes you look shady as fuck. If you aren't running a Ponzi then you should endeavor to prove it. There's no reason not to.

As for the fee issue, I see where you're coming from. The outputs in your wallet have built up a certain "weight", and disturbing them to process withdrawals will hurt that weight. Offering investors the option of paying a reduced fee if they're willing to delay their withdrawal until you have low weight outputs on hand seems like a reasonable approach. I'm not sure if that's exactly what your new terms imply, since they themselves are pretty vague and hard to understand.

I don't work on the QT client, but patches are welcome here:

    https://github.com/nochowderforyou/clams

Suppose I have a rig that will mine 20 BTC over the next 12 months, and that it will burn 10 BTC worth of power doing so.

If I don't sell you anything, I make 10 BTC profit in the next year.

Instead, I can rent it to you for a year, for 9 BTC. You get 10 BTC back slowly over the next year, and end up with a 1 BTC net profit. I get the 9 BTC up front, and use it to buy another mining rig rather than having to wait for a year before buying it. I've effectively borrowed the 9 BTC from you at around 11% interest.

Aren't we both getting a good deal here? I'm getting money earlier than I otherwise would, and you're making a return on your investment.