From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81066B73 for ; Thu, 30 Mar 2017 21:42:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 329D7106 for ; Thu, 30 Mar 2017 21:42:33 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id s68so70869660vke.3 for ; Thu, 30 Mar 2017 14:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=C3Fti1YEZakq95NUxELikPyhpE2RiH5Bgp+cqs2VTNw=; b=bY9DgjkAgOYkifpvWH0j0HAzhDnpj4qJzqWidt986rhft9l0M7DYxG9tM1Cm7Tu4gt MhHQidhkSqwcQS69v/HTy7Oc2rfm31LsnZDM5Mg4BFVhk72yt5YxihXC59IWfLYHEX/h t1XS61CRVAndwcz2c0PVu0huyvOWxhD9pce9dR2uB/DrsO13YYqCGM5wcqR2pdCiqbAx pfCADLRcxLYbXl4GT1E5dVcyFW/RDIqRUzx9g+zgfbAPtv+rohrDd4SnEPQ9CgRPY1JL vmvV4g23QkeH5Zdpg/cX9vZfn9ZVowe2my76BSQKJa+F9Q0zrLT55iCwF91ZTcarF9H8 RrVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=C3Fti1YEZakq95NUxELikPyhpE2RiH5Bgp+cqs2VTNw=; b=Cyx31Hu7djF90j/5JLlpn3jfMzZgIa+r0w1K3/h6xiz0qVUXXVOjDYtQxdtjAHn349 r9OAowMRv4qY0dNB//8aCy5f1easHH1tt8t7RoPd9RBWh0G39Py6DEaDNV48JUC9cJSV L/Gt+83/s+QKWlN4Hhx5dV2Ctd/ExLgOszTBftfdVYJDjT7vs7iP4ISKghfZ5ryHWrHD Bkysw/9PXCC8gj/VUPcUrsTbOelJqaEKZbKxc2nxpYOygPW6fW4/tRdKb45Gi3wEanui dkjnGyItIkfN/hQDYf/0+b/FWz1n6jffrm/7P3ZZXdldnhD/0QOXUqZWlrvybTwzLOIf g1XA== X-Gm-Message-State: AFeK/H2CgB4TePW32uZn+wm+vNjbTEOSQSYBdIgLak86JH17nfKqrlh3or+Jx3rF131qrhSovR9sjcRpkHyP8A== X-Received: by 10.176.84.209 with SMTP id q17mr1084013uaa.129.1490910152070; Thu, 30 Mar 2017 14:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 14:42:31 -0700 (PDT) In-Reply-To: References: <42619430.6XQoorDgjR@strawberry> From: Jared Lee Richardson Date: Thu, 30 Mar 2017 14:42:31 -0700 Message-ID: To: David Vorick , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=f403045e20e201a066054bf9925b X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 30 Mar 2017 22:03:55 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:42:34 -0000 --f403045e20e201a066054bf9925b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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 16M= B > > 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 th= e > > next block will just cause a large section of people to no longer feel > the > > need to pay fees. > > > As such I don=E2=80=99t fear the situation where the block size limit g= oes up a > lot > > in one go, because it is not in anyone=E2=80=99s interest to make the a= ctual > block > > size follow. > > There have been attacks demonstrated where a malicious miner with > sufficient hashrate can leverage large blocks to exacerbate selfish minin= g. > 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 somethin= g > I would trust as a tool to provide me with political sovereignty. Ethereu= m > passing Bitcoin in market cap does not mean that it has proved superior t= o > 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 an= d > trustlessness. Nobody is remotely close to competing with Bitcoin on thos= e > 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 > > --f403045e20e201a066054bf9925b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0There 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?=C2=A0 Having done a lot of mining,= I really really doubt this.=C2=A0 I'm assuming the theory relies upon = propagation times and focuses on small miners versus large ones, but that&#= 39;s wrong.=C2=A0 Propagation times don't affect small miners dispropor= tionately, though they might affect small POOLS disproportionately, that is= n't the same thing at all.=C2=A0 No miner since at least 2014 has opera= ted a full node directly with each miner - it is incredibly impractical to = do so.=C2=A0 They retrieve only the merkle root hash and other parameters f= rom the stratum server, which is a very small packet and does not increase = with the size of the blocks.=C2=A0 If they really want to select which tran= sactions to include, some pools offer options of that sort(or can, I believ= e) but almost no one does.=C2=A0 If they don't like how their pool pick= s transactions, they'll use a different pool, that simple.

If th= ere's some other theory about a miner exploiting higher blocksizes self= ishly then I'd love to read up on it to understand it.=C2=A0 If what yo= u/others actually meant by that was smaller "pools," that's a= much much smaller problem.=C2=A0 Pools don't earn major profits and ge= nerally are at the mercy of their miners if they make bad choices or can= 9;t fix low performance.=C2=A0 For pools, block propagation time was a majo= r major issue even before blocks were full, and latency + packet loss betwe= en mining units and the pool is also a big concern.=C2=A0 I was seeing occa= sional block propagation delays(over a minute) on a fiber connection in 201= 3/4 due to minute differences in peering.=C2=A0 If a pool can't afford = enough bandwidth to keep propagation times down, they can't be a pool.= =C2=A0 Bigger blocksizes will make it so they even more totally-can't-b= e-a-pool, but they already can't be a pool, so who cares.=C2=A0 Plus, c= ompact blocks should have already solve nearly all of this problem as I und= erstand it.

So definitely want to know more if I'm misunderstand= ing the attack vector.

>=C2=A0We already know that large empty blocks (rath= er, blocks with fake transactions) can be leveraged in ways that both damag= es the network and increases miner profits.

Maybe you're meaning an attac= k where other pools get stuck on validation due to processing issues?=C2=A0= This is also a nonissue.=C2=A0 The smallest viable pool has enough difficu= lties with other, non-hardware related issues that buying the largest, beef= iest standard processor available with ample RAM won't even come up on = the radar.=C2=A0 No one cares about $600 in hardware versus $1000 in hardwa= re when it takes you 6 weeks to get your peering and block propagation conf= iguration just right and another 6 months to convince miners to substantial= ly use your pool.

If you meant miners and not pools, that's also= wrong.=C2=A0 Mining hardware doesn't validate blocks anymore, it hasn&= #39;t been practical for years.=C2=A0 They only get the merkle root hash of= the valid transaction set.=C2=A0 The pool handles the rest.

>=C2= =A0In gene= ral, fear of other currencies passing Bitcoin is unsubstantiated. Bitcoin h= as by far the strongest development team, and also is by far the most decen= tralized.

Markets only care a little bit what your development team = is like.=C2=A0 Ethereum has Vitalik, who is an incredibly smart and respect= able dude, while BU absolutely hates the core developers right now.=C2=A0 M= arkets are more likely to put more faith in a single leader than core right= now if that comparison was really made.

"Most decentralized&qu= ot; is nearly impossible to quantify, and has almost no value to speculator= s.=C2=A0 Since all of these markets are highly speculative, they only care = about future demand.=C2=A0 Future demand relies upon future use.=C2=A0 Unsu= bstantiated?=C2=A0 Ethereum is already 28% of Bitcoin by cap and 24% by tra= ding.=C2=A0 Four months ago that was 4%.=C2=A0 Their transaction volume als= o doubled.=C2=A0 What world are you living in?

>=C2=A0A coin like ethereum ma= y 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.=C2=A0 Wait, = no.=C2=A0 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.=C2=A0 Die hard libertarians can barely keep a vo= ice in the U.S. congress - neither markets nor day-to-day users particularl= y care about the philosophy, they care about what it can do for them.

<= /span>
= >=C2=A0= Ethereum passing Bitcoin in market cap does not mean that it has proved sup= erior to Bitcoin.=C2=A0

The markets have literally told us why Ethereum is sho= oting up.=C2=A0 Its because the Bitcoin community has fractured around a de= bate with nearly no progress on a solution for the last 3 years, and especi= ally 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 nea= r-term future.

>=C2=A0It could just mean that enterprises are really excite= d about permissioned blockchains.

Then it would have happened not wh= en the BU situation imploded but when Microsoft announced they were working= with Ethereum on things like that.=C2=A0 No one cared about Microsoft'= s announcement.=C2=A0 You don't seriously believe what you're sayin= g, do you?

>=C2=A0That's not interesting to me at any market cap.
I agree with you, but Bitcoin becoming a page in the history books becaus= e a few die-hard libertarians didn't think price or adoption was import= ant is a big, big concern, especially when they almost have veto power.=C2= =A0 Markets don't care about philosophy, they care about future value.= =C2=A0 Bitcoin has value because we think it may be the most useful new inn= ovation in the future.=C2=A0 If we screw that future usefulness up, philoso= phy 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:
>=C2=A0What we want is a true fee-market where the miner can decide to make a b= lock
= > smaller to get people to pay more fees, because if we were to go to 16= MB
> 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 a= lways be mined in the
> nex= t block will just cause a large section of people to no longer feel the
> need to pay fees.

> As such I don=E2=80=99t fear the situation where the b= lock size limit goes up a lot
= > in one go, because it is not in anyone=E2=80=99s 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 ex= acerbate selfish mining. Adversarial behaviors from miners need to be consi= dered, it's not safe to simply assume that a miner won't have reaso= ns to attack the network. We already know that large empty blocks (rather, = blocks with fake transactions) can be leveraged in ways that both damages t= he network and increases miner profits.

In g= eneral, fear of other currencies passing Bitcoin is unsubstantiated. Bitcoi= n has by far the strongest development team, and also is by far the most de= centralized. To the best of my knowledge, Bitcoin is the only cryptocurrenc= y out there that is both not-dead and also lacks a strong central leadershi= p.

A coin like ethereum may even be able to = pass Bitcoin in market cap. But that's okay. Ethereum has very differen= t 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 en= terprises are really excited about permissioned blockchains. That's not= interesting to me at any market cap.

Bit= coin'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


--f403045e20e201a066054bf9925b--