1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WcDtu-0001IB-7W
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 13:04:46 +0000
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcDtq-0001oS-Tl
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 13:04:46 +0000
Received: by mail-la0-f43.google.com with SMTP id e16so3164204lan.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Apr 2014 06:04:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=EWvBx9QbSNPW7xLB6YHw+zAd7tIYZvsrxEZKMQDKxPw=;
b=HqPBeuZWOZUD1kvU5/YBb0X4I/TpzRtu29WbGZmJu4yFZvdwt4iDrEuLHKhLN8G7tB
2TqP49V1eM6wDWPy0vutxOMMih1E52y/bPt4yLeCNnrdjYUtdflVt6AetT82x9IXmc7K
EC23rO15QssF3jH7UR7B96HFLCwqW8xy+Fju81YtB7jX4dE9CH6Ezgkcq+HWrCXLqfc2
yFrdf1ZMXq0XpmjCcIuJC78mtBtKZm7uk0LAkNQL4+UwtoVJ43WP4b9z5lwda97kYZea
wNsQLzi941D2EsquWVfoL0K1OoULJryeydDpieYSQeKyS1AWZlqq6BqFmV3ur7uZpml0
Pmrw==
X-Gm-Message-State: ALoCoQkNMHkCRJTIQNhG9YJvcScRT8pvbAt5U8KbDgfzGZykZvBZtVAqarrhlSMaqu5ZJet/0OBx
MIME-Version: 1.0
X-Received: by 10.152.28.41 with SMTP id y9mr125775lag.57.1398085475793; Mon,
21 Apr 2014 06:04:35 -0700 (PDT)
Received: by 10.112.60.196 with HTTP; Mon, 21 Apr 2014 06:04:35 -0700 (PDT)
X-Originating-IP: [85.53.138.195]
In-Reply-To: <CAE-z3OX8PGs7B_e32BGPx2BRkKeUwEO+GY-=i-VCxmKsZG6EZw@mail.gmail.com>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>
<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>
<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
<CAE-z3OX8PGs7B_e32BGPx2BRkKeUwEO+GY-=i-VCxmKsZG6EZw@mail.gmail.com>
Date: Mon, 21 Apr 2014 15:04:35 +0200
Message-ID: <CAC1+kJMpb87zccRmGQ0KABim=08KnmU2fmiSVa2=2+JkB8_v1Q@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WcDtq-0001oS-Tl
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 13:04:46 -0000
I'm not convinced that headers first will result in miners hashing on
top of the block with more work without knowing if it's valid yet
instead of just keep hashing on top of the longest known-to-be-valid
chain.
Both options are risky for the miner in some way, and I guess the
probability of someone hashing an invalid block above difficulty is
too low to be the main concern, but there's intermediate solutions,
like say, waiting to validate at least 5% of the block.
But I don't see how miners mining headers first would result in empty
blocks either.
Why wouldn't them validate and include transactions after they have
received the full block?
They will likely know most of the transaction before receiving the block an=
yway.
In a future where they ONLY live on transaction fees, why would they
refuse to validate and include transactions? What are they hashing for
then?
If anything, looks like a threat to the current situation with huge
mining subsidies coming from the seigniorage, not a problem that you
would have when the the seigniorage is gone.
In any case, it is true that this is mining policy and therefore out
of the realm of what the protocol can regulate, so we should assume
miners will do whatever it's best for them.
The trade-off between tps and centralization remains: if you want
higher tx volume, less full nodes will be able to process it.
On 4/21/14, Tier Nolan <tier.nolan@gmail.com> wrote:
> 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 chec=
k
> 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.
>
--=20
Jorge Tim=F3n
http://freico.in/
|
