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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WLXLG-00026n-44 for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 12:24:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WLXLE-0000ir-Ir
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 12:24:02 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WLXL6-0007DK-Jk for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 13:23:52 +0100
Received: from 69-172-146-209.cable.teksavvy.com ([69.172.146.209])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 13:23:52 +0100
Received: from carterd by 69-172-146-209.cable.teksavvy.com with local (Gmexim
0.1 (Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 13:23:52 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Dan Carter <carterd@gmail.com>
Date: Thu, 06 Mar 2014 04:23:40 -0800
Message-ID: <531868CC.807@gmail.com>
References: <20140106120338.GA14918@savin>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 69-172-146-209.cable.teksavvy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:29.0) Gecko/20100101 Thunderbird/29.0a1
In-Reply-To: <20140106120338.GA14918@savin>
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-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
(carterd[at]gmail.com)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1WLXLE-0000ir-Ir
Subject: Re: [Bitcoin-development] Stealth Addresses
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: Thu, 06 Mar 2014 12:24:02 -0000
I think stealth addresses combined with zk-snarks would obviate the need
for CoinJoin. zk-snarks could be used to hide the coin's value and
stealth addresses could be used to hide the recipient for payments and
even mined coins. More info on zero-knowledge snarks:
http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf
http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf
Start with a mined coin: generate a coin secret, create a coinbase
transaction with an output to your stealth address and send
hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value)
where only the recipient (you) can decrypt. (The reward value is known
publicly but just assume it isn't here for generality). You also embed
the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in
fact SHA256(coin-secret + reward-value), where your private witnesses
are (coin-secret, reward-value).
Now you could split a coin into as many pieces as you want in a single
transaction and send to multiple recipients, some pieces go to yourself
(change) and others to the payee, every piece would have a different
recipient address thanks to stealth addresses, and all values hidden
thanks to zk-snarks.
So lets say you want to split the mined coin into two new ones. You
create a transaction where the input redeems the mined coin using mined
tx out + your stealth address, and there are two new coins as outputs to
your own stealth address each having: hash(new-coin-secret +
new-hidden-value) + encrypt(new-coin-secret + new-hidden-value). You
also embed the zk-snark proof that the two new hidden values add up to
the original hidden value, and that the two new hash results are in fact
SHA256(new-coin-secret + new-hidden-value), where your private witnesses
are (original-coin-secret, original-hidden-value, new-coin-secrets,
new-hidden-values).
If you want to merge two coins into one it's just a split backwards, two
inputs one output, zk-snark proof that two original hidden values add up
to the new hidden value and that the new hash result is
SHA256(new-coin-secret + new-hidden-value).
If you want to transfer ownership of a coin then just redeem at input,
and output same as mined coin except using recipient stealth address
(which is a public key) to encrypt(coin-secret + hidden-value).
- Dan
On 2014-01-06 4:03 AM, Peter Todd wrote:
> * Abstract
>
> A Stealth Address is a new type of Bitcoin address and related
> scriptPubKey/transaction generation scheme that allowers payees to
> publish a single, fixed, address that payors can send funds efficiently,
> privately, reliably and non-interactively. Payors do not learn what
> other payments have been made to the stealth address, and third-parties
> learn nothing at all. (both subject to an adjustable anonymity set)
|
