Are blockchain tracking sites tracking Segwit adoption wrong?

[Wind_FURY]

I got into a debate with franky1 some weeks ago in this thread, starting with this post, https://bitcointalk.org/index.php?topic=5026399.msg45926698#msg45926698

He claimed that websites like segwit.party were misleading everyone, and that Segwit adoption is only 10%, not 40%.

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)

I replied with this.

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.

Then he replied with this which confused me, because why would those websites be misleading us? Plus why isn't there anyone calling this issue out?

Can it be proven that there is only 10% Segwit adoption? How?

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

[1713915451]

1713915451

[1713915451]

1713915451

[piotr_n]

I think the best way to measure "Segwit adoption" is to look at how many segwit txs are inside the recently mined blocks.

Taking the last 1008 blocks (about one week of time) - up to block #546129:

There were 685908 segwit out of all 1727116 (non-coinbase) transactions - which means that about 39% of all mined transactions have been of segwit type.

If you look at the size (instead of tx count), you get 472263476 out of 984012845 bytes, coming down to about 47% of blocks' transactions space being used by segwit type.

[HeRetiK]

Transactions can include inputs from both legacy as well as SegWit addresses. As soon as a transaction includes a single input from a SegWit address, the whole transaction needs to be sent in the SegWit format.

Looking at the code in the repository posted by ETFbitcoin above, that's all that segwit.dance is checking for:

Code:

if txraw[8:12] == '0001':  # segwit tx has 0 inputs and 1 output
   txsegwit += 1

https://github.com/prusnak/segwit.party/blob/gh-pages/charts/extract.py

Unless I'm missing some additional data processing there's no weighing going in terms of how many inputs came from legacy addresses and how many inputs came from SegWit addresses.

So yes, frank1 is right in that a transaction is counted as a (full) SegWit transaction regardless of how many legacy inputs are involved. I'm not sure if I'd call it misleading though as from a protocol view a SegWit transaction is simply a SegWit transaction as soon as a single SegWit input is included. As such the data is pretty straight forward and a fairly reasonable metric to use.

If it's a useful metric for defining SegWit adoption is up for debate of course. But what does SegWit adoption even mean? eg. SegWit transactions weighted by input ratio, percentage of blockweight taken up by SegWit transactions, count of used SegWit addresses, bitcoins stored in SegWit addresses...? I guess you'd have to use a mixture of multiple metrics to get a clearer picture. The conclusions would still be a question of interpretation though.

[Wind_FURY]

Thanks Heretik. Would it then be fair to postulate that some people or organizations that say that Segwit is more "adopted" than Bitcoin Cash are wrong, or maybe biased, based on their interpretation of the data?

Take a look at this.

https://blog.bitmex.com/segwit-vs-bitcoin-cash-transaction-volume-update-bitcoin-cash-investor-flow-update/

[HeRetiK]

Thanks Heretik. Would it then be fair to postulate that some people or organizations that say that Segwit is more "adopted" than Bitcoin Cash are wrong, or maybe biased, based on their interpretation of the data?

Take a look at this.

https://blog.bitmex.com/segwit-vs-bitcoin-cash-transaction-volume-update-bitcoin-cash-investor-flow-update/

I don't think so.


First of all, the graph above would need to be cleaned up regarding the Bitcoin Cash stress tests mentioned in the article:

The Bitcoin Cash numbers are somewhat skewed by the “stress tests” which occurred in August 2018 and then September 2018.

Anyone who would use the graph above to "prove" Bitcoin Cash transactions catching up to SegWit transactions would be biased in their interpretation of the data themselves.


Secondly, in this discussion so far we have only established that weighting SegWit transaction count based on the ratio of legacy vs SegWit inputs may be a more objective metric. As of now we haven't even checked the difference between weighted SegWit transaction count and simple SegWit transaction count. Put differently I'd love to see the data on which franky1 bases their claim of SegWit transactions being on average only "0.25 SegWit".

Looking at the last few blocks I see that the majority of transactions (I guess > 95%) consist of either legacy transactions only or SegWit transactions only. The mix of SegWit and legacy inputs seems to be rather rare, at least rarer than to have an impact of the magnitude as described by franky1.

Obviously one would need to take a larger sample than the manual look that I just did, but the point is: Without any data to back it up, franky1's claim of SegWit adoption being only 1/4th of what most statistics tell is a baseless assumption. If I missed the part of discussion where actual data is used to prove this claim (ie. a weighted SegWit transaction count or the amount of "mixed" SegWit transactions) please link me up.

[Wind_FURY]

Obviously one would need to take a larger sample than the manual look that I just did, but the point is: Without any data to back it up, franky1's claim of SegWit adoption being only 1/4th of what most statistics tell is a baseless assumption. If I missed the part of discussion where actual data is used to prove this claim (ie. a weighted SegWit transaction count or the amount of "mixed" SegWit transactions) please link me up.

It might be another one of his gaslighting. I used to listen to him and ask him and JolandFyookball a lot of questions because they gave the "other side's" perspective, now I'm debating him almost everyday. Hahaha.

But as usual I will give him the benefit of the doubt and ask him to explain how he got his data.

[gmaxwell]

piotr_n basically answered the question decisively above based on his own analysis-- work that any of you could also reproduce.  He gave numbers in terms of percent of transactions spending one or more segwit inputs (so segwit using, by definition) as well as percentage of bytes.

As usual franky1 is trying to bamboozle people, by arguing someone isn't using segwit yet when they still have some older outputs they're spending that haven't yet become segwit outputs.

If you want to talk about users adopting segwit for their own transactions then figures like piotr_n's are exactly what you should be looking to.  If you want to, instead, talk about the resulting capacity increase then either the ratio of block size to weight (e.g. number of transactions is irrelevant) or the typical minimum fee rates to get into blocks are interesting.

[Gozzy]

I got into a debate with franky1 some weeks ago in this thread, starting with this post, https://bitcointalk.org/index.php?topic=5026399.msg45926698#msg45926698

He claimed that websites like segwit.party were misleading everyone, and that Segwit adoption is only 10%, not 40%.

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)

I replied with this.

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.

Then he replied with this which confused me, because why would those websites be misleading us? Plus why isn't there anyone calling this issue out?

Can it be proven that there is only 10% Segwit adoption? How?

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

Bech32 Statistics; https://p2sh.info/dashboard/db/bech32-statistics?orgId=1&from=now-1y&to=now

Segwit Usage; https://p2sh.info/dashboard/db/segwit-usage?orgId=1&from=now-1y&to=now

Seem's pretty viable in relation to all the other references, they have a number of viewable parameters like OP_RETURN usage etc

Enjoy

[franky1]

you open a topic to talk about me.. but then delete a post with me supplying some info.. hypocrisy

peak total UTXO 52mill (03 jun)
peak segwit utxo 560k (11 july)

current total UTXO ~50million
current segwit UTXO under ~90k

chart of last 6 months (source data)
all segwit utxo - https://p2sh.info/dashboard/db/bech32-statistics?orgId=1&from=1524780395012&to=1540591595014&panelId=3
al combine utxo - https://statoshi.info/dashboard/db/unspent-transaction-output-set?panelId=6&from=1524780395012&to=1540591595014

screw it lets even do you lot a favour lets just use the exact date where segwit had highest level
july 11th......... hmm not even 2%

segwit had a 6x DROP in utility on july 12th-14th

even the stats show since then total utxo went from 49mill(under, but i rounded up in your favour) to 50mill
yep the network acumilatd an extra 1mill UTXO.. yet did that mean that out of the 1m new UTXO more than 40% of new UTXO were segwit...

hmm nope segwit remained(emphasis) below 100k segwit UTXO

come on let logic prevail
if something gains 1mill and that new million of data should be 400k new segwit.. just to be 40% right?
but segwit did not grow by 40% in the last 3 months

i should have said 0% growth of segwit..(as it stayed flatline of ~90k segwit in the last 3 months)
but i done you a favour by counting the STAGNANT 90k as a rounded up 100k(one favour to you)
and made it as 10% utility in the last 3 months(1mill growth of all utxo and flatline rounded up 100k segwit)

have a nice day

[franky1]

The data you showed about measuring SegWit adaption by comparing SegWit UTXO count and all UTXO count to track SegWit adaption which IMO it's inaccurate because :
1. Many people who lost their Bitcoin before SegWit activation/usage
2. Microtransaction and faucet on Bitcoin was more popular and thus create lots of non-SegWit UTXO

Besides, we're talking about measuring SegWit adaption by comparing SegWit transaction and total transaction on each blocks (and average it each x blocks or x time unit), even though we're not sure if sites get the percentage by comparing count of SegWit output with count of all output or count of transaction which have SegWit output with count of all transaction in a block.

data i showed is the last 6 months so
1. your number 1 excuse does not apply/make sense because segwit is more than six months of being active
EG analogy someone shows birth/death records for the last 6 years. and then you come and mention an excuse of birth/deaths of 13 year ago.
... excuses may have been better if it explained the events of july/august(within chart date) not make an excuses about something before the chart date

2. yes that can explain the non segwit chart of the 49-52mill waves of utxo. but the segwit flatline should also be growing/moving changing. and doing so at a rate of X
obviously if more are using segwit, the segwit utxo should be increasing in the last 3 months


anyway il be devils advocate..
pro segwit campaign tips:
get segwit main dev sipa to pubish bech32 address on his website and bitcointalk profile
get segwit main dev/fan LueJR to pubish bech32 address on his bitcointalk profile
get segwit main pool fan BTCC to use bech32 address for coinreward (yea i understand that btcc is dying out after dcg purchase)

as i found it funny that they themselves are not using such addresses even when being so pro segwit

[gmaxwell]

comparing SegWit UTXO count and all UTXO count

Also, when P2SH embedding is in use (which is AFAIK by far the most common) you will mistake an output for non-segwit until its spent (and of course, once spent it doesn't get included in that count...).


Also the later posts indicates that the poster you're responding to is deceptively only counting non-embedded outputs as segwit.  Of course those aren't common-- they're not universally supported, so if you want people to pay you you don't generally use them yet.... p2sh embedding exists because it took years until everyone could reliably send to p2sh addresses... So segwit was introduced without a new address type to ensure it could be used instantly by anyone who wanted to use it, and so unsurprisingly that's primarily how its being used. (Later-- only after segwit was deployed-- a new address type was also created for the extra benefits it provides.)

To me it's becoming a little hard to swallow franky1's extreme dishonesty. Saying segwit adoption is low because a new address type specified a year after segwit isn't yet being that widely used in the face of almost half of all transactions using segwit and continuing to argue it after being patiently corrected isn't just an honest mistake.

[franky1]

comparing SegWit UTXO count and all UTXO count

Also, when P2SH embedding is in use (which is AFAIK by far the most common) you will mistake an output for non-segwit until its spent (and of course, once spent it doesn't get included in that count...).


Also the later posts indicates that the poster you're repsonding to is deceptively only counting non-embedded outputs as segwit.  Of course those aren't common-- they're not universally supported, so if you want people to pay you you don't generally use them yet.... p2sh embedding exists because it took years until everyone could reliably send to p2sh addresses...

(pre-empt any bad/false excuses about data)

chart isnt about the years prior.
chart isnt even created by me or anyone anti-segwit to even be biased data..
chart is from people on segwits side measuring a feature they like.. thus not biased data manipulated against segwit
chart is the last 6 months where segwit has been fully active.. yet in last 3 months the rise in utility has not shown growth.

funny part is greg is making excuses that segwit is now supposedly not getting adoption because people dont generally use it yet.
funny way to prove the point that was being made from the start that segwit is not over 40% adopted and not common and not universally supported.
gotta love gregs method of backtracking to now say something is not well supported

.....

a question that pro segwit adoption campaigners should really be asking is
'what the hell happened on july 11th -14th that literally killed off segwit adoption'

.....

but with greg showing that it takes years to adopt something, just makes things worse. devs went for a route that would take years(facepalm)
rather than a onchain scaling boost that could have already allowed real onchain extra proper tx space for proper transaction count growth (efficient byte per full tx on hard drive space of a full validating blockchain)

(pre-empt reply before 'stripped blocks' excuse)
yep segwit transactions(full data) are not byte for byte more efficient compared to legacy tx either

(pre-empt reply before segwits function was for LN compatibility)
yep we all know that the core roadmap decided an alternative network of non-blockchain design(no byzantine general solution) is what was decided as the multi year delay plan.
and the onchain scaling was only a 'side effect' (now proven not even that effective, although still advertised as a feature)

where this separate network is not even a sole bitcoin only feature. but a universal separate network for any compatible coin(thus not a 'bitcoin layer' but a fully separate network for any coin that is LN compatible)

[HeRetiK]

Ignoring P2SH addresses when discussing SegWit is rather deceptive, especially knowing that the majority of SegWit transactions still rely on P2SH addresses. Even moreso when one equates the lack of Bech32 adoption with a lack of SegWit adoption, which is apparently what is happening here.

The amount of bitcoins stored in P2SH addresses has remained rather static until the end of August 2017 (ie. the SegWit activation date). From thereon the amount of bitcoins stored in P2SH addresses continuously grew from a baseline of ~12.5% (ie. P2SH addresses that are likely unrelated to SegWit and can thus be discounted) to ~28.3% today (ie. ~15.8% of bitcoins are likely stored in SegWit P2SH addresses, assuming other usage of P2SH addresses didn't change significantly):

https://p2sh.info/dashboard/db/p2sh-statistics?orgId=1&from=now-2y&to=now


Meanwhile Bech32 has been dicking about at storing only ~0.8% of all bitcoins:

https://p2sh.info/dashboard/db/bech32-statistics?orgId=1&from=now-1y&to=now

...which comes to little suprise with the major hardware wallets not supporting Bech32 out of the box and many large exchanges not allowing withdrawal to Bech32:

https://en.bitcoin.it/wiki/Bech32_adoption

So that whole Bech32 situation is a mess but not necessarily reflecting the attitude towards SegWit itself.


Either way, without digressing further: Seeing how apparently ~16.6% of all bitcoins are stored in SegWit addresses (ignoring ~6.5% of bitcoins that haven't been moved for 3+ years of which part is likely forever lost [1]) we do get a different picture from purely tracking SegWit transactions -- tracked at a range of 30% to 50% [2], which is still the correct way to track SegWit transactions, whatever that may mean for adoption.

However no matter how you look at it we're also beyond the mere 10% as quoted in OP.



[1] https://bitinfocharts.com/top-100-dormant_3y-bitcoin-addresses.html

[2] https://p2sh.info/dashboard/db/segwit-usage?orgId=1&from=now-1y&to=now

[franky1]

heretic
X% of segwit tx, X% of segwit utxo, does not mean X% of btc coins. X transactions do not equal X coins

also P2SH tx's are not 100% segwit. they also include legacy multisig. thus again cause abstraction of real data by fooling people that combining legacy and segwit =segwit
(hint p2Wsh is more precise than just the p2sh category of mixed types)

that said. compiling data of transactions of segwit (bc1q & 'iswitness' 3addresses) is easy
but the excuses i have heard from pro-segwit campaigners for why the numbers are not higher. is just comedy
you cant hold one hand and say something is well supported and high. then in other hand say it takes years and people/exchanges have not yet adopted it... pick one hand and stick with it

but as i said the pro-segwit campaigners should really be asking these questions
1.why btcc,sipa, lukejr are not using bech32 addresses for coin rewards or donations
2. what happened in july 11th 2018
3. knowing segwit is not harddrive full tx byte efficient utility compared to legacy* when will bitcoin devs begin re concentrating efforts on onchain scaling of the bitcoin network?.. instead of twiddling thumps letting a separate network(LN**) take on the responsibility and only altering the bitcoin network to be compatible with a different network of multiple coin utility(LN)

*(dont harp on about stripped/compatible/filtered(choose own buzzword) blocks that are not validatible because signatures are not counted or available to validate a tx, thus are just pigeon english data of no bitcoin importance and used to decieve a node user as being a fullnode when infact they are not)
**(LN is not a sole bitcoin feature. nor a network that solves the byzantine generals issue(it has no blockchain/community audit in channel)

[HeRetiK]

X% of segwit tx, X% of segwit utxo, does not mean X% of btc coins. X transactions do not equal X coins

It does not. But I'm also neither referring to SegWit transaction, nor SegWit UTXOs but rather the raw percentage of coins stored in P2SH addresses as indicated by the stats above:

https://p2sh.info/dashboard/db/p2sh-statistics?orgId=1&from=now-2y&to=now

The one on top, "BTC stored", which is a rather clear-cut metric.

also P2SH tx's are not 100% segwit. they also include legacy multisig. thus again cause abstraction of real data by fooling people that combining legacy and segwit =segwit

Hence the baseline of ~12.5% which can be discounted as legacy multisig addresses:

The amount of bitcoins stored in P2SH addresses has remained rather static until the end of August 2017 (ie. the SegWit activation date). From thereon the amount of bitcoins stored in P2SH addresses continuously grew from a baseline of ~12.5% (ie. P2SH addresses that are likely unrelated to SegWit and can thus be discounted) to ~28.3% today (ie. ~15.8% of bitcoins are likely stored in SegWit P2SH addresses, assuming other usage of P2SH addresses didn't change significantly)

At the time of SegWit activation ~12.5% of bitcoins were stored in legacy multisig addresses. Looking back at a timeframe from August 2016 to August 2017 you see little to no growth as far as bitcoins stored in legacy multisig addresses are concerned. As such it stands to reason that the majority of coins stored in P2SH addresses since SegWit activation are most likely stored in SegWit P2SH addresses rather than legacy multisig P2SH addresses.

[franky1]

It does not. But I'm also neither referring to SegWit transaction, nor SegWit UTXOs but rather the raw percentage of coins stored in P2SH addresses as indicated by the stats above:

https://p2sh.info/dashboard/db/p2sh-statistics?orgId=1&from=now-2y&to=now

The one on top, "BTC stored", which is a rather clear-cut metric.

are likely stored in SegWit P2SH addresses, assuming other usage of P2SH addresses didn't change significantly)

 As such it stands to reason that the majority of coins stored in P2SH addresses since SegWit activation are most likely stored in SegWit P2SH addresses rather than legacy multisig P2SH addresses.

again your using mixed stats and presumptions based on.... pfft
so here is a clearer picture for you
https://p2sh.info/dashboard/db/p2wsh-statistics?orgId=1&panelId=2&fullscreen&from=1477510081999&to=1540754882003
(emphasis p2Wsh)
i will do you a favour though (check out light blue p2wpkh) it stats below
https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1&panelId=1&fullscreen&from=1333234800000&to=1540755252530
yep today 350k of 3mill .. finally exceeds my 10% compared to me stating 10% last month(as windfury said).. and as u can see last month. was ~10%

but even so still aint 40%
and even then the addresses dont mean % of user adoption. as that can be just a few exchanges hoard(if i was to play the presumptions game that laughably get played..)

[HeRetiK]

so here is a clearer picture for you
https://p2sh.info/dashboard/db/p2wsh-statistics?orgId=1&panelId=2&fullscreen&from=1477510081999&to=1540754882003
(emphasis p2Wsh)

What does this have to do with the majority of SegWit addresses being P2SH? For example Trezor doesn't support P2WSH yet [1], but is providing SegWit as P2WPKH-in-P2SH just fine.

We're back at the old argument of equating a lack of Bech32 support to a lack of SegWit adoption, only this time we're talking about P2WSH instead of Bech32. That's just silly.

[1] https://wiki.trezor.io/P2WSH

but even so still aint 40%
and even then the addresses dont mean % of user adoption. as that can be just a few exchanges hoard(if i was to play the presumptions game that laughably get played..)

As mentioned above:

Either way, without digressing further: Seeing how apparently ~16.6% of all bitcoins are stored in SegWit addresses (ignoring ~6.5% of bitcoins that haven't been moved for 3+ years of which part is likely forever lost [1]) we do get a different picture from purely tracking SegWit transactions -- tracked at a range of 30% to 50% [2], which is still the correct way to track SegWit transactions, whatever that may mean for adoption.

However no matter how you look at it we're also beyond the mere 10% as quoted in OP.

That is to say:

But what does SegWit adoption even mean? eg. SegWit transactions weighted by input ratio, percentage of blockweight taken up by SegWit transactions, count of used SegWit addresses, bitcoins stored in SegWit addresses...? I guess you'd have to use a mixture of multiple metrics to get a clearer picture. The conclusions would still be a question of interpretation though.

So yes, merely looking at SegWit transaction count, coins stored in SegWit addresses, etc will give you an incomplete picture.

Even moreso does merely looking at Bech32 support and P2WSH addresses however.

Of course one could argue that it's not "true SegWit" unless it's just Bech32 addresses or unless a transaction only includes SegWit inputs and outputs only. But that would be an incredibly useless argument to make as it dismisses most of the data, and worse still, the way SegWit is actually being used in the real world.

[franky1]

"and worse still how segwit is being used in the real world"

so by you mashing in legacy data to fudg numbers and make presumptions and inflate numbers.. positively affects how segwit affects how segwit is being used in the real world

..
sorry but only a segwit UTXO (whether p2wsh or p2wpkh") affect how segwit acts in the real world
no fudging in legacy data and calling it segwit can twist that.

anyway.
have a nice month
p.s if you are interested in facts about segwit. and the now 3 year "onchain scaling" debate that this all stems from

find out how many TRUE FULL bytes of data a legacy tx of 2-in-2-out tx uses. and compare it to a 2-in-2-out segwit uses
then do the same for a legacy 2 of 2 multisig vs a segwit 2 of 2multisig

again non of the stripped, filtered, downstream compatible vbyte wishy washy stuff.. i mean FULL TRUE BYTES of full true validation transaction

then ask yourself. if they just removed the witness scale factor so both segwit and/or legacy could all happily utilise the 4mb weight, without the wishy washy nonsense. which transaction type would use less bytes per tx

[Wind_FURY]

franky1, you're the transaction data expert. How to know if Segwit transactions in the blocks recently produced by Antpool and Bitmain are being excluded.

[franky1]

firstly now your just finger new topics found on twitter rather then discussing the reality of segwit adoption

secondly no one said antpool is perfect. they do empty blocks and other things too but not as much as a certain group of propagandists think

thirdly. ya maybe some of the "antpool" tagged facilities have yet to desire to adopt segwit.

fourthly , this indirectly points out something. pools can and do decide whatever transactions they like to be included or excluded
for instance BTCC would add any transaction that came from their exchange at 0 fee but made others pay high fee's to be considered into BTCC's blocks...
for instance there are some pools that refuse to add transactions where only a couple $ worth of btc is being moved

but i say this because nothing stops pools from doing this. by this you will also find that no pool is going to be forced, made to, or coerced into  including a LN close channel session onchain. yep its just a tx. and pools could ignore it if they want. so dont expect LN to come with guarantee's of ontime close sessions or expect segwit to get high adoption.

and you will find that when it comes to adopting new tech if you dont support it you dont have to just keep mouth shut and do as core say.