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
|
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 <tier.nolan@gmail.com>) id 1Xnd0x-0002OC-5F
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Nov 2014 00:39:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.48 as permitted sender)
client-ip=209.85.192.48; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f48.google.com;
Received: from mail-qg0-f48.google.com ([209.85.192.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xnd0w-0002cj-0d
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Nov 2014 00:39:27 +0000
Received: by mail-qg0-f48.google.com with SMTP id q108so4828349qgd.35
for <bitcoin-development@lists.sourceforge.net>;
Sun, 09 Nov 2014 16:39:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.193.5 with SMTP id ds5mr39448476qcb.30.1415579960540;
Sun, 09 Nov 2014 16:39:20 -0800 (PST)
Received: by 10.140.41.18 with HTTP; Sun, 9 Nov 2014 16:39:20 -0800 (PST)
In-Reply-To: <CAE-z3OW3=mBNC_p911y6HspF4r9g=sSPM2S-mmBTm+=hoxDprA@mail.gmail.com>
References: <CAE-z3OW3=mBNC_p911y6HspF4r9g=sSPM2S-mmBTm+=hoxDprA@mail.gmail.com>
Date: Mon, 10 Nov 2014 00:39:20 +0000
Message-ID: <CAE-z3OXr0wudFe2qVs0i8Y0PNtHUmfS_PDiOH5UeRyf1LnJC2A@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133a186b322830507766477
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: 1Xnd0w-0002cj-0d
Subject: Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
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, 10 Nov 2014 00:39:27 -0000
--001a1133a186b322830507766477
Content-Type: text/plain; charset=UTF-8
I made some changes to the draft. The merkleblock now has the auxiliary
header information too.
There is a tradeoff between overhead and delayed transactions. Is 12.5%
transactions being delayed to the next block unacceptable? Would adding
padding transactions be an improvement?
Creating the "seed" transactions is an implementation headache.
Each node needs to have control over an UTXO to create the final
transaction in the block that has the digest of the auxiliary header. This
means that it is not possible to simply start a node and have it mine. It
has to somehow be given the private key. If two nodes were given the same
key by accident, then one could end up blocking the other.
On one end of the scale is adding a transaction with a few thousand outputs
into the block chain. The signatures for locktime restricted transactions
that spend those outputs could be hard-coded into the software. This is
the easiest to implement, but would mean a large table of signatures. The
person who generates the signature list would have to be trusted not to
spend the outputs early.
The other end of the scale means that mining nodes need to include a
wallets to manage their UTXO entry. Miners can split a zero value output
into lots of outputs, if they wish.
A middle ground would be for nodes to be able to detect the special
transactions and use them. A server could send out timelocked transactions
that pay to a particular address but the transaction would be timelocked.
The private key for the output would be known. However, miners who mine
version 2 blocks wouldn't be able to spend them early.
On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
> in a bandwidth efficient way. The overhead per auxiliary header is only
> around 104 bytes per header. This is much smaller than would be required
> by embedding the hash of the header in the coinbase of the block.
>
> It is a soft fork and it uses the last transaction in the block to store
> the hash of the auxiliary header.
>
> It makes use of the fact that the last transaction in the block has a much
> less complex Merkle branch than the other transactions.
>
> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
>
>
--001a1133a186b322830507766477
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I made some changes to the draft.=C2=A0 The merkleblo=
ck now has the auxiliary header information too.<br><br></div><div>There is=
a tradeoff between overhead and delayed transactions.=C2=A0 Is 12.5% trans=
actions being delayed to the next block unacceptable?=C2=A0 Would adding pa=
dding transactions be an improvement?<br><br></div><div>Creating the "=
seed" transactions is an implementation headache.<br><br></div><div>Ea=
ch node needs to have control over an UTXO to create the final transaction =
in the block that has the digest of the auxiliary header.=C2=A0 This means =
that it is not possible to simply start a node and have it mine.=C2=A0 It h=
as to somehow be given the private key.=C2=A0 If two nodes were given the s=
ame key by accident, then one could end up blocking the other.<br><br></div=
><div>On one end of the scale is adding a transaction with a few thousand o=
utputs into the block chain.=C2=A0 The signatures for locktime restricted t=
ransactions that spend those outputs could be hard-coded into the software.=
=C2=A0 This is the easiest to implement, but would mean a large table of si=
gnatures.=C2=A0 The person who generates the signature list would have to b=
e trusted not to spend the outputs early.<br><br></div><div>The other end o=
f the scale means that mining nodes need to include a wallets to manage the=
ir UTXO entry.=C2=A0 Miners can split a zero value output into lots of outp=
uts, if they wish.<br><br></div><div>A middle ground would be for nodes to =
be able to detect the special transactions and use them.=C2=A0 A server cou=
ld send out timelocked transactions that pay to a particular address but th=
e transaction would be timelocked.=C2=A0 The private key for the output wou=
ld be known.=C2=A0 However, miners who mine version 2 blocks wouldn't b=
e able to spend them early.<br></div><div><br></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Sat, Nov 8, 2014 at 11:45 PM, T=
ier Nolan <span dir=3D"ltr"><<a href=3D"mailto:tier.nolan@gmail.com" tar=
get=3D"_blank">tier.nolan@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div>I created a draft BIP detailing=
a way to add auxiliary headers to Bitcoin in a bandwidth efficient way.=C2=
=A0 The overhead per auxiliary header is only around 104 bytes per header.=
=C2=A0 This is much smaller than would be required by embedding the hash of=
the header in the coinbase of the block.<br><br></div>It is a soft fork an=
d it uses the last transaction in the block to store the hash of the auxili=
ary header.<br><br></div>It makes use of the fact that the last transaction=
in the block has a much less complex Merkle branch than the other transact=
ions.<br><div><div><div><br><a href=3D"https://github.com/TierNolan/bips/bl=
ob/aux_header/bip-aux-header.mediawiki" target=3D"_blank">https://github.co=
m/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki</a><br><br></div>=
</div></div></div>
</blockquote></div><br></div>
--001a1133a186b322830507766477--
|
