The risk of losing money is mainly the leakage of secret keys in memory. There have been vairous ways of protecting in-memory sensitive data. You can find a brief discussion on them in the Discussion section of VRF-based mining paper.

In the case of combining secret keys into mining, the cooperative mining is no longer a profitable choice. Instead, the equilibrium is that each miner mines by himself, even though reward is unstable. Let me elaborate here.
When mining takes secret keys as input, the pool will lose his secret key if outsourcing mining. When a miner gets the secret key of the pool operator, he can steal money hold by this secret key anonymously by various ways (e.g., via mixing services). In short, outsourcing enables miners to steal money anonymously.
Then, consider a game between two miners A and B. A and B do not trust each other, but they want to stabilise their mining reward by mining together. When mining takes secret keys as input, the game goes as follows. If both of them collaborate honestly, both get most reward, i.e., stable income. If A collaborates honestly but B behaves maliciously, B gets all mining reward. Vice versa for A behaving maliciously while B collaborating honestly. If A and B behave maliciously, they are basically solo mining.
Thus, the equilibrium for this system is that, each miner mines by himself and gives no chance for other miners to steal his mining reward.
In this way, even though mining reward is not stable, cooperative mining is a worse strategy than solo mining.

Regarding your solution, joining mining pools is still the best strategy for miners.
There is an optimal strategy for each miner. A miner can try first phase for lots of times until getting a small difficulty. The first phase can be run concurrently. A mining pool can spawn more concurrent executions of the first phase, so have more advantage on mining than solo mining. In this way, pooled mining is still profitable, and miners are still willing to join mining pools.

I doubt this claim. These protocols achieve non-outsourceable pow mining.

https://github.com/DEX-ware/vrf-mining/blob/master/paper/main.pdf
https://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/
http://soc1024.ece.illinois.edu/nonoutsourceable_full.pdf

Ah sorry I refer to wrong txids. Yes I mean tx3 (Bob htlc-pays Alice coins). Alice waiting for timelocks to expire is inevitable. There should always be someone initiating the swap. As long as the swap is timelock-based, the initiator Alice should wait until the participant Bob participates in the swap.

The problem is that, if Bob stalls (tx3), Alice should not pay the premium. Meanwhile, if Alice stalls (tx2), Alice should still pay the premium.
Neither combining premium into tx1-4 trivially or paying premium independently works.
If the premium is paid in tx1, then Alice does not need to pay premium if she stalls tx2. But she should have paid as she uses her option.
If the premium is paid in a separate transaction without any dependency with tx1-4, then Alice can choose not to commit the premium transaction.
If Alice is forced to pay premium, then Bob may stall tx3-4 while receiving premium. But he should not receive premium as he does not participate in swap at all.


@aliashraf

This is an interesting one, thanks!
Here is my analysis. It's a complex protocol, so please correct me if I'm wrong somewhere.
My understanding is that, this is still an American Call Option.
You refer this as "selling put option". Although Bob "asks for" Alice to do this, Alice is the one with option, and she pays for this option with premium.
Also, in this protocol, Alice pays premium using Bitcoin rather than altcoins.

So the key techniques here are:
- Premium transaction tx_p has two branches. One branch requires multisig, while the other has a long timelock and only requires Bob's signature.
- You couple tx_3 (Bob htlc-pays Alice BTC) with tx_p as follows. In tx_btc, you use premium (i.e., output of tx_p) as input. In this way, no one can commit tx_3 before committing tx_p.

As you mentioned, the first post does not work, as Bob can get premium for free by waiting for 7 days.
To prevent this, you further use a transaction tx_btc0 with BTC as both input and output. Bob should wait for 12 blocks if he wants to spend BTC elsewhere. The tx_btc0 output is also used in tx_btc.

Here are some issues I identified:
1. I'm not sure whether such a transaction with overlapped conditions is acceptable on Bitcoin. I'm also not sure how Bitcoin deals with chained timelocks, i.e., whether a htlc-ed output can be spent by another htlc-ed output. For example, what if both tx_btc and tx_btc0 are committed, but after 12 blocks (before 48 hours) Bob spends tx_btc0's output? Then tx_btc is no longer valid. I'm not sure how Bitcoin deals with this.
2. The timelocks need to be chosen in a very careful and proper way. If tx_p's timelock is too short, Bob gets premium for free. If tx_p's timelock is too long, Alice may not have enough time to redeem BTC in tx_btc. Also, why 7 days for tx_p? It can be much shorter. Maybe we can couple tx_p with tx_btc0/tx_btc?
3. The option's strike time should be re-considered. Alice's option may not be 48 hours anymore. It's more like 48 hours - 12 blocks or something more fine-grained.

I believe these two techniques can lead to some more succinct and straightforward constructions. This is quite interesting and I will think about it.

> What we would need is a mechanism that the TX3 transaction "as a whole" must be atomic as well - i.e. that Alice's input only could be spent by Bob if he signs his input. This is where I still struggle if this is possible with multisig scripting. I was imagining something like to realize TX3 as a 2-of-2 multisig transaction. Probably that involves some P2SH trickery.

Atomic Swap happens after order matching. tx1~2 have explicit sender and receiver. This gives Bob opportunity to withhold (tx2). This is different from real-world options.
Then, the key issue here is to enable the script (on Bob's blockchain) to distinguish between Alice's misbehaviour (e.g., withholding tx3) and Bob's misbehaviour (e.g., withholding tx2).
To this end, the script paying the premium should examine whether tx2 has been paid within its timelock. If paid, then it's the normal case and premium should be paid. If not after timelock, then Bob misbehaves and premium should not be paid.

To conclude, Bob's misbehaviour space requires the script to distinguish between Alice's and Bob's behaviour, which requires the script paying premium to know the status of tx2.

You should assume Alice is honest if using tx3 to pay for the premium. Alice can choose not to pay the premium in tx3. As you mentioned, Bob is "unadvantageous" at this moment, so cannot enforce Alice to pay for the premium in tx3 or punish Alice.

Hi, my user name is elvisage.
I'd like to edit some content about Atomic Swap. I'll appreciate to be an editor.

Thanks