Topic: Time to roll-back Ordinals? (Read 2137 times)

its not about that. code can do wonderful things. its not just about nodes own mempools. thats just the first post/checkpoint that makes transactors think about the transactions they produce to have best chance of even reaching a mining pool... when broadcasting to peers at the pre-confirm relay
if they want better chances, they organise there transaction to be lean, mature utxo and not use certain junk opcodes

separately.. the consensus enforcement..
its about when mining pools solve a block. nodes check if they contain junk that has not paid fair fee according to fee formulae.. reject the block. thus enforcing pools to actually choose transactions wisely. its what consensus rules are for

you call it censorship resistance.. but just look at what mining pools do now. they cherry pick transactions anyway. atleast having decency rules about what should get priority to get included first.. where the indecent junk get penalised personally if they want to be included. again its not censorship if a spammy junk bloaty transaction has to pay 200x higher than a normal tx.


not even a 2 step mining process.. just a fee formulae score reading. as soon as it reaches a threshold of priority, put it in the block template, if not just leave it in mempool until utxo age matures or transactor RBF. or mempool of mining node prunes low priority thresholds

...
my posts about a fee priority formulae are not about censoring (default reject, no question) transactions. its about penalising transactions specifically independently without penalising everyone.. transactions that spam(young utxo). bloaty transactions(tx length). junk transactions (abuse unconditioned opcodes)

No, it's not that easy.

Nodes don't have an uniform view about the mempool. So you can't force miners to include certain transactions that pay a certain fee or have waited a certain time, because you can't know they have seen them. It would be necessary to know which transactions "exist objectively" for an efficient priority mechanism, but that's simply not possible when we have decentralized mempools.

If we could enforce a priority mechanism by consensus rule, then we would also be able to enforce an "anti-censorship" rule, i.e. that no transaction that pays enough fees could be discarded by miners. But that has the same problem.

The only way I see to implement such a thing is with a two-step confirmation process: Miners in a block simply collect transactions without verifying them, and in the next block another miner confirms them. This would need collaboration of two miners to override the priority mechanism, but still would be possible. (I have previously mentioned in some discussions a mechanism where nodes have to sign the txes they "know", but this could be gamed, too.)

If you see a way, then - we'd have censorship problem solved, so I'd love to see your BIP

he didnt dismantle anything.. try to read like someone that knows the code.. not someone on auto pilot allegiance to core dev gods sponsorship deal preferences.. .. .. he twisted words and pretended x crap didnt happen (but then debunks himself by then saying it did but not in the way he read me saying it). then he goes on and says things cant be consensus because by definition its not. but then says how nodes are consistant in things based on known parameters..

priority formulae CAN be made a consensus rule.. anything can be made a consensus rule.. the rules are just code. and anything can be made a rule and enforced by the code..

got to love gmax's twistings
everyone this week has seen mempools pruned purely for low fee rate.. everyones seen it. the prune rule is remove transactions due to a fee rate..
where as a fee priority would remove spammy, bloaty transactions first..

so when this was said

he pretends pruning mempool has nothing to do with the fee rate, "market".
(facepalm)
its the fee rate level, rules and code that decides what to prune!! which affects the market.. its all related and symbiotic

rather than a proper coded formulae that would have decided that spammers should be pruned or bloaters should be pruned first

THEY CHOSE to make the pruning no longer remove spam/bloat first. and instead remove low market fee first

the point i raised then and keep raising is we keep getting occurrences of congestion where junk and spam are allowed in and many peoples genuine transactions are dropped due to a fee rate rule. rather than a rule that actually prefers to drop junk/spam first.. rather then a rule that penalises just the junk/spammers
they prefered to "simplify" to "just a fee market" to cause everyone to be penalised when junk/spam occured but not deal with the junk/spam problem..

..
next funny is how he says about how this stuff reduces all the transaction relay repeats.. but then due to their actions, guess what.. people need to re-send their transactions to get back into mempool if the market goes down or respend with a higher fee RBF before being pruned or after being pruned if still not high enough or even send a child transaction to try to keep the low fee in mempool.. thus more transactions do get relayed just to fight the pruning mechanism

If people wish to form their own conclusions as to why 'priority' was removed, they can view the pull request in question here.  Let's see if anyone else can find evidence of a conspiracy.  

Bonus:  here is a post from a developer dismantling franky1's numerous misunderstandings about network function and fee policy.


//EDIT:


Sure.  It could be.  But no one likes you enough to listen, so it won't.



That's certainly one perspective.  Another is that the dev correctly interprets the situation, whilst it's you who twists all the words and does all the pretending.  

Yeah the network could be strengthened.  One way is to recognize the main purpose is not sending 0.00009999 btc or less in a send.

As the main chain should not allow small sends.


0.0001 is $3.75 value its small enough.

and 0.00001 is minimum fee that is  $0.375

Also 8mb blocks.

These three changes along with no node pruning allowed would work.

4tb ssd are cheap they can handle a larger chain.

Full sized nodes are a must.

Also certified a ssd with linux os and first 12 years of the chain could be sold by a few companies.

not as rubust as you think it is.. there is actually a tier system of node types and abilities.. its not as peer-to-peer equal as you have been told
your mentor pretends that pruned nodes are "full" nodes, that 'backward compatible' stripped nodes are "full".. they are not. they offer less peer services and do less functions than an actual full node does

learn the differences of what effects things have on the network when/if too many nodes 'prune'."strip",'bypass' EG use 2015 'backward' software thats stripped blockdata to then not IBD to full nodes, and bypasses validity checks.. or use 2019 that bypasses taproot validity checks.
 
with 99.99% of nodes reliant on the code of core(multigenerational but still core based), there is a central point of failure effect aswell. bitcoin no longers stands by the solution of byzantines generals problem.

years ago people wrote different nodes that knew the rules but checked them different ways in different code languages (coding is great at doing that) but things have got too cludgy and just become the same copy/paste line for line bug included bypass stuff as cores own node release..

bitcoin can be more robust than it currently is.

A real down-time by its real definition is something that stops functioning, and in the context of a cryptocurrency network going through a down-time would probably be when it stops producing blocks and a majority of full nodes can't connect with the rest of the network to validate.


I'm talking about how the network is currently designed, and it's robust.

the bitcoin network WAS NOT actually designed like that
before core. there were fee formulas("priority" threshold) where:
50kb of a block was for 0 fee high priority based on a few factors
250kb of a block was for high fee low priority based on a few factors
700kb of a block was for low fee but above min relay fee
simplified

buy spending in a leaner tx makes number bigger. by having more confirms makes the number bigger, by keeping more sats to spend instead of declare as fee makes the number bigger.. in essense by not spamming every block, by not spending just a few sats, by having a lean tx you can get away with not paying a fee at all and have more priority then a bloaty tx that has a large fee


its not always been the "fee open market" your forum-daddy mentor has told you. its become the way he likes since core removed these things... because dev politics want bitcoin to be expensive and headachy to use.. to promote that people should move over to their commercial middlemen service proposition of subnetworks where they can take a cut of commission from middlemen fees.. they can only charge sustainable middlemen fee's IF using bitcoin direct is not cheap

causing a fee war and fee market is not about "miner" economics. core devs are not tweaking fee calculation junk for some altruistic cause to help miners. its all dev politics to appease their corporate sponsors

bitcoin WAS NOT designed to appease corporate sponsors feature that aid corporate ROI.. but it has become it.. and bitcoin is not AI that changed itself. core devs did.

It depends on how you define downtime. In 2017 there were a couple of times that the exchanges were forced to shut down all deposits and withdrawals of Ether and its tokens because the network congestion had effectively crashed their system!

But that's how the network was actually designed, with the regulated blocks and the fee market. I know it's an inconvenience when the fees are high, but from an objective viewpoint, look how robust the network currently is in the middle of the so-called "Ordinals Attack".

A user could make an argument that Ethereum is as robust as Bitcoin because it too has not experienced any down-time, BUT try running an Ethereum node with your home computer. Ethereum developers gave up the ability to scale out for more transaction throughput, AND they're fees are STILL high.


Although that's not my personal opinion, in another topic I did say that's how he'll be remembered.

This is true. As a collector of old blockchain knick-knacks I looked into it once and all the original Colored Coins protocols are dead. I tried messaging their creators and they never responded to me.


Point taken. The big difference is BRC-20 tokens can't offer any kind of functionality... They aren't being used for anything other than hot potato ponzinomics. I suspect we'll never see them gain functionality as it will be prohibitively expensive to move them around as compared to ETH (usually), MATIC or BSC. Besides, that's not what the players of that particular game are there for, anyway.

I added "pseudo-" because unlike BRC-20, the ones on other networks such as ETH, BSC are actually being used for practical things. Not just as a price ticker.
(Sure there are a large category of money-grab altcoin tokens as well, but it doesn't comprise *all* the network's tokens like the BRC-20 ones do.)

great thing about code is there are many ways to do thing
however fees recently were 5sat/byte.. now 200sat/byte.. meaning 40x.. so you only wanting to penalise them by 10x is low
also them taking up 10kb with lean tx being 0.25kb is again a 40x space steal.. so penalty should be way more then 10x. more so a minimum multiplier of 40x.. id prefer 200x



i was thinking back to the days when there was a fee formulae that created a 'priority' score. where by first 50,000bytes had 'priority' of 0 fee(lean tx, old utxo age). then there was 250,000byte of high fee space and then 700,000byte of low priority low fee..
but modernising it by using a priority space based on opcodes.. where there were 2 separate "fee estimation" where nodes would default to 200x fee for the 10% space of junk.. that junk can only go in that 10% space. and mining pools would only put junk in if they are paying the 200x fee rate estimate..
this too would make the scam junkers think again if its costing them 200x * X% of blockspace for 1 tx.. and instead they become leaner to fit in more brc creations per block in that 10% allotment. but yes paying 200x for lean junk

Sorry, I sometimes skip your posts since they are filled with drama and LN/SegWit bashing

10 kbyte is too big though. Even a big ass multi-sig script containing 15 public keys (15*33=495) and 15 signatures (15*72=1080) barely reaches 2 kb (2000 bytes) and nobody uses such a crazy script.

P.S. IMO since 10k is the script size limit for legacy and witver 0 scripts, I'd say reject anything bigger than that for witver 1 as non-standard instead of just adding a penalty.

I may have a simpler idea - adjust the weight unit calculation and place x10 multiplier on script sizes >10000 bytes. This means the vsize is now almost x10 itself which corresponds to an x10 increase in fees. Now Ordinals and BRC-20 users who abuse the protocol to dump stupid JSON like:


will be paying a penalty to miners (who still win regardless, because even if BRC-20 volume reduces to 10% the x10 fee on the remaining inscriptions compensates for that.) Also covers OP_RETURN edge cases at the cost of making fringe use-cases for Bitcoin more expensive for L2 node operators.

i already explained in many topics and this one about conditioning the opcodes(looking for certain details). so the "penalise only junk" was related to that, having conditions and fees and penalties for just a subgroup of transactions.. much like is done by making legacy * 4 but in a more detailed and enforced way

i was trying to keep it short (avoid "wall of text") as it appears some other people dont read more then a couple lines before they get on the defensive

I like this option more since at the very least it makes abuse very expensive while satisfying those who claim "censorship"!
But through script size threshold not OP codes because if we place any kind of restrictions on OP codes we may end up hurting regular users who aren't injecting junk into the blockchain.

and yet the certain people that dont want anything done to bitcoin.. because they dont think transactions should be rejected... are strangely happy that transactions get rejected(pruned)

a LEAN tx of 226byte. paying rejectable amount of 21sat/b is 0.00004746 = $1.76

and so minimum fee of $1.76 is being rejected.. for being too low..(facepalm)

heres another idea
(if they fix the current byte count code cludge)
have a 2 tier system.. (there used to be one years ago)

90% of block base 1mb blockspace, standard tx(normal legacy, normal multisig, normal segwit not using opcodes of 'assumevalid' bypass)..
10% block this junk using certain opcode and or their utxos are less than 144confirm age

where by those in the 10% category are paying a fee rate for that space of 200x of base rate. and the usual normal standard 90% pay base rate fees from 10sat per kb  (lean 226byte=3sat fee total)

atleast that would appease the contradictory morons that want the junk to continue

Yeah, you wish. Today I went to pay an invoice and the transaction fees have suddenly rocked up again to 280 sat/vB for low priority, and pruning is activated for <21 sat/vB. 

I disagree. Bitcoin is still solid.