reply on: After the Core/Knots Hard Fork... Which version will you run and why? \ stacker news ~bitcoin

pull down to refresh

57 sats \ 22 replies \ @k00b 3 Sep \ on: After the Core/Knots Hard Fork... Which version will you run and why? bitcoin

We can reduce OP_RETURN limits in a soft fork afaik. Maybe we can get near universal support for a covenant soft fork if we reduce OP_RETURN this way.

36 sats \ 13 replies \ @028559d218 OP 3 Sep

So offer a deal? Soft-fork in covenants to soft-fork out larger op-returns? This is beyond my technical understanding.

150 sats \ 1 reply \ @siggy47 3 Sep

I wouldn't hold out much hope for a deal. It's an adolescent food fight at this point.

36 sats \ 0 replies \ @billytheked 3 Sep

best take

100 sats \ 10 replies \ @justin_shocknet 3 Sep

Covenants are instant ethereumification.

If Knots people weren't retarded they'd focus on fighting that.

0 sats \ 9 replies \ @SatosphereJunction 3 Sep

You'll change your tune once the chain starts getting spamed with CSAM. There are plenty of people that will do it just because they don't like Bitcoin.

0 sats \ 8 replies \ @justin_shocknet 3 Sep

If team Knots want to get serious then they should focus on technical merit, being wrong about prunable outputs just shifted the goalpost down this track which is a losers bet. Arbitrary data has always found a way, Knots is powerless to prevent that. Larping about filters in mempools show Knots users ignorance, they don't even know the purpose of the mempool or why they run one at all.

It's sad because I really want to support alternatives to Core, afaik Mechanic and Luke are on CTV just like the rest of them... maybe this is all kayfabe so people sleepwalk past etheriumification.

0 sats \ 1 reply \ @028559d218 OP 3 Sep

That's why there is going to be a consensus split. What filters/knots advocates are advocating for (no chance of csam on their node period) isn't compatible with Core 30.

Even a small number of Core 30 nodes 'in the wild' means that something/possibly anything could get through into blocks that is reprehensible. Which means knots users have to store that data indefinitely.

Unless knots users decide to run pruned/non-relay nodes (in which case bitcoin dies if everyone does that) OR there is a consensus change to permanently fix the "spam" issue so that knots users can run a full node again and not have to worry about csam again at least in op_return.

In which case there's a consensus split/consensus change with 2 different tokens, 2 different networks which is where we're headed in my opinion.

Bitcoin Core and Bitcoin Knots (Bitcoin Pure?) similar to Bitcoin and Bitcoin Cash in 2017.

0 sats \ 0 replies \ @justin_shocknet 3 Sep

There's so much lack of technical understanding here I don't even know where to begin. Unfortunately par for the course with Knots supporters, whom I otherwise align with sentimentally.

I'll just leave this from another comment in the thread.

Miners could censor arbitrary data today without a fork, but they aren't, hense a fork won't stick.

0 sats \ 5 replies \ @SatosphereJunction 3 Sep

OP_RETURN isn’t a knob you can twist like stereo volume. It’s baked into the protocol at a fundamental level. Changing it would be like replacing the dot on an ‘i’ with a triangle. Small on the surface, but breaking the rules of the language itself.

0 sats \ 4 replies \ @justin_shocknet 3 Sep

Yea and it's not going anywhere, it exists and has for ages, and it only exists because it's less bad than workarounds spammers have come up with.

Miners could censor arbitrary data today without a fork, but they aren't, hense a fork won't stick.

If you want to minimize further damage start fighting the next battle, not the lost one.

0 sats \ 3 replies \ @SatosphereJunction 3 Sep

Then why make the change v30 is proposing? Seems that it isn't necessary. so round and round we go.

0 sats \ 2 replies \ @justin_shocknet 3 Sep

Core makes a lot of useless and potentially hostile changes, they do every version... I'm already anti-Core.

The bar for Knots to be better is not that high yet you're still failing to clear it.

view all 2 replies

0 sats \ 7 replies \ @Filiprogrammer 3 Sep

We can reduce OP_RETURN limits in a soft fork afaik.

This would cause a hard fork.

0 sats \ 6 replies \ @k00b 3 Sep

Explain why please.

222 sats \ 1 reply \ @Murch 3 Sep

Limiting OP_RETURN size would be a soft fork.

100 sats \ 0 replies \ @optimism 3 Sep

Luke can also just make it a true chaintip fork, though. There's a nice integration point right here.

Bonus: if you do it without height threshold while implementing Luke's full definition of datacarrier as was recently explained here, you can even fork off those biblical texts someone put on the chain!

100 sats \ 1 reply \ @k00b 3 Sep

My understanding is that restrictions, a narrowing of something in consensus, can usually be implemented as a soft fork. But I'm now wondering if that just applies to opcodes.

100 sats \ 0 replies \ @optimism 3 Sep

You can do it if it's miner enforced. Is Ocean going to enforce it with 10-15EH?

0 sats \ 1 reply \ @Filiprogrammer 4 Sep

A block mined on the current consensus might not get accepted by nodes with the new OP_RETURN limit, thus causing a chain split. All miners would have to also implement that limit.

0 sats \ 0 replies \ @028559d218 OP 5 Sep

I think that's what I was alluding to... that a Knots fork (consensus change) limiting op_return would probably cause a chain split and a different blockchain/token.

It's the only way to be sure and 'get rid of' the spam.