Nope.
Well sorta.
The filters on OP_RETURN on Knots allow you to boot datacarrier out of your mempool if they don't pay enough per byte, with a multiplier that you set individually, which is really cool. This is obviously bypassed by other nodes and connections most of the time, almost all of the time if you don't have like a critical mass of nodes running a similar policy, but still to have a slight probabilistic effect on the price of OP_RETURN data is powerful. Bypassing it can be done by an attacker by spinning up a bunch of nodes, but Bitcoiners can try to specify certain rulesets that they prefer to connect to or specific individual nodes they like. That might be a solution but might lead to censorship if heavily relied upon. Idk, that might be a separate issue.
So instead, I would like to see a way wherein the pricing you set for a transaction based upon your filters, also sets a rank order attribute for the transaction to help determine how many blocks out this transaction should be, and perhaps this rank order gets communicated to other nodes which then average it with their own policy or use some kind of logistic real time update function like a chess ranking. This "chess ranking" can be a rough indicator of the consensus price that should apply to any one transaction. The issue with this in a naïve implementation may be censorship via lots of CPUs run by a single actor overwhelming the network with punishing rankings on stuff the government doesn't like or whatever. But the individual noderunner can still set his transaction ranking to 0 (highest priority) and communicate that to the nodes around him, which drastically reduces their rankings for him at least.
I think this design sucks unless we can use it as a basis to build a censorship resistant version of it. If course, many individual node runners can still counteract any punishing rankings by setting their policies to be more liberal. So perhaps this would be a way to give more fine-grained feedback of user preferences to miners.
Kevin's Bacon
npub18h…d8059
2025-05-11 15:11:18
in reply to nevent1q…dhsn
Author Public Key
npub18hdy2qy2qwga0ye7rtnucwuyf07erjfdmm7s74wwdt7sy4mk7tdsdd8059Published at
2025-05-11 15:11:18Event JSON
{
"id": "6e431957e34ad40a23f185d67591cb2c3936ee0229ff1db0f06c4cfe1745b6e2",
"pubkey": "3dda45008a0391d7933e1ae7cc3b844bfd91c92ddefd0f55ce6afd025776f2db",
"created_at": 1746976278,
"kind": 1,
"tags": [
[
"e",
"81ca09394c82a99dd5d974d9d2c0702f59dc7fc18e99db75f28a9aaa9fb15410",
"",
"root"
],
[
"e",
"496fdd02b5480d943efe2481c445739c62efedb624dd71a3c324d23b372af6f6",
"",
"reply"
],
[
"p",
"3dda45008a0391d7933e1ae7cc3b844bfd91c92ddefd0f55ce6afd025776f2db"
],
[
"p",
"8633073b8567da97ad119fedd9716154aa283234cbb7d28d5131daa077d1cf7a"
]
],
"content": "Nope.\n\nWell sorta.\n\nThe filters on OP_RETURN on Knots allow you to boot datacarrier out of your mempool if they don't pay enough per byte, with a multiplier that you set individually, which is really cool. This is obviously bypassed by other nodes and connections most of the time, almost all of the time if you don't have like a critical mass of nodes running a similar policy, but still to have a slight probabilistic effect on the price of OP_RETURN data is powerful. Bypassing it can be done by an attacker by spinning up a bunch of nodes, but Bitcoiners can try to specify certain rulesets that they prefer to connect to or specific individual nodes they like. That might be a solution but might lead to censorship if heavily relied upon. Idk, that might be a separate issue.\n\nSo instead, I would like to see a way wherein the pricing you set for a transaction based upon your filters, also sets a rank order attribute for the transaction to help determine how many blocks out this transaction should be, and perhaps this rank order gets communicated to other nodes which then average it with their own policy or use some kind of logistic real time update function like a chess ranking. This \"chess ranking\" can be a rough indicator of the consensus price that should apply to any one transaction. The issue with this in a naïve implementation may be censorship via lots of CPUs run by a single actor overwhelming the network with punishing rankings on stuff the government doesn't like or whatever. But the individual noderunner can still set his transaction ranking to 0 (highest priority) and communicate that to the nodes around him, which drastically reduces their rankings for him at least.\n\nI think this design sucks unless we can use it as a basis to build a censorship resistant version of it. If course, many individual node runners can still counteract any punishing rankings by setting their policies to be more liberal. So perhaps this would be a way to give more fine-grained feedback of user preferences to miners.",
"sig": "af2f0faab9c9edee7ca8b51794270f8fee689df80abff463f35f54f58063a585dfbbcbeb42bf9a570519fde58ac8b4450854fea341169de482ca2fb0c8f58c55"
}