Topic: Thoughts on Bitcoin's sustainability on the long term (Read 411 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))