[Cryptography] Satoshi's PGP key.

[Peter Todd]

On Fri, Dec 18, 2015 at 06:15:09PM -0800, Ray Dillinger wrote:
> On 12/17/2015 04:05 AM, Jerry Leichter wrote:
> > Ah.  So you think owning Bitcoins is a bad idea, then?
> 
> At the moment, yes.  I made some money on them, but I sold out.
> 
> Satoshi has enough that s/he has a huge target painted on his/her
> butt, but even if you don't own enough for that to be an issue,
> it's still a bad idea.
> 
> According to my math the protocol promotes mining consolidation,
> and the winning tactic for a consolidated miner amounts to a
> partial DDoS.
> 
> Once anyone has more than 1 - 1/Phi of the mining power, and
> there is enough *actual* demand to fill more than half of each
> block on average, then even if everybody else behaves optimally
> (which they don't) that miner gets rich faster than all other
> miners (at a higher rate of return on expense) by keeping the
> blocks, on average, half full of transactions in order to force
> up the fees other people pay.  It will cost the consolidating
> miner fees, of course, to prevent other miners from accepting
> tx below that fee level - but he'll get whatever share of them
> back that he's getting of the blocks, and he (and all other
> miners too) makes more money on all the other tx.

I think you've stumbled on a well known phenomenon(1), but you're
incorrect on two details. First of all miners don't have to pad their
blocks with fee paying transactions, they can pad their blocks with txs
that don't pay fees as well.  Secondly the blocksize limit puts a limit
on how effective the attack can be, which is why it's a fundemental
security parameter in the Bitcoin system that levels the playing field
between small miner and large. Notably, this effect makes all block
propagation optimisations that rely on miners pre-propagating block
contents only work under non-adversarial conditions where miners
cooperate. (and remember that this "cooperation" requires a significant
amount of coordination)

Unfortunately we're under heavy political pressure right now to raise
the blocksize, or even remove the blocksize limit entirely. If this
happens, the system risks being killed off through centralization as you
suspect.


1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html

Reproduced below:


Suppose I find a block. I have Q hashing power, and the rest of the
network 1-Q. Should I tell the rest of the network, or withhold that
block and hope I find a second one?

Now in a purely inflation subsidy environment, where I don't care about
the other miners success, of course I should publish. However, if my
goals are to find *more* blocks than the other miners for whatever
reason, maybe because transaction fees matter or I'm trying to get
nLockTime'd announce/commit fee sacrifices, it gets more complicated.


There are three possible outcomes:

1) I find the next block, probability Q
2) They find the next block, probability 1-Q
2.1) I find the next block, probability Q, or (1-Q)*Q in total.
2.2) They find the next block, probability (1-Q)^2 in total.

Note how only in the last option do I lose. So how much hashing power do
I need before it is just as likely that the other miners will find two
blocks before I find either one block, or two blocks? Easy enough:

Q + (1-Q)*Q = (1-Q)^2 -> Q^2 - Q + 1/2 -> Q = (1 - \sqrt(2))/2

Q ~= 29.2%

So basically, if I'm trying to beat other miners, once I have >29.3% of
the hashing power I have no incentive to publish the blocks I mine!

But hang on, does it matter if I'm the one who actually has that hashing
power? What if I just make sure that only >29.3% of the hashing power
has that block? If my goal is to make sure that someone does useless
work, and/or they are working on a lower height block than me, then no,
I don't care, which means my original "send blocks to >51% of the
hashing power" analysis was actually wrong, and the strategy is even
more crazy: "send blocks to >29.3% of the hashing power" (!)


Lets suppose I know that I'm two blocks ahead:

1) I find the next block: Q                    (3:0)
2) They find the next block: (1-Q)             (2:1)
2.1) I find the next block: (1-Q)*Q            (3:1)
2.2) They find the next block: (1-Q)^2         (2:2)
2.2.1) I find the next block: (1-Q)^2 * Q      (3:2)
2.2.2) They find the next block: (1-Q)^3       (2:3)

At what hashing power should I release my blocks? So remember, I win
this round on outcomes 1, 2.1, 2.2.1 and they only win on 2.2.2:

Q + (1-Q)*Q + (1-Q)^2*Q = (1-Q)^3 -> Q = 1 - 2^-3

Q ~= 20.6%

Interesting... so as I get further ahead, or to be exact the group of
miners who have a given block gets further ahead, I need less hashing
power for my incentives to be to *not* publish the block I just found.
Conversely this means I should try to make my blocks propagate to less
of the hashing power, by whatever means necessary.

Now remember, none of the above strategy requires me to have a special
low-latency network or anything fancy. I don't even have to have a lot
of hashing power - the strategy still works if I'm, say, a 5% pool. It
just means I don't have the incentives people thought I did to propagate
my blocks widely.

The other nasty thing about this, is suppose I'm a miner and recently
got a block from another miner: should I forward that block, or not
bother? Well, it depends: if I have no idea how much of the hashing
power has that block, I should forward the block. But again, if my goal
is to be most likely to get the next block, I should only forward in
such a way that >30% of the hashing power has the block.

This means that if I have some information about what % already has that
block, I have less incentive to forward! For instance, suppose that
every major miner has been publishing their node addresses in their
blocks - I'll have a pretty good idea of who probably has that most
recent block, so I can easily make a well-optimized decision not to
forward. Similarly because the 30% hashing power figure is the
*integral* of time * hashes/second, if miners are forwarding
near-target-headers, I might as well wait a few seconds and see if I see
any near-target-headers; if I do for this block then I have evidence
that hashing power does have it, and I shouldn't forward.


So yeah, we're fucked and have got to fix this awful incentive structure
somehow before the inflation subsidy gets any smaller. Also, raising the
blocksize, especially by just removing the limit, is utter madness given
it can be used to slow down block propagation selectively, so the
hashing power that gets a given block is limited repeatably to the same
group.

-- 
'peter'[:-1]@petertodd.org
000000000000000001bd68962863e6fa34e9776df361d4926912f52fc5f4b618
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151219/e3455d95/attachment.sig>