A sane default that better protects users could be...
If (plugged into power) && (wifi) then non-bloom peers are OK. It would
protect those users more than reliance upon on the smaller subset of bloom
nodes. Scale back to the less secure behavior when battery and bandwidth
matters.
Warren
On
I personally like the full-measure of eliminating the "CS-PRNG" entirely
from signing. If the "random" component is assumed to be untrusted,
keeping it in there adds no value, while eschewing the main benefit of
deterministic signing (ease of testing, auditing)
This just leaves the CS-PRNG
On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
> On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd wrote:
>
> > UPNP seems to work well for the reference client. What's the situation
> > there on Android?
> >
>
> Not sure - it could be investigated. I think UPNP is an entirely
> userspace
Oops, hit send too early.
Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd wrote:
> UPNP seems to work well for the reference client. What's the situation
> there on Android?
>
Not sure - it could be investigated. I think UPNP is an entirely
userspace-implementable protocol, so in theory it could be done by a
userspace librar
I might agree this would be helpful for the many phones plugged into power
and on wifi for large portions of the day. However that doesn't really
help much when phone IP addresses change often as you move onto different
networks, and currently IP address is the only thing that peers can keep
track
On Fri, Aug 16, 2013 at 04:36:20PM +0200, Mike Hearn wrote:
> That change was made in response to user complaints. Heck we get complaints
> about battery life and bandwidth impact even with Bloom filtering. We can't
> just randomly start using peoples bandwidth for relaying blocks, especially
> as
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wrote:
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node,
[...]
> has almost zero drawbacks,
There are whole countries who access the internet from single IP
addresses. There are major institu
That change was made in response to user complaints. Heck we get complaints
about battery life and bandwidth impact even with Bloom filtering. We can't
just randomly start using peoples bandwidth for relaying blocks, especially
as I guess most SPV nodes are behind NAT.
If Gavin is right and the fu
bitcoinj-0.10 release notes:
- We now require Bloom-capable (0.8+) peers by default and will
disconnect from older nodes. This avoids accidental bandwidth saturation on
mobile devices.
Given the user-security concern that Peter brings up, reconsideration of
this new default behavior in S
On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
> Doing this also makes it more difficult to sybil the network - for
> instance right now you can create "SPV honeypots" that allow incoming
> connections only from SPV nodes, thus attracting a disproportionate % of
> the total SPV populat
On Fri, Aug 16, 2013 at 03:41:54AM -1000, Warren Togami Jr. wrote:
> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
> If you disallow the same IP and/or subnet from establishing too many
On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
Part
Automatic heuristic driven prioritization, with sane defaults and some
configurable knobs, is exactly what I suggest.
In the short-term though, any connection limits added to the client by
default would be the simplest and easiest protection measure to audit. It
would improve things a lot over th
A ban-subnet RPC would be a reasonable addition, but obviously DoS
attackers that are IP or bandwidth constrained are really just script
kiddies. Also anything that involves every node operator doing manual
intervention rather works against decentralisation and having a big
network. That's why I ke
https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
*Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node, it becomes more expensive for attackers t
On Fri, Aug 16, 2013 at 01:32:39PM +0200, Mike Hearn wrote:
> and analysing it is really hard (plus it inverts the threat model - if you
> trust your computer and not your hardware wallet, why do you have a
> hardware wallet?)
Myself I would trust neither the hardware wallet nor my computer...
So
The only other thing I'd like to see there is the start of a new anti-DoS
framework. I think once the outline is in place other people will be able
to fill it in appropriately. But the current framework has to be left
behind.
If I had to choose one thing to evict to make time for that, it'd be the
Cool. Maybe it's time for another development update on the foundation blog?
On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen wrote:
> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded f
I filed a bug in the bitcoinj tracker for this a few days ago referencing
rfc 6967, but that RFC is very complicated and I'm not sure it's really
necessary to go that far. H(sighash||key) is easy to implement and I feel I
understand it better.
In our case it wouldn't have helped anyway - if anythi
On Fri, Aug 16, 2013 at 09:39:16AM +, Luke-Jr wrote:
> Now-merged pull request #2702 appears to have put the master branch on an
> unofficial Ripple fork of LevelDB, rather than merely updating us to LevelDB
> 1.12.0. While Vinnie did somewhat disclose this, I don't see any evidence the
> na
Now-merged pull request #2702 appears to have put the master branch on an
unofficial Ripple fork of LevelDB, rather than merely updating us to LevelDB
1.12.0. While Vinnie did somewhat disclose this, I don't see any evidence the
nature of this was fully understood by others. As I understood the
22 matches
Mail list logo
