Topic: Eligius pool is back under the new name Ocean - page 10. (Read 3019 times)

Luke and the team essentially said that the first two blocks including inscriptions was due to not having the filtering fully in place, but it is the intention nevertheless. So the next block will probably be ok without inscriptions if all goes according to the team's plan.

On the plus side, Luke's comments on the matter have been gathering a lot of positive attention. Many people seem to be looking forward for the next Bitcoin Core release to block filter Ordinals entirely after Luke said it's possible:


Via https://x.com/LukeDashjr/status/1732204937466032285

Look at all these retweets and likes this tweet has.

Well , looks like finally ocean established it's position on filtering transactions .

"We are happy to announce testing of Bitcoin Knots v25.1 has completed successfully, and is now deployed to production. Among other improvements, this upgrade fixes this long-standing vulnerability exploited by modern spammers. As a result, our blocks will now include many more real transactions and help to bring an end to the DoS attack being performed on the #Bitcoin network."

https://twitter.com/ocean_mining/status/1732207450114162855?s=20

oh boy, tell me about it, I just had a 3-4 day long debate on repution last week (in case anyone missed me here) . I hate debates.


You could call them whatever you want, it doesn't change the answer to your initial and main question which was/ still is




Ok, we have to stop here, at this point, I can't help but think that there is a major misunderstanding at the core of this topic, you are confusing two things, block weight and block size.

When Segwit/Block weight came into existing (bip 141 IIRC), the introduction of a new "way" to measure segwit transaction was introduced, and it's a simple formula;


In plain English, the segwit upgrade added another 3MB which could only be facilitated by witness data, so a non-segiwt block will still be capped by 1MB, so in theory a 100% segwit block could have the size of 4MB which is 4vM or 4M weigh units.

Nowadays, the VAST majority of transactions are segwit, which means, almost everyone using BTC is getting what you call a "discount", so everyone is using/abusing those 3MB added by the core devs.

So now we need to think of a Bitcoin block as 2 disks in 1, something like a bus where the bus cabin has a max capacity of 1000KG worth of people, and 3000KG in the luggage compartment, of course, people are free to cut their hands and put them in the compartment to spend less on those limited 1000KG,

Now if someone is pretty fat and weighs 1000KG and isn't willing to cut any of that fat to put it in the luggage compartment to allow other people to ride with him, that person will need to pay for the 1000KG + the 3000KG luggage compartment.

I like this analogy so let me keep going;

if that fat ass offers the bus driver 1k for the ride but then come 50 people who weigh 80KG each (4000KG in total) and are willing to cut 3000KG of their body parts to send it to the luggage compartment, each of them offered to pay only $40, the bus driver will then collect $2000, so he would pick these people first because he makes an extra $1000 in profit.

The bus driver here does not care about how the bus is going to be filled, he just runs a simple code that picks the best combination of people that would give him the highest reward for the trip, it could be 5 fat people or 500 apes who could squeeze themselves in and pay more per KG, he just couldn't give a flying fudge.

Are we not counting transaction fee discounts as discounts now?
I thought it was pretty standard bitcoin functionality by now, enough for most users to understand how they work.

For taking more block space, these transactions pay less fees (by the actual space). They unit is called vBytes because the fee is accounted in VIRTUAL bytes.
So, if that's not a discount, what should we rename this as?

No it doesn't mean that!
To have a 75% discount he would need to pay less per sat/vb than the others by 75%, which is not happening.

People sending 1 billion BTC in a tx don't have a discount on those that send half a coin.
People that cram 100 t-shirts in their luggage don't have a discount over the guy who puts in their already inflated sex doll.


Hihi, please to elaborate how
-replacing a tx of 5kvb that pays 50sat/vb would fetch more than 10 tx of 0.5kwb paying 45sat/vb
-also, how in name of god would a tx that pays more in fees not be already included in a block before of an ordinal that pays less per sat/vb


I'm pretty sure that the guys who told us we need to keep nodes requirement as small as possible to run on every computer as cheaply as possible are going to start saying we need each bitcoiner to host some 10kw $20k machines in their bedroom for the sake of decentralization. 
Everything around the forum lately is just popcorn material! Oh, sorry, fudgeee!

... this on and on going 'but but but what about the discount' ...

It's quite clear from the start that there's no special discount for 'ordinal' transactions, they pay as much per space as any other non '1' output transaction.
Bitcoin tries over and over and over again to maximise the fees received (there's a loop that tries a lot to do it) and ensure you get the most per block.
There is no special 'ordinal' transaction discount.

An 'ordinal' transaction is just a transaction, like any other.
The problem with 'ordinal' transactions is that they use a flaw in taproot to make very large transactions of whatever data you like.
If you pay a lot (per space) to put it in a block, it will win out against transactions that pay less (per space) to be in the block, if there's enough space left over after filling it with all the higher paying transactions.
In fact since they are so large, and due to the above, they may not make it into a block and there may be a bunch of lower paying transactions in the block with total space less than the 'ordinal' transaction.

I highly suggest he go read the code rather than believe some random person who told him about some 'special' ordinal discount.

Or I could point directly to where I made the mistake of thinking there was an issue and a number of people jumped at me pointing out I was wrong
https://bitcointalksearch.org/topic/m.61863960

This is not true, which is what I have been trying to explain to you, I literally gave you the code logic that does the sorting, the number of transactions is irrelevant, it is all about how much they pay per space unit.

You are probably better off with ignoring virtual size, just think of the block as 1MB in size ( that is what it actually is on the desk anyway).

If 1000 transactions each of the size of 1kb and all are paying 1 sat per kb, the total fee reward for the miner would be 1000 sat, if someone else has a transaction size of 1kb and decides to pay 1000 sat per kb, one of those 1000 1 sat guys will need to waite, if comes a guy with a transaction size of 1MB and is paying 1001 sat per kb all those 1 sat guys + the 1000 sat guy will have to wait till the next block.

So it is all about bitcoin spent per space unit ( be it byte or Vbyte), so every transaction that gets included always makes economical sense.

I'm not saying that miners should block anything.
Actually, they can do whatever the hell they want.
And that's what has been happening anyway.
In fact there's very little about what we can do about other people's hash power anyway.

But the argument about including ordinals in blocks because it makes the most economic sense doesn't seem to actually make too much sense from what I see.
At a time of high transaction congestion, a block template that made space by excluding ordinals to replace them with many more smaller transactions, would likely get similar or perhaps even higher fee rewards.
So all I'm saying is that in the end it doesn't make much of a difference economically probably.
But I'm not the one that came up with this argument actually, so the burden of proof lies with the accuser.

OK but what is your argument? here is another random non-Ordinal transaction from the same block the got some good "discount"


had it been non-Segwit, it would have doubled the fees.

Why does it look like the transaction you linked tricked the pool in anyway? it did not, it used segwit+taproot to minimize it's virtual size, it paid 40 sat / Vbyte which was the median fee rate for that block, so he did not outsmart the mining pool, he paid a nice 207,778 sats on a transaction that consumed ‎19.99 kB on the desk, the fee/space checks out, nobody cares if that was a discount, the core code allows them to do so -- so they do it.

So based on this logic, if you ask miners to block those transactions, then they would also block segwit transactions, because without segwit, transactions would take more space and thus increase miners profit, so they would censor P2TR, P2WPKH and force everyone else to back to P2PKH.

Miners do not oppose any protocol upgrades that make transacting on the blockchain cheaper, so nobody should expect them to oppose transactions that pay more, miners would take every sat they can off the table.

Also, keep in mind that most pools use the default getblocktemplate made by core devs, the way it operates is rather simple, it sorts transactions by sat/byte, something like


There is no "transaction type" or "who" is transferring "what", it's all about sats.

How do some ordinals transactions get a 75% discount?
Idk, maybe you can look at the tx I linked, hover over the green text saying "SegWit" on mempool.space and verify it yourself to tell me as also. (77e996de08c48ed282a7b8bc88ca199712a15fa68babb10a0b3ee760674cf21b)

Do non-ordinal transactions regardless of address type get the same discount? Probably not as they don't throw as much data in the blockhain.

The dynamic that is created here is that you get a transaction that is considered to be paying optimal fees, while actually grossly underpaying for the space it takes in a block.

Look at the stats for the provided transaction:

‎Size          19.99 kB
Virtual size ‎5.07 kvB

75% discount means the one making the inscription actually pays for what can count as an acceptable optimal fee transaction on the Virtual size instead of the actual space it takes.

How does it get a 75% discount?

All transactions that are not '1' addresses get it - that's what core decided long ago
(for no real good reason other than removal of the witness data made them somewhat smaller)

Though the reality actually is that '1' addresses pay 4 times as much as '3' and 'bc' addresses.
Not the other way around.

Again, core getblocktemplate (used for mining) maximises your block fees gained, on what is available, your supposed discount is irrelevant.

I feel like you're not answering my main question. Maybe I'm dumb, so let me dumb things down (for my own understanding).

On the point of Ordinals making sense to include in blocks:
I presented a transaction where an ordinal gets a 75% discount.

I was then told anyone can utilize these discounts.

But it's only ordinals that utilize the discounts to that extreme by essentially tricking the system.

---

So tell me in the end, with these massive discounts, does it make more sense financially for a miner to actually include an ordinal inscription or to include non-incription transacitons that don't abuse fee discount mechanisms?

It does not, this is what I have been trying to explain all along, this is the mining section where most people are miners who pay bills and invest a lot of money, the majority could not care less if you are transacting btc to buy coffee or to upload some stupid worthless Jpeg.

So miners can't fix this issue because they do not view it as an issue, but rather as a solution to the low income, if you post the same thing in the bitcoin discussion board -- the answers will differ, but again, if this is actually an issue, it needs to addressed before the core devs, miners simply do not care.

And BTW, i do not have a crystal ball but if any pool starts to actually ban Ordinals and start to pay less than other pools that do not, said pool will go broke, i so want to be proven wrong if one of the pools is willing to launch this experiment.

Yes, anyone can utilize fee discounts, but who's actually going to ABUSE them?
Someone transaction BTC from address A to address B, or someone uploading entire JPEGs on the blockchain?
That's the thing that matters on this issue.

This is funny.

Luke was the first to advocate censorship on a large scale by adding blacklisting of casino addresses - and it also randomly got other addresses.
He put it in the debian PPA and the code even stated it was blacklisting.
So anyone running the debian/ubuntu/whatever release of bitcoin back then was censoring.
After many complaints on the debian dev site it was finally removed.


As stated above, it's core bitcoin's calculation to maximise the block reward.
If you have some baseless conspiracy that bitcoin core code is crap and can't do that - go complain to them.

Not just Ordinal, every type of transaction could use/abuse/exploit those upgrades to make their transactions smaller in size and thus save on fees, but that does not matter, what matters is sat/Vbyte, so to answer this question


I am not sure, and it does not matter, the transactions that pay the most per the space they use -- make perfect sense to be included, you could argue that Ordinals are spam and should be banned on a protocol/node level, but that would be a different topic to discuss, the majority of miners would want to make the most profit regardless.

I am sure many miners would settle with lower payouts using a pool that does not censor certain transactions (like ditching F2pool for another pool), but settling with less profit due to the censorship of Ordinals isn't going to work, you may get a few miners to side with you on that regard, but I wouldn't be so optimistic, of course, this would also apply to pools that would for example do the opposite, like ban non-Ordinals transactions that pay more just to accept Ordinals that pay less.

That's job negotiation protocol of stratum V2 .
Miners creating their own templates will create a profitability disadvantage for the pool and the miners . If each user of ocean starts creating his own template that means that they will start working on it . So , the pool is not pointing it's entire hashrate for producing a block . It's essentially solo mining re introduced .
The reason pools were created is to increase/stabilize profitability . I don't see any reason miners will start using it in massive scale .
I'd like to hear what other people think .

How sure are you that Ordinal transactions make sense to include in blocks economically?
Did you know that Ordinal transactions can get a ~75% fee discount from exploiting Taproot OP codes and SegWit?

Example: https://mempool.space/tx/77e996de08c48ed282a7b8bc88ca199712a15fa68babb10a0b3ee760674cf21b

So maybe it could be in a miners best interest to actually not mine any of them as they take too much space in blocks and get big discounts.

Ya, good luck finding miners who would leave money on the table.



It is still custodial no matter what, the custodianship only ends when you receive your payouts to your wallet, and it starts again right after the first hash you submit, so the pool will always be custodial of something, be it your hashrate or the actually sats.

Currently, the pool would find a single block every 12 days, so in terms of custodianship, it's worse than all PPS pools, and it doesn't matter how much hashrate it gets, any PPS pool could outpace it in that regard, a PPS pool could start paying out every time they find a block or even every hour for that matter. so what gives?

You would expect that these devs would have created a truly decentralized mining pool, but no, just make another ordinary pool as if more pools will solve the problem, what happens when Luke gets a warning from the authorities and is forced to censor certain transactions, is he going to fight the government over it? creating a single point of failure is not going to solve censorship.

Yes, that was also a point I recogniced when I looked after the stats.
Looks like that only the big miners need to be decentralised on that pool.