From: Jeff Garzik <jgarzik@exmulti•com>
To: John Smith <witchspace81@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
Date: Fri, 5 Aug 2011 01:52:05 -0400 [thread overview]
Message-ID: <CA+8xBpd0ud0Jn7Xxfw3C-WCH12WuB7k_W5x00Mj2EidemGoYpQ@mail.gmail.com> (raw)
In-Reply-To: <CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com>
On Fri, Aug 5, 2011 at 1:37 AM, John Smith <witchspace81@gmail•com> 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.
jgarzik@exmulti•com
next prev parent reply other threads:[~2011-08-05 5:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 10:56 John Smith
2011-08-04 14:14 ` Matt Corallo
2011-08-04 14:38 ` Luke-Jr
2011-08-05 1:16 ` Gavin Andresen
2011-08-05 5:37 ` John Smith
2011-08-05 5:52 ` Jeff Garzik [this message]
2011-08-05 12:01 ` Joel Joonatan Kaartinen
2011-08-05 12:58 ` Christian Decker
2011-08-05 13:11 ` John Smith
2011-08-05 5:55 ` John Smith
2011-08-05 13:07 ` Andy Parkins
2011-08-05 13:19 ` John Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8xBpd0ud0Jn7Xxfw3C-WCH12WuB7k_W5x00Mj2EidemGoYpQ@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=witchspace81@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox