Topic: Implementation of push / auto update feature on bitcoin (per configuration) (Read 2597 times)

NAK's in the blockchain don't need to be exclusive though. For instance the protocol can be that NAK's are just some signed data, and you don't care how you get the data. For some scenarios putting it in the blockchain is great - the dev team goes crazy and backdoors the RNG - for others you're going to have to hope some other jam-proof communication mechanism works, like P2P distributed alerts or DNS seeds or whatever.

The big advantage of the blockchain is that many attacks aren't going to be very useful unless the target is synced with the network. Someone might, say, backdoor the RNG or make transactions be signed using nonces the attacker can predict. But users whose clients do manage to sync with the network will see the alert and not upgrade, and the ones that don't (because the attacker isolated them) are likely to do fewer transactions because they notice their client is acting funny and tx's aren't confirming or whatever.

Obviously the attacker could also fake parts of the GUI to make it looks like tx's are confirming, but now the number of lines of code they need to hijack just got even larger, making the attack even ever to spot.

Perfect enemy of the good yadda yadda. The current alert broadcast mechanism would probably work OK for that. Hopefully it'd hardly ever be used. The difficult bit would be testing it in the real world.

I'm not sure that I'd want to promote mined transactions as a jamming resistant communications channel. Especially since, you know, it's not actually jamming resistant, and it's not hard to imagine examples where the miners would actually be interested in jamming NAKs on an update.

It's too bad we don't have some kind of data structure that is automatically replicated to all Bitcoin nodes, and has some kind of "fee/KB" mechanism to discourage spamming it.

An idea I find attractive is to have the ability to have signers who can only give "negative karma"— these keys could be issued pretty liberally, since the only risk is that they delay an update. This models what we already believe to be the primary existing source of assurance: "if something bad is done, someone somewhere will sound an alarm". Coupled with suitable delays this could be pretty powerful.

The tricky part is having a jamming resistant way to get their negative views out to people.

Yeah, we're heading away from a world in which programs are issued by one entity. The gitian work is pioneering - in future we'll see security critical apps like Bitcoin wallets, Tor and maybe entire operating systems go through reproducible builds with threshold signing quorums, distributed across many jurisdictions.

Matt's work had an auto updater that watched for the gitian signatures, therefore, it would take a quorum of signers co-operating to push a bad Bitcoin release. If it were really bad or controversial then people would notice and downgrade or switch to some other fork, but of course the network would have been running with the new rulesets for a small amount of time.

What I'd like to see is a hybrid model in which a large quorum (maybe 20-30 people) is required to sign for an auto update, and the people in that group agree to only sign for an auto update for security-sensitive fixes. The recent mod zero bug would qualify for instance, but fee changes wouldn't. Thus most upgrades would still roll out slowly, but if a buffer overflow or other way to compromise bitcoind was discovered the community could patch itself fast.

Incidentally, we've started work on reproducible builds for bitcoinj. It's not very hard fortunately, most of the issues are the same as for native builds (timestamps in the files, etc).

You do not have to trust the coder behind the binary.

The binary is proven to be a result of the published source code— provable by you yourself, or indirectly by many unrelated parties performing the check and publishing a certification of their result (which already happens today).  The source code is open, transparent and generally developed with an open process so that you, your designees, and/or the general public can audit it and sound alarms if it does something unwelcome or suspect.

Exactly my point. If you already have trust in the coder behind the binary, how trusting his auto update hurt you more than installing manually?

Given that Matt already submitted code to make Bitcoin-Qt easily auto update, I think saying "it means we're compromised" is rather extreme. Matt certainly isn't compromised. He also runs the Ubuntu PPA which is basically a form of auto update for bitcoinds.

I think where we'll end up is with the core bitcoind not having any kind of auto update, and the end user wallets all will. It's security sensitive software so it's pretty important for anything end user facing.

+1

I agree.
This is a very important quote.

All 'alt coins' fork from Bitcoin-QT, not multibit. And it's not a matter of recommendation. Bitcoin-qt is also available in bitcoin.org. And even if the majority of users use multibit (which I'm not sure unless numbers are brought up), it doesn't have a 'check new version' as well, and serious 0day exploits can lead to losing wallets, coins, address collision attacks, etc

Well, since bitcoin.org is recommending Multibit anyway, it doesn't really matter if Bitcoin-QT has autoupdate or not.
The average user will not use Bitcoin-QT.

It's not a comment I made likely, nor is it a new one— I've made the comment many times in the past.

I'm not sure if you read the latter half of my response... since I directly speak to that.  I think there are possibilities in that space, but they are not so simple, because a simple delay does nothing if the discovery of problems cannot substantially block the updates.

This may one day become a historical quote. I think I will print it out using big letters and glue it above the screen of my computer.

Nobody said that the auto update would have to be fast.
You could have a delay of one day or two so that the experts can check the binaries first.

The easy answer then is for you to go ahead and implement the auto-update feature you are proposing, and then let the market decide if they want to use the fork that includes auto-update.

I believe that for the reasons stated above me in the thread that it is a bad idea, however since it is open source, anyone is welcome to add this feature to their branch and see how it competes with the non-auto update.

:-)

Not at all. I'm obviously failing to explain this to you, though I can't tell why. I'll let someone else have a crack at it.

gitian is an answer for people that know what they are doing (aka developers, system administrators, etc), that most of users of bitcoin-qt/daemon aren't. they download binaries from a link. unless it's implemented in the client itself, which I think would be overkill, they will just click a link and download. Plus, if you get this gist https://gist.github.com/devrandom/806265 it still uses sourceforge as a source, so it defeats the purpose anyway.


Well, you just contradicted yourself.

Its far more nuanced than you're making it out to be.

The binaries are directly tractable to the source code. The process that turns one to the other is deterministic, and multiple people (including people outside of the core development group) publish signatures signing that they got the same results.  This is what gitian does.  You can run this process yourself, and I think it would be great if you did.

The source code is transparent. Not everyone reads it, but many people do.  If something suspect goes into the source code, there is a pretty good chance that someone will call it out and sound alarms "do not install this!". ... and this is true if only a small number of people outside the core group are checking. This is only possible because they can check.

This audibility and transparency is essential.  But it's not fast. And if you have automatic update that are deployed faster than the loop can close— faster than the binaries certifications can be published, faster than people can review and alarm, then it would be centeralized then it isn't now.

I'd love to hear how you think the "NETWORK" could be decenteralized in any meaningful way if the software which makes up the network isn't.

That's a phrase that deserves to be quoted for posterity.