Re: [Bitcoin-development] BIP: register with IANA for bitcoin/cryptocoin port numbers
Ideally it would be good to have two ports, one for the main net, and one for the test net. However, in light of conservation only one may be granted. The question as to whether traffic could be multiplexed over a single port may be raised. I'm sure it would be *possible*, but testnet and mainnet are entirely separate networks. Not only that, but the entire point of the testnet is separation. There is no logic to multiplexing them. If conservation is an issue, I'd forgo the testnet port. We don't have a 'test ssh' or 'test mail server' port either, most people will just allocate a temporary number for those themselves. In case the port is already in use, bitcoin can run on and announce any another port. There is no strict need for it to be 8333 (or 18333) at all. There isn't even an argument for convenience. Most of the time, users don't specify nodes. And in the rare cases that they do they can specify a port as well. If a whole slew of alt coins also tried to reserve ports, I suspect that may raise eyebrows. That's somebody else's problem. Bitcoin is by far the most well-known of the 'coins' so it may be considered realistic to allocate one or two ports for it. Or not, in which case the altcoins can forget it too. Regards, Wladimir -- 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 3 January 2014 05:45, Troy Benjegerdes ho...@hozed.org wrote: On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell 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. No, the only cure is the check the hashes. We should know something about hashes here. TLS is a big pile of 'too big to audit'. Spend a couple of satoshis and put the hash of the source tar.gz and the binaries in the blockchain. Problem solved. Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm 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?
You know if you want to make some form of investment, you might like make an attempt to look them up on the internet, check the phone number in a phone book or directory enquiries, look for references and reviews? So it is with the hash of the binary you are about to trust with your investment funds. I dont think its such a difficult question. Ask your more technical friends to confirm this hash is correct. Its interesting that hashes are more trustworthy than signatures, since all the NSLs and backdoors, its hard to trust a signature. I have the same problem with linux distros that want to install hundreds of components downloaded over the internet, based on signatures. I would far rather a merkle hash of the distribution at that point in time, which authenticates directly any of the optional downloadable components. (Or better yet a distro that like comes on a CD and doesnt download anything... Amazing how most CD and even DVD iso images immediately download stupid things like fonts??? What were they thinking? I downloaded fedora 4GB of stuff and they need to download a font just to get past step 2 of the installer? Thats a sensless, retrograde, selective backdoor opportunity.) Adam On Fri, Jan 03, 2014 at 11:22:35AM +, Tier Nolan wrote: On Fri, Jan 3, 2014 at 9:59 AM, Drak [1]d...@zikula.org wrote: Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm Maybe a simple compromise would be to add a secure downloader to the bitcoin client. The download link could point to a meta-data file that has info on the download. file_url= hash_url= sig_url= message=This is version x.y.z of the bitcoin client It still suffers from the root CA problem though. The bitcoin client would accept Gavin's signature or a core team signature. At least it would provide forward security. It could also be used to download files for different projects, with explicit warnings that you are adding a new trusted key. When you try to download, you would be given a window Project: Some Alternative Wallet Signed by: P. Lead Message: Confirm download Yes No However, even if you do that, each trusted key is only linked to a particular project. It would say if the project and/or leader is unknown. References 1. mailto:d...@zikula.org -- 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] An idea for alternative payment scheme
The random number that the buyer uses could be generated from a root key too. This would allow them to regenerate all random numbers that they used and recreate their receipts. The master root would have to be stored on your computer though. The payment protocol is supposed to do something like this already though. On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi na...@shesek.info wrote: I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it. It would work like that: 1. The payee publishes his master public key 2. The payer generates a random receipt number (say, 25 random bytes) 3. The payer derives an address from the master public key using the receipt number and pays to it 4. The payer sends the receipt to the payee 5. The payee derives a private key with that receipt and adds it to his wallet Advantages: - It increases privacy by avoiding address reuse - The process is asynchronous. The payee is completely passive in the payment process and isn't required to provide new addresses before each payment (so no payment server required) - Its usable as a replacement for cases where re-used addresses are the most viable solution (like putting an address in a forum signature or as a development fund in a github readme) - The receipt also acts as a proof of payment that the payer can provide to the payee - Also, if the master is known to belong to someone, this also allows the payer prove to a third-party that the payment was made to that someone. If the output was spent, it also proves that he was aware of the payment and has the receipt. - Its a really thin abstraction layer that doesn't require much changes Disadvantages: - Losing the receipt numbers means losing access to your funds, they are random and there's no way to restore them - It requires sending the receipt to the payee somehow. Email could work for that, but a better defined channel that also can talk to the Bitcoin client and add the receipt would be much better. What do you think? -- 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?
On 1/3/14, Troy Benjegerdes ho...@hozed.org wrote: 'make' should check the hash. An attacker could replace that part of the makefile. Anyway, I think this is more oriented for compiled binaries, not for people downloading the sources. I assume most of that people just use git. The binary should check it's own hash. I'm afraid this is not possible. The operating system should check the hash. There's package management systems like apt-secure that do exactly this. -- 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] An idea for alternative payment scheme
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote: I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it. It would work like that: The payee publishes his master public key The payer generates a random receipt number (say, 25 random bytes) The payer derives an address from the master public key using the receipt number and pays to it The payer sends the receipt to the payee The payee derives a private key with that receipt and adds it to his wallet Allow me to introduce an even more wild idea. The payee publishes two public keys PP PP2. The payer picks the first k value he intends to use in his signatures. The payer multiplies PP2*k = n. The payer pays to pubkey PP+n with r in his first signature, or if none of the txins are ECDSA signed, in an OP_RETURN additional output. The payer advises the payee that PP+(pp2_secret*r) is something he can redeem. But this is technically optional because the payee can simply inspect every transaction to check for this condition. This is a (subset) of a scheme by Bytecoin published a long time ago on Bitcoin talk. It has the advantage that if payer drops his computer down a well after making the payment the funds are not lost, and yet it is still completely confidential. (The downside is particular way I've specified this breaks using deterministic DSA unless you use the OP_RETURN, ... it could instead be done by using one of the signature pubkeys, but the pubkeys may only exist in the prior txin, which kinda stinks. Also the private keys for the pubkeys may only exist in some external hardware, where a OP_RETURN nonce could be produced when signing). These schemes have an advantage over the plain payment protocol intended use (where you can just give them their receipt number, or just the whole key) in that they allow the first round of communication to be broadcast (e.g. payee announced to EVERYONE that he's accepting payments) while preserving privacy. -- 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 1/1/14, Peter Todd p...@petertodd.org 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. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. 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. The idea of sacrificing something external and make bitcoins appear still sounds crazy to me. I don't see how this pegging contributes in anything to a technical argument against merged mining, just looks like a moral argument against altcoin in general. But anyway, if you're going to make bitcoin's validation dependent on some external chain, it surprises me even more that you prefer that external dependency to be non-merge mineable. 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. Ok, so either we assume that the external-pegging hardfork wasn't a consensus or we just forget about the pegging and go back to talk about merged mining in general. Your argument is still for some reason some miners don't like the MM altcoin and prefer to attack it than to be profitable miners. If I mine BTC + NMC and you only mine BTC, it will be harder for you to compete against me: I can afford higher costs than you for the same BTC reward, since I'm also getting NMC. What you're saying is that Litecoin is more secure than Namecoin because while Litecoin can only be attacked by external attackers and current miners of other scrypt coins, Namecoin can also be attacked the Bitcoin miners that aren't currently mining Namecoin. This doesn't sound very reasonable to me. I think Namecoin is more secure than Litecoin and new coins should be created with SHA256 and merged mining in mind. At least merged mine with Litecoin if the still believe scrypt is so anti-ASIC and centralization-resistant (in fact Litecoin is more centralized than bitcoin with their shorter block intervals since better connections are favored, but that's another story). Merged mining is not only about not competing for proof of work like Satoshi defended. It is also about wasting resources: the more mining subsidies to different chains, the more wasted resources. By criticizing merged mining you're also indirectly legitimizing the same scamcoin madness you criticize. If you don't plan to merge mine, having SHA256 doesn't make sense because that makes you more fragile to potential bitcoin miners attacks and chainhopers. I don't think we would have this many alts living right now if all proof of work was SHA256. So if the anti-asic PoW myth and the absurd emerging morals of GPU-mining as an universal right weren't enough, you want to add an equally false merged mining is insecure to the collection of arguments supporting the search of the more absurd possible PoW holy grail. Please try to prove that MM is insecure and I'll try to prove your wrong. But we don't need zerocoin or an artificial pegging to discuss about this. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of 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
Re: [Bitcoin-development] An idea for alternative payment scheme
Seems like you (Nadav) are the third person to reinvent this idea so far :) I wrote up some of the post-Bytecoin variants here: https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530 The general limitation so far is its not SPV compatible, so the recipient has to test each payment to see if its one he can compute the private key for. Or the sender has to send the recipient out of band the derivation key. However at present most of the bitcoin infrastructure is using the bitcoin broadcast channel as the communication channel, which also supports payer and payee not being simultaneously online. You have to be careful also not to lose the key. You dont want a subsequent payer data loss event to lose money for the recipient. You want the message to be sent atomically. It does seem like a very attractive proposition to be able to fix the address reuse issue. Admonishment to not reuse addresses doesnt seem to have been successful so far, and there are multiple widely used wallets that reuse addresses (probably in part because they didnt implement HD wallets and so are scared of losing addresses due to backup failure risks of non HD wallets and fresh addresses). Adam On Fri, Jan 03, 2014 at 10:30:38AM -0800, Gregory Maxwell wrote: On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote: I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it. It would work like that: The payee publishes his master public key The payer generates a random receipt number (say, 25 random bytes) The payer derives an address from the master public key using the receipt number and pays to it The payer sends the receipt to the payee The payee derives a private key with that receipt and adds it to his wallet Allow me to introduce an even more wild idea. The payee publishes two public keys PP PP2. The payer picks the first k value he intends to use in his signatures. The payer multiplies PP2*k = n. The payer pays to pubkey PP+n with r in his first signature, or if none of the txins are ECDSA signed, in an OP_RETURN additional output. The payer advises the payee that PP+(pp2_secret*r) is something he can redeem. But this is technically optional because the payee can simply inspect every transaction to check for this condition. This is a (subset) of a scheme by Bytecoin published a long time ago on Bitcoin talk. It has the advantage that if payer drops his computer down a well after making the payment the funds are not lost, and yet it is still completely confidential. (The downside is particular way I've specified this breaks using deterministic DSA unless you use the OP_RETURN, ... it could instead be done by using one of the signature pubkeys, but the pubkeys may only exist in the prior txin, which kinda stinks. Also the private keys for the pubkeys may only exist in some external hardware, where a OP_RETURN nonce could be produced when signing). These schemes have an advantage over the plain payment protocol intended use (where you can just give them their receipt number, or just the whole key) in that they allow the first round of communication to be broadcast (e.g. payee announced to EVERYONE that he's accepting payments) while preserving privacy. -- 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] An idea for alternative payment scheme
On Fri, Jan 03, 2014 at 09:23:20PM +0100, Adam Back wrote: Seems like you (Nadav) are the third person to reinvent this idea so far :) Lol, fourth if you include me, although my case is rather embarassing as I had re-read Bytecoin's original post recently and completely missed the main point of it! I wrote up some of the post-Bytecoin variants here: https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530 The general limitation so far is its not SPV compatible, so the recipient has to test each payment to see if its one he can compute the private key for. Or the sender has to send the recipient out of band the derivation key. Actually I think it has the potential to be *more* SPV compatible than the alternative, as in conjunction with prefix filters it lets you receive unlimited unrelated payments that you can find in the blockchain with a single prefix query with a fixed bandwidth/anonymity set size tradeoff. (obviously in conjunction with one of the many ways of tagging transactions for more efficient search) The BIP38 approach with UI's that make it easy to create a new address for every payment on the other hand force you to either accept higher bandwidth consumption, or decrease your anonymity set size, or lose payments. (inclusive) I've got a post talking about this in more detail as well as an overview of bloom filters vs. prefix filters that I'll publish tomorrow. (tl;dr: bloom filters have very poor O(n^2) scalability and should be depreciated) However at present most of the bitcoin infrastructure is using the bitcoin broadcast channel as the communication channel, which also supports payer and payee not being simultaneously online. You have to be careful also not to lose the key. You dont want a subsequent payer data loss event to lose money for the recipient. You want the message to be sent atomically. It does seem like a very attractive proposition to be able to fix the address reuse issue. Admonishment to not reuse addresses doesnt seem to have been successful so far, and there are multiple widely used wallets that reuse addresses (probably in part because they didnt implement HD wallets and so are scared of losing addresses due to backup failure risks of non HD wallets and fresh addresses). -- 'peter'[:-1]@petertodd.org 0001a96469654430aa06e4ae7c7328a7eb848c6fc63443f24e4a 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 Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: You assume the value of a crypto-currency is equal to all miners, it's not. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. As I showed with my zerocoin example, often that is not the case, e.g. I do not support anonymity, or *can't* support it because of the local laws. Or for that matter, really boring examples like there's two competing implementations of some basic idea and we'd rather the winner be picked on technical merits rather than I have a grudge and a small pool so I'll this upstart at birth 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. The idea of sacrificing something external and make bitcoins appear still sounds crazy to me. I don't see how this pegging contributes in anything to a technical argument against merged mining, just looks like a moral argument against altcoin in general. It's a thought experiment; read my original post on how to make a zerocoin alt-chain and it might make more sense: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html Even better might be to use a merge-mined version of Mastercoin as an example, where the initial distribution of coins is fixed at genesis and forward from that is independent of the Bitcoin blockchain. 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. Ok, so either we assume that the external-pegging hardfork wasn't a consensus or we just forget about the pegging and go back to talk about merged mining in general. Your argument is still for some reason some miners don't like the MM altcoin and prefer to attack it than to be profitable miners. If I mine BTC + NMC and you only mine BTC, it will be harder for you to compete against me: I can afford higher costs than you for the same BTC reward, since I'm also getting NMC. What you're saying is that Litecoin is more secure than Namecoin because while Litecoin can only be attacked by external attackers and current miners of other scrypt coins, Namecoin can also be attacked the Bitcoin miners that aren't currently mining Namecoin. This doesn't sound very reasonable to me. I think Namecoin is more secure than Litecoin and new coins should be created with SHA256 and merged mining in mind. At least merged mine with Litecoin if the still believe scrypt is so anti-ASIC and centralization-resistant (in fact Litecoin is more centralized than bitcoin with their shorter block intervals since better connections are favored, but that's another story). Merged mining is not only about not competing for proof of work like Satoshi defended. It is also about wasting resources: the more mining subsidies to different chains, the more wasted resources. By criticizing merged mining you're also indirectly legitimizing the same scamcoin madness you criticize. If you don't plan to merge mine, having SHA256 doesn't make sense because that makes you more fragile to potential bitcoin miners attacks and chainhopers. I don't think we would have this many alts living right now if all proof of work was SHA256. So if the anti-asic PoW myth and the absurd emerging morals of GPU-mining as an universal right weren't enough, you want to add an equally false merged mining is insecure to the collection of arguments supporting the search of the more absurd possible PoW holy grail. Please try to prove that MM is insecure and I'll try to prove your wrong. But we don't need zerocoin or an artificial pegging to discuss about this. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? I'll give you a hint: marginal cost You're rant has rather little to do with my argument. -- 'peter'[:-1]@petertodd.org 0003065f32da26de1deda93eb722bf1dc4a1b787e7d68d282dbc 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!
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/3/14, Peter Todd p...@petertodd.org wrote: On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: You assume the value of a crypto-currency is equal to all miners, it's not. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. As I showed with my zerocoin example, often that is not the case, e.g. I do not support anonymity, or *can't* support it because of the local laws. Or for that matter, really boring examples like there's two competing implementations of some basic idea and we'd rather the winner be picked on technical merits rather than I have a grudge and a small pool so I'll this upstart at birth For whatever reason, someone wants to attack one chain, fine. But if the market is competitive enough and/or the reward of the MM-coin is high enough comparatively to the biggest ones in the MM group, then it is not profitable to mine. If you make a MM coin, it's fees reward are 5% of BTC + NMC rewards, and a jurisdiction somehow prohibits to mine the new coin (I can't imagine such a law being enforced, but I'll follow your argument), then BTC + NMC miners will just tend to disappear from that jurisdiction. It's a thought experiment; read my original post on how to make a zerocoin alt-chain and it might make more sense: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html Even better might be to use a merge-mined version of Mastercoin as an example, where the initial distribution of coins is fixed at genesis and forward from that is independent of the Bitcoin blockchain. I've read it until the end this time, and I have many doubts about proof of sacrifice as a security mechanism. Although it's certainly not proof of stake, it smells similarly to me. I'll have to think more about it. I still think that link doesn't prove anything against merged mining security. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? I'll give you a hint: marginal cost Please, don't give me clues and let's discuss the economics, that's precisely what I want and where I think you're getting it wrong. Since you refuse to try to prove that MM is less secure, I'll try myself to prove the opposite. Let's say we have currencies A, B, C and D, with daily rewards of 70, 20, 10 and 10 valuns respectively. A, B and C are merged mined, D is not. So with an equivalent reward to miners and one being merged mined while the other being independent, what's the more secure chain? C or D? Assuming similar hashing algorithms and perfect competition, the cost of producing enough hashing power to obtain 1 valun in rewards from D equals the cost of extracting 1 valun in rewards from the group A + B + C. Let's define 1 valun as the costs in energy and capital resources to produce X GH/s. So we have the following hashrates for each chain: A = 100*X GH/s B = 100*X GH/s C = 100*X GH/s D = 10*X GH/s Now here it comes our attacker paying for amazon servers. The costs in value to rent a server to produce X GH/s during a day cannot be lower than 1 valun, given the earlier assumptions. Let's assume it is equal to 1 valun for simplicity. So the cost to have 50% of D's hashing power for a day is 10 valuns. The cost to to have 50% of C's hashing power for a day is 100 valuns, but, hey, I'll use your hint now. Marginal costs. So I'm using 100 valuns to attack C, but I'm still getting my rewards from A and B as normal. As normal? Let's assume it's as normal first. I would be getting 90 valuns from chains A and B, so 100 - 90 = 10 valuns. Mhmm, it seems that although I need to make a considerably bigger investment in the case of attacking C, in the end the total costs will be the same of attacking D, that is 10 valuns. But, wait, I've doubled the hashrate!! Miners were getting 1 valun in reward per valun in mining costs when the hashrate was 100*X GH/s, now A and B hashrates are 200*X GH/s because I came to mine. Some of them will be smart enough to leave fast, but I will be really getting something between 45 and 90 valuns from honestly mining A + B, not 90 valuns as I was assuming. So it turns out that attacking D is actually cheaper than attacking C. Feel free to ask for corrections in the example if you think it needs them. Feel free to bring your edge legal cases back, but please try to do it on top of the example. PD I'm eager to read your post on BIP32-ish payment protocol, bloom filters and prefix filters, so I hope I'm not distracting you too much with this. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their
