From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
Date: Mon, 21 Apr 2014 12:34:49 +0100 [thread overview]
Message-ID: <CAE-z3OX8PGs7B_e32BGPx2BRkKeUwEO+GY-=i-VCxmKsZG6EZw@mail.gmail.com> (raw)
In-Reply-To: <a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd <pete@petertodd•org> wrote:
> Of course, in reality smaller miners can just mine on top of block headers
> and include no transactions and do no validation, but that is extremely
> harmful to the security of Bitcoin.
>
I don't think it reduces security much. It is extremely unlikely that
someone would publish an invalid block, since they would waste their POW.
Presuming that new headers are correct is reasonable, as long as you check
the full block within a few minutes of receiving the header.
If anything, it increases security, since less hashing power is wasted
while the full block is broadcast.
Block propagation could take the form
- broadcast new header
- all miners switch to mining empty blocks
- broadcast new block
- miners update to a block with transactions
If the block doesn't arrive within a timeout, then the miner could switch
back to the old block.
This would mean that a few percent of empty blocks end up in the
blockchain, but that doesn't do any harm.
It is only harmful, if it is used as a DOS attack on the network.
The empty blocks will only occur when 2 blocks are found in quick
succession, so it doesn't have much affect on average time until 1
confirm. Empty blocks are just as good for providing 1 of the 6 confirms
needed too.
[-- Attachment #2: Type: text/html, Size: 1864 bytes --]
next prev parent reply other threads:[~2014-04-21 11:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
2014-04-21 1:30 ` Jonathan Levin
2014-04-21 3:58 ` Mark Friedenbach
2014-04-21 4:06 ` Peter Todd
2014-04-21 4:44 ` Daniel Lidstrom
2014-04-21 5:46 ` Daniel Lidstrom
2014-04-21 11:34 ` Tier Nolan [this message]
2014-04-21 13:04 ` Jorge Timón
2014-04-21 15:40 ` Ashley Holman
2014-04-21 15:58 ` Alan Reiner
2014-04-21 16:00 ` Mark Friedenbach
2014-04-21 16:22 ` Paul Lyon
2014-04-21 16:38 ` Mark Friedenbach
2014-04-21 16:39 ` Mike Hearn
2014-04-21 16:45 ` Jonathan Levin
2014-04-23 2:54 ` Tom Harding
2014-04-23 15:05 ` Peter Todd
[not found] ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
2014-05-02 11:48 ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
2014-05-02 12:00 ` Sergio Lerner
[not found] ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
2014-05-05 19:45 ` Sergio Lerner
2014-05-05 20:27 ` Ittay
2014-05-07 4:31 ` [Bitcoin-development] DECOR+ Better block selection rule Sergio Lerner
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='CAE-z3OX8PGs7B_e32BGPx2BRkKeUwEO+GY-=i-VCxmKsZG6EZw@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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