BIP 110: Reduced Data Temporary Softfork

[Cricktor]

This is simply a patched version of Core done by some random Github user.

From what I saw on that Github repo (I didn't dig very deep) it's a fork from Knots with the changes by some dude to make it BIP-110 compliant.

So, if you trust Knots, check the applied patches and build it from source, you may risk to use it if you want to. I certainly don't recommend to use the binary releases, either. DYOR! Not that I'm interested to run Knots at all and whatever is patched off it.

And not really different than Knots which is also a Core fork.

I read somewhere, lost the source, oh boy that sounds a lot like urban gossip now, that the Knots developer doesn't make it too easy to follow his changes of his Core fork. But it's possible that I misunderstood something as I'm not a developer and don't have a lot of experience with git and Github repo management and fork related stuff.

It's likely a question of where you set your trust anchor, besides the crypto mantra "don't trust, verify!".

I'd highly recommend against using such stuff with real Bitcoins.

How many Bitcoin node operators actually use their node to manage a wallet with coins?

I can only speak for myself. I operate watch-only wallets with my Core node, no hot or cold non-watch-only wallets directly on my Core node(s). For real coins I use Electrum or Sparrow wallet connected to my own Electrum server, private keys are in a hardware wallet.

...

Some are into surprises, aren't they?

I thought they were all aware of a bug that was found in v30.0 and 30.1 about wallet migration. These Devs knows nothing or they know but love to fool around.

The wallet migration bug was only nasty if you met the quite particular triggers of it. I wouldn't exaggerate it. Sure, it's not nice to have such a bug but in my opinion it wasn't a reason to quickly upgrade (for me).

If you don't have backups, you're a bit of a lost case already. (No backups? No merci!)

The Knots maintainer/developer is probably too busy to spread his nonsense to create his fork based off Core v30.x because, well, in their view Core v30.x is the incarnation of evil.

[ABCbits]

the first release candidate 1 of uasf bip-110 port to Bitcoin Core is now available!
this is a pre-release, further information and the download files can be found at this github link: --snip--

How did you find out about that fork/git repository?

And not really different than Knots which is also a Core fork.

I read somewhere, lost the source, oh boy that sounds a lot like urban gossip now, that the Knots developer doesn't make it too easy to follow his changes of his Core fork. But it's possible that I misunderstood something as I'm not a developer and don't have a lot of experience with git and Github repo management and fork related stuff.

It's likely a question of where you set your trust anchor, besides the crypto mantra "don't trust, verify!".

You probably talk about this blog post, https://blog.lopp.net/knot-a-serious-project/ only section "Luke's Security Practices".

[cygan]

✂️
How did you find out about that fork/git repository?
✂️

this tweet brought this fork/git repository to my attention: https://x.com/dathon_ohm/status/2030054026729992597

and of course everyone is responsible for their own actions and you should check everything at least 2-3 times before trying out various new ‘releases’ in this cryptospace
i definitely didn't want to mislead anyone with my previous post!

[ABCbits]

✂️
How did you find out about that fork/git repository?
✂️

this tweet brought this fork/git repository to my attention: https://x.com/dathon_ohm/status/2030054026729992597

and of course everyone is responsible for their own actions and you should check everything at least 2-3 times before trying out various new ‘releases’ in this cryptospace
i definitely didn't want to mislead anyone with my previous post!

That X account share same name with author of BIP 110. But something is odd since other article about BIP 110 on internet point to different github account, https://github.com/dathonohm. Either way, i'll just avoid those github repo/account.

[DaveF]

At a *guess* they are tweeting and posting a bunch of links to generate some SEO and possibly get people who don't know to run their fork to show BIP110 support.
I would make sure anyplace you post links to the github you should make it non linkable like this:  h t t p : / / t h i s i s n o t w h e r e y o u s h o u l d b e . c o m

And probably always say somewhere near it that BIP110 will censor transactions and possibly cause you to loose coins.

This way any search engine that sees anything about that BIP will also see the fact that BIP110 will censor transactions and possibly cause you to loose coins.

-Dave

[Wind_FURY]

Reading the latest posts about BIP-110, it's getting very obvious that some people who didn't like Ordinals/Runes are currently starting to understand that it doesn't matter that they exist, and that the better path to take is to simply let the fee market do its thing than to be with those people who want to censor non-financial transactions.

[DaveF]

Reading the latest posts about BIP-110, it's getting very obvious that some people who didn't like Ordinals/Runes are currently starting to understand that it doesn't matter that they exist, and that the better path to take is to simply let the fee market do its thing than to be with those people who want to censor non-financial transactions.

Part of me thinks we can hope that people see what is going on. The other part of me really really really wants all these people who support knots and censorship and confiscation of coins fork off and go away.

Kind of like the BCH / BSV people, we really don't hear much from them anymore.


-Dave

[Wind_FURY]

Reading the latest posts about BIP-110, it's getting very obvious that some people who didn't like Ordinals/Runes are currently starting to understand that it doesn't matter that they exist, and that the better path to take is to simply let the fee market do its thing than to be with those people who want to censor non-financial transactions.

Part of me thinks we can hope that people see what is going on. The other part of me really really really wants all these people who support knots and censorship and confiscation of coins fork off and go away.

Personally, I'm trying to be agnostic and ignore, BUT  I like laughing at their narrative. EVERYONE knows there's no actual need for BIP-110 because it itself doesn't actually work in "filtering" those transactions they don't like.

Their "leaders" continue to misinform and mislead their followers in a path where they're actually going to lose. But it's laughable because they're going to HODL Bitcoin and sell KnotsCoin within two to three years.

 

[d5000]

That's my current assessment about which kind of "spam" BIP-110 could currently "fight":

- Taproot-based image/video NFTs: yes, but they were rarely a problem in the past (BRC-20 made up the vast majority of Ordinals transactions and block space usage) and can be replaced with other mechanisms
- OP_RETURN based image/video NFTs: yes, but they were rarely a problem in the past, can also be replaced
- Veriblock: Yes, but also can be replaced by OLGA or similar protocol
- Citrea: Yes, but simply would use fake public keys again.
- BRC-20: Yes, but they can be replaced with other protocols like Runes or Counterparty
- Stampchain traditional (P2MS): yes, but it is considered legacy and OLGA is the current standard
- Stampchain OLGA: No (uses 34 byte P2SH outputs)
- Runes: No (uses 83 bytes OP_RETURN)
- Counterparty: No (uses 83 bytes OP_RETURN)
- Omni: No (uses 83 bytes OP_RETURN)
- Images in general: No (can be embedded in OLGA stamps and other techniques)
- Non-standard contiguous images: No (see description here)
- Standard contiguous images: If I understood Habovštiak correctly, also no.
- Arbitrary data in general: can never be blocked, by no BIP of any kind, due to the fake private key method.
- Destructive illegal data attack: No, because of the four previous items.

Correct me if I'm wrong with any of these.

This means that while some protocols may have to change, they would be able to. And while some particular methods may become a bit more expensive, as I understood the Habovštiak method is quite efficient in using transactions' space, and thus would be similarly cheap to OP_RETURN.