Core & Knots aren't the only choices \ stacker news ~bitcoin

pull down to refresh

555 sats \ 52 comments \ @siggy47 4 Sep bitcoin

In trying to follow this debate, I keep seeing @justin_shocknet refer to something called BTCD. I wondered what he was talking about, and while hunting around I found this site.

I'm not suggesting that anyone switch to some obscure implementation. I just thought this site was interesting:

https://coin.dance/nodes

view all related items

447 sats \ 9 replies \ @justin_shocknet 4 Sep

I wouldn't call BTCD obscure, literally every LND node uses its walletkit, which makes it a considerable number of economic nodes

There was one bug exploited by one of the Ark scammers that caused instances to crash a few years ago, but otherwise it's been pretty stable... Maintained by folks at Lightning Labs

There's just not much software around it, I've never ventured to see what it would take to power a mempool visualizer etc with it

I primarily run it for serving block filters

28 sats \ 5 replies \ @siggy47 OP 4 Sep

I wasn't specifically referring to BTCD as obscure. A few of the other implementations are only run by one node.

93 sats \ 3 replies \ @optimism 4 Sep

Bitcore -> nodejs client originally made by bitpay, still maintained
bcoin -> another nodejs client, not-so-maintained anymore
Bitcoin Unlimited -> very old - this is now a hardfork
Bitcoin Classic -> hardfork

not sure:

Bitcoin UASF -> I think this is the BIP-148 client, but tbh this was a long time ago
TRB -> this looks very, very odd.

100 sats \ 1 reply \ @siggy47 OP 4 Sep

Thanks for this. They're all new to me.

36 sats \ 0 replies \ @optimism 4 Sep

None of these in that list are what you'd look to replace Core(-derived) with. btcd is currently by far the safest bet, but I've myself not ran it for 3 years now, so my experience is outdated.

117 sats \ 0 replies \ @DarthCoin 4 Sep

to mention also https://libbitcoin.info

36 sats \ 0 replies \ @Bell_curve 16h

how can you vote for a third party?

53 sats \ 0 replies \ @BlokchainB 4 Sep

Ark scammers hahahahahaha

17 sats \ 1 reply \ @DarthCoin 4 Sep

I've tested once BTCD, back few years ago. But was using quite a lot of resources of that machine. Maybe was my fault not doing something well... idk. Is it better nowadays?

100 sats \ 0 replies \ @justin_shocknet 4 Sep

I've got both core and btcd running on one box and they seem to take about the same resources

btcd  CPU(raw): 64.6%   CPU(machine-share): 1.3%   Cores used: 0.65
bitcoind  CPU(raw): 56.9%   CPU(machine-share): 1.2%   Cores used: 0.57

Only the btcd one is public facing though, its serving block filters to neutrino clients with a high connection cap and is pretty well known, usually pumping out 20+mbps... given that, it's pretty efficient

There were some performance fixes last year iirc but I think they were mostly related to initial sync/verification

257 sats \ 18 replies \ @DarthCoin 4 Sep

Are we not done with this crap debate about "core vs knots" ? Is a waste of time.

84 sats \ 9 replies \ @1984 4 Sep

@DarthCoin i've seen you comment this multiple times before "Are we not done with this crap debate" and I fully agree. however, never saw you comment about this thesis, just curious:

increasing datacarrieresize comes with the downside that higher image quality of child pornography can be put onchain, without having to use inscriptions
node runners would effectively be hosting this kind of stuff forever

103 sats \ 1 reply \ @DarthCoin 4 Sep

if you are worried about porn, don't use internet. Is full of it.

0 sats \ 0 replies \ @1984 4 Sep

ty - zap - that's what i needed a blunt argument by darth

0 sats \ 6 replies \ @mtk4000 4 Sep

It's insane that people are taking this argument seriously. It has always been possible to put objectionable material on chain. It's cheaper with inscriptions than with OP_RETURN. Although I expect Knots zealots to do it with OP_RETURN in an attempt to discredit Core. One of the tradeoffs of a censorship-resistant network.

0 sats \ 5 replies \ @1984 4 Sep

if I am not mistaken the argument goes like this:

with inscriptions the "objectionable data" is spread out in multiple utxos
so one could say that this is a plausible deniability when it comes to child pornography, since no-one can point to a specific utxo and say that noderunners are hosting "objectionable data" unless they use software to see the inscription lol

however, with OP_RETURN, the "objectionable data" can be put into a single utxo - so one can point to it and say that noderunners are hosting it

42 sats \ 4 replies \ @mtk4000 4 Sep

If that's the only argument, it's more nonsensical than I thought. You need software to decode an OP_RETURN and you need different software to decode an inscription. The distinction is completely inconsequential. At least, I don't see how an inscription offers any plausible deniability of anything. It's tied to an input instead of an output.

0 sats \ 3 replies \ @1984 4 Sep

hmm I see your point, honestly can't remember the entire argument and also forgot which influencer said it, and don't wan to go back to find out

0 sats \ 2 replies \ @SimpleStacker 4 Sep

I mean, even a jpeg needs to be decoded

Thus, the argument really rests on an understanding of the law, which I am not seeing any discussion of.

21 sats \ 1 reply \ @nout 4 Sep

The law around this is even more stupid than you would expect and so the difference between inscriptions and op_return is inconsequential.

view all 1 replies

0 sats \ 3 replies \ @supratic 4 Sep

evidently, people have nothing better to do.

10 sats \ 2 replies \ @SatosphereJunction 4 Sep

I have lots of things I'd rather be doing. Core seems intent on disrupting my space.

127 sats \ 1 reply \ @DarthCoin 4 Sep

start using your brain

0 sats \ 0 replies \ @SatosphereJunction 4 Sep

My brain is working fine. Go back and read your own documents.

0 sats \ 3 replies \ @SatosphereJunction 4 Sep

Not sure. Has core decided to stop attacking Bitcoin's protocol?

5 sats \ 2 replies \ @mtk4000 4 Sep

Do you really believe an inconsequential change to relay policy is an attack on Bitcoin's protocol, or are you parroting something you read?

0 sats \ 1 reply \ @SatosphereJunction 4 Sep

Because most nodes run with default settings, changing the default OP_RETURN policy materially alters network behavior. It isn’t a consensus change, but it operates as a de facto protocol change. A very poorly thought through one at that.

0 sats \ 0 replies \ @028559d218 20h

Please correct me if I'm wrong... but your outlook seems to be among the minority of node-runners here at Stacker News. Including among some people who have been in Bitcoin a long, long time.

408 sats \ 1 reply \ @carter 4 Sep

0 sats \ 0 replies \ @028559d218 20h

I don't think the Knots people would understand this.

46 sats \ 9 replies \ @supratic 4 Sep

Interesting to see how knots is taking off... 18,5% now. Yesterday I checked it was 17%

There are many implementations of bitcoin already. Unfortunately, they are not easy to spin up and definitely not for the average pleb to run and maintain.

The day will come, when these and others implementations will be easily accessible and available to chose from, each one with its own flavor.

0 sats \ 7 replies \ @siggy47 OP 4 Sep

18.5 % today. Who knows where it will be in 2 months with the porn FUD? That, coupled with noderunners who remain on 29? Things could get weird.

36 sats \ 0 replies \ @DarthCoin 10h

LOL we still have nodes running the v0.8.3 ! Knots filters will never work with that.

178 sats \ 0 replies \ @DarthCoin 4 Sep

It doesn't really matter the % as long as there will still be around other nodes without any restriction. The same blocks will be downloaded anyways.

Is totally useless.

57 sats \ 3 replies \ @mtk4000 4 Sep

It won't get weird because the Knots filters won't affect the network at all. They'll proudly keep datacarrier transactions out of their personal mempools, and download them anyway after they inevitably get mined.

10 sats \ 2 replies \ @siggy47 OP 4 Sep

I'm no expert in this area, so your reply is comforting. All the fork talk is distressing. Putting that aside, do you think core devs' reputation has already or will take a hit, and will this be a problem once the dust from all this crap has settled?

103 sats \ 0 replies \ @mtk4000 4 Sep

It depends on how aggressively the anti-Core people continue pursuing their social media attack. The most likely outcome is that Core 30 gets released, gains adoption gradually like most releases, nothing changes vis-à-vis data on chain, and people forget about it.

36 sats \ 0 replies \ @supratic 4 Sep

bitcoin don't care about these things. Tick tock next block. What are you worried about?

108 sats \ 0 replies \ @supratic 4 Sep

I think it will get really weird really soon... I'm really ready🍿

0 sats \ 0 replies \ @Fenix 4 Sep

They like the illusion of have choice when they filter spam. Proto-censors.

176 sats \ 0 replies \ @optimism 4 Sep

btcd isn't an "obscure" implementation; it's been around for over a decade; I've ran it for years as a second node. It's not as well reviewed as Bitcoin Core, as it has less eyes on it, but the last few years we've seen good contributions, for example coming from fuzzing efforts, so it's not awful at all. I've also used btcd's wire module for custom p2p clients a lot when doing investigations - this module is literally what triggered me to learn to write production capable golang.

However: running a bitcoin node is a responsibility. If you cannot answer Justin's awesome question "why are you running a mempool?" (most eloquent formulation in #1205858 lol) without proclaiming bs, then it would be wise to study hard before making decisions about which node software to run.

36 sats \ 5 replies \ @0xbitcoiner 4 Sep

👀 #1008546

33 sats \ 4 replies \ @optimism 4 Sep

Has anyone tested it yet in operation? I can't prioritize doing it myself right now. Might not be able to do it before October.

100 sats \ 3 replies \ @0xbitcoiner 4 Sep

I watched the whole video back then, and if I’m not mistaken, they were still in the final testing phase. Not sure if anyone tried it out, but I was really impressed with the performance. Definitely worth checking out!

100 sats \ 2 replies \ @optimism 4 Sep

It seemed that for v3, -node, basically the network and chain logic part, is considered the equivalent of release candidate now (#1194522 and #1197814) and that now it needs interaction in -server, which would make it a package closer to bitcoind.

I want to test the performance of it after IBD, to be able to put the tradeoffs into perspective. For example: libbitcoin does IBD against 100 peers, so I'd want to know what happens if you get 100 peers doing IBD against a single libbitcoin node, what the impact is on machine resources and what the impact of that is on other operations, like unconfirmed tx relay and chaintip blocks.

100 sats \ 1 reply \ @0xbitcoiner 4 Sep

Totally missed those posts, but for a good reason, digital detox and vacation. Your idea sounds awesome! Make sure to share the results with us, it’s definitely gonna make a great post.

33 sats \ 0 replies \ @optimism 4 Sep

I'm really hoping someone will beat me to it haha

138 sats \ 2 replies \ @adlai 4 Sep

There's an interesting tradeoff between diversity of implementations and consensus stability. On one hand, the ethos of permissionless innovation encourages alternative implementations; on the other, each difference in the node's behavior could lead to forking away from the main network.

One notable example of this, which happened just between different versions of core, is the March 2013 Fork.

Obviously, as the ecosystem has matured, specification of the consensus behavior has improved, along with the tools available for implementation developers to ensure that their code doesn't cause chain forks.

0 sats \ 1 reply \ @justin_shocknet 4 Sep

each difference in the node's behavior could lead to forking away from the main network

happened just between different versions of core, is the March 2013 Fork

I think this illustrates the case for competing implementations, if any one of them has a bad update the damage is relatively confined... whereas if 99% of the network is running one implementation and it has a bad upgrade, causing a substantial chunk of the network to upgrade with it, that could be much more damaging.

All eggs in one basket theory

0 sats \ 0 replies \ @adlai 4 Sep

From a consensus persective, each different version of a codebase is a node that could behave differently; the same even applies to hardware and configuration parameters, although if the code is written properly, those aren't supposed to have consensus-critical effects.

As you can see from BIP0050, the decision in that case was actually to downgrade the update, despite the fact that one could argue that the new version actually fixed an undocumented bug in the old version.

36 sats \ 0 replies \ @sagars209 4 Sep

here you go .. check this great video https://www.youtube.com/watch?v=g5kIhj1ioS0