AJ Towns censoring on Delving Bitcoin to cover Bitcoin Core backdoors ? \ stacker news ~bitcoin

AJ Towns censoring on Delving Bitcoin to cover Bitcoin Core backdoors ?

15.9k sats \ 120 comments \ @theariard 27 Feb bitcoin

During the last weeks, while I was reviewing few PRs on Bitcoin Core (e.g v3 policy or sibling eviction), I did notice that code design and proposals were abnormally vulnerable to some class of attacks to target Bitcoin use-cases. After questioning the reviewers and proposing them to test the code branch in real-world conditions on signet or mainnet, they ignored my critics and one of the maintainer move ahead merging the PRs.

Latter on, on the Bitcoin R&D forum dubbed “Delving Bitcoin”, AJ Towns did reveal the existence of private discussions rooms where some selected Bitcoin Core contributors were engaging and designing new Bitcoin Core proposals. Thus bypassing the usual transparency standards underpinning FOSS and making Bitcoin Core development a “close-door” process. Some of the vulnerable code enhancements I did pointed out the issues in public on the Core repository, sounds to have been through this “close-doors” process.

As Pieter Hintjens (the Zero MQ creator and a FOSS veteran), put it in one of his book on the necessity of transparency in FOSS.

"Transparency is very important to get rapid criticism of ideas and work in progress. If a few people in a team go off and work on something together for some time -- a few days seems harmless, a few weeks is not -- then what they make can be presented to the group as a fait accompli. When one person does that, the group can just shrug it off. When two or more people do that, it becomes much harder to back off from bad ideas. Secrecy and incompetence seem bound together. Groups that work in secret do not achieve wisdom.

TIP: When one person does something in a dark corner, that's an experiment. When two or more people do something in a dark corner, that's a conspiracy.”

When I did the same remark to AJ Towns on the aforementioned thread, rather to engage constructively in the discussion on what communication standards we all wish to maintain a high-degree of intellectual honesty on the “Delving Bitcoin” forum in a decentralized ecosystem, he did threat me back to cancel my account by abusing its admin rights on the platform and then deleted my post (cf. the screenshot).

Dear Bitcoin community, there is something very fishy happening in the Bitcoin Core development process right now, and I seriously wonder if a subset of contributors are not engaged in deliberately inserting backdoors to defraud or hypothetically get technical leverage on user funds in the future, for any kind of political move.

Personally, I’ll stop engaging or contributing on Delving Bitcoin, we have many more communications platforms available to engage in Bitcoin development (e.g nostr, google groups, personal blogs, stacker.news, etc).

https://m.stacker.news/17758

view all related items

2408 sats \ 2 replies \ @rblb 27 Feb

So, besides the usual quarrels that are very common in FOSS development, you raise an important point, my understanding is that you do believe that these PRs introduced vulnerabilities to certain attacks.

The fact that the PR is merged doesn't prevent you from proving your point, so, if you can simulate these attacks in a real world scenario, as you proposed originally, I suggest you do that and show the results to the public, you will get much more people on your side then.

304 sats \ 0 replies \ @theariard OP 1 Mar

That is on my todo list, like still working on the mitigations and disclosure of any other bitcoin or lightning security vulnerability that could be still of my knowledge. Like it has been the case very consistently since beginning of contributing on rust-lightning (now LDK) in 2018 / 2019.

0 sats \ 0 replies \ @premitive1 27 Feb

you will get more people on your side then.

And more credibility.

2383 sats \ 7 replies \ @oomahq 27 Feb freebie

There is something very fishy going on in Bitcoin Core indeed. I have another "anecdote" involving Anthony Towns and several other developers and maintainers:

In v26.0 Marco Falke saw fit to redefine the description of the datacarriersize config option from:

"Maximum size of data in data carrier transactions we relay and mine"

"Relay and mine transactions whose data-carrying raw scriptPubKey is of this size or less".

AJ Towns and Gibbs ACKed the redefinition: https://twitter.com/oomahq/status/1742679458530672642

This was around the same time @lukedashjr was proposing to extend the applicability of datacarrier to also catch inscriptions. Then Gloria Zhao and Ava Chow (Bitcoin Core maintainers with commit access) used that new meaning of datacarriersize as an argument to reject the fix (for non autists: inscriptions store they data in the input section of transactions, while "scriptPubKey" means output, so they narrowed the applicability of datacarriersize in its description text).

Luke's PR: https://github.com/bitcoin/bitcoin/pull/28408

This is particularly infuriating since Luke is also the developer who originally contributed the datacarrier and datacarriersize config options to Bitcoin Core back in 2014. They redefined the meaning of his contribution in his face to be able to reject his new work more comfortably.

Here's some Twitter receipts of Ava Chow arguing that the "inscription bug" is fixed due to the "amended" meaning of datacarriersize:

https://m.stacker.news/17775 https://m.stacker.news/17776

1844 sats \ 3 replies \ @BitcoinErrorLog 27 Feb

This is also how mempoolfullrbf got in. I had support from the author and some other core devs for a PR to remove it before release, but they said that because it was already scheduled for release in some weeks, it was me trying to change consensus. Since when his Core release schedule a method of consensus? The custom is that a clearly controversial change that disrupts the user space would at least be postponed, but no rational argument would be accepted.

5213 sats \ 1 reply \ @anon 27 Feb

You had no business defending your broken business model and fundamental misunderstanding of fullrbf in the first place, so lets not pretend that these issues are at all related.

There is an issue here, but it's not your misunderstanding of the security of 0 conf transactions or node relay policy or the inclusion of settings and configuration option enabling users to configure their relay policies as they please - and as they already could with more effort or alternative clients. Lets not conflate your misunderstanding with the politics of Bitcoin Core development.

212 sats \ 0 replies \ @nk1tz 27 Feb

He had every right to object to a disruption of existing and appropriately risk-managed 0conf use cases.

Especially so when core contributors were also projecting an explicit desire to turn the default to ON in a future release on the back of its introduction.

I disagree that this isn’t related. Both situations are examples of pushing aside well articulated critique to achieve a false sense of consensus.

154 sats \ 0 replies \ @theariard OP 1 Mar

As a PR author I still think mempoolfullrbf is a worthy technical change, especially to avoid discrepancies among network mempool states.

Retrospectively this is correct the deployment could have been more smoothed and coordinated to let some use-cases adapt their software.

Overall, I still think the conversation should be zoomed out, it’s missing the point on the role of transaction-relay and mempool policy is playing in the security and operations of modern bitcoin use-cases (e.g Lightning or ordinals), and the de facto technical leverage that Core as a project can exercise on them. It’s not anyone responsibility though kinda the situation we’re in today.

Highlighted community awareness on this subject as early as 2021: https://bitcoinops.org/en/newsletters/2021/05/19/

786 sats \ 1 reply \ @wealthcrumb 27 Feb

Luke is also the developer who originally contributed the datacarrier and datacarriersize config options to Bitcoin Core back in 2014

Interesting, if he was planning on doing something akin to inscriptions back then, and was trying to keep the door open for them at the time. Perhaps even while convincing the devs to ACK based on their understanding the change in the way that it is now defined.

So, is it that devs are manipulating things now, or is it that Luke was manipulating things back then?

106 sats \ 0 replies \ @oomahq 27 Feb freebie

To the best of my understanding, back then Luke was working to try to restrain OP_RETURN data blobs with the (still active) spam filter we all know and love (max 80 bytes).

This is basically what datacarriersize is.

Here are the revelant Pull Requests: https://github.com/bitcoin/bitcoin/pull/3715 https://github.com/bitcoin/bitcoin/pull/5077

109 sats \ 0 replies \ @theariard OP 1 Mar

See one of my underlying comments on the impact of transaction-relay and mempool policy on the operations of modern Bitcoin use-cases, such as inscriptions.

My technical position would be more to dry-up such policy in terms of consensus rules, i.e identically enforced by all peers of the Bitcoin network rather to keep multiplying the jungle of special policy rules, where a single change can break your whole use-case.

We’ll always have to deal with mempool policy, yet it might be more wise to keep it minimal and differentiating as less as we can among types of Bitcoin use-cases (unless for reasons on on-chain economic traffic ? even that proposal might be contentious).

4549 sats \ 21 replies \ @theariard OP 27 Feb

I’ll make one more public comment as I being asked by a Bitcoin Core contributor I trust what is going on.

I’m not the first one who has sent lawyers letters to another Bitcoin developer to produce a chilling effect.

Alex Morcos from Chaincode did last year, it’s documented here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003887.html

For everyone awareness, a lot of Bitcoin Core developers, a lot of younger and elders devs cannot speak freely on the subject as their legal fees in the context of some of the BDFL litigations is contributed by Alex Morcos.

From my appreciation, a lot of developers fear to speak up their minds in public and to be threat to be withdrawn legal support provided in the context of current or any future litigation.

Personally, I’m not a defendant in the CSW litigation so I don’t have this constraint and I stay free to speak up my minds about other developers’s behaviors, who ever they are.

608 sats \ 1 reply \ @petertodd 27 Feb

For everyone awareness, a lot of Bitcoin Core developers, a lot of younger and elders devs cannot speak freely on the subject as their legal fees in the context of some of the BDFL litigations is contributed by Alex Morcos.

Speaking as one of those devs, being in three different lawsuits with Craig Wright right now funded I'm part by Chaincode, it would be good if Chaincode could publicly confirm that the letter you received was real or not.

1004 sats \ 0 replies \ @theariard OP 1 Mar

I confirm the authenticity of the letter.

I can also confirm there were no material evidences backing up this letter according to Chaincode’s own legal firm. A practice which is very ethically questionable according to US bar guidelines in matters of lawyers’s letters.

I’m still waiting for Alex Morcos to clarify his pattern of behavior here.

Overall I believe the BDFL is a positive thing, at the very least in terms of having one or more legal defense group for FOSS developers at the image of the EFF. Without this becoming a factor of centralization itself.

I fully empathize with you on being a defendant in three lawsuits with CSW. You can be very certain the legal basis to open additional counter-litigation against CSW and Calvin Ayre have been explored on my side.

5431 sats \ 1 reply \ @TonyGiorgio 28 Feb

a lot of younger and elders devs cannot speak freely

a lot of developers fear to speak up their minds in public

Hmm I wonder fucking why. Maybe because of bullshit like this post.

77 sats \ 0 replies \ @theariard OP 1 Mar

I didn’t qualify AJ’s maintenance of Delving Bitcoin of bullshit.

Quite the contrary, I did invite to clarify his position and make it clear I was interested to engage in the conversation.

In matters of FOSS, if you have an issue with transparency and justifying your public actions in the public domain, something is wrong in my opinion.

1120 sats \ 13 replies \ @anon 27 Feb

I'm extremely skeptical of your point of view based on you sending a lawyer letter alone. This is a questionable extreme escalation at best and CSW-esque that pushes more conversation offline in privacy at worst. Can you say anything further to convince the general pleb public that this was a reasonable course of action and you had exhausted other options?

350 sats \ 11 replies \ @premitive1 27 Feb

Are you daft? @theariard was the one who RECEIVED a letter from a lawyer. What are you on about, anon?

10 sats \ 0 replies \ @anon 27 Feb

should "I’m not the first one who has sent lawyers letters to another Bitcoin developer to produce a chilling effect." Instead read ? "I’m not the first one who has received lawyers letters to another Bitcoin developer to produce a chilling effect."

10 sats \ 9 replies \ @anon 27 Feb

sincere apologies, if thats the case I misread and had it in reverse

0 sats \ 8 replies \ @anon 27 Feb

You had it right. He did receive a letter from chaincode labs which is a separate case to this one. I only see one threat of action in this discussion and it comes from the OP and can be found in other comments.

276 sats \ 1 reply \ @petertodd 27 Feb

I don't read it that way. If the archives are correct he was accused of making legal threats before making any statement that can be construed as one.

103 sats \ 0 replies \ @theariard OP 1 Mar

Yes, my original post on Delving Bitcoin was to raise awareness on any long-term risk we could have to have design development process happening behind “close-doors” especially related about IP.

When we see how CSW is making claims based on decade-old communications, and some of the very OG developers (e.g Sirius) have publish their own personal archives to bring clarity, I sincerely think we should minimize private technical conversations only for grounded reasons.

10 sats \ 3 replies \ @premitive1 27 Feb

How can you argue it's a separate case to this one when the discussion is about whether or not Bitcoin development is being corrupted by involvement of a corporation who sent a letter from their lawfirm a year prior to the discussion in question. https://github.com/jamesob/delving-bitcoin-archive/blob/master/archive/rendered-topics/2024-02-February/2024-02-22-workgroup-lifecycle-id598.md

0 sats \ 2 replies \ @anon 27 Feb

Is this as simple as at that github link the OP stating, "At the very least, people engaging in such private communication channels should consult lawyers in the main major juridictions, if such communication practice is not specially tainting their responsibilities in case of future FOSS software defect in some way." in a genuine way of trying to say "hey I don't know if this is legally acceptable with this software license maybe we should ask a lawyer" and getting misconstrued as a direct legal threat and all spinning out of control from there? Could most of this just be a misunderstanding that got out of hand? However when I read that it definitely feels to me like a legal threat, but maybe it was just a well intentioned question that wasn't well phrased?

39 sats \ 0 replies \ @theariard OP 3 Mar

"hey I don't know if this is legally acceptable with this software license maybe we should ask a lawyer

I had especially in mind the CSW’s database case, where CSW is making claims based on a sui generis rights recognized by the EU laws.

Whatever we can think of the EU laws legitimacy in this area, seeing how they can be leveraged against the interest of the Bitcoin ecosystem, especially we should be more careful of marking “original work” in critical Bitcoin areas the public domain. Systematically closing the doors to future CSW’s like judicial contests.

reply on another page

160 sats \ 0 replies \ @premitive1 27 Feb

Comes off as more of a warning to potential liability than a threat.

reply on another page

0 sats \ 1 reply \ @anon 27 Feb

To make clear is this correct: the proper understanding is the OP received a Cease & Desist Letter in 2017 from Chaincode. Separately also now in 2024 OP is also saying lawyers need to be consulted - but not directly threatening legal action or sending a letter directly from a lawyer? Sorry this is hard to follow. Just trying to get this straight. Not trying to give anyone a hard time.

169 sats \ 0 replies \ @theariard OP 3 Mar

The year I received a cease-and-desist letter from Chaincode was 2023 (last year) not 2017.

170 sats \ 0 replies \ @theariard OP 3 Mar

For full clarity towards the general pleb public.

I have never sent a lawyer letter to AJ Towns, neither threats him in private to take this course of actions.

However, I did receive lawyer’s letter in the past from some bitcoin core development organization for matters related to development. See one of my post above about March 2023 mailing list event. I think I made it very clear it constituted a break of “good faith” communications in the community.

I’ve never receive from them formal excuses for such conduct of actions leading to a "CWS-esque” situation as you said so. Neither invitation to clarify our misunderstanding on the appropriate channels.

0 sats \ 2 replies \ @StoneCodlHodl 28 Feb

I will speak for most people here: FUCK LAWYERS - most politicians are former lawyers - politicians write the laws which lawyers rape the citizens are judged with. And all judges are also former lawyers.

This is ->THE<- reason why Bitcoin devs should work only via a pseudonym. Keep writing code laws can't touch.

25 sats \ 1 reply \ @theariard OP 3 Mar

what do you do if you have an opsec failure and your pseudonym doesn’t bind? better to have defense in depth ready.

0 sats \ 0 replies \ @StoneCodlHodl 3 Mar

100%. If you are wise; you adopt a page from the governmental mafia: A fully separated and hardened device, and network (Tor/VPN/??), for your clandestine ops. This need not be a high cost device - it's not your daily driver.

1975 sats \ 17 replies \ @BitcoinErrorLog 27 Feb

https://m.stacker.news/17791

1252 sats \ 15 replies \ @nerd2ninja 27 Feb

To the contrary. Users are asking for better LN experiences that handle force closers better and ease channel open tx fees and liquidity management issues.

TX batching works well for the channel open tx issues, covenants via timeout trees as detailed by John Law can help with both onboarding with the initial channel open and a graceful exit, and eltoo (which can be enabled with APO or CTV + CSFS both methods being covenant enabling) help to smooth out the force closure issues which in turn helps to build out multi-party channels which help with liquidity management issues.

Now that's all to say nothing about delving bitcoin. Is it a mechanism to subvert the perception of consensus proposals? That I'm merely reading this thread and observing to find out. It's outside the scope of my criticism of your post which is simply a laser focus on the idea that users aren't asking for covenants.

154 sats \ 0 replies \ @theariard OP 1 Mar

Sibling eviction breaks current LN stuff from my technical analysis. Thats’s the thing mempool policy have become so much complex so unless you have cross-layer expertise, it’s become very hard to give a fully fledged out analysis of technical correctness and trade-offs.

10 sats \ 8 replies \ @premitive1 27 Feb

"users" don't understand how lightning works at all, so they certainly aren't asking for particularl technical changes to address what they are asking for.

435 sats \ 1 reply \ @nerd2ninja 28 Feb

Yes, you're right and not only that, they're scared of changes right now, which is why patience (likely years of it) and presentation of facts is important. They are however complaining about the things I mentioned. I only say that covenants are one way of doing it and wouldn't be so closed minded as to say its the only way. If you have other ways of doing it (that don't compromise rehypothecation risk, theft risk, or censorship risk to unreasonable degrees), I'd want to read on it.

39 sats \ 0 replies \ @theariard OP 3 Mar

covenant is probably a good thing on the long-term. however getting covenants are hard to get right. saying this as someone who spent a lot of time doing reviews on covenants over the past years.

247 sats \ 5 replies \ @ek 27 Feb freebie

Users = node runners in @nerd2ninja's case I believe.

487 sats \ 0 replies \ @nerd2ninja 28 Feb

Even then he's still right. Lots of node runners don't understand the particulars of technical changes.

100 sats \ 3 replies \ @premitive1 27 Feb

I appreciate the clarification. This whole thread demands further attention and consideration to who are stakeholders in bitcoin, and the relationship all different levels of the ecosytem interact with each other. Things seem to be getting extremely contentious.

40 sats \ 1 reply \ @ek 27 Feb

I agree. You seem to be making the same point as Peter in the Shinobi episode of WBD, so you might want to listen to it if you haven't already.

71 sats \ 0 replies \ @DiedOnTitan 28 Feb

Thanks for the link to WBD...That led me to another twist in the rabbit hole. Now reading BIP-119.

39 sats \ 0 replies \ @theariard OP 3 Mar

Me, I’m answering questions towards the plebs.

In my opinion, if someone should clarify its relationships with other stakeholders in the ecosystem, it should be this guy (morcos @chaincode.com). While I think a lot of people appreciate what he’s doing with the BDFL, given the secrecy which is surrounding legal matters by design, it could be fruitful to have ethical guarantees such as “we’ll never defund or threat to defund a developer defendant lawsuit solely because you’re raising concerns about how we contribute to Bitcoin Core”.

AJ Towns himself makes that “don’t bite the hands that feeds you” concern years ago on his blog platform.

Due to familiarity with all-kind-of-things-law matters, I’m far more chill than a lot of developers in matters of being threats by lawsuits including by billion-powered entities, including defending myself on my own means only if I have to.

That said, this is not the case of a lot of other devs, I think.

Alex is a single-digit billionaire so he can be busy to answer you. From my experience he’s always done to discuss, if you ask nicely.

1 sat \ 4 replies \ @oomahq 27 Feb

I run my own CLN node and for now I'm fine with everything as it is, thank you.

10 sats \ 2 replies \ @nerd2ninja 28 Feb

This has become a rare thing to see someone write these days, but noted.

0 sats \ 1 reply \ @oomahq 28 Feb

I spun mine up in mid 2022. Back then there was a fledging community of LN hobbyist node runners, but the spam has mostly killed that off.

0 sats \ 0 replies \ @nerd2ninja 28 Feb

Back then I was reading people saying there was no need to use LN because the on-chain fees were too low to make them care enough to try it. I knew things would go in the other direction back then, even if the particulars for why are different each time.

0 sats \ 0 replies \ @fishyness 28 Feb

deleted by author

0 sats \ 0 replies \ @oomahq 27 Feb

This aged well.

1765 sats \ 2 replies \ @anon 27 Feb

Personally, I’ll stop engaging or contributing on Delving Bitcoin [...]

the same way you stopped engaging and contributing to LN? lol

100 sats \ 0 replies \ @oomahq 27 Feb

Who are you.

0 sats \ 0 replies \ @BitByBit21 27 Feb

I see a pattern there

832 sats \ 3 replies \ @1440000bytes 27 Feb

Where is the legal threat that everyone is talking about?

604 sats \ 1 reply \ @BlueSlime 27 Feb

"Lack of publicity might be jeopardizing the MIT / Apache 2 license and the de facto entrance in the domain public of Bitcoin design ideas."

I think this is what is being referred to.

77 sats \ 0 replies \ @theariard OP 1 Mar

Yes, MIT / Apache 2 license have been designed ~20 years. Not necessarily the best tools to protect the openess of Bitcoin domain public against external actors like CSW.

77 sats \ 0 replies \ @theariard OP 1 Mar

On my side I’m talking about the last year ones shared on the lightning dev mailing list.

I don’t understand the AJ position, I did offer to clarify my words on Delving Bitcoin though he did opted to censor my post instead. I think AJ is free to post on stacker.news here or on another thread to clarify his position.

1827 sats \ 2 replies \ @nout 27 Feb freebie

Here are the original posts backed up: https://github.com/jamesob/delving-bitcoin-archive/blob/master/archive/rendered-topics/2024-02-February/2024-02-22-workgroup-lifecycle-id598.md

It seems that @theariard mentioning that lawyers should be consulted is what triggered the response from AJ Towns, but I can't rule out "being a dick" on either side as the cause either... Quote:

At the very least, people engaging in such private communication channels should consult lawyers in the main major juridictions, if such communication practice is not specially tainting their responsibilities in case of future FOSS software defect in some way.

0 sats \ 0 replies \ @theariard OP 3 Mar

See what I said above:

"I had especially in mind the CSW’s database case, where CSW is making claims based on a sui generis rights recognized by the EU laws. Whatever we can think of the EU laws legitimacy in this area, seeing how they can be leveraged against the interest of the Bitcoin ecosystem, especially we should be more careful of marking “original work” in critical Bitcoin areas the public domain. Systematically closing the doors to future CSW’s like judicial contests."

0 sats \ 0 replies \ @premitive1 27 Feb

Because if one outcome of such working group is this bitcoin/bitcoin#29319, this is a complete design process failure, given some of the mechanisms are either weak (v3 policy) or apparently useless (sibling evictions to remove CPFP carveout).

While we cannot prevent private communications among members belonging to and funded by the same development entity, I think we should socially discourage private communication channels about FOSS software among members of different development entities. Lack of publicity might be jeopardizing the MIT / Apache 2 license and the de facto entrance in the domain public of Bitcoin design ideas.

At the very least, people engaging in such private communication channels should consult lawyers in the main major juridictions, if such communication practice is not specially tainting their responsibilities in case of future FOSS software defect in some way.

838 sats \ 4 replies \ @03479d0ee6 27 Feb

I'm an outsider I'm not involved in any of these Bitcoin and PR discussions, but I think other node implementations should arise based on Core, for people to decide what to run and support. Being dependent on a small group of devs to decide what to commit doesn't seem good.

10 sats \ 1 reply \ @oomahq 27 Feb

There is (at least?) one. @lukedashjr has been maintaining his own modded releases of Bitcoin Core for more than 10 years, with all the features and fixes he believes should have made it into Core.

It's called Bitcoin Knots.

189 sats \ 0 replies \ @03479d0ee6 27 Feb

Yes, I know. Core still needs more competition, and Core should probably be the most conservative implementation.

0 sats \ 0 replies \ @theariard OP 3 Mar

the libbitcoin kernel project should dramatically change the dynamics. without having to re-write a full-node implementation, you will be able to write consensus-valid validation bitcoin software for all kind of things.

0 sats \ 0 replies \ @03bebce944 28 Feb

deleted by author

693 sats \ 1 reply \ @k00b 27 Feb

As Pieter Hintjens (the Zero MQ creator and a FOSS veteran), put it in one of his book on the necessity of transparency in FOSS.

I hadn't encounter this book before. Thank you!

121 sats \ 0 replies \ @theariard OP 1 Mar

Yep, the ZeroMQ guide is a jewel to design distributed systems: https://zguide.zeromq.org/docs/preface/

850 sats \ 5 replies \ @anon 27 Feb

At the risk of being horribly cliche, it sounds like Nostr probably fixes this. Also as a humble pleb I have no idea wtf is going except that I'm not upgrading my node anytime in the near future until this dust is settled and may even revert back 1-2 versions. Can anyone provide a left side of the bell curve explanation and steel man both sides please?

1 sat \ 3 replies \ @_vnprc 27 Feb

I do not recommend skipping upgrades or reverting your node version. At a minimum you should use the latest node version that receives security backports. Some rare critical security fixes are hidden in plain sight for good reason.

11 sats \ 2 replies \ @premitive1 27 Feb

so perhaps the solution is to upgrade to non-core implementations that remove the bugs while maintaining security fixes. The WHOLE point of this post is that OP argues core devs are creating backdoors for exploits.

122 sats \ 1 reply \ @_vnprc 28 Feb

If you don't trust the development process then your only options are to run old software or manually audit the codebase. I don't think running old software will protect you from malicious code injection. This attack vector doesn't work by stealing your coins directly, instead it weakens trust in the whole bitcoin ecosystem and crashing the price. It doesn't matter what node software you run when your bitcoin buys you less goods and services than it used to.

As for actual long-term fixes to this problem you should look into libbitcoinkernel, it will enable a plurality of consensus compatible bitcoin node implementations.

39 sats \ 0 replies \ @theariard OP 3 Mar

yes all points that make sense. that things like libbitcoinkernel or p2p stack could benefit from longer-term security backport would be a good thing. however in terms of bitcoin core codebase modularization we’re not there yet.

0 sats \ 0 replies \ @theariard OP 3 Mar

Nostr probably improves this.

I think we’re still years (half-decade ?) ahead of dev experience matching what is offered by GH, assuming Nostr moves in the good direction (which I hope so!).

Also as a humble pleb I have no idea wtf is going except that I'm not upgrading my node anytime in the near future until this dust is settled and may even revert back 1-2 versions.

Spend more time becoming more technical by yourself. Don’t trust the devs on the face value of their technical statements. Always verify. When you have established developers disagreeing among themselves in the public, spend even more time verifying their statements.

308 sats \ 0 replies \ @theariard OP 1 Mar

okay already replied to a lot of comments - i did the non-anon first as people are speaking with their own stacker.news accumulated reputation at least. i’ll see to do the others in the future.

ultimately, bitcoin FOSS development it’s like ~30 people in the world, and folks have different conceptions of what bitcoin development process should looks like, and the standards of communication behaviors among them.

it’s good to take time to talk about it, at the very least if it can saves uses inflation bugs or block size war situations in the future.

personally, i do have the level of domain expertise to judge technical soundness by myself of bitcoin, lightning and other things, including the dirty parts like secp256k1 or networking.

754 sats \ 1 reply \ @BITC0IN 27 Feb

could you expand more on this and be more specific about your concerns: "I did notice that code design and proposals were abnormally vulnerable to some class of attacks to target Bitcoin use-cases"

155 sats \ 0 replies \ @theariard OP 1 Mar

All transaction-relay jamming attacks against Lightning nodes. Google things like pinning and replacement cycling. While experts have divergent opinions on severity and exploitability, none to the best of my knowledge have demonstrated their implausibility.

1817 sats \ 5 replies \ @anon 27 Feb

This you:

If I estimate myself victim of being harassed by your behavior or you’re overriding your janitorial role in the maintenance of this communication plateform, please be known there is always the ability to pursue remediation in front of the Australian authority or any other competent one.

613 sats \ 1 reply \ @petertodd 27 Feb

The interesting thing is @theariard allegedly said that after he was incorrectly accused of making legal threats by @ajtowns. Not before. Reads quite differently in that context: obviously people always have the ability to get the law involved.

I say allegedly because those archives are unsigned and untimestamped, so we're trusting a bunch of people with interests in this discust that all this is actually correct. @theariard should clarify if the archived message really was written by him.

77 sats \ 0 replies \ @theariard OP 1 Mar

Yes this is very clear I do have a vested interest in the discussion. So don’t trust me, verify.

I cannot assert on the archived message correctness as I can't consult it from an external public URL (as of block 832728 - 00000000000000000001349107f838fb193dda1fc5395c45548f8cb6f30cfc5d).

One that could be OTS e.g. I have not verified if AJ is technically able to un-archive my post for everyone publicity.

725 sats \ 0 replies \ @anon 27 Feb

source

66 sats \ 1 reply \ @anon 27 Feb

LMAO - ragequit engage

0 sats \ 0 replies \ @theariard OP 3 Mar

there are sane angers, when you think the process is broken.

at least it’s good to slow down and take time to explain why you think things are broken, and do a honest attempt to fix them.

512 sats \ 0 replies \ @Lumor 27 Feb

Discourse doesn't give other users the "View ignored content"-link. :/

5353 sats \ 4 replies \ @Murch 28 Feb

Dude, you keep suggesting that your discussion partners are unqualified or malicious. You recently indicated that you do not want to collaborate. You've repeatedly announced that you are calling it quits. As it is, nobody benefits: I'm sure I'm not the only one that has stopped reading your wall-of-text comments because they're so hard to parse and so often not relevant.

There has been drama with you at the center at least three times in the last couple years. The common denominator doesn't seem to be the other people. If you don't want to be here, why don't you at least take a break until you feel better?

207 sats \ 0 replies \ @theariard OP 1 Mar

Murch - If you have a mental breakdown you’re free to apply your own advices and take vacations or ask a sabbatical to your own employer.

Personally I would understand, I’ve never seen you involved in time and operationally constraints technical actions in the Bitcoin space, e.g security-coordination disclosure neither seen any CVE you could have submitted yourself (my memory might be incorrect you’re free to correct me or points me to some stack overflow post ?).

As a former employee of some of said discussions partners myself, I could pointed out to dramas over more than three times over more than the last couple of years, where they are a common denominator.

305 sats \ 2 replies \ @Murch 28 Feb freebie

As I read the V3 PR, the issues that were brought up there were not introduced by the proposal but just not fully resolved by the PR alone. A few points seem also completely out of scope, more related to the LN spec than the proposed changes. Generally there was a lot of noise in this PR. I would recommend that anyone in this thread who is developing strong feelings actually go and peruse the PR. IMHO, the amount of low-signal noise produced by two of the reviewers of enough to drive away most other would be reviewers—I know because it did that to me, when I looked the PR over to see whether I could help with review. Ain't nobody got time to read all that.

Either way, those PRs are part of a bigger project that is still work in progress. V3 transactions are still non-standard, and more PRs are to be deployed before these rules even become active. The three "unprofessional reviewers" have spent a lot of time in the last months honing the related proposals with the PR author and are highly qualified to review the changes.

Given that the rules aren't even active...

Regarding cluster mempool: redesigning the mempool is a big endeavor. So, picking some brains to check whether the idea is even a significant improvement, feasible and worth the effort before getting everyone unnecessarily excited seems completely reasonable. That brainstorming involved a bunch of transaction graphs and feerate diagrams, so forum software was expedient to discussing the idea. Within a few weeks, the same threads were set to being publicly readable, as the idea seemed worth exploring further. Since the posts are now all public, I'm not sure where a discussion about introducing a backdoor is supposed to be hiding.

I for one am pretty sure that it's not mandatory for Bitcoin Core contributors to publicly share their every crazy idea as it pops into their head. I'd even go so far that some might want to do a little more pondering before they do.

223 sats \ 0 replies \ @theariard OP 1 Mar

On v3 transactions the three ‘unprofessional reviewers” are free to deploy v3-enabled bitcoin infrastructure to back up their reviews with real-world demonstrations as I did invite them to do so before the PR merge.

Time spent reviewing and working on the PR is not a convincing argument. Let’s all remember OP_EVAL.

Within a few weeks, the same threads were set to being publicly readable, as the idea seemed worth exploring further.

I’ll let you comment on the “fait accompli” as I’m pointing out in Pieter Hintjens book. Given the technical complexity of the mempool at the very contrary on my side all the discussions should be public. I did pointed out on the original cluster mempool issue (#27677) all the potential interactions with other parts of the ecosystem (miners, LN, L1 on-chain users) that I think the designers of cluster mempools are not completely mastering themselves.

I for one am pretty sure that it's not mandatory for Bitcoin Core contributors to publicly share their every crazy idea as it pops into their head. I'd even go so far that some might want to do a little more pondering before they do.

It’s not mandatory to share every crazy idea in public, yes. However with cluster mempools we’re very far from this “soundness” threshold as it’s already been presented in a restrained circle few core dev a while. Why more secrecy about this project ?

0 sats \ 0 replies \ @Murch 28 Feb

:s/of enough/is enough

2394 sats \ 2 replies \ @anon 27 Feb

If long-time contributors from different organizations and affiliations are asking you to stop sending hundreds of comments and straying from topics, it's not a conspiracy.

You are always welcome to stand-up your own communication platform that you feel is more fair but in absence of that, maybe it's time to take an actual sabbatical this time and turn your talents to something where you'll be more appreciated.

1 sat \ 0 replies \ @petertodd 1 Mar

If long-time contributors from different organizations and affiliations are asking you to stop sending hundreds of comments and straying from topics, it's not a conspiracy.

You misread that comment. It is not saying @theariard has been posting hundreds of comments. It's referring to the hundreds of comments in general from all commenters.

0 sats \ 0 replies \ @theariard OP 3 Mar

About instagibb’s comment is not like himself has recognized the value of my technical observations w.r.t soundness of its own pet project in a different context, ephemeral anchor (cf. https://delvingbitcoin.org/t/ephemeral-anchors-and-mevil/383).

So I’ll let Greg Sanders explain himself here on the present case. Apart of the present divergence, he’s someone I respect professionally in Bitcoin.

On the call to take a sabbatical, look what I said in my sabbatical announcement post.

"The open feud with some people at Spiral and Chaincode, whatever significant are their contributions to bitcoin. Those people had my trust and confidence, they broke them and I’m not Mother Teresa. This has been ongoing since almost 2 years now, I guess this will take as long or even more to solve and I prefer to allocate the best of my time and energy to arrange a resolution satisfying everyone. Long-term principles at stake concern every other open-source dev.”

I’ll let you observe by yourself to what organizations belongs the people I’m pointing out the standards of behaviors in my post.

Apart of them, my talents stay widely appreciated among the remaining on the Bitcoin space. At least easy to say more than yours anon ?

181 sats \ 7 replies \ @nicosey 28 Feb

Why not write some code to prove your thesis? Talk is cheap as they say...

77 sats \ 6 replies \ @theariard OP 1 Mar

I did write a functional test on the sibling eviction PR to bake my claims actually. Branch is here: https://github.com/ariard/bitcoin/commit/04fdc0a77f70a998a433a3839c807422bc2e3bfa

And I did propose on the v3 PR before the merge to do a real-world test on the mitigations on a signet deployment. The “professional” reviewers and the maintainer did prefer to merge.

Talk is cheap, code costlier, deep security flaw in Bitcoin even more expensive.

0 sats \ 3 replies \ @nicosey 4 Mar

Code is costlier, but you need consensus and that I am afraid is harder to get and only working examples with proofs will stop what you may see is political...

0 sats \ 2 replies \ @theariard OP 4 Mar

Certainly consensus code is very costly in itself. However mishandled security failures are even more expensive on the long-term, e.g TheDAO hack and the moral hazard culture this generated in ETH.

Of course, this is always an option to go to publish a pinning toolkit and see the Lightning ecosystem jeopardized. In those matters it’s always good to have ethical self-restraint and respect a strict boundary on how much sensitive information you reveal.

0 sats \ 1 reply \ @nicosey 4 Mar

I think that would be a good idea. It would raise awareness into the area and force investment into research.

Without that you get these debates, which ultimately are decided by politics and ones ability to debate...

200 sats \ 0 replies \ @theariard OP 5 Mar

I’ll go to hack a pinning toolkit, the easy pinnings it’s not that much work.

0 sats \ 1 reply \ @1440000bytes 3 Mar

PR authors are expected to respond to all review comments before merge: https://github.com/bitcoin/bitcoin/blob/2649e655b9203d6d08cb1a26fa4846f2c403b297/CONTRIBUTING.md#address-feedback

Maintainer (achow in this case) should step down if PR really introduced vulnerability

0 sats \ 0 replies \ @theariard OP 3 Mar

In my opinion, this PR is pretending to fix Lightning vulnerabilities, while in fact it lets wide area of attack surface opened.

Sadly, you have to be a cross-layer expert to understand this and I’m not even sure the v3 PR reviewers sufficiently understood what they were reviewing and I did ostensibly call to test more this change. So it sounds like pure “security theater” in my opinion.

“Gradient" solutions are rarely acceptable in network security, as you’re just increasing the re-deployment costs for any future full and sounds mitigation.

I have not seen achow commenting in public on this decision merge.

Overall, calling to have achow stepping down is disproportionate, achow is one of the most reliable maintainers in my experience. However, having achow explaining more this merging decision in the present case would be very welcome.

651 sats \ 3 replies \ @anon 27 Feb

Have you considered whether almost all of your posts in the past three years being off-topic, unproductive, and outright incomprehensible as well as generally behaving like a huge dick might have something to do with people ignoring your comments?

116 sats \ 0 replies \ @oomahq 27 Feb

Pretty interesting that virtually all comments with this tone are being posted anonymously.

40 sats \ 0 replies \ @premitive1 27 Feb

So being a dick excuses implementing bad code, or you're not conceding that point?

0 sats \ 0 replies \ @theariard OP 3 Mar

hello anon:

a) off-topic, i’ll make the call myself
b) unproductive, not so much if look on the matters of fixes / ideas adopted by other devs
c) outright incomprehensible, you’re free to engage politely and ask what is incomprehensible

on being a dick, yes the brilliant jerk syndrome. i don’t know a bitcoin security legend who has not been accused of being a dick with its communication style. time is limited and so many vulnerabilities to hunt after.

396 sats \ 4 replies \ @Fabs 28 Feb

I've never seen so many "anons" in a single comment section on SN, anyways: as far as I can tell, there seems to be malicious efforts being made to include backdoors into Bitcoin Core, most likely allowing core devs- as well as any other actors that happen to stumble upon said backdoors to exploit the protocol in one way or another, if the changes make it into Core, correct?

What are possible ways that one could deal with the possible threats as described by OP, and what are the chances that this will unfold into a bigger mess?

77 sats \ 0 replies \ @theariard OP 1 Mar

Technically, in the present state of Bitcoin Core 0.27 codebase I would say it allows you to wreck a Lightning node, if you know where to hit.

Exploiting base-layer it’s a different topic, though if you can massively target Lightning nodes, not good for stability of miner incomes.

1105 sats \ 1 reply \ @TonyGiorgio 28 Feb

Most of the anons are all 100% correct and justified. The amount of total shit being blasted by a maniac that needs to step back and get help is ridiculous. Any person that has publicly and/or directly tried to talk and listen has been targeted by the OP eventually. So why engage publicly anymore? He's burned all trust or civility.

It's all one giant boy who cried wolf story over the last few years and people are fucking sick of it. The title of the post itself is malicious and blown over the top.

374 sats \ 0 replies \ @theariard OP 1 Mar

Hi Tony, I remember you to thanks me in-person for my Lightning security works at TAB Conf 2022, after or around my panel on this subject, am I correct yes or no ?

11 sats \ 0 replies \ @Murch 28 Feb

Aww come on, does this really pass the giggle test?

21 sats \ 0 replies \ @anon 28 Feb

Thanks for letzing us know

67 sats \ 1 reply \ @anon 27 Feb

I'm extremely turned off by anyone threatening legal involvement in an open source project. This wreaks of CSW. Pleb question: is this a legit concern or is this the ord_disrespector crowd raging they aren't getting their way?

0 sats \ 0 replies \ @theariard OP 3 Mar

In my opinion, the concern is we have a subset A of developers being involved in the defense of a subset B of developers while the same subset A making legal threat to another subset C of developers.

So I think we need a clarification, either it’s not okay to have legal threats among developers, or it’s okay in function of whom is making the threat. Second alternative doesn’t look to fly in terms of ethics and principles, I think.

0 sats \ 1 reply \ @IanMalcolmPhd 18 Mar

This is not good. For future changes that get ramrodded through (with potential vulnerabilities as @theariard has suggested), consider making them public and read only for the non members.

42 sats \ 0 replies \ @theariard OP 21 Mar

Yes - Bitcoin FOSS flourished by transparency and peer-to-peer, grassroots dev.

0 sats \ 1 reply \ @02e5638cc5 28 Feb freebie

...and then deleted my post (cf. the screenshot)

What did you say exactly in the deleted post?

...and I seriously wonder if a subset of contributors are not engaged in deliberately inserting backdoors to defraud or hypothetically get technical leverage on user funds in the future, for any kind of political move.

Do you have any evidence that leads you to believe this other than the fact that they were designing new proposals in private discussion rooms?