Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Jorge Timón
On 1/10/14, Peter Todd wrote: > 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 h

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Peter Todd
On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote: > On 1/10/14, Peter Todd 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 tho

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Jorge Timón
On 1/10/14, Peter Todd 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

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Jorge Timón
On 1/10/14, 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-10 Thread Peter Todd
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote: > On 10 January 2014 10:20, Peter Todd 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-10 Thread Drak
On 10 January 2014 10:20, Peter Todd 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>

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Peter Todd
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 certain

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Peter Todd
On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote: > On 1/6/14, Peter Todd 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-10 Thread Peter Todd
On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote: > Thanks Peter for the paper! > > I'm just going to restate your 'simple explanation' to make sure I > got it... > > The payee publishes a public key of theirs, which will be a > long-standing identifier, public key = 'Q', correspond

Re: [Bitcoin-development] Privacy and blockchain data

2014-01-10 Thread Peter Todd
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 > > remaind