Re: [Bitcoin-development] BIP 21 (modification BIP 20)
On Monday, January 30, 2012 1:07:16 PM thoma...@gmx.de wrote: I too support BIP21 over BIP20. BIP 21 is not forwards-compatible, and is intentionally designed to be biased toward decimal. BIP 20 is neutrally biased, forward-compatible, and has been implemented for over a year now. If BIP 20 is to be Superceded, a proposal should improve on it, not make it worse with bigotry and short-sightedness. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 21 (modification BIP 20)
Hi all, Speaking on behalf of the MultiBit team (Jim's currently on holiday), we will not be supporting Tonal Bitcoins anytime soon. Therefore we back the BIP 21 proposal. At present MultiBit does not support the message or send fields but we would be happy to add this functionality as required. Regarding the idea of a signed URI, it is appealing, however, it may not work. If I understand it correctly, the main idea appears to be to protect a URI from malicious replacement (at MultiBit we were concerned that a Bitcoin swatch would be subjected to the same attack vector and we came up with the term swatch swabbing). If a Bitcoin URI is served up from a trusted source (e.g. a merchant site over HTTPS) then there is no need for signing. It should be assumed that the merchant will offer a clean room payment area so that no untrusted JavaScript will creep into the final page and wreak havoc. It would seem that in any situation where the attacker has complete control over the content of the URI they will be able to successfully swab it to match their own fraudulent address. Imagine attempting to protect a QR code posted against a pole attempting to get BTC donations for a charity. How long before that was replaced by a different version operated by the thieves with good signatures all round? Of course, I may have misunderstood so I would welcome further discussion. One field that the MultiBit team would like to add to the BIP 21 proposal is expires which would contain an ISO8601 formatted date/time in UTC (e.g. 2000-01-01T23:59:59Z). This would allow merchants to issue Bitcoin URIs that would expose them to a currency/inventory risk for a defined period of time. Kind regards, Gary Rowe PS First post to this list -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
Cool design. It seems resilient to many attacks. A Sybil attack coming from a large botnet (which controls addresses in many ranges) can still fill all buckets in both tables, I think. As far as I can tell, that wasn't possible with the old design. Given the randomness in Pieter's design, that seems extremely unlikely / difficult to do. Is it possible to do a back-of-the-envelope calculation to figure out what percentage of nodes on the network an attacker would have to control to have a (say) 1% chance of a successful Sybil attack? I like this change; I'd like to pull it for the 0.6 release. I've also been wondering if it is time to remove the IRC bootstrapping mechanism; it would remove a fair bit of code and we'd stop getting reports that various ISPs tag bitcoin as malware. When testing the list of built-in bootstrapping IP addresses I always connect fairly quickly, and the DNS seeding hosts seems to be working nicely, too. -- -- Gavin Andresen -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: I've also been wondering if it is time to remove the IRC bootstrapping mechanism; it would remove a fair bit of code and we'd stop getting reports that various ISPs tag bitcoin as malware. When testing the list of built-in bootstrapping IP addresses I always connect fairly quickly, and the DNS seeding hosts seems to be working nicely, too. Sο— would we remove it or leave it deactivated as a fallback users can turn on? I have two different thoughts about IRC depending on the answer. I think it's important that we have more mechanisms then just DNS and hardcoded seednodes. This is important because the mechanisms we have are all pretty subject to blocking. Now— before you say it— Bitcoin isn't intended to be blocking resistant (combine it with Tor and Tor anti-censorship tools) but by making blocking a bit harder we discourage people from even trying, even if we're not seriously in the anti-blocking business— and it gives bitcoin users more confidence because there is a bit less FUD What if your ISP blocks it?? It uses DNS! Someone might take away the domains! SOPA PIPI ACTA CIPA Alakazam. Is the fact that users can addnodes / addr.txt enough of an alternative to address this? _If so_, then removing it is a good idea. I volunteer to maintain a multi-channel joining node for the foreseeable future to avoid letting old clients get partitioned (several people need to do this). An area where I think our mechanisms are inadequate absent IRC is announcing new nodes. I had a new listener up for over a week recently and was basically getting no inbound until I enabled IRC. I volunteer to do some measurement of this (e.g. bring up some nodes with no irc and find out how long until sipa hears about them). If DNS seeds are slow to learn about new nodes we may need to add a simple UDP announcement feature. In any case, I hadn't been thinking that we would completely remove IRC— I was expecting us to keep IRC around but turned off. In particular I think it may be a little risky to turn off IRC at the same time as deploying addrman, because if addrman has unexpected bad behavior IRC is what may keep things going. Obviously it should be well tested enough to feel confident, but belt-and-suspenders is the way to go. If we do keep in the long run I think it's important to _fix_ IRC. Right now it has some really stupid behavior which is highly pro-partitioning. */who only returns a few nodes, and because most idlers aren't actually working (no port forward) it's usually for there to be only a few that work. (I've never seen zero, but I've seen 1). *Other than who we only learn about nodes when they join. But the stable long lived nodes we need to hear about seldom rejoin. Nonuseful windows boxes go up and down a lot. *Nodes sit in a single channel forever. There are 100 of them. Especially with fewer clients on line nodes may be sitting alone with no correctly working nodes with them. *Nodes recently seen on IRC are highly promoted in the peer selection. So, here is an updated irc.cpp which I've been running (in various versions) for a while: http://people.xiph.org/~greg/irc.cpp It does the following things: * Only stays connected for a half hour * If its sure its not listening it uses a random nick so people won't try to connect * Reconnects if it needs more connections * If the node is actually listening (evidence by actual incoming connections) it reconnects on its own every 1-2 hours and joins two channels at random rather than one. (it doesn't change peer selection— It's hard to be confident of the impact of that change. I think addrman makes it less of an issue) I've only not submitted it as a pull request because I haven't had a chance to test to my standards, and because I felt unsure about the future of IRC. I feel strongly that if we're going to keep IRC as a backup we should fix it. If we're not going to bother then thats fine— but I think we need to think carefully if we're doing enough for bootstraping (with the points I made) without it. Certainly getting it off by default would be a good move. The botnet allegations are horrible. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: Given the randomness in Pieter's design, that seems extremely unlikely / difficult to do. Is it possible to do a back-of-the-envelope calculation to figure out what percentage of nodes on the network an attacker would have to control to have a (say) 1% chance of a successful Sybil attack? The randomness prevents finely crafted attacks since an attacker can't predict which bucket his address ends up in. I don't think it helps against brute force attacks though. If 60% of the network's nodes are controlled by an evil botnet, 60% of the nodes we pull out of the address manager point to the attacker. If a client has 8 connections to the network, a Sybil attack would succeed 1.7% of the time. At current network size, 60% of listening nodes is 2,800; only 2-5% of a decent botnet. Nodes that accept incoming connections are far less vulnerable, since the probability of success decreases exponentially with the number of connections. 95% botnet control with 125 connections has 10^-6 chance of success. Perhaps we could add a command-line option for increasing the maximum number of outbound connections. That way, nodes unable to accept incoming connections can easily decrease their susceptibility to Sybil attack. I've also been wondering if it is time to remove the IRC bootstrapping mechanism; it would remove a fair bit of code and we'd stop getting reports that various ISPs tag bitcoin as malware. When testing the list of built-in bootstrapping IP addresses I always connect fairly quickly, and the DNS seeding hosts seems to be working nicely, too. I think it should be disabled by default one release after the new address manager is released. That way, we're not changing too many parts of the bootstrapping process at once. As an aside, I can't help but wonder whether ISPs blocking IRC traffic filters some botnets out of the IRC bootstrapping channels; keeping them more pure. -- Michael -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 21 (modification BIP 20)
Regarding the idea of a signed URI, it is appealing, however, it may not work. If I understand it correctly, the main idea appears to be to protect a URI from malicious replacement No. The main idea is to protect the consumer against a malicious seller pretending that he has not been paid. Please read the forum. If a Bitcoin URI is served up from a trusted source (e.g. a merchant site over HTTPS) then there is no need for signing. It should be assumed that the merchant will offer a clean room payment area so that no untrusted JavaScript will creep into the final page and wreak havoc. It would seem that in any situation where the attacker has complete control over the content of the URI they will be able to successfully swab it to match their own fraudulent address. Imagine attempting to protect a QR code posted against a pole attempting to get BTC donations for a charity. How long before that was replaced by a different version operated by the thieves with good signatures all round? Of course, I may have misunderstood so I would welcome further discussion. The bitcoin address that is used to sign URIs will establish the online reputation of the merchant. If a merchant has received a payment and pretends not to have received it, the signed URI will prove him wrong. In principle it would be possible to use HTTPS signatures for that purpose, but this is not really the way HTTPS is supposed to work, and it has disadvantages: - HTTPS is not always available; there are other communication channels. - A website, even a single page, may contain URIs posted by various merchants; we need to distinguish the identity of the merchant from the identity of the website. - with signed URIs, a Bitcoin client can easily keep track of the signatures for all the payments it made. if we used the HTTPS signature of the webpage as receipts, then users would need to save them manually. To my knowledge, nobody does that. One field that the MultiBit team would like to add to the BIP 21 proposal is expires which would contain an ISO8601 formatted date/time in UTC (e.g. 2000-01-01T23:59:59Z). This would allow merchants to issue Bitcoin URIs that would expose them to a currency/inventory risk for a defined period of time. yes, that too. see my proposal here: https://bitcointalk.org/index.php?topic=60828.0;topicseen -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
