* [Bitcoin-development] Blitcoin? (Black Hat 2011)
@ 2011-08-04 10:56 John Smith
2011-08-04 14:14 ` Matt Corallo
2011-08-04 14:38 ` Luke-Jr
0 siblings, 2 replies; 12+ messages in thread
From: John Smith @ 2011-08-04 10:56 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
L.S.
Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky
at BH 2011, there is one article about this dated yesterday:
http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics
The article is very unspecific though. They talk about a tool called
"blitcoin" that "unmasks" both sides of a bitcoin transaction. A google
search also turned up nothing, except some misspellings.
Does anyone have more information?
JS
[-- Attachment #2: Type: text/html, Size: 711 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) John Smith
@ 2011-08-04 14:14 ` Matt Corallo
2011-08-04 14:38 ` Luke-Jr
1 sibling, 0 replies; 12+ messages in thread
From: Matt Corallo @ 2011-08-04 14:14 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Sounds like Dan wrote a tool which attempts to connect inputs/outputs
and make a map of a person on the network, or at least thats my blind
guess. Something people have been saying was easily possible for some
time, but for some reason people insist on refusing their precious
Bitcoin isnt anonymous.
Matt
On Thu, 2011-08-04 at 10:56 +0000, John Smith wrote:
> L.S.
>
> Some bitcoin "security vulnerabilities" have been discussed by Dan
> Kaminsky at BH 2011, there is one article about this dated yesterday:
>
> http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics
>
> The article is very unspecific though. They talk about a tool called
> "blitcoin" that "unmasks" both sides of a bitcoin transaction. A
> google search also turned up nothing, except some misspellings.
>
> Does anyone have more information?
>
> JS
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) John Smith
2011-08-04 14:14 ` Matt Corallo
@ 2011-08-04 14:38 ` Luke-Jr
2011-08-05 1:16 ` Gavin Andresen
1 sibling, 1 reply; 12+ messages in thread
From: Luke-Jr @ 2011-08-04 14:38 UTC (permalink / raw)
To: bitcoin-development
On Thursday, August 04, 2011 6:56:42 AM John Smith wrote:
> L.S.
>
> Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky
> at BH 2011, there is one article about this dated yesterday:
>
> http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kam
> insky-reveals-network-security-research-topics
>
> The article is very unspecific though. They talk about a tool called
> "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google
> search also turned up nothing, except some misspellings.
Well, that certainly doesn't sound like a security vulnerability at all.
It's by design that everyone knows about every transaction.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-04 14:38 ` Luke-Jr
@ 2011-08-05 1:16 ` Gavin Andresen
2011-08-05 5:37 ` John Smith
2011-08-05 13:07 ` Andy Parkins
0 siblings, 2 replies; 12+ messages in thread
From: Gavin Andresen @ 2011-08-05 1:16 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
Dan gave a brief explanation of "blitcoin" on the forums:
https://bitcointalk.org/index.php?topic=34458.0
"As reported, I've got a BitCoin deanonymization mechanism. It's not
complicated.
Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers
messages. The first IP to consistently relay transactions for a given
identity, is the given identity.
Of course the entire BitCoin cloud doesn't allow inbound connections
(although you can do rather evil stuff with UPNP to force that open too).
But this isn't a problem -- there's only about 3000 to 8000 IPs that are
BitCoin nodes that accept inbound connections. Since everyone else depends
on them, you just need to create your own mass cluster of IPs that are a
decent chunk of the P2P network. Nodes on average have seven outbound
connections, so it should take only a few hundred unique to be one of the
first-hop peers even for the outbound-only set."
... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
address. And might go partway to explaining why we're having trouble with
network connectivity...
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2216 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 1:16 ` Gavin Andresen
@ 2011-08-05 5:37 ` John Smith
2011-08-05 5:52 ` Jeff Garzik
2011-08-05 5:55 ` John Smith
2011-08-05 13:07 ` Andy Parkins
1 sibling, 2 replies; 12+ messages in thread
From: John Smith @ 2011-08-05 5:37 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andresen <gavinandresen@gmail•com>wrote:
>
> ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
> address. And might go partway to explaining why we're having trouble with
> network connectivity...
>
Well it's good that the bitcoin network is seeing some security testing.
So I understand that we have a combination of problems at the moment:
1) A DDoS possibility (if this is really the cause of the network
connectivity problems)
2) An attacker can figure out which node first broadcasted a transaction, by
connecting to the entire network or having everyone connect to his node(s)
3) The recipient re-broadcasts transactions (is Theymos right here?),
allowing both the sender and recipient to be found
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).
JS
[-- Attachment #2: Type: text/html, Size: 1720 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 5:37 ` John Smith
@ 2011-08-05 5:52 ` Jeff Garzik
2011-08-05 12:01 ` Joel Joonatan Kaartinen
2011-08-05 5:55 ` John Smith
1 sibling, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2011-08-05 5:52 UTC (permalink / raw)
To: John Smith; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 5:37 ` John Smith
2011-08-05 5:52 ` Jeff Garzik
@ 2011-08-05 5:55 ` John Smith
1 sibling, 0 replies; 12+ messages in thread
From: John Smith @ 2011-08-05 5:55 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
> 3) The recipient re-broadcasts transactions (is Theymos right here?),
> allowing both the sender and recipient to be found
>
Hm this would potentially allow getting the IP for any recipient Bitcoin
address, given that a client with the private key connects to the network
once in a while.
Send them a transaction that is guaranteed to not be written into a block by
a miner, then monitor who rebroadcasts it over a few days/weeks.
I guess this could also be used to find out who has the stolen coins.
JS
[-- Attachment #2: Type: text/html, Size: 746 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 5:52 ` Jeff Garzik
@ 2011-08-05 12:01 ` Joel Joonatan Kaartinen
2011-08-05 12:58 ` Christian Decker
0 siblings, 1 reply; 12+ messages in thread
From: Joel Joonatan Kaartinen @ 2011-08-05 12:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:
> 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.
Could every node do the resends? Alternatively, could we implement a TOR
like tunneling system just for the first leg of the transactions
(overkill?). Then again, maybe just a TOR gateway if that's desired.
> > 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.
This is a nice idea but sounds rather unreliable.
> 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.
There's already an implementation of this, called UTP. If we do decide
that using UDP is worthwhile, this library is probably better than
implementing something ourselves.
- Joel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 12:01 ` Joel Joonatan Kaartinen
@ 2011-08-05 12:58 ` Christian Decker
2011-08-05 13:11 ` John Smith
0 siblings, 1 reply; 12+ messages in thread
From: Christian Decker @ 2011-08-05 12:58 UTC (permalink / raw)
To: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]
While I do think that anonymity (or pseudonymity) is a nice feature, I don't
think it deserves the full focus of the developers. The core of the protocol
is about making transactions in a secure and fast way, not allowing
everybody to be anonymous, whether they want to or not. TOR already is a
good options for those that want to stay anonymous, and there is no need to
pull support into the main client, if only a few will use it. I think very
few of the developers actually claimed that Bitcoin is anonymous, and has
never been a big advertising point from the "official" side of Bitcoin,
network analysis has been always known to break anonymity.
I see no need for action from the developer side.
-cdecker
On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan Kaartinen <
joel.kaartinen@gmail•com> wrote:
> On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote:
> > 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.
>
> Could every node do the resends? Alternatively, could we implement a TOR
> like tunneling system just for the first leg of the transactions
> (overkill?). Then again, maybe just a TOR gateway if that's desired.
>
> > > 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.
>
> This is a nice idea but sounds rather unreliable.
>
> > 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.
>
> There's already an implementation of this, called UTP. If we do decide
> that using UDP is worthwhile, this library is probably better than
> implementing something ourselves.
>
> - Joel
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3776 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 1:16 ` Gavin Andresen
2011-08-05 5:37 ` John Smith
@ 2011-08-05 13:07 ` Andy Parkins
2011-08-05 13:19 ` John Smith
1 sibling, 1 reply; 12+ messages in thread
From: Andy Parkins @ 2011-08-05 13:07 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: Text/Plain, Size: 800 bytes --]
On 2011 August 05 Friday, Gavin Andresen wrote:
> "As reported, I've got a BitCoin deanonymization mechanism. It's not
> complicated.
>
> Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers
> messages. The first IP to consistently relay transactions for a given
> identity, is the given identity.
Transaction forwarding could be randomised slightly, by randomising the
outgoing relay order; and adding a random delay between each forward. Even
the massively connected monitor can't represent _all_ the connections on every
real node, so it would have no way of knowing whether it got any transaction
from the originator or because it got a fast path through the first N nodes to
receive it.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 12:58 ` Christian Decker
@ 2011-08-05 13:11 ` John Smith
0 siblings, 0 replies; 12+ messages in thread
From: John Smith @ 2011-08-05 13:11 UTC (permalink / raw)
To: Christian Decker; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Fri, Aug 5, 2011 at 12:58 PM, Christian Decker <
decker.christian@gmail•com> wrote:
> While I do think that anonymity (or pseudonymity) is a nice feature, I
> don't think it deserves the full focus of the developers. The core of the
> protocol is about making transactions in a secure and fast way, not allowing
> everybody to be anonymous, whether they want to or not. TOR already is a
> good options for those that want to stay anonymous, and there is no need to
> pull support into the main client, if only a few will use it. I think very
> few of the developers actually claimed that Bitcoin is anonymous, and has
> never been a big advertising point from the "official" side of Bitcoin,
> network analysis has been always known to break anonymity.
>
Yes. Optionally layering Bitcoin over Tor/I2P is a much better option than
trying to replicate an onion network in Bitcoin itself. For one, traffic
analysis is much more difficult if your onion routing network contains
multiple kinds of traffic. Also it would complicate the core algorithm and
waste developer time. Doing anonymity *right* is very hard. So let's leave
it to the Tor/I2P people that know what they're doing.
>
> I see no need for action from the developer side.
>
Except the part about making the client/network more resistant against DDoS.
JS
[-- Attachment #2: Type: text/html, Size: 1761 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
2011-08-05 13:07 ` Andy Parkins
@ 2011-08-05 13:19 ` John Smith
0 siblings, 0 replies; 12+ messages in thread
From: John Smith @ 2011-08-05 13:19 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
On Fri, Aug 5, 2011 at 1:07 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On 2011 August 05 Friday, Gavin Andresen wrote:
>
> Transaction forwarding could be randomised slightly, by randomising the
> outgoing relay order; and adding a random delay between each forward. Even
> the massively connected monitor can't represent _all_ the connections on
> every
> real node, so it would have no way of knowing whether it got any
> transaction
> from the originator or because it got a fast path through the first N nodes
> to
> receive it.
>
Right, while it doesn't warrant completely changing the transport protocol
to UDP or implementing onion routing, I'm all for simple timing and order
randomization changes if they can make attacks like this less effective.
JS
[-- Attachment #2: Type: text/html, Size: 1089 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-08-05 13:19 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox