I'm posting this thread to raise concerns about this change.
First off, some background on block size tradeoffs. This is transcribed from a slide in Adam Back's presentation "Bitcoin Scaling Tradeoffs":
Second, some info from Luke-Jr via #namecoin-dev about what block size is safe if we don't want the above "workarounds" to happen.Adam Back's slides wrote: Why do miners prefer smaller blocks?
Workarounds today
- Orphan rate - mining is a race to propagate block in last 3 seconds
- Limit is latency, burstiness not bandwidth
- 1MB is not much, but it is hard to global broadcast in 3 seconds
What happens if orphan rate goes up?
- Use a pool! (eg slush!)
- Relay network (custom routes, network compression, much faster medium size miners)
- Peering (large miners use peering)
- Not so good: validationless mining reduces SPV security (eg BIP66 4th july side-effect)
- Miners work around it: more validationless mining, more centralized huge pools... one pool?
- But centralisation presents risk to Bitcoin's main properties.
(Some messages have been redacted due to being off-topic.)
Code: Select all
Apr 21 04:14:11 <Jeremy_Rand> Luke-Jr: are my recollections of 3 to 4MB being the "safe" limit for block size with current relay tech still accurate? I haven't read up on this topic in many months
Apr 21 04:15:13 <qpm> freenode:<Luke-Jr> Jeremy_Rand: safe is like 400-500k :/
Apr 21 04:15:22 <qpm> freenode:<Luke-Jr> maybe lower, I forgt
Apr 21 04:16:02 <Jeremy_Rand> Luke-Jr: ah. That's news to me. I could have sworn someone (was it Austin Hill?) said in a press interview the limit was between 3 and 4?
Apr 21 04:16:03 <qpm> freenode:<Squidicuz> Luke-Jr, so we should be mining smaller blocks at the moment?
Apr 21 04:16:22 <qpm> freenode:<Luke-Jr> Squidicuz: yes
Apr 21 04:16:28 <qpm> freenode:<Squidicuz> okay :\
Apr 21 04:16:36 <Jeremy_Rand> (I'm not arguing with you, just curious why my memory conflicts with what you say)
Apr 21 04:16:37 <qpm> freenode:<Luke-Jr> Jeremy_Rand: for a centralised Bitcoin, that might be true
Apr 21 04:16:47 <Jeremy_Rand> ah
Apr 21 04:16:48 <Jeremy_Rand> I see
Apr 21 04:16:51 <qpm> freenode:<Luke-Jr> right now, Bitcoin is very centralised :/
Apr 21 04:17:05 <Jeremy_Rand> yeah. Centralization of Bitcoin makes me sad
Apr 21 04:17:09 <qpm> freenode:<Squidicuz> centralised where though?
Apr 21 04:17:51 <qpm> freenode:<Squidicuz> which aspect*
Apr 21 04:18:05 <qpm> freenode:<Luke-Jr> Squidicuz: there's handful of miners, who rely on a block relay backbone run by Matt
Apr 21 04:18:22 <qpm> freenode:<Squidicuz> true, but why is that bad?
Apr 21 04:18:54 <qpm> freenode:<Squidicuz> the whole network is made of relying on someone who is doing something for someone/something
Apr 21 04:18:56 <qpm> freenode:<Squidicuz> ...
Apr 21 04:19:29 <Jeremy_Rand> Luke-Jr: curious why the block relay system from Matt can't be used for the public P2P network?
Apr 21 04:19:42 <qpm> freenode:<Squidicuz> it is isolated collusion between pockets that breed corruptions :s
Apr 21 04:20:05 <qpm> freenode:<Luke-Jr> Jeremy_Rand: the benefit is mostly because there's 2 hops instead of N
Apr 21 04:20:07 <qpm> freenode:<Squidicuz> Jeremy_Rand, in latest there is part of that relay for just the blocks
Apr 21 04:20:18 <qpm> freenode:<Squidicuz> _i think_
Apr 21 04:20:32 <Jeremy_Rand> Luke-Jr: oh. So it only works because it's centralized by design.
Apr 21 04:20:40 <qpm> freenode:<Luke-Jr> yes
Apr 21 04:20:52 <Jeremy_Rand> so many things on the Internet have that property
Apr 21 04:20:53 <qpm> freenode:<Luke-Jr> I mean, Matt is working on new block relay p2p code, but that can only do so much
Apr 21 04:20:54 <qpm> freenode:<Squidicuz> oh
Apr 21 04:20:56 <Jeremy_Rand> makes me sad
Apr 21 04:21:01 <qpm> freenode:<Squidicuz> but that is and isn;'t bad. .
Apr 21 04:21:22 <qpm> freenode:<Luke-Jr> Squidicuz: a court could literally order Matt to censor an address, and he could effectively do it
Apr 21 04:21:24 <qpm> freenode:<Squidicuz> it could be much better. yes
Apr 21 04:21:37 <qpm> freenode:<Squidicuz> hmmm
Apr 21 04:21:47 <qpm> freenode:<Luke-Jr> any block with a transaction paying that address would be penalised heavily by the relay network filtering it
Apr 21 04:21:55 <qpm> freenode:<Squidicuz> Luke-Jr, cuz the service is centralized. ?
Apr 21 04:22:06 <qpm> freenode:<Luke-Jr> Squidicuz: yes
Apr 21 04:22:13 <qpm> freenode:<Squidicuz> hmph
Apr 21 04:22:33 <qpm> freenode:<Squidicuz> Luke-Jr, but isn't that block relay part being added to mian?
Apr 21 04:22:43 <qpm> freenode:<Squidicuz> I mean core.. err soon*
Apr 21 04:22:58 <qpm> freenode:<Luke-Jr> the protocol improvements are, but you can't reduce hops in p2p
The BDB lock limit, according to https://github.com/bitcoin/bips/blob/ma ... .mediawiki , in practice enforces a maximum block size that is a bit larger than 500 kbytes, which is close to the threshold that Luke describes as safe. It's also much larger than our currently mined blocks. I asked Luke on #namecoin-dev whether it would be fair to infer from this that we should keep the BDB lock limit in place.
(Some messages have been redacted due to being off-topic.)
Code: Select all
May 15 18:14:34 <Jeremy_Rand> Hi Luke-Jr. On April 21 you said here that the safe block size limit for a decentralized Bitcoin would be somewhere around 400-500k? Any chance you might be able to provide me with a link where I could read up on that?
May 15 18:32:22 <qpm> freenode:<luke-jr> nope
May 15 18:36:51 <Jeremy_Rand> Luke-Jr: let me give you some background on why I'm curious about the 400-500k. Right now Namecoin has a lower block size limit than Bitcoin, because we never lifted the BDB lock limit (ported from the temporary fix that Bitcoin Core deployed before BDB was phased out)
May 15 18:37:52 <Jeremy_Rand> At the moment, domob is planning to remove that lock limit when we hardfork for BIP9. But if lower block size than Bitcoin's current max is beneficial, that might affect our decision on whether to leave the lock limit in place.
May 15 18:39:19 <Jeremy_Rand> So, if you're able to provide us with some info so that we can make a more informed decision on that, it would be greatly appreciated
May 15 18:40:38 <qpm> freenode:<luke-jr> as of right now, mining over the p2p network is unfeasible
May 15 18:40:45 <qpm> freenode:<luke-jr> miners all rely on Matt's centralised block relay backbone
May 15 18:46:24 <Jeremy_Rand> luke-jr: would that situation be improved if the block size were limited to the amounts that the BDB lock limit enforced? If it would be an improvement, would it be slight or significant?
May 15 18:47:04 <qpm> freenode:<luke-jr> it'd be an accidental improvement in the typical case
May 15 18:47:25 <qpm> freenode:<luke-jr> that being said, the bdb lock limit is arguably a useful limit to retain anyway
May 15 18:49:14 <Jeremy_Rand> luke-jr: ok. So in Namecoin's case, since we don't have a huge volume of non-spam transactions, and since we value decentralization highly, would it make sense for us to keep the BDB lock limit in place, at least until either we seriously need more block size or better scaling tech is produced in the Bitcoin world?
May 15 18:49:50 <qpm> freenode:<luke-jr> probably
May 15 18:51:21 <Jeremy_Rand> luke-jr: ok. Thanks for the analysis. Is it okay if I send a chatlog of this conversation to some other Namecoin devs who don't hang around in IRC all the time? (Or for that matter, is it okay if I paste it into the public Namecoin forum?)
May 15 18:51:37 <qpm> freenode:<luke-jr> sure
May 15 18:52:10 <Jeremy_Rand> is that a "sure" to both requests, or just the former?
May 15 18:52:18 <qpm> freenode:<luke-jr> I don't care
May 15 18:52:24 <qpm> freenode:<luke-jr> I assume this channle is public anyway
May 15 18:53:04 <Jeremy_Rand> ok. I'll post it on the Namecoin forum when I have a few minutes
Thoughts on this?