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
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
Cool. Maybe it's time for another development update on the foundation blog?
On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote:
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,
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
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
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
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
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 of
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
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com 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
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 I
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org 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
On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org 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
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 at
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
15 matches
Mail list logo
