Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)

From: Jeff Garzik <[email-masked]>
Date: Fri, 5 Aug 2011 01:52:05 -0400

On Fri, Aug 5, 2011 at 1:37 AM, John Smith <[email-masked]> wrote:
> Well it's good that the bitcoin network is seeing some security testing.

Yep.

> 1) A DDoS possibility  (if this is really the cause of the network
> connectivity problems)

Unfortunately the nodes accepting incoming connections are small
enough in number (7000?) that you can shut down a lot by attacking
those nodes.

This was part of the motivation of turning on upnp by default in the
GUI version, but maybe we need to go further than that...

> 3) The recipient re-broadcasts transactions (is Theymos right here?),
> allowing both the sender and recipient to be found

Yes, that is correct.  Bitcoin resends wallet transactions with zero
confirmations, and both sent and received transactions fall within the
"wallet tx" superset.

TBH I had forgotten about the resend on the receiver side, though.
It, of course, makes plenty of sense in the context of importing
transactions from foreign sources, e.g. receiving transactions via a
USB flash drive.

> Drawok's suggestion about using UDP packets with spoofed sender addresses is
> interesting, as UDP has another advantage; you can open up an "inbound" UDP
> port on almost any NAT router without any UPNP magic: just send out an UDP
> packet, the router will wait a certain time for answers (on a mapped port
> number) and relay these back.
>
> It also has some potential issues; the client needs special privileges to
> spoof sender addresses, and some ISPs might filter out packets with
> non-matching sender addriess (unsure how common this is).

Well, it -is- possible to implement TCP over UDP <grin>  The TCP
connection sequence over UDP helps to work against spoofing, while UDP
helps to open an inbound UDP port as you describe.

Not that I'm endorsing a bitcoin-internal TCP stack... just sayin'  :)

-- 
Jeff Garzik
exMULTI, Inc.
[email-masked]