Topic: Bitcoin block size limit (Read 422 times)

It is not often someone surprises me, well done.

 

Actually it is not good for bitcoin.

What you are saying is that ,
it is ok if the majority of the car buyers buy Toyota and Chevy vehicles and quit buying Ford vehicles.

What a logical person will tell you, is that means soon Ford will go out of business ,
while Toyota and Chevy take over the whole markets.

Or
to clarify

if the majority of the crypto buyers buy Ethereum and Litecoin/Doge coins and quit buying Bitcoins.

What a logical person will tell you, is that means soon Bitcoin will go out of business ,
while Ethereum and Litecoin/Doge coins take over the whole markets.  

im all for free choice.

but to say things like
if you dont like bitcoin 'f**k off' to another network
if you want a better experience try an altcoin
altcoins are great because they take users away, this is good for bitcoin

is stupid excuses that i would hear people in Myspace say
if you dont like myspace sign up to facebook
if you want a better expereince sign up to facebook
facebook is great because it takes users away from myspace. this is good for myspace

i hope you see the stupidity of that mindset
rather than trying to get bitcoin to be really practical as a payment system ON THE BITCOIN NETWORK. seems too many are  saying its ok to keep bitcoin limited and to promote altcoins and other services instead.. (facepalm)

i still wait for the 600k tx day potential to be surpassed.. something  calculated in 2010. and 4 years ago now promise to offer so much more tx capacity
i still wait for cheaper transactions. yet all i see is the code which show devs have X4 legacy and not / 4 any tx format.
transactions are not sub pennies/cents.

people think paying $0.50 is acceptable yet 4 years ago devs said they wanted to add new features that would scale bitcoin and make transactions cheaper(than the max of 0.20 back then).

all i see is hard drives filling up by 1.7x but not getting 1.7x transaction amounts compared to 2017

the reason people still talk about it 4 years on is because real statists and hard drive data show the capacity 'scaling' has not been fixed, nor has the transaction fee discount actually result in sub penny tx's. nor have we seen many other promises met.. so yea people will still talk about it

it is okay. i trust free markets. if another coin overtakes BTC, so what?

altcoins free up block space for bitcoin users = cheaper bitcoin fees. altcoins also offer bitcoin users cheaper options where they don't need bitcoin's security guarantees. this is good for bitcoin users.

you are just taking the fearmongering position of an altcoin shill. a more reasonable position is the one held by philipma1957:


let me know when that happens.

i think you are plainly wrong that people will stop buying bitcoins because there are cheaper/less secure options. the market has proven over and over that bitcoin users are willing to pay high fees and/or wait for longer confirmation times.

but even if you were correct, that wouldn't be a legitimate reason to weaken bitcoin's security model by bloating blocks or speeding up block times. bitcoin is not here to pander to peoples' desire for free shit. if you don't want to pay for adequate security, you can pay the consequences instead: Two Miners Execute 51% Attack on Bitcoin Cash

you are conflating "miserable adoption" with "polluting the blockchain".......why?


i'm fine with that. altcoins---like any offchain protocol or sidechain---offer weaker security guarantees at a cheaper price. that's the free market at work, and this situation benefits bitcoin users.

I can not believe that there are still people talking about this in 2020, especially after seeing miserable adoption of LN, the same as bitsquare or bisq today. The problem is not the technical part, it is the decision making ability of the dev team, they made one after another wrong decisions

As predicted, segwit and LN has permanantly polluted bitcoin blockchain and there is no way to remove them, raising the block size might get a bit help, but in todays world, 10 minute confirmation is just too slow, many other coins are already in place for the fast confirmation, and with lots of other improvements in both theory and practice, once their marketcap have been pumped above bitcoin, we will see what will happen

might wanna double check your math.
if you had a block of the transaction you quote as 441wu
it will be only 5208..... why.. because even in segwit the 192 bytes that are not witness still limited to the 1mb base
there is no way to get 9000tx ...

maybe you need to retrain your 'simple maths' because it doesnt appear you recognise the simple stuff so just avoid including it

also the calculation that satoshi and others done YEARS ago was a 1in 2 out.. which got the 4200 (7tx/s)
you know.. its more likely people dont wanna spend all their funds so more likely have a 'change' address attached to. hense why it was used as a primary use representer.

now i dare you to try a segwit 1in 2out to be a more a fair comparison.. because your math is more about not knowing the 1mb base is still involved in segwit.. and instead you try to use thin(1n 1out) transactions which make it look like its due to segwit. when reality shows its due to thin transactions rather than the representer transaction of 1in 2out.
shame on you.

heck.. i can do a thin in 1out non segwit(legacy). and guess what... same 5208 tx as segwit.. but hard drive size taken up is actually 1mb
your first example of a similar 1in 1out segwit would take up 2.29mb
kinda funny you dont actually see that.

after all your dribble about bandwidth and hard drive capacity worries.. your not actually realising that
a non segwit block of 1in 1out would be hard drive 1mb 5208 tx
a segwit block if 1in 1out would be hard drive 2.29mb 5208 tx

so dont go using the stupid math hiding trick. if you actually cared about hard drive and bandwidth like you pretend you do. you would be counting the actual bytes involved and not playin g the segwit tricks of hiding information and forgetting which rule apply.

but i do laugh you think that segwit can achieve a 1.29million tx a day scaling...
ill wait and see that happen.. and wait..
and wait..
and wait...
...... or probably faster you realise your math mistakes and your inability to recognise whats really happening at code and hard drive level to realise where your mistakes have been made

.. just remember.. in non-segwit(legacy) the weight is not a real number. its s stupid multiplication done to make transactions more expensive. legacy WU is not the actual bytes of tx. nor the hard drive space it takes up nor the bandwidth usage.

have a nice day though

Simple math can prove SegWit allows more transaction in a block. For reference, i use https://blockchair.com/bitcoin/transaction/868f240241c8fd0c13e9c69805612b647cc30aa1e982a9b0c9735b38d8607f7b and https://blockchair.com/bitcoin/transaction/d046a5746b0ebe9d86103852f1ed36edb553dc8d60187a52b1dfbee3f22eb9d6 where both of them have 1 input/1 output.

Block size limit (in weight unit) : 4.000.00 weight unit
SegWit transaction size (in weight unit) : 441
Non-Segwit transaction size (in weight unit) : 768

Total SegWit transaction size can fit in a block : 4000000 / 441 = 9070.2947845805 -> 9070
Total Non-SegWit transaction size can fit in a block : 4000000 / 768 = 5208.333333333333 -> 5208

If you still think SegWit doesn't allow more transaction fit in a block, then there's nothing else i'd say.

like i tested ETF.. ill test you..
show me one day thats surpassed 600k transactions.. and ill concede that segwit is for 'scaling' bitcoin.

and when schnorr is around ill ask the same question again..

what your not seeing as the truth is that schnorr and segwit are tactics to hide counting data from the rules to falsify numbers.
take segwit by not counting the witness area hard drives fill up by upto 4mb a block but the rules treat it as if only 1mb is being transmitted around.
the whole and sole point of the 1mb limit. to limit data transmission to 1mb a block..
so by core saying more than 1mb is allowed to transmit. theres no point in the 1mb limit.. yet they keep it for stupid reasons

these new features are not about scaling up bitcoin (dont ever expect more than 600k transactions.. definetly dont expect 2,400k tx's)
its about trying to prevent de-scaling(less transactions) by hiding information they wish to add to bloat up the blocks.
yep they want more bloated scripts but know if they did have the bloated scripts less transactions would average out.. so segwit/schnorr is just hiding data to try keeping to an average tx count. thus not scaling up. but just preventing bitcoin from scaling down
basically keep it at a stifled level of transaction count. all to persuade people that bitcoin cant scale. and introduce people to other networks

if you cant see whats really going on especially with these features only benefitting making other networks compatible and getting people to use these other networks. then you need to start taking a more critical look at all their excuses against allowing more than a 600k tx a day average cap
truly ask yourself why allow 4mb with all the cries against hard drive and bandwidth limits.. yet saying no to 4x tx capacity.. for the same space/bandwith

it does have a cost!
each byte of witness is responsible for 1 unit of weight. considering fees per size it reduces the cost.
also considering storage, communication,... reducing the size even by small amount reduces the cost.

i don't know why you are putting words in my mouth!

again with putting words in my mouth!
Schnorr like SegWit can contribute to scaling bitcoin, when more people use it whether it is multisig or not. for example if one exchange that is using a 2 of 3 multisig for its hundreds of daily payment switches to Schnorr musig it will start taking up a lot less space daily hence leaving that space for other transactions to be included in blocks.

FWIW i am not opposed to block size increase. in fact i have always supported proposals such as SegWit2x since i believe the hard fork to increase block size itself is long overdue. but i prefer all these other proposals that compress everything more, specifically Schnorr due to its compressed signatures, natural signature aggregation feature and much faster verification (single or batched).

^ great comedy moment there

ok so satoshi years ago calculated a 4200 tx capacity of bitcoin 1mb... (7tx/s) (600k a day)
ill just sit here patiently while i wait for your evidence of a single day that has surpassed 600k tx in a day..
.. ill wait
...
.....
......
........
...........
ok no evidence.. ok fine so segwit has not increased transaction count..
maybe try giving up on that joke you said and try another
upto 4mb of hard drive space but not 4x tx average increase.. so do you really think segwit is really hard drive efficient.. go on e honest with yourself.. 4x hard drive utility but not 4x tx utility. its simple math

P.S
bitcoin block 540107 = 4mb hard drive utility and......... wait for it.. 230 tx
https://www.blockchain.com/btc/block/00000000000000000021868c2cefc52a480d173c849412fe81c4e5ab806f94ab

yep its time to say that segwit is NOT hard drive efficient for transaction count.

i said new tx format.. you said alternative...
AKA schnorr does not help compress current transactions. people need to move funds into new formats.

also currently core discounts the 'witness' script data. meaning schnorr wont make transactions cheaper because the witness/script area has no cost anyway.

cant believe you think that schnorr is a fix for current ecdsa while then saying its an alternative..
yep i said its a new tx format using a different signing protocol. its not the same schnorr does not work with old tx formats..

thus i think you need to figure out which flip flop your trying to push and stick with one.
id suggest sticking with the flip that schnorr is new and doesnt compares legacy/traditional. and also is only really useful for bloated scripts. not everyday 1in 2 out transactions.

try if you really wanted to promote it as being a possible cure to prevent future bloated scripts from decreasing transaction counts by removing the bloat of such future scripts.
dont even bother trying to suggest it can be used as a tx count increaser.. so but no.. thats not its purpose

yes they do. every Schnorr signature drops the stupid decision to use DER encoding and that is compressing transactions by removing the extra 8 bytes garbage that each signature currently has and that is a 11% compression of signatures. also another byte is dropped from the public keys that come with each signature so the size goes up to 9 bytes.

signature aggregation (you refer to as multisig) is another characteristic of Schnorr signatures.

wrong. Schnorr is the alternative to ECDSA signatures that is currently we have ECDSA and in the future we can have ECSDSA. it has nothing to do with tx format!

I agree that datasize shouldn't be such a strong a deciding factor, but disagree with your view about the universality of internet in the world. There are still many places with little or no internet access. Sure i have 4g, but the only existing data plan is only 600mb per month... Its been more than a year since we lost adsl here, and there is still no (cheap enough) alternative in sight.

Of course those people aren't going to bother with running a node, they won't use the core wallet, they go lite spv wallet and be done with it. There is no other realistic option, but your idea isn't bad either, i would still not use core even if the wallet showed immediately the funds available, at least until i somehow get uncapped internet again.

Remember how it took me 3 months to sync last time i tried running a full node the last months i still had working adsl? those of us in a bad internet situation will not be running nodes anyway. The current blockchain is huge and if it were to increase its size even more rapidly, it would make no difference to us in the low end.

Its like telling someone earning 5 USD a month that the plane ticket price was slashed from 2000 USD into 1000 USD. Gee thanks, it would still take 17 years of savings (assuming you magically don't pay bills or need to eat)...

I would simply drop the idea of running full nodes on very small simple devices as well. A full node requires gigs of storage, 300g but preferably 500g so it lasts a bit more, and even if you trim the node it still needs to download all that. The issue i see is that simply enlarging the block size doesn't appear to solve the issue but delay it a bit.

I don't like LN much, but at least its optional. I can stick to doing 1 sat/B transactions, until they let me do 0.1 sat/B transactions. Segwit bech32 native addresses has saved me satoshis, so i welcome it.

come on.. you been round long enough to know these myths been busted.
1. blockheaders and other optimisations made bitcoin many many times faster than 2011 version of bitcoin. so yep thats right barebones devices can handle more.

2&3. the whole 4mb weight is where the core devs admit that bitcoin can handle users transmitting 4mb of data.. yet they refuse to allow a 4x of transaction count increase. the whole segwit is nt about more transactions. but allowing bloated scripts(dead weight)

4. time for IBD can be made to be a background concern. getting nodes to have a reliable UTXO set to atleast see an 'available balance' so people can just get on and use the node. and then, in the background the IBD can occur. yep people are not frustrated with the time to download the blockchain. they are peed off that they cant see balance or make transactions until the blockchain is downloaded. so the solution is available. let users usee bitcoin and then they dont notice the IBD occuring behind the scenes

as for the debate about speed. in previous posts shows the scale of 1mb's . come on.. even in africa they have 4/5g and fibre. heck even quiet villages of good old england have fibre. we are not in dial-up era anymore. and cant just keep using the dialup conundrum all the time as an excuse to promote the insecure non blockchain networks made for commercial profit..

come on you been around long enough to seen passed all the old myths..

It wouldn't regress because the attack gets cheaper and cheaper to mount over time.

Even outside of an explicit attack scenario, consistently full blocks is the natural state of the network. Whatever incremental limits you put on block size, blocks will become filled shortly afterwards.

So, raising the block size in this manner is a classic "tragedy of the commons" scenario. Block space = highly distributed, permanent storage. It is a very valuable commodity, and users will naturally want to obtain it at the lowest possible price. By allowing demand for transactions to solely determine block size, we would therefore create an endless race towards zero fees and larger block sizes. There would be no built-in check on blockchain growth.

Monero was able to solve this problem by implementing two properties: 1) A penalty function for oversized blocks which lowers the mining reward, and 2) a tail emission. This cannot be implemented in Bitcoin unless users are willing to remove the hard cap on supply.

What can someone achieve by making lots of transactions? Except spending BTC for transactions and fees?

Adaptive block size increases like this are easily gamed. An attacker intent on bloating block sizes can simply flood the network with transactions. The attack will actually become cheaper over time as block size increases, which makes it especially dangerous.

For someone who is interested in Bitcoin Core development, you should first learn how to quote properly.

84gb per day or 30 terabyte annually with 1 Mbps.
We already have enough internet speed and storage space to support that. But.

My point was not to switch to a large block from now on, despite it's still possible, but to adjust the block size accordingly to transaction count, if required, which means raise the size to 8mb per block once the chain gets closer to that demand. Something like block size adjustment could be added on protocol, which would eliminate the onchain scalability issue every skeptic is talking about.

And yet, Satoshi was referring that it's not necessary for everyone to have the full node, miners can easily afford it. For the rest of users, it's possible to run the node with block headers only to enable simplified payment system onchain, which requires only 4,2Mb storage per year.