Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
That was essentially what we did in the end, we replaced the network identifier (main/test) with the genesis block hash. The result is never going to accidentally work with Bitcoin Core (nor vice-versa), but is readily extensible to any other altcoins that want to use the specification without requiring any sort of central registry. Interesting approach, and I also think that requiring a central registry would be potentially harmful. However, I think it might not be adequate to think of the network identifier as being congruent with the genesis block hash. In the theoretical case of the blockchain being continued on two forked chains (with two communities which prefer one of the chains each), clients would not be prevented from interpreting messages on the wrong chain. Best regards, Isidor -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] determining change addresses using the least significant digits
Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Any thoughts? Best regards, Isidor -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Hi there, comments in-line: I later wrote up the idea in the context of adding Zerocoin to Bitcoin: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html For the sake of maximum clarity with respect to modelling the value of a Bitcoin, I don't think that approaches which change the number of coins that can possibly be circulated should be encouraged. So, I like the idea of having the sacrificed coins appearing in the mining fees in a future block. But what is meant with OP_DEPTH in this context? From what I read, this operation just manipulates the stack size when evaluating the script, so I don't see how it would affect miner incentives. Best regards, Isidor -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). Why not serialize some kind of blockchain identifier with the messages? Arbitrarily deviating from a given design choice just for the sake of doing it differently may serve the goal of creating more overall code diversity, but would not necessarily serve the quality of the blockchain network where it is done for. Best regards, Isidor -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Hi there, some thoughts in-line: Finally, distributors of consumer wallets can use this research in order to distribute their wallet with policies which may be less prone to Tor-specific attacks. Or leave this out altogether if their audience has different expectations for connecting to Bitcoin. Sure. I guess there will be wallets for all kinds of people in future, sharing a common core that they can customise (this is certainly the vision and general direction for bitcoinj, and it's working out OK). To clarify, my comments above were for mainstream granny-focused wallets. Wallets designed for crypto geeks can and should expose all the knobs to let people run wild. I hear that. But I don't see why mainstream wallets and wallets designed for crypto research should not share a common core. Nor do I understand why having a common core for different types of wallets should be reserved for BitcoinJ. When Bitcoin was pretty new, having a less customizable core did probably have more of a merit in order to achieve network stability through monoculture. But as of today, Bitcoin has proven itself as being capable of allowing a variety of client application to run on the network, so why should the reference implementation not reflect this kind of diversity? The policy the mainstream distribution imposes upon the core can still be rather restrictive. One possible direction to go is to use Tor for writing to the network and use general link encryption and better Bloom filtering for reading it. Thus new transactions would pop out of Tor exits, but there isn't much they can do that's malicious there except mutate them or block them entirely. If you insert the same transaction into the P2P network via say 10 randomly chosen exits, the worst a malicious mutator can do is race the real transaction and that's no different to a malicious P2P node. Even in a world where an attacker has DoS-banned a lot of nodes and now controls your TX submission path entirely, it's hard to see how it helps them. It might deserve some research in order to determine how Tor's privacy guarantees might be impacted if we allow attackers to mess around with exit node choices in a rather predictable and low-cost manner. Unfortunately, I can't think of another (non-Bitcoin) application which puts Tor to a similar test. The nice thing about the above approach is that it solves the latency problems. Startup speed is really an issue for reading from the network: just syncing the block chain is already enough of a speed hit without adding consensus sync as well. But if you're syncing the block chain via the clearnet you can connect to Tor in parallel so that by the time the user has scanned a QR code, verified the details on the screen and then pressed the Pay button, you have a warm connection and can upload the TX through that. It reduces the level of startup time optimisation needed, although Tor consensus download is still too slow even to race a QR code scan at the moment. I think tuning the consensus caching process and switching to a fresh one on the fly might be the way to go. I do agree that hybrid clearnet/Tor approaches come with interesting performance properties. When BIP70 is in use, you wouldn't write the tx to the network yourself but you could download the PaymentRequest and upload the Payment message via an SSLd Tor connection to the merchant. Then malicious exits can only DoS you but not do anything else so there's no need for multiple exit paths simultaneously. BIP70 is interesting, indeed, although I still fail to understand why (according to the specs I saw) the PaymentRequest message is signed, but not the Payment message. But in context of the discussed protocol issues, I think it just moves the issue from the payer to the payee, so it may or may not partially relieve network-related issues, depending on the usage scenario. Best regards, Isidor -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
[...] I'm confused by this, I run quite a few nodes exclusively on tor and chart their connectivity and have seen no such connection dropping behaviour. In my experience the problem has always been getting bootstrapped. Most nodes hardly give any hidden service nodes in their getaddr. (this has been improved in master by including a set of hidden service seed nodes) But this assumes -onlynet=tor. Tor with exit nodes should be less problematic, unless someone managed to DoSban all the exit nodes as described in the paper (but I've never seen such an attack myself). When refering to getting bootstrapped, do you only mean collecting node addresses, or also syncing blocks? If you're saying the drops in connection counts are likely to be not caused by a DoSban attack on the exit nodes, what could be other reasons to look into? Can you tell me more about how you measured this? [As an aside I agree that there are lots of things to improve here, but the fact that users can in theory be forced off of tor via DOS attacks is not immediately concerning to me because its a conscious choice users would make to abandon their privacy (and the behaviour of the system here is known and intentional). There are other mechanisms available for people to relay their transactions than connecting directly to the bitcoin network; so their choice isn't just abandon privacy or don't use bitcoin at all.] Right, there's something to be said for splitting your own transaction submission from normal P2P networking and transaction relay. (esp for non-SPV wallets which don't inherently leak any information about their addresses) There was a pull request about this for Bitcoin Core one, maybe I closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 . Great! I find it very interesting to research options for splitting communication between Tor and non-Tor as long as the introduced information leakage between both connection methods can be proved to be nonexistent or negligible. In the case of Bitcoin, this makes me wonder about an attack that could look approximately like this: * Node A connects to Bitcoin using Tor (for submitting transactions) and IPv4 (for all other communication). * Node B strives for direct IPv4 connections with node A * Node B uses the direct IPv4 connections in order to supply Node A with additional peer addresses not supplied to any other nodes * Node B observes these additional peer addresses For transactions submitted to the additional peer addresses supplied by node B, how to prevent that the probability of these originating from node A is higher than for originating from other nodes? For handling block propagation using non-Tor connections, it's probably harder to create information leaks, as the logic for handling disagreement about blocks is pretty well-researched, meaning that it's less important where the blocks come from. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
The goal is to have an opportunity cost to breaking the rules. Proof of Burn is a real cost for following the rules. For every participant who could try to decide about the adequateness of the cost, no direct effect comes from the difference between Proof of Burn, and approaches which keep the Bitcoins inside the set of outputs that can still participate. So, any notion which differentiates with respect to this must make some assumption about what defines the interest of the Bitcoin nodes as a community. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
[...] And, on the flip side if the host is persistently behind tor, even with some watermarkable behaviour, their privacy is protected. So making sure that hosts can continually use tor (or similar systems) should be the higher priority. (And, of course, not reimplementing tor leverages the millions of dollars of investment and dozens of subject matter experts working on that system). Reimplementing Tor would not only mean to lose all the investment that ran into Tor, but also to lose a large user base. We can see this with TorCoin. Still, the fact that Bitcoin is a use case for Tor which measurably shows some limits where it is not fully clear if Tor or Bitcoin is to be blamed does not only mean that both projects may have to evolve in order to properly solve the issue, but also that the means of interfacing between both projects may have to be extended. Ideally, in a way which does not require to run a separate Tor and/or Bitcoin network in order to work, but which will be generic enough to satisfy both sides' need to still work in a standalone manner. But I do see huge merit in exploring better ways of synergy between the projects. For example, Tor's hardcoded circuit length may be considered as a hack which was only necessary due to the lack of a suitable resource compensation mechanism. Which is something that is available with Bitcoin. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
[...] The Bitcoin miner will include burn transactions because they offer Bitcoin fees. Bitcoin miner can not selectively block side chains since the hashes associated with the burn do not disclose which side chain or other project they are for. Here you have a “merged mining” that does not need Bitcoin miner support or even consent. Miners might decide to block all burn transactions, and other nodes might decide to stop relaying them. This may be considered as preferable by all participants who do not want to add more potential for deflation. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
[As an aside I agree that there are lots of things to improve here, but the fact that users can in theory be forced off of tor via DOS attacks is not immediately concerning to me because its a conscious choice users would make to abandon their privacy Bitcoin already has a large population of users who have little or no technical skill, it wouldn't surprise me at all if it was found to be the clear majority by now. Assuming success and growth in future, very few users will make any decisions at all about their privacy, they will just accept the defaults. In such a world no consumer wallet is going to directly expose Tor to end users - if used at all it'll just be used behind the scenes. So automated fallback or control over exits would be a concern for such wallets. In order to get more synergy between Bitcoin users of varying skill levels, my suggestion would be a cleaner separation between technical mechanisms and policies (possibly suitable for users without technical skills). Core development would mean providing suitable mechanisms by which it is possible to run Bitcoin on different constraints. This may include ways to handle attacks specific to the Tor/Bitcoin combination. People who like to research what is possible with the protocol can then experiment on how these mechanisms can be used in order to mitigate these attacks. Finally, distributors of consumer wallets can use this research in order to distribute their wallet with policies which may be less prone to Tor-specific attacks. Or leave this out altogether if their audience has different expectations for connecting to Bitcoin. The tricky part is probably to figure out what is the greatest common denominator of what keeps Bitcoin stable and running while still leaving room for customized policies. But I think that separating concerns like this is better than letting a debate about how to mitigate certain Tor-related attacks evolve towards a debate about Tor or not Tor. My gut feeling about this stuff has changed over time. I don't think it'd be a great idea to tie Bitcoin to Tor too deeply, convenient though its infrastructure is. Most apps don't need a whole lot of onion routing - a small amount built in to the p2p layer would be sufficient. Tor is huge, complicated and could be a liability in future. I think it would be very interesting to explore alternatives for Tor. But at this point, completely abandoning Tor would mean that users either have to agree to have their transactions correlated to their IP address, or to trust their transactions to a third party where they are not subject to the security guarantees Bitcoin's logic can provide anymore. In my opinion, it's a rather huge sacrifice. What I find interesting, however, is that a lot of suggestions I see with respect to attacks related to Tor/Bitcoin (including my own) involve some kind of extra effort required for Tor users on Bitcoin in order to protect themselves against these attacks. So, it may be interesting to explore if it is viable to think of Tor's privacy guarantees as coming for free. Going from there, if it cannot be guaranteed to work completely for free, the question would be to what extent the required extra effort should be a shared effort of the network, and to what extent users requiring the improved privacy should use their own resources in order to make it possible. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Hi Gregory, response below quote: Since this attack vector has been discussed, I started making some measurements on how effective it is to connect to Bitcoin using Tor, and I found that the number of connections dropping to near-zero is a situation which occurs rather frequently, which suggests that there is still room to improve on the DoS handling. I'm confused by this, I run quite a few nodes exclusively on tor and chart their connectivity and have seen no such connection dropping behaviour. Can you tell me more about how you measured this? When you say running exclusively on Tor, what do you mean exactly? Do you also connect or allow connections through hidden services? I made outbound connections through Tor exit points the only way to connect to Bitcoin, and increased the number of allowed outbound connection in order to get more meaningful values. Lately, I could see unusual behaviour at: * 2014-11-28 13:14 UTC * 2014-11-25 07:32 UTC * 2014-11-24 13:06 UTC Anything I should look into? [As an aside I agree that there are lots of things to improve here, but the fact that users can in theory be forced off of tor via DOS attacks is not immediately concerning to me because its a conscious choice users would make to abandon their privacy (and the behaviour of the system here is known and intentional). There are other mechanisms available for people to relay their transactions than connecting directly to the bitcoin network; so their choice isn't just abandon privacy or don't use bitcoin at all.] I think this issue is more important than it seems. Firstly, when running Tor-only, there are still attack vectors which make use of the DoS protection deficiencies. Secondly, if we tell people not to connect directly if they want privacy, how do we ensure that these indirect methods will not come with implications for their privacy? Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Hello there, quote: Please see also the following: https://cpunks.org//pipermail/cypherpunks/2014-November/005971.html I agree about the severity of the Tor/Bitcoin issue, but I see no point in bashing Bitcoin's financial privacy characteristics as the linked pages seem to do. Bitcoin can be useful as a part of a strategy to improve on privacy, but it does not intend to be a run-and-forget solution for doing so. A lot of issues found in this context can actually be traced back to Tor's characteristics already known before. It's just that Bitcoin makes Tor's deficiencies more measurable - before Bitcoin, those interested in researching how Tor performs in an automated context where a much smaller community. In the end, I guess both projects can benefit from the research we can do now. Respect, - -Odinn Jeff Garzik: I don't recall being contacted directly, but the attack has been discussed. It relies on a number of conditions. For example, if you are over Tor, they try to kick the machine off Tor, _assuming_ that it will fall back to non-Tor. That's only true for dual stack nodes, which are not really 100% anonymous anyway -- you're operating from your public IP anyway. Generally, it cannot be said that the attack vector described here is irrelevant for non-dual-stack nodes. An attacker might not be able to collect IP addresses of Tor-only nodes, but he can try to kick the users from all Tor exit nodes he does not control, and proceed with other attacks when a large number of Tor-only users connect through his Tor exit node(s). Since this attack vector has been discussed, I started making some measurements on how effective it is to connect to Bitcoin using Tor, and I found that the number of connections dropping to near-zero is a situation which occurs rather frequently, which suggests that there is still room to improve on the DoS handling. Best regards, Isidor -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Hi Mike, thanks for your assessment. Please find my replies in-line: DKIM is hardly a PoW; signing is cheap and gets cheaper all the time. I used to work in the email business and big bulk mailers all spent far more CPU time on other aspects of their business, the overhead of DKIM is irrelevant. Well, as long as bulk mailing companies run around investing into per-destination DKIM toggling, stating that they want to cut down CPU usage due to crypto processing, I tend to believe that it can have an important impact depending on the setup. Of course, I cannot rule out the possibility that they would be better off investing into profiling CPU usage, and/or exploring a higher ROI possibly coming from using more CPU time on other processing. I see no point neglecting an issue just because there are business models where it is irrelevant, though. PoW didn't work in the anti spam world because it (amongst other problems) mixes up bulk mail and spam, which are not the same thing. Very common conceptual error though. I did not say so, either. But bulk mailing and e-mail spam are not orthogonal with respect to the technical characteristics that make them possible. And nor are DKIM and PoW/hash-cash fully orthogonal. I like the objections you raised. Avoiding DKIM because of the CPU costs involved might be as groundless as stating we don't use HTTPS in order to save CPU time. Still, these substantiations can be found in the wild, and they won't disappear because we discuss them here on a theoretical level. If you assume conceptual errors, though, I would suggest we discuss the e-mail topic off-list, though. I simplify things a bit in order to not bore the group with too much text about non-Bitcoin stuff, but this does not mean that I'm not familiar with, or am not open for discussing the subtle differences of different approaches that have been researched in the e-mail business. humans also don't care if their patience is put to the test by having to wait until one Tor exit node is finally unbanned, or by waiting for the connection PoW to finish because it temporarily got harder due to an attack. They don't? This is news to me. Humans always care. One of the surest ways to hurt your online business is to have a slow website because lots of users will give up rather than tolerate a few seconds of latency. At Google we actually had formulas that could relate a change in web search latency to revenue impact. You might want to re-read my statement more carefully. I did not say they don't care about delays, but I do say that they don't care where the delays come from. It is a known fact that Google will also penalize web sites which have high latencies, so the top results appear as being also of technical quality. But neither the users nor Google will care if the web site is slow because the site owner did not allocate proper resources for running the frontend quickly, or if the database server is making things slow. So humans very much care! I actually doubt that any reasonable mobile wallet will use the new Tor support bitcoinj by default, for example, because it imposes quite some startup cost when the downloaded consensus isn't fresh, and slow startup is painful. It could be optimised but nobody has done that. For long running desktop wallets where startup time can be amortised over hours or days, I guess it makes more sense. I agree that improving on the performance of the consensus bootstrapping logic is an interesting topic. I agree that PoW tokens might make sense as a last resort if nodes can't even put a connection at the bottom of a priority queue and you're right that it may be a useful tool in a shared toolbox. However if we reach the point where users are all being PoWd then we're already pretty hosed and it's probably close to game over :( I don't think this was ever about _all_ IPs suffering from DoS measures. But I do think that Bitcoin will already suffer if we get to a point where it is practically useless when being used over Tor, or where this is only possible by immediately sacrificing the privacy improvement Tor introduces. I'd say, better have a few Tor-based users realize that they should look for a fixed update because their client has to do PoW for connecting, rather than having all Tor-based users locked out. I think Tor is a separate issue. If an attacker wants to either force all users off Tor, or force them via a handful of exits, then this attack is quite detectable already and wallets could already decide to simply give up on Tor at that point automatically. No PoW needed. Well, ideally, nodes would disconnect a banned IP with some kind of notice saying why it was banned, but that's a small improvement. I fully agree. A ban notice could also make it easier to track down DoS handling issues triggered by incompatible updates, and possibly make it harder for someone to issue bans for malicious reasons without being noticed.
Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Hi Mike, hi Ivan, hi all, Since when? This has been a recognized approach since people called it hashcash ([1] - before cryptocurrencies were even invented). I only know of one site that worked the way you propose: TicketMaster, a long time ago. They used it as a less harsh form of blocking for IPs that they strongly suspected were bots, which is what you suggest indeed. But 99% of the hard work of that system was in scoring the connections. The actual PoW part didn't work that great because bots have much more patience than humans do. I think the proposal back then was targeted at e-mail delivery. Interestingly, one of today's most common approaches against unsolicited e-mails, DKIM, can also be considered as being a relative to PoW if we consider that bulk mailer operators don't like it because of the CPU burden it creates. But with e-mail, people tend to see it even as an advantage to also have identification of the participants, so it's no surprise that pure PoW approaches did not achieve importance. With cryptocurrencies, it's different. Combating DoS without creating additional ways to identify users is something where many interested users can be found. Humans may have less patience than an attacker who just wants to achieve his DoS objective in a batch processing manner. But humans also don't care if their patience is put to the test by having to wait until one Tor exit node is finally unbanned, or by waiting for the connection PoW to finish because it temporarily got harder due to an attack. No doubt that a dedicated attacker can have an (even big) advantage resource-wise. But this is no different between the case where both computing power and the number of Tor exit nodes are the resource to compete on, and the case where it's just the resource of Tor exit nodes that gets exhausted. But by giving users the choice of proving their dedication through a connecting PoW challenge, I would expect users having more possibilities of finding their way through a DoS-imposed partial outage. After all, the possibly powerful attacker has to invest his resources into making all access routes to the network unusable, while for well-behaved users, every single access route that still works is useful. Therefore, I think it makes sense to add more degrees of freedom. Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs. And unfortunately those don't work very well these days either :( None of these measures are perfect. But I think we can achieve a solution that is good enough. Hopefully without integrating a centralized captcha provider ;) To be clear, I do not propose to have _all_ clients do complicated work. Just those using an address which has been misbehaving. Yes, I understand, but then you're back to scoring clients - the hard part - and the only question is do you slow down that client by sticking them at the bottom of a work queue or by requiring them to solve a difficult PoW. The best approach is the first one because that scales naturally you don't have to define some notion of misbehaviour, you just prioritise amongst clients. On the one hand, I think that to some extent, the work queue based throttling just moves the problem from making it hard to connect towards making it hard to do something useful with your connection. But as I touched above, I see the merit that comes from the PoW-based approach in allowing well-behaving users to explore multiple axes of putting effort into connecting. Expanding on this approach, I think that the work queue based approach and PoW could be combined, leading to three measures the nodes can use for throttling misbehaving clients: * scaling up connection PoW * throttling the connection on the work queue * throttling the IP on the work queue The challenging part would be to properly tune the extent of the three measures in order to throttle attackers' messages with minimum impact to well-behaving users. The current notion of misbehaviour is only somewhat useful. It's easy to classify reasonable behaviour as harmful and shoot yourself in the foot. We managed this at least once back in 2010 when we actually released a version of Bitcoin that interpreted a normal request to serve the block chain as a DoS attack! It couldn't serve the chain at all! Additionally many things that can be interpreted as an attack like sending a message with a bad signature can also be caused just by mistakes, or version skew during software upgrades. So it's very tricky to get this right. Sure, but that's a different topic. It may not be even realistic to have a model which can be reduced to deciding between purposeful misbehaviour and regular usage. But an attacker who wants to cut off IPs from the network will always use whatever misbehaviour that leads to maximum penalty, meaning that it is a decision between not penalizing at all, or doing so. That's important because one quite common way big sites
Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Hi Mike, thanks for your assessment. Please find my replies in-line: Misbehaving addresses can have their connecting difficulty scaled up, which should make it uneconomic to try to DoS the usage of Tor exit nodes for connecting to Bitcoin. You can't solve DoS by requiring all clients to do complicated work, Since when? This has been a recognized approach since people called it hashcash ([1] - before cryptocurrencies were even invented). I hear your concerns, but even then, I would see the PoW-based approach as an improvement to today's situations. To be clear, I do not propose to have _all_ clients do complicated work. Just those using an address which has been misbehaving. Right now, they cannot connect at all, no matter how much resources they dedicate towards doing so. all that means is that weak clients (like users mobile phones and tablets) are successfully DoSd whereas the attackers botnet of stolen computers sit there solving PoWs. The way I had it in mind, well-behaved clients on an address used by attackers would have more effort to connect because of the PoW, but after that, they can stay connected. The attacker also has to put more effort into connecting, and after sending malformed messages, gets disconnected. So, the attacker would have to perform much more PoW computations in order to keep up his attack. The correct way to solve DoS is by having work prioritisation and queueing mechanisms, then finding ways to distinguish good clients from bad clients. Doing this whilst preserving privacy is hard. Long term the only way to solve it may be to require clients to present some kind of cookie during resource exhaustion events that prove they've been around for a while, thus allowing them to jump the queue. Exactly. Not every user may like to have a cookie by which an observer might get the chance to even link his connection to his previous connections, thereby allowing the discussed deanonymization technique to get even more effective. Maybe having both options would be even better: In case of an attack, those able to solve the anti-DoS PoW can still connect (just maybe slower). Those who wish to run a weak client can choose to sacrifice privacy for connectivity and keep a cookie for connecting. Best regards, Isidor [1] http://www.hashcash.org/papers/hashcash.pdf -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Hi there, quote: [...] If two distinct transactions (with unrelated bitcoin addresses) come from the same set of 8 peers, the attacker can conclude that they originated from the same user. This gives another method (in addition to transaction graph analysis) for an attacker to link different BC addresses of the same user. Using the same set of nodes for posting transactions using unrelated inputs kind of limits the privacy improvement that can be gained from using unrelated inputs in the first place. Similar to how Tor uses different circuits for different hosts to connect to, it may make more sense to only use the same set of nodes for posting a subsequent transaction when the input addresses are also the same. [...] Some details are here: https://www.cryptolux.org/index.php/Bitcoin I also find the topic of banning Tor exit nodes interesting. I wonder if it makes more sense not to ban IP addresses completely, but instead to throttle them using a PoW-based access control scheme. Misbehaving addresses can have their connecting difficulty scaled up, which should make it uneconomic to try to DoS the usage of Tor exit nodes for connecting to Bitcoin. It may also help nodes behind a NAT router if they share their global IP with misconfigured nodes. Best regards, Isidor -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Protocol Specification
Hello Krzysztof, [...] As before, it can be found under: http://enetium.com/resources/Bitcoin.pdf I hope it will prove useful to the community and thank in advance for any further improvement proposals. I think it's great work and provides a good reference for those who want to get some insight into Bitcoin's design. Have you considered putting the document source under version control, which may facilitate tracking future protocol improvements in the document easily? Best regards, Isidor -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
quote: [...] On 4/24/14, Chris Pacia ctpa...@gmail.com wrote: It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. I would much prefer the hassle of a green address notary than always having to make sure I have double what I need to make a purchase. This scheme wouldn't be mandatory. You can still wait for confirmations or rely somehow on existing trust instead if that's better for you on that situation. Considering hotel or car rental payments where the credit card processor reserves a higher amount in order to cover risks, it doesn't seem like anything new or particularly inconvenient that a payment system may require a larger amount than the final price being available. Which brings us to the question: Is it an important characteristic in a payment system that it is capable of quickly spending your last penny? Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
quote: https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most of the pooling-centralization problems. Unfortunately, it is opt-in, and GHash.io doesn't support it. Also most miners don't care and don't do the work to set it up. To do transaction inclusion themselves, they'd need to run a full node, which is a bit more work and resources than just pointing hashpower at a stratum server. If you figure out a way to make GBT widely used (50% hashpower), kudos to you. Well, as soon as miners learn about the merits of controlling the blocks' contents, this issue may get solved by the market pressure of miners expecting this kind of service from their pool. I mean, the dev community constantly has some level of disagreement about the best policies for what to include in blocks. But seen from the perspective of some Bitcoin business or another, certain policies might be more preferable. So if miners start to understand that they could take a stake for their favourite Bitcoin businesses by choosing a mining pool which employs a preferable transaction inclusion policy, the question would not anymore be which pool gives me the most Bitcoins or the lowest variance, regardless of the technical background, but which pools does the best for my Bitcoin economy needs. And this may be a very economically driven decision by itself, considering that the exchange rates for Bitcoins depend on Bitcoin businesses doing well. If we get to this point with respect to user (miner) education, then it is probably only a matter of time until people start to find it cumbersome to mine on a black-box pool and having to manually verify that they still have an agreeable transaction inclusion policy, when they can just mine on a GBT pool and configure things in their mining software. On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez r...@i-rme.es wrote: [...] We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. Bear with me, but this piece of rhetorics struck me. Why even mention those who think it's not harmful, when your next sentence states that their opinion should be ignored completely? Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
quote: On 6/16/14, Mike Hearn m...@plan99.net wrote: If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they don't collectively lemming us all off a cliff by doing that ;) Replace-by-fee doesn't imply the use of green addresses (there's other solutions to 0 conf transactions in that context, for example, scorched earth). And giving up the non-enforceable first-seen default mining policy doesn't mean giving up on the Bitcoin experiment either. If something means giving up on the Bitcoin experiment, then for sure it's not one mining policy or another, but the assumption that we should have one uniform mining policy. If we had a community where enough miners had their own opinion about the best mining policy, and expressed it by choosing an appropriate mining pool, then we would have better decentralized mining based on selfish motives of the miners, rather than based on an abstract thought of centralization is bad, so I will consider how much mining profit from qualitatively interchangable mining pools I'm willing to sacrifice in order to ease my centralization fears. Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
quote: Mike Hearn, why don't we just have all nodes report attempted double spends through the node network. No need to involve the miners at all really, or do your suggestion but also report the double spend attempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can be more sure that a double spend attack was not tried. Attacker would have to hold back second tx by 10-60 seconds and hope that that second tx (with higher fee) get's into a solved block before the first one. This forced delay time ought to make the attack less successful (but not impossible). What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding reporting double spends, this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an every double spend is a misbehaviour policy? Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
In my opinion, the number of full nodes doesn't matter (as long as it's enough to satisfy demand by other nodes). Correct. Still, a high number of nodes has a few other benefits: 1) The more nodes there are, the cheaper it should be to run each one, given that the bandwidth and CPU for serving the chain will be spread over more people. 2) It makes Bitcoin *seem* bigger, more robust and more decentralised, because there are more people uniting to run it. So there's a psychological benefit. Psychological benefit vs. effective benefit involves the danger of destroying trust in the Bitcoin network when there are hard facts for non-robustness while the node number looks big. Therefore, it may make sense to establish better metrics. Also, we don't have a good way to measure capacity vs demand at the moment. Whether we have enough capacity is rather a shot in the dark right now. What matters is how hard it is to run one. Which is why I'm interested to learn the reason behind the drop. Is it insufficient interest, or is running a node too painful? For this purpose I'd like to exclude people running Bitcoin Core on laptops or non-dedicated desktops. I don't think full nodes will ever make sense for consumer wallets again, and I see the bleeding off of those people as natural and expected (as Satoshi did). But if someone feels it's too hard to run on a cheap server then that'd concern me. In my opinion, the characteristic of being able to make use of non-dedicated nodes should be regarded as an advantage of the Bitcoin protocol, and not something to get rid of. Nodes being able to contribute this way may lead to even more robustness than decentralization alone, as they can do so without exposing a fixed address which could be attacked. Best regards, Isidor -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. I'm not a core developer, but I would certainly hope that those who have commit access to the Bitcoin repository don't let themselves be pressured by a company holding back user funds in order to get a patch included into the Bitcoin source code. I think this is less a matter of whose fault it is if a company running a custom wallet implementation has problems peering with a network mostly running another, community-based wallet implementation. It is a matter of common sense that it's just not practical to try to quickly apply an update to a distributed network, which may possibly cause problems with peering and consensus finding. When working with a protocol based on mutual agreement of a large user base, a single entity like MtGox would be better off trying to have their preferred changes implemented slowly if at all, while solving their immediate issues on their side. Problems with transactions being accepted can often be solved by changing the wallet client's way of peering with other nodes, without changing the protocol at all. Thinking this further, I am kind of surprised that something like this can even become an issue worth discussing. I never heard of a bank which would try to create pressure by suspending money withdrawals until the TCP/IP protocol is changed to match their preferences. Best regards, Isidor Zeuner -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
