frustrated with both core and knots
would like to see a conservative well reviewed and maintained third option
will do my best to make that a reality
until then i will simply not upgrade my nodes
Thread
Login to reply
Replies (31)
Is the implication meant to be that Bitcoin Core isn't conservative, well reviewed, and/or well maintained? If so, why do you think that?
Or is your desire to have additional implementations that are conservative, well reviewed, and well maintained? If so, do you think that's a better use of limited developer talent than focusing on making Bitcoin Core better?
When I read your post, I get the feeling that you think about "Core" and "Knots" as teams that each move with a single shared purpose, as if under the direction of an individual. That might be true for Knots, which effectively has a single developer, but it's not how I see the Bitcoin Core project, whose contributors are often in disagreement with each other (if usually only about the best way to achieve a particular goal). Maintaining that environment where independent contributors can easily collaborate, are free to express their differing opinions, and can create single-topic software forks (like PT's librerelay or the BIP148 activation client) if they feel out of alignment with the other devs seems to me like a better use of scarce talent than creating more implementations for the purpose of having more teams.
thinking something similar to the latter but with more maintainers
The more the merrier
Puts last year's discussions on ossification into context really with all the squabbles.
Be fascinating to see what would come out if all this energy were directed instead to L2/L3 solutions and additional work on mining and hash power decentralisation. Humans are similar to electricity grids - vast energy losses in trasmission!
Exactly. I'm fine staying on v28 for a few years
Go to 29. You may not get 2 years out of 28.
I am using it with LND - works great, recommended π
if this is the best drama we have u know we are struggling this cycle
NOTE OF THE YEARπ«‘
There is no technical basis to oppose lifting the OP_RETURN limit in mempool policy. The amount of emotional thinking in this space is wild.
Unless of course you are not a jew and do not like the child porn on your home servers.
Just go buy BSV and leave BTC alone.
And I will support it.
Let's go!
frustrated with both core and knots
would like to see a conservative well reviewed and maintained third option
will do my best to make that a reality
until then i will simply not upgrade my nodes
View quoted note →
Bitcoin is just another victim of the old EMBRACE, EXTEND, EXTINGUISH corporate playbook, a documented strategy used by tech giants.
"Maxis" were maybe the first (unwillingly?) actors of this playbook
Good luck.
I'll be upgrading to v30.
You enjoy the child porn as well? Nice!
Door number three is the status quo.
Best...ππππππ«Ά
Libbitcoin enters the chat
3rd option would be cool roll back Taproot and fix OP_RETURN at 21 bytes.
hope you are just trolling.
Satan Core 1.0 is looming .. I sh*t you not.
What versions are people running?
View quoted note β
fence straddling? π
Get Eric Voskuil on citadel or listen to his Bitcoin takeover interviews. The project is solid but, from his words, hasn't taken any third-party funding.
As a dev, libbitcoin is ok to get running and hack on, but it's missing the type of project management that core has. It's not really possible to find out what needs to be done, unless it's behind closed doors. All their comm channels seem dead
Libbitcoin is the way.
Why?
Core solution is just accepting that Ordinals are inevitable in the chain and minimize damage, allowing people to use OP_RETURN as preferred option to upload this data.
Instead of storing in Witness or another solutions that increase UTXO set, that will be an increase in RAM requirement for nodes, a true menace for decentralization.
Do it @ODELL ! The more implementation options we have, the more decentralized bitcoin becomes. This is the way.
Do we have any third implementation that would simply be conservative?
Just a v28 with only patches in case of network-threatening bugs?
I'd like to support that kind of third implementation. Might as well use those sats while they still hold some value...
