The way IDs are determined about sia HOT 6 CLOSED

Further investigation makes it seem important that the hash of the transaction be included when determining output ids. Right now, different transactions could result in the same outputID, which means that someone spending an output could create signatures that are valid for transactions that they perhaps didn't mean to sign.

It means that you could reorganize the blockchain and change who sent someone coins, but the act of spending those coins is still valid. Example:

Chain 1: miner A has coins of OutputID a, sends them to Bob, resulting id is b. Sends them to Charlie, resulting id is c. Charlie signs something that spends the coins he received, sending them to Chuck.
Chain 2: miner A has coins of OutputID a, sends them to Bill, resulting id is still b. Bill sends them to Charlie, resulting id is c. Charlie's signature spending the coins is still valid, so Chuck can spend the coins without Charlie's consent, even though Charlie has potentially received the coins from a different person.

This attack is weirdness, and I feel like there are some subtle problems with leaving it possible.

from sia.

So, I've implemented it such that the output id includes the hash of the transaction that announced it. That's all fancy for transactions, but I've left a quirk in the contracts, which I'm probably also going to change, but not entirely sold that it's a necessary change.

A contract output has the same ID regardless of where the money is sent. So the output id for window_i is going to be the same, regardless of whether the address in the output is the host's address or the client's address. This should also be changed.

from sia.

fxd

from sia.

should probably reference the commit that fixed it. Or mention "fixes 32" in the commit message. I frequently forget to do that though.

from sia.

hmm. It's really implemented in the whole pull request. #40

from sia.

In that case I should mention it in the merge commit. Whatevs

from sia.