On Mon, Aug 19, 2013 at 5:09 AM, John Dillon
wrote:
> > Here's another question for you Mike: So does bitcoinj have any
> > protections against peers flooding you with useless garbage? It'd be
> > easy to rack up a user's data bill for instance by just creating junk
> > unconfirmed transactions ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/18/13 8:09 PM, John Dillon wrote:
> On the other hand, a tx with some txin proofs can be safely relayed by SPV
> nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
> size small in mind?
More than a kilobyte, probably
My apologies, that was for Peter
On Mon, Aug 19, 2013 at 5:00 AM, John Dillon
wrote:
> -BEGIN PGP MESSAGE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
> G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
> GmRRyOR
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0
On Mon, Aug 19, 2013 at 03:09:07AM +, John Dillon wrote:
> That is good too.
>
> I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
> Should be easy to do as a patch to satoshi bitcoin I think. The implementation
> must include a RFC3514 compliant service bit to let p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd wrote:
> 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 in
On Sat, Aug 17, 2013 at 8:35 AM, Mike Hearn wrote:
> There shouldn't be a "smaller subset of Bloom filtering nodes" because the
> idea of making it optional is a stupid one.
>
> If you're worried about DoS, come up with real fixes instead of trying to
> break features that work.
It is not just ab
There shouldn't be a "smaller subset of Bloom filtering nodes" because the
idea of making it optional is a stupid one.
If you're worried about DoS, come up with real fixes instead of trying to
break features that work.
On Sat, Aug 17, 2013 at 2:08 AM, Warren Togami Jr. wrote:
> A sane default t
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
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
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
On 16 August 2013 03:00, 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 fees. I
> was busy today generating scatter-plots and histograms of transaction fees
>
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 fees. I
was busy today generating scatter-plots and histograms of transaction fees
versus priorities to get some insight into what miner polici
27 matches
Mail list logo
