By the way, I have a download of the Bitcoin-Qt client and signature
verification running in a cron job.
On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn wrote:
> My general hope/vague plan for bitcoinj based wallets is to get them all
> on to automatic updates with threshold signatures. Combined wi
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at
> Users will have available multisig addresses which require
> transactions to be signed off by a wallet HSM. (E.g. a keyfob
Hardware is a good thing. But only if you do the crypto in the
hardware and trust the hardware and its attack models ;) For
instance, the fingerprint readers you see everywh
> Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big
> trouble" risk entirely
This isn't really possible. A trojaned client will spend your coin as
easily as the owner can, passphrases will be logged, windows box will
be owned, secondary remote spendauth sigs into the network cha
I would rather we spend time working to make users' bitcoins safe EVEN IF
their bitcoin software is compromised.
Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big
trouble" risk entirely, instead of worrying about unlikely scenarios like a
timing attack in between ACKs/pulls. Eli
>> gpg signing commits, like the Linux kernel
> Though, honestly, when I ACK that means I read the code, which is more
> important than the author really. github seems fine for that still,
> though I do wonder if there is a race possible,
>
> * just before I click "pull", sneak rebases the branch
On Tue, Apr 2, 2013 at 11:41 PM, Wladimir wrote:
> Maybe now that bitcoin is growing out of the toy phase it's an idea to start
> gpg signing commits, like the Linux kernel
> (https://lwn.net/Articles/466468/).
>
> But I suppose then we can't use github anymore to merge as-is and need
> manual ste
Maybe now that bitcoin is growing out of the toy phase it's an idea to
start gpg signing commits, like the Linux kernel (
https://lwn.net/Articles/466468/).
But I suppose then we can't use github anymore to merge as-is and need
manual steps?
Wladimir
On Tue, Apr 2, 2013 at 12:54 AM, Roy Badam
And the moment I hit send I realised it's not necessarily true.
Conceivably, a collision attack might help you craft two commits (one
good, one bad) with the same hash.
But I still maintain what I just posted is true: if someone gets
malicious code into the repo, it's going to be by social enginee
The attack Schneier is talking about is a collision attack (i.e. it
creates two messages with the same hash, but you don't get to choose
either of the messages). It's not a second preimage attack, which is
what you would need to be able to create a message that hashes to the
same value of an exist
The threat of a SHA1 collision attack to insert a malicious pull request
are tiny compared with the other threats - e.g. github being compromised,
one of the core developers' passwords being compromised, one of the core
developers going rogue, sourceforge (distribution site) being compromised
etc e
On 2 April 2013 00:10, Will wrote:
> The threat of a SHA1 collision attack to insert a malicious pull request
> are tiny compared with the other threats - e.g. github being compromised,
> one of the core developers' passwords being compromised, one of the core
> developers going rogue, sourceforg
On 1 April 2013 20:28, Petr Praus wrote:
> An attacker would have to find a collision between two specific pieces of
> code - his malicious code and a useful innoculous code that would be
> accepted as pull request. This is the second, much harder case in the
> birthday problem. When people talk
An attacker would have to find a collision between two specific pieces of
code - his malicious code and a useful innoculous code that would be
accepted as pull request. This is the second, much harder case in the
birthday problem. When people talk about SHA-1 being broken they actually
mean the fir
I was just looking at:
https://bitcointalk.org/index.php?topic=4571.0
I'm just curious if there is a possible attack vector here based on the
fact that git uses the relatively week SHA1
Could a seemingly innocuous pull request generate another file with a
backdoor/nonce combination that slips un
15 matches
Mail list logo
