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
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

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 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

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 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

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 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

2014-01-10 Thread Jorge Timón
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

2014-01-10 Thread Jorge Timón
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

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 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
--