<center>![atomicswaps.jpeg](https://files.peakd.com/file/peakd-hive/edicted/QqPGRhCi-atomic-swaps.jpeg)
</center>

As stated in [part 1,](https://peakd.com/pob/@edicted/pob-part-1-distributed-proxy-nodes) a huge reason why HiveEngine cannot migrate to a decentralized network is due to all the Hive for the peg being centralized to a single account to easily manage the HiveEngine "DEX".  Wouldn't it be nice if we could decentralize this process and not store all that Hive in the same place.  Ideally, this would increase security and trust in the system while also providing more liquidity.  The trick is keeping the logistics efficient and protecting against potentially new attack vectors. 

# That's where Atomic Swaps come in. 
Wouldn't it be nice if we could just trade assets with each other without having to rely on a centralized authority?  The entire purpose of atomic swap tech is to do just that.  They are the foundation of DEXchanges.  Luckily, I think Hive is in  prime positioning to take a few shortcuts to get the job done and develop from a solid foundation of stepping stones. 

<center>![baby stepping stones fix steem.png](https://files.peakd.com/file/peakd-hive/edicted/7VpNdj8H-baby20stepping20stones20fix20steem.png)
</center>

# Shortcuts
The DPOS consensus layer itself is a shortcut that sacrifices security (decentralization) for scalability.  Logistics become much easier on Hive because we decide which node is going to produce a block in advance. 

#### Think about it this way:
Look at the Bitcoin network.  When someone wants to send Bitcoin to another wallet what happens logistically?  That operation is signed by a private key to create a public transaction that is safe to share with the entire world.  We all know this, but what happens to that signed public transaction afterwards?  

Well, as stated, after signing with the private key, it becomes safe to share, so it is in turn shared with the entire Bitcoin network.  Every node needs to know about every transaction, so all the nodes start sharing them with each other.  

This is one of the big reasons no one can use a public transaction to double spend; nodes simply assume they got the same information more than once and ignore it (because that's exactly what happened). 

-----

#### Because the Bitcoin network has no idea who's going to win the hash lottery and post the next block, all the information must be shared. 

-----

<center>![code_wave_tsunamiabsorbbitcoin.jpg](https://files.peakd.com/file/peakd-hive/edicted/QdmHdSuJ-code_wave_tsunami-absorb-bitcoin.jpg)
</center>

#### So what happens on the Hive network? 
Say I sign a transaction and connect to @anyx's node to broadcast it.  What happens then?  Well, @anyx's node knows exactly which node is posting the next block.  Rather than having to share that information with the entire network, he simply has to send it to the single node that's scheduled to produce the next block.  This makes everything much more efficient, especially if it was @anyx's node that was going to post the next block.

# What's the point? 
The point is that Hive is a much more efficient network than many many of the other ones out there.  We can capitalize on these efficiency shortcuts to implement tech like atomic swaps much faster than the "competition". 

<center>![whatareatomicswaps.jpg](https://files.peakd.com/file/peakd-hive/edicted/sZg57W7j-what-are-atomic-swaps.jpg)
</center>

Atomic swaps hinge on tech called time-lock smart-contracts.  Essentially, you'd send Bitcoin to an address but lock it up in one of these contracts.  If the transaction on the other chain fell through the Bitcoin you sent would get bounced back. 

I think Hive can completely sidestep this these contracts and build a shortcut directly into the consensus layer that would enable atomic swaps.  Imagine creating a contract in advance on Hive that says something like, "If any Bitcoin enters this address, send the proportional amount of Hive to the account specified."  

-----

#### Honestly, the more I think about it, the more it seems that atomic swaps to Bitcoin (any many others) could actually be very easy to implement on Hive. 

----

I feel like the most pertinent problem regarding this whole situation is the fact that the witnesses would have to agree to implement it.  Not only would it require a hardfork, but it would also start requiring witness nodes to acquire information on the chains we are providing atomic swaps to.  If we tried to implement atomic swaps to a dozen different chains, that kind of bloating on the Hive witness nodes might be unacceptable to a lot of devs. 

However, again, this is where shortcuts come in.  Hive is very good at taking these scalability shortcuts.  If we enabled atomic swaps to Bitcoin, some witnesses would start running their own Bitcoin nodes and connecting it to their Hive nodes. However, some witnesses could simply get the information they needed from other 3rd parties and simply trust it was accurate (further sacrificing security for efficiency).  If done correctly, these shortcuts would provide more benefit than the implied risks.  

<center>![new steemit tech.jpg](https://files.peakd.com/file/peakd-hive/edicted/IqYI1FSN-new20steemit20tech.jpg)
</center>

# Ultimate shortcut: Pseudo Atomic Swaps
All of the above assumes that the witnesses actually agreed to hardfork the chain and implement atomic swaps.  What do we do in the meantime?  I believe we can take an even bigger shortcut that does not require permission from the witnesses. 

##### [We can thank Steemit Inc for creating Escrow services in HF14!](https://peakd.com/escrow/@edicted/hive-goldmine-looking-at-escrow-services)
Honestly Steemit Inc really did a lot of work that this network fully took for granted or even downright ignored.  Escrow services are an example of an extremely powerful technology that seems to be completely ignored. 

# Escrow smart-contracts
Hive already has its own version of centralized time-locked contracts, and escrow services are it!  By centralizing the final authority to a single escrow account, we can prototype pseudo atomic swaps (and much much more). 

# Example
You want to trade Hive for Bitcoin.  You create an escrow smart-contract and send the Hive to an account that promises to pay you Bitcoin.  When you get the Bitcoin you unlock the money to the account that paid you.  If you don't unlock the money the Escrow account is called in to make the right decision and release the funds.  Accounts that try to cheat the system may be charged a fee and/or lose reputation.

# Disadvantages:
As already stated, the disadvantage of pseudo atomic-swaps via escrow contracts is that they put a single account in charge if a dispute arises.  However, anyone can choose their own trusted source to be the neutral arbiter, so in that sense it is more decentralized than a lot of the other options out there. 

Another big disadvantage of pseudo atomic swaps is that you have to predefine the account sending Bitcoin in advance.  The first example I gave (where atomic-swaps were implemented by the witnesses) we can require the account that sends Bitcoin to specify their Hive account.  With Escrow you have to define both accounts in advance and for how much while locking funds in escrow. 

# Conclusion
I feel like I don't have to explain why atomic swaps to Bitcoin would be absolutely huge for the Hive network.  It would get the attention of the entire cryptoshpere and likely pump the coin pretty fiercely.   Hopefully we can start small and make these permissionless pseudo atomic-swaps first and build from there.  

This could be the foundation of an entirely new way of trading assets in a more decentralized manner.  Cut out the middle man. Tokens on the Hive blockchain will not gain traction without a more decentralized way of managing them.  This includes SMT, HiveEngine, and potential proof-of-burn tokens.  All roads lead to Rome (what an inappropriately centralized metaphor).