Topic: Are blockchain tracking sites tracking Segwit adoption wrong? (Read 1142 times)

how can "wu clan" spam MORE confirmed transactions. if wu clan are not adding spam transactions to thier block.
EG
a train
you only have a filled train if you put more people on the train. you cant blame a train driver for filling trains if that train isnt filled. what you should do is ask the other train drivers of other trains(pools) why they let people get on and off at every station to cause issues.
(hint. could be solved by introducing a fee priority rule that costs users more that spend more than 2 times a day or a rule that tx's wont get added to a block unless 6 confirms)
you dont simply reddit shout "wu clan must be adding lots of 1 confirm tx's" .. because blockchain data doesnt show that to be the case


also about the mixer. knowing the taint followed a particular mixer and you analyze the blockdata. and whos mixer is linked to particular people. you get to see which group is more involved.

and yes i did laugh at the joke.. the whole kardashan drama to finger point away from devs is the funniest part though.
yet its the devs who are literally the only ones that write the code that cause changes to the protocol that cause protocol issues.

its real funny when some people point fingers at people who dont even write a line of code... thats true comedy

my mindset is blockchains dont scale themselves. devs CODE scaling.
if a dev says blockchains cant scale. and the dev is refusing to scale it.
its the dev that has failed.
again blockchains are not some AI. its reliant on devs. so if a dev says no. then its the dev that is refusing. not the technology
(if you reply with typical floppydisk size data or else server farm reply that circles since 3 years+ ago..... update yourself microsd, fibre,5g)

The Coinbase bit was more of a joke so if that presumption made you laugh than I guess the joke worked... kinda?

Point being that while the transaction drop-off is unlikely to be a coincidence it is also close to impossible to tell who's play it was. Even less so if a mixer was involved.



I don't quite get what you are trying to say. Mining empty blocks (as was the case with Antpool, especially) increases the effectiveness of spam transactions so your hint of "empty blocks = less spam" makes absolutely no sense to me.



That's an oversimplification of the complexity of the issue and you should know better than that. But it's also pretty much off-topic and has been argued to death so I'll leave it at that.

1. presuming is was random. is a laugh. check the core BIP dates (july 2015 spam attack .... bip for CSV)
2. not coinbase non-batching.. the transactions were from a mixer well known linked to a certain dev
3. even if coinbase spammed. check the puppet master dcg.co/portfolio/#c.. also note a dev group in #b

but thats digressing off the point. since segwit there has been a red curve of transactions

oh and before you presume the red curve 2018 drop was due to lets say coinbase batching.. that too can be proved just a presumption.
because if that was the case. you would on one of the charts windfury provided for the topic (inputs and outputs)
in a situation of batching. would see inputs and outputs rise .. not fall.

.. in 2018 coinbase did start batching.. but still the transaction count chart.. AND the inputoutput chart BOTH DROPPED
which means coinbase had little influence.
(the 'spam' if you analyse the blockchain and not reddit PR. shows it was MIXER caused..people actually put in a lil amount of coin into the main mixers and later followed the taint. so blockchain analysis revealed the actual truth.. not reddit/twitter PR)

oh.. by the way. dont now presume "Wu CHINA" spammed.. as the blockchain data (again not reddit PR) can show "Wu clan" was not filling blocks to spam that things are over capacity.. (hint: empty blocks = less spam)

..
finally to hopefully put to rest the meander about "conservatism" aka "doing nothing"

the drama which i call the "floppydisk space(1mb) or else servers" is so laughable.
Kodak tried that in 1999 when they too thought going digital with microsd cards wont work due to limits of floppy disks...

the reply the world gave kodak was .. what i shall call now a 256GB space is a fingernail size bit of plastic
we are not in the floppy, dialup era.. we are in in fibre/5G/microsd era..

if anyone wants to say 1mb is too much for 10minutes.. better tell liverstreamers, skyp/facetimers, gamers that.. oh wait. that would be a laugh

frank1... gotta love the finger pointing that it was Core creating spam.

In all seriousness though, obviously we don't know who was responsible for creating the spam and probably never will. However Bitcoin Cash proponents being behind the transaction spam makes more sense to me due to (1) Core developers insisting on Bitcoin not running at capacity yet (which would have been the case, if not for the spam transactions) and (2) Bitcoin Unlimited / XT / ABC chanting the eternal song of "look at all these transactions, we need to move now and increase the block size" while flaming Core for "doing nothing" while "organic growth" is "overloading the network".

For all we do know though it might just have been Coinbase fucking up the network with their (back then) lack of transaction batching.

That being said I appreciate you posting your view on that matter.

though above appears to be just another meander off topic and a point finger to kardashian drama session.. ill address it
(but dang im starting to notice this tactic occur so much)

HeRetiK.. gotta love the finger pointing that it was someone else creating spam.
the 2015 spam ......... oh you mean the core bips... for instance the checksequenceverify bip was a very spammy period as one example i remember (gotta laugh at a certain dev that ramped up his favourite mixer service at that time period. wasnt that subtle)
(you might wanna check your calender vs core bips)

funny thing is. spam only happens when core want a new BIP adopted under the premise "transactions are at peak, adopt us and we give you more capacity"

no other proposal had mandatory adoption. no other proposal had tricks to get adoption.
over the years xt, bu, classic and others just released software and if people didnt adopt it. no deadlines. no force no coercion. just let people run it and see what happened..it was a 'oh well consensus said no.'

only core couldnt take no as an option..(blockstream devs had a seed round tranche of funds bet on the november 2017 ultimate deadline)
 core only had 35% vote winter2016 - start of summer 2017.. they hated it. but didnt want to back down and go back to the drawing board. it was a core roadmap or else.
lesson to core.. when someone says "take the highroad" that means eat your hat, accept no as the answer. and retreat with respect... doesnt mean to actually TAKE the road

i hope you now calender check and blockchain data check which bips occured at spammy periods. .. oh and i mean data check, not reddit/twitter kardashian drama PR check

it was you that shown off the 2009-2018 data.. so i just shown the curve of that graph. also with all the (false) promotion of "more transactions" and stuff.. that curve would continue on its 10 year trend... (under core expectations/PR/assumptions)
the green curve was within the confines of expectation, even with block limits. (because transactions per block are not at expected "peak" capacity, so you cant say it would platto out due to capacity as the capacity of cores promotion is more than 7tx/s right... while reality at the green/red is not even 3.5tx/s)

oh.. and the ATH spike actually shows that capacity hadnt peaked and actually had more potential.......
but.. as the curve shows the reality of transactions DROPPING at mid 2017

thats something that got debated and laughed about a couple years ago.
long story short
median can be more scewed and abused than anything.

median has nothing to do with what multiple people spend.
median has nothing to do with what average spend it.
median is just what the SINGLE piggy in the middle spent.(not group, not community. just the single middle)
which can be easily prepared collated and tweaked

its called looking and observing.

look at the chart which you provided for the last near 10 years and see the curve
EG
if you were to see this:
            /\/
        /\/
    /\/
/\/
if you flatten out the small tips and dips. would you call it a vertical?, or horizontal? or diagonal line?
you would call it a diagonal line.. same goes for your 10 year chart. you would see a curve.

its just basic shape recognition a 5 year old can do

Because 2016 - 2017 was the start and the peak of the hype. Would you say that it will never reach and surpass that level again? Or would you say that the fees will be higher than ever if it surpasses that level? Because it will, and it will have lower fees.

Plus I believe median was used to avoid "skewing" the data from the extreme numbers from outliers.

Where did you get the "green line"?

IIRC that drop in daily transactions around June was when the spam transactions subsided, presumably because the proponents of what is now Bitcoin Cash / Bitcoin ABC (FKA Bitcoin Unlimited FKA Bitcoin XT) gave up on trying to pressure Core into increasing the block size; finally deciding to simply fork off instead. On a closer look the initial release of Bitcoin XT in late 2015 also marks the beginning of the suspicious acceleration in transaction amount growth. Most likely a coincidence but still a kinda weird one at that, especially in retrospect.

I do assume you have a different take on it though?

green line=community expectation of natural growth
red line. .. well ill let you work out what happened mid 2017.. where the red line begins and shows a different direction than the expections


(quick hand doodle dont knitpick the specifics. just concentrated on the question about green vs red)
the peak at end of 2017-start of 2018 is just he couple month drama of ATH
but again explain why the red curve.
i also beside the eye swaying 2009-2018 chart. i done a 2016-2018 specific.. chart beside it... just to draw attention to the point of this topic related to segwit which was first mentioned and debated blah blah blah. not in 2009-15 but from 2016+ just so people can concentrate on that period

i also included some dotted lines that help show rough area of transaction lows and highs of both 2016 and 2017. to also show that 2018 fell below 2016-2017 standards

but again.. explain the red line.. i think you all know exactly what happened at the point where green met red. (hint mid 2017)

yea you can stretch out the data back to 2009 to sway thee eyes away from the period of concern
but care to notice the 2018 cliff edge that went BELOW 2016-17 levels

kind of funny you think including 2009-2015 is helpful.
when infact people will notice a nice exponential curve upwards. that then went weird after mid 2017
and no segwit had nothing to do with 2009-2015

as for fees
"median" dang, im not gonna repeat the long lengthy debate where lauda tried that "median" trick a couple years back
hint. to save months of social drama... median has nothing to do with average

for instance
1-1-1-1-1-9-9-9-9 of the set of 9 transaction amounts median=1
EG i could make a block of 9 transactions and put my own transactions paying myself 1sat 5 times(stat tweaking). and then let in normal peoples transactions (real community) of 9sat
thus the community majority pay 9 but the stats tweak show on graph sites that use "median" show only '1'
yet the average would be 4.555555
(BTCC done alot of throwing in lots of free transactions from its own exchange.. purely to make stats look better then general reality of whole community utility)

---

transaction fee's again.. by looking at the lack of transactions per block. explains itself
nothing at all to do with segwit gets more transactions in but cheaper.. because .. there are LESS transactions(2018 cliff dive)

oh and also if you look at the bytes USED per tx and if you count the PRICE people pay. you will see they pay more now than in 2016

but i do find it funny about using the "median" as oppose to average.  yea i remembered that lil trick

funny that when segwit was announced people were hopeful to get back below 10cents average amounts again.
funny that when the base block is not actually 100% filled. the fee's are not below 10cents

Because there was no better word in what you were doing.

You told me once that fees are higher in the network today after Segwit activation than before that, backed up by your "facts". Is that not gaslighting? Fees have never been lower in satoshis/byte.



You also said that adoption is decreasing. Why is network activity increasing year on year?

In essence, yes. What's keeping you? There are thousands of coins restaurants out there, vote with your wallet. It's a free market after all.

That being said, it's kinda silly to change restaurant merely because they added menu options that you personally don't want to take. But to each their own.

"one lone voice cant change the chains policy"(facepalm)
under consensus 65% voices said no to a restaurant chan updating the menu. infact the waiter in the chain should not have added dessert without the chain.

but i guess you now admit core own the chain........ and no longer just a waiter within the chain.

the dessert is on the table.. it never was before august 2017. but now its on the table the waiters are already dishing it out

those that didnt want the dessert had no choice. they now end up paying for it. but the waiter strips it off the plate trashes it and just gives you what you think is what you want. but now you are not given the full meal that every full paying customer should get.

again the now set full menu meal includes a dessert. you as a customer never got the chance to say dont offer dessert in august 2017(consensus)  it was mandatoryily changed(consensus bypassed, bilateral split UASF)

you are told the new full menu is compatible with the old menu as the new waiters strip the dessert off the plate..but you still pay the new full price but dont get to see the full menu any more. if you dont like it go f**k off to a new restaurant

play your silly games all you want. core changed the menu and those not wanting a new menu get a wishy washy scrubbed off version of the menu. but still pay the full price. they cant even give the dessert to others(relay) that may want the dessert. as its been stripped off the plate. thus others no longer see you as a equal peer as you dont hold a main+dessert

again it wasnt a consensus event.
if you cared about bitcoin security where no software should have the ability to do that. you would understand the issue. but your too deep in doing what they want to care about bitcoin.

again no choice no way of voting that the menu should stay the same(consensus).. it just became a upgrade your tastebuds to eat the dessert and be a full peer.. of go to a different restaurant

anyway doomad. you are protecting devs not bitcoin security. so no point in talking technical to you. hense i dont.. you might have notice i actually bothered to ELI-5 many things. but even that passed over your core defense cap
no point circling the same topic with you because you are just blind to th bitcoin security issues of "inflght upgrades"(consensus bypasses).

best bet is you go learn some romantic poetry instead and become a core romantic
you have had ample opportunity to learn whats really going on, now i think you havnt bothered more because your not interested in the network security. but only interested in core friendship

end of debate

I'm happy to keep it going with the analogy if that's what you really want.  

You're in a restaurant that serves dessert.  You are there by choice.  You're seated in the "no dessert" section.  Also by choice.  Even though it's more expensive without the dessert discount.  That means you are not getting a dessert.  Dessert is not being brought to your table.  You've never even seen a dessert.  You can still enjoy your main and pay exactly what you've always paid for it.  Stop whining at us because we like sitting in the dessert section and we're happy with the one main.  One lone voice can't change the restaurant chain's policy on main courses.  Each restaurant location sets its own menu, but most of them seem to have the same menu.  Most of the other customers seem very content with the current menu.  Sometimes you have to tip a bit more when it's busy, but most people don't have a problem with this because they love the service and the quality.  This restaurant always seems to know exactly what the majority of its customers want, almost as if it was run by them.  I honestly don't know why you keep coming here when all you do is complain about the menu.  Some people just like the attention, I guess.  You also strike me as the kind of person that doesn't tip very generously.  We like it here, though.

I even hear that a small number of locations for this chain of restaurants have a bespoke menu.  You run one of those restaurants, don't you?  You let customers decide how many main courses they want to have, but there's definitely no dessert menu.  It seems that idea hasn't proven very popular, though.  Most people are happy with either just the one main, or the one main and then a nice big dessert.  I'd have thought you'd be appreciative of the fact that you're totally free to run your own restaurant with no dessert on offer.  Literally no one can force you to offer dessert at your location.  I don't know why you think you get to tell the other locations what should be on their menu, though.  It's not your call.  You've made your choice for what goes on your menu, so you need to respect the choice of the other locations.  Maybe you should consider being less of a dick about this and just be thankful for what you've got.  No one else can reverse your order like they can in old-fashioned restaurants.  You don't have to give them your personal contact details to eat here like old-fashioned restaurants do.  They're open 24/7, when the old-fashioned restaurants are often closed.  You can even be refused service altogether at those old-fashioned places.  Everyone is welcome here.  You might not like the menu, but there are clearly enough good reasons for you to stick around because you haven't left yet.

Plus, there's always that other chain of restaurants with the controversial advertising and up-to-32-course meals and no dessert if you like your mains so much.  We think that's a tad gluttonous, though.  If everyone ate a large number of courses there, most of their locations would probably be forced to shut and you'd be left with only one central location where the service was absolutely terrible.  They could change the menu as much as they wanted and people wouldn't have much say in it.  Plus, even though you can have up to 32 courses there, most people who eat there don't even finish their starters.  People just seem to go there for a light snack.  It's all a bit strange, really.  But if you like that business model, the option is yours.

And there are countless other restaurant chains too, but the service and quality varies greatly.  Sometimes people get food poisoning at those other chains.  Standards are pretty lax.  

Many believe that's why this chain of restaurants we eat in is so popular.  The quality here is really high.  And there are so many locations.  Sometimes people forget how important those aspects are and that maybe it's not the best idea to jeapordise those qualities.

you forgot your dessert analogy didnt you
people didnt ask for dessert they were happy with their main meal... but the dessert arrived at the table anyway, they were just told to not see or hand it around. and to only touch the main meal plate the waiter handed them stripped of the dessert

though the people with only the main meal pay more for their meal even if they cant be involved in having a full valid meal+dessert.

funny, flip flops you make
compatible no need to upgrade
concensus need to upgrade

just accept it.. consensus bypassed.
and yes its old news but you keep meandering topics to bring it up

yes
check out the usual group you chat to. lauda, achowe, carlton. they love their 'conservative' 'ad-homs' 'compatible' over use.
even doomad had joined in with "conservative" "compatible" repetition. doomad even gets mad if i myself dont use certain buzzwords
it kinda became a strange thing i noticed and picked up on.
much like a certain mindset loves to scream bcash, china, lambo, fomo. you start to see what crowd people circle in by their use of language

as for your 'gas lighting'. seems you have picked up a new word recently. reading your posts for months it wasnt there. then recently its been used multiple times in the last month.. so its something i noticed


correct it did not.
you can malleate a transaction now. by using legacy. so it didnt solve malleation for the network.

there are multiple ways to malleate a tx. segwit solved one that was needed to make BTC "compatible" with LN
due to how LN monitors a TX by its TXID but only for segwit transactions

and yes devs want to re introduce things that make malleation possible again for segwit tx formats.

segwits true purpose was not a network solution. it was a make a tx format thats compatible with LN. al other half promises were wishy washy PR stuff to try coaxing people to adopt and wave a flag of devotion


a transaction that has 2 inputs and 2 outputs
some call it vin   vout
some call it sender   receiver
some call it spending   paying


ask your chums. a few know a few dont. and one in particular doesnt like it when im being subtle but give him no input

Will you go far in saying that everything you said had not one single lie or half-truths? This is a "yes or no" question.


Why "pfft"? It did not fix malleability?


This is a stupid question. What is 2-in-2out again?


What OPcodes would that be?

The reason Bitcoin is secure is because there's a lower resource cost for running a full node with a smaller blockweight than there would be with a larger blockweight.  That's why we're doing what we're doing.  Of all the blockchains that exist today, this one is the most secure.  We're not going to jeopardise that.



The correct analogy would be that those who ordered a dessert get a discount on their meal, whereas you pay the same price you always used to pay before they introduced the dessert menu.  If you don't order the dessert, you can't even see it.  You can continue eating, blissfully unaware of the existence of dessert if that's what you want.  The choice is yours.  



There's no flip flopping, those securing the chain decide what consensus is.  They've decided on SegWit.  That's not tyranny.  Forcing a larger blockweight onto nodes that don't want it is tyranny.  Node operators have the option of running code that supports a larger blockweight.  If or when they decide to do that, fair enough.  We can then have a larger blockweight.  But they aren't doing that now.  So stop being the guy who thinks they get to order for everyone.  You are the lone voice with little-to-no support who, depending on what day it is, wants either EC or a 4mb blockweight that everyone can use.  Why is it so difficult for you to comprehend that's not what everyone else wants?  At present, ~0.53% of nodes on this network are running clients that advocate larger blocksize/blockweight.  0.53%.  And your preferred method of getting people to agree with you appears to be attacking developers and coming up with bizarre tin-foil-hat stories about how certain people control the network.  And you wonder why you're not having much success and people think you're being dishonest?  Either come up with a sensible and reasonable case that people might actually take seriously, or just wait patiently for people to decide for themselves when the right time is to run code supporting a larger blockweight.  You've made your choice.  No one is telling you what to run.  Why can't you respect everyone else's decision?

awww you actually think the trust has meaning.. i think you have forgotten the point of bitcoin
you care more about cor trust, than you do about bitcoin security

if you went out for a meal as a group of 10 people and 6 people didnt want dessert. but the 4 people demanded dessert and so the whole table were given dessert. thus the restaurant were deemed as fully accepting dessert but, the waiter charged you 4 times more for your main meal because they had to scrape off the dessert from your plate and edited your receipt to show as a more expensive meal without dessert even though the reality is that a dessert was provided to everyone on the table. you were told to just accept it or f**k off to a different table.

its funny you argue that the meal order cannot change without group agreement. and then argue that people should just shut up if the group dont get a group agreement because one person gets to order for everyone
.. stop flip flopping. decide.. consensus is what you want or tyranny

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)

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.

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

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

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

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.

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.

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:


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.

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/

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:


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.

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.

I got into a debate with franky1 some weeks ago in this thread, starting with this post, https://bitcointalksearch.org/topic/m.45926698

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


I replied with this.


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?