pull down to refresh

After the Core/Knots Hard Fork... Which version will you run and why?
1344 sats \ 77 comments \ @028559d218 18h bitcoin
Since arbitrary data will arguably be easier to embed in transactions (although it's clearly possible now) under Core v30... it's also possible that some amount of abusive material/illegal data will wind up on the Bitcoin blockchain.
In which case 'running knots' with its current consensus rules, identical to bitcoin core's, will still store and relay that data once it is mined into blocks. ONE document (for example containing classified data) or illegal JPEG for example mined under V30 and all knots and core nodes will store it regardless of mempool policy indefinitely.
Therefore the only way to 'purify' the chain if V30 occurs even with a small amount of adoption, is through a Hard Fork, most likely originating with Bitcoin Knots.
Which is why I believe we will see an arbitrary-data hard fork in the next year, probably resulting in 2 separate chains Bitcoin Core and Bitcoin Knots with different consensus rules.
So which one will you run?
Bitcoin Core as it stands now20.0%
Bitcoin Core but *most likely* V3017.8%
Bitcoin Knots with *current* consensus8.9%
Bitcoin Knots with anti-spam consensus31.1%
Not sure22.2%
45 votes \ 6h left
write
preview
related posts
409 sats \ 37 replies \ @justin_shocknet 16h
There won't be a hard fork, the whole debate has gotten very moronic.
Core should be deprecated and implementation forks should be the norm, but Knots incoherence is doing more harm than good towards that end. #1204434
The people most vocal about running Knots don't even seem to understand remedial Bitcoin, terrible optics.
reply
0 sats \ 7 replies \ @fourrules 13h
What do people most vocal about running Knots not understand about Bitcoin? Blanket vague unsubstantiated statements like that create more knots node, because you will cast aspersions and then ignore the qualified responses.
reply
38 sats \ 3 replies \ @028559d218 OP 13h
A lot of things. Knots runners generally believe that if 51% of the network 'runs knots' then they win. Like it's a simple majority vote.
What they win i'm not sure they can articulate... maybe an end to spam or a return to 'monetary bitcoin' (this is how influencers explain it).
By that logic a government/business could spin up tons of nodes with different rules/different mempool policies and filter transactions that way... but of course it doesn't work that way.
Knots users also think that knots has different rules or consensus rules it abides by... which isn't true.
They also think that their knots nodes store different things in blocks than core nodes do (after they're mined) which is not true so 'run Knots to save bitcoin' seems poorly articulated/understood.
Eventually knots people figure out that their nodes will permanently store v30 transactions but they don't realize this yet.
Knots users also generally believe (i've seen this articulated) that the only way today to get a jpeg on-chain is by going to a miner which is not true.
reply
10 sats \ 2 replies \ @fourrules 13h
Knots runners generally believe that if 51% of the network 'runs knots' then they win. Like it's a simple majority vote.
No they don't, but the more people running knots the more likely it is that miners adding jpegs to blocks will get orphaned, increasing the risk of loss of income, which they way against the transaction fees that they can get. I don't know anyone who thinks 51% is a significant number. So basically you don't know remedial things about knots advocates position.
He who knows only his own side knows little of that.
Edit: knots users also think that that knots has different rules or consensus rules.
Citation needed. OP_Return limit is a policy or Bitcoin Core, the node implementation most nodes have been running since Satoshi.
They also think that their knots nodes store different things in blocks than core nodes do (after they're mined) which is not true.
No, again. Wow, if this is the calibre of person on the Core side I really do suspect that bitcoin is being attacked by the 50 cent army.
This is a much less intelligent response than I was expecting.
reply
100 sats \ 1 reply \ @028559d218 OP 13h
with all due respect these are the overwhelming positions/views/takes from knots advocates i have seen in kratter's videos (that i linked to) and in many, many others.
They may not be your position... but they are a very common position/articulated understanding from knots advocates. Just read the video comments.
As far as the orphan block thing i mean maybe it's true but i'm skeptical. My understanding of the argument is that compact relay is slower for miners mining spam that fewer nodes include... so they're at a disadvantage.
I have also read that larger miners, in such an instance, will be better connected to the network and have a material advantage relative to smaller miners that depend on compact block relay.
Plus smaller miners win blocks less often... so are more vulnerable to orphan blocks anyway as compared to foundry for example that can mine their own blocks consecutively.
Smaller miners with custom templates are more vulnerable than larger ones... increasing centralization risk which is what we don't want. I think the jury is still out on this stuff either way without more data.
Citation needed. OP_Return limit is a policy or Bitcoin Core, the node implementation most nodes have been running since Satoshi.
Not true? op_return is technically consensus the size of op_return is relay policy. Op_return of 100kb is consensus valid and has been for years fwiu that's why it's possible in blocks today just not common because it's really expensive and relay policy is standard 80 bytes.
reply
0 sats \ 0 replies \ @fourrules 12h
You're using YouTube comments as a reasonable sample set? I bet it was only a subset of stupid comments, but idiots are always overrepresented in YouTube comments.
they are a very common position/articulated understanding from knots advocates
Maybe I just ignore stupid comments more than you but I don't think picking the dumbest people on one side of any argument is a wise approach.
About orphaned blocks, you're getting into very much not remedial territory, and I'm not qualified to comment. But it's certainly something reasonable and intelligent and informed people can investigate whether without resorting to ad hominems and staking their relations on conclusions in advance.
the size of op_return is relay policy That's what I said. What was not true?
reply
10 sats \ 2 replies \ @justin_shocknet 13h
Start by telling me why you, personally, run a mempool?
reply
10 sats \ 1 reply \ @fourrules 13h
That's not the start of an answer to the question of what people most vocal about running Knots don't understand about Bitcoin. It's simply a means of casting aspersions, exactly what I said you'd do. Next when I respond and it gets too dicey for you you'll ignore the qualified responses and engage in ad hominem attacks or gaslighting.
Why don't you just explain the remedial things that knots advocates don't understand, win me over as a non-aligned node runner. It's remedial bitcoin so it should be easy to explain in a paragraph.
reply
0 sats \ 0 replies \ @justin_shocknet 13h
Knots users don't understand why they run a mempool or relay in the first place, or why op_return exists.
Since you dodged a very simple question you seem to agree.
reply
0 sats \ 28 replies \ @SatosphereJunction 14h
This is a protocol fight not an implementation fight. If the protocol allows an implementation to include CSAM then the whole protocol will fail. Wait till miners get sued for distribution of CSAM and node runners get prosecuted for storing it.
reply
200 sats \ 24 replies \ @justin_shocknet 14h
Goalpost shift, started with relay filters. Knots is losing on technical merit every time I poke my head in... and I'm reluctant to say that because I'm no fan of Core as noted.
I honestly couldn't tell you the latest Knots position because it's changed so many times. It's probably changed again since I've started writing this response.
reply
0 sats \ 23 replies \ @fourrules 13h
Relay filters are to avoid relaying undesirable content. Not all content that a node runner may want to filter out is illegal, it might be a matter of preference. Or it might be a matter of principle filtering out anything over a certain size to ensure that bitcoin is held to a higher monetary standard. But that content may also be illegal and knots node runners and advocates are legitimately getting concerned that their concerns are not getting addressed with a reasonable amount of care and consideration.
reply
0 sats \ 22 replies \ @justin_shocknet 13h
I agree that node runners should absolutely be able to apply preferences to their relay policies. I have no issue with the position that Core should not remove user preference settings.
That is however NOT the totality of Knots position nor what they are losing on.
reply
17 sats \ 17 replies \ @028559d218 OP 13h
Keep in mind that knots users cannot accept 'co-existence' with core because in that case the spam transactions keep getting through.
It's either dominate (to over 90% required to effect the relay network iiuc) OR fork to change the rules/create a separate network those are the choices fast approaching for knots.
reply
100 sats \ 14 replies \ @justin_shocknet 13h
Indeed, they've narrative trapped themselves. Completely out-kicked their coverage, painted into a corner, wrong hill to die on... choose your metaphor.
It'll be a tragedy to see the anti-Core momentum get lost if they continue on this path.
reply
0 sats \ 13 replies \ @fourrules 13h
So how much CP will you allow on your machine? Is a few JPEGs an ok amount of CSAM for you?
view all 13 replies
10 sats \ 1 reply \ @SatosphereJunction 13h
Fast approaching for core you mean. They are the ones that decided on this course of action. I didnt care until they made an issue of it.
reply
0 sats \ 0 replies \ @028559d218 OP 13h
current core users, for better or worse, could take the rip van winkle test and go to sleep for 5 years, probably let their node just run...
and when they woke up it would still be consensus valid. because 100kb op_returns for better or worse are consensus valid. So nothing has fundamentally changed.
(not saying you shouldn't update node software... you should but consensus hasn't changed that's my point)
Knots users, and i'm not judging them in any way, are being put in a position to store whatever on their nodes, depend on the goodness of random people, or fork and change the rules so they know they won't object to what's getting into blocks.
Those are their current options.
reply on another page
0 sats \ 3 replies \ @fourrules 13h
If it's not the totality then maybe what you're experiencing as a move of the goalpost is just a bigger goalpost than you can see with your tunnel vision.
reply
0 sats \ 2 replies \ @justin_shocknet 13h
You can't even explain why you run a mempool, with hysterical hyperbolic responses like yours you can't blame anyone but yourself for not understanding your position.
reply
0 sats \ 1 reply \ @fourrules 13h
I didn't say why I run a memepool because it is none of your business and has nothing to do with the debate, it was just a rhetorical tactic to avoid answering the simple question I asked you, to qualify what you said in your first comment.
You eventually did and the answer was woeful.
view all 1 replies
117 sats \ 0 replies \ @nout 10h
There is no way to prevent CSAM being included in the data using one of many possible ways (e.g. in witness, which is what ordinals use). It's already most likely included in existing chain.
Why is this a protocol fight? HTTP, SMTP, FTP all include CSAM (by some definition of "include").
reply
0 sats \ 1 reply \ @028559d218 OP 13h
This is exactly my point. This goes way deeper than relay policies... that's why knots will fork eventually when they figure out what their options are.
reply
0 sats \ 0 replies \ @fourrules 13h
deleted by author
57 sats \ 21 replies \ @k00b 18h
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.
reply
36 sats \ 13 replies \ @028559d218 OP 18h
So offer a deal? Soft-fork in covenants to soft-fork out larger op-returns? This is beyond my technical understanding.
reply
150 sats \ 1 reply \ @siggy47 17h
I wouldn't hold out much hope for a deal. It's an adolescent food fight at this point.
reply
36 sats \ 0 replies \ @billytheked 10h
best take
reply
100 sats \ 10 replies \ @justin_shocknet 16h
Covenants are instant ethereumification.
If Knots people weren't retarded they'd focus on fighting that.
reply
0 sats \ 9 replies \ @SatosphereJunction 14h
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.
reply
0 sats \ 8 replies \ @justin_shocknet 14h
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.
reply
0 sats \ 5 replies \ @SatosphereJunction 14h
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.
reply
0 sats \ 4 replies \ @justin_shocknet 13h
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.
reply
0 sats \ 3 replies \ @SatosphereJunction 13h
Then why make the change v30 is proposing? Seems that it isn't necessary. so round and round we go.
view all 3 replies
0 sats \ 1 reply \ @028559d218 OP 13h
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.
reply
0 sats \ 0 replies \ @justin_shocknet 13h
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.
reply
0 sats \ 6 replies \ @Filiprogrammer 14h
We can reduce OP_RETURN limits in a soft fork afaik.
This would cause a hard fork.
reply
0 sats \ 5 replies \ @k00b 12h
Explain why please.
reply
222 sats \ 1 reply \ @Murch 11h
Limiting OP_RETURN size would be a soft fork.
reply
100 sats \ 0 replies \ @optimism 11h
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!
reply
100 sats \ 1 reply \ @k00b 11h
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.
reply
100 sats \ 0 replies \ @optimism 11h
You can do it if it's miner enforced. Is Ocean going to enforce it with 10-15EH?
reply
0 sats \ 0 replies \ @Filiprogrammer 1h
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.
reply
311 sats \ 4 replies \ @SwapMarket 15h
Just run core v30 with datacarriersize=80 in bitcoin.conf. All they change is the default value.
reply
0 sats \ 3 replies \ @028559d218 OP 13h
This doesn't work.
Even a relatively small number of V30 nodes 'on the network' at default settings... and it's possible 'objectionable content' will make it into blocks.
Once one 'objectionable picture' gets in a block it is stored on all core and knots full nodes forever, because a 100kb file is consensus valid. Even having datacarriersize=0 doesn't change that... it stays on the computer forever as long as the computer doesn't prune/remains archival and consensus remains the same.
I don't buy the argument that mechanic has made that governments only care (provided they do care) about mempool policy. "Governments don't care about blocks on a hard drive" etc etc... I think that's ridiculous.
"Ladies and gentlemen of the jury the accused had pictures on a harddrive that's OK... but they had them in their mempool that's NOT OK!!!"
Right... that's not how government works they will never make that distinction should they target people for simply running a bitcoin node.
So if knots runners follow through on this logic "more copies" of knots isn't the answer in fact it's more copies of the data they find objectionable.
It's a consensus change they need... to protect the peer-to-peer nature of Bitcoin while being able to "legally" run a full node and that is incompatible with core v30.
So a chain split will happen it's not if it's when.
2 separate tokens 2 separate networks it's all over except for signing the documents
reply
21 sats \ 1 reply \ @SwapMarket 13h
Ok, maybe. So I will run my nodes illegally. I think a bigger danger is the whole "money transmitter license" theme which is not over.
reply
10 sats \ 0 replies \ @028559d218 OP 13h
Correct. Knots advocates are bringing this up now quite a bit... that V30 effectively makes bitcoin relay functionally illegal.
It might already be illegal because of the whole money-transmitter thing... but it's "more illegal" now because even one image/document on the entire blockchain that's illegal/classified/objectionable makes the entire network legally questionable.
reply
0 sats \ 0 replies \ @SimpleStacker 8h
regarding objectionable material, i kinda want to look up what the law says about what does and doesn't constitute illegal activity there. Like if I were unknowingly hosting that material because it's on a bitcoin block somewhere...
but i'm too afraid to look it up
reply
100 sats \ 0 replies \ @optimism 12h
so this test, currently on the knots repo, will fail on this magic new hard-forked Knots?
   # Make a large scriptPubKey for the coinbase transaction. This is OP_RETURN
   # followed by 950k of OP_NOP. This would be non-standard in a non-coinbase
   # transaction but is consensus valid.

   # [..]

   # Get the block parameters for the first block
   big_script = CScript([OP_RETURN] + [OP_NOP] * 950000)
   # [..]
This "war" (lmao!) shows how pathetic the community is. Let's do a nice dip. To under 1K USD.
reply
96 sats \ 2 replies \ @siggy47 16h
I wish Saylor and Fink would pick a side so I can pick the other one.
reply
36 sats \ 1 reply \ @SimpleStacker 8h
What if they pick opposite sides?
reply
30 sats \ 0 replies \ @siggy47 8h
That would be a problem, but I think they would be on the same side.
reply
36 sats \ 0 replies \ @supratic 17h
both, so I can analyze and compare.
reply
21 sats \ 2 replies \ @0xbitcoiner 18h
You mean you couldn’t put that info in before version 30?
reply
0 sats \ 1 reply \ @028559d218 OP 18h
My understanding is that you could... but many people are saying that with op_return it will be different.
Even if someone selects their own mempool policy... the transactions/data itself is still being stored on the node after it's mined in blocks and those blocks are relayed.
So a hard fork is needed.
reply
42 sats \ 0 replies \ @0xbitcoiner 18h
I don’t really have a solid opinion, but I remember people talking about a hard fork because of the inscriptions, and it still hasn’t happened. I’m not ruling it out, but honestly, I think it’s kinda unlikely. Time will tell.
reply
5 sats \ 0 replies \ @SatosphereJunction 12h
It is beyond reckless for Core 30 to force this change to the protocol.
reply
0 sats \ 0 replies \ @Entrep 1h
You've raised a valid point about the potential for unwanted data on the blockchain. It's a real issue, and it's something the community has been discussing for years.
reply
0 sats \ 0 replies \ @realBitcoinDog 4h
Lmao wait what did I miss? They hard forked?
reply
0 sats \ 0 replies \ @oliverweiss 16h
How likely is it that a hard fork will happen in your opinion?
reply