Quote from: giszmo on June 29, 2013, 09:54:15 PM

Quote from: tomcollins on June 29, 2013, 08:35:56 PM

How do you avoid transaction malleability?

https://en.bitcoin.it/wiki/Transaction_Malleability

Does this not mean that even if you have a signed refund transaction, it is possible for the funding transaction to be changed, such that the refund transaction is now invalid?

Or is this just not a concern?

good point. While I'm slightly surprised to read about transaction signing not covering the whole transaction which sounds like a huge design flaw now, changing the hash sounds spooky to me, too.

It seems like it's something that is not likely to be a huge deal and you can only be spite exploited by it. Say your funding transaction gets modified for some reason and that changes its hash- it's not like the server can spend it all. It just makes your refund transaction invalid. So the money is stuck in a joint account until a new refund is created. The server could just laugh at you and you'd be out the money, but it doesn't seem like they get any real benefit out of it. They could hold it hostage in a malicious case, where they refuse to sign a new transaction unless you give them half or something similar, but that would wreck their reputation and likely you would prefer to have smaller transactions to the server anyway, and if it fills up, send another one.

Malleability of transactions seems annoying to me and prevents a lot of pure trust-less applications from being rock solid.

The poker application did sound interesting. However, I'm not sure it's practical to do this - any time the table composition changes, you need to have some kind of new funding transaction and finalize a refund to that player. The shared wallet would change due to different public keys, meaning you pretty much need to start from scratch every few minutes whenever someone leaves or joins (which can happen often in cash games). I suppose you could have a system where a central server that runs the game just sets up separate channels for each player. Whenever that person makes a bet, money is removed from the refund. You'd also likely have a "bank" that has another input (refund transaction takes an input from the player and one from the house, and the one from the house would have to equal the amount money each player has on the table up to what the player has). Whenever a player wins a hand, he gets money put into his account, and whenever he bets, it gets removed. Transactions are updated, and timestamped, and when he leaves the table, the transaction is finalized. This requires a significant amount of money for the server to put up, which seems suboptimal, but at least better than the alternative of having to keep submitting a transaction any time someone joins or leaves a table. I'm not sure this solves a problem better than having a site that just holds money for you. Then again, with hacking issues of some sites and seizure issues, this might be safer.