Re: [Bitcoin-development] Merge mining
But there's so much 'dry powder' out there (GPUs), I wonder if *not* supporting merge-mining is any better? At least the attacker has to do some unique PoW, so you hope it's costing them something. With lots of people having access to 100TH+ there's not really much 'cost' to doing a 51% attack on an alt-coin beyond a short-term diversion away from 'profitable' mining. At least by supporting merged mining, more miners are likely to 'support' multiple coin types, thus making a 51% attack from an individual/group less straightforward. The rational decision for a non-scam altcoin, is to take advantage of merged mining to get as much security as possible. Exactly. Rob -- 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] Dedicated server for bitcoin.org, your thoughts?
Has anyone seen the talk at 30c3 on the current NSA capabilities? https://www.youtube.com/watch?v=b0w36GAyZIA Specifically they are able to beat the speed of light between you and a website such that if you communicate with Bob, they can sent competing packets that will arrive before Bob's packets. They have realtime deep packet insertion able to inject arbitrary data into an TCP streams and can change file downloads **on the fly**. This can be done remotely. Sourceforge do not have https downloads, so this is yet another reason to move downloads to somewhere that does - like github. The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Revealed as part of the presentation is the fact that if the NSA has access to these capabilities, then so do others and in fact one of the things revealed yesterday was independently discovered already and published. Same goes for the bitcoin.org site - why are we dragging our feet on installing an SSL certificate and redirecting all http to https? While no solution is perfect, it's a lot better than zero defense. You can see the irony of disseminating the bitcoin crypto-currency client in the clear. For anyone who has not seen the video. You will be shocked by what is actually in the wild being used today. It goes way beyond anything imaginable even in science fiction. https://www.youtube.com/watch?v=b0w36GAyZIA Drak -- 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] Dedicated server for bitcoin.org, your thoughts?
On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- 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] Dedicated server for bitcoin.org, your thoughts?
Given that hardly anyone checks the signatures, it's fair to say downloads aren't protected by anything at the moment. SSL for downloads can only raise the bar, never lower it, and if the NSA want to kick off the process of revoking some of the big CA's then I'm game (assuming anyone detects it of course) :) Anyway, nobody is dragging feet, the problem is right now we get what is effectively a huge free subsidy from github and SourceForge for site hosting. The cost is no SSL. So getting SSL would require that we pay for it ourselves, but the primary method we have for funding public goods/infrastructure (the Foundation) which is the subject of various conspiracy theories. Jeremy has made a generous offer further up the thread, the issue being I guess none of us know how much traffic we actually get :( I remember suggesting that we whack Google Analytics or some other statistics package on when the new website design was done and that was rejected for similar reasons (organisations are bad). So we are in a position where we get a subsidy of large but unknown size from various existing US corporations, but moving to different ones is controversial, hence no progress :) On Tue, Dec 31, 2013 at 1:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- 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] Dedicated server for bitcoin.org, your thoughts?
Interesting. I think the original BitDNS discussion was more interesting that what currently is happening with namecoin, see https://bitcointalk.org/index.php?topic=1790.0 Satoshi said there: 1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat. Besides, ICANN is currently selling out the global public namespace - not that anybody really cares about such measly topics as the ownership of global namespaces. And so some guy on the Cayman Islands is now the largest holder of TLD's. On Tue, Dec 31, 2013 at 2:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat here? Okay. The NSA can trivially compromise an HTTPS download site: even ignoring the CA insecurity, and government run CAs certificate authorities issue CA certs to random governments and corporations for dataloss prevention purposes. Not to mention unparalleled access to exploits. The downloads are protected by something far stronger than SSL already, which might even have a chance against the NSA. Actual signatures of the downloads with offline keys. I'm all pro-SSL and all that, but you are— piece by piece— really convincing me that it produces an entirely false sense of security which is entirely unjustified. -- 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] Dedicated server for bitcoin.org, your thoughts?
I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands.One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid.This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting...For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file.You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash.This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly "released", if that's really a problem.I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgradeFormalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions.For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet.On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote:The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress.Oh, it did? When was that? I must have missed this excitement :)Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier.Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- 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] Dedicated server for bitcoin.org, your thoughts?
We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. Jeremy Spilman jer...@taplink.co wrote: I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands. One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid. This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting... For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file. You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash. This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly released, if that's really a problem. I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgrade Formalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions. For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet. On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote: The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress. Oh, it did? When was that? I must have missed this excitement :) Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier. Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- 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
Re: [Bitcoin-development] The insecurity of merge-mining
On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker can 51% attack your altcoin at negligible cost by re-using existing hashing power. I strongly disagree on this isolated point. Using the same logic, Bitcoin is vulnerable to an attacker at negligible cost by re-using existing hashing power from mining Namecoin. Any non-scam altcoin is pretty safe using merged mining, since any would-be attacker is going to have it in their interests to invest in the altcoin instead of attacking it. It's only the scam ones that want to pump dump with no improvements, that are really at risk here. The rational decision for a non-scam altcoin, is to take advantage of merged mining to get as much security as possible. There are also some possible tricks to get the full security of the bitcoin miners even when not all participate in your altcoin (but this area probably needs some studying to get right). You assume the value of a crypto-currency is equal to all miners, it's not. Suppose I create a merge-mined Zerocoin implementation with a 1:1 BTC/ZTC exchange rate enforced by the software. You can't argue this is a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the only thing you can do with the coin is get some privacy. But inevitably some miners won't agree that enabling better privacy is a good thing, or their local governments won't. Either way, they can attack the Zerocoin merge-mined chain with a marginal cost of nearly zero. OTOH if the Zerocoin scheme was implemented by embedding ZTC transactions within standard Bitcoin transactions - even without any attempt at hiding them - the attackers would need a 50% majority of hashing power to succeed. Of course potentially slow confirmations is a trade-off, but that's likely a perfectly OK trade-off in this case. -- 'peter'[:-1]@petertodd.org 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 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] The insecurity of merge-mining
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker can 51% attack your altcoin at negligible cost by re-using existing hashing power. I strongly disagree on this isolated point. Using the same logic, Bitcoin is vulnerable to an attacker at negligible cost by re-using existing hashing power from mining Namecoin. Any non-scam altcoin is pretty safe using merged mining, since any would-be attacker is going to have it in their interests to invest in the altcoin instead of attacking it. It's only the scam ones that want to pump dump with no improvements, that are really at risk here. The rational decision for a non-scam altcoin, is to take advantage of merged mining to get as much security as possible. There are also some possible tricks to get the full security of the bitcoin miners even when not all participate in your altcoin (but this area probably needs some studying to get right). You assume the value of a crypto-currency is equal to all miners, it's not. Suppose I create a merge-mined Zerocoin implementation with a 1:1 BTC/ZTC exchange rate enforced by the software. You can't argue this is a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the only thing you can do with the coin is get some privacy. But inevitably some miners won't agree that enabling better privacy is a good thing, or their local governments won't. Either way, they can attack the Zerocoin merge-mined chain with a marginal cost of nearly zero. Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the worst they could do is not-participate by mining empty blocks. OTOH if the Zerocoin scheme was implemented by embedding ZTC transactions within standard Bitcoin transactions - even without any attempt at hiding them - the attackers would need a 50% majority of hashing power to succeed. Of course potentially slow confirmations is a trade-off, but that's likely a perfectly OK trade-off in this case. Potentially slow confirmation is also the only shortcoming of using Bitcoin's proof-of-work directly. Luke -- 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] The insecurity of merge-mining
On Wed, Jan 01, 2014 at 05:09:27AM +, Luke-Jr wrote: You assume the value of a crypto-currency is equal to all miners, it's not. Suppose I create a merge-mined Zerocoin implementation with a 1:1 BTC/ZTC exchange rate enforced by the software. You can't argue this is a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the only thing you can do with the coin is get some privacy. But inevitably some miners won't agree that enabling better privacy is a good thing, or their local governments won't. Either way, they can attack the Zerocoin merge-mined chain with a marginal cost of nearly zero. Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the worst they could do is not-participate by mining empty blocks. Nope. Tying the alt-coin difficulty to the Bitcoin difficulty isn't some magic way to avoid a 51% attack - you still need a majority of consensus. The attackers can still mine a conflicting chain and there's still no reasonable way to choose between the two chains other than proof-of-something. Even worse, then can do a data-hiding attack by mining a conflicting chain without publishing the blockchain data, then revealing it some time in the future, or just sowing FUD by making it clear that the mining is happening. Like it or not crypto-coins solve double-spending with proof-of-publication, and that can't be done without some kind of mathematically verifiable majority aligned with the interests of the crypto-coin users. Recall that my zookeyv(1) and zerocoin alt(2) proposals from last summer was specifically designed to take that situation into account, and of course could at best only make it clear that it was happening and how many Bitcoins needed to be sacrificed to make the chain secure. 1) #bitcoin-wizards, 2013-05-31 2) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html -- 'peter'[:-1]@petertodd.org 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 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
