Re: [Bitcoin-development] Privacy and blockchain data
On Tue, Jan 07, 2014 at 10:34:46PM -0800, Jeremy Spilman wrote: 2) Common prefixes: Generate addresses such that for a given wallet they all share a fixed prefix. The length of that prefix determines the anonymity set and associated privacy/bandwidth tradeoff, which remainds a fixed ratio of all transactions for the life of the wallet. Interesting thought to make the privacy/bandwidth trade-off using vanitygen and prefix filters. But doesn't this effectively expand the universe of potential spies from 'the global attacker' who is watching your SPV queries, to simply 'the globe' -- anyone with a copy of the blockchain? It's a trade-off. Most people are going to use public peers for their SPV nodes - they're not going to run full nodes. They also are going to want to limit how much bandwidth they use to sync their wallets; if they don't care the can use a very short, or no, prefix and the problem goes away. If you make that bandwidth/privacy trade-off by using very specific filters and non-specific addresses then you have a situation where those public peers are learning a lot of potentially valuable data. It's easy to imagine, say, the IRS being willing to pay for data on how many Bitcoins people have in their wallets to try to catch tax cheats for instance, and that can easily fund a lot of fast and high-quality peers that don't advertise the fact that they're selling data on the contents of your wallet. On the other hand if you use non-specific filters, and prefixed addresses for incoming payments, then you're not leaking high-quality information to anyone. I think this makes for a more robust Bitcoin system, especially as we need things like CoinJoin for privacy that make *everyones* privacy matter to you; CoinJoin could easily be defeated by aquiring lots of good info on the contents of wallets through SPV queries. Some stats on UTXO set size: (slightly stale -- as of block 270733) 7.4m unspent outputs 2.2m transactions with unspent outputs 2.1m unique unspent scriptPubKeys Side note: the top 1,000 scriptPubKeys have 10% of all unspent outputs. Let's say you use an 8-bit prefix (1/256) that would be ~10,000 transactions in the UTXO you would be monitoring. But if I knew a few different days / time-periods you transacted, I could figure out your prefix. Actually UTXO isn't the right way to look at this; prefix filters would be almost certainly matched against all txouts in blocks. Or put another way, UTXO isn't the right way to look at it because the attacker will have some rough idea of the time period, and wants to know about transactions made. Of course, anyone you transact with would know your prefix outright. Well what good, in your example, is it for the attacker to go from I know my target gets a paycheck every two weeks for $x to His wallet prefix is abcd with y% probability? Even once you learn the prefix of your target's wallet, what funds they actually own is still embedded in a much larger anonymity set of hundreds to thousands of transactions that had nothing to do with them. Wouldn't this also allow obvious identification of spend versus change addresses in a transaction? No, I specifically said that you don't want to use prefixes with change txouts for that reason. Fortunately while the set of all scriptPubKey's ever used for change txouts will grow over time, as long as you are not watching for new payments on any key in that set you only need to query for the ones that still have funds on them, and that's only because you want to be able to detect unauthorized spends of them. -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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 Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote: On 1/6/14, Peter Todd p...@petertodd.org wrote: On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote: It's not meant to prove anything - the proof-of-sacrificed-bitcoins mentioned(*) in it is secure only if Bitcoin itself is secure and functional. I referred you to it because understanding the system will help you understand my thinking behind merge-mining. *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct because you're sacrificing the thing that the chain is about. Now that has some proof-of-stake tinges to it for sure - I myself am not convinced it is or isn't a viable scheme. I'm not sure I understand all the differences between proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm still convinced this doesn't have anything to do with MM PoW vs PoW. Proof-of-sacrified-bitcoins is always a true sacrifice - provided Bitcoin itself maintains consensus the proof is a guarantee that something of value was given up. Proof-of-sacrificed-newcoins means that within some consensus system I created a signed statement that *within the system* means I lose something of value. However that sacrifice is only valid if the consensus of the system includes that sacrifice within the consensus, and if the mechanism by which that consensus is maintained has anything to do with those sacrifices you quickly find yourself on pretty shakey ground. You know, something that I haven't made clear in this discussion is that while I think merge-mining is insecure, in the sense of should my new fancy alt-coin protocol widget use it?, I *also* don't think regular mining is much better. In some cases it will be worse due to social factors. (e.g. a bunch of big pools are going to merge-mine my scheme on launch day because it makes puppies cuter and kids smile) Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. The problem here is that my new system has a substantial *negative* value to those existing Namecoin holders - if it catches on the value of their Namecoin investment in the form of coins and domain names may go down. Thus for them doing nothing has a negative return, attacking my coin has a positive return minus costs, and with merge-mining the costs are zero. Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. Of course, this is what Luke-Jr was getting at when he was talking about scam-coins and merge mining: if you're alt-currency is a currency, and it catches on, then it dilutes the value of your existing coins and people who own those coins have an incentive to attack the competitor. That's why merge-mined alt-coins that are currencies get often get attacked very quickly. -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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 10, 2014 at 06:11:28AM -0500, Peter Todd wrote: Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Come to think of it, we've got that exact situation right now: the new Twister P2P Microblogging thing has a blockchain for registering usernames that could have been easily done with Namecoin, thus in theory Namecoin owners have an incentive to make sure the Twister blockchain gets killed at birth. Pretty easy to do right now too as the hashing power behind Twister is miniscule and probably will stay that way - the only incentive to mining is that you get the right to make a promoted post - called a spam message in the codebase - that in theory Twister clients are supposed to show to their users. Of course, there's absolutely no way to guarantee that clients actually do that. -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote: On 10 January 2014 10:20, Peter Todd p...@petertodd.org wrote: Oh, sorry, I forgot to mention it in my first write-up but you can easily make stealth addresses include a second pubkey for the purpose of the communication that either isn't used in the scriptPubKey at all, or is part of a n-of-m multisig. (n=2) Interestingly that also means you can give a third-party that key and out-source the effort of scanning the blockchain for you. That seems pretty exciting to me. What is the chance of this becoming a BIP? Needs a prototype implementation first. The version with no prefix is the simple one and doesn't have any other dependencies; the prefix version is harder because it isn't clear yet what's the best way to force the prefix, or for that matter whether scriptPubKey or H(scriptPubKey) indexes will be available. It's on my todo list, but as you've probably noticed my todo list is rather long. :) -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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/10/14, Peter Todd p...@petertodd.org wrote: Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Namecoin, Devcoin and Ixcoin are also currencies and therefore compete with Bitcoin. How is that even Ixcoin (clearly a scamcoin that indirectly damages the image of Bitcoin) has survived? My explanation is that miners aren't necessarily holders. It's certain that there's holders who don't mind and can't do anything about it. In fact, I think many miners sell their mined coins for fiat to cover their investment and costs. The profit margin is reduced as the mining market becomes more competitive, so even for miners it will get very expensive and risky to do stupid things. Talking about stupid things, I don't see many bitcoiners throwing rocks at local currency users or barter clubs nor burning down banks to protect their investment. Barter is just another competitor in the media of exchange market. The problem here is that my new system has a substantial *negative* value to those existing Namecoin holders - if it catches on the value of their Namecoin investment in the form of coins and domain names may go down. Thus for them doing nothing has a negative return, attacking my coin has a positive return minus costs, and with merge-mining the costs are zero. What percentage of Bitcoin/Namecoin miners do you think own namecoins? How much can they afford to lose to attack competition? Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. No, the harm to the old system participants is distributed among all the participants, not only miners (assuming miners have any speculative position at all). I'm not denying that people do crazy and stupid things, but let's at least allow the anti-competition attacker be equally crazy in both cases. Miners attacking competition for one or more of the chains they mine are acting irrationally in both cases. You're trying to rationalize the actions of the MM attackers, but they're just being stupid, since if they weren't, they would just try to maximize profits. Of course, this is what Luke-Jr was getting at when he was talking about scam-coins and merge mining: if you're alt-currency is a currency, and it catches on, then it dilutes the value of your existing coins and people who own those coins have an incentive to attack the competitor. That's why merge-mined alt-coins that are currencies get often get attacked very quickly. I have many other explanations for the few currencies that died with MM (can you remember any name?). At the beginning all altcoins were much smaller and easier to attack, all of them. Bitcoin mining pools didn't wanted to update to merged mining and didn't acted very rationally about it. Namecoin went through a really delicate situation just before hardforking to MM, but now is by far the most secure altcoin of them all, all thanks to MM. All rational bitcoin miners should also mine namecoin. Period. All those who consider it competition with their current Bitcoin speculative position, should just attack in the market by selling the namecoins as soon as they get them. Providing security for a chain DOES NOT give it an utility or rise its demand. Operation COSTS DO NOT CAUSE VALUE. About Luke-Jr's thinking, I don't think it's along those lines. If you create a new chain for the long term, you should try to maximize its security and that currently means you should merged mine with bitcoin. The main rational reason to never do merged mining is to prevent competitive and rational miners from crashing the price of your currency, which is everything a scamcoiner cares about, the price and market cap. Of course Luke-Jr can correct me if that's not how he thinks. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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/10/14, Peter Todd p...@petertodd.org wrote: Come to think of it, we've got that exact situation right now: the new Twister P2P Microblogging thing has a blockchain for registering usernames that could have been easily done with Namecoin, thus in theory Namecoin owners have an incentive to make sure the Twister blockchain gets killed at birth. You don't have to MM from birth. That I've already agreed is dangerous. But if you start with SHA256, then merged mining is a trivial fork at least 3 currencies have done successfully. As said we plan to make Freicoin merge-mineable in the future, and we expect to get much more security after we do. The only adverse effect may be a temporary drop in price due to the new miners selling all the frc they get until a new price equilibrates with the demand. But that's not really bad for the currency, just to the holders at that moment. Pretty easy to do right now too as the hashing power behind Twister is miniscule and probably will stay that way - the only incentive to mining is that you get the right to make a promoted post - called a spam message in the codebase - that in theory Twister clients are supposed to show to their users. Of course, there's absolutely no way to guarantee that clients actually do that. If a system doesn't compensate its miners in a liquid enough way, the system will probably be insecure, but that's another topic... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote: On 1/10/14, Peter Todd p...@petertodd.org wrote: Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Namecoin, Devcoin and Ixcoin are also currencies and therefore compete with Bitcoin. How is that even Ixcoin (clearly a scamcoin that indirectly damages the image of Bitcoin) has survived? Because there aren't that many pools out there and Ixcoin (and devcoin) appear to have been lucky enough to servive long enough to get the support of a reasonably big one. Once you do that, the potential attackers have PR to think about. (namecoin especially has a PR advantage) None of this stuff is hard and fast rules after all. Talking about stupid things, I don't see many bitcoiners throwing rocks at local currency users or barter clubs nor burning down banks to protect their investment. Barter is just another competitor in the media of exchange market. Those are all examples where the cost to the bitcoiner defending their currency is high - I might get arrested trying to burn down a bank. Anyway, I'm starting to think you're reading too much into my statement merge mining is insecure, which, keep in mind, I said in relation to a guy who was trying to recruit devs to implement some unknown altcoin thing. Imagine you're one of the first US cave divers back in the early 70's. You've been doing it for only a few years yourself, and you and your buddies, some of them now late, realized pretty quick it's bloody dangerous and there's all kinds of ways to get yourself killed. (caving itself is bad enough) On the other hand, if you're careful and have good training it *is* possible to reduce the risks significantly. Meanwhile the media and public in general is starting to pick up on caving and cave diving and there's a tonne of new people - most of whome don't seem to know what they're doing - are getting into both sports. You just know this is going to lead to a lot of people getting hurt and killed who probably should have just stuck to caving. (IE, stuck to making Bitcoin-using applications) In that context I sure as heck would loudly yell CAVE DIVING IS FUCKING DANGEROUS, DON'T DO IT. Sure, that's not quite telling the whole story, but the message is pretty close to the truth. The people that should be in the sport are the ones that take a statement like that as a warning to do their research; I have no reason to think the OP asking for developers was one of those people. Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. No, the harm to the old system participants is distributed among all the participants, not only miners (assuming miners have any speculative position at all). I'm not denying that people do crazy and stupid things, but let's at least allow the anti-competition attacker be equally crazy in both cases. Distributing harm among n people just reduces the harm for each person by a factor of n. That may or may not make that harm smaller than whatever tiny reward mining the chain would be. I have many other explanations for the few currencies that died with MM (can you remember any name?). At the beginning all altcoins were much smaller and easier to attack, all of them. Bitcoin mining pools didn't wanted to update to merged mining and didn't acted very rationally about it. Namecoin went through a really delicate situation just before hardforking to MM, but now is by far the most secure altcoin of them all, all thanks to MM. All rational bitcoin miners should also mine namecoin. Period. All You assume doing so has zero cost - it doesn't. Running namecoind involves effort and bandwidth on my part. those who consider it competition with their current Bitcoin speculative position, should just attack in the market by selling the namecoins as soon as they get them. Providing security for a chain DOES NOT give it an utility or rise its demand. Operation COSTS DO NOT CAUSE VALUE. Lets rephrase that A secure chain is no more useful than a less secure chain. A secure chain will not be more valuable than a less secure chain, all other things being equal. I don't think we're going to see eye to eye on this. -- 'peter'[:-1]@petertodd.org 28e2c0ade6ce50b5ce4d95037e5e2dcd500b4bb52adbe73c signature.asc Description: Digital signature --
