Yes, if the wallet isn't up to date yet, it uses the highest estimated
block height from connected peers, but that could be gamed by
controlling the network. The app has blockchain checkpoints in it
though, so you couldn't truncate the chain starting point below that.
The worst case is that you get
Probably because the network isn't designed for interactive proofs. Most
interactive algoritms AFAICT requires that some machine holds a secret
state (or at least continuous and untampered state, but you still need to
verify you're falling to the right machine), otherwise the machine can be
mimicke
Sorry, you're right. I'd have hoped a delay that doubles on failure each
time up to some max would be good enough, relying on the p2p network to
unlock a PIN feels weird, but I can't really quantify why or what's wrong
with it so I guess it's just me :-)
On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voi
The problem is if someone moves system time forward between app launches.
The lockout period doesn't have to be all that precise, it just makes you
wait for the next block, then 5, then 25, and so on. Using a well
known time server over https would also be a good option, but the wallet
app already
Given that the speed at which the block chain advances is kind of
unpredictable, I'd think it might be better to just record the time to disk
when a PIN attempt is made and if you observe time going backwards, refuse
to allow more attempts until it's advanced past the previous attempt.
On Fri, Ju
>
> Ok... 'time' on the blockchain could be 'gamed' ... but with great
> difficulty.
Unfortunately not: miners have in the past routinely gamed the timestamp in
order to use it as an extra nonce and squeeze some more gigahashes out of
their hardware/pool.
Also remember that currently the chain c
6 matches
Mail list logo
