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?
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.
a full on 1/3 of knots people said they want to run filters in consensus
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.
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.
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.
Citation needed. OP_Return limit is a policy or Bitcoin Core, the node implementation most nodes have been running since Satoshi.
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.
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.
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.
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.
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.
Start by telling me why you, personally, run a mempool?
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.
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.
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.
Just run core v30 with datacarriersize=80 in bitcoin.conf. All they change is the default value.
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
If you are worried about this, you should go back in time and stop running Bitcoin Core more than a decade ago, because the blockchain has had such 'objectionable content' in it for longer than that.
That's why... I don't understand the point of 'run knots save Bitcoin'...
Wouldn't knots need a consensus change, need a block 'cleanup' to be truly 'clean'?
What are knots people going to do if a 'questionable' jpeg winds up as an inscription?
Will the government say "oh it's just an inscription it's fine"... but "oh it's in your mempool [in that case] isn't not???"
None of this makes any sense to me.
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.
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.
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
We can reduce
OP_RETURNlimits in a soft fork afaik. Maybe we can get near universal support for a covenant soft fork if we reduceOP_RETURNthis way.This would cause a hard fork.
Explain why please.
Limiting OP_RETURN size would be a soft fork.
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!
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.
You can do it if it's miner enforced. Is Ocean going to enforce it with 10-15EH?
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.
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.
So offer a deal? Soft-fork in covenants to soft-fork out larger op-returns? This is beyond my technical understanding.
I wouldn't hold out much hope for a deal. It's an adolescent food fight at this point.
best take
Covenants are instant ethereumification.
If Knots people weren't retarded they'd focus on fighting that.
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.
I wish Saylor and Fink would pick a side so I can pick the other one.
What if they pick opposite sides?
That would be a problem, but I think they would be on the same side.
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.
both, so I can analyze and compare.
You mean you couldn’t put that info in before version 30?
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.
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.
What is really the probability that CSAM gets included by any of the large KYC pools?
It seems somehow unlikely that such a block would be constructed by a large pool due to legal risks.
And if it is constructed by some other miner I could imagine that such a block would be orphaned by the other miners.
Yes it happened on the BSV chain, but who care's about that?
Data storage on the chain is undesirable, but this fear about CSAM seems exaggerated.
It is beyond reckless for Core 30 to force this change to the protocol.
Lmao wait what did I miss? They hard forked?
they will wait til they have enough % of the network
Lol
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.
Get this crappy ai spam crap out of here
How likely is it that a hard fork will happen in your opinion?
It wouldn't surprise me if the Knots people changed consensus (forked off) from the the main chain. That seems to me... the only likely way for them to achieve their goals.