ok guys. thinking caps on please

[franky1]

cry some more doomad, its what your best at

you have no clue. but continue to cry.

devs can code what they like. but when it comes to a network that involves consensus devs should not have the ability to just trojan in new features without the mass of nodes being ready to validate such new rules upfront. to THEN activate the new rule/feature so that the nodes know how to treat it.

(after 5 years of correcting your cries. lets emphasise once again)
what should happen is nodes upgrade to include proposed validation code. and then it activates


try to learn a few things because you have wasted 5 years on crying about your authoritarian system where you want core devs to be the deciding power house above user nodes where user nodes have no choice

consensus is about opt-in(vote) to activate
where lack of majority = no activation
where there is no miscount of inclusion, no pre activation mandated fork, no rejecting opposition to fake majority.

YOU think it means activate and have those that dont opt in just be sheep following without verifying the new rules. or already thrown off the network by showing objection

you have no clue what the true blockchain and consensus inventions purpose is.

you love a subnetwork that has no blockchain or consensus and you love that it doesnt. you dont want accountability of the masses, by the masses
you want 1 on 1 battle of the fittest

now go cry somewhere that people wish to kiss your ass and hug you. becasue that s all you seem to positively respond to
so go talk to your subnetwork community of a dozen big mouths.

you are the irritant of the forum and you think your are liked because you see (only) 12 people that kiss your ass so think they represent the "community"

i dont care about being liked. id rather discuss the important things of how things actually work or should work.. not play your games offering empty promises and unsold dreams of networks that exist but have more structural flaws then a cracked wall on a weak foundation of some outdated and under used church (i use a church analogy becasue you sound like a religious preacher for your community)

[1715335498]

1715335498

[franky1]

I can't talk for CBDC, but I always had this stablecoin idea where it grew with a %10 steady pace every year and owners would get that extra. So if you owned it, you would be gradually getting more the longer you hold it. I haven't decided it if t would b like per hour or day or week or month, but as long as you keep it on your wallet, it would have a %10 per year increase to all owners, directly to their wallets that hold it, no staking, no mining, just straight goes into their address that has it. This way it would prevent inflation and also would grow as well like fiat. And its stable as well so it should be covered, but how would you cover something that grows %10? Where would that money come from? Well that's what I couldn't figure out so I never did it lol.

things i do see.
obviously its more like bank account savings interest. where by the longer you save the more coin you accumulate. rather than spending it and letting someone else accumulate.

but just getting extra coin is inflationary.
because there is no supply end limit. nor a decrease of supply per period.
infact 10% of X means more coins in year 2 are made than year one, more in year 3 than year 2 and so on

ok lets delve into this
you could have two options
letting max increase of coin be 0.0262% a day(10% a year)
that way you dont need to hoard for a year to hit threshold of getting a 10% increase
or the utxo has to accumulate an age of 365days to win the 10%
meaning not everyone will get interest due to the need to spend to live factor

mechanisms such as looking at age of utxo to calculate days since uxto creation where at the spend it results in the 'change'(new utxo you keep) include the increased amount. which is something that can easily be validated by a network

expanding on your idea
someone that spends money 2 times a day and gets equal returned back.
obviously wont have qualifying utxo of +1day age between spends so earns no 0.0262% interest
where as as someone that waits 3 days before spending gets 3x 0.0262%

which could present as a system of slowing down peoples spontaneous spending (buying something just coz they seen it/want it that day) and instead make people plan spending habits more

[DooMAD]

devs can code what they like.

Quoting for posterity.  Pretty sure it's the first time you've conceded that point.

but when it comes to a network that involves consensus devs should not have the ability to just trojan in new features

If they could do that, there wouldn't have been a scaling debate to begin with.  People chose to run some code that you disagree with.  It's as simple as that.

what should happen is nodes upgrade to include proposed validation code. and then it activates

Bitcoin has no concept of your beliefs of what "should" or "shouldn't" happen.  And if it did happen, then consensus made it happen.  You just don't understand consensus.

try to learn a few things because you have wasted 5 years on crying about your authoritarian system where you want core devs to be the deciding power house above user nodes where user nodes have no choice

You have plenty of choices:

1) Run a client which supports SegWit and continue following the current consensus rules
2) Run a client which doesn't support SegWit and continue following the current consensus rules
3) Run a client which supports SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client
4) Run a client which doesn't support SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client
5) Run an SPV client and have no input on consensus rules
6) Run some code you wrote yourself with whatever new consensus rules you like, to form a new network consisting of one deranged lunatic all on his own
7) Run some code you paid someone to write for you with whatever rules you like, to form a new network consisting of one deranged lunatic all on his own
8) Run a node for a crappy fork like Bitcoin Cash, since it's clearly more closely aligned to your utterly misguided values and will have more than one lunatic for you to proliferate a chain with
9) Run into traffic, get hit by the largest possible vehicle and know that you won't be missed

What other choices would you like?  Pick one and STFU.  

consensus is about opt-in(vote) to activate
where lack of majority = no activation
where there is no miscount of inclusion no fork to fake majority.

We've already established that you don't understand consensus.  All you have are worthless opinions which don't matter.  And the worthless opinions of a hypocrite at that, because you continue to use the network and follow the consensus rules you claim are "fake consensus".   Like it or not, you're still here, so clearly it can't be as bad as you claim.  

you think it means activate and have those that dont opt in just be sheep following without verifying the new rules. or already thrown off the network by showing objection

It doesn't matter what I think, that's quite literally how it works.  If you try to run code which is incompatible, you won't remain synced with the network.  If my node is running code that defines your node's network magic as incompatible, it will refuse to serve new blocks to you.  You will then have a different version of the blockchain to Bitcoin's network and you will be forced to form a network of your own.  You've witnessed it do precisely that and yet you still deny that's how it works.  It happened right in front of you.  But you act as though it didn't.  All that's left to determine is if you're blind, stupid, or psychologically detached from reality.

you have no clue what the true blockchain and consensus inventions purpose is.

My understanding is demonstrably more sound than yours.  Your own words above prove that you do not understand consensus because you can't accept what you've seen with your own eyes.  Nodes don't get disconnected unless someone configures their node to disconnect certain nodes.  I'll repeat again, people chose to run some code that you disagree with.  Accept it and move on with your pathetic existence.

i dont care about being liked.

That much is apparent.

[franky1]

2) Run a client which doesn't support SegWit and continue following the current consensus rules
3) Run a client which supports SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client
4) Run a client which doesn't support SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client

this is where you get things wrong
well i know deep down you used to know this stuff.. and now your just either incompetent, ignorant or just trolling

2. does not follow the current consensus rules.
what they get from a segwit compliant node (dev buzzwords not mine) stripped/segregated/ downstream version of the blockchain that has no witness data. thus they cannot validate or verify those transactions
they also are not deemed worthy of being part of the unconfirmed tx relay peer system and not part of the seeding of the initial block download for those wanting to get the blockchain. due to lack of having full data

3&4 no longer require what you describe
funny part is for years i have been telling you that the 3&4 you describe now (which is consensus) but then you refuted that was consensus by saying that its not consensus and that devs can throw in code as they like without needing the vote.
much like you just done a couple posts above

you know that 2017 and this year segwit and taproot and full-rbf activated without the need of real vote of a mass upgrade requirement pre-activation.. . due to their mechanisms they put in to slide in activations without needing majority node readiness

you love the feature of not caring about node readiness
you love the fact that nodes are not seeding the blockchain to new peers(you love the stripped data mechanism and pruning)
you love the mandatory activation of rejecting opposition in 2017. and you love the validation bypass mechanism of 'treat blindly as acceptable' (without validation if certain opcode is used in tx) for older nodes

stop playing dumb to cause an argument that you have kept losing every time.

the blockdata and code proves my points.. but you cannot prove your point

so just accept finally for the 5th your you have no code or blockdata to support your cries. and instead stop arguing to pretend your the victim with lots of friend that agree with you.

you are just a social queen with no data to back up your game apart from  quotes that cant be backed up by data

now grow up once and for all

[DooMAD]

2) Run a client which doesn't support SegWit and continue following the current consensus rules
3) Run a client which supports SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client
4) Run a client which doesn't support SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client

this is where you get things wrong
well i know deep down you used to know this stuff.. and now your just either incompetent, ignorant or just trolling

2. does not follow the current consensus rules.
what they get from a segwit compliant node (dev buzzwords not mine) stripped/segregated/ downstream version of the blockchain that has no witness data. thus they cannot validate or verify those transactions
they also are not deemed worthy of being part of the unconfirmed tx relay peer system and not part of the seeding of the initial block download for those wanting to get the blockchain. due to lack of having full data

Yes, option 2) does follow consensus rules.  Stop trying to change the definition of consensus to mean "only allow the things that align with my personal beliefs" because that's not what consensus means.  If you think that's what it means, you're going to be frequently disappointed.  Also, option 2) is still a valid choice when you stated unequivocally that "user nodes have no choice".  So, wrong on every front so far.  Let's continue...

3&4 no longer require what you describe
funny part is for years i have been telling you that the 3&4 you describe now (which is consensus) but then you refuted that was consensus by saying that its not consensus and that devs can throw in code as they like without needing the vote.
much like you just done a couple posts above

you know that 2017 and this year segwit and taproot and full-rbf activated without the need of real vote of a mass upgrade requirement pre-activation.. . due to their mechanisms they put in to slide in activations without needing majority node readiness

you love the feature of not caring about node readiness
you love the fact that nodes are not seeding the blockchain to new peers(you love the stripped data mechanism and pruning)
you love the mandatory activation of rejecting opposition in 2017. and you love the validation bypass mechanism of 'treat blindly as acceptable' (without validation if certain opcode is used in tx) for older nodes

I see.  So, in essence, you just want to quibble about opt-in, backwards-compatible features, because you despise freedom.  And, rather perversely, believe that others having freedom to opt into new backwards-compatible features somehow impinges upon your freedom.  But the only way that would make sense is if you believe you have the freedom to deny freedom to others (which is certainly possible, given that you really are that fucked in the head).  

You want to (seemingly deliberately) conflate 'agreement with willing participants' and 'overall consensus rules'.  If you actually understood consensus (and clearly you don't), you would know that the consensus rules are the ones that determine the validity of the network and the blockchain.  Nothing more, nothing less.  Features can be implemented in such a way that won't break consensus rules, but still allows willing users to take advantage of features which other users have no interest in using.  Anyone rational would call that a good thing.  What's your malfunction?

More to the point, why do you continue to use open-source software when literally anyone can introduce a backwards-compatible feature and there's literally nothing you can do to prevent it?  "pEoPlE sHoUlDn'T bE aLlOwEd To CoDe ThAt".  Unenforceable.  You have no answer to it.  You clearly despise it being the reality of the situation and you fully recognise you are powerless to stop it from happening time and time again.  Why don't you find a closed-source project where people don't have the freedom to make changes that cause you to spend the rest of your sad life pissing into the wind and achieving nothing?  Again, you will never find what you want here.  Because what you want is to deny freedom to others.  You are inhuman garbage.

you have no code

I've got code you despise.  It functions perfectly well.  Loads of people use it.  You have no code you approve of.  Everything you like only exists in your imagination.  Therefore, you've got it backwards yet again.  It is you that has no code.

[franky1]

locking topic until the malicious troll forgets where he is and what he was trying to say (as always) and returns to his hobbit home of his favoured subnetwork

2) Run a client which doesn't support SegWit and continue following the current consensus rules
3) Run a client which supports SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client
4) Run a client which doesn't support SegWit and proposes a change to consensus if a given activation threshold is met, hoping that others run the same client

this is where you get things wrong
well i know deep down you used to know this stuff.. and now your just either incompetent, ignorant or just trolling

2. does not follow the current consensus rules.
what they get from a segwit compliant node (dev buzzwords not mine) stripped/segregated/ downstream version of the blockchain that has no witness data. thus they cannot validate or verify those transactions
they also are not deemed worthy of being part of the unconfirmed tx relay peer system and not part of the seeding of the initial block download for those wanting to get the blockchain. due to lack of having full data

Yes, option 2) does follow consensus rules.

READ YOUR OWN WORDS

" Run a client which doesn't support SegWit and continue following the current consensus rules"

how can you say something is following the current segwit rules if it doesnt support segwit!!

also
how can you say something is following the current taproot rules if it doesnt support taproot!!

if it doesnt support it they are not validating things they dont understand. they are just BLINDLY using an opcode trick to accept without verifying the transaction..
thus they are not following the consensus rules becasue they are not verifying all the rules because they dont have all the rules to verify everything. they are no longer full validation nodes

YOU HAVE BEEN TOLD THIS
DEVS ADMIT THIS
so its time YOU ADMIT IT TOO
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#backward-compatibility

older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.

What a non-upgraded wallet cannot do
Validating segregated witness transaction. It assumes such a transaction is always valid

(treat as checked without actually checking)

this applies to taproot too
nodes that do not support taproot do not know the code/rules needed to verify taproot so are (by use of opcode trick) told to accept it unchecked)

PLEASE DO SOME RESEARCH!!

again a segwit compliant node strips/filters out (witness)data and gives the unsupported node a block that has less data than a segwit node has

the unupgraded node then doesnt verify segwit transactions and just blindly gets told to keep data unchecked.
those unupgraded nodes are down rated as less then full node. and not treated as good source nodes for IBD


true consensus is about agreement by the masses to then activate a feature becasue the masses agree they are ready to accept the new rule

however the mandatory activations, the backward compatibility stripping/filtering of data and the op-code tricks means those not upgrading are not voting at all. they are simply downgraded out of being full nodes and the features are activated without their need to agree/consent

true consensus for emphasis one more time because of your ignorance it needs repeating
was that rule changes did not happen new features did not happen unless the mass of nodes were ready to fully verify new rules new data. as thats the whole point of a secure network

your desires of a network of nodes that are not fully verifying and not needing to fully verify and not keep full archive data while in your stupid eye want too pretend they are still "full nodes" is your incompetence of understanding network security, code, protocols, rules and consensus requirement

how go do some research and stop being a corporate defence troll, at the expense of weakening the network