pull down to refresh

Let’s say someone is selling cp for BTC will you make your node refuse to validate a block paying them? Will you filter that transaction from your mempool? Why stop at just keeping jpgs of cp off the chain?
150 sats \ 8 replies \ @optimism 21h
Just run blocksonly, don't allow blockfilters and don't use LN. Problem solved.
reply
110 sats \ 7 replies \ @BITC0IN 18h
I'd rather continue to speak-relay-gossip known monetary only transactions, while not speaking-relaying-gossiping known arbitrary data blobs.
I also can't broadcast a transaction from my node with blocksonly=1
That feature needs to be turned off if you want to send Bitcoin.
reply
102 sats \ 6 replies \ @optimism 18h
Fine. The neat thing is you can do whatever you want and so can I. And if I don't like your node I can just not connect to your node and you can do to my node the same.
Easy, right? Problem solved again.
reply
110 sats \ 5 replies \ @BITC0IN 16h
I mean that depends. part of the problem is peoples ignorance surrounding this issue.
disclosure seems prudent to me.
fyi: despite that blocksonly code you reference being in place, it does not functionally work when I tested sending bitcoin in the field with my own node. there may be other factors at work though, i did not test this extensively.
another draw back of being blocksonly=1 is that my peers (i'd say most) start to disconnect from me, since they think I'm a bad peer.
reply
166 sats \ 4 replies \ @optimism 15h
it does not functionally work when I tested sending bitcoin in the field with my own node
I remember it used to be like that - with 0.12 or so - but it should be fixed now. iirc the main issue is that since smartfees tracks the number of blocks it took for a tx to be mined since we saw it, there is no good fee estimation (though this could be fixed.)
I run a blocksonly node to serve history for others' IBD over tor, but I've compiled it w/o wallet so I cannot test it quickly right now (and I don't really like testing on mainnet anyway). I'll build and run some reproducible tests tomorrow, because it should work (as permissioned txs should be forwarded as well, so I'll test that too) - and if not, I think that it's patch-worthy - I'd gladly work on a fix if this was regressed (and with it supply a test with higher coverage.)
my peers (i'd say most) start to disconnect from me
There are 2 blocks-only slots and 8 non-blocks-only outgoing connection slots per node, so you'll serve a smaller subset of total connections, yes, and it'll take longer to serve many incoming peers.
reply
100 sats \ 3 replies \ @BITC0IN 15h
iirc I only had one consistent peer when being blocksonly=1 when trying to sync to the chaintip. once at the chaintip I think i got more peers, but still very few.
Thanks for looking into this, me and the one other user in the world who used this feature appreciate it.
oh also, there's some edge cases with lightning nodes who switch blocksonly=1 on too. terrible cases of channel opens being stuck in some instances (just me lol) that required LND updates to flush out.
also,
put me in the release notes! ;D
reply
21 sats \ 2 replies \ @optimism 15h
there's some edge cases with lightning nodes
If LND now supports blocksonly then that's an awesome improvement that I didn't know worked. I remember needing a mempool for it to work in the past.
put me in the release notes! ;D
lol!
reply
100 sats \ 1 reply \ @BITC0IN 14h
If LND now supports blocksonly then that's an awesome improvement that I didn't know worked. I remember needing a mempool for it to work in the past.
no I don't think it does work, which is what I found out the hard way with some stuck channel opens.
Might be worth it for LND to disable that argument actually, now that I think about. it's a foot gun that I used well to clean the toes of my node.
go make a PR and claim credit!
It's an important question. I'd like to see people engage with it in good faith.
From what I'm hearing, the pro-filtering argument is for allowing node runners to not store images, or other objectionable material, in their mempools. I'm fine with that. Arguments against choice have to meet a high bar for me to accept them and these technocratic arguments haven't risen to that level for me.
The argument for stopping at this point is that there would be no faster way to turn the public against bitcoin than by being able to say, accurately, that we're all willingly transmitting child pornography to each other.
If engaging in that transmission is optional, then culpability can be put on the particular node runners who are storing it, rather than the whole community/project/movement.
reply
21 sats \ 0 replies \ @Akg10s3 21h
Thanks for your reply!! For me, it was like a translation of what's in the header or beginning of the post!!
reply