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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1Y6Nxs-000336-Hc
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Dec 2014 18:25:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.172 as permitted sender)
client-ip=209.85.212.172;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-wi0-f172.google.com;
Received: from mail-wi0-f172.google.com ([209.85.212.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y6Nxr-0004Ep-5G
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Dec 2014 18:25:48 +0000
Received: by mail-wi0-f172.google.com with SMTP id n3so25882722wiv.11
for <bitcoin-development@lists.sourceforge.net>;
Wed, 31 Dec 2014 10:25:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.181.12.100 with SMTP id ep4mr115301762wid.62.1420050341125;
Wed, 31 Dec 2014 10:25:41 -0800 (PST)
Received: by 10.194.0.209 with HTTP; Wed, 31 Dec 2014 10:25:41 -0800 (PST)
In-Reply-To: <CAAS2fgRxysRqkSxqbF8Y9u2ptfVjX0PU6W85jD-RjSn9hUqNBA@mail.gmail.com>
References: <54A1A99E.1020604@certimix.com>
<CAAS2fgSvq_Tnon1C+xED06VYPizj+XTiDu0xm0MvCg_9-ejcjA@mail.gmail.com>
<54A2D1F4.9050306@certimix.com>
<CAAS2fgRxysRqkSxqbF8Y9u2ptfVjX0PU6W85jD-RjSn9hUqNBA@mail.gmail.com>
Date: Wed, 31 Dec 2014 13:25:41 -0500
Message-ID: <CABHVRKT6TFcdbqbdyX8D-zbUO4xFXuL3LLd1R7VLH4=JGEK9UQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0435c61425619c050b873c66
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(stephencalebmorse[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Y6Nxr-0004Ep-5G
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP: Voluntary deposit bonds
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: Wed, 31 Dec 2014 18:25:48 -0000
--f46d0435c61425619c050b873c66
Content-Type: text/plain; charset=UTF-8
I agree with Gregory Maxwell, I don't think it would be as easy as just
changing IsCoinBase(), since there are places where the code assumes that
the coinbase's vin doesn't spend any prevouts and/or has size 1. For
example, here
<https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L617-620> and
here <https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L785-L808>
.
I think the motivation behind the original suggestion is to have a way to
pay specific miners upon solving a block without risking possibly paying
other miners through pay-to-fee. What I'm not sure about, though, is why
not just send them a transaction once you see that the miner has solved a
block? Not a pay-to-fee transaction, a pay to pubkeyhash or whatever type
of transaction you need to make to send the miner some coins.
Although I don't completely understand the motivation for making such
transactions, maybe this would this work. Have outputs in the coinbase
transaction which have nValue == 0, then only apply the COINBASE_MATURITY
rule to spending coinbase outputs which have non-zero value. That way you
could make a transactions which is only valid after the miner specified
solves a block with the coinbase having the same TxID referenced by the new
transaction's input. It's still a hard fork, but might be easier than
allowing the coinbase to spend prevouts. I guess, at that point though, why
not just hard fork to allow the coinbase to spend prevouts...
Best,
Stephen
On Tue, Dec 30, 2014 at 1:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
> <sergiolerner@certimix.com> wrote:
> > Slight off-topic:
> > That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
> > Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
> > simple change that goes along the lines of Satoshi's original design.
> > Bitcoin was a beautiful design, and extra complexity is making it ugly.
> > We need Bitcoin to be simple to understand for new programmers so they
> > can keep the project going. It doesn't help the project that one needs
> > to be a guru to code for Bitcoin.
>
> Sergio there is no "abuse" there, OP_NOP3 in that case would be
> redefined to OP_COINBASE_FOO_CONSISTENCY.
>
> (I say FOO because it's not clear what rule you actually hope to apply
> there.)
>
> What you suggested has no purpose by itself: it would need an
> additional change which overlays functionality in order to actually do
> something. Such a change would likely be "ugly"-- it's easy to be
> elegant when you do nothing.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d0435c61425619c050b873c66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree with Gregory Maxwell, I don't think it would b=
e as easy as just changing IsCoinBase(), since there are places where the c=
ode assumes that the coinbase's vin doesn't spend any prevouts and/=
or has size 1. For example, <a href=3D"https://github.com/bitcoin/bitcoin/b=
lob/v0.9.3/src/main.cpp#L617-620">here</a>=C2=A0and <a href=3D"https://gith=
ub.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L785-L808">here</a>.=C2=A0<=
div><br><div>I think the motivation behind the original suggestion is to ha=
ve a way to pay specific miners upon solving a block without risking possib=
ly paying other miners through pay-to-fee. What I'm not sure about, tho=
ugh, is why not just send them a transaction once you see that the miner ha=
s solved a block? Not a pay-to-fee transaction, a pay to pubkeyhash or what=
ever type of transaction you need to make to send the miner some coins.<div=
><div><br></div><div>Although I don't completely understand the motivat=
ion for making such transactions, maybe this would this work. Have outputs =
in the coinbase transaction which have nValue =3D=3D 0, then only apply the=
COINBASE_MATURITY rule to spending coinbase outputs which have non-zero va=
lue. That way you could make a transactions which is only valid after the m=
iner specified solves a block with the coinbase having the same TxID refere=
nced by the new transaction's input. It's still a hard fork, but mi=
ght be easier than allowing the coinbase to spend prevouts. I guess, at tha=
t point though, why not just hard fork to allow the coinbase to spend prevo=
uts...</div><div><br></div><div>Best,</div><div>Stephen</div></div></div></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,=
Dec 30, 2014 at 1:28 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"=
mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, Dec 3=
0, 2014 at 4:25 PM, Sergio Lerner<br>
<<a href=3D"mailto:sergiolerner@certimix.com">sergiolerner@certimix.com<=
/a>> wrote:<br>
> Slight off-topic:<br>
> That looks like an abuse of the VM. Even P2SH is an abuse of the VM.<b=
r>
> Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking=
about a<br>
> simple change that goes along the lines of Satoshi's original desi=
gn.<br>
> Bitcoin was a beautiful design, and extra complexity is making it ugly=
.<br>
> We need Bitcoin to be simple to understand for new programmers so they=
<br>
> can keep the project going. It doesn't help the project that one n=
eeds<br>
> to be a guru to code for Bitcoin.<br>
<br>
</span>Sergio there is no "abuse" there,=C2=A0 OP_NOP3 in that ca=
se would be<br>
redefined to OP_COINBASE_FOO_CONSISTENCY.<br>
<br>
(I say FOO because it's not clear what rule you actually hope to apply =
there.)<br>
<br>
What you suggested has no purpose by itself: it would need an<br>
additional change which overlays functionality in order to actually do<br>
something. Such a change would likely be "ugly"-- it's easy t=
o be<br>
elegant when you do nothing.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Dive into the World of Parallel Programming! The Go Parallel Website,<br>
sponsored by Intel and developed in partnership with Slashdot Media, is you=
r<br>
hub for all things parallel software development, from weekly thought<br>
leadership blogs to news, videos, case studies, tutorials and more. Take a<=
br>
look and join the conversation now. <a href=3D"http://goparallel.sourceforg=
e.net" target=3D"_blank">http://goparallel.sourceforge.net</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--f46d0435c61425619c050b873c66--
|
