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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <runesvend@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6444E955
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jan 2017 18:58:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com
[209.85.216.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D75A6127
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jan 2017 18:58:20 +0000 (UTC)
Received: by mail-qt0-f178.google.com with SMTP id v23so198997496qtb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jan 2017 10:58:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=AIuxluI/EMpD6dqbSlwxb9zYc7MX23uqPO30uFthcWE=;
b=LCj8yrjdqalzsOmSEUoJTYY3g4G/gPkqkZcctXws7tAp0c+xa/66WwWKXZuL4kSsgP
RQd+7lLQyuf4qOguqpqaPILf3pU7aE4UriTjyAtK2lQx6oWKoH1qlf69ru2E1y4ShRtI
cvRV/46U/0Kbe3A7Z1+IxhAAS2FxigQDgGB7Pl8m5jPW8i7Tjs61SZtDKezBQJuMe3d/
gEdKDrEkYDLBBzhA026VGDIzkAq7hbZ9se3XYevKkdmRkzB/f+TyNz9g8Q2vS+x/k8Vm
tTMkCpNm/WSMgNbCKmX2fCvXkWfa3Bm6gFXFHGVgtoJOqHTyRWPH+GUoVVA5qQRiMS7P
8qMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=AIuxluI/EMpD6dqbSlwxb9zYc7MX23uqPO30uFthcWE=;
b=JwnhSF+JYOxYLBlM2JVQac2sFebnPAQXLJvGdYAnXGRHd5cF2ttoLkElGMeNyVlKRw
3BdJ0gRlH8wxOQeJ2jgAuQ2CKvlLI0ZntkdqmzqZaow91ZFCoKH5ioFv/3cKvrAQqbWm
f8hlMDvLVjJzY54ceRpAFGUSyaoh944U/+alMIlAO0VFxdtnl6v5yC1K3o5tMA96i+Jg
CFh1GwGXY4ZEDzjgdDhmEcgM/kqURCyEqbke6wTZg/PL9W9W+uLyMqXb3TxFSANbz1lD
YpiSeg4vFohBOILPyoeHOHzWZHJQORIZifoVqoYhjjEdRKIY3FnuCH9JKGRV0HKMKHdL
hFZA==
X-Gm-Message-State: AIkVDXIc5IC94jUruElwBkaga9XHkOsy2aSmE6KKHGQe1WkxBNYukpu/vuiJjKzTXOZSoFF1KagEHEfe0mSGsg==
X-Received: by 10.55.4.138 with SMTP id 132mr30716927qke.190.1485284299883;
Tue, 24 Jan 2017 10:58:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.175.50 with HTTP; Tue, 24 Jan 2017 10:57:59 -0800 (PST)
From: "Rune K. Svendsen" <runesvend@gmail.com>
Date: Tue, 24 Jan 2017 19:57:59 +0100
Message-ID: <CAH2=CKzssBAUP1CfiVNxWRK-S7FvZtbMdwVWmvU62CG9hU96WQ@mail.gmail.com>
To: Bitcoin <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114c8cda15ce9d0546dbb30e
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 24 Jan 2017 20:06:41 +0000
Subject: [bitcoin-dev] Separating mining from tx verification by enabling
paying to valid POW header
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2017 18:58:21 -0000
--001a114c8cda15ce9d0546dbb30e
Content-Type: text/plain; charset=UTF-8
As mining works now, miners have to verify all Bitcoin transactions in the
blocks they mine, because they would otherwise risk producing an invalid
block. This is problematic because many miners are Chinese, and thus have
poor Internet connectivity, so it would be preferable to separate the task
of creating valid proof-of-work from the task of collecting valid
transactions.
This could be made possible by adding an opcode that checks whether the
top-most stack item is a valid block header, we could call it
OP_VALID_HEADER(VERIFY), thus allowing miners to be paid for a valid block
header through a regular Bitcoin transaction, rather than through the
coinbase transaction only. This allows a different group to simply act as
collectors of transactions, and create OP_VALID_HEADER-transactions that
pay to block headers with a merkle root that includes all the highest-fee
transactions.
So, these collectors would accumulate as many connections as possible
within the Bitcoin P2P network, and collect all the highest fee
transactions they can find. Then construct a block which includes all these
transactions, and a coinbase tx that pays the block reward plus fees to the
collector.
With this block the collector would then create a Bitcoin transaction, with
a OP_VALID_HEADER-output that can be redeemed by supplying the block header
in the script but with a modified nonce/timestamp such that the
proof-of-work+timestamp is valid. Miners would then only have to look for
these Bitcoin transactions from the collectors, and mine on whichever
header pays them the most, without having to care about whether the block
in question includes invalid transactions, because the miner is paid for
just a valid proof-of-work hash. When the miner finds a solution, it
publishes the transaction, the collector see this transaction, gets it
valid header, and publishes the block.
A side bonus of this is that botnet miners can now participate on basically
equal footing with traditional miners: they just listen to the P2P network
for the transaction from the collector who pays them the most, which will
include as many transactions as possible to earn the most in fees, thus
verifying transactions without having to do the work.
/Rune
--001a114c8cda15ce9d0546dbb30e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As mining works now, miners have to verify all Bitcoin tra=
nsactions in the blocks they mine, because they would otherwise risk produc=
ing an invalid block. This is problematic because many miners are Chinese, =
and thus have poor Internet connectivity, so it would be preferable to sepa=
rate the task of creating valid proof-of-work from the task of collecting v=
alid transactions.=C2=A0<div><br></div><div>This could be made possible by =
adding an opcode that checks whether the top-most stack item is a valid blo=
ck header, we could call it OP_VALID_HEADER(VERIFY), thus allowing miners t=
o be paid for a valid block header through a regular Bitcoin transaction, r=
ather than through the coinbase transaction only. This allows a different g=
roup to simply act as collectors of transactions, and create OP_VALID_HEADE=
R-transactions that pay to block headers with a merkle root that includes a=
ll the highest-fee transactions.</div><div><br></div><div>So, these collect=
ors would accumulate as many connections as possible within the Bitcoin P2P=
network, and collect all the highest fee transactions they can find. Then =
construct a block which includes all these transactions, and a coinbase tx =
that pays the block reward plus fees=C2=A0to the collector.=C2=A0</div><div=
><br></div><div>With this block the collector would then create a Bitcoin t=
ransaction, with a OP_VALID_HEADER-output that can be redeemed by supplying=
the block header in the script but with a modified nonce/timestamp such th=
at the proof-of-work+timestamp is valid. Miners would then only have to loo=
k for these Bitcoin transactions from the collectors, and mine on whichever=
header pays them the most, without having to care about whether the block =
in question includes invalid transactions, because the miner is paid for ju=
st a valid proof-of-work hash. When the miner finds a solution, it publishe=
s the transaction, the collector see this transaction, gets it valid header=
, and publishes the block.</div><div><br></div><div>A side bonus of this is=
that botnet miners can now participate on basically equal footing with tra=
ditional miners: they just listen to the P2P network for the transaction fr=
om the collector who pays them the most, which will include as many transac=
tions as possible to earn the most in fees, thus verifying transactions wit=
hout having to do the work.</div><div><br></div><div><br></div><div><br></d=
iv><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 /Rune</div></div>
--001a114c8cda15ce9d0546dbb30e--
|
