From: Justus Ranvier <justus@openbitcoinprivacyproject.org>
To: "Rune K. Svendsen" <runesvend@gmail.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Date: Mon, 21 Sep 2015 12:15:12 -0500 [thread overview]
Message-ID: <56003B20.1030504@openbitcoinprivacyproject.org> (raw)
In-Reply-To: <F59E7FFD-D4C7-45D3-8224-4C1D62D8AAB6@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1697 bytes --]
On 19/09/15 15:11, Rune K. Svendsen wrote:
> An honest miner is a miner that supports the network by building on top of the best valid chain. A malicious miner is one who wants to disrupt the Bitcoin network, not support it, for example by executing a 51% attack which mines empty blocks on top of the best chain.
This isn't a particularly good definition.
"An honest miner is a miner that supports the network by building on top
of the best valid chain."
What is the "best valid chain"? The one with the most proof of work? The
one that meets some other definition of "best"?
"A malicious miner is one who wants to disrupt the Bitcoin network, not
support it"
This is a tautology, the equivalent of saying "a malicious miner is a
miner that is malicious" A true, but entirely useless, statement.
"for example by executing a 51% attack which mines empty blocks on top
of the best chain."
Again, you're begging the question with the word "attack", because
that's what you're supposed to demonstrate.
Apparently the difference between honest mining and malicious mining is
empty blocks? You've said in both cases the miners are extending the
"best valid chain". Is extending the best valid chain with an empty
block always a malicious act?
What's the significance of 51% in this definition? Is the same empty
block which extended the best valid chain honest if the miner who
produced it has 49% of the network hashing power and malicious if they
add a few more ASIC units?
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18729 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
prev parent reply other threads:[~2015-09-21 17:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 19:05 [bitcoin-dev] Hash of UTXO set as consensus-critical Rune Kjær Svendsen
2015-09-18 19:43 ` Patrick Strateman
2015-09-18 20:07 ` Alex Morcos
2015-09-18 20:11 ` Matt Corallo
2015-09-18 20:17 ` Rune Kjær Svendsen
2015-09-18 20:37 ` Jorge Timón
2015-09-18 20:38 ` Jorge Timón
2015-09-18 22:22 ` Vincent Truong
2015-09-19 2:30 ` Justus Ranvier
2015-09-19 15:45 ` Rune Kjær Svendsen
2015-09-19 17:19 ` Justus Ranvier
2015-09-19 20:11 ` Rune K. Svendsen
2015-09-20 0:48 ` Dave Scotese
2015-09-21 17:15 ` Justus Ranvier [this message]
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=56003B20.1030504@openbitcoinprivacyproject.org \
--to=justus@openbitcoinprivacyproject.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=runesvend@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