Hello BCH: 2.26 MB & we keep 1MB

[hugeblack]

Hello Roger Ver:
Did you know that we were able to achieve 2.26MB block size "on-chain transactions" without changing 1 MB block size limit?. Thanks, #segwit.
Hash: 00000000000000000021868c2cefc52a480d173c849412fe81c4e5ab806f94ab
https://www.blockchain.com/btc/block/00000000000000000021868c2cefc52a480d173c849412fe81c4e5ab806f94ab
This is a whole without the need for lightning network, more low fees.
*** I do not know if anyone has posted this, please let me know to lock it.

[1713582733]

1713582733

[1713582733]

1713582733

[1713582733]

1713582733

[1713582733]

1713582733

[1713582733]

1713582733

[1713582733]

1713582733

[xskl0]

Congratulations... We can have huge blocks and our 0 confirm transaction system is not less secure because of segwit.

[Red-Apple]

we have had at least 50x  2MB+ blocks already. check blocks such as 505253, 508116, 531885, 505225,...

here is the funny part! bitcoin has 4 MB blocks and BCH has 32 MB blocks but bitcoin blockchain is currently 45.4 GB bigger than BCH blockchain despite BCH being about 7000 blocks ahead of bitcoin

the fund doesn't stop there.
bitcoin average block size is about 1.3 MB while BCH average block size is 50 kB which is only 3% of bitcoin

[steve_rogers321]

We might have huge barrier and our zero ascertain transaction system is much secured because of segwit. Bitcoin has 4 megabytes of block and 32 MB of BCH but Bitcoin blockchain is larger than 45.4 GB.

[cellard]

Congratulations... We can have huge blocks and our 0 confirm transaction system is not less secure because of segwit.

0 confirmations were NEVER secure, only an idiot would think otherwise.

The fact that you have huge blocks and the usage is even less than Dogecoin should really make you think twice. How can you not see that huge block space is a big target for anyone with enough funds to start a spam attack and clutter the network? (I mean, someone serious, unlike the Bitpico scammers)

[NeuroticFish]

The fact that you have huge blocks and the usage is even less than Dogecoin should really make you think twice. How can you not see that huge block space is a big target for anyone with enough funds to start a spam attack and clutter the network? (I mean, someone serious, unlike the Bitpico scammers)

After millions were spend in a hype attempt for Bcash, it's hard for them to understand they are continuously pissing against the wind.
In truth I also don't understand why would somebody buy an over-hyped altcoin with no real use nor special functionality at 450$ a piece.
Your Dogecoin example is pretty good, although Dogecoin still has a nice community which I am not sure Bcash has.

[Red-Apple]

Congratulations... We can have huge blocks and our 0 confirm transaction system is not less secure because of segwit.

0 confirmations were NEVER secure, only an idiot would think otherwise.

The fact that you have huge blocks and the usage is even less than Dogecoin should really make you think twice. How can you not see that huge block space is a big target for anyone with enough funds to start a spam attack and clutter the network? (I mean, someone serious, unlike the Bitpico scammers)

there is no point spam attacking something that is not used. a spam attack requires incentive so that the attacker gains something out of that attack. it is never done for trolling or having fun! LOL
for example the spam attack against bitcoin had multiple possible reasons: altcoin pumpers pumping their altcoins with the premise that bitcoin is slow and they will replace it. big blockers spamming bitcoin to say we need bigger blocks. the miners spamming bitcoin to earn more fees as the fees went to the moon. government agents wanting to destroy bitcoin or at least slow down its adoption.

but what would you gain by spamming BCH?!!!

[2fresh]

BCH average block size is 50 KB and although is only 3% of Bitcoin beside this Bitcoin has average 1.3 MB block size. But I believe BCH has the potentialities to go forward for its unique features.

Changing block size is unique? Been there done that.

[franky1]

a 2.26mb block..
but such a shame it doesnt amount to 5000 transactions on such a big block.
such a waste of space. only a couple hundred transactions for over 2mb of space.

development still required me thinks

[NeuroticFish]

development still required me thinks

That's correct. I've read somewhere that Schnorr signatures could reduce the transaction sizes by some 25% (average) and would also add more privacy.
I don't know yet if there are unwanted side effects in that though... We'll live and see...

[davis196]

I don't think that Roger Ver cares about the BCH block size.It's all about the money,not about the technology.
BCH can still make him a few millions worth of USD,despite the fact that bitcoin cash is a shitty altcoin.
The "scaling" debate is now over and bitcoin core won.

[dadach]

I don't know how anyone could fall for that BCH propaganda they are pushing.

[Wind_FURY]

development still required me thinks

That is true. I believe that the development on the network's latency, block propagation, and "time-locked, off-chain" transactions should be first explored before making a development roadmap for increasing block sizes.

But Segwit is in the right direction in my opinion. Because with it will come other inclusive soft forks like Schnorr that would improve on-chain scalability.

[franky1]

development still required me thinks

That's correct. I've read somewhere that Schnorr signatures could reduce the transaction sizes by some 25% (average) and would also add more privacy.
I don't know yet if there are unwanted side effects in that though... We'll live and see...

But Segwit is in the right direction in my opinion. Because with it will come other inclusive soft forks like Schnorr that would improve on-chain scalability.

ok heres a lesson for you both
the 1mb limit still exists in the bitcoin core network.
transaction data needs to sit in the 1mb limit. but Segwit lets signatures sit outside.
the reason the block in this topics example is what it is.. is because alot of signature data sits outside the 1mb area. but.. that leaves space inside the 1mb are.. hense why the OP's example only has a few hundred transactions as oppose to a couple thousand

schnorr will reduce the amount of signatures thus bring down only the witness area weight. but it still does not sort out the limitation of the 1mb area

what needs to happen is completely remove the 1mb limit so all the legacy transaction data can utilise the entire 4mb weight. which then means we actually get more transaction capacity per mb (4x with a true no hidden sublimit, 4mb block)

the math was already done and the consensus is if EVERY transaction was a LEAN SEGWIT. the best hope would be 2.1x increase of transactions.

but at the moment it still sits at only 10% segwit utility.
(i know people will say its 40%. but thats not the case. the graph showing such treats a mixed tx of legacy and segwit as a full segwit which misleads the reality of real statistics)

in short. if schnorr was used the OP's example would still only be a couple hundred transactions but the weight outside the 1mb limit would be less.
meaning schnorr is not scaling. is unbloating the bloat of the 'witness' area

[NeuroticFish]

transaction data needs to sit in the 1mb limit. but Segwit lets signatures sit outside.
[...]
in short. if schnorr was used the OP's example would still only be a couple hundred transactions but the weight outside the 1mb limit would be less.
meaning schnorr is not scaling. is unbloating the bloat of the 'witness' area

I think (you know better the internals than me, so correct me if I'm wrong) that for non-SegWit transactions the signatures are still inside the 1MB.
And since most transactions are still not SegWit, shouldn't you revise that math? Just telling.

[franky1]

transaction data needs to sit in the 1mb limit. but Segwit lets signatures sit outside.
[...]
in short. if schnorr was used the OP's example would still only be a couple hundred transactions but the weight outside the 1mb limit would be less.
meaning schnorr is not scaling. is unbloating the bloat of the 'witness' area

I think (you know better the internals than me, so correct me if I'm wrong) that for non-SegWit transactions the signatures are still inside the 1MB.
And since most transactions are still not SegWit, shouldn't you revise that math? Just telling.

i done loads of math..
but if you are talking about schnorr being used in the OP's example. well th tx count would still be the same but the 'weight' (bit above the 1mb will be less
schnorr wont affect tx count. schnorr only reduces signatures of. SEGWIT transactions

[franky1]

transaction data needs to sit in the 1mb limit. but Segwit lets signatures sit outside.
[...]
in short. if schnorr was used the OP's example would still only be a couple hundred transactions but the weight outside the 1mb limit would be less.
meaning schnorr is not scaling. is unbloating the bloat of the 'witness' area

I think (you know better the internals than me, so correct me if I'm wrong) that for non-SegWit transactions the signatures are still inside the 1MB.
And since most transactions are still not SegWit, shouldn't you revise that math? Just telling.

again the area outside the 1mb area is just for signatures and more precisely just signatures of segwit addresses
for non segwit INPUTS the signature of it sits inside the 1mb BASE BLOCK
for segwit inputs the signature sits outside
but in both cases the input and outs, values etc still sit inside the 1mb

EG imagine one tx of 4 inputs
1Am4deup4ddr3555
bc1qM4d3up4ddr355
1Am4deup4ddr3555
1Am4deup4ddr3555

only 1 signature sits outside the 1mb output. yet the people that do stats of sgwit utility would treat that tx as 1 segwit tx. when reality shows it as 0.25 segwit

as for the byte for byte movement
they want to make it feel like the transaction is 4x smaller inside the 1mb area.. (the fake news that it can fit 4x more transactions) the reality is that there is less than 72byte decrease in the 1mb area

im not gonna go full anal precise math..
ill just give you an example where we say a signature is 70 bytes and the whole tx is 630bytes
                                                  1mb  base          3mb witness
4x legacy inputs                     |       630bytes     |       000bytes      |
3x legacy 1 segwit inputs        |       560bytes     |       070bytes      |
2x legacy 2 segwit inputs        |       490bytes     |       140bytes      |
1x legacy 3 segwit inputs        |       420bytes     |       210bytes      | *
4x segwit inputs                     |       350bytes     |       280bytes      | **

now here is the thing
the most leanest 1in 1 out is about 180bytes (again im simplying)
*you can fit in 1 lean segwit or 1 lean legacy
**you can fit in 1 lean legacy or 2 lean segwit
but you cant fit in  another tx of the same 4input size as above
so although there is 4x space. its not 4x capacity

now what the OP's example done was use multisigs imagine each input was a 2sig multisig meaning the first 4xlegacy input is now 910 byte (again over simplifying)
                                                  1mb  base          3mb witness
4x legacy inputs                     |       910bytes     |       000bytes      |
3x legacy 1 segwit inputs        |       770bytes     |       140bytes      |*
2x legacy 2 segwit inputs        |       630bytes     |       280bytes      |**
1x legacy 3 segwit inputs        |       490bytes     |       420bytes      |***
4x segwit inputs                     |       350bytes     |       560bytes      |****

as you can see. now if all inputs were segwit and were multisig. you could fit in another
*1 lean 1in1out segwit tx
**1 lean 1in 1out legacy tx or 2 lean 1in1out segwit tx
***3 lean 1in 1out legacy tx or 3 lean 1in1out segwit tx or 1 4in segwitmultisig tx
****3 lean 1in1out legacy... or 4 lean 1in1out segwit.. or ... 1 4insegwitmultig tx with 1 lean 1in 1out segwit

but here is the thing.. to be able to get the 4 lean 1in 1out segwit. it requires the bloated segwit multisig
you will not gt another 3 or 4 tx's in if the other transactions were lean or standard to begin with.


ill explain
imagine the whole block was the lean legacy 1i1o (180bytes each)
max transactions = 5555 tx (kep this number in mind)
no block has ever been 5555tx. because not everyone uses the compressed keys of single 1in 1out
anyway
if the whole block was lean segwit 1i1o (110base 70witness)
max transactions = 9090tx  (not 4x capacity, not even 2x capacity) base=1mb witness=0.636btc (1.636mb weight)

imagine the whole block was 4in1out legacy but not multisig(630byte each)
max transactions = 1587tx
if the whole block was segwit 4i1o not multisig
max transactions = 2857tx (again not even 2x)
..
but here is the statistics cheat
lets take just 1587 4in1ou.. mak then all segwit.. and then throw in loads of lean 1in1o segwit
max transactions = 1587 4in tx  AND 4041 lean segwit 
so thats 5628 transactions  which is base=1mb winess=0.727mb witness (1.727 weight)
and as you can see not 4x capacity of the same format but just 3x of leaned small tx. (and thats the trick)

now lets do the multisig (910 bytes)
legacy multisig=1090 transactions
segwit multisig=2857 transactions
(as you can see thats 2.8x but only if the whole block is as such. but its only 2857 tx.. not 5555tx or 9090tx )
so although it looks like a bloated multig can get you 2.8x simply by converting every tx to segwit.. there is less tx to start with
anyway. lets take the 1090 multisigs. convert them to 1090 segwit multisig and then fill the spare space with lean 1i10 segwit just to do the same stats cheat
1090 sw multig + 5622lean = 6712 transactions. which is base=1mb witness=1mb (2mb weight)

so although it apears that your getting in 4x transactions. thats not 4x transactions of similar type.
and its not 4x transactions of the 5555tx of lean block.

its like imagine a bus of adults.. kick 1 adult out.. another adult gets a seat. but this time they are saying. noo lets let in 4 midgets to twist the statistics

where as the reality is real use of real tx's are not lean and there will never be ample supply of midgets

yet. if the block was 4mb of space for legacy to use.
you would get
4mb full use= 22,222 lean 1i1o transactions
4mb full use= 6349 of 4i1o transactions. (as oppose to 2857 in the segwit base|witness split)
4mb full use= 4395 of 4i10 multisig transactions (as oppose to the 2857 in the segwit base|witness split)

summary
you get more transactions in (without lean trickery to up tx count) per byte via a 4mb full access block rather than the base|witness limitation of a same pseudo 4mb 'weight'

in short get rid of the 1mb base limit so all transactions can really and properly use the 4mb 'weight' and then we can have more transactions
and yes. we can mix some of the multisigs and lean tx's to get more than 6349 and 4395 tx's listed just above the summary to also play the tricks and get closer to 20,000 transactions

[Wind_FURY]

development still required me thinks

That's correct. I've read somewhere that Schnorr signatures could reduce the transaction sizes by some 25% (average) and would also add more privacy.
I don't know yet if there are unwanted side effects in that though... We'll live and see...

But Segwit is in the right direction in my opinion. Because with it will come other inclusive soft forks like Schnorr that would improve on-chain scalability.

ok heres a lesson for you both
the 1mb limit still exists in the bitcoin core network.
transaction data needs to sit in the 1mb limit. but Segwit lets signatures sit outside.
the reason the block in this topics example is what it is.. is because alot of signature data sits outside the 1mb area. but.. that leaves space inside the 1mb are.. hense why the OP's example only has a few hundred transactions as oppose to a couple thousand

schnorr will reduce the amount of signatures thus bring down only the witness area weight. but it still does not sort out the limitation of the 1mb area

what needs to happen is completely remove the 1mb limit so all the legacy transaction data can utilise the entire 4mb weight. which then means we actually get more transaction capacity per mb (4x with a true no hidden sublimit, 4mb block)

the math was already done and the consensus is if EVERY transaction was a LEAN SEGWIT. the best hope would be 2.1x increase of transactions.

but at the moment it still sits at only 10% segwit utility.
(i know people will say its 40%. but thats not the case. the graph showing such treats a mixed tx of legacy and segwit as a full segwit which misleads the reality of real statistics)

You mean blocks, not transactions, right? But did the 40% Segwit adoption graph from segwit.party, before it went down, mean transactions? I believe it did.

in short. if schnorr was used the OP's example would still only be a couple hundred transactions but the weight outside the 1mb limit would be less.
meaning schnorr is not scaling. is unbloating the bloat of the 'witness' area

But it helps in scaling. "Scaling" a decentralized network should start in finding solutions for better network latency and data propagation before block size increase proposals. But if you want a short cut, Bitcoin Cash is ready.

[NeuroticFish]

EG imagine one tx of 4 inputs
1Am4deup4ddr3555
bc1qM4d3up4ddr355
1Am4deup4ddr3555
1Am4deup4ddr3555

only 1 signature sits outside the 1mb output. yet the people that do stats of sgwit utility would treat that tx as 1 segwit tx. when reality shows it as 0.25 segwit

You spent quite some time with all this and I did my best to follow, however, from start, this looked fishy. I mean, why on Earth would somebody keep in a wallet SegWit and non-SegWit addresses?
Then I looked into block 542,195 (it's the latest at the time of writing) and I found 5 or 6 transaction with SegWit and non-SegWit inputs (out of 1495). Hardly a case that counts. So your math starts with wrong basis imho. Most of those transactions actually have one legacy input.

So we are back to square 1.
We have transactions with legacy inputs and we have transactions with SegWit inputs.
The majority is still legacy, or at least not pure SegWit.

So the questions are:
1. All inputs legacy (1*) - where do the signatures stay? In the 1 MB, right?
2. All inputs legacy (1*) can't we use Schnorr sig and make space for more transactions?
3. All inputs 3* (P2SH nested SegWit) where do the signatures stay? Can't we use Schnorr sig and make space for more transactions?


Now, I know that 4MB > 1MB and it would fit more info, but it's not what I was asking about - maybe it was misleading because the thread was about the more info in a block and I tried to get some side-info.
To also have at least a part of the story on-topic:
You can't deny that with SegWit we are a step forward. Maybe in your eyes it's not a big step, but just think: it's in the right direction.
Maybe you remember that there were months of debate and the impression that the Devs are not doing anything and they are afraid to really touch the software. They touched it and since then new things are coming.
SegWit was a step. Schnorr sig may be another.
You say that this is not real scalability. You may be right, but if you think like that, 4MB is also not significantly better, it just buys a little more time. The solution is clearly something different and LN may be that solution, of course, when it'll become more robust. Until then, people are just happy that the fees are low, the network works fine and the solutions the Devs proposed really work.

[franky1]

You mean blocks, not transactions, right? But did the 40% Segwit adoption graph from segwit.party, before it went down, mean transactions? I believe it did.

But it helps in scaling. "Scaling" a decentralized network should start in finding solutions for better network latency and data propagation before block size increase proposals. But if you want a short cut, Bitcoin Cash is ready.

1. i mean transactions where if one input(UTXO) out of say 4input(UTXO). the whole transaction is classed as a segwit transaction instead of 0.25. then out of all transactions over one block or one day or one week whatever they say 40% are segwit and 60% have no segwit inputs at all

however. if they done it properly and said of all inputs(UTXO) being spent of (what the currently call a segwit tx) only 25% of a transaction is actually segwit.. then the result would be only 10% of all inputs(UTXO) being spend either per block or per day or per year, whatever would only segwit utilised

2, the halt on removing/increasing the base block limit is not about scaling bitcoin. its about making different networks famous by making bitcoin look bad enough that people should use other networks
for instance. 2 years have been wasted on features not to scale bitcoin. but to push people into using other networks.
yep 2 years to twist bitcoin to work with LN (ln is not a bitcoin feature. but a separate network for multiple coins to use in the future where LN will be seen as the payment tool for bitcoin and litecoin.

bitcoins whole purpose was that you dont need counterparties. you dont need the counterparties to be awake and responsive and requiring their authorisation to make payments..

but while 2 years+ have passed of doing nothing else but keep bitcoin where it is and just tweak bitcoin to be compatible with that separate network. nothing has been done to scale bitcoin.