Pages:
Author

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

legendary
Activity: 1120
Merit: 1152
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.
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.

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.
legendary
Activity: 1526
Merit: 1134
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.
staff
Activity: 4242
Merit: 8672
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.
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.
legendary
Activity: 1120
Merit: 1152
The tricky part is having a jamming resistant way to get their negative views out to people.

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.
staff
Activity: 4242
Merit: 8672
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.
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.
legendary
Activity: 1526
Merit: 1134
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).
staff
Activity: 4242
Merit: 8672
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?
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.
member
Activity: 105
Merit: 10
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.

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?
legendary
Activity: 1526
Merit: 1134
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.
full member
Activity: 254
Merit: 100
If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

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.

+1

I agree.
This is a very important quote.
member
Activity: 105
Merit: 10
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.

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
hero member
Activity: 675
Merit: 514
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.
staff
Activity: 4242
Merit: 8672
It's not a comment I made likely, nor is it a new one— I've made the comment many times in the past.

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.
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.
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

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.
hero member
Activity: 675
Merit: 514
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.
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.
legendary
Activity: 4130
Merit: 1307
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.

:-)



We are in 2013, in the era of "browser apps" and self updating software, and all coins, even though coded in C++, have no reason to not have an auto update / push update feature for critical bugs / exploits / etc. How many people get stuck and clueless about new versions, since the Qt client have no "check for new version" button, unless they check the forums? It's understandable, for a pool owner, to not have auto updating software because it can break everything, so it could be disabled. But for the end user, there's no excuse.

Coin developers should try to get to a consensus and implement a simple hash version checking against the tags on github / sourceforge for example, at least to warn users about new versions (and even a distributed changelog / news about the new version, take a look at Filezilla that is open source)

Imagine having 16 coin clients installed on the computer, and manually having to check for new versions for each one? An auto-update makes sense doesn't it?
staff
Activity: 4242
Merit: 8672
it still uses sourceforge as a source, so it defeats the purpose anyway.
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.
member
Activity: 105
Merit: 10
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.

Quote
Quote
You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries,
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.

Well, you just contradicted yourself.

Quote
Bitcoin is a decenteralized system and is staying that way.
staff
Activity: 4242
Merit: 8672
Right, the auto update / push feature "vulnerability" makes sense now, even though, by downloading it, you are already trusting a binary and/or source code, otherwise Bitcoin wouldn't exist, [...] the source is already centralized either on github or sourceforge, if you want to see it that way.
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.

Quote
You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries,
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.

legendary
Activity: 1400
Merit: 1013
If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
That's a phrase that deserves to be quoted for posterity.
Pages:
Jump to: