> There have been attacks demonstrated where a malicious miner with sufficient hashrate can leverage large blocks to exacerbate selfish mining.
Can you give me a link to this? Having done a lot of mining, I really really doubt this. I'm assuming the theory relies upon propagation times and focuses on small miners versus large ones, but that's wrong. Propagation times don't affect small miners disproportionately, though they might affect small POOLS disproportionately, that isn't the same thing at all. No miner since at least 2014 has operated a full node directly with each miner - it is incredibly impractical to do so. They retrieve only the merkle root hash and other parameters from the stratum server, which is a very small packet and does not increase with the size of the blocks. If they really want to select which transactions to include, some pools offer options of that sort(or can, I believe) but almost no one does. If they don't like how their pool picks transactions, they'll use a different pool, that simple. If there's some other theory about a miner exploiting higher blocksizes selfishly then I'd love to read up on it to understand it. If what you/others actually meant by that was smaller "pools," that's a much much smaller problem. Pools don't earn major profits and generally are at the mercy of their miners if they make bad choices or can't fix low performance. For pools, block propagation time was a major major issue even before blocks were full, and latency + packet loss between mining units and the pool is also a big concern. I was seeing occasional block propagation delays(over a minute) on a fiber connection in 2013/4 due to minute differences in peering. If a pool can't afford enough bandwidth to keep propagation times down, they can't be a pool. Bigger blocksizes will make it so they even more totally-can't-be-a-pool, but they already can't be a pool, so who cares. Plus, compact blocks should have already solve nearly all of this problem as I understand it. So definitely want to know more if I'm misunderstanding the attack vector. > We already know that large empty blocks (rather, blocks with fake transactions) can be leveraged in ways that both damages the network and increases miner profits. Maybe you're meaning an attack where other pools get stuck on validation due to processing issues? This is also a nonissue. The smallest viable pool has enough difficulties with other, non-hardware related issues that buying the largest, beefiest standard processor available with ample RAM won't even come up on the radar. No one cares about $600 in hardware versus $1000 in hardware when it takes you 6 weeks to get your peering and block propagation configuration just right and another 6 months to convince miners to substantially use your pool. If you meant miners and not pools, that's also wrong. Mining hardware doesn't validate blocks anymore, it hasn't been practical for years. They only get the merkle root hash of the valid transaction set. The pool handles the rest. > In general, fear of other currencies passing Bitcoin is unsubstantiated. Bitcoin has by far the strongest development team, and also is by far the most decentralized. Markets only care a little bit what your development team is like. Ethereum has Vitalik, who is an incredibly smart and respectable dude, while BU absolutely hates the core developers right now. Markets are more likely to put more faith in a single leader than core right now if that comparison was really made. "Most decentralized" is nearly impossible to quantify, and has almost no value to speculators. Since all of these markets are highly speculative, they only care about future demand. Future demand relies upon future use. Unsubstantiated? Ethereum is already 28% of Bitcoin by cap and 24% by trading. Four months ago that was 4%. Their transaction volume also doubled. What world are you living in? > A coin like ethereum may even be able to pass Bitcoin in market cap. But that's okay. Ethereum has very different properties and it's not something I would trust as a tool to provide me with political sovereignty. Well great, I guess so long as you're ok with it we'll just roll with it. Wait, no. If Bitcoin loses its first-mover network effect, a small cadre of die-hard libertarians are not going to be able to keep it from becoming a page in the history books. Die hard libertarians can barely keep a voice in the U.S. congress - neither markets nor day-to-day users particularly care about the philosophy, they care about what it can do for them. > Ethereum passing Bitcoin in market cap does not mean that it has proved superior to Bitcoin. The markets have literally told us why Ethereum is shooting up. Its because the Bitcoin community has fractured around a debate with nearly no progress on a solution for the last 3 years, and especially because BU appears to be strong enough to think they can fork and the markets know full well what a contentious fork will do to Bitcoin's near-term future. > It could just mean that enterprises are really excited about permissioned blockchains. Then it would have happened not when the BU situation imploded but when Microsoft announced they were working with Ethereum on things like that. No one cared about Microsoft's announcement. You don't seriously believe what you're saying, do you? > That's not interesting to me at any market cap. I agree with you, but Bitcoin becoming a page in the history books because a few die-hard libertarians didn't think price or adoption was important is a big, big concern, especially when they almost have veto power. Markets don't care about philosophy, they care about future value. Bitcoin has value because we think it may be the most useful new innovation in the future. If we screw that future usefulness up, philosophy gives us no more value than Friendster has today. On Thu, Mar 30, 2017 at 4:19 AM, David Vorick via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > What we want is a true fee-market where the miner can decide to make a > block > > smaller to get people to pay more fees, because if we were to go to 16MB > > blocks in one go, the cost of the miner would go up, but his reward > based on > > fees will go down! > > A block so big that 100% of the transactions will always be mined in the > > next block will just cause a large section of people to no longer feel > the > > need to pay fees. > > > As such I don’t fear the situation where the block size limit goes up a > lot > > in one go, because it is not in anyone’s interest to make the actual > block > > size follow. > > There have been attacks demonstrated where a malicious miner with > sufficient hashrate can leverage large blocks to exacerbate selfish mining. > Adversarial behaviors from miners need to be considered, it's not safe to > simply assume that a miner won't have reasons to attack the network. We > already know that large empty blocks (rather, blocks with fake > transactions) can be leveraged in ways that both damages the network and > increases miner profits. > > In general, fear of other currencies passing Bitcoin is unsubstantiated. > Bitcoin has by far the strongest development team, and also is by far the > most decentralized. To the best of my knowledge, Bitcoin is the only > cryptocurrency out there that is both not-dead and also lacks a strong > central leadership. > > A coin like ethereum may even be able to pass Bitcoin in market cap. But > that's okay. Ethereum has very different properties and it's not something > I would trust as a tool to provide me with political sovereignty. Ethereum > passing Bitcoin in market cap does not mean that it has proved superior to > Bitcoin. It could just mean that enterprises are really excited about > permissioned blockchains. That's not interesting to me at any market cap. > > Bitcoin's core value add is and should continue to be decentralization and > trustlessness. Nobody is remotely close to competing with Bitcoin on those > fronts, and in my mind that's far more important than any of the other > mania anyway. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
