Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
An attacker with some small hashpower isolates you (as an individual) from the network by MITMing your network. You just switch the the attackers chain as if nothing happened because of the network rule that defines it as OK. Today, you will see that you're behind and warn the user. Was it really so hard to write a three-sentence paragraph to clarify the attack instead of insulting people? Still, posting ideas here without spending time to ensure you understand the Bitcoin network well is frowned upon. Matt On 12/23/13 17:51, Ryan Carboni wrote: I think you misunderstood my statement. If time 3 days, and after 4 blocks have been mined, then difficulty would be reset. In theory, one would have to isolate roughly one percent of the Bitcoin network's hashing power to do so. Which would indicate an attack by a state actor as opposed to anything else. Arguably, the safest way to run Bitcoin is through a proprietary dial-up network. On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach m...@monetize.io mailto:m...@monetize.io wrote: Ryan, these sort of adjustments introduce security risks. If you were isolated from the main chain by a low-hashpower attacker, how would you know? They'd need just three days without you noticing that network block generation has stalled - maybe they wait for a long weekend - then after that the block rate is normal but completely controlled by the attacker (and isolated from mainnet). There are fast acting alternative difficulty adjustment algorithms being explored by some alts, such as the 9-block interval, 144-block window, Parks-McClellan FIR filter used by Freicoin to recover from just such a mining bubble. If it were to happen to bitcoin, there would be sophisticated alternative to turn to, and enough time to make the change. On 12/22/2013 07:10 PM, Ryan Carboni wrote: I think Bitcoin should have a sanity check: after three days if only four blocks have been mined, difficulty should be adjusted downwards. This might become important in the near future. I project a Bitcoin mining bubble. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Peer Discovery and Overlay
Some really nice efforts out there to map and analyze the bitcoin P2P network. The current protocol apparently recommends returning up to 2500 addresses from 'getaddr'. I'm not sure how much clients are expected to probe the address space in order to select 'far-apart' peers, or how much such an process would even attempt to achieve. How much does it matter if the ability to discover the entire network of peers is fast or slow? There are probably pros and cons to both. Is there any thought to how existing bitcoin node relations, and the ease at which peers can be discovered, becomes a service in itself, or even possibly a vulnerability? Are there any past instances of applications hijacking or interfacing with the exiting p2p messages, or abusing 'getaddr' functionality? Are there any guidelines on this, or should there be? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman jer...@taplink.co wrote: Are there any past instances of applications hijacking or interfacing with the exiting p2p messages, or abusing 'getaddr' functionality? Are there any guidelines on this, or should there be? There was a BIP by Stefan Thomas for adding custom services to the protocol. Discovery would be helpful here too. If this was added, it wouldn't be intended for use in a hostile way though. This one was the custom services BIP. It defines a change to the version message and also custom sub-commands. https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki This one discusses how network discovery should be handles. https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
On Tue, Dec 24, 2013 at 12:52:46AM -0800, Jeremy Spilman wrote: Some really nice efforts out there to map and analyze the bitcoin P2P network. The current protocol apparently recommends returning up to 2500 addresses from 'getaddr'. I'm not sure how much clients are expected to probe the address space in order to select 'far-apart' peers, or how much such an process would even attempt to achieve. The logic is that by simply connecting to peers at random you keep the network structure as a whole randomized. You don't need to make any specific attempt at connecting to far-apart peers. How much does it matter if the ability to discover the entire network of peers is fast or slow? There are probably pros and cons to both. Is there any thought to how existing bitcoin node relations, and the ease at which peers can be discovered, becomes a service in itself, or even possibly a vulnerability? Keep in mind it's easy for better knowledge of the network to be a vulnerability; the number of full nodes is small enough that DoS attacking all of them is quite feasible. The other big vulnerability is that getaddr data is best effort; we currently have no mechanism to ensure that nodes are in fact operated by separate individuals. It'd be quite easy for someone to set up a relatively small number of nodes that only advertise themselves in the getaddr information. Over time they would get proportionally more incoming connections than is fair As for node addresses being a service, that's what the DNS seeds are! bitcoinj clients, for instance, depend very heavily on those seeds and can be easily compromised in a variety of ways by them. -- 'peter'[:-1]@petertodd.org 92a315c01cfc115d7f1b40dc44edbafd504b0d7498b0704a signature.asc Description: Digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
I was concerned about this issue so we sponsored BlueMatt to implement an address database for bitcoinj. In the future it won't be entirely reliant on what DNS tells it. Warren On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd p...@petertodd.org wrote: As for node addresses being a service, that's what the DNS seeds are! bitcoinj clients, for instance, depend very heavily on those seeds and can be easily compromised in a variety of ways by them. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
Thanks Warren! That's great. It's also a prerequisite for chain pruning, so it's not only about decentralisation but also scalability. Looking forward to reviewing and merging that. On Tue, Dec 24, 2013 at 6:11 PM, Warren Togami Jr. wtog...@gmail.comwrote: I was concerned about this issue so we sponsored BlueMatt to implement an address database for bitcoinj. In the future it won't be entirely reliant on what DNS tells it. Warren On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd p...@petertodd.org wrote: As for node addresses being a service, that's what the DNS seeds are! bitcoinj clients, for instance, depend very heavily on those seeds and can be easily compromised in a variety of ways by them. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 41
You just completely ignored my point. I'm not sure who's trying to insult whom, or if you're attempting an argumentum ad hominem. My idea is completely valid. The only way to man in the middle to have such a large percentage of hash power is to either a) attack a pool (which people would notice when their withdrawals go nowhere), b) attack a large number of nodes, which must have enough combined hash power to mine four blocks within three days for people to notice (I think it is unlikely for Bitcoin point of sale nodes to have significant hash power), or c) the attacker himself has 1% of the hash power and is diverting it to conduct a man in the middle attack against one single person (as opposed to a major retailer who has a round the clock IT staff). In order for a large number of nodes to be attacked, it must be by someone who either is a state actor or an ISP, at which point you've already lost. It's really simple math, it require on even the most optimistic estimates a tenth of a percent of the total network hash power to mine 4 blocks within three days with good luck. Or maybe this single person is on vacation, then it would take a hundredth of a percent of the total hash power over two weeks. I think very few people even have a hundredth of a percent of the total hash power, which goes to show how secure the network is, and how little my proposal would weaken network security. I'll concede that difficulty could be reduced only by 80% if only four blocks were mined in 3 days, which would provide sufficient margin against these proposed man in the middle attacks, because block-chain growth would be noticeably reduced. But I repeat myself. Repeatedly. I wish you would understand my points. I'm making a good faith effort to provide an original idea before it's possibly too late. But fine. I have nothing more to add, and it's the holidays. On Tue, Dec 24, 2013 at 2:47 AM, bitcoin-development-requ...@lists.sourceforge.net wrote: An attacker with some small hashpower isolates you (as an individual) from the network by MITMing your network. You just switch the the attackers chain as if nothing happened because of the network rule that defines it as OK. Today, you will see that you're behind and warn the user. Was it really so hard to write a three-sentence paragraph to clarify the attack instead of insulting people? Still, posting ideas here without spending time to ensure you understand the Bitcoin network well is frowned upon. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
