outputs aren't being rejoined properly? about clams

[dooglus]

Now I get it.

This part of the code:

pcoin.first->GetHash() != txNew.vin[0].prevout.hash

prevents two outputs from the same transaction from being merged together.

The intention of the code is probably to prevent adding in the output that is being staked. If we check the output index number as well as the transaction hash, this will be fixed.

[dooglus]

Fixed in #22.

[ClamProject]

I am sure I am mistaken, but it looks a bit like this line of code was specifically designed to prevent what you are enabling..?

Under what circumstances would it be desirable to recombine outputs belonging to the same hash?

When would two outputs, from the same transaction, appear?

• The Client previously decided to 'split' the output.
• A user purposefully splits outputs directing them to the same address in the same tx (I believe this may be checked against).

Reasons NOT to recombine outputs with the same hash:

• If the client split them in a previous stake (and our split code is fixed to work properly), presumably there was a reason and the intention is to keep them split.
• If a user split them on purpose, recombining them is counter-productive, as well.

[dooglus]

You may be right as to the original intention of the code. It's impossible to tell in the absence of comments or other design documentation whether that line is doing what was intended or not.

My guess was that the intent of the code was to check whether the current iteration through the loop is looking at the output which just staked, and if so, to ignore it, which is what my modification makes it do. I could be wrong with my guess.

If the client split them in a previous stake (and our split code is fixed to work properly), presumably there was a reason and the intention is to keep them split.

I'm thinking the client split them because they were staking too fast. Later on, as the difficulty increases, maybe they start staking too slowly, and so need recombining.

Consider the case where I have two outputs (A and B) of 6 CLAMs each, at the same address.

A gets split into Ax and Ay. B gets split into Bx and By.

Ax, Ay, Bx, By are all 3 CLAMs each, all at the same address.

Ax can combine with Bx or By but not with Ay.

Where's the sense in that?

Given the current code, Ax will combine with Bx and By, making Cx (9 CLAMs), and the next time it stakes, Cx will combine with Ay, making a single 12 CLAM output. So the end result is the same, but it takes an extra step.

With my modification, Ax will combine with all 3 of the other 3 CLAM outputs giving a single 12 CLAM output immediately (subject to thresholds, etc).

It just seems neater to treat all outputs as equal, whether they're from the same transaction or not.

Actually, why do we even care what address they're at? If I have two tiny outputs at different addresses and one of them is lucky enough to stake, why not combine the two tiny outputs into a less tiny one so that they have a decent chance of staking again sometime?

Maybe it's useful for accounting purposes. If I'm running a wallet site, say, maybe I choose to keep each user's deposit in their own address so I can keep track of how their coins stake, and merging across addresses would mess that up.

[ClamProject]

I think your comment about 'wallet services' is apt. Unfortunately, you can't enforce proper design that doesn't rely on 'accounts' and per address accounting.

In the end, I think your logic is sound.

Assuming a loop condition with splitting and recombining can be avoided, and a reasonable split/combine threshold can be implemented via some difficulty/output size magic: I agree with the change.