value is below market. premium is above market
it appears your numbers for 2022-23 are average not value

your formulae numbers are subjective
8 cent electric of a 12 month ROI

hmm



my numbers are
from efficient asic farming mining in low electric of $18k for this fortnights mining rate
to an inefficient asic hobby mining in high electric of $118k for this fortnights mining rate

which is an average of ~$68k
value: 18k
average: 68k
premium: 118k

as for your numbers for 2018.. that is way above premium for that period even for high electric regions

my math is based on a 2 year ROI
because industrial mining farms buy hardware that lasts 2 years and electric contracts that are bought for upto 2 years so the number of coins earned over a 2 year period become the math.

and industrial electric is cheaper then $0.08 at $0.04
and the hobbiest is electric is more then $0.08 at upto $0.48

..
that said you have a good bases of looking beyond the markets for underling value. but your math is a lil out, compared to rational expectations of what real mining farms do

and another hint. the math you show saying how you are using 1 year measures of coins earned. and then 6 months and then fortnightly difficulty changes.. yet your charts changes daily so your not exactly sticking to the difficulty steps of one change a fortnight. using average hashrate of that fortnight

most miners dont account for costs on the daily. they take the monthly costs or the 2 yearly costs and compare it to coins earned over those averages

i have expressed many options. your ignorance and attitude of blind obedience to the central point of failure called core(they admit they are) has blinded you of other options which you ignore or pretend you dont remember

you advertise other networks that need middlemen(routers)
you are the one proposing fee mechanisms that do not benefit the user but benefit centralised pool managers (not the asic miners)

i have said for many years of fee mechanisms that punish only the spammers not everyone. thus fairly punishes the abusers
https://bitcointalk.org/index.php?topic=1811430.msg18046048#msg18046048

i have said that no one deserves a whole blockspace for 1 transaction. where it should be fair lean transactions to allow more individuals to transact per block.. not less
(unlike you that has always wanted less transactions per block via many campaigns you have promoted)

i have even said get rid of the cludgy miscount of bytes and instead streamline the code back to basics so that using a 4mb blockspace can allow actual transactors to use 4mb of space.. meaning more utility of space of the whole 4mb so that the average 2k tx per mb becomes upto 8k for 4mb of space. instead of the cludge that exists today of miscounting bytes which only allows an average of 3k tx for 1.5mb of space 6 years after so many promises of "scaling" were made

funny part is that i have been talking about scaling transaction counts onchain before the forkcoins existed

and by scaling.. you have no idea what that word means.

you shout the word "bigger blocks" while ignoring actual options.
i have said even years ago about a block that SCALES
heck i have en said about scsaling transaction counts within the current limits too

then you for years have been saying anyone that wants scaling wants LEAPS of blocksize(facepalm)

as for who does or doesnt want something different. you want people to obediently follow core roadmap and want anyone else suggesting anything else to STFU and F**k OFF
so its you that doesnt want things to change away from a corporate plan

heck for years there have been suggestions made about your favoured subnetwork. and you have screamed how people should shut up and stop talking abut x,y,z

as for other bitcoin things i have said about fee mechanisms that only punish the bloaters. and YOU are the one that shouts how everyone should pay more, whilst letting the bloat continue.  onchain or use another network

heck if its not cores sponsored roadmap, you want all those against it to use other networks

yes YOU have screamed your version of scaling is: "100mb blocks asap" as your argument to say no to scaling

yet many many people including me have been saying about scaling as small but regular adjustments to increase transaction count.. which is the true definition of scaling
also fee mechanisms to reduce spam to allow more genuine transactors. and fee mechanisms that only punish the bloat/spammers to punish the bad and incentivise the good for having more transaction opportunity without impunity for being a lean non spammy user

you cry that removing spam is censorship when reality is the spam bloat censors out genuine transactors

you have things backwards
...
as for lightning. its not fit for purpose.
basic common sense and maths shows the more users on it the more it actually bottlenecks and fails

but rather the fix the flaws you and your idols just want to waste YEARS advertising its dream to people rather than fixing the flaws to make the dream a reality.


lightning has failed so many physics/math/economic policies of effective monetary policy that lightning would have to go backwards and start again if it was to even try living up to its promises

however bitcoin does not need to go backwards. just needs to stop future crap continuing, and concentrate on going forward in a proper scalable way that works and has security precautions of nodes first activation second. to secure the network as a priority. not secure human devs god-mode title

fair play to those that want to make crypto services and niche subnetworks.

but to be ignorant of the flaws and instead only want to do snake oil sales pitches of best case scenario and utopian dreams... isnt helping anyone
just getting outraged because someone is breaking the snake oil sales pitch of utopian fluffy cloud dreams says more about those that still want to recruit victims into a flawed system.. than it says about me who is trying to tell people of the risks/flaws so they can make their own decisions of risk tolerance

lightning even by devs own admissions is not going to succeed as a mass network for millions of users

there is nothing bad in realising these facts, learning from mistakes and then trying something different.

there will be other subnetworks that offer things that mainnet do not. but lightning wont be #1 subnetwork

there are already other subnetworks that require locking up bitcoin and have more bitcoin liquidity locks pegged to the other subnetworks than lightning has

A these should not all be pre-activated to just let anything in.
B each should be default deactivated. and then get activated via node updates when they have a purpose via code/decisions of what they should be used for
where node users have had a choice/opportunity to upgrade to be ready to enforce the rules


i know you dont know what consensus is. but after soo many years,, you should know by now

get it yet
nodes should update to be ready to verify new rules then the rules activate
rather then new crap start and everyone race to catchup try to understand the crap

and yes not all new changes get to just happen .. they require the community to have vetted the code and understand the code to then see it as good/worthy of activating

..
i know you want systems that reduce utility of bitcoin
for years you did not want block space changes that allow more transactions with your fake cries of 4mb bloat is bad"
now you cry that 4mb bloat is good because this bloat also reduces transaction counts

your campaign is all about reducing transaction counts per block no matter the method.
yes i call them campaigns as its obvious you have a particular cause you follow that differs from bitcoins utility

you also campaign for reducing how many full nodes(full verification and archiving) are on th network protecting the network

you also campaign for the less users to pay more..

all of your campaigning defy the natural utility/ethos of bitcoin

you love the idea that nodes dont have to upgrade and that nodes get stripped blocks. or nodes choose to prune whole sections of the blockchain.

you goal is not to evolve bitcoin to be a system that allows more transaction on chain (more p2p digital cash utility)
you want another network to be the p2p digital cash

so there is no point in you playing your silly games of pretending your desires are about aiding bitcoin evolution

what you defend is not bitcoin. but human developers that are sponsored to implement code that sways people into using other networks

you do not idolise utility of the masses. you idolise corporate networks wanting to make profit from users by doing middlemen crap

these ordinal crap memes are not actual NFT

they have no true blockchain based proof of transfer

yes "software" can analysis and decide what it wants to show and choose as the output path. but nothing in pure blockchain data shows the path using proofs

bitcoin value(btc) does show proof of transfer.. but the crappy memes dont. its just dead weight.

once people realise it they will realise they have been suckered into paying for a meme thats not spendable. unless they find another fool to dupe into buying it.

and we should not be trying to advertise or promote trading value for memes that have no real ownership transfer as it then gives bitcoin a bad name by having a fake nft system scamming people. we need to stop the spammy scammy memes. or have the project manager use his brain to work out a simple way to make it proof of transferable.

there is a way. but i prefer he just dont spam blocks. so im not helping him out to fix his cludge

above is the image representation of the data of blocks involved in activating segwit

(flags= small reference in block data that shows desire/preference for something)

as you can see from november 2016 when segwit was first proposed and allowed flagging. until july 2017 only got under 50% wanting segwit activated naturally(genuine open choice)

however in May there was another proposal. called the NY Agreement by which from june, many economic nodes and some large mining pools agreed that if the rest of the mining pools and the NYA flag a month long 90% acceptance they would start rejecting(subliminal threat) blocks that disagreed with segwit to cause a statistical 100% acceptance even if not a 100% opinion acceptance... to help activate segwit.. but they wanted a 2mb block later in the year(in hindsight they never got the 2mb blockspace)

the NYA proposal then resulted in the segwit flags showing as an unnatural growth to an unnatural 100% acceptance of segwit in the july-august period which resulted in segwits activation

the group that strongly opposed it decided that they wanted to continue as is so they started accepting blocks that were normal blocks. (ones segwit rejected)
segwit was declared by the economic nodes(merchants/services) as bitcoin and the opposition as an altcoin where the altcoin had to change things in its minority chain to ensure the chains dont converge by the end of august. (so that the flag can be taken out/to not need to continue having 100% flagging which was used to prevent differing blocks on the bitcoin side)


this version of events is backed up by actual agreements. actual code and actual blockdata that is immutable and is strongly uneditable by 6 years of confirmations

point is if its a stupid signature(your words)
of a shut down service (your words)
which this topic is showing is involved in illicit activity..

would you want to continue advertising it... well i guess money speaks louder then personal opinions

..
i do hope though that you are "stacking sats" (saving) so that one day those sats add up to a point where you can be self sustainable to not need to rely on those sig campaign/ other campaigns that promote things. and instead live freely thus not needing to put your personal opinions to the side for a income

get the hint chip mixer is dead....
.. your not going to get paid next week. the funds are gone

no reason to promote them for another week
feel free to change your signature any time you want

things some people will never learn

mixers ARE flagged as money laundering services and a higher risk of facilitating illegal activities ..

mixers are not a privacy tool. regulated exchanges actually watch users that have mixed coins far more then they watch regular users
you are not hiding by using mixers, your actually ending up being spotted and seen more by using them

you need to realise that laws are real.. and that using privacy coins and anonymity services does not absolve you of a law nor make laws dissolve.
laws dont disappear. they still remain

it just means it takes longer for people doing illicit things to be found. where by the only safety is if you play with such small amounts you just get lost in the noise and become not worthy of chasing

money is not 100% fungible
when you get an income from an employer, its treated differently by the tax office to money you got from a loan, lottery win, relative, investment account. or street hustler/drug dealer

yes swapping and mixing does produce more varied % of fungibility the more its mixed to create more noise and limit the % of risk of relating to criminal funding.

but at the same time using a popular advertised service known to be used by the dark markets actually cuts throw the noise and gets funds flagged more.. and by using a service with a higher majority of darkmarket users.. innocent users end up with a higher % of that dark money being passed to them

i do laugh when people want privacy but then advertise/promote where they throw their funds publicly
these comedians like to shot themselves in the foot

sending to multiple people in 1 transaction is cheaper then sending via multiple transactions

a LEAN legacy transaction is 226bytes (legacy 1in 2 out(one recipient + change return))
meaning paying 10 people is 2260bytes at 1sat/byte=2260sats

a multispend transaction is 532bytes(legacy 1in 11 out(10 recipient + change return))
meaning paying 10 people is 532bytes at 1sat/byte=532sats

without code changes.. the spam, by just sitting in mempool plays with the fee structure
it also plays with the tx per block structure
it also plays with the time expectation for payment settlement

but hey an exploit has been allowed and you dont want to fix it because you think its not broke

oh and the fee mechanism you think will "figure itself out" wont figure itself out to make spam disappear in blocks...
because said spam can manipulate fee's of other people in the pending(zero-confirm) stage of mempool filling

nah its not.. but nice try. i guess the latest campaign script has deceived you again
forget the campaigners that recruited you...
. forget their scripts for one moment
where you are pretending to be against the bloat memes. but then loudly saying you dont want the meme spam to stop and instead want everyone else to pay more

just ask yourself .. for yourself. do you personally want to pay more and wait even longer for your btc payments.. personally.. just to turn bitcoin into a meme library
or do you want to transactions to be lean and cheap where more people can transact freely and the TOTAL utility of many then affords the "incentive" for mining pools

here is one thing..
even if memes dont get into blocks. they can sit in mempools pending for days-weeks and it only takes 75 memes of 4mb to fill a 300mb mempool and cause all other transactions to "pay more" to avoid being trimmed off the bottom of the 300mb limit of mempool
emphasis: even if a meme never gets into a block and just keeps getting re-broadcast to mess with the mempool trimming mechanism

if you cant see this is a attack vector to cause less transactions per block but more fees per block breaking bitcoins utility and desire.. then you have your nose to close to your teams latest campaign scripts and not allowing yourself to see beyond the speeches.

short couple of questions, with easy answer that will reveal your convictions/mindset:
a. do you prefer 4mb of about 75 spam memes paying 4000000sat total to pool
b. do you prefer 1.5mb of about3000 normal tx paying 4000000sat total to pool
c. do you prefer 4mb of around 8000 normal tx paying 4000000sat total to pool

no its not

you need to understand the opcodes better
the one that the ordinal spam uses can be limited without harming the ones that other taproot functions use

a. they dont know where to spend it.. thus think its not a currency because they seen no real world usage of it

b. they are informed of bitcoin(by idiots) as a 'get rich quick' scheme. thus they dont see it as a viable currency because they are only informed about getting rich.. so think its a scam

c. they are not informed about what differences different coins offer and why bitcoins value underlying the market is higher then others. so they think bitcoin is just speculatively pumped by 25000x above a coin offered for $1.. so they dont trust bitcoin and think it can crash to $1

..

so, the solution
dont explain bitcoin like a greedy wallstreet salesmen talking about it like a get rich scheme
instead show local retailers nearby that accept it/prove its usefulness

explain how some altcoins only cost <$35 of electric combined to get a newly generated coin. and bitcoin cost $15k+ a coin. and so the markets speculate from that point and above

some speculate by 1x-6x above value cost. some speculate by 45x
more speculations means less value is protected. thus stay away from those extreme high speculations

explain how some coins have deflationary supply and some dont. and how that alters the value/cost fundamentals too

taproot has opened up a whole new set of new underclass opcodes.
some do require specific stuff or will fail.. some dont

the ones that dont have any expections assigned to them should be tightened and refined to expect what is expected
EG the opcode these ordinal spam are using should be made to expect some kind of signature script or byte length

usually people cry if i was to explain every single opcode of every feature of every generation of subclass just to then only need to explain one instance/usecase..
so i usually dumb things down to only speak of one instance

but you want the lengthy one (i expect cry babies responding)
pre segwit there were 16 opcodes and only 1 with a no expectations. where others did have expectations. but in the years prior the 'no expectation limit' opcode was not really used for multiple reasons... (anyonecanspend)

when segwit activated by using that unused opcode..  it came with its own subclass of opcodes where again most were set to limits but left one limitless/expectationless. but no one really used it for multiple reasons

and now taproot by using that unused sub opcode. SHOULD HAVE come with limitations/expectations for majority of taproot opcodes and where one opcode to be used for next generation tx formats goes UNUSED/deactivated until the next consensus activation of a new feature
.....
as for the one sig length promo
the devs PROMOTING taproot were the ones PROMOTING one sig length
not me

yes i agree. the one siglength is not a taproot thing.. AS PROVEN BY THE LACK OF SUCH FRIGGEN rule

blame them for mis promoting because they were the ones saying it was all part of taproot

where by they were even saying crap like

"no one will be able to tell if its taproot or normal segwit"
a lie because segwit is BC1Q and taproot is BC1P
you can spot a taproot without even trying

many lies were said to promote taproot and look where its ended up

---

i usually learn everything there is to learn and then on the forum dumb things down to ELI-5 for readers of the forum

but if you want a slightly more techno buzzword filled explanation:
taproot has its own class of opcodes
it has its own version of checkmultisig which in taproot is called checksigadd
you cant use a old class opcode checkmultisig in tapscript and cant use a tapscript opcode in legacy

ordinal spam is not put into a checksigadd opcode of taproot because that opcode expects signatures. not random bloat.
ordinal spam uses another opcode called opsuccess
there is more then one and these should not be used/active unless a new feature is activated where expected functions are ruled into that opcode by activation

the softening of consensus has allowed an exploit to allow utility of opcodes with no expected rule

tightening consensus again can plug the hole

first of all. people like you act as if there is only 2 ways: overly restricted or extreme looseness

however there are other ways in between
looseness but with refined expectations where nodes and transactors can have certain expectations of each other depending on methods of use

do you really think that all taproot subclass of opcodes need upto4mb space for one instance..
no

you also think that code cant make rules so code has to be made to provide looseness/softness to the extremes.
it does not
it can refine space in one part and refine other space in another part where it actually flags which part it wants to use when it uses it. where by the flag then shows the node what to be looking out for and what to expect. rather than a "accept everything unchallenged"

we are not talking about segwit
we are talking about the particular opcode specific to the taproot subclass of opcodes that allowed the meme bloat
remember taproots promise "one signature length"

^ nope
solution to having a bitcoin NFT system of file hashes is much simpler then that..
again it does not use taproot or op return

your last paragraph shows good thinking outside of the box but your not quite there yet

to fully enforce a fee mechanism to scare(not completely stop) meme bloat requires enforcing full node compliance to reject blocks that contain transactions that dont honour the fee mechanism, which can cause forks
yet meme bloat have other tricks to pay less than the average so even with such enforcement it wont completely stop them


however to stop meme bloat from entering future blocks, doesnt require or cause forks.
it can use the same soft consensus trick(no fork) that allowed the bloat. but in reverse to stop the bloat memes continuing to enter.. while still allowing taproot

a 80byte limit is within range of 4mb limit. thus not a block forking just a tx not entering a block thing. thus no fork
its simply hardening the rules again. (undoing the exploit) to prevent future spam

also preventing future spam by hardening consensus again does not put a stop to any new feature activations.. instead it just ensures any new feature activations are ready to activate before activation. rather then slide in a feature and then have every race to then be ready...
in short it stops new exploits from just finding their way in unverified