Nostr Web Client

Dec '23?

ive been running Core with pull request 28408 (match more datacarrying) for well over a year. before the discussion for the PR was closed, at taiwan bitdevs we applied this patch together as a way to show our attendees how datacarrier works (or more like why it was broken). some users even continue to use that version of Core in their nodes, even applying the patch up through v28/29.

the users understand how arbitrary data still show up on blocks and still go through the process om their own. the patch itself works just fine, i dont see why datacarrier should be removed if it is working properly.

i followed the recent mailing list discussion and i dont have any strong opinions on the implementations that choose to bypass existing restrictions. doesnt matter that much to me, but the PR you submitted removes a functionality node operators use and im a bit lost as to why.

i dont buy that removing restrictions will reduce utxo bloat, intuitively it makes me think the situation would be made worse

i dont have a random fancy whitepaper to kick off discussion like the ML, i can only ask whats wrong with fixing it ?

on a positive note, at least theres acknowledgement that datacarrier is dysfunctional. best of luck with your endeavors to remove it, id even prefer that result compared to doing absolutely nothing.

Reply to this note

Please Login to reply.

Discussion

sedited 8mo ago

The problem with the patch from the perspective of disallowing data embedding is that for it to be effective an overwhelming majority of nodes would have to upgrade to this patch. In the time where most nodes are not upgraded yet, the network will perform in a degraded manner, but data carrying transactions will still be relayed. If most nodes eventually upgrade, it is easy for the spammer to come up with a new script variation that is not covered by the current filter, which starts the entire game again. At the moment nodes upgrade very slowly. It usually takes years before a big majority of nodes upgrade to the newest version. You could argue that this is fine, and people will just be encouraged to update faster, but then you enter dangerous "auto-updating" teritory, which is against the core tenets of our project.

Nyoro~n 8mo ago

what do you mean by 'degraded manner' for the network as a whole?

other than a lower availability of these spam transactions in any given set of nodes' mempool, it makes little no difference for a node that is enforcing existing policy which is the network at large. it would only be degraded for the participants that want higher availability of arbitrary data prior to the spam transaction getting mined which is even a smaller set of people than the people who actibely upgrade software and/or apply patches.

the argument i see being made is that fee estimation could be messed up, but the thing is that fees are up to the node. their ability to calculate fees on their own criterion of what to bid against is none of anyone's business and certainly doesnt degrade the rest of the network. the node knows whats best, assumptions on what a miner "might" include in blocks dont need to (and shouldn't) be forced upon them.

sedited 8mo ago

Not having transactions in the mempool that are being mined into a block degrades compact block resolution. This leads to slower block relay and a quadratic increase in p2p traffic. If you don't accept data carrying transactions that your peers send to you, you create a negative externality for them if they are mined, because they need to relay them to you again.

Nyoro~n 8mo ago

arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?

when a peer is relaying a bunch of spam to my node, my node basically treats that peer like a block relay. not my business that he sends those txs to me multiple times and not his business i refuse to forward along transactions. in the event where multiple chaintips appear, I'd prefer to relay that the block with more of the transactions ive already validated in memory over the one where theres transactions my node hasnt validated

sedited 8mo ago

> arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?

I don't understand why you are saying this works. Clearly transactions are finding their way to miners over the regular p2p network. For what it's worth I also don't understand why this change is sold as company x needs this to post the data as op_returns. They should just do it now, because enough nodes and miners have these liberal policies already. Bitcoin Core should still adopt the relaxed policy to make relay smooth, and make it easier to use, because it reduces harm in terms of node storage requirements, but keep the option, so node runners like yourself can encourage building templates with non-data carrying transactions.

Nyoro~n 8mo ago

apologies, my nostr-edit appears not not have made it to you: "arent nodes running filters to impede this propagation as a way to marginally discourage behavior relaying *blocks with* transactions not accepted by the wider network"

i think you mistake the occasional stunt by miners to throw random junk they choose to include in blocks as a failure of mempool policy. it'd be as absurd as to pointing to an empty block and blame it on mempool policy too

sedited 8mo ago

Thanks for reposting :)

My nostr client is really messing the rendering of this thread up right now. Maybe it's good to stop a discussion at some depth ^^.

My impression is the recent large OP_RETURNs are not a miner stunt. A stunt for sure given their content, but my impression is they get through by relay.

Nyoro~n 8mo ago

🤔, so which is it? you can have whatever impression you want but this works in a certain way.

are these larger OP_Return transactions successfully relayed through the network because a sufficient amount of nodes actively configured their node to do so (because Core or Knots wont do it out of the box save for Libre Relay and some very old versions) or are these transactions resorting to services like slipstream because the wider network wont relay them?

because if you're saying these transactions get through by a small subset of configured nodes relaying to one another, consider to extending that conclusion to nodes choosing to configure in another direction too 😅 and if you're saying these transactions had to be sent to the miner directly because the wider p2p network wont relay them, well...seems like you understand that filters work and that it costs something to get around them 🤷

sedited 8mo ago

Mmh, I think it is clear that if ~all nodes use the same policy a transaction has a tough time of getting through. Surely there is also a cost for getting around them too. But I think we've reached the point here where that cost is low, and the cost incurred by not adapting is bigger.

I also think it should be left configurable at least . Miners should get the choice of not having to include these transactions, meaning Bitcoin Core should allow excluding them from template generation. Similarly nodes relaying transactions to these miners should be able to exclude them to able to relay lower fee transactions that might get evicted otherwise if the mempool is full already.