yes because me and the 100s of people who have been contributing for the past decade just all of a sudden wants to destroy bitcoin. People need to give their head a shake.
What exactly have you contributed to Bitcoin code? I'm sure you contributed less than op return nackers such as
@Adam Back and
@Luke Dashjr. Make it make sense. It seems you and
@calle have external motives to be honest. You guys are trying too much and not really addressing the ussue.
I didn't knots people cared about credentialism, but I guess thats fair. so here are mine.
there are ~1234 contributors to bitcoin. in terms of raw contributions mine would be 188/1234:
https://cdn.jb55.com/s/4104d140cd815d77.txt#:~:text=William%20Casarin
If adam has contributed he must be doing it under a nym since I don't see any commits from him.
my commits:
📃.txt
I worked on usdt tracing and performance optimizations. I am by no means a frequent contributor, I mainly work on lightning tech.
things I've worked on:
core-lightning:
📃.txt
lnsocket - a C/rust library for talking to lightning network nodes
GitHub
GitHub - jb55/lnsocket-rs: A rust library for communicating with lightning nodes
A rust library for communicating with lightning nodes - jb55/lnsocket-rs
btcs - a bitcoin toy bitcoin script interpreter
GitHub
GitHub - jb55/btcs: toy bitcoin script parser/evaluator/compiler/decoder
toy bitcoin script parser/evaluator/compiler/decoder - jb55/btcs
bitcointap - A tool for tapping into bitcoin-core tracepoints to extract data in realtime:
Delving Bitcoin
Bitcointap: an strace-like tool for bitcoin ebpf USDT tracepoints
I thought I’d share this tool I put together, based off of @0xB10C 's peer_observer project. bitcointap is a rust library and cli tool for tappin...
opentimestamps: i put together the haskell implementation of ots, and built a suite of tools that work with them:
GitHub
GitHub - jb55/ots-tools: opentimestamps tools
opentimestamps tools. Contribute to jb55/ots-tools development by creating an account on GitHub.
I maintain the "bitcoin" nodejs rpc lib:
https://npmrepo.com/bitcoin
I've hacked on HWI and helped with a lot of the bitcoin-nix infrastructure.
I've also been around since 2010 and have a decent understanding how various parts of the codebase work, especially on the script side.
what about you?
Mr. Back's work is in the citations of the whitepaper and Luke got way more credentials, so do the other nackers who are in the top rows. I, unfortunately, only started on this journey in 2017, but I am constantly learning. I try to remain unbiased and wrote about the issue my thoughts. More nuanced approach would be appreciated if you are with the ackers.
Not meant to discredit contribution , but you can’t just assume that it’s positive (though its intention almost 100% is)
that's nonsense
And, to be honest, I don't run knots, I run core 29.0.0 and intend to run it for the upcoming few years. I surely won't be upgrading to v30 any time soon.
i'm going in the opposite direction. I want more freedom not less, so I am patching my node to run without any filtering (libre relay)
You are so good in what you do .
Libre relay has been around for ages, you've been running that all this time? I would assume you were on Core
yes i run core, but i rebased libre relay and it wasn’t difficult so that made me impressed enough to try it
I have been very anti paternalistic filtering since the very early days of bitcoin, which is why i’m probably so anti knots since they want to add more filters not less.
I understand there's a need to relax the data carrier limits for new use cases but opening it up to the max block size seems like an overshoot. I want to retain the optionality, though I understand that, after block confirmation, my node will end up storing the data that guys like yourself relayed to the miners. It's a catch 22.
I am kind of mix feeling , though I never contribute to core dev due to my limited knowledge , I knew spam is annoying and having filter seems such a great idea . 💡 dilemma : to filter or not to filter
its just relaxing the filters to what is actually reflected in the protocol rules. The more divergence between relay policy and consensus rules and economic activity, the less accurate your node is when doing fee estimation.
> its just relaxing the filters to what is actually reflected in the protocol rules.
Which is the max block size.
> the less accurate your node is when doing fee estimation.
I never had a substantial discrepancy in fee estimates.
I don't think there are many new attack vectors introduced by these changes but still, as good practice, no upgrading to newer versions before they have been out for a prolonged time.
It surely will lead to a cleaner code, that I agree.
yes max block size, something you can relay today on libre relay and get it in into a block with 0 issues. its not done because its undiscounted and non-economical. people would use witness space for this instead.
In essence, it's not done because the propagation path is scarce. The more widespread Libre Relay nodes are, the more reliable and censorship-resistant the OP_RETURN data storage becomes in the Bitcoin blockchain. At 1%, it's niche and fragile; at 20%, it starts to significantly improve reach.
unfortunately this is not true. you get 100% deliverability with about 5 nodes
Given below is a try at unbiased assessment of the perspectives from both sides. A nuanced approach is key here, no need to attack and belittle each other.
ManyKeys
OP_RETURN Data Carrier Size Removal: Technical and Legal Risks
Increasing Bitcoin's OP_RETURN data carrier size from 80 bytes up to ~4 MB per block (Bitcoin Core v30) brings new technical and legal risks—especially regarding liability for illicit data—alongside a drive toward network standardization and transparency. This analysis weighs both sides, highlighting the debate between critics warning about centralization pressures and developer advocates focused on protocol realities and censorship resistance.
Read article →
Only if they know a miner running liver relay and have him in their peer; oherwise, it seems not plausible.
miners do run with very few filters, because they are economically motivated to do so
Given that Inscription based fees represent only a negligible (~0.1%) addition to miner profits after hashrate and cost adjustments, and with added risk of transmitting illicit material, miners might be more careful in accepting 4MB files for confirmation, don't you think?
are you asking if miners are going to start widespread censoring of valid transactions in bitcoin? i doubt it. even if one did another wouldn't. otherwise bitcoin wouldn't be censorship resistant.
No, they can easily not update to v30 or not run libre relay, but instead continue running v29 with their data carrier preferences and still be within protocol rules. They would thus be exercising their choice. If more become aware of this, the propagation path would remain niche and limited. It's their choice to make. Looking forward to seeing how this unravels.
you can't stop economically motivated actors from getting around it. its not hard to run libre relay over core or knots.
This is like claiming there's no risk/reward. For negligent upside and exceeding risks, they might choose not to. If most chooses not to, the propagation path remains limited, as currently. These are just possible scenarios, you might be correct to bet on human greed.
One does nit have to call it greed. But it is the best bet, that a majority is intrested in a working businessmodel. And inclusive businessmodels offer more opportunity than exclusive ones.
I set my filters to remove only monetary transactions 🌝
lol equally useless
