Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
Related to Russia's Tor bounty? http://www.theguardian.com/world/2014/jul/25/russia-research-identify-users-tor On 28 Jul 2014 04:45, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote: These website list Tor nodes by bandwidth: http://torstatus.blutmagie.de/index.php https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc And the details reveal it's a port 8333 only exit node: http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124 As I pointed out above, — it isn't really. Without the exit flag, I believe no tor node will select it to exit 8333 unless manually configured. (someone following tor more closely than I could correct if I'm wrong here) blockchain.info has some records about the related IP going back to the end of this May: https://blockchain.info/ip-address/5.9.93.101?offset=300 dsnrk and mr_burdell on freenode show that the bitnodes crawler showed it accepting _inbound_ bitcoin connections 2-3 weeks ago, though it doesn't now. Fits a pattern of someone running a bitcoin node widely connecting to everyone it can on IPv4 in order to try to deanonymize people, and also running a tor exit (and locally intercepting 8333 there), but I suspect the tor exit part is not actually working— though they're trying to get it working by accepting huge amounts of relay bandwidth. I'm trying to manually exit through it so I can see if its intercepting the connections, but I seem to not be able. Some other data from the hosts its connecting out to proves that its lying about what software its running (I'm hesitant to just say how I can be sure of that, since doing so just tells someone how to do a more faithful emulation; so that that for whatever its worth). -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On behalf of BIP 70 extension proposal
Good to see that it has been discussed, but I see the idea has been postponed. I agree our proposals don’t differ substantially. Besides naming, I think the differences are the algorithms that are used for signing the extended certificate / mandate by the merchant and the way backwards compatibility is handled. Also taking into consideration the replies on your proposal, I think the following decisions are most important to be made when we make a step back: What party/system do we want to rely on to verify the identity of the merchant? Options I’ve seen: - X.509 CAs - Payment Processors (PP) - PGP/Bitcoin-based Which “PKI do we want to use to identify the merchant (related to the previous question)? - X.509 certificate - Merchant identifier - Twitter handle Which “PKI” do we want to use to authenticate the PP? - X.509 certificate - Extended certificate My personal opinion: I’d prefer to stick to the X.509 system for identification of the merchant, even though the system is not perfect. In the case of a webshop transaction, a customer probably already relies on the X.509 system to authenticate the identity of the merchant during the shopping session (HTTPS) in his browser when he transmits his personal data like his address. I’d prefer not to add a competing identification system a customer also needs to rely on, unless that system brings objective improvements and can also be used in the HTTPS session. I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose. Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal. /Mark On 27 Jul 2014, at 21:31 , Mike Hearn m...@plan99.net wrote: Hi Mark, This is very similar to a proposal I made some time ago: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html I think the outlines of a design are clear - my proposal and yours don't I think differ substantially. Someone needs to make it happen though. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
As I pointed out above, — it isn't really. Without the exit flag, I believe no tor node will select it to exit 8333 unless manually configured. (someone following tor more closely than I could correct if I'm wrong here) The exit flag doesn't mean what you would expect it to mean. The reason such a node won't get much traffic is that Tor speculatively builds circuits at startup on the assumption they'll be used for web browsing. Thus if you don't exit web traffic you won't get much in the way of traffic at least not until bitcoinj based wallets start shipping Tor mode. There's a perfectly reasonable explanation for why someone would run such a node. In fact I run a Tor exit that only allows port 8333 too: it's a way to contribute exit bandwidth without much risk of getting raided by the cops. Occam's razor and all -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/28/2014 6:44 AM, Gregory Maxwell wrote: On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote: These website list Tor nodes by bandwidth: http://torstatus.blutmagie.de/index.php https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc And the details reveal it's a port 8333 only exit node: http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124 As I pointed out above, — it isn't really. Without the exit flag, I believe no tor node will select it to exit 8333 unless manually configured. (someone following tor more closely than I could correct if I'm wrong here) blockchain.info has some records about the related IP going back to the end of this May: https://blockchain.info/ip-address/5.9.93.101?offset=300 dsnrk and mr_burdell on freenode show that the bitnodes crawler showed it accepting _inbound_ bitcoin connections 2-3 weeks ago, though it doesn't now. Fits a pattern of someone running a bitcoin node widely connecting to everyone it can on IPv4 in order to try to deanonymize people, and also running a tor exit (and locally intercepting 8333 there), but I suspect the tor exit part is not actually working— though they're trying to get it working by accepting huge amounts of relay bandwidth. I'm trying to manually exit through it so I can see if its intercepting the connections, but I seem to not be able. Some other data from the hosts its connecting out to proves that its lying about what software its running (I'm hesitant to just say how I can be sure of that, since doing so just tells someone how to do a more faithful emulation; so that that for whatever its worth). -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development The thing is, if it doesn't have the exit flag it cannot generate lots of traffic from real good-intended clients, because it's quite hard for clients to choose this Node as ËXIT in their path if it doesn't have the exit flag. So the traffic comes from clients who specifically added ExitNode fingerprint in their torrc and only use that Tor instance for Bitcoin. So, someone build this custom Tor node for themselves only, for plausible den. A pool could be the cause as it was earlier discussed here... The thing is I cannot find this node on atlas, globe or blutmagie can you please provide fingerprint and IP address again? So I may ignore it on my relays and talk to some people about it? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT1jXjAAoJEIN/pSyBJlsRjqgIAIFxHcypU6KUaNdSvESADilM kFiitf00f4Uy9tBwSLVPQw+I2L1EmMiCNvqG4RRjV2+/PS696HCz0Jt0gVaGlMPl DHQSHsozx3BaXi5PpGeLl7uSNLHlEdytytZ8xb08I4IuqcNNHzvxnou7gXapeezC PuSABsxVLpDn+OP7QLRy/PlL948Yfgbxwb9dcn+lUdgDlByxxhMmOrk+o/VdGfnh cL/C+qgpuJiI/wrQridtBmxU8h7Z6TKKua7eWONyg6MrnjwWuZTumhAGO2H4X1Na IZiCmhEwtxb97TMG0EvgcZTeRzfzoddTnOe6ZEsiqOZ7qPNjFJ2i8RoSOI3gUCQ= =t3Mb -END PGP SIGNATURE- -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
On Mon, 28 Jul 2014 07:28:15 -0400, Peter Todd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've got a bitcoin-only exit running myself and right now there is absolutely no traffic leaving it. If the traffic coming from that node was legit I'd expect some to be exiting my node too. Multiple people have confirmed the node is connected to an abnormally large % of the Bitcoin network. Looks like a Sybil attack to me, trying to hide behind a Tor exit node for plausible deniability. I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. I'm not even sure that this behaviour can be considered abuse.. it's pretty much following the rules and maybe even improving the transaction and block propagation. As far as monitoring transaction origins someone could do that using lots of different IPs instead of just one (more like an actual Sybil attack rather than this non-Sybil attack).. and noone would be making a fuss (and imo, probably someone does do that too as it would be useful to capture a larger number of inbound connections). Rob -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On behalf of BIP 70 extension proposal
On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk m...@coinqy.com wrote: Good to see that it has been discussed, but I see the idea has been postponed. I'm not sure postponed is the right word. It wasn't in v1, but many useful things weren't. It's more like, a bunch of people have to do work to upgrade this and at the moment they're all busy with other things. I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose. I don't think I proposed this exactly? It's the other way around - a merchant issues an extension cert to allow the PP to act on their behalf. Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal. I'm not sure I understand. Your proposal also has two signatures. Indeed it must because delegation of authority requires a signature, but old clients won't understand it. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On behalf of BIP 70 extension proposal
On 28 Jul 2014, at 14:46 , Mike Hearn m...@plan99.net wrote: I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose. I don't think I proposed this exactly? It's the other way around - a merchant issues an extension cert to allow the PP to act on their behalf. I referred to your idea in https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html which is indeed not the proposal itself. Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal. I'm not sure I understand. Your proposal also has two signatures. Indeed it must because delegation of authority requires a signature, but old clients won't understand it. I’ll rephrase what I intended to say. In your proposal two signatures need to be computed over the payment request data, one with the key related to the X.509 certificate (for backwards compatibility) and one with the ECDSA public key. On my proposal only one signature needs to be computed over the payment request data using the former key, the same way it happens now. Indeed there is another signature, which is to authenticate the payment delegation. If you take it into account in the signature count, then your proposal has three signatures. /Mark-- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On behalf of BIP 70 extension proposal
I referred to your idea in https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04076.html which is indeed not the proposal itself. Right, gotcha. Had forgotten about that. Indeed there is another signature, which is to authenticate the payment delegation. If you take it into account in the signature count, then your proposal has three signatures. Yes, I see now, you are right. A mandate type system is probably simpler indeed. So what now? To be honest my next priority with BIP70 was to formalise the extensions process, I've been dragging my feet over that because I'm working on other things. And then after that to knock some heads together over at BitPay/Coinbase and get them to put useful text in the memo field instead of random numbers. Baby steps -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote: I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. The bitcoin protocol is more or less identityless. It's using up lots of network capacity, number of sockets is as pretty close as you get. I'm not even sure that this behaviour can be considered abuse.. it's pretty much following the rules and maybe even improving the transaction and block propagation. It isn't relaying transactions or blocks as far as anyone with a connection to it can tell. and sure, probably not much to worry about— people have been running spy nodes for a long time, at least that much is not new. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/28/2014 5:08 PM, Gregory Maxwell wrote: On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote: I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. The bitcoin protocol is more or less identityless. It's using up lots of network capacity, number of sockets is as pretty close as you get. I'm not even sure that this behaviour can be considered abuse.. it's pretty much following the rules and maybe even improving the transaction and block propagation. It isn't relaying transactions or blocks as far as anyone with a connection to it can tell. and sure, probably not much to worry about— people have been running spy nodes for a long time, at least that much is not new. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development gmaxwell - I wanted to ask you a non-expert question. Let's say I use my bitcoin-qt on my laptop with Tor, and send some BTC or receive some, what can my Tor exit node see / do / harm? He can alter the content, by modifying and transmitting invalid transactions to the network but this will have no effect on me, e.g. can't steal coins or send them on my behalf or intercept my payments, right? It's not clear for me what data would such a node see? Why would you spend money to setup a spy node for this what relevant data can it give you? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT1nafAAoJEIN/pSyBJlsR8GYIAL9LkZvPbKjJ6cUxlC4yRKay YUumAafCKYMvp8Ywvz3CWpC4Gncn+v29hhJu/Nc0wSItAnf4suwrAFtBAwAYlUx8 a1J6S1hgGXCBWDZcGHDc1Xt2lLzvijDcilSZfQWXnAdoEaZyln/7Kn+o/fFcXG6h DUkSCSe9M3tN/tZBcZrhBXTENhoJ6MZldcgey6Ky0qLkmI3GCd0MhM+D15xl1LkT 6IS2r2y0RUOxkbg/SuSzFS8vnNTTWmZpbECo3Qq98W41X0M3ZtjOlaByPZXFX5K9 +HUeiptV9zukSdIRcuGH1PUQvU9nk+G1rFKr0dXu4oPvAUxqyw9uCTFgHXczuQY= =gw3W -END PGP SIGNATURE- -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
On Fri, Jul 25, 2014 at 12:30:11PM +0200, Mike Hearn wrote: Ok... 'time' on the blockchain could be 'gamed' ... but with great difficulty. Unfortunately not: miners have in the past routinely gamed the timestamp in order to use it as an extra nonce and squeeze some more gigahashes out of their hardware/pool. Also remember that currently the chain could be dominated by a coalition of just two pools. There's a solution to both of these problems.. https://github.com/CatcoinOfficial/CatcoinRelease/commit/0d03a5b3d8bb7bc3c935e7196c5d807da997cf9c If you want a really reliable time source, use at least three block chains and make sure they all agree within an hour. An application presented with a fake blockchain can use quite a few heuristics to test the 'validity' of the block chain. The app cannot tell if it was given a truncated chain. You could keep such an app stuck in the past forever. This is often a problem. Reliable 'time' has been impossible up until now - because you need to trust the time source, and that can always be faked. Using the blockchain as an approximate time source gives you a world wide consensus without direct trust of any player. Much though I hate to be a party pooper, you could currently get Bitcoin-level trusted time by just polling at least two or three independent servers e.g. google.com, baidu.cn, yandex.ru(they all serve time via HTTPS headers). Well, being as how I don't trust Bitcoin anyway because it includes SSL, yes, you could get 'bitcoin-level' trust. If we crack the mining decentralisation problem then this argument becomes a lot stronger, but for now .. But if you actually want something secure, you look at the altcoin space which solved the mining decentralization problem when Litecoin came out, and this also solves the having to trust a single source code base. There is lots of code diversity out there in altcoins, and what appears to me to be a really strong cryptographically sound time source, but only if you use multiple diverse sources. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
