The duplicate input vulnerability shouldn't be forgotten

[aliashraf]

Don't want to disturb you guys, but this train looks to be pretty much derailed. I know it is always a good idea to ask companies to contribute more, but is this all we got? Isn't it somehow underreacting to double input bug story?

Also, I think it is not helpful either to say "don't tell others what to do, tell us what are you going to do for your country blockchain". We need to discuss technical aspects of the issue.

[1715512406]

1715512406

[1715512406]

1715512406

[buzztiaan]

Maybe it's time to promote more Bitcoin Knots and other node software that is not Core? Seems to me like having multiple implementations that are not forks of another another will provide a resilience against bugs.

* http://bcoin.io/
* https://libbitcoin.dyne.org/
* https://github.com/btcsuite/btcd/
* https://bitcore.io/

i'm sure you can find more on your own

[Lauda]

AFAIK, blockchain.info has hired 1 employee (although I can't recall which whop) and there was a Xapo listing for a Bitcoin Core developer some time ago (I'm not sure what happened with that). Other than those two, I haven't seen other examples of companies doing this.

Last I heard, Sjors Provoost works for Blockchain.info, Anthony (AJ) Towns works for Xapo, and Jim Posen works for Coinbase. Blockstream employees Pieter Wuille, Jorge Timon, Gregory Sanders, and several other contributors (plus two C-Lightning devs)  Several companies also help support the Media Lab's Digital Currency Initiative (DCI) that employees Wladimir van der Laan and Cory Fields (as well as several other open source Bitcoin contributors who don't normally focus on Bitcoin Core).

The other major source of employment for Bitcoin Core work is ChainCode Labs.

(I could be forgetting some companies; if so, sorry.)

I thought it was Sjors, but I didn't want to spread potentially false information as I wasn't completely sure. Well yes, Blockstream is implied for everyone who's been around for a while (hence why I didn't mention it). I guess it wouldn't be bad to keep a list like this somewhere; maybe the community could create some pressure in order to get other big companies to at least hire 1 person to work on the reference implementation. This also helps with *development decentralization* (me recalls the bcash nonsense 'Blockstream = most commits' or w/e).

* https://bitcore.io/

"Bitcore™ © BitPay, Inc. Bitcore is released under the MIT license." Stabbing my eyeball with a fork would be more pleasant than using an implementation made by a malicious actor.

[pooya87]

* https://libbitcoin.dyne.org/

the website doesn't contain any link to source code apart from a broken link called "git repository" which leads nowhere. using google i found https://github.com/libbitcoin/libbitcoin which seems to be a library not an application (full node implementation) and it is in C++ so i wouldn't be surprised if most of it was copy of bitcoin core code.

* https://bitcore.io/

last commit belongs to Nov 23, 2017! it doesn't seem that active either.

[byteball]

...
Firstly, it implies a new kind of consensus system, with no theoretical support. I'm not aware of any serious work covering a decentralized consensus based system that uses heterogeneity of implementations as a main or auxiliary security measure e.g. for immunity against software bugs.

What if there were special research labs running a few implementations each, e.g. GoLang, Java, Python, pure C (is there one?) with a human deciding which chain is correct? When nodes disagree with each other, they send alert to an operator on duty, operator wakes up, fires up his/her laptop, investigates and warns the community about potential split.

I have no idea how such service could be monetized or rewarded. They can get fame, using that fame for their own projects, or they can get donations from whales or from big Bitcoin businesses.

[amishmanish]

Awesome discussion. My head is swirling from all the information so I'll do my part to ensure that, as the topic suggests, the duplicate input vulnerability is never forgot!!

The Seventeenth of September

Remember, remember!
The Seventeenth of September,
The DoS vul'bility and Inflation fault;
I know of no Reason
Why the 0.15 to 0.16.2 season
Should ever be forgot!
 
 

Inspired by the inimitable Folk verse. Thank You. Now I shall go back to wondering when, if ever, I'll be able wrap my head around bitcoin! 

A seemingly presumptuous, non-technical observation: Cobra should realize that Greg seems to have enough respect for him and he shouldn't construe his zen'd out insights as insulting. Nobody is insulting anyone. Lets just stand together. Cheers to everyone!

[hobbes]

Separate the networking part from wallet and GUI to reduce complexity.

Maybe the alert system could be modified to only warn the user with a predefined warning to go check the news because something is going on.

[cellard]

Separate the networking part from wallet and GUI to reduce complexity.

Maybe the alert system could be modified to only warn the user with a predefined warning to go check the news because something is going on.

Interesting.. a hardcoded generic message that says "go check the news" could be helpful, however, who has the keys? it should require the signature of several trusted developers to guarantee they aren't all compromised, at least 10 signatures for safety imo, with developers that live in different timezones.

And still an attacker with enough resources could buy enough media to fool the public and use the generic message for their agenda. See this in action:

https://www.youtube.com/watch?v=_fHfgU8oMSo

It's not clear to me if the alert system does more harm than good or not. Ideally we just want to avoid these bugs. Lowering complexity is always welcome in Bitcoin... it just needs to store keys safe and not screw up during transactions, the rest is an extra. Of course, easier said than done, but as far as I know some of the "super minimalist" clients weren't affected by this bug, so "bitcoin minimalists" scored another point.

[DooMAD]

Maybe the alert system could be modified to only warn the user with a predefined warning to go check the news because something is going on.

The alert system wasn't only disbanded due to concerns over who could send what message, but also because of a potential vulnerability involving DoS attacks on full nodes:

All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage.

I don't think they're in any hurry to bring it back in a slightly different guise.  There would be a certain irony if we inadvertently introduced new security risks while attempting to safeguard against potential future security risks.

[theymos]

Maybe the alert system could be modified to only warn the user with a predefined warning to go check the news because something is going on.

I suggested something like that previously.

I do think that some alert system would be good, though the old alert system's propagation method and especially its single-key authentication was really bad, so I don't mourn its loss specifically. A new system could work by polling DNS TXT records + signatures (eg. alert.bitcoincore.org.    TXT    "predefined_alert=2 time=... sig=ABCD+/012..."), with many domains+keys controlled by many people and perhaps a requirement that at least a few of them agree before displaying an alert.

[aliashraf]

Isn't it more about prevention rather than cure?

And for the cure, I don't get it how an alarming system would help? Actually it seems to me as a source of even further risks. I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.

[Lauda]

Isn't it more about prevention rather than cure?

And for the cure, I don't get it how an alarming system would help? Actually it seems to me as a source of even further risks. I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.

A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though.

[hobbes]

(...)
I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.

A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though.

At least for alternative implementations for monitoring it is the way to go.

Could you elaborate on the drawbacks?

[Lauda]

(...)
I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.

A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though.

At least for alternative implementations for monitoring it is the way to go.

Could you elaborate on the drawbacks?

ryanofsky is working on process separation as seen here: https://github.com/bitcoin/bitcoin/pull/10973. Here are his slides regarding process separation: https://docs.google.com/presentation/d/1AeJ-7gD-dItUgs5yH-HoEzLvXaEWe_2ZiGUUxYIXcws/edit#slide=id.p. Look at page 6.
Reviewing the node code would be easier if it was completely separated from the GUI and wallet code (there would be noticeably a lot less lines of code to go through). I'm not sure if the end goal is complete separation though.

[aliashraf]

Isn't it more about prevention rather than cure?

And for the cure, I don't get it how an alarming system would help? Actually it seems to me as a source of even further risks. I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.

A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though.

Good point to start from, more radical changes would be necessary tho.

I'm thinking of a complete rewrite by both employing loose coupling and revisioning in bootstrap-from-genesis  policy and relaxing down-to-big-bang compatibility requirements. Thanks for the links  by the way.

[zheniasom]

I agree with DooMad completely. Diversity is the only real solution to network security.

We have to deal with the fact that bugs are found in absolutely ALL software.
Only thing we can hope is that it is: A) rare that bugs are found in all software at the same time and B) that no single entity will likely have all of these bugs at that time.