Topic: Are blockchain tracking sites tracking Segwit adoption wrong? - page 2. (Read 1104 times)

If you went out for a meal with a group of people and you're all eating together, then everyone else decides to order a dessert, but you don't want to, do you then whine about being treated as a "second class" attendee?  Have they "bypassed consensus" for that meal just because you don't want a dessert?  Are you going to hold a petty grudge against that one person who proposed having dessert and blame them for everything else you don't approve of for the rest of forever?  

Congrats on your -ve trust, by the way.  I'm surprised it didn't happen sooner to be honest.

of the network is supplied with stripped, non-full data the network no longer enforces full validations. they are automatically trated as scond class(downstream/bridged nodes) or as you call it "compatible"

new rules change without the network having to upgrade nodes.
take segwit. old nodes treat segwit as "compatible"... (the buzzword you love)

or as i call it network consensus bypass
yes we both wish for devs to used real consensus. but the bypass ("compatibility" as you call it) allowed it to change without mass node upgrade to 'opt-in'

as for the pools. the november 2016-summer17 election for segwit was consensus. and it only achieved ~35% vote.
as it was a wave a new version number if you want in...

analogy wear your old dirty underwear but wave a clean pair of underpants if you want in. only 35% of pools waved a clean pair of underpants (new vrsion number)
but then the 'mandatory update'(august '17) wasnt an opportunity for pools to wave their old underpants(stay with old version number) in the air to say they are sticking with things as they are. to prevent the new rules

the mandatory update was wear the old underpants, but you better wave new underpants(version number) in the air or your off the network. thus if pools didnt, they would be off the network
EG if there were 20 pools and only 2 pools waved new underpants(new version number) the network would be at 2 pools but show as 100% adoption... dont you get it. fake election.

you even said it yourself that core can write whatever code they lik and not be told what they can and cant do.
luke JR also said it when h said about the compatibility/ "inflight upgrades" bypass
gmax said it with is buzzword of bilateral split

core did not use the consensus election in the intended way. they bypassed it.

thus segwit got activated even without general public nodes having to change. or vote it in to a full community acceptance level. those opposing it just got ignored

then a couple weeks later it only needed one pool to create new skidmark free underwear and all nodes wont be checking that the underpants are really used(signatures of segwit tx's) as it blindly passes the 'are they underpants' test because it bypasses the full validation. (segwit provide old nodes with something that is not full data, that old nodes dont signature validate but just accept as "compatible" even though what they recive is not full real true validation data)

again the devs admit this.
downstream filtered(gmax buzzword)
bridged/stripped (luke Jrs buzzword)

again learn about luke jr's consensus bypass that he calls "inflight upgrades"

For once, we actually agree on something.  I was starting to think that wasn't possible.  China is not a hive-mind and it isn't right for people to portray it as one.



There's nothing wrong with it taking time.  You're the one who keeps gabbering about certain people not using it when you think they ought to be.



Devs can propose rule changes.  They can't enforce them.  Only full nodes and miners securing the network can enforce rules. 

I'm going to call you out on this each and every time you lie about it.  Devs cannot enforce rule changes. 

though i now see some are digressing off the topic of segwit adoption, after they themselves admit adoption is slow as it takes time..

lets rply to this topic meander.. as it is funny
.. yep funny, old, outdated, mythbusted propaganda above by cellard. but gotta love your effort of that same old myth busted joke that keeps repeating for atleast 2-4 years old..
here is some tips. if you want to continue being a comedian, update your jokebook.. as people now laugh at you for using stale jokes rather than laugh with you about the content of the joke itself

p.s im a white-brit... but ill say this
i know you may have been drip-fed by fox news about terms like
"communism" "china" "bomb them bomb them bomb them"
but the reality is in china:
not every business is run by 1 man
not every facility is run by 1 man
not a whole population is controlled by 1 man.

one day i hope you take a plane journey and experience life outside your country and see the diversity of the world

and more specifically to antpool. not every facility is actually in china.
should you actually investigate such you will see that Wu doesnt manage the facilities. nor the block mining stratums. nor the decisions of the block creators deemed as "antpool"
also other pools that get wrongly classed as "china" are not china.. slush(managed by aa guy in thailand) f2pool, world wide access

..last point to make
pools cant change the rules.. but devs can. so the over all funny part is when defending a dev pointing at a pool is the weakest defense people reply with
(kid with chocolate on face: "no mummy, the dog ate the chocolate cookies and caused the crumbly mess"(dogs cant eat chocolate))

"gaslighting" new buzzword this month?..
whats next? "conservative".. "ad-hom".. yea certain buzzwords start circulating in a certain group of people, which just shows they only fed off each other in an echo chamber

keeping the 4mb and removing the witness scale factor would actually allow MORE transactions per block
as for malleability. pfft
its more for a new TX format that is compatible for LN
funny part a 2-in-2out tx of legacy vs a 2-in-2out tx of segwit.. legacy uses less actual bytes on a hard drive.
(but shhh dont tell them that. they still think stripping blocks and not validating signatures and not relaying every tx is ok)
another funny part. new/re-activated opcodes can re-introduce malleability. but thats for another topic


years ago there was a fee priority formulae..
refer to that and you will learn about "coin-age"

now imagine instead of just fee= byte*feeperbyte
but instead something like
fee= (byte*feeperbyte) * (144/coin-age)

so if a coins age is 1 confirm. 144/1=144, meaning the person pays 144x more
so if a coins age is 72 confirm. 144/72=2, meaning the person pays 2x more

image a current fee of 1satper byte. and a tx of (not exact) 250 bytes

confirms   1        6           72        144
price      36000   6000      500      250

now would you spam the network every block if it cost you 36000sat a time. or just use the network wisely for a couple purchases a day far cheaper

if you do the math you will find is a tx had just 1 confirm, but was ignored in the next 6 blocks.. the fee is already set-in as 36000. so when at the 6th block. it would then appear as a premium compared to fresh tx's wrote with a fee of 6 confirms(6000sat).
that way pools can also tell not just by time stamps. but by fee which deserve priority and would be more considered as its more profitable to accept them.

after all right now if everyone just paid 250sat.. because everything is just sat per byte.. there is no "priority". so a tx could sit in mempool for hours and have no better placement than someone who just made a fresh tx a minute ago.. as the amounts thy both pay right now are the same.


no i was not. but seems your buddies have been telling you if people dont love core they must love cash.. (facepalm)
thats the narrow minded view of the kardashian drama.

my view is NOT network X monarchy by team A or F**k off to network Y
my view is network X that has MANY diverse teams that use consensus and all contribute and compromise until an agreement can be made of essential stuff all can generally agree on

EG
not 1mb or "gigabytes by midnight" false choices.
but consensus and compromise of 2-4mb which everyone can generally accept. (without the wishy washy bypass crap of 4mbweight limited by witness scalefactorx4) thats not actually a full utility of 4mb for all tx formats

Most likely Jihan Wu's degree on psychology at play here, by spreading his hashrate around and mining segwit blocks in some instances and don't in others, to trick people like franky1 into thinking his business is decentralized and he isn't calling all the shots. Naive in my opinion, that guys strikes as a classic control freak.

Too bad his shenanigans have ended up in a tricky situation as he finds himself holding massive amounts of bcash. Let's see how he gets out of this one.

you can spot when a block contains absolutely no segwit UTXO's because the "stripped" size(b) and the size(b) are virtually equal give or take a few bytes difference for the block format/header stuff

that said. the blocks that are tagged as "antpool" but do include segwit show that not everything is run by one man (countering the "china own 51%" racism

you will also notice that some "antpool" blocks coin reward are different. theres half a dozen different coin reward addresses. each different address represents a different facility in a different location.

you will also notice that one of them "antpool" coin reward addresses is actually a bech32 address. which also counters the propaganda. as it shows that antpool isnt a single mindset of Wu but different facilities differnt countries and different managers with different judgements

(sorry to the core cabin of PR team, for busting the myth of Wu)
so i hope all you lot in this topic that just follow a certain narative have all got the message about that myth. as thats been circling for years as a drama finger pointing exercise by mainly your buddies for years

for instance.. even just above combining antpool & btc.com into some single mindset....(facepalm)
but i do laugh when a certain group treat over a billion people (china) as a single mindset.. now that is funny

But is Antpool and BTC.com's decision to exclude Segwit transactions more of an "idealistic" move? Because I believe it will make them less profit over the long term.


There were also computations that showed Antpool and BTC.com were earning less because of the exclusion. Maybe they have something else planned.


Wishy washy? Wasn't stripping the witness data from the middle to the end of a block allowed more transactions to fit in a block, and wasn't it to fix the malleability issues?

Gaslighting again?


Ok, I will read about this and open another topic for more discussion.


Are you talking about a fee market? That makes it reasonable considering the limited size of each block.

But the "more aged UTXOs getting a lower fee" as a result does not sense. Can you explain why?


What would be your ideal Bitcoin? Is it still Bitcoin Cash? You were debating for Roger Ver's narrative not too long ago.

We can't say with 100% certainty that they are excluding SegWit transactions just by looking at the size of blocks.  We can definitely conclude that blocks larger than 1mb in size have to have some SegWit usage included, but it's entirely feasible to have a block smaller than 1mb that still includes some SegWit transactions.  Perhaps it's just a coincidence?  I saw two antpool blocks yesterday over 1mb.

each pools has their own intentions. EG btcc used to let in tx with zero fee but only when the tx originating from their exchange
another pool guaranteed first-in (priority) if they done a API pushtx through a website portal*
another pool guaranteed first-in (priority) if they done a API pushtx through a website portal* when paying the pool indirectly
*then treating the normal network relay/mempool as second class
another pool wouldnt include transactions where the utxo is under 6 confirms(honestly, most pools should do this, as it would help avoid spam and also reduce orphan risk)

but back to the question you asked
well if you had 2 tx's both say 300bytes but one earning you 25cents and the other treated as $1 which one would you grab

if core removed the wishy washy witness scale factor *4, guess what
1. both legacy and segwit transactions can in full non stripped format all happily utilise the 4mb 'weight'
2. both legacy and segwit transactions would both be 25 cents. yep cores code makes legacy 4x more expensive. not discount segwit by 75%(thus code counters their PR adverts)

core can easily also limit the sigops/tx. that way it allows more tx per block during spam attacks. .. did you know the way core put in sigop limits that one person can make just 5 transactions and use up the block sigop limit because the tx sigop limit is so high (facepalm)
..
also by reducing the tx sigop limit, thus allowing more tx per block sigop limit also as a side effect reduces the chance of the whole linear validation delay issue.. but if core were to actually do some efficiency stuff and actually fix things, they would have no PR to say other non-blockchain networks are needed.

did you know that core could code many things. including a fee priority formula that charged people that re-spend funds more than once a day with a higher fee, thus a tx that has more aged utxos getting a lower fee.

imagine it a utxo spamming(re-spending) every block paying 144x more than someone spending once a day. which can be done with just a few lines of code.

yep. bitcoin is code and MANY things can be done. but core pretend only 2 things can be done... hense their false narative of
"gigabytes by midnight or LN"

Would you believe that that would be the main reason why Antpool and Bitcoin.com are excluding Segwit transactions?

What about doing it as a means to collect higher fee rewards per block?

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.

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.

"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

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



As mentioned above:


That is to say:


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.

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..)

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.




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


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.

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)

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

(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)