I doubt there would be a material difference even in that case. I wonder if anyone has tried this experimentally on regtest to see if it's true.
> If there is a sudden arrival of 100 transactions with big fees and big size in vbytes they might blow out estimates, and you don't see it if you are blocksonly.
It's possible to like the product without liking the producer
To be clear, I do like Luke, but I think the closest I've come to "supporting" him is the phrase "I do like Luke" in this sentence
And if that crosses the line for you, then I think your line is weirdly placed
I'm not aware of anything I've said in support of Luke Dashjr
> Why would it be ridiculous?
Because in a system like the mempool, if a relatively small difference was actually bad, then a relatively large difference should be worse. But in reality, the largest possible difference between mempools is for one person to have a really big one and for another person not to have one at all. And even in that extreme case, feerate estimates are barely affected. (See below.) Since the largest possible difference has very little affect, it is absurd to monger fear about a much smaller difference (i.e. the difference between a Core mempool and a Knots mempool).
> "barely affected" seems vague
Let me try to make this claim more specific. Feerate estimates are exceptionally variable, and, in nodes which *have* a mempool, it changes subtly based on the order in which unconfirmed transactions appear to your node, which is not enforced by any policy. Therefore, even when two nodes have the same mempool policy, I don't expect them to have matching estimates except when fees are minimal (i.e. when it gets "stuck" at 1).
As a result, I am unwilling to say "blocksonly mode makes no difference at all," as anyone might then try to make me look foolish by displaying a side by side comparison and saying "look, there's technically a slight difference," amd you denied *any* difference.
But I can still be more specific by saying the following. I *would* look foolish if the following supposition is wrong: the variance between a blocksonly node's feerate estimates and a Core v30 node's feerate estimates are probably within 1 standard deviation of the "natural" variance between two nodes that have an identical mempool policy.
The idea that feerate estimates are materially downgraded when a node lacks a few dozen spam transactions seems completely ridiculous when you realize that they are barely affected when you don't have a mempool at all
maybe but I think that would probably require the server to make its api endpoints queriable over nostr, similar to how DVMs work
SNAP just became an essential service: https://apnews.com/article/snap-shutdown-lawsuits-deadline-4af8b0dec6cd31cddd023cc99c131b73
On a long enough time horizon, all government services will be deemed essential, and shutdowns won't actually shut anything down. I give other examples in this post:
That would help make it more private but also less accessible
I like having a qr code that an ordinary mobile device can scan with their regular camera, and boom, there's instantly money inside
It means there is less need for instructions like "Make sure you download the Tor browser first and then open the link in there"
I think a possibly-better solution is to wrap all queries to the api endpoints via a proxy such as corsproxy.io -- that would hide each user's ip address from the endpoint, but (1) it would put further strain on the infrastructure of that public service, which will surely stop working at some point (2) you've really just shifted the privacy problem to corsproxy.io -- now *the proxy* knows all the data I'm trying to conceal from the endpoint
BRB, rebuilding Hedgehog on top of Ark
https://github.com/supertestnet/arkash
https://video.nostr.build/172f560b89ca608a69e3ce177c735a330406371066e2dc79406200521c5e3fce.mp4
I think so. Here is the relevant code snippet: https://github.com/bitcoinknots/bitcoin/blob/eeb9cc1120661d0e9fd28ddb6fef2c04992a4666/src/script/script.cpp#L329
It is a function called DatacarrierBytes and I don't know c++ all that well but it appears to match transactions containing OP_FALSE OP_IF or OP_RETURN, and counts the number of bytes they carry as a payload. I assume this function gets called wherever the data arrives filter is applied, which I suppose is probably in policy.cpp -- though I haven't checked
> If I'm not mistaken, BIP444 proposes having a council or group of people making decisions on what is "troublesome content".
I didn't see anything explicitly about a council. If the "group" is defined as the set of miners, then I think it would be wrong to assert that this proposal "gives" them power to make decisions on what is troublesome content.
On a related note, I think miners already have that power, implicitly, because they have a veto on what counts as valid in bitcoin. Specifically, even if all the non-mining bitcoin nodes consider some type of transaction valid, the set of miners can refuse to mine transactions of that type, thus effectively overriding the will of all other nodes.
I think it would probably be unwise to ask them to formalize this power in some sort of coordination software and then begin using that software to manually "vote" on what counts as troublesome content. (Again, i do not think bip444 proposes this.) A group with that kind of power in bitcoin sounds like a bad idea to me, and although I think miners technically have that power already, it is not, to my knowledge, formalized in any sort of coordination/voting software. If such software gets written and widely deployed among miners, I think bitcoin would be in greater danger than it currently is of becoming "ruled by committee."
Once more, I do not think bip444 proposes any such thing.
> And is the method of invalidating transactions to invalidate the entire block?
The proposed method is for miners to refuse to mine on top of any block containing a troublesome image. They would instead mine a replacement block without that image in it.
> what about all the other transactions in that block, what happens to them?
They go back into the mempool, to be mined in future blocks (presumably the very next one), except transactions such match the tx types identified in the bip, in which case those transactions would become invalid once this bip activates, either by the "emergency method" (which involves rolling back one block, and which sounds like a bad idea to me) or by the "flag day" method (which sounds like a decent idea to me).
> Changing policy rules is an unworkable solution
It works well at its primary job, which is filtering my own personal mempool
> Mempool policy is a crutch
It objectively reduces the negative impact of spam on my node
> It will not stand the test of time because it can be easily circumvented, as...Libre Relay [shows]
LibreRelay does not undermine the filters' ability to do their primary job well, which is to filter my own mempool and thus reduce the negative impact of spam on my node
> I think you should put your considerable talents to work turning the coinbase into an on-chain privacy tool
I already built that, I just don't care to market it
It applies it to inscription envelopes specifically, by testing for the existence of the bytes for "OP_FALSE OP_IF" in the witness
I have looked at bip444 and I think it is a good idea to temporarily invalidate the transaction types it identifies
I do not think it's "emergency deployment" mechanism is wise, though it does sound fun
> Aren't you also against inscriptions?
Yes
> Shouldn't knots also filter inscriptions?
Yes
> Maybe it does that already, I don't know
It filters inscriptions that are larger than 83 bytes
I would prefer it to filter all of them, but filtering the big ones is a decent start
That said, my motivations include both self-interest and interest in others. If you want to see what outcome would ensue if I changed my motivations (e.g. "what if you were only interested in yourself") you could prompt the pro-spam position much more efficiently by asking about more directly pro-spam motivations -- e.g. "what if you were interested in seeing more spam on the network." If you tune the motivations properly, you can get any response you like.
For purely selfish reasons, 1MB of jpegs in op_returns are worse than 1MB of jpegs in inscriptions, because op_returns take up more base space, which is the more expensive part of blockspace. My transactions must use some base space, as a transaction that *only* uses the less-expensive witness space would be invalid.
As a result, I prefer *less* of that base space to be consumed by jpegs, so that I can use that space; and therefore, even if I had purely selfish motives, I would consider it worse for 1MB of jpegs to be embedded in op_returns instead of inscriptions.
Humans wrote bitcoin. The only objective things a bitcoin node knows are what its devs and users tell it.
A Core node doesn't know what a valid tx is, except it does because a human told it via the consensus rules
A Knots node doesn't know what a spam tx is, except it does because a human told it via the mempool policy
I don't know what calculations you are referring to. The tool tracks usage of bandwidth. In the context of the mempool, standard transactions consume bandwidth when downloaded and when relayed. Filtered transactions only consume bandwidth when downloaded -- they are not relayed. Therefore, filtered transactions objectively consume less bandwidth. And, as some of the most common spam formats are among the transaction types filtered by Knots, a Knots mempool objectively uses less bandwidth on spam-relay than a Core mempool. That is what my tool highlights, and to do so, it uses specific examples from recent blocks.