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
216
217
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Wd5cN-00026V-1h
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 22:26:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.51 as permitted sender)
client-ip=209.85.216.51; envelope-from=tier.nolan@gmail.com;
helo=mail-qa0-f51.google.com;
Received: from mail-qa0-f51.google.com ([209.85.216.51])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd5cL-0000hI-Ui
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 22:26:15 +0000
Received: by mail-qa0-f51.google.com with SMTP id j7so1512076qaq.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 15:26:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.20.113 with SMTP id 104mr58081393qgi.71.1398291968427;
Wed, 23 Apr 2014 15:26:08 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 15:26:08 -0700 (PDT)
In-Reply-To: <CAAS2fgQQyY=BGcM21EJiMkwBH0G5J57ahYEiD=bQTuprLHrHPA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
<CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
<CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
<CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
<CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com>
<CAE-z3OX7AppQeBcMBArccELQxnZBPNCefiRJvTt0gYYjxKAQuQ@mail.gmail.com>
<CAAS2fgQQyY=BGcM21EJiMkwBH0G5J57ahYEiD=bQTuprLHrHPA@mail.gmail.com>
Date: Wed, 23 Apr 2014 23:26:08 +0100
Message-ID: <CAE-z3OX3mC5bvBAXCoT3oECP6C=c=tLUD1QNVvdTcqLgQRyhcA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c12d1812165c04f7bd3859
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
(tier.nolan[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: 1Wd5cL-0000hI-Ui
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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, 23 Apr 2014 22:26:15 -0000
--001a11c12d1812165c04f7bd3859
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> You can see me proposing this kind of thing in a number of places (e.g.
> http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
> only forces the subsidy today, but the same mechnism could instead
> force transactions..
Interesting. You set the share-block size to 16kB and set the share POW to
1/64 of the main target.
Each share-block would be allowed to append up to 16kB on the previous
share-block.
This would keep the bandwidth the same, but on average blocks would be only
512kB.
e.g. to get you fast confirmation.", or
> previously on BCT for the last couple years) but there are still
> limits here: If you don't follow the fast-confirmation share chain
> you cannot mine third party transactions because you'll be at risk of
> mining a double spend that gets you orphaned, or building on a prior
> block that other miners have decided is bad. This means that if the
> latency or data rate requirements of the share chain are too large
> relative to ordinary mining it may create some centralization
> pressure.
>
This effect could be reduced by having "colours" for blocks and
transactions.
The block colour would be a loop based on block height.
You could have 16 transaction "colours" based on the lowest 4 bits in the
txId.
A transaction is only valid if all inputs into the transaction are the
correct colour for that block.
This allows blocks to be created in advance. If you are processing colour
7 at the moment, you can have a colour 8 block ready.
16 colours is probably to many. It would only be necessary for things
like 1 second block rates.
The disadvantage is that wallets would have to make sure that they have
coins for each of the 16 colours.
If you spend the wrong colour, you add 16 block times of latency.
>
> That said, I think using a fast confirmation share-chain is much
> better than decreasing block times and could be a very useful tool if
> we believe that there are many applications which could be improved
> with e.g. a 30 second or 1 minute interblock time. Mostly my thinking
> has been that these retail applications really want sub-second
> confirmation, which can't reasonably be provided in this manner so I
> didn't mention it in this thread.
>
In a shop setting, you could set it up so that the person scans a QR-code
to setup a channel with the shop.
They can then scan all their stuff and by the time they have done that, the
channel would be ready.
If there was a queue, it could be done when the person enters the queue.
In fact, there could be QR-codes at multiple locations.
--001a11c12d1812165c04f7bd3859
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">
</div>You can see me proposing this kind of thing in a number of places (e.=
g.<br>
<a href=3D"http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt" t=
arget=3D"_blank">http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.=
txt</a> "p2pool<br>
only forces the subsidy today, but the same mechnism could instead<br>
force transactions..</blockquote><div><br></div><div>Interesting.=C2=A0 You=
set the share-block size to 16kB and set the share POW to 1/64 of the main=
target.<br><br></div><div>Each share-block would be allowed to append up t=
o 16kB on the previous share-block.<br>
<br></div><div>This would keep the bandwidth the same, but on average block=
s would be only 512kB.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> e.g. to=
get you fast confirmation.", or<br>
previously on BCT for the last couple years) but there are still<br>
limits here: =C2=A0If you don't follow the fast-confirmation share chai=
n<br>
you cannot mine third party transactions because you'll be at risk of<b=
r>
mining a double spend that gets you orphaned, or building on a prior<br>
block that other miners have decided is bad. =C2=A0This means that if the<b=
r>
latency or data rate requirements of the share chain are too large<br>
relative to ordinary mining it may create some centralization<br>
pressure.<br></blockquote><br></div><div class=3D"gmail_quote">This effect =
could be reduced by having "colours" for blocks and transactions.=
<br><br>The block colour would be a loop based on block height.<br></div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">You could h=
ave 16 transaction "colours" based on the lowest 4 bits in the tx=
Id.<br><br></div><div class=3D"gmail_quote">A transaction is only valid if =
all inputs into the transaction are the correct colour for that block.<br>
<br></div><div class=3D"gmail_quote">This allows blocks to be created in ad=
vance.=C2=A0 If you are processing colour 7 at the moment, you can have a c=
olour 8 block ready.<br><br></div><div class=3D"gmail_quote">16 colours is =
probably to many.=C2=A0=C2=A0 It would only be necessary for things like 1 =
second block rates.<br>
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The d=
isadvantage is that wallets would have to make sure that they have coins fo=
r each of the 16 colours.<br><br>If you spend the wrong colour, you add 16 =
block times of latency.<br>
</div>=C2=A0<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That said, I think using a fast confirmation share-chain is much<br>
better than decreasing block times and could be a very useful tool if<br>
we believe that there are many applications which could be improved<br>
with e.g. a 30 second or 1 minute interblock time. =C2=A0Mostly my thinking=
<br>
has been that these retail applications really want sub-second<br>
confirmation, which can't reasonably be provided in this manner so I<br=
>
didn't mention it in this thread.<br></blockquote><div><br></div><div>I=
n a shop setting, you could set it up so that the person scans a QR-code to=
setup a channel with the shop.<br><br></div><div>They can then scan all th=
eir stuff and by the time they have done that, the channel would be ready.<=
br>
<br></div><div>If there was a queue, it could be done when the person enter=
s the queue.<br><br></div><div>In fact, there could be QR-codes at multiple=
locations.<br></div></div></div></div>
--001a11c12d1812165c04f7bd3859--
|
