Bitcoin Forum
December 08, 2016, 08:25:03 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: "BlitCoin": "unmasks one or both ends of a BitCoin transaction"?  (Read 6796 times)
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile
August 05, 2011, 04:00:05 AM
 #21

If peers exchanged session keys (pki or diffie-h-m), then users could onion-wrap their transactions just like nym/cypherpunk remailers. If nodes broadcast transactions at random or frequent intervals I think it would be very difficult to associate a single ip with a transaction, like TOR-lite implemented in the bitcoin network itself.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481228703
Hero Member
*
Offline Offline

Posts: 1481228703

View Profile Personal Message (Offline)

Ignore
1481228703
Reply with quote  #2

1481228703
Report to moderator
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
August 05, 2011, 05:31:16 AM
 #22

"Dan’s two main assertions are that Bitcoin is not scalable (at transaction levels reaching even a fraction of those for the Visa payment network)"

Does this mean we can make Visa payments for a fraction of a cent? I don't agree with Dan's comparison's of bitcoin to Visa. A more interesting argument would be in how Visa would benefit from decentralization.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Serith
Sr. Member
****
Offline Offline

Activity: 269


View Profile
August 05, 2011, 06:31:02 AM
 #23

Quote from: Gavin Andresen
so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
address.
Blitcoin? (Black Hat 2011)

how about an obvious solution to have proxy settings as an option for bitcoin client?
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
August 05, 2011, 08:06:34 AM
 #24

This just highlights the importance of hiding your IP when using bitcoin. The use of Tor should be a "recommended practice" as the use of different address per transaction. It would be nice to provide a bitcoin+Tor bundle on bitcoin.org.

Unfortunately I'm not sure if the current bootstrap process could handle most nodes being behind Tor or I2P. Bitcoin should be capable to connect to URLs instead of only IPs (is it? I'm not sure), so that hidden services could be resolved. And it would be nice if every bitcoin node, bundled with the anonymization proxy, could set up a hidden service for itself automatically.
apetersson
Hero Member
*****
Offline Offline

Activity: 666


mycelium.com


View Profile WWW
August 05, 2011, 09:23:18 AM
 #25

i don't know who came up with this "bitcoin is anonymous" thing.
it is clearly not, anyone who knows about graphs, read the paper or looked at blockexplorer can tell you that. so please stop beating a dead horse Smiley

that does not mean it is useless. in fact, its non-anonymity legitimizes it when looked at by governments. embrace it.
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
August 05, 2011, 11:49:37 AM
 #26

i don't know who came up with this "bitcoin is anonymous" thing.
it is clearly not, anyone who knows about graphs, read the paper or looked at blockexplorer can tell you that. so please stop beating a dead horse Smiley

Right... how much bitcoins do I have then, if I have any? Point any transactions done by me, or prove I haven't ever done any.

Bitcoins do have a good level of anonymity, and if you use it properly, they are much more anonymous than any other electronic means of payment I'm aware of.
 
that does not mean it is useless. in fact, its non-anonymity legitimizes it when looked at by governments. embrace it.

The easier it gets to trace bitcoins transactions, the easier it will be for governments to pursuit those who use the technology. Don't be naive, most governments will try to ban bitcoin if it ever grows enough to bothers them. Actually, I imagine many governments already have laws that implicitly forbid things like bitcoin.

Helping people to preserve their financial privacy is important, and I think it's the second most important utility of bitcoin, after fighting inflation, of course. Actually, I think you cannot do the latter if you can't do the former.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 05, 2011, 12:00:40 PM
 #27

I really like the descriptions of Bitcoin scalability in your other set of slides; they fairly succinctly point out the issues with scaling, and how the proposed solution to dealing with large transaction volumes inevitably mean Bitcoin will become highly centralized.

Edit: Also, now I've found the correct set of slides - how would bitcoinfs by injecting data into other users' transactions work? The signature obviously can't sign itself, but the rest of the transaction script is signed - you'd have to somehow inject data into the signature value itself. Which I guess might be doable actually...

(Oh - and the suggestion of generating private keys from passwords is interesting, because Bitcoin users are obviously already using a less secure version of this using a single round of SHA256.)

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
BitVapes
Full Member
***
Offline Offline

Activity: 140


BitVapes.com


View Profile WWW
August 05, 2011, 12:23:30 PM
 #28

I really like the descriptions of Bitcoin scalability in your other set of slides; they fairly succinctly point out the issues with scaling, and how the proposed solution to dealing with large transaction volumes inevitably mean Bitcoin will become highly centralized.

who knows, maybe we will all have 900 Petabit/sec connections by the time bitcoin transactions require 1 Terabit/sec.  One can hope.

Buy Electronic Cigarettes with Bitcoin @ http://bitvapes.com
TraderTimm
Legendary
*
Offline Offline

Activity: 1652



View Profile
August 05, 2011, 05:58:55 PM
 #29

The major flaw in making any of this works assumes the coins will be spent or transferred immediately. They could just as easily be 'parked' for quite some time until things cool down.

fortitudinem multis - catenum regit omnia
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
August 05, 2011, 10:14:31 PM
 #30

That is definitely an area in need of improvement:  we are always desperately short of hosts that accept incoming connections on the network.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Big Time Coin
Sr. Member
****
Offline Offline

Activity: 332



View Profile
August 07, 2011, 08:14:48 AM
 #31

Heh all.

Slides are up at dankaminsky.com/bo2k11.

"What type of transactions are we talking about here? Would you need to actually spend BTC to reveal information? "

Loose transactions that involve sending money, can expose the IP address of the sender.  The transaction has to enter the relay network somehow, and the first sender is the source.

"I was kind of hoping for something a little more interesting, giving his penchant for breaking shit - but this is neat too."

No need to overcomplicate things.  Although, looking at the source, each peer node that is selected from the outbound lists has to be on a unique /16 network.  Getting large numbers of nodes with inbound connectivity and unique x.y.0.0 addresses is actually a bit of a task.  I have a little more interesting plan for how to achieve that inexpensively.

That's great Dan.  Nice work.  Most of the stolen coins can be traced with your technique when they get moved around.  At the very least we can see when they are NOT being moved around, which is also useful information.  It would be nice to put it to work right away because hackers may be dumping mass coins as I type this.

How soon can we mirror blockexplorer.com enhanced with the IPs listed next to the send and recieve addresses in other words how much would you estimate the cost/man-hour investment?  Is this a one-man one-day job or are we talking 10 guys full time for a month.

Once the software is coded up and running smooth, how much would it cost to run your proposed monitoring network 24/7?  Can it be run on a single top-end desktop PC or would it take a huge hardware rental/investment - and what kind of bandwidth?

Just ballpark estimate, can this be done for under $10k and by the end of the month?

Big time, I'm on my way I'm making it, big time, oh yes
- Peter Gabriel
Economics
Jr. Member
*
Offline Offline

Activity: 35


View Profile
September 08, 2011, 04:03:30 PM
 #32

This seems pretty simple, but I'm not sure what it takes to scale it.  I modified the standard linux bitcoind client to connect to as many clients as possible and write a line to the log file for each new transaction received.

With my home connection and a mediocre machine, I'm at 375 connections.  What would it take to get more?  Just wait longer; it still seems to grow slowly?  Connect to all irc channels (00-99) to listen for more new connections?  What else could be done?

Below is a sample of the log file (with ip obfuscated slightly).  I could imagine that if you could combine this type of data with blockexplorer, you could get a percentage confidence that a particular ip initiated the transaction.

ip, transaction id, number of connections, time, time with ms
======================================
New tx from,*.*.79.142,   1a1d4f099b2bb9ec3121f99d1efd2ffccd31aad72dbab5528f7fccb868fe581f,   372,   1315497415,   1315497415632
New tx from,*.*.112.255,389557dc8d0d1a55210a324fec4d96af5aa6718ced5dd02ac7227f18d35bbecb,374,1315497444,1315497444126
New tx from,*.*.44.152,d066924c72b5ce47a3fdeae61b7ce684e32ae67de260d4e62097ab701e62d603,372,1315497447,1315497447440
New tx from,*.*.186.54,3c204aa513e940642e7ad07a1b07265d22fb063001b4721d51f270abf457f358,373,1315497451,1315497451284
New tx from,*.*.162.247,b21ee08eb268313a660ce65771b24f16f5b213bc5ee87f692559d783abd41362,376,1315497469,1315497469097
New tx from,*.*.48.11,15cc9d11d658b7239036e119fc2bc9a4959fc686609a44c05b2c7603612657c0,376,1315497469,1315497469939
New tx from,*.*.164.43,24cdfeacc2de0ef849aaa490a22b5f44f5faeb3a20c4c979c894d05f5fd7a688,376,1315497472,1315497472182
New tx from,*.*.119.238,bbbb7ff8aebcff5e5a71f735dfe26217f1930cc6ea8f3f9f3818624317e1d2b7,379,1315497494,1315497494491
New tx from,*.*.75.41,1b261310e0915e2b29fa7a5c24d5188d827da2eeab1480956606e9ddd9b23728,380,1315497516,1315497516919
New tx from,*.*.24.189,bd480e84e14988389bdf6b3de0cf99afc3b53b6be0934e5d5c87596d911bf056,380,1315497517,1315497517998

--E
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
September 08, 2011, 04:14:35 PM
 #33

So let's talk about how to get around this problem, besides using tor (since it is notoriously slow, I can't see it being very suitable for downloading the blockchain through, etc).

What about generating transactions offline, then sending them from a public location, or uploading them to a website, etc?  Is there a way to do this?
burlyman007
Jr. Member
*
Offline Offline

Activity: 30


View Profile
September 08, 2011, 05:28:33 PM
 #34

This is super interesting.

Thank you, dakami, for the find! I enjoyed your slides.

Is there a way to configure my Bitcoin client to run through Tor? Although I don't expect anyone to attempt to trace any of my addresses, I'm all about privacy and security.

Lastly, would generating a new address for each transaction eliminate this security risk?
Binford 6100
Hero Member
*****
Offline Offline

Activity: 504


PGP OTC WOT: EB7FCE3D


View Profile
September 08, 2011, 07:30:21 PM
 #35

So let's talk about how to get around this problem, besides using tor (since it is notoriously slow, I can't see it being very suitable for downloading the blockchain through, etc).

What about generating transactions offline, then sending them from a public location, or uploading them to a website, etc?  Is there a way to do this?

I have half a solution: spend coins via tor (broadcasting tx)
and download blockchain as usual, no need to cripple your bitcoin experience

You can't build a reputation on what you are going to do.
Economics
Jr. Member
*
Offline Offline

Activity: 35


View Profile
September 08, 2011, 08:40:32 PM
 #36

Bitcoin can use a socks4 proxy, so presumably you could easily set a proxy once the blockchain is downloaded.
In fact, there may be a market for a 'bitcoin proxy' that promises some sort of anonymity.  With a large enough user base, this would be feasible.

--E
Big Time Coin
Sr. Member
****
Offline Offline

Activity: 332



View Profile
September 08, 2011, 09:10:08 PM
 #37

The thread lives!!

Remember "Economics", according to the slides, those IP addresses are not the ones initiating the transactions in (100% - 375/~50000) of cases, since those IPs are just gossiping nodes, relaying information received via P2P. 

To get the IP by your technique, you would need to connect to every node.  And since only 8 connections are allowed per node, and once it propogates to 8 it doesn't disconnect itself with no reason, that part of kaminsky's technique (described on slide 25) will not actually work IRL.  Node discovery and nat/tor problems as well.  Also the outbound/inbound allowed thing.

slides @ http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 see slide 22 - 35.

Big time, I'm on my way I'm making it, big time, oh yes
- Peter Gabriel
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
September 08, 2011, 10:05:26 PM
 #38

The thread lives!!

Remember "Economics", according to the slides, those IP addresses are not the ones initiating the transactions in (100% - 375/~50000) of cases, since those IPs are just gossiping nodes, relaying information received via P2P. 

To get the IP by your technique, you would need to connect to every node.  And since only 8 connections are allowed per node, and once it propogates to 8 it doesn't disconnect itself with no reason, that part of kaminsky's technique (described on slide 25) will not actually work IRL.  Node discovery and nat/tor problems as well.  Also the outbound/inbound allowed thing.

slides @ http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 see slide 22 - 35.
Actually, that's a good point.  You wouldn't be able to connect to existing nodes that limit themselves to 8 connections, as they already have 8 valid nodes to connect to, and won't change without reason.
elggawf
Sr. Member
****
Offline Offline

Activity: 308



View Profile
September 08, 2011, 10:14:04 PM
 #39

Actually, that's a good point.  You wouldn't be able to connect to existing nodes that limit themselves to 8 connections, as they already have 8 valid nodes to connect to, and won't change without reason.

Okay, so you can't do the attack on demand. You could, however, trivially and for very little cost, maintain a good number of peers accepting incoming connections, and just wait it out until you're pretty sure you're connected to most of the peers on the network. That's (I think) what jgarzik is talking about how we always need more peers accepting incoming connections, because the less there are, the easier and less costly this attack is.

^_^
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW
September 08, 2011, 11:48:33 PM
 #40

I've started recording ip's on my block tracker site. Currently connected to 600 nodes but don't want to increase the limit any further as bitcoind cpu usages gets too high.

http://pi.uk.com/bitcoin/unconfirmed-transactions

It will be interesting to to see whether any of these ip's are actually the transaction sender. A lot of them link to personal home pages and stuff.

When i collect enough data i'll use the frequencies of ip's associated with a given address to try and guess the owner.

Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!