pull down to refresh

There are many interesting ideas floating around for scaling Bitcoin, from Lightning (which I think is ingenious but of course has its limitations) to sidechains, statechains, etc.
A lot of hope is also often put on potential future upgrades of Bitcoin itself like introducing covenants, etc.
What I was wondering, what do you think are the odds that a great (complementary) scaling solution is hiding in plain sight. Something that is possible with current (Taproot) functionality?
Are there convincing arguments to be made that this should not be the case? I.e. that we have completely mapped the search space and need to upgrade Bitcoin, or is it just the lazy way out saying that we need this or that opcode and suddenly everything is fine.
Would be interested in hearing your opinions? I haven't yet fully absorbed all the opcodes in a way that I have an intuitive understanding of them for a lack of better word. I understand Taproot and have already programmed some applications for fun but I know, to really innovate, you need to live and breathe something. I am playing around with the idea of hiding a lot of state in a merkle tree in a taproot address and to allow trustless peg-ins and peg-outs into this system. Am I wasting my time here?
10 sats \ 0 replies \ @kruw 26 May
I've heard RGB provides this sort of infinite upside in scalability. But there seems to be little interest for or against it.
reply
My .02: what's hiding in plain sight is that money is social and that scaling will also be social. There will not be technological magic that swoops in to save us. It will be new institutions built on the seed of btc, adapting to its affordances. It will be new ways of relating to each other.
But this way of relating, even more than the technical aspects of btc, will take a long time to propagate and can't be rushed.
reply
I agree, and there will be different trust models. However, I think we should still strive for allowing as many people as possible to be self sovereign. I am also using WoS for example for small sums since I know that I can always retreat to the base chain or non custodial lightning. If fees are too high at some point this will simply not be an option for many.
reply
111 sats \ 5 replies \ @freetx 26 May
what do you think are the odds that a great (complementary) scaling solution is hiding in plain sight.
Its something I think about often. I do think - if severely pressed with no hope of a soft-fork - someone would come up with some novel way to scale BTC with the already provided OPCODEs.
Controversial Hot Take:
I think a deeper truth is that scaling doesn't really matter and we can probably make do as is for a long long time.
Simple fact is: People don't want to spend their Bitcoin. You can see this again and again....there was just a "El Salvador Report" on front page where it was mentioned that most of the shops that had "we take bitcoin" signs have now stopped taking it.
This is not because of some technical problem with Bitcoin...certainly not a scaling issue....its because there is no demand for it. If there were people lined up out the door trying to buy BigMacs with BTC, they would accept it....but there isn't.
Greshams Law is a real thing. People would prefer to spend their shitcoins (USD) and hold onto their gold (BTC).
reply
21 sats \ 2 replies \ @jgbtc 27 May
I'd like to see the demand for scaling come from users via increased adoption rather than from impatient devs looking to make their mark by solving hypothetical scaling problems.
reply
10 sats \ 1 reply \ @nyan OP 27 May
I think calling Bitcoin scaling problems hypothetical is living in denial of reality. If you already have a big stack you might not care but bear in mind that without eventual scaling your stack’s terminal value will be significantly less.
reply
I think calling Bitcoin scaling problems hypothetical is living in denial of reality.
Well....right now 10 sat/vb transactions are clearing. What "scaling" issues actually exist at this moment? Is LN not usable for small transactions?
You may be saying "yes, its fine at the moment, but how can we onboard the world onchain". And yes that would be correct but it technically is a hypothetical problem.
I'm not sure (a) the world will arrive en masse and/or (b) that they will demand to be on-chain.
I think the likely state of on-boarding the next 3B users will be: Fiat -> CEX (SQL Database) -> LN. In which case I think we already have that covered?
reply
Agree
Spend weak money, save hard or strong money
reply
I like your hot take and I partially agree. As long as Bitcoin is in the process of filling its predestined place (pick your number, is it to replace all gold, all bonds, etc) people are unwilling to spend it.
However, I think at the same time we should not get complacent about the status quo because eventually, we all want and need Bitcoin to become the global currency.
Also, if I am not mistaken, in El Salvador the main reason why merchants are not taking Bitcoin is volatility but I might be mistaken. And in any case, I agree with you that Gresham’s law plays a big role in Bitcoin adoption.
reply
102 sats \ 0 replies \ @om 26 May
It's possible that BitVM improvements (BitVM2, BitVMX) will grow the capability of on-chain verification while ZK improvements (Plonky3, Binius) will increase the efficiency of ZK proofs so much that on-chain ZK verification would become practical. I wouldn't bet on that though as BitVMs don't look convincing to me, in particular BitVMX's choice of RISC architecture tells me that they have no idea what they're doing (see Starknet's Cairo CPU for an architecture well suited to the problem).
Am I wasting my time here?
Who knows? So far only channel factories go there but they're impractical without covenants (see Jonh Law's paper on scaling with covenants). Figure out how to do it better if you can!
reply
There's always a tradeoff; information theory limitations.
reply
0 sats \ 0 replies \ @OT 26 May
Improvements to lightning might be enough if we have a long enough time frame.
Buying something with bitcoin should be instant and cheap like WoS
reply