Why Nostr? What is Njump?
2023-09-09 08:58:15

dr.orlovsky on Nostr: Here is my line of thoughts on #BiFi. Of course, >10 min for confirming tx with just ...

Here is my line of thoughts on #BiFi.

Of course, >10 min for confirming tx with just dozen tx-per-sec throughput will not run financial system - as it can’t run money or payment system (not to mention lack of privacy/publicity, which is worse than in VISA/MC). Thus, #Bitcoin blockchain is a non-go.

There are just two approaches to solve the issue:
- build layers on top, providing scalability;
- replace layer one (get rid of blockchain).

1. Layers on top.

First, one can’t solve problems of blockchain by doing more blockchains. Thus, side/drive/crazy/*/chain-approach changes nothing in this regard. Yes, you can experiment with them or do some interesting stuff - but that is not our topic here.

Next, we have Lightning, Enigma and Ark. The last two require softfork to be trustless, so this is years - but I think they can be a solution.

Current Lightning (I call it Lightning BOLT, by the name of the current standards) fails with liquidity scaling - the infamous inbound liquidity problem. It also can’t route non-fungible state (not just NFT, but for instance bonds, which are usually non-fungible), thus for financial industry (but also for global payments) it will not work as it is.

The only way for making Lightning working is to build multi-peer channels, where no inbound liquidity problem is present, and where you can operate non-fungible state. This is the future #1 for #BiFi. I just discovered that there is a proposal on this matter, which may enable such future: multipeer Nucleus Lightning channels - https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230820/bfb41b20/attachment-0001.pdf Channel factories and other approaches are a bit worse: they either require softforks (like eltoo), require all peers to be online (thus poor sybil resistance and scalability) or less efficient in liquidity management.

Other ways - like fedimints - are trusted, thus it is not what we are interested in here (no benefit over trusted crypto DeFi like on Arbitrum or zk rollups).

2. Replacing blockchain.

The only proposal for that is #prime, but I expect more to come (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021732.html).

With prime, you do not need soft/hardforks, Lightning or anything else: it is quite simple to be built within a ~year (prime is simpler than bitcoin blockchain, all the business/verification is moved to RGB, which is already working).

The only problem with prime is that for $BTC one can move in - but not come back to Bitcoin blockchain in a trustless way. I do not see that as a problem at all (there will be those taking the risk, and the adoption will gradually build, with most of bitcoins eventually moving to the prime), but some hodlers are afraid. Well, I will leave them alone so they can push for their favorite soft-forks for enabling trustless pegouts: zk-opcodes, simplicity, some advanced schemata with CTV/APO etc - or drivechains, if they think that economically-incentivized miners can be trusted due to some Nash equilibriums. Anyway, I do not care on that part and the future of #BiFi on prime/RGB doesn’t depend on them: if bitcoiners will be slow to move to prime, those who were brave enough with moving BTC one way will have their BTC priced higher, leading more BTC to move there - and so on.

TL;DR:

Without softfork one can build #BiFi either with Nucleus multipeer Lightning channels (hard way) or on #prime (easy way).

With a softfork some Ark/Enigma/channel factories can also become an option - but a softfork will take >2 years and by that time we may either have prime or Nucleus.

PS: What’s Next

Those interested in designing & building #prime can join tech group by LNP/BP Association here: https://t.me/prime_layer1

LNP/BP Association https://www.lnp-bp.org is the non-profit leading #RGB, #prime, multipeer channels development, which needs grants/patrons for 2024

In https://pandoraprime.ch we are building products for the described #BiFi stack and are looking for VCs
Author Public Key
npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym