What happens in Long BTC transaction times

#1

What happens when an order is agreed on but the transaction takes longer than the allowed time to confirm? For example when the BTC network is congested a confirmation can take 10+ hours, but the trade has a timeout of 8 hours.

So when does BC consider the transaction done? after the transaction is broadcasted or after a certain number of confirmations?

1 Like
#2

Great question, for a start I think user should be given the info on how is the transaction confirmation time + fee is like at the moment by referencing to online dashboard similar to ethereum’s gas station, to estimate and make informed decision on how long they should set their transaction timeout. Or this functionality can be baked in the Borderless?

But bear in mind all of this are valid comcerns that will likely be detrimental to the end user experience, which should be tackled in the near future.

2 Likes
#3

Yep, obviously latency in trades is an issue. But this also reminds me of confirmation times for exchanges do not need to solely depend on the member chains. Perhaps the team imagines this could apply to the use of Borderless?

#4

Any new details on this question? I tried to search more about the confirmation times in BC how they are different then the main chains but I was not able to find any reading material that goes into detail on how this affects a trade or how they make BC trades more secure. Can the team provide more details ?

#5

One avenue to look at would be the scenario where three bitcoin confirmations are needed, but only two confirmations have occurred. I remember Patrick explaining this in his Blockchain Brad interview about a year ago. At the time, Patrick called it Greedy Stateful Data, where the data is always stored, so that the height of Block Collider’s chain may include the same BTC block references many times. However, these BTC block references may change. Let’s assume that the same BTC block is referenced in twenty consecutive Block Collider blocks. We can call this BTC Block A. But then, on the twenty first Block Collider block, another valid BTC block is referenced. We can call this BTC Block B. During a Borderless transaction, Block Collider may not necessarily have to wait for the Bitcoin network to confirm the most current block. Instead, Block Collider could require thirty five consecutive BTC Block A blocks (without a competing BTC Block B block) before it will allow a transaction to execute on Borderless. This could resolve the issue of waiting for the final BTC block to confirm, but wouldn’t resolve extreme network congestion on native chains.

This being said, there are probably a lot of details that I’m not aware of that should be answered by someone from BC Core.

1 Like
#6

It would still perhaps be an iffy proposition to some re confirmation times for btc, as some would wait 6 blocks.

The idea I think was linked to the growth of the network, and the fact that states of other chains are also progressing, thus giving more finality on the BC chain. If a reorg happened on one of the member chains, it’s still provable what occurred on the BC multichain. The implications of this is what we have to consider…

1 Like
#7

In response to the original question, this is a great point. There will definitely be a notification for average confirmation times and recommend fees to settle an order within the time. Lets say for example, the settle window is only an hour left and BTC is getting quite congested, we would inform both parties that the likelihood of settling on the BTC side will be slim.

3 Likes