Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Matt Corallo


On 05/29/15 23:48, Gavin Andresen wrote:
 On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me
 mailto:bitcoin-l...@bluematt.me wrote:
 
 Sadly, this is very far from the whole story. The issue of miners
 optimizing for returns has been discussed several times during this
 discussion, and, sadly, miners who are geographically colocated who are
 optimizing for returns with a free-floating blocksize will optimize away
 50% of the network!
 
 
 I must have missed that analysis-- link please?  Or summary of HOW they
 will optimize away 50% of the network?
 
 Or are you assuming that 50% of the network is colocated... (which is a
 potential problem independent of blocksize)

If, for example, the majority of miners are in China (they are), and
there is really poor connectivity in and out of China (there is) and a
miner naively optimizes for profit, they will create blocks which are
large and take a while to relay out of China. By simple trial-and-error
an individual large miner might notice that when they create larger
blocks which fork off miners in other parts of the world, they get more
income. Obviously forking off 50% of the network would be a rather
extreme situation and assumes all kinds of simplified models, but it
shows that the incentives here are very far from aligned, and your
simplified good-behavior models are very far from convincing.

 
 
  In addition, I'd expect to
  see analysis of how these systems perform in the worst-case, not 
 just
  packet-loss-wise, but in the face of miners attempting to break the
  system.
 
 
  See 
 http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
  analysis of but that means bigger miners can get an advantage 
 argument.
 
  Executive summary: if little miners are stupid and produce huge blocks,
  then yes, big miners have an advantage.
 
 I'll talk about transaction fees in a second, but there are several
 problems with this already. As pointed out in the original mail, gfw has
 already been known to interfere with Bitcoin P2P traffic. So now by
 little miners, you mean any miner who is not located in mainland
 China? Whats worse, the disadvantage is symmetric - little miners are at
 a disadvantage when *anyone* mines a bigger block, and miners dont even
 have to be evil for this to happen - just optimize for profits.
 
 
 But the disadvantage is tiny. And essentially zero if they connect to
 your fast relay network (or anything like it).
 

The disadvantage is small with 1MB blocks, but already non-zero. 20MB
blocks are much, much worse (lots of things here dont scale linearly,
even just transfer over a high-packet-loss-link). I mentioned this in my
original email as something which doesnt make me comfortable with 20MB
blocks, but something which needs simulation and study, and might
actually be just fine!

 
  But they're not, so they won't.
 
 I dont know what you're referring to with this. Are you claiming little
 miners today optimize for relay times and have good visibility into the
 Bitcoin network and calculate an optimal block size based on this (or
 would with a 20MB block size)?
 
 
 Do you have another explanation for why miners choose to leave
 fee-paying transactions in their mempool and create small blocks?

Defaults? Dumb designs? Most miners just use the default 750K blocks, as
far as I can tell, other miners probably didnt see transactions relayed
across several hops or so, and a select few miners are doing crazy
things like making their blocks fit in a single packet to cross the gfw,
but that is probably overkill and not well-researched.

  Until the block reward goes away, and assuming transaction fees become
  an important source of revenue for miners.
  I think it is too early to worry about that; see:
 
 http://gavinandresen.ninja/when-the-block-reward-goes-away
 
 You dont make any points here with which I can argue, but let me respond
 with the reason /I/ think it is a problem worth thinking a little bit
 about...If we increase the blocksize sufficiently such that transaction
 fees are not the way in which miners make their money
 
 
 I'm not suggesting that we increase the blocksize sufficiently such that
 transaction fees are not the way in which miners make their money.
 
 I'm suggesting the blocksize be increased to 20MB (and then doubled
 every couple of years).

Do you have convincing evidence that at 20MB miners will be able to
break even on transaction fees for a long time? (The answer is no
because no one has any idea how bitcoin transaction volumes are going to
scale, period.)

 And in which miners make their money is the wrong metric-- we want
 enough mining so the network to be secure enough against double-spends.

Sure, do you have a value of hashpower which is secure enough (which
is a whole other rabbit hole to 

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Alex Mizrahi

 Stop trying to dictate block growth limits.  Block size will be determined
 by competition between miners and availability of transactions, not through
 hard-coded limits.

Do you even game theory, bro? It doesn't work that way.

Mike Hearn described the problem in this article:
https://medium.com/@octskyward/hashing-7d04a887acc8

But the solution he's proposing is ridiculously bad and unsound: he expects
business owners to donate large sums of money towards mining. If it comes
to this, what sane business owner will donate, say, 100 BTC to miners
instead of seeking some alternatives? Proof-of-stake coins are already
there. I'm well aware of theoretical issues with PoS security, but those
theoretical issues aren't as bad as donation-funded cryptocurrency security.

But you know what works? Mining fees + block size limit.
Users and merchants are interested in their transactions being confirmed,
but block size limit won't allow it to turn into a race to bottom.
This is actually game-theoretically sound.


   I see now the temporary 1MB limit was a mistake.  It should have gone in
 as a dynamic limit that scales with average block size.

This means that miners will control it, and miners couldn't care less about
things like decentralization and about problems of ordinary users. This
means that in this scenario Bitcoin will be 100% controlled by few huge-ass
mining operations.

Possibly a single operation. We already saw GHASH.IO using 51% of total
hashpower. Is that what you want?

Miners are NOT benevolent. This was already demonstrated. They are greedy.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Gavin Andresen
On Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote:

 Hello. I am from F2Pool. We are currently mining the biggest blocks on
 the network.


Thanks for giving your opinion!



 Bad miners could attack us and the network with artificial
 big blocks.


How?

I ran some simulations, and I could not find a network topology where a big
miner producing big blocks could cause a loss of profit to another miner
(big or small) producing smaller blocks:

http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

(the 0.3% advantage I DID find was for the situation where EVERYBODY was
producing big blocks).


 We think
 the max block size should be increased, but must be increased
 smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
 and so on. Thanks.


Why 2 MB ?   You said that server bandwidth is much more expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development