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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Wd4tC-00072Z-9E
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 21:39:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.52 as permitted sender)
client-ip=209.85.215.52; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f52.google.com;
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd4tB-000555-9g
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 21:39:34 +0000
Received: by mail-la0-f52.google.com with SMTP id mc6so138338lab.25
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 14:39:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.154.102 with SMTP id vn6mr86527lbb.55.1398289166481;
Wed, 23 Apr 2014 14:39:26 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 14:39:26 -0700 (PDT)
In-Reply-To: <CAE-z3OX7AppQeBcMBArccELQxnZBPNCefiRJvTt0gYYjxKAQuQ@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>
Date: Wed, 23 Apr 2014 14:39:26 -0700
Message-ID: <CAAS2fgQQyY=BGcM21EJiMkwBH0G5J57ahYEiD=bQTuprLHrHPA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Wd4tB-000555-9g
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 21:39:34 -0000
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> An interesting experiment would be a transaction "proof of publication"
> chain.
>
> Each transaction would be added to that chain when it is received. It co=
uld
> be merge mined with the main chain.
>
> If the size was limited, then it doesn't even require spam protection.
>
> Blocks could be "discouraged" if they have transactions which violate the
> ordering in that chain. Miners could still decide which transactions the=
y
> include, but couldn't include transactions which are double spends.
>
> The locktime/final field could be used for transactions which want to be
> replaceable.
>
> The chain could use some of the fast block proposals. For example, it co=
uld
> include orphans of a block when computing the block's POW.
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.. 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.
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.
One of the neat things about this is that you can introduce it totally
separately from Bitcoin without any consensus or approval from anyone
else=E2=80=94 E.g. P2pool builds such a chain today though it doesn't enfor=
ce
transactions. It would immediately provide the useful service of
demonstrating that some chunk of hashpower was currently working on
including a particular set of transactions. Once the details were
worked out it could be added as a soft-forking requirement to the
commonly run system.
|
