What are the technical obstacles that Bitcoin has to overcome in the next decade

[elliottflz65]

I have been studying Computer Science at College which has taken over my life for the last two years. I have been tasked with a essay that will be the last one I have to write which I am allowed to pick any subject and I have picked Bitcoin. I thought that an interesting topic would be the obstacles that Bitcoin has overcome which I have mostly written and then I thought adding some of the obstacles that Bitcoin has yet to face and might take the collective minds to figure out.

What do you think will be the biggest technical obstacles faced in the next decade?

[1714630199]

1714630199

[1714630199]

1714630199

[1714630199]

1714630199

[1714630199]

1714630199

[NotATether]

You probably mean "obstacles to be tackled within the next decade" 

Well, we clearly need to standardize how our Layer-2 transactions system works (lightning network), since at the rate the price is going in the long term, fees will be too high in USD value for smaller transactions. Eltoo is a nice step towards that direction but it's clear that standardization won't happen with a bunch of completing LN clients being maintained, the only way I can see a set of LN internals being cemented for good is if they're merged into Bitcoin Core itself. Not the protocol, just the client.

To do that we need to invent a way to make scripts with complex rules, what you folks call "smart contracts". Bitcoin Script is too simple to make something like this, as I wrote about in another post.

Normally you'd think about using a general-purpose language such as e.g. Lisp (or even C, but I think that's too big) and then your scripting engine evaluates the commands to do algorithms that you would otherwise be able to do in "grownup" programming languages.


For an example of the above, there is a need for a method to make two parties "bind", or agree, to a particular transaction that one will send to another, and not to send other transactions that haven't been agreed upon. This logic would be too large to fit in a Bitcoin transaction at a reasonable size, and too complex to do in Bitcoin Script anyway. So it will need its own protocol and network of nodes that specifically understand, and speak, this logic. And what can already be done today, is broadcasting the final state to bitcoin's blockchain (and a "sentinel" initial state that proves there's an L2 contract in place). This is the basics of how LN channels work.


The challenge is that the scripts must not be too large or they won't fit inside blocks and/or will cause transactions to be too big to include many of them in a block at the same time, which will congest the network. However, this is usually what happens when you're using such languages (unless you choose one that can be translated to "bytecode" similar to the one Bitcoin Script reads, e.g. something like Java but way smaller).

There are two solutions to this problem. One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.

The other solution is to somehow offload this logic to another protocol, and just broadcast a final result, and proof that there's a contract happening, like in the above example. And this is what devs are currently trying to do.


Now after all that is done, there's the additional problem of getting most people to use LN. User adoption is fairly slow and cannot be sped up, and obviously, not everyone is going to use LN. Even today some exchanges and users are still using legacy addresses. So naturally, LN will be subject to this adoption rate as well. This is where exchanges supporting LN and mass media promotion of LN will be useful.

[ABCbits]

What do you think will be the biggest technical obstacles faced in the next decade?

Obviously it's scaling bitcoin for mass/global adaption. Based on network, there are 3, which are on-chain (Bitcoin), side-chain (such as Liquid and RSK) and off-chain/2nd-layer (such as LN). For on-chain scaling, it's mainly about reducing transaction size, transaction batching and faster verification.
1. Taproot already locked-in and it's just matter of time before it's activated. However, Taproot only has noticeable impact with complex script and multiple keys/signature.
2. Using more efficient transaction serialization to reduce transaction size. See Did you know bitcoin uses 6 different ways to represent integers.
3. Mimble Wimble which perform transaction batching and improve privacy. But AFAIK it's difficult to implement Mimble Wimble without sacrifice it's privacy property.

One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.

And increase block size also involve social (and even politic) problem.

[fresheneesz]

These are the kinds of obstacles I see for bitcoin in the next 10 years:

* Scaling
 * There are various bottlenecks to increasing bitcoin's blocksize, and a number of ideas for how to loosen those bottlenecks.
 * Layer 2 networks like lightning will continue to be developed and gain adoption.

* Education and Tooling
 * Coin storage education - How will most people store their coins? How will your grandma store her bitcoin? How do we teach people what is a safe way to store their bitcoin and what is not? This includes procedures for how to create and use bitcoin wallets, improved tools and services for key storage and recovery, and education around the risks of various solutions that are out there. Perhaps the community should embrace and collaborate on some wallet guides to educate people.
 * Collaborative custody tools and services. Companies like Unchained Capital and Casa are working on this kind of thing, but standards are needed and the complexity needs to come down a lot and the accessibility needs to come up.
 * Wallet vaults can massively improve the security and ease of use of cold wallets. However covenants are needed, which will require one or more new Script opcodes (eg these ones).

* Governance
 * The Bitcoin community will likely continue have debates about how to make changes to the protocol and hopefully we can converege on a sustainable mechanism that is used for more than one or two updates before being discarded (like previous methods).

* Political and legal challenges
 * As adoption reaches significant levels, its likely there will be a lot more tension in some countries around Bitcion. Some countries will embrace it, some will try to reject it by proposing and/or passing various laws.
 * Existing laws that make bitcoin hard to use (legally) in some countries will hopefully be reformed (eg the tax implications of every-day-sized transactions in the US).  
 * Mining - The amount of electricity and capital eaten up by bitcoin mining will only rise further in the next 10 years while the price is still rising faster than the coinbase reward halvings are reducing the mining rewards. The drama here will only increase, as will the pressure from people who want Bitcoin to adopt a proof of state consensus mechanism. The challenge here is doing the right thing and not caving to pressure and rushing out half-baked solutions. Perhaps the community will eventually decide a PoS consensus protocol is safe and beneficial, but we shouldn't rush to make that decision based on pressure from virtue signalers.

[kxwhalexk]

To achieve deeper application and popularization, scalability is essential.
There are probably the following solutions：
1）SideChains
Its definition is: a protocol that allows Bitcoin to be safely transferred from the Bitcoin main chain to other blockchains, and can be safely returned to the Bitcoin main chain from other blockchains.

2）Sharding
In fact, it is a traditional database technology that divides large databases into smaller, faster, and easier-to-manage parts.However, it will be quite complicated when applied to the blockchain.

If the side chain is "externally grafted" to the main chain, then sharding is to "internally split" the main chain. Obviously the latter is more difficult to implement than the former.

3）Directed Acyclic Graph
This is a graph structure with vertices and edges. It can guarantee to go from a vertex along several edges (directed), but it can never return to the origin (acyclic).

4）Sub Chain
If you consider the ecology of MOAC, it is like a GitHub for development, then the sub-chains can be turned into functional libraries, so that the sub-chains can be shared with each other. The various service-providing sub-chains must be subdivided into roles due to different services.

[amishmanish]

--snip--
There are two solutions to this problem. One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.

This is pretty interesting to know that the next set of challenges that LN will face is related to the need for complex scripts and the need for Bitcoin to find a way to accommodate this. Now, all this talk about Smart contract language for Bitcoin is a bit esoteric from my viewpoint but didn't a bunch of developers propose a scripting language change to achieve specifically this? It was called Simplicity and I could never go beyond the video where the developer is showing the Half-adder implemented in Simplicity.

What is the current state of development with Simplicity? Did it not prove useful in being the smart-contract solution? Once you answer a few questions, I promise I'll do some research on my own too. Thanks for this.

To answer the OP, I don't understand why nobody has pointed this out yet, but one of the challenges I feel is for the mining incentive to continue to remain lucrative to ensure the hashrate that we see today. In two decades, it'll halve twice. The state of the fee-market by that time and price of BTC will be the factors to decide whether it is lucrative enough for miners providing security to the chain.

[franky1]

But is it really technical obstacles? Few obvious option (such as increasing block reward and setting minimum transaction fee) has always been possible.

increasing the blockreward is not been a viable option
on a technical level its not hard
but the economical/political/algo promise bases.. it breaks the moral rules

bitcoin was designed from day one to release 5000000000sats every block and half every 210k blocks. leading to a moral/economic rule of total circulation limit of 2100000000000000sats
changing this breaks the moral economic code of limited supply

doesnt matter if its changing the smallest unit of measure into even smallest sharable units of measure or changing it to produce more current measures. both have been ruled out as viable options due to the scarcity promise of limited supply

Don't forget on-chain transaction quantity.

yes this is the key method forward. it then allows more utility.
at the moment 2500tx only allows for 360000 people to make one transaction a day if uniformly and fairly used by everyone

but to also help with the equal share or chance to get a 'slot' the transaction fee desperately needs a fee formulae..
not the current rule where
segwit pays ~same sat/weight
legacy pays ~same sat/weight*4

but where the utxo's age becomes a consideration.
where by spammers pay more than infrequent users. deterring spammers.. thus not turning the blocks into spam blocks leaving random users bottlenecked paying higher to compete

for instance right now its possible and does not break any consensus or morals
to change the fee policy to not care the ethic hereditary of a transaction(legacy or segwit) but instead just count the utxo blockheight vs current blockheight at new transaction creation/broadcast. and give anyone spending under 72block(half a day) a 4X premium
or more creatively set 1confirm as 144x and descend down to 1x if coin over 144 confirms

[BlackHatCoiner]

both have been ruled out as viable options due to the scarcity promise of limited supply

Where's the scarcity promise? Would you mind sharing a link? I know that whether we had 8 or 18 digits, we'd still never exceed the 21,000,000 BTC; isn't that what matters? Even if it can be divided, how would that affect the Bitcoin or the people's wealths?

I think that Satoshi made it pretty clear that we could extend its decimal places in the future. There's no reason, at the moment, though. You can't send less than 547 sats, so it'd be ironic to upgrade to 12 places.

[ranochigo]

To answer the OP, I don't understand why nobody has pointed this out yet, but one of the challenges I feel is for the mining incentive to continue to remain lucrative to ensure the hashrate that we see today.

You don't need for mining to maintain the same hashrate as today. The system works if it is more profitable to be an honest miner than to use their equipment to attack Bitcoin. The problem arises only if that condition is not fulfilled.

In two decades, it'll halve twice. The state of the fee-market by that time and price of BTC will be the factors to decide whether it is lucrative enough for miners providing security to the chain.

Once every ~4 years, so it'll be 5 halvings. Those are not the only factors; you have to include the potential for any on-chain capacity growth as well. I'd say this isn't an issue that Bitcoin really faces, you do have sufficient cushioning from rapid decrease in block rewards; decreases substantially at the start but then the fees gradually forms a greater composition of the revenue.

[ndalliard]

both have been ruled out as viable options due to the scarcity promise of limited supply

Where's the scarcity promise? Would you mind sharing a link? I know that whether we had 8 or 18 digits, we'd still never exceed the 21,000,000 BTC; isn't that what matters? Even if it can be divided, how would that affect the Bitcoin or the people's wealths?

I think that Satoshi made it pretty clear that we could extend its decimal places in the future. There's no reason, at the moment, though. You can't send less than 547 sats, so it'd be ironic to upgrade to 12 places.

franky1 is a "troll" and has a hard time to provide anything of substance (see for example here). i agree with you, that adding more digits is not a technical obstacle and also would not change the scarcity of bitcoin

[franky1]

both have been ruled out as viable options due to the scarcity promise of limited supply

Where's the scarcity promise? Would you mind sharing a link? I know that whether we had 8 or 18 digits, we'd still never exceed the 21,000,000 BTC; isn't that what matters? Even if it can be divided, how would that affect the Bitcoin or the people's wealths?

I think that Satoshi made it pretty clear that we could extend its decimal places in the future. There's no reason, at the moment, though. You can't send less than 547 sats, so it'd be ironic to upgrade to 12 places.

maybe if you discover the words sharable units. and understand scarcity in regards to shares of units.
you will understand what scarcity is

btc at code level does not exist. you will not find any btc in any raw transaction data. no btc on the blockchain.
its all measured in sats..
always have been

the measures known as bits(100sat) millibits(10000sats(0.001btc) and btc are just graphic multiplication on the user display for easy human reading

knowing that there has been a hard rule of sats.. and a human construct multiplication of btc
is the same as the '10min block' thing in reality being 2016 blocks a fortnight hard rule not a 10min rule

but thats the symantecs debate

the economic rule is limited satoshi supply where breaking up satoshis into even more units that can be shared. is making it less scarce. because more people get a slice

it then becomes that bitcoin is not 100,000,000x of the smallest unit of measure basket term
but then becomes a basket term for even more sharable units
emphasis of sharable units

[ndalliard]

the economic rule is limited satoshi supply and breaking up satoshis into even more units that can be shared. is making it less scarce. because more people get a slice

i probably shouldn't engage with you, but what you say here is wrong. you mean it gets more accessible, but it doesn't get less scarce

[franky1]

the economic rule is limited satoshi supply and breaking up satoshis into even more units that can be shared. is making it less scarce. because more people get a slice

i probably shouldn't engage with you, but what you say here is wrong. you mean it gets more accessible, but it doesn't get less scarce

you have precisely by your own admission only a few weeks knowledge on topics like LN
i know you have joined the promotion of alternate network hype gang of utopian overpromises

but take a step back and realise people want to know about flaws and issues.. and not just be pumped with hype and dreams

yes i dont give kiss-ass hugging messages of hope. but atleast look passed the tone of my messages that fluffy dreamers hate and realise the actual reality of the situations i talk about

oh
and 21m btc is not a hard rule
20,999,999,999,xxx sats is the hard rule of limited supply
if you think its about 'btc' then do try and i mean this really try to find a raw transaction in the blockchain whos output value is "1" where 1 represents a btc
.. heck ill be nice to you,.. there isnt any

if your here to make friends and create a social culture divide.. fine, thats your business
im here because i care about bitcoin(not other network)

(sorry to other readers for the social drama of the altnet hypers)

in short
if its easier to share.. then its not hard to get

gold is not scarce.. everyone on this forum has gold. its in the device your reading this message in right now.
easy to find easy to get

[BlackHatCoiner]

franky1 is a "troll" and has a hard time to provide anything of substance (see for example here). i agree with you, that adding more digits is not a technical obstacle and also would not change the scarcity of bitcoin

I know who's franky1, but I'd discourage anyone from having an disagreement with him, just like you do. There's just not a point, it is completely meaningless to discuss for over a post with him.

maybe if you discover the words sharable units. and understand scarcity in regards to shares of units.

Alright, scarcity definition:  A situation in which something is not easy to find or get. It doesn't matter if that something becomes easier in terms of sharing, or if the digits of its unit can is extended. That is your assumption.

[gmaxwell]

In this thread: https://www.youtube.com/watch?v=YtLEWVu815o

FWIW, lightning already lets you use smaller amounts.

[franky1]

FWIW, lightning already lets you use smaller amounts.

(sarcasm)dont say that the LN utopian fluff PR guys have been beating me left and right trying to say that everything in LN is the same as bitcoin and spreading vile that im talking nonsense about how LN uses different units of measure that bitcoin cannot accept..
if you continue revealing that LN is different to bitcoin with its own separate units of measure, they will abandon you as their worship leader and call you a LN heretic

so maybe whisper it next time or they will hate you too
(/sarcasm)

maybe their anger and claims of misinformation is that i claim its 12 decimals when they want to be anal and say its 11 (pico minus 1). yet they miss the point entirely that its more then 8, thus not bitcoin compatible

anyway.. after Gmax's shameless plug of another network (standard poke to avoid solving bitcoin issues)
lets draw the topic back to bitcoin issues.

the main one seems to be what is being promoted as a technical problem.. getting the byzantine generals to agree on a bitcoin evolution
though digging deeper. its more political than technical.

first coercing the main merchants(generals) to change or their transactions will be more expensive.. so merchants follow pools and ripple effects onto users(cadet) that want to use merchants, so follow too.

next coercing pools to change unless have their blocks rejected by merchants. again ripple effects pools follow and users follow.

but before the political game even begins. trying to convince the core devs to implement some change. is the bigger political game. because if they decline to release a code change in their implementation. it aint going to happen. any 'forked github' of bitcoin software by default is always treated with opposition. even if it has no intention of forking the chain

[elliottflz65]

Normally you'd think about using a general-purpose language such as e.g. Lisp (or even C, but I think that's too big) and then your scripting engine evaluates the commands to do algorithms that you would otherwise be able to do in "grownup" programming languages.

What do you mean by C being too big? Do you want a language which is easy to pick up and is a higher level language? Would Python be an option since its probably one of the easiest languages to learn. I do not know enough about Lisp to comment.

[titular]

What do you think will be the biggest technical obstacles faced in the next decade?

Obviously it's scaling bitcoin for mass/global adaption. Based on network, there are 3, which are on-chain (Bitcoin), side-chain (such as Liquid and RSK) and off-chain/2nd-layer (such as LN). For on-chain scaling, it's mainly about reducing transaction size, transaction batching and faster verification.
1. Taproot already locked-in and it's just matter of time before it's activated. However, Taproot only has noticeable impact with complex script and multiple keys/signature.
2. Using more efficient transaction serialization to reduce transaction size. See Did you know bitcoin uses 6 different ways to represent integers.
3. Mimble Wimble which perform transaction batching and improve privacy. But AFAIK it's difficult to implement Mimble Wimble without sacrifice it's privacy property.

One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.

And increase block size also involve social (and even politic) problem.

Do you think adding Mimble Wimble will bring negative press such as that with XMR. Mimble Wimble in my opinion is will be unnecessary for a while. I'm not insinuating exchanges will delist Bitcoin (lmao) but wouldn't adding Mimble Wimble not be entirely good?

[titular]

--snip--
There are two solutions to this problem. One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.

This is pretty interesting to know that the next set of challenges that LN will face is related to the need for complex scripts and the need for Bitcoin to find a way to accommodate this. Now, all this talk about Smart contract language for Bitcoin is a bit esoteric from my viewpoint but didn't a bunch of developers propose a scripting language change to achieve specifically this? It was called Simplicity and I could never go beyond the video where the developer is showing the Half-adder implemented in Simplicity.

What is the current state of development with Simplicity? Did it not prove useful in being the smart-contract solution? Once you answer a few questions, I promise I'll do some research on my own too. Thanks for this.

To answer the OP, I don't understand why nobody has pointed this out yet, but one of the challenges I feel is for the mining incentive to continue to remain lucrative to ensure the hashrate that we see today. In two decades, it'll halve twice. The state of the fee-market by that time and price of BTC will be the factors to decide whether it is lucrative enough for miners providing security to the chain.

Why is it a concern what the mining block reward will be? By the next halving, Bitcoin will have gone much higher in price, thus making mining still worthwhile. While the amount of Bitcoin you receive per block mined will go down, this doesn't mean the dollar amount per block will.

[vjudeu]

Aside from difficulty technical implementation

It's not that hard. I can imagine a new Segwit address type for Pedersen Commitments, where you will have such commitment instead of typical ECDSA signature or typical Schnorr signature. Pedersen Commitments are based on public keys, if some script types should be based on something else, then that could be solved as in taproot: by creating some public key and tweaking that with the hash of the script. So: each input and output could be expressed as a public key in some unique way, as in taproot. Then, all that public keys could be used to form Pedersen Commitment of a transaction, which will allow to join matching transactions without invalidating that commitments. Maybe it is even possible to extend tapscript to cover that, if so, then we would have better privacy, because of less address types involved.

there would be problem such as proving your transaction

Why? If you can join transactions and if the recipient never spent that coins, then it will see its outputs in the final transaction. On the other hand, if the recipient saw its outputs in a mempool and decided to spend them right away, before reaching first confirmation, then that recipient knows that finally its address will not be included in the blockchain. The recipient could pretend that the coins were never sent, but then the sender could reveal sending transaction before joining, and by having that two transactions, it would be possible to construct another valid and signed transaction with recipient's address being spent and send to the final address (directly or indirectly, because if any two matching transactions can be joined, then having full list of recipients and senders require observing mempool 24/7 and catching all transactions in that transaction chain). Another interesting property of Pedersen Commitments is that if the recipient and the sender is the same entity, then an infinite chain of valid and signed transactions could be created between them, so if there is any change, then the number of parties involved is unknown.