public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jared Lee Richardson <jaredr26@gmail.com>
To: David Vorick <david.vorick@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Thu, 30 Mar 2017 14:42:31 -0700	[thread overview]
Message-ID: <CAD1TkXtHpb+aZhYufLRhDAy9=K9H+DZdDjounPubUuR9idVT3w@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnypMev625j6htvpC+xJo3y5VgWednOBaRhqtuiMKKNPFsw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 8503 bytes --]

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 11912 bytes --]

  reply	other threads:[~2017-03-30 21:42 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 19:50 [bitcoin-dev] Hard fork proposal from last week's meeting Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19   ` David Vorick
2017-03-30 21:42     ` Jared Lee Richardson [this message]
2017-03-30 11:24   ` Aymeric Vitte
  -- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
     [not found]   ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01  1:41     ` Rodney Morris
2017-04-01  6:18   ` Jared Lee Richardson
2017-04-01  7:41     ` Eric Voskuil
     [not found]       ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
     [not found]         ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45           ` Natanael
     [not found]       ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42         ` Jared Lee Richardson
     [not found]   ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
     [not found]     ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26       ` Natanael
2017-03-29 19:33 Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17   ` Jared Lee Richardson
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08   ` Jared Lee Richardson
2017-03-30  7:11     ` Luv Khemani
2017-03-30 17:16       ` Jared Lee Richardson
2017-03-31  4:21         ` Luv Khemani
2017-03-31  5:28           ` Jared Lee Richardson
2017-03-31  8:19             ` Luv Khemani
2017-03-31 15:59               ` Jared Lee Richardson
2017-03-31 16:14                 ` David Vorick
2017-03-31 16:46                   ` Jared Lee Richardson
2017-03-31 18:23                     ` David Vorick
2017-03-31 18:58                       ` Eric Voskuil
2017-04-01  6:15                       ` Jared Lee Richardson
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53   ` Alphonse Pace
2017-03-28 21:06     ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29  8:45   ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31   ` Wang Chun
2017-03-28 17:33     ` Jeremy
2017-03-28 17:50     ` Douglas Roark
2017-03-28 17:33   ` Juan Garavaglia
2017-03-28 17:53     ` Alphonse Pace
2017-03-28 22:36       ` Juan Garavaglia
2017-03-29  2:59         ` Luv Khemani
2017-03-29  6:24         ` Emin Gün Sirer
2017-03-29 15:34           ` Johnson Lau
2017-04-01 16:15             ` Leandro Coutinho
2017-03-29  9:16       ` Jared Lee Richardson
2017-03-29 16:00         ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46   ` Luke Dashjr
2017-03-28 20:50   ` Tom Zander
2017-03-29  4:21     ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29  6:32 ` Bram Cohen
2017-03-29  9:37   ` Jorge Timón
2017-03-29 19:07     ` Jared Lee Richardson
2017-04-02 19:02       ` Staf Verhaegen
2017-03-29  7:49 ` Martin Lízner
2017-03-29 15:57   ` David Vorick
2017-03-29 16:08     ` Aymeric Vitte
     [not found]       ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18         ` David Vorick
2017-03-29 16:20           ` Andrew Johnson
2017-03-29 16:25             ` David Vorick
2017-03-29 16:41               ` Andrew Johnson
2017-03-29 17:14                 ` Aymeric Vitte
2017-03-29 20:53               ` Jared Lee Richardson
2017-03-29 20:32           ` Jared Lee Richardson
2017-03-29 21:36             ` praxeology_guy
2017-03-29 22:33             ` Aymeric Vitte
2017-03-30  5:23               ` Ryan J Martin
2017-03-30 10:30                 ` Tom Zander
2017-03-30 16:44                   ` Jared Lee Richardson
2017-03-30 20:51                   ` Jared Lee Richardson
2017-03-30 21:57                     ` Tom Zander
     [not found]               ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13                 ` Aymeric Vitte
2017-03-29 19:46     ` Jared Lee Richardson
2017-03-29 19:10   ` Jared Lee Richardson
2017-03-29 19:36     ` praxeology_guy
2017-04-02 19:12     ` Staf Verhaegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD1TkXtHpb+aZhYufLRhDAy9=K9H+DZdDjounPubUuR9idVT3w@mail.gmail.com' \
    --to=jaredr26@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=david.vorick@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox