pull down to refresh

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:
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
reply
I wasn't specifically referring to BTCD as obscure. A few of the other implementations are only run by one node.
reply
  • 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.
reply
Thanks for this. They're all new to me.
reply
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.
reply
reply
how can you vote for a third party?
reply
Ark scammers hahahahahaha
reply
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?
reply
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
reply
Are we not done with this crap debate about "core vs knots" ? Is a waste of time.
reply
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
reply
103 sats \ 1 reply \ @DarthCoin 4 Sep
if you are worried about porn, don't use internet. Is full of it.
reply
0 sats \ 0 replies \ @1984 4 Sep
ty - zap - that's what i needed a blunt argument by darth
reply
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.
reply
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
reply
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.
reply
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
reply
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.
reply
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.
evidently, people have nothing better to do.
reply
I have lots of things I'd rather be doing. Core seems intent on disrupting my space.
reply
127 sats \ 1 reply \ @DarthCoin 4 Sep
start using your brain
reply
My brain is working fine. Go back and read your own documents.
reply
Not sure. Has core decided to stop attacking Bitcoin's protocol?
reply
Do you really believe an inconsequential change to relay policy is an attack on Bitcoin's protocol, or are you parroting something you read?
reply
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.
reply
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.
reply
408 sats \ 1 reply \ @carter 4 Sep
reply
I don't think the Knots people would understand this.
reply
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.
reply
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.
reply
LOL we still have nodes running the v0.8.3 ! Knots filters will never work with that.
reply
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.
reply
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.
reply
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?
reply
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.
reply
bitcoin don't care about these things. Tick tock next block. What are you worried about?
reply
I think it will get really weird really soon... I'm really ready🍿
reply
They like the illusion of have choice when they filter spam. Proto-censors.
reply
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.
reply
reply
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.
reply
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!
reply
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.
reply
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.
reply
I'm really hoping someone will beat me to it haha
reply
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.
reply
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
reply
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.
reply
here you go .. check this great video https://www.youtube.com/watch?v=g5kIhj1ioS0
reply