Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-19 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread Mark Friedenbach
-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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread John Dillon
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread John Dillon
-BEGIN PGP MESSAGE- Version: GnuPG v1.4.11 (GNU/Linux) hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7 eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread John Dillon
-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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-17 Thread Jeff Garzik
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-17 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Warren Togami Jr.
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Warren Togami Jr.
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Gregory Maxwell
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Warren Togami Jr.
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Peter Todd
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Warren Togami Jr.
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Warren Togami Jr.
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-15 Thread Melvin Carvalho
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 >

[Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-15 Thread Gavin Andresen
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