Topic: Thoughts on Bitcoin's sustainability on the long term (Read 478 times)

once things are in a block. censoring it (removing it is not a thing bitcoin does)

however hardening consensus back to some parameter of common sense utility is not censoring
also it doesnt cause a re-org/fork

if all nodes alive today say anything below 3.99 is acceptable.. then something thats 90byte is also acceptable

..
pretending that transactions are not rejected, ignored at pre-confirm is silly notion. transactions are rejected for many reasons.
EG trying to broadcast a litecoin tx in the bitcoin network.. rejected
tx below satoshi dust rejected
transactions trying to use 8mb of bloat rejected
i can give soo many more examples

bitcoin is not permissionless
its a consent network
even requires people to sign their own utxo to show consent to have their spends be added to a block. meaning the network  needs a utxo owners consent
and yes 2009-2016 users proposing new rule needed the majority to upgrade their nodes to be ready to verify a tx meets the new rules before the new rule activated is the network consent

those shouting censorship resistance and permissionless have no clue about consensus(consent)
they just want to make the bitcoin have no rules so that it loses its integrity. becasue they are too hyped up on sales pitching alternative networks people should use instead

its funny how they dont want more transactions on bitcoin but happy for wasteful bloat on bitcoin. the reason is obvious and said in last paragraph

But we currently don't have any other way of allowing everyone to voice and take action based on their opinions, and since it's a fucked up world, even the results won't be telling, since more will forget about their vote and follow the $/BTC. So yeah, I was describing how that should normally be done, not that I believe in the method and the results.


Censoring stuff in an anti-censorship tool, opening the pandora box, now it's ordinals next it will be MARA look-alike filters, all that bla bla crap we definitely don't need.


Oh, consensus, I'm pretty sure there won't be any, more than that I'm also betting on the fact that the majority won't caree about this nor do they even know about transaction fees or anything else. And just yesterday I stumbled upon this gem, and it's not a newbie saying it:


So, at this point the average Joe probably doesn't care about the tx fee, doesn't care about running a node, and would not give a damn about our fork or consensus! 
Which is not really painting the pretty picture I want to fall asleep looking at!

having each tx format have consensus policy for byte usage rules.. filters out a tx being used as a meme.
(unless you are talking about a monochrome thumbnail of 7pixels by 8pixels)
so saying silly things like "but if we increase the blocksize we let in risk of memes returning
no, just no.
read first line of this post for solution.


as for blocksize
there can be rules for that too
if every 52500 blocks the majority of blocks are 95% at 3.99mb then new blocksize
and before blackhat sings the stupid song of "100megabites by midnight" song his buddy screams for years. no
scaling is not leaping
scaling can be progressive growth over time

as for saying "but computers cannot handle more then Xmb of data per 10 minutes"
um
bog-standard pc's download process and display 50GB in 2 hours. (HD movies)
bitcoin nodes handle 300mb of transactions at any given time (mempool)

by the way, lets go low
5mb/s internet
300mb per minute

Regarding the block size equilibrium, what about having a variable block size (like XMR does)? Would it be better than a fixed limit?

IIRC, last time I checked it was pretty small (~100KB), but it can go higher than that (not sure how much).

Still though, even this solution would require a hard fork and maybe it would invite even more Ordinals...

Practically, what you describe is called a fork, and as history is concerned, forking doesn't go well.

Which transactions go against the principles? And which principles?

For this to happen you need to find consensus. Don't you think there will be a reasonable percentage of the userbase who will refuse it?

Theoretically, in a completely free and decentralized system, this equilibrium should come by itself, right now, god knows where it is.


It's pretty easy, do you consider the block limit causing problems (Y/N),  if no it's obvious if Y then we have 3 choices:
- make more people go to LN, a thing which although the ideal solution is not happening so you would have to enforce it, which is bad
- ban certain transactions, which go against some principles
- raise block space gradually and witness the consequences, I don't think that a gradual 2x every two years would harm that many nodes.


It's a space and if we go to the extremes ram issue, as I said before an increase of 4x in block size assuming full blocks won't be that much, not if at the same time, we preach for the average Joe to buy a hardware wallet, to have his own airgap coin storing solutions, and to have a different device altogether other than his work laptop or smartphone when he deals with crypto.
What the difference between an already needed 1TB drive and a 2TB drive that would only become obsolete 4 years from now? I would say it's nothing to be scared of!

Anyhow let's see where this madness will go, normally the FOMO should die out but before it impacts the fees more than it has already but at the same time, short interval, we should be thankful for the mining pace increase (519 / 482.27 expected, 36.73 ahead), 36 blocks ahead of the normal schedule in 3 days that have eased considerably the mempool.

in the current 4mb block limit
if pools are happy to get 0.13btc total fee per block(at 10sat per byte)
(current average of tx and cost pre ordinal drama)

which means on the average 1.3mb block situation pre ordinal of 2000tx
is 0.00006500 per tx ($1.44)

by doing a few(not the extremes of lean and decludge)
can allow in 3-8x more tx
meaning
worse case people pay same 10sat per byte and pools get 0.4btc-1btc in total fees
but there are 6000-17k tx count per bloc instead of 2000tx

or. each tx gets to pay less then 10sats per byte
which if each tx is less than the average 650byte and closer to the 226 leanest tx size
can be upto 2.8x discount just on the lean tx.
and upto 3 x on the tx per block discount of pools decide they are happy with 0.4btc total block fee (compared to the fee earnings average pre 2023 drama)

The million dollar question is: so what's the equilibrium of this? Alright, let's make an extreme assumption, that block size is 1 GB. By that reasoning, there's absolutely no problem at leaving it there, because miners will unquestionably pay the extra hard drives for a network that is capable of handling more.

I'm indeed confused and doubtful. That's why I want to talk about it.

I say that it will make fees go down, but it won't solve the problem of the average Joe. Whether the block size limit is 1 MB or 10 MB, it still can't handle the same as VISA. So, in a global scale, it can't work.

I don't know the numbers precisely. I only know that the cost rises analogously with the block size limit.

4mb blockspace
+with lean tx byte limit
   +with each opciode having purposeful byte limits
     which dont yield entry paths to bloat whole blocks with one output
+with tx formula that
    +punish bloaters per input/output
    +punish bloaters per excessive input/outputs batchers
    +punish young utxo age spammers
+full 4mb treated as 1 area
   +removing the cludge that separates as 1:3
   +counts every byte as a byte
   +no miscount cludge bad math

hardening the cludgy/soft wont cause a contentious hard fork
nor would it cause a hard fork
as all refined limits are within the "allowed" range of the soft
only result is TX of softy/bloaty/cludge being created in future wont pass inspection and the tx of individuals still trying to make cludgy tx will have individual tx not be confirmed.

---

in such a scenario of block design as just laid out above
an average 1in-2out tx filled block lean payment of 226byte
= block of 17698 tx
=2,548,512tx a day

compared to pre ordinal average:
=2000tx
=288,000tx a day

so without moving the 4mb block allowance devs deem network safe in 2017
can see upto a 8.8x increase in tx count (extreme lean)
more then 3x vs pre ordinal average (average expectation)

---

to those screaming "cost" of hard drives
if $50 for 2tb hard drive is a fear factor
where 2tb represents
500gb historic + 7 years future
if $50 for 7 years sounds bad
then guess what
7tx a year of $2 is just as bad

so if you are a proponant that $2 a tx is ok
and want people only using bitcoin once every 7 weeks
you are debunking your own
tx cost good via your "cost bad"

where rationally
people upgrade their computers every 2-8 years anyway. thus no real world extra hardware cost compared to what they have spent normally per period for their device they use anyway

but its the tx cost and limited use of once per 8 weeks which you now imply is the bad cost limit of $50 per 7 years if you are trying to rationalise $2 per tx=good, if you are also trying to rationalise $50 per 7 years is bad in the same brain neuron you call an idea

No, it doesn't work like that, because we have the $ which drives everything round here right now!
If there are no users the blocks are empty and you can host the node on 5-year-old smartphone, but it's useless, right?
If there are no nodes but there are users miners who will see all those tx fees and will definitely spend $100 on another hard drive to have a chance of getting all that $BTC$.


Bruh! Sorry but at this point, it feels like you don't know what you want either. At one point you say that increasing the block will definitely make the fees go down but at the same time, it won't fix anything but it's also it's more good than bad. So, ....... which is it?

But leaving this aside, I really want to know why you're so focused on the cost for a bitcoin node but at the same time you have avoided twice in a row pointing to a number on the cost!
I don't get the logic here, it seems like the same people who see Bitcoin replacing all the global finances, trashing WU, Paypal, and destroying the USD will fail because of the cost of a 2TB SSD, you have to admit, just the thought of this is ridiculous. If a bunch of crypto kitties is making the network unusable then probably everything was just a wet dream from the start!

And if there is no full node, chances are, there isn't a bitcoin either. You can take it to both extremes, but I don't see a point.

I'm not against a x4 increase. I'm against a x1000 increase, as in BSV. A small block size increase will do more good than harm.

And with full nodes soon treating all transactions as RBF, they'll be essentially forced to move to off-chain solutions. But, that doesn't tell me much. A x4 increase wouldn't solve this problem. The average Joe would still pay lots in fees every year, if he chooses to make the transactions on-chain.

Yes, but there will always be someone who'll take advantage of the empty space, and there will always be a miner who'll include that in their block as long as it pays at least 1 sat if the mempool is empty.

Why would quadrupling the block size limit would consequent to quadrupling the revenue? Isn't it competition that rises the median fee? Breaking that competition could have opposite results. Currently, the candidate block in my mempool is consisted of transactions that pay ~19 sat/vb, and is ~2.5 MB. Total money in fees ~0.2 BTC. Raise the block size to the ceiling and expect that total to drop.

If there is no average Joe using bitcoin there is no need for the average Joe o run a full node!
Can you give me a breakdown of the additional cost that the average Joe would have to pay over 10 years for an x4 increase in blocksize?
Because we already know the cost average Joe has to pay now to do a tx with the chance of being confirmed, that's 30 cents a day, so around 110$ a year!


No, it's the same.
You need Bitcoin to send bitcoins and you need fees to compete with others for the space in the block.
If one miner (like Luxor) decides to do something stupid and include zero fees transactions it doesn't matter, Luxor could have mined a zero tx block or a 1 tx block, this would be, again going to the car analogy like Shell letting you fill your tank for free.

If a mining pool decides to do something this stupid it will simply chase away its miners, and miners have different views on these issues than the average Joe, for example, miners don't like transactions accelerators, because if they accept lower fees tx it means less payout for the miners also. By the time the reward will drop further, nearing half of the revenue or even lower any mining farm and mining pool pulling out this nonsense will just go bankrupt.


I am curios about the miner who would pass a $5,731 (last block reward) and do this for every block, let's assume 4 times more since we increased the space, that's $20k, and in a scenario the miner has 5% of the hashrate, how about 7 blocks, so $140k a day loss. Would you do it?
Especially since right now $140k means the income of 2 Exahash of hashing power a day?  

If we agree that the average Joe will not run a full node, I don't help him at all. In fact, a block size increase would only benefit the average Joe.

Flawed analogy. Cars don't have a zero cost to acquire. Clogging up the network with absolute trash costs nothing the miner to include it into the candidate block, as long as that trash doesn't exceed the economically allowed size. The opportunity cost is non-zero the moment the unconfirmed transactions exceed in total the allowed space in size. Whether a miner mines an empty block, or a block that's filled up with garbage that pay 0 sat, the opportunity cost is equal. Rising the block size limit has as consequence to increase the storage spent recklessly.

I don't either, but it depends on the limit. Let the block size at 1 GB, and expect him to pay minimum to do the exact same thing.

Indeed . I think that we first have to define what spam is . The definition is :
"Spam is any kind of unwanted, unsolicited digital communication that gets sent out in bulk. Often spam is sent via email, but it can also be distributed via text messages, phone calls, or social media."
Definition should also contain "at near to zero cost " as email providers don't get a single penny ( can't think of a way they get paid , correct me if i'm wrong )  from spammers for the services they are providing .
As long as the "spammer" pays to use the network i don't see any reason he can't do it . And after all it's a miners/pools decision on what should be added on a block or not (proof of work ) .

Sorry but I don't see how this works, it makes it easier to spam but it makes it far costlier to clog the network.
By the same logic if you shrink the block size by a factor of 4 you would make spamming more expensive, but how would that help the average joe?

Second, there is this myth that is also rolled over in the real life if you increase road size by 3 times you will just have 3 times more cars, I wonder what will happen if you increase the road 10x times, you will have people drive  5 cars at once?
The same thing is with block space, if we increase the space by x4 in order for the spammers to clog the network as they do now they will have to block at least 75% of the capacity with their spammy transactions, right now the fees are 25.58 BTC , for them to make the other 75% completely inaccessible for the users that are still sitting in the mempool now they would have to cough up at least 75 BTC, that's $1.7 mils and still let the transactions that are now being confirmed pass through.
With the current blocksize with $1.7 mills in BTC you could spam all day the current blocks with ~70sat/byte.
*rough calculation, so I might have got some wrong in the +/- 10% area.

Also, another thing, from a miner's point of view, I would rather have spamming and consolidating inputs at 1sat/b rather than have empty blocks, because they still pay for it and that goes to the miner's revenue. And more miner revenue, more secure the network will be!

I'm not. You're the one who said that people use Binance because the network is clogged up with transactions in mempool:

Who's setting this multiplier? The protocol rules surely shouldn't.

I don't say that if we rise the block size these people would swift to running a full node. I'm quite arguing they'll still stay on SPV, just as you do, but with a main difference: they won't hand over custody.

The fee remains the same, but the miner prices the byte differently. Raising the block size by 4x would also incentivize for more recklessness in transaction compression.

That's right, it's not difficult to set up an LN node, mostly there are solutions like Umbrel that are adapted to less experienced users.  Rather I see that there is a waste of energy and also of resources that not everyone has the possibility to deal with, beyond technical capabilities.

running a node or subnetwork app is only complicated if the dev team didnt code it to be user friendly

EG it doesnt take much to put things into a top of app menu item in the GUI. but if devs feel they should only bother leaving it as a config manual entry or a command line option of a debug window.. thats on the dev.. not on the users competence

its silly little things
like segwit has been activated for 6 years
but for many years the main segwit codes rushed to get segwit activated. but then for YEARS did not even bother to get cores "sign/verify message" GUI feature to actually be compatible with segwit.

yep YEARS
https://bitcoinops.org/en/newsletters/2021/09/29/#preparing-for-taproot-15-signmessage-protocol-still-needed

its silly things like dont make things user friendly and then pretend its not needed, as the excuse not to finish the job

I don't think that solutions like BlueWallet are popular just because they are technically simpler. People don't run their own nodes because it's already resource and effort-comsuing with the current blocksize. Running your own LN node is not harder than running a Bitcoin Core node. If you can read instructions on a site and follow them, and google problems if they arise, you can do both.

ok lets first define 3 types of transactions (attacks) because your making 3 arguments about 3 different attacks types of people bloating and spamming and your using those types against the wrong solutions

1. multi-ouput batchers = the CEX withdrawals (over chargers)
2. bloat witness opcodes = meme ordinal bloaters
3. spending young utxo = spammers

lets say all examples in this post are based on a 1sat per byte(for normal utility)

using a business mind (1)
when you deposit into a CEX it costs you 1 tx fee (2in 2out lean = ~374byte)
374sat
when they then move from their hot to cold and then cold to hot and then hot you your withdrawal address
thats
sweep deposit | colt to hot  | hot to your address
500in 1out      1in 2out        1in 500out
0.2% of tx       0,2% of tx    0.2% of tx   should be your "fair cost"

74044             226             17158     (per cex session)
148                 -                 35          (per customer)
(based on a 500 user batch)
binance should at a 1sat per byte be charging a user 183sats
so yes 50000 is extreme as thats pretending its
274 sats per byte per user
but thats their internal business decision and not the bitcoin
so simply dont use binance

---

ok now lets deal with the bitcoin network stuff

ok so code can create magnificent things called rules and policies the network agree to collectively verify the network

so
1. a rule can be made if a tx has too many outputs. then a fee multiplayer is in place EG under 4 outputs=min sat/byte.. 4-100output =4-100x min sat per byte.. and so on 101-500output =400-2000x sat per byte

2 define byte length per opcode. where no one needs thus gets to use an opcode where they can have 10kb per use or able to use the whole 3.999mb

3. if utxo is under 288confirms. then use multiplier
EG a spammer spamming every block pays 288x min fee

this means not everyone is fined or pressured to pay more.
but if some individual wanted to for instance create a tx where:
an opcode allowed more then 80bytes. lets say 10kb
and they had 399 outputs
and spent it every block (a 3.99mb block of 1tx)

that one person. would need to pay (if min sat/byte was 1sat/byte)
1596sat perbyte for the opcode(1)
x288 for the age = 459648sat per byte for which being 3.99mb tx
18381,3235,2000sats (18,381btc per tx)
so yea they can pay the fine. but then they would run out of funds before the day ends

where as someone spending once every 2 days with a 2in 2out
would need to spend ~226byte = 226sat in the very same block

---

as for the highlight about lukes Bip
isny it funny that luke and sipa were the main segwit promoters.. yet
even now they were using legacy
(sipa's legacy vanity address(his site) and lukes legacy (stolen at christmas))

I agree that scalability isn't a solved issue, especially if we think of adoption of Bitocoin as money (because I wouldn't say it's a big deal for hodlers, traders, or even for occasional big purchases, as hodlers don't need many transactions, traders often use centralized platforms, and big buyers can afford to lose some money on a fee). It's rather just something that's put on hold, not currently obvious as a big problem. Perhaps we'll see very user-friendly off-chain solutions OR get used to being okay with accepting zero-confirmation transactions up to a certain amount of money (then the high fees can be avoided) for the purchase. Or maybe the future of Bitcoin is still more of a future of an asset, not money.
As for a fork, I wouldn't say the risk is past us, but if Bitcoin survived the SegWit situation, I don't think it'll suffer much from future disagreements. A new coin can appear, but it won't undermine Bitcoin, wherever it's going.

But these services impose much larger transaction fees than the Bitcoin network. Binance, specifically, charges 50,000 sats for withdrawing your bitcoin to a legacy address.

What about my other argument?
Isn't it weird that the contributor of this BIP is Luke, when he was the one who proposed 300kb block size?

Don't forget that rising the block size by a factor of 4, would make spamming 4 times cheaper. Therefore, we'd definitely have more non-currency transactions. I'm guessing that it'd do more good for spammers than for actual users. See the recent Ordinal thing. You should take it for granted that the network will be clogged up 4 times more than now.

Don't get a shadow banner on your tail.

Admin! You try to ruin my day?

"An Error Has Occurred!
You are searching too quickly. Wait 4 seconds. (There is a Google-based search engine on the search page that does not have this limit.)"

Attention hut.

hardening consensus is not a fork creating event

if current rules are "we dont care"
then any new rule that says "only 80bytes on opcodeXX".  is within that "we dont care" range of 'upto 3.99mb amount thus wont cause any disruption

all it means is anyone after activation. that then tried to make a tx. will get their tx rejected if that individual made a bloaty tx
thus punishing the spammer alone not the network

it wont cause any block issues by refining and defining opcode byte limits because any new byte limits will be under the current lax rules thus not cause issues to current rules

the only time there would be a fork risking event is the opposite
if there was a rule of 80bytes in an opcode that someone wanted a new rule of XXXXkb

significantly...
Instead of a $50 500GB a $150 2TB SSD that would be full in 8 years, 16GB of RAM you can buy at $50
Common, the increase would have been significant in 2009, not now!
And let's remember that automatically increasing block size won't mean we will have 4 times as many transactions instantly.

Now, the problem of security.
Bitcoins security is simple, if you reward miners enough you will have enough hashrate protection, valued at how much you pay for it, 100 Exahash or 100 Pethash are meaningless if you won't look at how easy it would be for an attacker to get ahold of that, back in 2013 a single S19 could have attacked the network, but there wasn't one available at that time for 2000$ 

So at any point, you would need to look at how much it would cost someone to attack it and at every single point this will be related to the reward, so the thing is that in order to keep the same level of protection the users would have to come up with the fees themselves. Right now, we have $21,621,853.65 in income in the last 24 hours and 821,913 active addresses, I choose active addresses because it's better than looking at the number of transactions, so that's 26$ per address used to keep the same level of protection without reward.
Would it work if the reward halves two times and the price is still at 20k? I would say no!

Yes.


It should be based on initial (e.g. hardware) and operational cost (e.g. internet connection and electricity) of a node, while also considering future initial/operational cost. In past, only BIP 103 consider this perspective seriously.


Usually no, since upgrade usually released as soft-fork.

They have to answer

But generally speaking a hard fork comes with a lot of work and risks. Literary everyone has to upgrade to the new protocol, a regular user with a full node can no longer run their old version anymore, the businesses that were accepting payment using their own setup have to upgrade, exchanges, payment processors, mining pools, etc. all have to upgrade. Anybody who doesn't will automatically split the chain. Depending on the changes, the SPV users may also be forced to upgrade.

The bigger the community gets, the harder it gets to pull a successful hard-fork with least amount of network disruption but I wouldn't say it is impossible though. With enough time (like a year) we could make it happen clean enough.

there is a massive difference between softening consensus to let lame stuff in quick. vs when a need emerges that benefits ever user of the network the network should shift

the second part is true hard consensus. the network upgrades their nodes to be ready to verify the new need that benefits everyone. vs the soft consensus where any whim core wants is thrown in even without nodes being ready for it
the importance of network security is having mass nodes ready to verify a ruleset. not abstain and just let things pass without seeing if it complies to a ruleset

60mill people of coinbase.com 25mill people of binance use them as custodians because of the tx restrictions and cost of using the p2p BITCOIN NETWORK

if binance alone can cause a week of congestion and fee excess on the bitcoin network. then bitcoin has been held back at limits that should have moved years ago
14 years and we are still at the <7tx/s (its about 3.5tx/s)
this is not about leaping to 100mb blocks like someone who inspires you thinks is the only opposite option to the current situation. its about removing the cludge of current situation to allow lean utility of upto 6000tx/s of current average tx size., then lean up the tx to be more so to get to about 10,000tx a block
AND
making fee penalties for those that spam their value more then X times aday rather then penalising everyone for those spammers abuse
for now
and then move up progressively(not leaping) the block size from 4mb to the next level
AND (as a sub service a new (fully working/unflawed) sub/side networks for niche utility where there is a monetary policy and security to protect users. (not blame users for flaws/loopholes)


you do know whats junk. bitcoin is a payment network not a meme network.
consensus is code. code makes rules to understand what is deemed a purpose of a tx
im not saying no to taproot for instance. but taproot promised its purpose was lean signatures of 1 signature length. and so the opcode for taproot can have a limit of 1 signature length to ensure it meets its promise of purpose, thus removes the edge cases of abusing taproot for junk purposes

But, inevitable at some point. For example, when the cryptographic algorithm breaks, we must make it non-standard the least and introduce the new, resilient algorithm. Same like with block size increase, if a need emerges and benefits every single user of the network, the network should swift to it.

But if blocks are big, they can get the benefits of big blocks without giving up custody, whereas if they are not technically competent, and we take the lightning path, they have to give up custody. And it already happens. See BlueWallet.

What do the developers say about that?

I'm only saying that you don't know what's "junk", and obviously people who send that "junk" isn't junk to them. If they pay the cost, they can clog the network likewise, there's nothing we can do about it. And as I've said numerously, any rule which would be enforced solely for this purpose would only do harm, because there are nearly infinitely manners to clog the network like this; NFT users will just find another way.

My thoughts on Bitcoin's sustainability is a bit different, because I do not want another fork war. I think we should focus more on creating something that will generate more transactions and not something that will remove transactions or reduce it from the Blockchain.

Take the off-chain solution like the Lightning Network as an example.... it is reducing on-chain transactions ...and we know the Block reward are supposed to be replaced by miners fees, so if we have less transactions in the future and almost no Block reward... who will be mining?

That for me is what sustainability is about.... finding solutions that will run on-chain and something that will generate miners fees in the long run.  

you ask about bitcoin sustainability. so you must be seeking understanding about what is bitcoin to understand what needs to be sustained

the answer, its a payment network, that needs to continue to be a payment network to be sustainable. otherwise its just an expensive congested junk network of cat memes
...you thinking bitcoin fails if its not allowed to let in cat memes. is where your hung up missing the whole point

its become soft in recent years which has allowed cat means.. is the honest answer. not that it fails if we should prevent cat memes

cat memes were not on the network before certain softness was allowed years ago and even more so allowed recently

there are many ways to stop it

but first you need to understand bitcoins true purpose and how to sustain it

imagine this
you go to a store and buy a cordless drill with a visacard. you tap to pay. and look for the approval message, thinking it should appear in 2 seconds.. but instead you read
"we are not just processing your payment, we are instead transfering the latest marvel movie in HD from your card to your bank account, please wait for completion before we care about processing your payment for the cordless drill".. "please pay extra fee next time to avoid this delay"
and then you get elevator music playing out of the card reader

is that sustainable
visa suddenly saying its now a movie streaming service and not caring about being a payment service.. nope not sustainable, no one would want to use visa if it played that game. and visa should not change into something it was not first designed for
..

bitcoin is not a "permissionless system of freedom to junk it up and expense it"
we know where you might have got that idea from. or more specifically who.

bitcoin is a consensus payment system
something that person that inspires you does not understand or want bitcoin to remain as/return to being

consensus
consent of the masses

consent is different than permission
as no single person is giving permission(signing off on your payment on route).
 but the masses are(were strongly, now weakly) consenting to rules which strengthen what is deemed acceptable purpose to ensure best practices
so that people can do things lean and purposeful for its real purpose without needing someone else to sign for a payment you wish to go somewhere***

. as for subnetworks
there will new new subnetworks with their own purpose/niche utility. but the ones on offer lack many things to be the solution to a payment system with no middlemen because they cannot cope with the liquidity of peoples needs and they rely on middlemen
***(liquid uses 'federated reserves' middlemen for the pegging and the other L network needs middlemen signatures long the routes to give permission for funds to move through them for routing and require your destination to sign off on permission to receive payments)

notice the difference between consensus vs permissioned networks now, i hope so.

so it will be new and different subnetworks without the flaws that will offer better niche sub services

i will apologise for being the bearer of bad news. but it does need to be said

note there is not one single insult in this post

When it comes to scaling I always believed that we need a middle ground to do everything but not rely on one solution alone. For example you can't just increase the block size and call that a solution just like you can't not-increase the block size and say second layer is the solution alone.

We basically need 3 things at the same time: increasing the capacity, compressing the blocks/transactions and working on second layer solution.

This is also why I liked the idea of SegWit2x although it suffered from a flaw. It separated the hard fork and soft fork whereas it should have done it all in one hard fork.
In my opinion we need a hard fork sooner than later. A hard fork not only to increase the capacity (to something like 4-8 MB block size) but also to solve a lot of bugs lets say "weirdness" in the protocol that can help with the compression too. Weirdness like the one extra wasted byte that all OP_CHECKMULTISIG(VERIFY) scripts must contain, or the couple of extra bytes that are wasted by all transactions with witness, the 4 byte transaction version that is almost completely useless,  the flaws in ways [sig]OPs are counted, the existence of P2PKH and P2WPKH at the same time while they serve the same exact purpose (same as P2SH and P2WSH), and a lot more.

Do SPV wallets must upgrade their wallet softwares when Bitcoin protocol has upgrades?

Users of SPV wallets are simply download, install those wallets to use for their storage, transaction broadcasting. If they can do more technical steps to verify wallet software before using it, it is better.

I don't think users are responsible for too depth technical knowledge and codes or steps. They simply interact with good wallet softwares in wallet interface. To help Bitcoin adoption, I don't think developers should force users to interact with wallet softwares by code.

Increasing blocksize is great when time comes. If Bitcoin had Segwit upgrade for it in 2017, it can have Segwit 2 in future. Community will support the block size increase and upgrade if it brings benefit in transaction fee and average waiting time for confirmations.

Why are you saying that alternatives to blocksize increase are increasing Bitcoin complexity? If a user can run a full node, they can run an LN channel. And if they can't run a full node because they are bad with technology, then they won't do it, regardless if blocksize is big or small.

I think it's fine if most users run SPV wallets, if casual users use custodial wallets, and only enthusiasts run full nodes. Yes, they won't get all the benefits of being your own bank and "don't trust, verify", but most people don't need them. Just owning and using Bitcoin in sufficiently secure manner is enough.

Thank you for starting this discussion on the sustainability of the Bitcoin network. These are important questions to consider as the network continues to grow and evolve.

Regarding the block size limit, it is a trade-off between centralization and decentralization. On one hand, larger blocks allow for more transactions to be processed, increasing scalability. On the other hand, larger blocks also require more computing power and storage space, making it more difficult for smaller players to participate in the network as full nodes. This can lead to centralization, where only a few large entities are able to participate as full nodes, while the rest of the users have to rely on these entities to validate their transactions.

In terms of block size limit, there is no one-size-fits-all answer, as the optimal block size will depend on the specific use case and the goals of the network. Some proponents argue that the block size limit should be increased in the future to accommodate more transactions, while others believe that alternative scaling solutions, such as the Lightning Network, should be pursued instead.

Regarding the issue of backwards compatibility, it is an important factor to consider when making changes to the network. Any changes that break backwards compatibility can result in a split in the network, potentially leading to multiple versions of the cryptocurrency. This can cause confusion and fragmentation among users, making it more difficult for the network to achieve widespread adoption.

In conclusion, the future of the Bitcoin network's scalability and sustainability is uncertain, and there are many factors to consider when making decisions about the network's future. Discussions like this can help to gather diverse perspectives and find the best way forward.

Yes i agree that there are flaws (or were introduced) in the system. And Ordinals is a clear demonstration of spam attack against Bitcoin that needs to be addressed for any hope of sustainability. It was decent until this happened. Even your idea is with merit, anything to make it more expensive to spammers or deter them in anyway so they naturally go away where its cheaper to do so.

I believe one of the reasons for the existence of PoW was designing a system to address the issue of spam in email. It is ironic that we now need to address the issue of spam in the blockchain, as it has clearly gone out of hands.

So if we go back to the previous pre-ordinals stage, was is sustainable? I think so yes. Even if you didn't have universal instant transactions, it was still good enough for most transactions and the occasional instant transaction, a system which could be improved still sure, lightning has its own de-merits but at least it was optional and you could just ignore it.

But I don't understand how's this associated with sustainability. If you think stuff like Ordinals are an obstacle to sustainability, then the system is fundamentally flawed to begin with. Limiting op codes will not prevent anyone from spamming the blockchain. Simple example: split the ordinal into x transactions. The only disincentive is the money they have to pay. Anything beyond that will probably do more harm than good.

So, what you're suggesting is to go on without backwards-compatibility. I agree that doing this might make the system work potentially more efficiently, but I'm not quite sure about this:

ill be polite

changing the opcodes so each opcode has a defined byte limit, does not censor transactions but defines a transactions utility and purpose.
EG taproots promise of lean signature space that only requires <80bytes per transaction. instead of their current allowance of <3.99mb
multisig of 15 address limit =15*80byte
and so on
...
hardening the softness of these opcodes does not censor development, it prevents buggy new upgrades from sliding in soo easily. where it requires nodes to upgrade to be prepared to verify a new ruleset(proposal) before it can activate

this means developers can still code things, but they will be coding things the majority would enjoy and want. instead of what a small group has sponsored them to slide in

i understand hard consensus sounds like censorship of development by preventing a corporation lobbying the develops to do a certain thing. but it  can also be opportunity for said corporations to think beyond their personal desires and think about whole bitcoin community desire to sponsor features that help and give the whole community something nice

....
hardening consensus to require node readiness pre activation supports network security

defining the opcode byte limit makes transactions lean to support less wasted space usage to allow more transactions per block

removing the cludge code and fake math of byte counting..  that restricts tx data to 1mb and allows said excess uncounted(discounted) wasteful weight space.. would then allow more transactions per block by allowing them into the 3mb restricted area(restricted for certain formats witness) without changing the 4mb limit for now
where all transactions are seen as the same level of "freedom" to use part of the 4mb without being treated like a limited class
..
including a proper and better fee formulae (thats not just discounting new features to promote push people into using them. and instead making spammer that respend multiple times a day pay more then frugal spenders(once a day) can penalise the spammers without making the rest of the community "pay more"

..
all of this can be done without a re-org or fud of needing to split the network. nor need any opposition wars.*

* well unless one brand of nodes continues to pretend the network is their kingdom and they are the only monarchs that should reign supreme and rule over its peasants

Reserved for future summaries.

I would like to devote this thread for thoughts about sustainability, broadly and specifically. Bitcoin has come a long way in the last 13 years, and we're likely still on the beginning of something powerful. I think that as time goes by, and most of us are united and consented on the current protocol rules, Bitcoin won't stop thriving in the market. A lot of users believe that the main source of failure in the long run, is network sustainability. Lately, I've been trying to imagine how would a so succeeded network come into such dead end.

I have come to the conclusion that the network's sustainability is impossible to predict in the current phase. There are just too many parameters to take into account. What will the price of bitcoin be in decades ahead, what levels of security are considered sufficient, what kind of layers we'll have by then, what other incentives, maybe even nation strategies concerning cryptocurrencies. However, I'm sure for one thing: activity. If there's demand for the network to operate, it will be supplied. And for a network of global scale to operate normally, I think we need to concentrate on one thing: scalability.

I don't believe that changing the block size limit is the ticket for a global scaled network. But, neither do I believe that leaving it as is, is too. I'm all in for transaction compression (which is what's scaling in the end), as an off-chain solution like lightning, but the problem with this is that it restricts access to technically incompetent users. It fundamentally does, because no ordinary person who wants to gain the benefits of peer-to-peer cash, has the time to configure a lightning node, a Bitcoin node, and run both. Even if he goes on with pre-installed solutions (e.g., Umbrel), which separate the technical part from the end user, it's still discouraging because the user has to have a computer running every day, all day, which is orders of magnitude more difficult than holding a private key, and more expensive.

Big blocks, I agree, throw out a significant part of "small players" out of the window, because the cost of infrastructure to run a node rises significantly. Even my Raspberry Pi 4 sort of slowed down recently with the Ordinals overwhelming the mempool. But, ironically, so do small blocks if we take the lightning path ("small", in terms of technical competence). Therefore, I notice one thing: the future of Bitcoin's scalability is misty.

---

But, scalability, as per se, isn't only what's concerning me. In fact, it's rather the stimulus. It's what is likely to cause the real problem; discord. As I said at first, as long as there's a consensus around a particular set of rules, there can be progression. If the network splits, the result might not be as desired as expected. So, let's have a talk. Fruitful discussion is our only weapon we, as forum, have to confront this.

Here's some questions for debate:

• Will there probably be another block size war? If yes, shouldn't we take precautions now that we've learned from the mistakes of the previous time? What precautions?
• Should we rise the block size limit at some point in the future? If yes, how much? If no, what's the appropriate alternative?
• Can there be progression without backwards-compatibility?

Self-moderated. Will not ever delete post based on opinion. Keep things civil. Be constructive.