Topic: Hello BCH: 2.26 MB & we keep 1MB (Read 368 times)

When a newbies come to invest, it is as usual that they have very poor knowledge about crypto worlds activity. They want to follow according websites or rumours.Their experience is very low for why they do so.They must be introduced with some genuine source and they have to know the fluctuations of market.

This is great news I want to give congrats. It will give a transaction of less value and give a high security. Thank you segwit you are doing a amazing job.

Ok, I will take a look in statoshi.info later and come back. "Do not trust, verify". Hahaha.

Can you suggest other explorers and sites to use to closely look at all the blockchain data? Thanks.


In your opinion, yes, but what would you have done that you believe might be better than Segwit if you were made to decide?

it was mentioned before.
a TX that is

1AmadeupAddress -> 1AnotherAdrress
1AmadeupAddress
1AmadeupAddress
bc1qaMadeupaddr

would be classed as a segwit tx. although its utility is not full segwit.
its actually majority legacy tx.

also that 240k tx is only 1666 average tx a block.. seems less people are making transactions than in the past...
(240tx for 24h =2.77tx/s..   hmm no where near the 'more than 7tx/s' )
oh and ofcourse there are merchants and core that without user consent are defaulting spend/change addresses to be segwit. thus the numbers are fudged, not by choice but by default

a better metric for segwit utilisation was to view the UTXO set and count the UTXO's that are 'iswitness' i guarantee you its less than 40%... but that would be biased because it includes funds people havnt moved since segwits mandatory activation
..
so lets just take the block data of september 22.. like you did
statoshi.info shows under 24%(23.81) of full data is in the witness area. . dang not 40% on the 22nd.. hows about that.
 but we all know that a segwit signature is 82 bytes instead of 72 bytes. so the utility of segwit is <24% but the efficiency of transaction per byte due to segwit is even less than than that

the whole codebase of core is all wishy washy. add a few bytes here hide a few bytes there.. multiply some bytes by 4.. treat an entire tx as segwit even if only a certain amount is actually pushed outside the 1mb area.. is all just wishy washy

but have a nice day

i know im gonna expect a reply where a block is shown that has 40% 'iswitness' 543172 today(26th sept)
and i can can show another block thats well under 10% 'iswitness'543169
and we can spam post that all day long. different blocks.. but the average is 23.62% for the week..
but the end thing is. its been a year and less than 40%(lets just be realistic and call it what it is 24%) of the community are using segwit.... same result as the pre segwit . where less than 40% were flagging as wanting segwit (before the mandate threat and 3 card game trick)

Going back to this topic, I found the data the proves you are wrong or might be gaslighting again, http://charts.woobull.com/bitcoin-segwit-adoption/

The data shows that the total daily transactions in the network on September 22 is 240,000 txs, and Segwit transactions are 96,000 txs, making up 40% of the total.

I see it as a service layer on top of Bitcoin network - it still needs Bitcoin network for starting and ending the nodes - a layer that will be used by everybody, if they'll want to pay their coffee directly with Bitcoin.
I expect that there may be a good chance most people will use "web wallet" like services to access this feature, but on the other hand (too) many also use them now too for no good reason.


LN can help with scaling - it will be able to handle a much bigger number of Bitcoin transfers (let's not call them transaction to avoid a mix-up) and it's about Bitcoin. It's enough for most. People don't have to get THAT technical to use Bitcoin, really...


LN is .. beta? Or not even beta? Unfortunately the expectations over LN are too big - even as implementation time frame.
I don't think they intend to launch it with flaws.


Sorry to disappoint you, but I don't care much of such things.


OK. This was all I needed, the fish example was, although funny, not necessary.
I somehow hoped the "gain" is bigger. Oh well...


LN will be there for speed. For small amounts and fast. For the rest, or if you just simply don't want to use LN, Bitcoin network will still be there.
Even now, if you don't want to use SegWit or just don't care about it, everything should still work.


Interesting point of view, sorry that I thought you are Bcash-er.
Bitcoin is what the majority take as Bitcoin. Today they expect CORE / devs' lead. If they'll do something really bad, or start doing nothing, their "reign" will end.


Bugs do happen, unfortunately. Self-sufficiency may get them found late, indeed, but it happens.
You may be a bit too harsh...

Ok. But it is strange that no one tried to make this argument before. I will try to confirm this with someone who knows.


Lightning is NOT a separate network. Why are you gaslighting?


Yes you can always do it on the base layer, no one is removing that "feature".


This is a lie.

now here is something to think about thats not anal about math or techno jargon.
so it easy to think about.


but please without anyone wearing the core team fan defence cap
and with instead the bitcoin network innovation hat (and i dont mean separate networks like merge mined coins, side chains or second layer services wanting bitcoin fame)

think about this


if someone gave you a banana that could only give 2000 nibbles of nutrition and it cost 10 cents per nibble, which used to only cost under 1cent per nibble before a GMO messed with the delivery pricing structure

and a GMO company said it would take a couple years but we can give more nibbles per banana and delivery would be less..

would you after 2-3 years when presented with a segnana which is physically bigger but offers less nibbles per mouthful
and now costs 27cents for each nibble. and then handed a glossy leaflet for a LemoN that is segnana nutrient compatible as well as LeTtuCe nutrient compatible that promises to do more, but will take a further few years

would you still celebrate the GMO's on their initial promises?

I don’t know this news. It’s very positive news for the crypto market and also have positive impact. If it is true then we are more secure than before.

i see LN as a niche service outside the bitcoin network and something that only gamblers faucet raiders and multispenders per day will benefit from.(if they ever sort out the issues)
i see it sitting in the same 'layer' as coinbase.

LN is not a bitcoin feature. its a separate network/service and will be used by people holding multiple currencies

however LN is being promoted as "the" bitcoin feature that everyone will have to use as its "the" scaling solution and problem solver for the bitcoin network.

LN is buggy. i have informed them of many bugs and although they wont admit the source they have tweaked a few things to stop a few things.

but if you ever happen to listen into some of the hidden chatter between devs and their banking partners. and if you ever learned about the banker contract with devs from november 2016 november 2017 and its true purpose of how the bankers are to eventually make ROI of their investments (phase 1 segwit phase 2 LN) you will see a shocking roadmap of central control and deception that is turning bitcoins open community ethos of what people thought bitcoin was about in 2009. into a future banker fortknox replication of what happened to gold a century ago
in short
too many people are promoting that LN is the central network everyone will need to use. rather than a side service outside the network for those niches that may want to use it

actually i was very anal
there is actually a difference between a legacy 3* multisig and a segwit 3*
and i did factor that in.

as i said if they were all pre segwit formats. we could fit in 60k of more transactions in and still have the same 606kb block as you shown.
again legacy segwitmix of the 606kb block = transaction size average 405byte
de-evolving the segwit transactions to their reciprical legacy format retaining input and output and signature count
= a 540kb block of same transaction numbers. = 361 byte average transaction size
which means if the (base block) was happy to hold all 606kb would result in 1678 transaction simply by devolving the segwits into legacy

think of it this way.
a FISH bowl of fish(inspired by your name)
a lgacy fish is 3.6cm long from nose to tail
segwit does not make fishes leaner to allow more fish into the bowl.
segwit cuts off the tail and puts the tails into another fishbowl. but now the tail-less fish need to be fatter to balance and able to continue swimming. so then if you reattach their tail would be 4cm long each
meaning if you looked at the 2 bowls as a whole. each fish is 4cm long because of segwit.
the deception is the glass wall making people think the tail bowl does not exist. and tails should not be counted.
but on the mantle piece the bowls sit on. the weight does matter. and both bowls do count
(but on the hard drive the 2merkles are stored on. the megabytes do matter and both merkles do count)

and when you calulate the weight on the mantle/actual mb on the hard drive vs the number of fish/transactions
the cutting the tail but bloating the fish does not = more fish


2.26mb for only a couple hundred transaction is a positive! ! !
im facepalming right now

as for your hope for LN. well thats the reliance of people hoping for moving their funds to then lock them into fatories and take away bitcoins ethos of a payment network. and thus destroy bitcoins revolutionary concept. and let people think the only way to pay is co-signed accounts.. (backward thinking)

remember LN is not a bitcoin feature, its a separate network. many coins will use LN. its not a sole feature of bitcoin and is not promoting bitcoin. its killing bitcoin and the propaganda of saying its part of bitcoin is purely to make LN famous while saying bitcoin is broke.

they are just pretending its a bitcoin thing to get attention on LN(aswell as investment)

i am 100% a bitcoiner
the issue is too many people think CORE is bitcoin.

i dont mean cash is bitcoin.
i mean no one should be bitcoin

i am not a cash promoter, i dont spend it i dont use it i dont mine it.
i simply dislike the devs of core.

if you can separate the human devs from bitcoin core network.. because its those devs who are saying bitcoin is broke, cant scale and ln is the future. you will understand
i dislike the human core devs

but i am 100% in and devoted to the bitcoin core network

.. as we can see. the core devs are not perfect. they had a bug in the code for 2 years that not only caused the same assert() crash that they dramatised against BU last year. but the bug core devs introduced 2 years ago can actually cause EXCESS coin creation

so i say this (remember this is about the monarchistic team not the network)

can all core fans now admit core are not perfect and diverse teams of multiple code bases all on the network as a consensual level playing field would have been beneficial than the monarchy core has became

its time the community admit, its time to diversify the network and release core from a leadership(reference) position

diversity + distribution = decentralised network
distribution alone does not = decentralisation

(expect my post to get deleted as its not core friendly)

If I ignore the usual Bcash commercial that surrounds your explanation, it is really useful and helped me understand this and that. The merit I gave is for the useful part of the post


Thank you.


It was just perfect. Shame I didn't pick a more crowded block, like at least the "previous" one, but hey, this does the job too.


Interesting, but on another hand, bc1* are leaner than 3* SegWit, right? Maybe that's why they said 'leaner'.


Probably. However, people either don't understand, either don't care or just fine with that. I am "just fine with that". I see it as a service people can use if they want to. And an useful one (when it'll work) and one that should get the overload, hence help with the scalability. I see it as a better option than another fixed block size.


Here I need a clarification: I think that you counted only bc1 addreses as SegWit, while many (me included) use 3* addresses for SegWit purpose, to avoid issues with various services that don't handle SegWit yet.
Also, I know that SegWit is not as widely used as it should be. But hey, it's only some 1 year old?
 

It looks indeed like a waste, but again, you may have missed 3* addresses (which I know, may or may not be SegWit).
Also, on the bright side, it still saves space where it matters.


I guess that we look at the bright side and you don't
In my opinion, the great thing is that we have again blocks that are not full and the fees are most of the time very low. And when LN will be ready, then I'd think to throw out a competition, since people seems love them. Until then, I know, there are plenty of altcoins that can handle more transactions per day than Bitcoin. So what? We'll get better

Roger Ver is an advisor that is pretty much paid to shill whichever project he happens to be affiliated with at the time, quite successfully I should add. Segwit will be enough for now, especially since the market volume has died down as of late, but we will definitely need some second layer solutions if we see the volume that was happening last Dec.

1. yes
2. that would help. but looking at the devs proposals they don't want to break legacy transactions as thats another hard fork (oops i mean another mandatory ban/reject or else convoluted threat pretending to be a 'soft USAF)
and only looking to soft fork schnorr in to be used by segwit multisigs (only multisigs benefit anyway. and modifying segwit multisigs are easier to trojan in modifications than it is to modify legacy multisigs(3*(emphasize legacy 3* not the segwit version of same prefix))

3. if its segwit, signatures sit outside the 1mb base

(i tried not to go math anal in previous posts) or be too biased. or be too complicated.. but here goes (sorry to say this)
as for the block that you mentioned at the time of you posting
out of the 606kb only 102kb sat outside the baseblock (16% data)

oh and doing more math
a legacy 1in 2 out is ~225byte
a segwit  1in 2 out is ~250byte

yeo ~25 byte difference.
the reason being that a segwit signature is ~80 bytes not 70(82 vs 72 to be more exact)

and the input address bc1q uses a few EXTRA bytes (plus a few other details that waste a few bytes)
yep they are making signatures/addresses more bloated (i laugh when they say they words like 'efficient' leaner')
just to swap and twist things around to be able to move signatures.

but this whole game they are playing is not for scaling onchain purposes.. but for transaction formats that are compatible with LN
LN is not a bitcoin feature. its a separate network that many coins will use. (something most dont realise and just co-brand it with bitcoin to give it attention)

anyway.. knowing that segwit adds bytes to inout addresses and signatures

i did further maths. and converted all the inputs and outputs to be just regular 1*addresses byte usage instead of bc1q* byte usage
and i also brought the actual segwit signature back to regular legacy (72 as oppose to 82)
(note yes i went anal and only touched the addresses/signatures that were segwit... i wasnt lazy to just deduct Xbytes from all inputs outputs and signatures.)

and guess what.
the 1495 tx block you mentioned would only be 540kb. if segwit did not exist
so although the data as it sits in the block on the network with mix of legacy and segwit has
504kb in base and 102kb in witness area,
if segwit did not exist. that same data of number of inputs, outputs, sigs would sit at 540kb total (not 606k total)
meaning. the "omg segwit saved 102k in base.." is actually
OMG saved 40kb in base but added 102kb into witness

yea. that data would have only been 540kb if all were legacy
so the base block saving is only actually 40kb

kinda funny when you look at it from that perspective, right..

so a 1495 tx block. where the base saving is only 40k. is less than 10% actual scaling utility

hope the math or the explanation hasnt confused you

but hey..
if you think its still good to celebrate the OP's title that 2.26mb only = a couple hundred transactions.. then you've missed all the issues with "2.26mb for only a couple hundred transactions".. to me thats NOT something to be proud of

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.

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.

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.

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

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

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.