pull down to refresh
@Murch
stacking since: #127838
222 sats \ 0 replies \ @Murch 11 Sep \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
The outcome depends on how much of the hashrate is accepting the offending transactions. If both the majority of the network and the majority of the hashrate is rejecting some transactions, yes, the miners that include those transactions will have a greater delay for their blocks to reach other miners. This delay causes a higher stale rate, so the lenient miners would be more likely to lose blocks to competitors that can propagate blocks quickly.
However, if the majority of the network rejects some type of transactions, but a majority of the hashrate accepts those transactions I would expect the effect to present differently: miners are generally well-connected, and the miners with loser mempool policies would likely all be connected via the subgraph with the loser mempool policies. A miner publishing a block with offending transactions would see it propagated quickly to the majority of the hashrate. Meanwhile the minority of miners not accepting the offending transaction would be the only ones affected by the delay: they would be more likely to still find a competing block when the majority of the hashrate had already switched over to extend the chaintip with the offending transactions. I would argue that in this case, the delay actually helps the majority miners with the loser policy because it causes the stricter minority to waste hashrate, similar to a selfish mining attack.
So in short, yes accepting unpopular transactions hurts your block propagation if both the network and other miners don’t accept them. However, you may also be collecting more transaction fees that may offset the loss to some extent, as the propagation delay we are talking about would cause an effective revenue loss of around 1%.
Bitcoin Core 30.0 includes a new mempool policy against legacy transactions with an excessive signature operation count (see https://github.com/bitcoin/bitcoin/issues/32521).
via Optech newsletter #364:
Did you have a specific point in mind that you would like to see explained further? I already spent about ~20h in the last three days mostly responding to Chris, so if you could narrow it down, I’m happy to answer here.
The "special thing" about Runes is that they do exactly what BRC20 was doing (defining, minting, and transferring tokens), but it does so in OP_RETURN outputs, which do not get added to the UTXO set, in a blockspace efficient manner. So, it’s simply better in all dimensions than BRC20 tokens at what BRC20 tokens supposedly do, without resulting in an incentive to create minuscule abandoned outputs. And it was created by the inventor of Ordinals which probably makes it even more blessed in some circles. :shrug:
If you are worried about this, you should go back in time and stop running Bitcoin Core more than a decade ago, because the blockchain has had such 'objectionable content' in it for longer than that.
As pointed out elsewhere, we think of the
minRelayTxFee as a minimum cost for the network to forward a transaction. When the minRelayTxFee was reduced recently, also the incrementalRelayTxFee was reduced, as it doesn’t make much difference whether you are sending a new transaction or use bandwidth to replace an existing transaction with an updated version of it. In the upcoming Bitcoin Core 30.0 release, they will both be 0.1 s/vB which means that you will need to pay at least 20 sats for the 200 vB transaction from your example for it to be relayed, and if you were to bump it, a replacement of the same size would need to increase the fee by at least 20 sats to be forwarded by nodes.I think that what Luke argues is that a miner including all these shitty txs is comparable.
That’s charitable of you, but Luke literally claims that
-datacarrier has always referred to all forms of embedding data, when that is in direct contradiction to the discussion around and documentation of the introduction of -datacarrier. He even unilaterally filed a CVE for that. As far as I am aware, no other Bitcoin Core contributor shares this interpretation.Just how terribly designed BRC-20 is from top to bottom really adds insult to injury.
Interesting point about the complexity, needing to create multiple outputs and inputs would have definitely made it more expensive and a bit more complex. So, yeah, Taproot did make it easier, and if it had been harder, the BRC-20 author would have perhaps not created his proof-of-concept design for a laugh. Just how terribly designed BRC-20 is from top to bottom really adds insult to injury.
Bitcoiners were paying artificially inflated prices to get their transactions confirmed?
For large parts of the last three years, there were transactions in the mempool bidding more than 1 s/vB or more. For those periods, the answer is clearly no, because the price was determined by the blockspace market, and not the minimum feerate. Beyond that, I was very surprised that the miners didn’t think their incentives through and went along with mining transactions bidding less than 1 s/vB. It seems to me that they permanently reduced the ceiling of feerate peaks, simply by replacements being incremented in smaller steps. If they had thought it through, and considered how little these fees brought in the big picture, they should not have deviated from the established minimum feerate. If they had not performed this unforced error, no in general as well.
Jargon nit:
Block reward = block subsidy + transaction fees
Inscriptions being caused by a bug in Taproot is an often repeated, but unconvincing narrative. I would agree with "none of the volume spikes were caused by a softfork".
The 2017 spike coincided with a big bullrun to a new ATH. There just was massive trading and transaction volume. While Segwit had been activated, most wallets didn’t support it yet, and most transactions were still non-segwit.
I bet this drama would be much less heated, if we would try assigning statements to the people that said them, instead of larger groups of people that they are not even part of…
We could also try checking claims before amplifying them. Wouldn’t that be something?
Not just petty, but also illustrating how law enforcement is deployed on his whim for personal reasons.