Thread by @librehash

1/ Polkadot is a really well-designed project with some extremely smart folks at the helm - but their plan for interoperability with Bitcoin won't work for a few reasons that will be explained in detail within this thread. #Polkadot $DOT #Parity

2/ Documentation on the proposed 'bridges' for $DOT can be found here = wiki.polkadot.network/docs/en/learn-…

This is where the 'XClaim' protocol is introduced.

2a/ One major setback stopping this from being trustless from the jump is the fact that Polkadot does not use Proof of Work (that is necessary) - but even putting this to the side, there are critical elements missing.

3/ Attached to this tweet is an illustration of how #Polkadot proposes to implement its parachain appendage for Bitcoin

3a/ In short, BTC is supposed to be sent from the bitcoin blockchain, 'locked' in a "vault", then have the TX confirmed by a 'relay chain', after which the equivalent (1:1) # of 'PolkaBTC' will be minted.

Redemptions 'burn' PolkaBTC

4/ First issue here is with the concept of validating the TX on $BTC #Bitcoin ; the only way this can be done is if the $DOT nodes are running *full nodes* for Bitcoin (only way to validate in a trustless manner)

4a/ One may argue for using an SPV instead (like Electrum), but the issue with this is that bitcoins are being *generated* on $DOT's blockchain, so it is imperative that this be *trustless*, which means the TX must be fully validated.

4b/ Additionally there is no logic stated in the documentation for how they will prove transaction X belongs to person Y attempting to mint PolkaBTC with them (cont)

4c/ This is something that can prove tricky because some TXs involve more than one input as the attached graphics show.

After TX is sent, there's no way to tell how much of an input was used in the TX.

Therefore, $DOT needs to stipulate 1-inputs TXs only.

5/ Next problem we have here are the "locking" of bitcoins. It makes sense how $DOT proposes to credit them on their chain (issues detailed above) - they want to validate a TX was made on Bitcoin before crediting the PolkaBTC.

5a/ The problem with that though is there must be a way to stop that user from moving those bitcoins after they're validated. Obv. $DOT's solution is to "lock" them, but they don't state *how*

5b/ Answer was searched for everywhere.

Starting with the Git repo: github.com/interlay/BTC-P…

Following the order of the photos below, we eventually ended up at the specification here: interlay.gitlab.io/polkabtc-spec/…

5c/ However, even the specs offer little to no guidance on exactly *how* this locking mechanism would work

Attached are all excerpts we cold find related to that

6/ Another problem is that the punishment-fee proposal for vaults is impossible to implement.

Specifically, they call for vaults to be punished for not meeting a time restriction.

Ironically what makes this impossible is a decentralized network

6a/ $DOT uses Substrate - which is wholly separate than $DOT

The attached image from Parity's site: parity.io/what-is-substr…

6b/ So we know $DOT uses Substrate...we just need to find how their network architecture is designed

Which appears to be through libp2p (same library ipfs uses)

source = parity.io/substrate-in-a…

6c/ As expected, libp2p uses the gossip protocol to relay messages to other nodes on the network

source: docs.libp2p.io/concepts/publi…

This design makes a time-based punishment setup *impossible*.

6d/ Essentially you have a setup like you see in the attached pictures here.

There's no way for any node to really know when the time should have *started* as they don't know which was first / last / how much the entire network knows or knew.

7/ Using smart contract as the vault "lockups" are wholly unacceptable as well because *any* external custodian violates the trustless principle. There are no 3rdparty custodians in Bitcoin

8/ One thing that bugged me was the fact that there's a provision for "collateralization" in this scheme. Why?

This is supposed to be an actual *swap*.

Collateral is only necessary when trust is involved.

9/ And if you're wondering, yes, $DOT stated that this bridge solution would be trustless.

(re-attached to jog anyone's memory that forgot)