Avatar
Cody
c6ddba5ee3dc641aa5b1b88bfed85ece646153bd9d598866c4122defb9c10a73
Wyoming
Replying to Avatar OrangeSurf

Miners determine which of the valid transactions in their mempool are selected for inclusion in a block.

Aside from the need for transactions to be valid, there are no consensus rules around transaction selection, miners are able to use whatever selection method they wish.

So how do block templates compare? Let's examine what happened prior to block 821498 (mined within the last hour).

The block mined by Antpool had a max total bid of 7.73789496 BTC. You can find this using bitcoin-cli getblockstats

My local instance of bitcoin core running the default policy rules + FullRBF had a max total bid of 7.71806816 BTC, lower than the mined block by 0.01982680 BTC.

The block templates provided by nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3

had a max total bid of 7.7334687 BTC, lower than the mined block by 0.00442626 BTC.

The block template provided by ocean npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze

had a max total bid of 6.6127135 BTC, lower than the mined block by 0.43183364 BTC

Filtering policy and sorting method vary by pool, but mining is highly competitive. For how long can mining pools who do not maximise fee revenue survive?

The rate of my data logging (every few seconds) means it's inevitable that I don't capture the latest templates, so that accounts for a small part of the delta. You can see on the mempool block audit page that the expected mempool space template for the mempool block is 7.737 BTC , slightly higher than the 7.7335 BTC template I captured.

An additional source of the delta is that there were some transactions (in blue) which AntPool included which were not in

@mempool

's mempool and likely not in mine or oceans (I didn't save the block template so can't check).

These 6 transactions pay a total of 4,072,619 sats in fees. Plus there is a transaction that was included which had a marginal fee rate, paying a 73,828 sats.

A total of 4,146,447 sats

To create space to include these transactions 45 transactions were dropped, each paying 89,833 sats.

A total of 4,042,485 sats

Including these transactions resulted in a net increase for the in band fees of 103,962 sats (0.00103962 BTC)

Check the block audit at https://mempool.space/block/000000000000000000028bdf4456e7e2519b0ba4b6d52cea0cc18c726f60a578

Hopefully long enough for them to implement StratumV2 so hasher's can go back maximizing profits. But it seems nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze is bleeding hashrate.

I think nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze long term is a great pool but I'm beginning to wonder if their stance on Monkey jpegs is going to result in failure to launch. They are now running a little cold(block luck) and slowly bleeding hashrate.

Who is paying these on chain fees!?!?!? 🤞that nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze finds one if these juicy blocks

True. Bullish on the price, but bearish on the culture and decentralized on Bitcoin going forward.

Replying to Avatar Luke Dashjr

The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.

It is not my intention, nor that of my team at

nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.

Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.

🔥🔥🔥

What kind of sailing are you into? I cruised the Pacific Northwest engineless* for five summers on a homebuilt cutter. I've been getting the itch to get another boat

Oh this is a World War Z thing! If 9 of the ten men agree it is the duty if the 10th man to take the other position.

Why don't you just sell your goods to fund this website? You leatherwork seems great, which means you probably don't need to beg for charity, just sell your goods and pay for the website like every other entrepreneur. This is not a good look imo