Topic: Begginer's Doubt About Fork (Read 208 times)

I’m starting to get into the BW rules as I roleplay some more games, but I also encounter some difficulties in my path.

Well, the situation is the following: a group of tunnel-dweller wants to find it’s way through the tunnels and find the beast that they were searching for; then try to ambush it (or by some means have an advantage in positioning) and sneak to kill it. I ask them for a linked-test:

Orienteering + Tactics (vs. Observation) + Stealth (vs. Observation)

It would break down to:

Orienteering - Beginner’s Luck (Perception) + ForK + Help. I set the Ob 2 (night at familiar land), doubled it to 4 because of BL. So the player had: Per 4 + 1D (ForK) + 1D Help. The thing is, the ones helping didn’t have Orienteering but had Skills that could be used to help. So I imagined that BL only double the obstacle and didn’t negate the help.
Tactics - Almost the same. Beginner’s Luck (Perpcetion) + ForK + Linked Test Success + Help. It was a versus the beast Perception, so I couldn’t quite figure out how to do it. So it was: Per 4 + 1D Fork + 1D LT Success + 1D Help. This Help was totally my house-rule because none of them knew Tactics but all of them could help in some way. I just said that +1D would be enough. I know this is not written anywhere. And, they rolled against the beast and obviously won. What to do?
Steatlh - Again, Beginner’s Luck vs. Perception of the beast. Just said yes and didn’t ask for a roll and rolled a Steel test for the beast.

What’s the best way to deal with this?

The other question is handling a fight that everyone is involved. Following this scene, they sneaked and tried to kill it, but the beast didn’t die and engaged a Bloody Versus! with the guy down there (the rest were up in a bridge). My player’s wanted to help from distance, but I couldn’t also make a Range and Cover! because there was one guy too near. I wanted a more flexible system, where everyone would had a chance to do it’s actions in a space of time. I had to resolve the Versus! and then the other player’s actions.

Thanks!

Although, in practical sense, a lot of bitcoin services already do accept deposits on 0 confirmations. The common case here would be casinos, where deposits are instantly credited, as soon as the tx is detected in mempool. So even without the tx not in a stale branch, it is theoretically possible to attempt a douple-spend without a 51% attack.

Also, as pointed out several times and most recently by Antonopoulos, a successful 51% attack right now -- while economically unviable-- would immediately be marked out by the majority of network as a malicious attempt. And they would all anyway vote to reject the chain and return to previous state. It would cause some chaos and lost resources for most, but it would totally bankrupt the attacker (since his chain would be rejected anyway).

 

That is not quite correct. When the chain is re-orged, then all transactions in the stale blocks that aren't already in the new chain are returned to the mempool. The result is ultimately the same, but it is not necessary for the wallet to resubmit the transaction.

The double-spend happens when a transaction in the new chain invalidates a transaction that was previously confirmed in the stale branch, and the already confirmed transaction is rejected. In order to do that successfully, that attacker must be able to add blocks more quickly than the rest of the network so that they can force a re-org with a branch containing the double-spending transaction. Such an attack requires more than 50% of the total hash rate, and that is why it is called a 51% attack.

The way you explained suggest that I can double spend and create new BTC from that, but I understood, thanks.

When the chain forks, let suppose that the network followed the stronger chain. If some transaction in the stale block is not duplicated in the chain is it reversed?

If the fork extend to some number of blocks, is not clear to me if is possible (and if is easy) a node verify transactions considering two chains, so it make sense to revert transactions from stale blocks.